kernel/linux.git/drivers/extcon/Kconfig, branch v6.6.132

extcon: max8997: select IRQ_DOMAIN instead of depending on it

2024-06-12T09:12:27+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-08-05T06:42:15+00:00

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

extcon: usbc-tusb320: add USB_ROLE_SWITCH dependency

2023-05-29T14:41:07+00:00

When CONFIG_USB_ROLE_SWITCH=m, tusb320 cannot be built-in: ld.lld: error: undefined symbol: fwnode_usb_role_switch_get >>> referenced by extcon-usbc-tusb320.c >>> drivers/extcon/extcon-usbc-tusb320.o:(tusb320_probe) in archive vmlinux.a ld.lld: error: undefined symbol: usb_role_switch_set_role >>> referenced by extcon-usbc-tusb320.c >>> drivers/extcon/extcon-usbc-tusb320.o:(tusb320_state_update_handler) in archive vmlinux.a Add the appropriate Kconfig dependency to prevent this configuration but still allow the driver to be built-in when USB_ROLE_SWITCH is disabled. Fixes: df101446a402 ("extcon: usbc-tusb320: add usb_role_switch support") Signed-off-by: Arnd Bergmann Reviewed-by: Alvin Šipraga Signed-off-by: Chanwoo Choi

extcon: usbc-tusb320: Add USB TYPE-C support

2022-09-25T19:40:13+00:00

The TI TUSB320 seems like a better fit for USB TYPE-C subsystem, which can expose details collected by the TUSB320 in a far more precise way than extcon. Since there are existing users in the kernel and in DT which depend on the extcon interface, keep it for now. Add TYPE-C interface and expose the supported supply current, direction and connector polarity via the TYPE-C interface. Signed-off-by: Marek Vasut Acked-by: Heikki Krogerus Reviewed-by: Alvin Šipraga Signed-off-by: Chanwoo Choi

extcon: ptn5150: Add usb role class support

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

Some usb controller drivers may not support extcon but use usb role class as it's the preferred approach, so to support usb dual role switch with usb role class, add usb role class consumer support. Signed-off-by: Li Jun Reviewed-by: Krzysztof Kozlowski Signed-off-by: Chanwoo Choi

extcon: sm5502: Add support for SM5703

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

SM5703 is another MFD from Silicon Mitus which has a very similar MUIC unit to the one in SM5502. The only difference I've noticed is slightly different configuration only enables the interrupts which are exactly the same as on SM5502. If we make use of different interrupts in the future, this can be improved by having a separate struct for SM5703, but the main functionality (detecting cable or OTG adapter) is working properly. Signed-off-by: Markuss Broks Signed-off-by: Chanwoo Choi

extcon: intel-cht-wc: Support devs with Micro-B / USB-2 only Type-C connectors

2022-02-01T13:55:12+00:00

So far the extcon-intel-cht-wc code has only been tested on devices with a Type-C connector with USB-PD, USB3 (superspeed) and DP-altmode support through a FUSB302 Type-C controller. Some devices with the intel-cht-wc PMIC however come with an USB-micro-B connector, or an USB-2 only Type-C connector without USB-PD. Which device-model we are running on can be identified with the new cht_wc_model intel_soc_pmic field. On models without a Type-C controller the extcon code must control the Vbus 5V boost converter and the USB role switch depending on the detected cable-type. Acked-by: Chanwoo Choi Signed-off-by: Hans de Goede Signed-off-by: Sebastian Reichel

extcon: extcon-axp288: Use P-Unit semaphore lock for register accesses

2021-10-27T05:13:38+00:00

use low level P-Unit semaphore lock for axp288 register accesses directly and for more than one access a time, to reduce the number of times this semaphore is locked and released which is an expensive operation. i2c-bus to the XPower is shared between the kernel and the SoCs P-Unit. The P-Unit has a semaphore wich the kernel must lock for axp288 register accesses. When the P-Unit semaphore is locked CPU and GPU power states cannot change or the system will freeze. The P-Unit semaphore lock is already managed inside the regmap access logic, but for each access the semaphore is locked and released. So use directly iosf_mbi_(un)block_punit_i2c_access(), we are safe in doing so because nested calls to the same semaphore are turned to nops. Suggested-by: Hans de Goede Reviewed-by: Hans de Goede Tested-by: Hans de Goede Signed-off-by: Fabio Aiuto Signed-off-by: Chanwoo Choi

extcon: sm5502: Add support for SM5504

2021-06-21T09:28:01+00:00

SM5504 is another MUIC from Silicon Mitus that is fairly similar to SM5502. They seem to use the same register set, but: - SM5504 has some additional bits in SM5502_REG_CONTROL - SM5504 has a quite different set of interrupts - SM5504 reports USB OTG as dev_type1 = BIT(0) instead of BIT(7) Overall it's minor and we can support this by defining a separate struct sm5502_type for SM5504. Signed-off-by: Stephan Gerhold Signed-off-by: Chanwoo Choi

ASoC/extcon: arizona: Move arizona jack code to sound/soc/codecs/arizona-jack.c

2021-03-18T11:46:15+00:00

The jack handling for arizona codecs is being refactored so that it is done directly by the codec drivers, instead of having an extcon-driver bind to a separate "arizona-extcon" child-device for this. drivers/mfd/arizona-core.c has already been updated to no longer instantiate an "arizona-extcon" child-device for the arizona codecs. This means that the "arizona-extcon" driver is no longer useful (there are no longer any devices for it to bind to). This commit drops the extcon Kconfig / Makefile bits and moves drivers/extcon/extcon-arizona.c to sound/soc/codecs/arizona-jack.c . This is a preparation patch for converting the arizona extcon-driver into a helper library for letting the arizona codec-drivers directly report jack state through the standard sound/soc/soc-jack.c functions. Signed-off-by: Hans de Goede Acked-by: Charles Keepax Tested-by: Charles Keepax Acked-by: Chanwoo Choi Signed-off-by: Lee Jones