Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: [PATCH v1] Revert "extcon: usb-gpio: add support for ACPI gpio interface" | From | Chanwoo Choi <> | Date | Fri, 24 Mar 2017 20:47:44 +0900 |
| |
Hi Lu Baolu,
On 2017년 03월 24일 20:24, Andy Shevchenko wrote: > On Fri, 2017-03-24 at 20:03 +0900, Chanwoo Choi wrote: >> On 2017년 03월 22일 22:09, Andy Shevchenko wrote: >>> On Wed, 2017-03-22 at 10:14 +0900, Chanwoo Choi wrote: >>>> On 2017년 03월 22일 03:37, Andy Shevchenko wrote: > >>>>> The commit 942c7924a51e introduced a check for ACPI handle for >>>>> the >>>>> device that never appears on any ACPI-enabled platform so far. >>>>> It >>>>> seems >>>>> a confusion with extcon-intel-int3496 which does support ACPI- >>>>> enabled >>>>> platforms. >>>> >>>> Only for the reason that there is no any usecase until now, >>>> and remove the confusion between extcon-usb-gpio and extcon-intel- >>>> int3496. >>>> Should we revert it? >>> >>> >>>> >>>> I think that both extcon-usb-gpio and extcon-intel-int3496 >>>> driver are not same operation perfectly. Also, the filename >>>> of extcon-intel-int3496 has specific name. Instead, extcon-usb- >>>> gpio.c >>>> is more common device driver. >>>> >>>> Can the extcon-intel-int3496.c support the everything on acpi >>>> side? >>> >>> For my understanding we have the only driver for now for USB mux in >>> the >>> kernel for ACPI-enabled platforms. >>> >>> Besides confusion, it makes harder to fix a real bugs in at least >>> GPIO >>> ACPI library since we need to amend any user of it first. While >>> confusion is here, I can't do anything to not possible break the >>> functionality of the driver in a real use case if any (I doubt there >>> is >>> any in this particular case). >>> >>> So, my opinion here is "yes, we should revert it until we have a >>> confirmation that there is a product which is using this among with >>> ACPI" (which I doubt ever exists). >> >> Because you told me there was not any use case of extcon-usb-gpioc.c >> on acpi side. But, I think that it is not enough as the reason. >> >> Because I already mentioned, >> 1. >> "The both extcon-usb-gpio and extcon-intel-int3496 driver >> are not same operation perfectly." It two driver are same operation >> and there is no use case on acpi side, I may agree your suggestion. >> But, in this case, they are different between two drivers. >> >> 2. >> Also, extcon-intel-int3496 has the specific name 'int3496'. >> I think that it only depends on the specific device driver on acpi >> side. >> I don't think it cover all of use case on acpi side. > > Just one question: is there *real* existing device where ACPI table > contains something related to extcon-usb-gpio? > > I'm pretty sure the answer is no. Moreover, Lu pointed me out to the > series which tried to update the driver in question to support int3496. > Though it comes as a separate driver, thus that series was abandoned > IIUC. > > I really don't care if some dead confusing code will be left in some > poor driver, at the end it's not my call. > > P.S. We already spent enough time making a mountain out of a molehill. I > rest my case. >
OK. Just I want to receive the reply from Lu Baolu.
In the "extcon-usb-gpio ACPI support" mail thread, I understood that Lu Baolu said that the related patches were abandoned.
To Lu Baolu, Don't you ever use the extcon-usb-gpio.c in the future on acpi side? If you agree it, I'll revert it.
-- Best Regards, Chanwoo Choi Samsung Electronics
| ![\](/images/icornerr.gif) |