user/sven/linux.git/drivers/extcon, branch v5.18.3

extcon: intel-cht-wc: Report RID_A for ACA adapters

2022-02-01T13:55:12Z

Make cht_wc_extcon_get_id() report RID_A for ACA adapters, instead of reporting ID_FLOAT. According to the spec. we should read the USB-ID pin ADC value to determine the resistance of the used pull-down resister and then return RID_A / RID_B / RID_C based on this. But all "Accessory Charger Adapter"s (ACAs) which users can actually buy always use a combination of a charging port with one or more USB-A ports, so they should always use a resistor indicating RID_A. But the spec is hard to read / badly-worded so some of them actually indicate they are a RID_B ACA even though they clearly are a RID_A ACA. To workaround this simply always return INTEL_USB_RID_A, which matches all the ACAs which users can actually buy. Acked-by: Chanwoo Choi Signed-off-by: Hans de Goede Signed-off-by: Sebastian Reichel

extcon: intel-cht-wc: Add support for registering a power_supply class-device

2022-02-01T13:55:12Z

The bq25890 used on the Yogabook YB1-X90 / -X91 models relies on the extcon-driver's BC-1.2 charger detection, and the bq25890 driver expect this info to be available through a parent power_supply class-device which models the detected charger (idem to how the Type-C TCPM code registers a power_supply classdev for the connected charger). Add support for registering the power_supply class-device expected by this setup. Acked-by: Chanwoo Choi Signed-off-by: Hans de Goede Signed-off-by: Sebastian Reichel

extcon: intel-cht-wc: Refactor cht_wc_extcon_get_charger()

2022-02-01T13:55:12Z

This is a preparation patch for adding support for registering a power_supply class device. Setting usbsrc to "CHT_WC_USBSRC_TYPE_SDP << CHT_WC_USBSRC_TYPE_SHIFT" will make the following switch-case return EXTCON_CHG_USB_SDP just as before, so there is no functional change. Acked-by: Chanwoo Choi Signed-off-by: Hans de Goede Signed-off-by: Sebastian Reichel

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

2022-02-01T13:55:12Z

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: intel-cht-wc: Use new cht_wc_model intel_soc_pmic field

2022-02-01T13:55:12Z

The CHT_WC_VBUS_GPIO_CTLO GPIO actually driving an external 5V Vboost converter for Vbus depends on the board on which the Cherry Trail - Whiskey Cove PMIC is actually used. Since the information about the exact PMIC setup is necessary in other places too, struct intel_soc_pmic now has a new cht_wc_model field indicating the board model. Only poke the CHT_WC_VBUS_GPIO_CTLO GPIO if this new field is set to INTEL_CHT_WC_GPD_WIN_POCKET, which indicates the Type-C (with PD and DP-altmode) setup used on the GPD pocket and GPD win; and on which this GPIO actually controls an external 5V Vboost converter. Acked-by: Chanwoo Choi Signed-off-by: Hans de Goede Signed-off-by: Sebastian Reichel

extcon: Deduplicate code in extcon_set_state_sync()

2021-12-24T06:27:52Z

Finding the cable index and checking for changed status is also done in extcon_set_state(). So calling extcon_set_state_sync() will do these checks twice. Remove them and use these checks from extcon_set_state(). Signed-off-by: Alexander Stein Signed-off-by: Chanwoo Choi

extcon: usb-gpio: fix a non-kernel-doc comment

2021-12-24T06:27:52Z

Do not use "/**" to begin a non-kernel-doc comment. Fixes this build warning: drivers/extcon/extcon-usb-gpio.c:23: warning: expecting prototype for drivers/extcon/extcon-usb-gpio.c(). Signed-off-by: Randy Dunlap Reported-by: kernel test robot Signed-off-by: Chanwoo Choi

extcon: usbc-tusb320: Add support for TUSB320L

2021-10-27T05:13:39Z

TUSB320L is a newer chip with additional features, and it has additional steps in its mode changing sequence: - Disable CC state machine, - Write to mode register, - Wait for 5 ms, - Re-enable CC state machine. It also has an additional register that a revision number can be read from. Add support for the mode changing sequence, and read the revision number during probe and print it as info. Signed-off-by: Yassine Oudjana Signed-off-by: Chanwoo Choi

extcon: usbc-tusb320: Add support for mode setting and reset

2021-10-27T05:13:38Z

Reset the chip and set its mode to default (maintain mode set by PORT pin) during probe to make sure it comes up in the default state. Signed-off-by: Yassine Oudjana Signed-off-by: Chanwoo Choi

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

2021-10-27T05:13:38Z

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