kernel/linux.git/drivers/extcon, branch v6.1.168

extcon: adc-jack: Cleanup wakeup source only if it was enabled

2025-12-06T21:12:30+00:00

commit 92bac7d4de9c07933f6b76d8f1c7f8240f911f4f upstream. Driver in the probe enables wakeup source conditionally, so the cleanup path should do the same - do not release the wakeup source memory if it was not allocated. Link: https://lore.kernel.org/lkml/20250509071703.39442-2-krzysztof.kozlowski@linaro.org/ Reported-by: Christophe JAILLET Closes: https://lore.kernel.org/r/22aaebb7-553b-4571-8a43-58a523241082@wanadoo.fr/ Fixes: 78b6a991eb6c ("extcon: adc-jack: Fix wakeup source leaks on device unbind") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Chanwoo Choi Signed-off-by: Greg Kroah-Hartman

extcon: adc-jack: Fix wakeup source leaks on device unbind

2025-12-06T21:12:20+00:00

[ Upstream commit 78b6a991eb6c6f19ed7d0ac91cda3b3b117fda8f ] Device can be unbound, so driver must also release memory for the wakeup source. Do not use devm interface, because it would change the order of cleanup. Link: https://lore.kernel.org/lkml/20250501-device-wakeup-leak-extcon-v2-1-7af77802cbea@linaro.org/ Acked-by: MyungJoo Ham Signed-off-by: Krzysztof Kozlowski Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin

extcon: max8997: select IRQ_DOMAIN instead of depending on it

2024-06-12T09:03:41+00:00

[ Upstream commit b1781d0a1458070d40134e4f3412ec9d70099bec ] IRQ_DOMAIN is a hidden (not user visible) symbol. Users cannot set it directly thru "make *config", so drivers should select it instead of depending on it if they need it. Relying on it being set for a dependency is risky. Consistently using "select" or "depends on" can also help reduce Kconfig circular dependency issues. Therefore, change EXTCON_MAX8997's use of "depends on" for IRQ_DOMAIN to "select". Link: https://lore.kernel.org/lkml/20240213060028.9744-1-rdunlap@infradead.org/ Fixes: dca1a71e4108 ("extcon: Add support irq domain for MAX8997 muic") Signed-off-by: Randy Dunlap Acked-by: Arnd Bergmann Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin

extcon: cht_wc: add POWER_SUPPLY dependency

2023-09-13T07:42:53+00:00

[ Upstream commit d20a3a8a32e3fa564ff25da860c5fc1a97642dfe ] The driver fails to link when CONFIG_POWER_SUPPLY is disabled: x86_64-linux-ld: vmlinux.o: in function `cht_wc_extcon_psy_get_prop': extcon-intel-cht-wc.c:(.text+0x15ccda7): undefined reference to `power_supply_get_drvdata' x86_64-linux-ld: vmlinux.o: in function `cht_wc_extcon_pwrsrc_event': extcon-intel-cht-wc.c:(.text+0x15cd3e9): undefined reference to `power_supply_changed' x86_64-linux-ld: vmlinux.o: in function `cht_wc_extcon_probe': extcon-intel-cht-wc.c:(.text+0x15cd596): undefined reference to `devm_power_supply_register' It should be possible to change the driver to not require this at compile time and still provide other functions, but adding a hard Kconfig dependency does not seem to have any practical downsides and is simpler since the option is normally enabled anyway. Fixes: 66e31186cd2aa ("extcon: intel-cht-wc: Add support for registering a power_supply class-device") Signed-off-by: Arnd Bergmann Reviewed-by: Hans de Goede Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin

extcon: usbc-tusb320: Unregister typec port on driver removal

2023-07-19T14:22:08+00:00

[ Upstream commit 3adbaa30d973093a4f37927baf9596cca51b593d ] The driver can register a typec port if suitable firmware properties are present. But if the driver is removed through sysfs unbind, rmmod or similar, then it does not clean up after itself and the typec port device remains registered. This can be seen in sysfs, where stale typec ports get left over in /sys/class/typec. In order to fix this we have to add an i2c_driver remove function and call typec_unregister_port(), which is a no-op in the case where no typec port is created and the pointer remains NULL. In the process we should also put the fwnode_handle when the typec port isn't registered anymore, including if an error occurs during probe. The typec subsystem does not increase or decrease the reference counter for us, so we track it in the driver's private data. Note that the conditional check on TYPEC_PWR_MODE_PD was removed in the probe path because a call to tusb320_set_adv_pwr_mode() will perform an even more robust validation immediately after, hence there is no functional change here. Fixes: bf7571c00dca ("extcon: usbc-tusb320: Add USB TYPE-C support") Cc: stable@vger.kernel.org Signed-off-by: Alvin Šipraga Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin

extcon: usbc-tusb320: Convert to i2c's .probe_new()

2023-07-19T14:22:08+00:00

[ Upstream commit 5313121b22fd11db0d14f305c110168b8176efdc ] The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König Signed-off-by: Chanwoo Choi Stable-dep-of: 3adbaa30d973 ("extcon: usbc-tusb320: Unregister typec port on driver removal") Signed-off-by: Sasha Levin

extcon: Fix kernel doc of property capability fields to avoid warnings

2023-07-19T14:21:52+00:00

[ Upstream commit 73346b9965ebda2feb7fef8629e9b28baee820e3 ] Kernel documentation has to be synchronized with a code, otherwise the validator is not happy: Function parameter or member 'usb_bits' not described in 'extcon_cable' Function parameter or member 'chg_bits' not described in 'extcon_cable' Function parameter or member 'jack_bits' not described in 'extcon_cable' Function parameter or member 'disp_bits' not described in 'extcon_cable' Describe the fields added in the past. Fixes: ceaa98f442cf ("extcon: Add the support for the capability of each property") Signed-off-by: Andy Shevchenko Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin

extcon: Fix kernel doc of property fields to avoid warnings

2023-07-19T14:21:52+00:00

[ Upstream commit 7e77e0b7a9f4cdf91cb0950749b40c840ea63efc ] Kernel documentation has to be synchronized with a code, otherwise the validator is not happy: Function parameter or member 'usb_propval' not described in 'extcon_cable' Function parameter or member 'chg_propval' not described in 'extcon_cable' Function parameter or member 'jack_propval' not described in 'extcon_cable' Function parameter or member 'disp_propval' not described in 'extcon_cable' Describe the fields added in the past. Fixes: 067c1652e7a7 ("extcon: Add the support for extcon property according to extcon type") Signed-off-by: Andy Shevchenko Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin

extcon: usbc-tusb320: Update state on probe even if no IRQ pending

2022-12-31T12:32:39+00:00

[ Upstream commit 581c848b610dbf3fe1ed4d85fd53d0743c61faba ] Currently this driver triggers extcon and typec state update in its probe function, to read out current state reported by the chip and report the correct state to upper layers. This synchronization is performed correctly, but only in case the chip indicates a pending interrupt in reg09 register. This fails to cover the situation where all interrupts reported by the chip were already handled by Linux before reboot, then the system rebooted, and then Linux starts again. In this case, the TUSB320 no longer reports any interrupts in reg09, and the state update does not perform any update as it depends on that interrupt indication. Fix this by turning tusb320_irq_handler() into a thin wrapper around tusb320_state_update_handler(), where the later now contains the bulk of the code of tusb320_irq_handler(), but adds new function parameter "force_update". The "force_update" parameter can be used by the probe function to assure that the state synchronization is always performed, independent of the interrupt indicated in reg09. The interrupt handler tusb320_irq_handler() callback uses force_update=false to avoid state updates on potential spurious interrupts and retain current behavior. Fixes: 06bc4ca115cdd ("extcon: Add driver for TI TUSB320") Signed-off-by: Marek Vasut Reviewed-by: Alvin Šipraga Acked-by: Heikki Krogerus Link: https://lore.kernel.org/r/20221120141509.81012-1-marex@denx.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

extcon: usbc-tusb320: Call the Type-C IRQ handler only if a port is registered

2022-11-08T15:45:31+00:00

Commit bf7571c00dca ("extcon: usbc-tusb320: Add USB TYPE-C support") added an optional Type-C interface to the driver but missed to check if it is in use when calling the IRQ handler. This causes an oops on devices currently using the old extcon interface. Check if a Type-C port is registered before calling the Type-C IRQ handler. Fixes: bf7571c00dca ("extcon: usbc-tusb320: Add USB TYPE-C support") Signed-off-by: Yassine Oudjana Reviewed-by: Marek Vasut Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20221107153317.657803-1-y.oudjana@protonmail.com Signed-off-by: Greg Kroah-Hartman