On 11/23/25 12:03 PM, Maud Spierings wrote: > On 11/22/25 14:37, Konrad Dybcio wrote: >> On 11/22/25 12:07 PM, Maud Spierings wrote: >>> On 11/20/25 16:36, Konrad Dybcio wrote: >>>> On 11/17/25 4:44 PM, Maud Spierings wrote: >>>>> On 11/17/25 16:35, Konrad Dybcio wrote: >>>>>> On 11/17/25 3:13 PM, Maud Spierings wrote: >>>>>>> Hi Konrad, >>>>>>> >>>>>>> On 11/17/25 13:59, Konrad Dybcio wrote: >>>>>>>> On 11/16/25 11:52 AM, Maud Spierings via B4 Relay wrote: >>>>>>>>> From: Maud Spierings <[email protected]> >>>>>>>>> >>>>>>>>> Add nvmem cells for getting charge control thresholds if they have >>>>>>>>> been set previously. >>>>>>>>> >>>>>>>>> Signed-off-by: Maud Spierings <[email protected]> >>>>>>>>> --- >>>>>>>> Have you verified that e.g. >>>>>>>> >>>>>>>> connecting the charger >>>>>>>> setting the charge threshold >>>>>>>> rebooting to windows >>>>>>>> rebooting to windows once more for good measure >>>>>>>> rebooting to linux >>>>>>>> >>>>>>>> still has the settings persist? >>>>>>> Hmm I have tried several things but I can't seem to get the values to >>>>>>> stick. I the spmi-sdam driver is compiled in, I am not quite sure if I >>>>>>> might be missing something. >>>>>> Hm, I wonder if Windows/UEFI overwrites these values or whether they're >>>>>> used by something else.. >>>>>> >>>>>> Can you set a threshold in windows and see if Linux can read back that >>>>>> data? >>>>> the values in /sys/class/power_supply/jada-jada/ are zero when rebooting >>>>> from Windows into Linux after enabling charge limitting in the Asus >>>>> application. >>>>> >>>>> I remember my old vivobook (x86) also forgot its settings each boot, but >>>>> given the nvmem cells that should not be happing here I guess. It is odd >>>>> that there seems to be no collision between Windows and Linux. Maybe the >>>>> Windows mechanism is doing the old trick of writing it in there every >>>>> boot? >>>> Odd indeed.. Does it work if you reboot from Linux to Linux? >>> It seems not, I seem to remember testing it quite some time ago, but I >>> cannot get it to remember any way, at least it is not popping up in sysfs, >>> always back to 0 >> It seems like the driver currently only populates the sysfs start/stop >> values if the "enable" bit is set >> >> Could you check this (hacky and wrong) diff and give it another try? >> >> diff --git a/drivers/power/supply/qcom_battmgr.c >> b/drivers/power/supply/qcom_battmgr.c >> index c8028606bba0..9ebd8adfb8eb 100644 >> --- a/drivers/power/supply/qcom_battmgr.c >> +++ b/drivers/power/supply/qcom_battmgr.c >> @@ -733,7 +733,7 @@ static int >> qcom_battmgr_charge_control_thresholds_init(struct qcom_battmgr *batt >> u8 en, end_soc, start_soc, delta_soc; >> ret = nvmem_cell_read_u8(battmgr->dev->parent, "charge_limit_en", >> &en); >> - if (!ret && en != 0) { >> + if (!ret) { >> ret = nvmem_cell_read_u8(battmgr->dev->parent, >> "charge_limit_end", &end_soc); >> if (ret < 0) >> return ret; >> >> > Nope still nothing, there is one err about "failed to send synthetic uevent: > -11" during startup, but I don't know how relevant that is.
Hm, I'm a little puzzled.. It may be that ASUS customized the charge control functionality, but I doubt that In any case, this patch should let you limit the charging bounds within a single boot on Linux, so that's already useful.. Reviewed-by: Konrad Dybcio <[email protected]> Konrad
