kernel/linux.git/drivers/extcon/extcon-intel-int3496.c, branch linux-7.1.y

extcon: int3496: replace use of system_wq with system_percpu_wq

2026-03-20T02:20:43+00:00

Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistentcy cannot be addressed without refactoring the API. This patch continues the effort to refactor worqueue APIs, which has begun with the change introducing new workqueues and a new alloc_workqueue flag: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") system_wq should be the per-cpu workqueue, yet in this name nothing makes that clear, so replace system_wq with system_percpu_wq. The old wq (system_wq) will be kept for a few release cycles. Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari Signed-off-by: Chanwoo Choi Link: https://lore.kernel.org/lkml/20251104110105.116858-1-marco.crivellari@suse.com/

extcon: int3496: Add support for controlling Vbus through a regulator

2022-05-13T08:03:40+00:00

On some boards the 5V vboost-regulator for powering devices connected to the micro USB connector is not controlled through a GPIO. This happens for example when the 5V vboost-regulator is integrated into the charger IC and controlled over I2C. Add support for controlling the 5V vboost-regulator through the regulator framework for such boards. Signed-off-by: Hans de Goede Signed-off-by: Chanwoo Choi

extcon: int3496: Add support for binding to plain platform devices

2022-05-13T08:03:40+00:00

On some X86 Android tablets the DSTD lack the INT3496 ACPI device, while also not handling micro USB port ID pin events inside the DSDT (instead the forked factory image kernel has things hardcoded). The new drivers/platform/x86/x86-android-tablets.c module manually instantiates an intel-int3496 device for these tablets. Add support to the extcon-intel-int3496 driver to bind to devices without an ACPI companion and export a normal platform_device modalias for automatic module loading. Signed-off-by: Hans de Goede Signed-off-by: Chanwoo Choi

extcon: int3496: Request non-exclusive access to the ID GPIO

2022-05-13T08:03:40+00:00

Some DSDTs are buggy and do a read from the ID pin during the ACPI initialization, causing the pin to be marked as owned by: "ACPI:OpRegion" and causing gpiod_get() to fail with -EBUSY. Pass the GPIOD_FLAGS_BIT_NONEXCLUSIVE flag to the gpiod_get() call to work around this. Signed-off-by: Hans de Goede Signed-off-by: Chanwoo Choi

extcon: int3496: Make the driver a bit less verbose

2022-05-13T08:03:40+00:00

On all devices which I have with an INT3496 ACPI device, there is only an ID pin defined. Change the log-messages about not being able to get GPIOs for "VBUS EN" and "USB MUX" to use dev_dbg(). Signed-off-by: Hans de Goede Signed-off-by: Chanwoo Choi

extconn: Clean-up few drivers by using managed work init

2021-03-23T14:22:40+00:00

Few drivers implement remove call-back only for ensuring a delayed work gets cancelled prior driver removal. Clean-up these by switching to use devm_delayed_work_autocancel() instead. Additionally, this helps avoiding mixing devm and manual resource management and cleans up a (theoretical?) bug from extconn-palmas.c and extcon-qcom-spmi-misc.c where (devm managed)IRQ might schedule new work item after wq was cleaned at remove(). This change is compile-tested only. All testing is appreciated. Reviewed-by: Hans de Goede Signed-off-by: Matti Vaittinen Link: https://lore.kernel.org/r/b1030eddbf0069f2d39e951be1d8e40d6413aeeb.1616506559.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Greg Kroah-Hartman

extcon: int3496: Convert to use SPDX identifier

2018-08-28T02:21:15+00:00

Convert driver to use SPDX identifier. While here, fix MODULE_LICENSE() string to be the same as license text states. Signed-off-by: Andy Shevchenko Signed-off-by: Chanwoo Choi

extcon: int3496: Use proper GPIO include

2018-07-12T00:06:30+00:00

Since commit eca0f13c836a ("extcon: int3496: Ignore incorrect IoRestriction for ID pin"), the driver doesn't use GPIOF_* flags anymore. We can thus now drop the deprecated include file for GPIO and use the new one. Signed-off-by: Wolfram Sang Signed-off-by: Chanwoo Choi

extcon: int3496: Ignore incorrect IoRestriction for ID pin

2018-03-21T04:58:07+00:00

The commit 70216fd937fe ("extcon: int3496: Set the id pin to direction-input if necessary") introduced a workaround for incorrect IoRestriction mode in ACPI table. Now, when GPIO ACPI library does it in generic way, see the commit 1b2ca32ab0b8 ("gpiolib: acpi: Introduce NO_RESTRICTION quirk") for the details, just set an appropriate quirk flag instead. Reviewed-by: Hans de Goede Tested-by: Hans de Goede Signed-off-by: Andy Shevchenko Signed-off-by: Chanwoo Choi

extcon: int3496: process id-pin first so that we start with the right status

2018-02-13T21:37:33+00:00

Some other drivers may be waiting for our extcon to show-up, exiting their probe methods with -EPROBE_DEFER until we show up. These drivers will typically get the cable state directly after getting the extcon, this commit changes the int3496 code to wait for the initial processing of the id-pin to complete before exiting probe() with 0, which will cause devices waiting on the defered probe to get reprobed. This fixes a race where the initial work might still be running while other drivers were already calling extcon_get_state(). Fixes: 2f556bdb9f2e ("extcon: int3496: Add Intel INT3496 ACPI ... driver") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Signed-off-by: Chanwoo Choi