linux-kernel - Re: [PATCH v1] Revert "extcon: usb-gpio: add support for ACPI gpio interface"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 24 Mar 2017 20:03:20 +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>
Cc:     Lu Baolu <baolu.lu@...ux.intel.com>
Subject: Re: [PATCH v1] Revert
 "extcon: usb-gpio: add support for ACPI gpio interface"

Hi,

On 2017년 03월 22일 22:09, Andy Shevchenko wrote:
> On Wed, 2017-03-22 at 10:14 +0900, Chanwoo Choi wrote:
>> Hi,
>>
>> 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.

> 
>>
>>>
>>> Revert commit 942c7924a51e to avoid any confusion in the future.
>>>
>>> Cc: Lu Baolu <baolu.lu@...ux.intel.com>
>>> Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
>>> ---
>>>  drivers/extcon/extcon-usb-gpio.c | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/extcon/extcon-usb-gpio.c
>>> b/drivers/extcon/extcon-usb-gpio.c
>>> index d47573a31e17..9c925b05b7aa 100644
>>> --- a/drivers/extcon/extcon-usb-gpio.c
>>> +++ b/drivers/extcon/extcon-usb-gpio.c
>>> @@ -26,7 +26,6 @@
>>>  #include <linux/platform_device.h>
>>>  #include <linux/slab.h>
>>>  #include <linux/workqueue.h>
>>> -#include <linux/acpi.h>
>>>  #include <linux/pinctrl/consumer.h>
>>>  
>>>  #define USB_GPIO_DEBOUNCE_MS	20	/* ms */
>>> @@ -111,7 +110,7 @@ static int usb_extcon_probe(struct
>>> platform_device *pdev)
>>>  	struct usb_extcon_info *info;
>>>  	int ret;
>>>  
>>> -	if (!np && !ACPI_HANDLE(dev))
>>> +	if (!np)
>>>  		return -EINVAL;
>>>  
>>>  	info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
>>>
>>
>>
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics