[PATCH v2 6/9] power: supply: max77693: Add USB extcon detection for enabling charging

[Artur Weber]

On 15.07.2024 14:55, Artur Weber wrote:
> Add a device tree property, "maxim,usb-connector", that can be used to
> specify a USB connector to use to detect whether a charging cable has
> been plugged in/out, and enable/disable charging accordingly.
> 
> To accommodate this, also add an internal pointer to the CHARGER regulator,
> which is used to enable/disable charging and set the input current limit
> (which will be done in subsequent commits).
> 
> The extcon listener/worker implementation is inspired by the rt5033_charger
> driver.
> 
> Signed-off-by: Artur Weber <aweber.kernel at gmail.com>
> ...> diff --git a/drivers/power/supply/max77693_charger.c 
b/drivers/power/supply/max77693_charger.c
> index 0ddaa03669a2..2dc273dd96ee 100644
> --- a/drivers/power/supply/max77693_charger.c
> +++ b/drivers/power/supply/max77693_charger.c
> ...
> +static int max77693_set_charging(struct max77693_charger *chg, bool enable)
> +{
> +	int is_enabled;
> +	int ret = 0;
> +
> +	is_enabled = regulator_is_enabled(chg->regu);
> +	if (is_enabled < 0)
> +		return is_enabled;
> +
> +	if (enable && !is_enabled)
> +		ret = regulator_enable(chg->regu);
> +	else if (!enable && is_enabled)
> +		ret = regulator_disable(chg->regu);
> +
> +	return ret;
> +}

Nevermind, the regulator-based approach simply doesn't work here, 
because we pretty frequently end up in a situation like this:

[   20.162612] ------------[ cut here ]------------
[   20.162618] WARNING: CPU: 0 PID: 29 at drivers/regulator/core.c:3015 
_regulator_disable+0x140/0x1a0
[   20.162645] unbalanced disables for CHARGER
[   20.162649] Modules linked in: fuse brcmfmac_wcc hci_uart btintel 
btbcm bluetooth snd_soc_midas_wm1811 st_accel_i2c st_sensors_i2c 
st_accel_spi st_accel brcmfmac ecdh_generic st_sensors st_sensors_spi 
ecc libaes brcmutil cfg80211 rfkill exynos_adc yamaha_yas530 
industrialio_triggered_buffer kfifo_buf exynos_rng s5p_sss cm3323 
industrialio
[   20.162737] CPU: 0 PID: 29 Comm: kworker/0:2 Tainted: G        W 
     6.10.0-postmarketos-exynos4 #82
[   20.162747] Hardware name: Samsung Exynos (Flattened Device Tree)
[   20.162754] Workqueue: events max77693_charger_extcon_work
[   20.162770] Call trace:
[   20.162778]  unwind_backtrace from show_stack+0x10/0x14
[   20.162804]  show_stack from dump_stack_lvl+0x50/0x64
[   20.162824]  dump_stack_lvl from __warn+0x94/0xc0
[   20.162838]  __warn from warn_slowpath_fmt+0x120/0x1b4
[   20.162855]  warn_slowpath_fmt from _regulator_disable+0x140/0x1a0
[   20.162873]  _regulator_disable from regulator_disable+0x34/0x6c
[   20.162890]  regulator_disable from 
max77693_charger_extcon_work+0x1e4/0x268
[   20.162907]  max77693_charger_extcon_work from 
process_one_work+0x154/0x2dc
[   20.162925]  process_one_work from worker_thread+0x250/0x438
[   20.162941]  worker_thread from kthread+0x110/0x12c
[   20.162958]  kthread from ret_from_fork+0x14/0x28
[   20.162970] Exception stack(0xc18edfb0 to 0xc18edff8)
[   20.162979] dfa0:                                     00000000 
00000000 00000000 00000000
[   20.162987] dfc0: 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 00000000
[   20.162994] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
[   20.162999] ---[ end trace 0000000000000000 ]---
[   20.163007] max77693-charger max77693-charger: failed to set charging 
(-5)

This can be reproduced by booting the device in with no cable plugged 
in, then plugging in an OTG cable. It prints the warning on connect and 
disconnect. More importantly, this prevents a switch to/from OTG mode in 
the scenarios that print a warning. (I've also encountered some issues 
with similar warnings being printed on unsuspend, but wasn't able to 
reproduce them; I'm willing to assume they were related to plugging in 
an OTG cable as the wakeup trigger.)

As far as I understand it, this is because regulator_is_enabled checks 
for the hardware state, not for the in-software regulator enable count, 
and the charging bits are flipped on by default (presumably by the 
bootloader). I thought regulator-boot-on would handle this, but clearly 
it doesn't...

Best regards
Artur