Date:   Fri, 24 Mar 2017 20:47:44 +0900
From:   Chanwoo Choi <cw00.choi@...sung.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        linux-kernel@...r.kernel.org,
        MyungJoo Ham <myungjoo.ham@...sung.com>,
        Lu Baolu <baolu.lu@...ux.intel.com>
Subject: Re: [PATCH v1] Revert
 "extcon: usb-gpio: add support for ACPI gpio interface"

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

Powered by blists - more mailing lists