kernel/drivers/extcon, branch linux-5.1.y

extcon: axp288: Add a depends on ACPI to the Kconfig entry

2019-05-31T13:43:59Z

[ Upstream commit fa3c098c2d52a268f6372fa053932e11f50cecb1 ] As Hans de Goede pointed, using this driver without ACPI makes little sense, so add ACPI dependency to Kconfig entry to fix a build error while CONFIG_ACPI is not set. drivers/extcon/extcon-axp288.c: In function 'axp288_extcon_probe': drivers/extcon/extcon-axp288.c:363:20: error: dereferencing pointer to incomplete type put_device(&adev->dev); Fixes: 0cf064db948a ("extcon: axp288: Convert to use acpi_dev_get_first_match_dev()") Reported-by: Hulk Robot Suggested-by: Hans de Goede Signed-off-by: YueHaibing Reviewed-by: Hans de Goede Reviewed-by: Mukesh Ojha Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin

extcon: arizona: Disable mic detect if running when driver is removed

2019-05-31T13:43:34Z

[ Upstream commit 00053de52231117ddc154042549f2256183ffb86 ] Microphone detection provides the button detection features on the Arizona CODECs as such it will be running if the jack is currently inserted. If the driver is unbound whilst the jack is still inserted this will cause warnings from the regulator framework as the MICVDD regulator is put but was never disabled. Correct this by disabling microphone detection on driver removal and if the microphone detection was running disable the regulator and put the runtime reference that was currently held. Signed-off-by: Charles Keepax Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin

extcon: ptn5150: fix COMPILE_TEST dependencies

2019-04-05T01:08:37Z

The PTN5150 dependencies look like they were meant to do the right thing, but they actually should not allow building without I2C for compile testing, as that results in a Kconfig warning and subsequent build failure: WARNING: unmet direct dependencies detected for REGMAP_I2C Depends on [m]: I2C [=m] Selected by [y]: - EXTCON_PTN5150 [=y] && EXTCON [=y] && (I2C [=m] && GPIOLIB [=y] || COMPILE_TEST [=y]) Selected by [m]: - EEPROM_AT24 [=m] && I2C [=m] && SYSFS [=y] - KEYBOARD_CAP11XX [=m] && !UML && INPUT [=y] && INPUT_KEYBOARD [=y] && OF [=y] && I2C [=m] - INPUT_DRV260X_HAPTICS [=m] && !UML && INPUT_MISC [=y] && INPUT [=y] && I2C [=m] && (GPIOLIB [=y] || COMPILE_TEST [=y]) - ... [many others] Add parentheses around the expression so we can compile-test without GPIOLIB but not without I2C. Fixes: 4ed754de2d66 ("extcon: Add support for ptn5150 extcon driver") Signed-off-by: Arnd Bergmann Signed-off-by: Chanwoo Choi

extcon: ptn5150: Fix return value check in ptn5150_i2c_probe()

2019-02-11T08:21:38Z

In case of error, the function devm_gpiod_get() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: Wei Yongjun Signed-off-by: Chanwoo Choi

extcon: Add support for ptn5150 extcon driver

2019-02-11T08:21:38Z

PTN5150 is a small thin low power CC (Configurationn Channel) Logic chip supporting the USB Type-C connector application with CC control logic detection and indication functions. Signed-off-by: Vijai Kumar K [cw00.choi: Fix bulid dependency and clean-up code] Signed-off-by: Chanwoo Choi

extcon: max8997: Fix lack of path setting in USB device mode

2018-11-14T00:06:32Z

MAX8997 driver disables automatic path selection from MicroUSB connector and manually sets path to either UART or USB lines. However the code for setting USB path worked only for USB host mode (when ID pin is set to ground). When standard USB cable (USB device mode) is connected, path registers are not touched. This means that once the non-USB accessory is connected to MAX8997-operated micro USB port, the path is no longer set to USB and USB device mode doesn't work. This patch fixes it by setting USB path both for USB and USB host modes. Signed-off-by: Marek Szyprowski Signed-off-by: Chanwoo Choi

extcon: max8997: Avoid forcing UART path on drive probe

2018-11-12T00:17:13Z

Driver unconditionally forces UART path during probe, probably to ensure that one can get kernel serial log as soon as possible. This approach causes some issues, especially when board is booted with non-UART cable connected to micro-USB port. For example, when USB cable is connected, UART TX/RX lines are unconditionally short-circuited to USB D+/D- lines. This is in turn recognized by a series of serial BREAK signals and some random characters when USB host tries to perform enumeration procedure. To solve the above issue and keep UART console operational as early as possible, set UART path only when USB ID reports UART capable cable. Signed-off-by: Marek Szyprowski Signed-off-by: Chanwoo Choi

extcon: max14577: Avoid forcing UART path on drive probe

2018-11-12T00:17:13Z

extcon: max77693: Avoid forcing UART path on drive probe

2018-11-12T00:17:13Z

extcon: max77843: Avoid forcing UART path on drive probe

2018-11-12T00:17:13Z