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 13:24: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 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.

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