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:   Wed, 22 Mar 2017 15:09:59 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Chanwoo Choi <cw00.choi@...sung.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"

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).

> 
> > 
> > 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);
> > 
> 
> 

-- 
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Intel Finland Oy