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...@linux.intel.com> >>> Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.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
