* Re: [PATCH v3 9/9] arm64: dts: mt6392: add mt6392 PMIC dtsi
From: Chen-Yu Tsai @ 2026-03-26 5:43 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: wens, Luca Leonardo Scorcia, linux-mediatek, Val Packett,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Linus Walleij, Liam Girdwood, Mark Brown, Gary Bisson,
Julien Massot, Louis-Alexis Eyraud, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <28102417-4a2a-4e29-afbd-d0f2aa76074b@collabora.com>
On Wed, Mar 18, 2026 at 06:22:42PM +0100, AngeloGioacchino Del Regno wrote:
> Il 18/03/26 14:54, Chen-Yu Tsai ha scritto:
> > On Wed, Mar 18, 2026 at 8:39 PM AngeloGioacchino Del Regno
> > <angelogioacchino.delregno@collabora.com> wrote:
> > >
> > > Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
> > > > From: Val Packett <val@packett.cool>
> > > >
> > > > Add the dts to be included by all boards using the MT6392 PMIC.
> > > >
> > > > Signed-off-by: Val Packett <val@packett.cool>
> > > > Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> > > > ---
> > > > arch/arm64/boot/dts/mediatek/mt6392.dtsi | 141 +++++++++++++++++++++++
> > > > 1 file changed, 141 insertions(+)
> > > > create mode 100644 arch/arm64/boot/dts/mediatek/mt6392.dtsi
> > > >
> > > > diff --git a/arch/arm64/boot/dts/mediatek/mt6392.dtsi b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
> > > > new file mode 100644
> > > > index 000000000000..fbf6f671524c
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
> > > > @@ -0,0 +1,141 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * Copyright (c) 2019 MediaTek Inc.
> > > > + * Copyright (c) 2024 Val Packett <val@packett.cool>
> > > > + */
> > > > +
> > > > +#include <dt-bindings/input/input.h>
> > > > +
> > > > +&pwrap {
> > > > + pmic: pmic {
> > > > + compatible = "mediatek,mt6392", "mediatek,mt6323";
> > > > + interrupt-controller;
> > > > + #interrupt-cells = <2>;
> > > > +
> > > > + keys {
> > > > + compatible = "mediatek,mt6392-keys";
> > > > +
> > > > + key-power {
> > > > + linux,keycodes = <KEY_POWER>;
> > > > + wakeup-source;
> > > > + };
> > > > +
> > > > + key-home {
> > > > + linux,keycodes = <KEY_HOME>;
> > > > + wakeup-source;
> > > > + };
> > > > + };
> > > > +
> > > > + pio6392: pinctrl {
> > > > + compatible = "mediatek,mt6392-pinctrl";
> > > > +
> > > > + gpio-controller;
> > > > + #gpio-cells = <2>;
> > > > + };
> > > > +
> > > > + rtc {
> > > > + compatible = "mediatek,mt6392-rtc",
> > > > + "mediatek,mt6323-rtc";
> > > > + };
> > > > +
> > > > + regulators {
> > > > + compatible = "mediatek,mt6392-regulator";
> > > > +
> > > > + mt6392_vproc_reg: buck_vproc {
> > >
> > > s/buck//g
> > >
> > > Also, no min/max voltages?!
> >
> > We really shouldn't set min/max voltages in the PMIC dtsi file.
> >
> > The min/max voltages are supposed to be the intersection of the
> > consumers acceptable operating ranges. The min/max of the regulator
> > itself is already implied by the model / compatible.
> >
>
> Your point is fair, but it's also true that some of the regulators are not
> really meant to ever output anything different than what they are supposed
> to, though, with slight variations being possible... I guess the best option
> here is to leave declaring voltages to board DTs instead, which is sensible
> in the end.
>
> Okay, agreed. Let's go with no voltages.
>
> Reminder for myself: there's a bunch of PMIC devicetrees to cleanup in here...
And to be honest, even the default names are not needed. They are again
implied by the compatible, and even the regulator's own node name.
So either we could have a whole bunch of empty regulator nodes with
labels for easy reference, or just have the upper level "regulators"
wrapper node with a "mt63??_regulators" label for board dts files
to reference and add the _used_ regulators to.
If you agree, I can do the cleanup work.
ChenYu
^ permalink raw reply
* Re: [PATCH v7 2/2] cpufreq: Add boost_freq_req QoS request
From: Viresh Kumar @ 2026-03-26 5:03 UTC (permalink / raw)
To: Pierre Gondois
Cc: linux-kernel, Lifeng Zheng, Huang Rui, Gautham R. Shenoy,
Mario Limonciello, Perry Yuan, Rafael J. Wysocki, linux-pm
In-Reply-To: <20260325165255.386576-3-pierre.gondois@arm.com>
On 25-03-26, 17:52, Pierre Gondois wrote:
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> @@ -1445,18 +1456,42 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
> cpumask_and(policy->cpus, policy->cpus, cpu_online_mask);
>
> if (new_policy) {
> + unsigned int req_nr;
Maybe rename to `count` ?
> for_each_cpu(j, policy->related_cpus) {
> per_cpu(cpufreq_cpu_data, j) = policy;
> add_cpu_dev_symlink(policy, j, get_cpu_device(j));
> }
>
> - policy->min_freq_req = kzalloc(2 * sizeof(*policy->min_freq_req),
> + req_nr = policy->boost_supported ? 3 : 2;
> + policy->min_freq_req = kzalloc(req_nr * sizeof(*policy->min_freq_req),
> GFP_KERNEL);
> if (!policy->min_freq_req) {
> ret = -ENOMEM;
> goto out_destroy_policy;
> }
>
> + if (policy->boost_supported) {
I would rather add this last: min -> max -> boost.
And change the code in free as:
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 58e3839a2140..7f5d18da78c6 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1358,17 +1358,18 @@ static void cpufreq_policy_free(struct cpufreq_policy *policy)
/* Cancel any pending policy->update work before freeing the policy. */
cancel_work_sync(&policy->update);
- if (policy->max_freq_req) {
+ if (policy->boost_freq_req) {
/*
- * Remove max_freq_req after sending CPUFREQ_REMOVE_POLICY
+ * Remove boost_freq_req after sending CPUFREQ_REMOVE_POLICY
* notification, since CPUFREQ_CREATE_POLICY notification was
- * sent after adding max_freq_req earlier.
+ * sent after adding boost_freq_req earlier.
*/
blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
CPUFREQ_REMOVE_POLICY, policy);
- freq_qos_remove_request(policy->max_freq_req);
+ freq_qos_remove_request(policy->boost_freq_req);
}
+ freq_qos_remove_request(policy->max_freq_req);
freq_qos_remove_request(policy->min_freq_req);
kfree(policy->min_freq_req);
> + policy->boost_freq_req = policy->min_freq_req + 2;
> +
> + /*
> + * If boost is supported,
> + * init the constraint with cpuinfo.max_freq.
> + */
Don't need a comment for obvious code ?
> + ret = freq_qos_add_request(&policy->constraints,
> + policy->boost_freq_req,
> + FREQ_QOS_MAX,
> + policy->cpuinfo.max_freq);
> + if (ret < 0) {
> + /*
> + * So we don't call freq_qos_remove_request() for an
> + * uninitialized request.
> + */
Actually we are calling freq_qos_remove_request() for NULL values. This comment
and other exiting ones like this can be removed I guess. They aren't adding much
value.
--
viresh
^ permalink raw reply related
* Re: [PATCH v7 1/2] cpufreq: Remove per-CPU QoS constraint
From: Viresh Kumar @ 2026-03-26 4:37 UTC (permalink / raw)
To: Pierre Gondois
Cc: linux-kernel, Lifeng Zheng, Huang Rui, Gautham R. Shenoy,
Mario Limonciello, Perry Yuan, Rafael J. Wysocki, linux-pm
In-Reply-To: <20260325165255.386576-2-pierre.gondois@arm.com>
What do you mean by per-CPU QOS constraint in Subject ? This is per-policy
constraint and you are not removing it, you are just avoiding to update it in
one of the paths.
On 25-03-26, 17:52, Pierre Gondois wrote:
> policy->max_freq_req QoS constraint represents the maximal allowed
> frequency than can be requested. It is set by:
> - writing to policyX/scaling_max sysfs file
> - toggling the cpufreq/boost sysfs file
>
> Upon calling freq_qos_update_request(), a successful update
> of the max_freq_req value triggers cpufreq_notifier_max(),
> followed by cpufreq_set_policy() which update the requested
> frequency for the policy.
> If the new max_freq_req value is not different from the
> original value, no frequency update is triggered.
>
> In a specific sequence of toggling:
> - cpufreq/boost sysfs file
> - CPU hot-plugging
> a CPU could end up with boost enabled but running at the
> maximal non-boost frequency, cpufreq_notifier_max() not being
> triggered. The following fixed that:
> commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging
> a CPU")
>
> The following:
> commit dd016f379ebc ("cpufreq: Introduce a more generic way to
> set default per-policy boost flag")
> also fixed the issue by correctly setting the max_freq_req
> constraint of a policy that is re-activated. This makes the
> first fix unnecessary.
>
> As the original issue is fixed by another method,
> this patch reverts:
> commit 1608f0230510 ("cpufreq: Fix re-boost issue after hotplugging
> a CPU")
Looks okay otherwise.
--
viresh
^ permalink raw reply
* Re: [PATCH v6 3/4] cpufreq: Set policy->min and max as real QoS constraints
From: Viresh Kumar @ 2026-03-26 4:26 UTC (permalink / raw)
To: Pierre Gondois
Cc: linux-kernel, Jie Zhan, Lifeng Zheng, Ionela Voinescu,
Sumit Gupta, Huang Rui, Gautham R. Shenoy, Mario Limonciello,
Perry Yuan, Rafael J. Wysocki, Srinivas Pandruvada, Len Brown,
Saravana Kannan, linux-pm
In-Reply-To: <583fd75b-d510-488b-854d-51312dd18e56@arm.com>
On 25-03-26, 17:54, Pierre Gondois wrote:
> Is the current state of this patch + the above modification acceptable ?
I will review it closely again once you send it.. There were too many small
changes and I got confused earlier :)
--
viresh
^ permalink raw reply
* Re: [PATCH v3 7/8] arm64: dts: qcom: sdm845-db845c: describe WiFi/BT properly
From: Dmitry Baryshkov @ 2026-03-26 1:59 UTC (permalink / raw)
To: David Heidelberg
Cc: Bjorn Andersson, Konrad Dybcio, Vinod Koul, linux-arm-msm,
Liam Girdwood, linux-kernel, devicetree, Luiz Augusto von Dentz,
Rob Herring, linux-bluetooth, Balakrishna Godavarthi,
Matthias Kaehlcke, linux-wireless, Jeff Johnson, ath10k, linux-pm,
Bartosz Golaszewski, Krzysztof Kozlowski, Mark Brown,
Krzysztof Kozlowski, Bartosz Golaszewski, Marcel Holtmann,
Conor Dooley, Manivannan Sadhasivam
In-Reply-To: <a75f80bc-d2fa-41f6-91aa-8252fbb415e6@ixit.cz>
On Thu, 26 Mar 2026 at 02:02, David Heidelberg <david@ixit.cz> wrote:
>
> On 19/01/2026 18:08, Dmitry Baryshkov wrote:
>
> [...]
>
> > + wcn3990-pmu {
> > + compatible = "qcom,wcn3990-pmu";
> > +
> > + pinctrl-0 = <&sw_ctrl_default>;
> > + pinctrl-names = "default";
> > +
> > + vddio-supply = <&vreg_s4a_1p8>;
> > + vddxo-supply = <&vreg_l7a_1p8>;
> > + vddrf-supply = <&vreg_l17a_1p3>;
> > + vddch0-supply = <&vreg_l25a_3p3>;
> > + vddch1-supply = <&vreg_l23a_3p3>;
> > +
> > + swctrl-gpios = <&pm8998_gpios 3 GPIO_ACTIVE_HIGH>;
>
> Do you know if the GPIO is common for whole sdm845, or it's only recommended as
> reference design, or nothing?
>
> I did test defaulting to GPIO 3 on Pixel 3 and WiFi works as before, but since
> previous downstream kernel didn't touched GPIO 3 at all, I'm worried about
> toggling unrelated GPIO.
It is an input-only GPIO, but nevertheless, if you are not sure, just skip it.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 01/19] tracepoint: Add trace_call__##name() API
From: Masami Hiramatsu @ 2026-03-26 1:28 UTC (permalink / raw)
To: Vineeth Pillai (Google)
Cc: Steven Rostedt, Peter Zijlstra, Dmitry Ilvokhin, Masami Hiramatsu,
Mathieu Desnoyers, Ingo Molnar, Jens Axboe, io-uring,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexei Starovoitov, Daniel Borkmann, Marcelo Ricardo Leitner,
Xin Long, Jon Maloy, Aaron Conole, Eelco Chaudron, Ilya Maximets,
netdev, bpf, linux-sctp, tipc-discussion, dev, Jiri Pirko,
Oded Gabbay, Koby Elbaz, dri-devel, Rafael J. Wysocki,
Viresh Kumar, Gautham R. Shenoy, Huang Rui, Mario Limonciello,
Len Brown, Srinivas Pandruvada, linux-pm, MyungJoo Ham,
Kyungmin Park, Chanwoo Choi, Christian König, Sumit Semwal,
linaro-mm-sig, Eddie James, Andrew Jeffery, Joel Stanley,
linux-fsi, David Airlie, Simona Vetter, Alex Deucher,
Danilo Krummrich, Matthew Brost, Philipp Stanner, Harry Wentland,
Leo Li, amd-gfx, Jiri Kosina, Benjamin Tissoires, linux-input,
Wolfram Sang, linux-i2c, Mark Brown, Michael Hennerich,
Nuno Sá, linux-spi, James E.J. Bottomley, Martin K. Petersen,
linux-scsi, Chris Mason, David Sterba, linux-btrfs,
Thomas Gleixner, Andrew Morton, SeongJae Park, linux-mm,
Borislav Petkov, Dave Hansen, x86, linux-trace-kernel,
linux-kernel
In-Reply-To: <20260323160052.17528-2-vineeth@bitbyteword.org>
On Mon, 23 Mar 2026 12:00:20 -0400
"Vineeth Pillai (Google)" <vineeth@bitbyteword.org> wrote:
> Add trace_call__##name() as a companion to trace_##name(). When a
> caller already guards a tracepoint with an explicit enabled check:
>
> if (trace_foo_enabled() && cond)
> trace_foo(args);
>
> trace_foo() internally repeats the static_branch_unlikely() test, which
> the compiler cannot fold since static branches are patched binary
> instructions. This results in two static-branch evaluations for every
> guarded call site.
>
> trace_call__##name() calls __do_trace_##name() directly, skipping the
> redundant static-branch re-check. This avoids leaking the internal
> __do_trace_##name() symbol into call sites while still eliminating the
> double evaluation:
>
> if (trace_foo_enabled() && cond)
> trace_invoke_foo(args); /* calls __do_trace_foo() directly */
nit: trace_call_foo() instead of trace_invoke_foo()?
Anyway looks good to me.
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
>
> Three locations are updated:
> - __DECLARE_TRACE: invoke form omits static_branch_unlikely, retains
> the LOCKDEP RCU-watching assertion.
> - __DECLARE_TRACE_SYSCALL: same, plus retains might_fault().
> - !TRACEPOINTS_ENABLED stub: empty no-op so callers compile cleanly
> when tracepoints are compiled out.
>
> Suggested-by: Steven Rostedt <rostedt@goodmis.org>
> Suggested-by: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org>
> Assisted-by: Claude:claude-sonnet-4-6
> ---
> include/linux/tracepoint.h | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
> index 22ca1c8b54f32..ed969705341f1 100644
> --- a/include/linux/tracepoint.h
> +++ b/include/linux/tracepoint.h
> @@ -294,6 +294,10 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> WARN_ONCE(!rcu_is_watching(), \
> "RCU not watching for tracepoint"); \
> } \
> + } \
> + static inline void trace_call__##name(proto) \
> + { \
> + __do_trace_##name(args); \
> }
>
> #define __DECLARE_TRACE_SYSCALL(name, proto, args, data_proto) \
> @@ -313,6 +317,11 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> WARN_ONCE(!rcu_is_watching(), \
> "RCU not watching for tracepoint"); \
> } \
> + } \
> + static inline void trace_call__##name(proto) \
> + { \
> + might_fault(); \
> + __do_trace_##name(args); \
> }
>
> /*
> @@ -398,6 +407,8 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> #define __DECLARE_TRACE_COMMON(name, proto, args, data_proto) \
> static inline void trace_##name(proto) \
> { } \
> + static inline void trace_call__##name(proto) \
> + { } \
> static inline int \
> register_trace_##name(void (*probe)(data_proto), \
> void *data) \
> --
> 2.53.0
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 7/8] arm64: dts: qcom: sdm845-db845c: describe WiFi/BT properly
From: David Heidelberg @ 2026-03-26 0:02 UTC (permalink / raw)
To: Dmitry Baryshkov, Bjorn Andersson, Konrad Dybcio, Vinod Koul
Cc: linux-arm-msm, Liam Girdwood, linux-kernel, devicetree,
Luiz Augusto von Dentz, Rob Herring, linux-bluetooth,
Balakrishna Godavarthi, Matthias Kaehlcke, linux-wireless,
Jeff Johnson, ath10k, linux-pm, Bartosz Golaszewski,
Krzysztof Kozlowski, Mark Brown, Krzysztof Kozlowski,
Bartosz Golaszewski, Marcel Holtmann, Conor Dooley,
Manivannan Sadhasivam
In-Reply-To: <20260119-wcn3990-pwrctl-v3-7-948df19f5ec2@oss.qualcomm.com>
On 19/01/2026 18:08, Dmitry Baryshkov wrote:
[...]
> + wcn3990-pmu {
> + compatible = "qcom,wcn3990-pmu";
> +
> + pinctrl-0 = <&sw_ctrl_default>;
> + pinctrl-names = "default";
> +
> + vddio-supply = <&vreg_s4a_1p8>;
> + vddxo-supply = <&vreg_l7a_1p8>;
> + vddrf-supply = <&vreg_l17a_1p3>;
> + vddch0-supply = <&vreg_l25a_3p3>;
> + vddch1-supply = <&vreg_l23a_3p3>;
> +
> + swctrl-gpios = <&pm8998_gpios 3 GPIO_ACTIVE_HIGH>;
Do you know if the GPIO is common for whole sdm845, or it's only recommended as
reference design, or nothing?
I did test defaulting to GPIO 3 on Pixel 3 and WiFi works as before, but since
previous downstream kernel didn't touched GPIO 3 at all, I'm worried about
toggling unrelated GPIO.
Thanks!
David
> +
> + regulators {
> + vreg_pmu_io: ldo0 {
> + regulator-name = "vreg_pmu_io";
> + };
> +
> + vreg_pmu_xo: ldo1 {
> + regulator-name = "vreg_pmu_xo";
> + };
> +
> + vreg_pmu_rf: ldo2 {
> + regulator-name = "vreg_pmu_rf";
> + };
> +
> + vreg_pmu_ch0: ldo3 {
> + regulator-name = "vreg_pmu_ch0";
> + };
> +
> + vreg_pmu_ch1: ldo4 {
> + regulator-name = "vreg_pmu_ch1";
> + };
--
David Heidelberg
^ permalink raw reply
* [PATCH v9 5/6] power: supply: max77759: add charger driver
From: Amit Sunil Dhamne via B4 Relay @ 2026-03-25 22:22 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
André Draszik, Lee Jones, Greg Kroah-Hartman,
Badhri Jagan Sridharan, Heikki Krogerus, Peter Griffin,
Tudor Ambarus, Alim Akhtar, Mark Brown, Matti Vaittinen,
Andrew Morton
Cc: linux-kernel, linux-pm, devicetree, linux-usb, linux-arm-kernel,
linux-samsung-soc, RD Babiera, Kyle Tso, Amit Sunil Dhamne
In-Reply-To: <20260325-max77759-charger-v9-0-4486dd297adc@google.com>
From: Amit Sunil Dhamne <amitsd@google.com>
Add support for MAX77759 battery charger driver. This is a 4A 1-Cell
Li+/LiPoly dual input switch mode charger. While the device can support
USB & wireless charger inputs, this implementation only supports USB
input. This implementation supports both buck and boost modes.
Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
Reviewed-by: André Draszik <andre.draszik@linaro.org>
---
MAINTAINERS | 6 +
drivers/power/supply/Kconfig | 11 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/max77759_charger.c | 774 ++++++++++++++++++++++++++++++++
4 files changed, 792 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 61bf550fd37c..eefd78c72d82 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15716,6 +15716,12 @@ F: drivers/mfd/max77759.c
F: drivers/nvmem/max77759-nvmem.c
F: include/linux/mfd/max77759.h
+MAXIM MAX77759 BATTERY CHARGER DRIVER
+M: Amit Sunil Dhamne <amitsd@google.com>
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: drivers/power/supply/max77759_charger.c
+
MAXIM MAX77802 PMIC REGULATOR DEVICE DRIVER
M: Javier Martinez Canillas <javier@dowhile0.org>
L: linux-kernel@vger.kernel.org
diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index 92f9f7aae92f..3a2cdb95c98e 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -631,6 +631,17 @@ config CHARGER_MAX77705
help
Say Y to enable support for the Maxim MAX77705 battery charger.
+config CHARGER_MAX77759
+ tristate "Maxim MAX77759 battery charger driver"
+ depends on MFD_MAX77759 && REGULATOR
+ default MFD_MAX77759
+ help
+ Say M or Y here to enable the MAX77759 battery charger. MAX77759
+ charger is a function of the MAX77759 PMIC. This is a dual input
+ switch-mode charger. This driver supports buck and OTG boost modes.
+
+ If built as a module, it will be called max77759_charger.
+
config CHARGER_MAX77976
tristate "Maxim MAX77976 battery charger driver"
depends on I2C
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index 4b79d5abc49a..6af905875ad5 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -128,3 +128,4 @@ obj-$(CONFIG_CHARGER_SURFACE) += surface_charger.o
obj-$(CONFIG_BATTERY_UG3105) += ug3105_battery.o
obj-$(CONFIG_CHARGER_QCOM_SMB2) += qcom_smbx.o
obj-$(CONFIG_FUEL_GAUGE_MM8013) += mm8013.o
+obj-$(CONFIG_CHARGER_MAX77759) += max77759_charger.o
diff --git a/drivers/power/supply/max77759_charger.c b/drivers/power/supply/max77759_charger.c
new file mode 100644
index 000000000000..9bb414599f16
--- /dev/null
+++ b/drivers/power/supply/max77759_charger.c
@@ -0,0 +1,774 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * max77759_charger.c - Battery charger driver for MAX77759 charger device.
+ *
+ * Copyright 2025 Google LLC.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/cleanup.h>
+#include <linux/device.h>
+#include <linux/devm-helpers.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/linear_range.h>
+#include <linux/mfd/max77759.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/power_supply.h>
+#include <linux/regmap.h>
+#include <linux/regulator/driver.h>
+#include <linux/string_choices.h>
+#include <linux/workqueue.h>
+
+/* Default values for Fast Charge Current & Float Voltage */
+#define CHG_CC_DEFAULT_UA 2266770
+#define CHG_FV_DEFAULT_MV 4300
+
+#define MAX_NUM_RETRIES 3
+#define PSY_WORK_RETRY_DELAY_MS 10
+
+#define FOREACH_IRQ(S) \
+ S(AICL), \
+ S(CHGIN), \
+ S(CHG), \
+ S(INLIM), \
+ S(BAT_OILO), \
+ S(CHG_STA_CC), \
+ S(CHG_STA_CV), \
+ S(CHG_STA_TO), \
+ S(CHG_STA_DONE)
+
+#define GENERATE_ENUM(e) e
+#define GENERATE_STRING(s) #s
+
+enum {
+ FOREACH_IRQ(GENERATE_ENUM)
+};
+
+static const char *const chgr_irqs_str[] = {
+ FOREACH_IRQ(GENERATE_STRING)
+};
+
+#define NUM_IRQS ARRAY_SIZE(chgr_irqs_str)
+
+/* Fast charge current limits (in uA) */
+static const struct linear_range chgcc_limit_ranges[] = {
+ LINEAR_RANGE(133330, 0x0, 0x2, 0),
+ LINEAR_RANGE(200000, 0x3, 0x3C, 66670),
+};
+
+/* Charge Termination Voltage Limits (in mV) */
+static const struct linear_range chg_cv_prm_ranges[] = {
+ LINEAR_RANGE(3800, 0x38, 0x39, 100),
+ LINEAR_RANGE(4000, 0x0, 0x32, 10),
+};
+
+/* USB input current limits (in uA) */
+static const struct linear_range chgin_ilim_ranges[] = {
+ LINEAR_RANGE(100000, 0x3, 0x7F, 25000),
+};
+
+struct max77759_charger {
+ struct device *dev;
+ struct regmap *regmap;
+ struct power_supply *psy;
+ struct regulator_dev *chgin_otg_rdev;
+ struct notifier_block nb;
+ struct power_supply *tcpm_psy;
+ struct delayed_work psy_work;
+ struct mutex retry_lock; /* Protects psy_work_retry_cnt */
+ u32 psy_work_retry_cnt;
+ int irqs[NUM_IRQS];
+ struct mutex lock; /* protects the state below */
+ enum max77759_chgr_mode mode;
+};
+
+static inline int unlock_prot_regs(struct max77759_charger *chg, bool unlock)
+{
+ return regmap_update_bits(chg->regmap, MAX77759_CHGR_REG_CHG_CNFG_06,
+ MAX77759_CHGR_REG_CHG_CNFG_06_CHGPROT, unlock
+ ? MAX77759_CHGR_REG_CHG_CNFG_06_CHGPROT : 0);
+}
+
+static int charger_input_valid(struct max77759_charger *chg)
+{
+ u32 val;
+ int ret;
+
+ ret = regmap_read(chg->regmap, MAX77759_CHGR_REG_CHG_INT_OK, &val);
+ if (ret)
+ return ret;
+
+ return (val & MAX77759_CHGR_REG_CHG_INT_CHG) &&
+ (val & MAX77759_CHGR_REG_CHG_INT_CHGIN);
+}
+
+static int get_online(struct max77759_charger *chg)
+{
+ u32 val;
+ int ret;
+
+ ret = charger_input_valid(chg);
+ if (ret <= 0)
+ return ret;
+
+ ret = regmap_read(chg->regmap, MAX77759_CHGR_REG_CHG_DETAILS_02, &val);
+ if (ret)
+ return ret;
+
+ guard(mutex)(&chg->lock);
+
+ return (val & MAX77759_CHGR_REG_CHG_DETAILS_02_CHGIN_STS) &&
+ (chg->mode == MAX77759_CHGR_MODE_CHG_BUCK_ON);
+}
+
+static int get_status(struct max77759_charger *chg)
+{
+ u32 val;
+ int ret;
+
+ ret = regmap_read(chg->regmap, MAX77759_CHGR_REG_CHG_DETAILS_01, &val);
+ if (ret)
+ return ret;
+
+ switch (FIELD_GET(MAX77759_CHGR_REG_CHG_DETAILS_01_CHG_DTLS, val)) {
+ case MAX77759_CHGR_CHG_DTLS_PREQUAL:
+ case MAX77759_CHGR_CHG_DTLS_CC:
+ case MAX77759_CHGR_CHG_DTLS_CV:
+ case MAX77759_CHGR_CHG_DTLS_TO:
+ return POWER_SUPPLY_STATUS_CHARGING;
+ case MAX77759_CHGR_CHG_DTLS_DONE:
+ return POWER_SUPPLY_STATUS_FULL;
+ case MAX77759_CHGR_CHG_DTLS_TIMER_FAULT:
+ case MAX77759_CHGR_CHG_DTLS_SUSP_BATT_THM:
+ case MAX77759_CHGR_CHG_DTLS_OFF_WDOG_TIMER:
+ case MAX77759_CHGR_CHG_DTLS_SUSP_JEITA:
+ return POWER_SUPPLY_STATUS_NOT_CHARGING;
+ case MAX77759_CHGR_CHG_DTLS_OFF:
+ return POWER_SUPPLY_STATUS_DISCHARGING;
+ default:
+ break;
+ }
+
+ return POWER_SUPPLY_STATUS_UNKNOWN;
+}
+
+static int get_charge_type(struct max77759_charger *chg)
+{
+ u32 val;
+ int ret;
+
+ ret = regmap_read(chg->regmap, MAX77759_CHGR_REG_CHG_DETAILS_01, &val);
+ if (ret)
+ return ret;
+
+ switch (FIELD_GET(MAX77759_CHGR_REG_CHG_DETAILS_01_CHG_DTLS, val)) {
+ case MAX77759_CHGR_CHG_DTLS_PREQUAL:
+ return POWER_SUPPLY_CHARGE_TYPE_TRICKLE;
+ case MAX77759_CHGR_CHG_DTLS_CC:
+ case MAX77759_CHGR_CHG_DTLS_CV:
+ return POWER_SUPPLY_CHARGE_TYPE_FAST;
+ case MAX77759_CHGR_CHG_DTLS_TO:
+ return POWER_SUPPLY_CHARGE_TYPE_STANDARD;
+ case MAX77759_CHGR_CHG_DTLS_DONE:
+ case MAX77759_CHGR_CHG_DTLS_TIMER_FAULT:
+ case MAX77759_CHGR_CHG_DTLS_SUSP_BATT_THM:
+ case MAX77759_CHGR_CHG_DTLS_OFF_WDOG_TIMER:
+ case MAX77759_CHGR_CHG_DTLS_SUSP_JEITA:
+ case MAX77759_CHGR_CHG_DTLS_OFF:
+ return POWER_SUPPLY_CHARGE_TYPE_NONE;
+ default:
+ break;
+ }
+
+ return POWER_SUPPLY_CHARGE_TYPE_UNKNOWN;
+}
+
+static int get_chg_health(struct max77759_charger *chg)
+{
+ u32 val;
+ int ret;
+
+ ret = regmap_read(chg->regmap, MAX77759_CHGR_REG_CHG_DETAILS_00, &val);
+ if (ret)
+ return ret;
+
+ switch (FIELD_GET(MAX77759_CHGR_REG_CHG_DETAILS_00_CHGIN_DTLS, val)) {
+ case MAX77759_CHGR_CHGIN_DTLS_VBUS_UNDERVOLTAGE:
+ case MAX77759_CHGR_CHGIN_DTLS_VBUS_MARGINAL_VOLTAGE:
+ return POWER_SUPPLY_HEALTH_UNDERVOLTAGE;
+ case MAX77759_CHGR_CHGIN_DTLS_VBUS_OVERVOLTAGE:
+ return POWER_SUPPLY_HEALTH_OVERVOLTAGE;
+ case MAX77759_CHGR_CHGIN_DTLS_VBUS_VALID:
+ return POWER_SUPPLY_HEALTH_GOOD;
+ default:
+ break;
+ }
+
+ return POWER_SUPPLY_HEALTH_UNKNOWN;
+}
+
+static int get_batt_health(struct max77759_charger *chg)
+{
+ u32 val;
+ int ret;
+
+ ret = regmap_read(chg->regmap, MAX77759_CHGR_REG_CHG_DETAILS_01, &val);
+ if (ret)
+ return ret;
+
+ switch (FIELD_GET(MAX77759_CHGR_REG_CHG_DETAILS_01_BAT_DTLS, val)) {
+ case MAX77759_CHGR_BAT_DTLS_NO_BATT_CHG_SUSP:
+ return POWER_SUPPLY_HEALTH_NO_BATTERY;
+ case MAX77759_CHGR_BAT_DTLS_DEAD_BATTERY:
+ return POWER_SUPPLY_HEALTH_DEAD;
+ case MAX77759_CHGR_BAT_DTLS_BAT_CHG_TIMER_FAULT:
+ return POWER_SUPPLY_HEALTH_SAFETY_TIMER_EXPIRE;
+ case MAX77759_CHGR_BAT_DTLS_BAT_OKAY:
+ case MAX77759_CHGR_BAT_DTLS_BAT_ONLY_MODE:
+ return POWER_SUPPLY_HEALTH_GOOD;
+ case MAX77759_CHGR_BAT_DTLS_BAT_UNDERVOLTAGE:
+ return POWER_SUPPLY_HEALTH_UNDERVOLTAGE;
+ case MAX77759_CHGR_BAT_DTLS_BAT_OVERVOLTAGE:
+ return POWER_SUPPLY_HEALTH_OVERVOLTAGE;
+ case MAX77759_CHGR_BAT_DTLS_BAT_OVERCURRENT:
+ return POWER_SUPPLY_HEALTH_OVERCURRENT;
+ default:
+ break;
+ }
+
+ return POWER_SUPPLY_HEALTH_UNKNOWN;
+}
+
+static int get_health(struct max77759_charger *chg)
+{
+ int ret;
+
+ ret = get_online(chg);
+ if (ret < 0)
+ return ret;
+
+ if (ret) {
+ ret = get_chg_health(chg);
+ if (ret < 0 || ret != POWER_SUPPLY_HEALTH_GOOD)
+ return ret;
+ }
+
+ return get_batt_health(chg);
+}
+
+static int get_fast_charge_current(struct max77759_charger *chg)
+{
+ u32 regval, val;
+ int ret;
+
+ ret = regmap_read(chg->regmap, MAX77759_CHGR_REG_CHG_CNFG_02, ®val);
+ if (ret)
+ return ret;
+
+ regval = FIELD_GET(MAX77759_CHGR_REG_CHG_CNFG_02_CHGCC, regval);
+ ret = linear_range_get_value_array(chgcc_limit_ranges,
+ ARRAY_SIZE(chgcc_limit_ranges),
+ regval, &val);
+ return ret ? ret : val;
+}
+
+static int set_fast_charge_current_limit(struct max77759_charger *chg,
+ u32 cc_max_ua)
+{
+ bool found;
+ u32 regval;
+
+ linear_range_get_selector_high_array(chgcc_limit_ranges,
+ ARRAY_SIZE(chgcc_limit_ranges),
+ cc_max_ua, ®val, &found);
+ if (!found)
+ return -EINVAL;
+
+ return regmap_update_bits(chg->regmap, MAX77759_CHGR_REG_CHG_CNFG_02,
+ MAX77759_CHGR_REG_CHG_CNFG_02_CHGCC, regval);
+}
+
+static int get_float_voltage(struct max77759_charger *chg)
+{
+ u32 regval, val;
+ int ret;
+
+ ret = regmap_read(chg->regmap, MAX77759_CHGR_REG_CHG_CNFG_04, ®val);
+ if (ret)
+ return ret;
+
+ regval = FIELD_GET(MAX77759_CHGR_REG_CHG_CNFG_04_CHG_CV_PRM, regval);
+ ret = linear_range_get_value_array(chg_cv_prm_ranges,
+ ARRAY_SIZE(chg_cv_prm_ranges),
+ regval, &val);
+
+ return ret ? ret : val;
+}
+
+static int set_float_voltage_limit(struct max77759_charger *chg, u32 fv_mv)
+{
+ u32 regval;
+ bool found;
+
+ linear_range_get_selector_high_array(chg_cv_prm_ranges,
+ ARRAY_SIZE(chg_cv_prm_ranges),
+ fv_mv, ®val, &found);
+ if (!found)
+ return -EINVAL;
+
+ return regmap_update_bits(chg->regmap, MAX77759_CHGR_REG_CHG_CNFG_04,
+ MAX77759_CHGR_REG_CHG_CNFG_04_CHG_CV_PRM,
+ regval);
+}
+
+static int get_input_current_limit(struct max77759_charger *chg)
+{
+ u32 regval, val;
+ int ret;
+
+ ret = regmap_read(chg->regmap, MAX77759_CHGR_REG_CHG_CNFG_09, ®val);
+ if (ret)
+ return ret;
+
+ regval = FIELD_GET(MAX77759_CHGR_REG_CHG_CNFG_09_CHGIN_ILIM, regval);
+ regval = umax(regval, chgin_ilim_ranges[0].min_sel);
+
+ ret = linear_range_get_value_array(chgin_ilim_ranges,
+ ARRAY_SIZE(chgin_ilim_ranges),
+ regval, &val);
+
+ return ret ? ret : val;
+}
+
+static int set_input_current_limit(struct max77759_charger *chg, int ilim_ua)
+{
+ u32 regval;
+
+ if (ilim_ua < 0)
+ return -EINVAL;
+
+ linear_range_get_selector_within(chgin_ilim_ranges, ilim_ua, ®val);
+
+ return regmap_update_bits(chg->regmap, MAX77759_CHGR_REG_CHG_CNFG_09,
+ MAX77759_CHGR_REG_CHG_CNFG_09_CHGIN_ILIM,
+ regval);
+}
+
+static const enum power_supply_property max77759_charger_props[] = {
+ POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_CHARGE_TYPE,
+ POWER_SUPPLY_PROP_HEALTH,
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX,
+ POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
+ POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
+};
+
+static int max77759_charger_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *pval)
+{
+ struct max77759_charger *chg = power_supply_get_drvdata(psy);
+ int ret;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_ONLINE:
+ ret = get_online(chg);
+ break;
+ case POWER_SUPPLY_PROP_PRESENT:
+ ret = charger_input_valid(chg);
+ break;
+ case POWER_SUPPLY_PROP_STATUS:
+ ret = get_status(chg);
+ break;
+ case POWER_SUPPLY_PROP_CHARGE_TYPE:
+ ret = get_charge_type(chg);
+ break;
+ case POWER_SUPPLY_PROP_HEALTH:
+ ret = get_health(chg);
+ break;
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX:
+ ret = get_fast_charge_current(chg);
+ break;
+ case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX:
+ ret = get_float_voltage(chg);
+ break;
+ case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+ ret = get_input_current_limit(chg);
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ pval->intval = ret;
+ return ret < 0 ? ret : 0;
+}
+
+static const struct power_supply_desc max77759_charger_desc = {
+ .name = "max77759-charger",
+ .type = POWER_SUPPLY_TYPE_USB,
+ .properties = max77759_charger_props,
+ .num_properties = ARRAY_SIZE(max77759_charger_props),
+ .get_property = max77759_charger_get_property,
+};
+
+static int charger_set_mode(struct max77759_charger *chg,
+ enum max77759_chgr_mode mode)
+{
+ int ret;
+
+ guard(mutex)(&chg->lock);
+
+ if (chg->mode == mode)
+ return 0;
+
+ if ((mode == MAX77759_CHGR_MODE_CHG_BUCK_ON ||
+ mode == MAX77759_CHGR_MODE_OTG_BOOST_ON) &&
+ chg->mode != MAX77759_CHGR_MODE_OFF) {
+ dev_err(chg->dev, "Invalid mode transition from %d to %d\n",
+ chg->mode, mode);
+ return -EINVAL;
+ }
+
+ ret = regmap_update_bits(chg->regmap, MAX77759_CHGR_REG_CHG_CNFG_00,
+ MAX77759_CHGR_REG_CHG_CNFG_00_MODE, mode);
+ if (ret)
+ return ret;
+
+ chg->mode = mode;
+ return 0;
+}
+
+static int enable_chgin_otg(struct regulator_dev *rdev)
+{
+ struct max77759_charger *chg = rdev_get_drvdata(rdev);
+
+ return charger_set_mode(chg, MAX77759_CHGR_MODE_OTG_BOOST_ON);
+}
+
+static int disable_chgin_otg(struct regulator_dev *rdev)
+{
+ struct max77759_charger *chg = rdev_get_drvdata(rdev);
+
+ return charger_set_mode(chg, MAX77759_CHGR_MODE_OFF);
+}
+
+static int chgin_otg_status(struct regulator_dev *rdev)
+{
+ struct max77759_charger *chg = rdev_get_drvdata(rdev);
+
+ guard(mutex)(&chg->lock);
+
+ return chg->mode == MAX77759_CHGR_MODE_OTG_BOOST_ON;
+}
+
+static const struct regulator_ops chgin_otg_reg_ops = {
+ .enable = enable_chgin_otg,
+ .disable = disable_chgin_otg,
+ .is_enabled = chgin_otg_status,
+};
+
+static const struct regulator_desc chgin_otg_reg_desc = {
+ .name = "chgin-otg",
+ .of_match = of_match_ptr("chgin-otg-regulator"),
+ .owner = THIS_MODULE,
+ .ops = &chgin_otg_reg_ops,
+ .fixed_uV = 5000000,
+ .n_voltages = 1,
+};
+
+static irqreturn_t irq_handler(int irq, void *data)
+{
+ struct max77759_charger *chg = data;
+
+ power_supply_changed(chg->psy);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t bat_oilo_irq_handler(int irq, void *data)
+{
+ struct max77759_charger *chg = data;
+
+ dev_warn_ratelimited(chg->dev,
+ "Battery over-current threshold crossed\n");
+
+ return irq_handler(irq, data);
+}
+
+static int max77759_init_irqhandler(struct max77759_charger *chg)
+{
+ struct device *dev = chg->dev;
+ irq_handler_t thread_fn;
+ char *name;
+ int i, ret;
+
+ for (i = 0; i < ARRAY_SIZE(chgr_irqs_str); i++) {
+ ret = platform_get_irq_byname(to_platform_device(dev),
+ chgr_irqs_str[i]);
+ if (ret < 0)
+ return dev_err_probe(dev, ret,
+ "Failed to get irq resource for %s\n",
+ chgr_irqs_str[i]);
+
+ chg->irqs[i] = ret;
+ name = devm_kasprintf(dev, GFP_KERNEL, "%s:%s", dev_name(dev),
+ chgr_irqs_str[i]);
+ if (!name)
+ return dev_err_probe(dev, -ENOMEM,
+ "Failed to allocate space for irqname: %s\n",
+ chgr_irqs_str[i]);
+
+ if (i == BAT_OILO)
+ thread_fn = bat_oilo_irq_handler;
+ else
+ thread_fn = irq_handler;
+
+ ret = devm_request_threaded_irq(dev, chg->irqs[i], NULL,
+ thread_fn, 0, name, chg);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Unable to register irq handler for %s\n",
+ chgr_irqs_str[i]);
+ }
+
+ return 0;
+}
+
+static int max77759_charger_init(struct max77759_charger *chg)
+{
+ struct power_supply_battery_info *info;
+ u32 regval, fast_chg_curr, fv;
+ int ret;
+
+ ret = regmap_read(chg->regmap, MAX77759_CHGR_REG_CHG_CNFG_00, ®val);
+ if (ret)
+ return ret;
+
+ chg->mode = FIELD_GET(MAX77759_CHGR_REG_CHG_CNFG_00_MODE, regval);
+ ret = charger_set_mode(chg, MAX77759_CHGR_MODE_OFF);
+ if (ret)
+ return ret;
+
+ if (power_supply_get_battery_info(chg->psy, &info)) {
+ fv = CHG_FV_DEFAULT_MV;
+ fast_chg_curr = CHG_CC_DEFAULT_UA;
+ } else {
+ fv = info->constant_charge_voltage_max_uv / 1000;
+ fast_chg_curr = info->constant_charge_current_max_ua;
+ }
+
+ ret = set_fast_charge_current_limit(chg, fast_chg_curr);
+ if (ret)
+ return ret;
+
+ ret = set_float_voltage_limit(chg, fv);
+ if (ret)
+ return ret;
+
+ ret = unlock_prot_regs(chg, true);
+ if (ret)
+ return ret;
+
+ /* Disable wireless charging input */
+ ret = regmap_update_bits(chg->regmap, MAX77759_CHGR_REG_CHG_CNFG_12,
+ MAX77759_CHGR_REG_CHG_CNFG_12_WCINSEL, 0);
+ if (ret)
+ goto relock;
+
+ ret = regmap_update_bits(chg->regmap, MAX77759_CHGR_REG_CHG_CNFG_18,
+ MAX77759_CHGR_REG_CHG_CNFG_18_WDTEN, 0);
+ if (ret)
+ goto relock;
+
+ return unlock_prot_regs(chg, false);
+
+relock:
+ (void)unlock_prot_regs(chg, false);
+ return ret;
+}
+
+static void psy_work_item(struct work_struct *work)
+{
+ struct max77759_charger *chg =
+ container_of(work, struct max77759_charger, psy_work.work);
+ union power_supply_propval current_limit, online;
+ int ret;
+
+ ret = power_supply_get_property(chg->tcpm_psy,
+ POWER_SUPPLY_PROP_CURRENT_MAX,
+ ¤t_limit);
+ if (ret) {
+ dev_err(chg->dev,
+ "Failed to get CURRENT_MAX psy property, ret=%d\n",
+ ret);
+ goto err;
+ }
+
+ ret = power_supply_get_property(chg->tcpm_psy, POWER_SUPPLY_PROP_ONLINE,
+ &online);
+ if (ret) {
+ dev_err(chg->dev,
+ "Failed to get ONLINE psy property, ret=%d\n",
+ ret);
+ goto err;
+ }
+
+ if (online.intval && current_limit.intval) {
+ ret = set_input_current_limit(chg, current_limit.intval);
+ if (ret) {
+ dev_err(chg->dev,
+ "Unable to set current limit, ret=%d\n", ret);
+ goto err;
+ }
+
+ charger_set_mode(chg, MAX77759_CHGR_MODE_CHG_BUCK_ON);
+ } else {
+ charger_set_mode(chg, MAX77759_CHGR_MODE_OFF);
+ }
+
+ scoped_guard(mutex, &chg->retry_lock) {
+ if (chg->psy_work_retry_cnt)
+ dev_dbg(chg->dev,
+ "chg psy_work succeeded after %u tries\n",
+ chg->psy_work_retry_cnt);
+ chg->psy_work_retry_cnt = 0;
+ }
+
+ return;
+
+err:
+ charger_set_mode(chg, MAX77759_CHGR_MODE_OFF);
+ scoped_guard(mutex, &chg->retry_lock) {
+ if (chg->psy_work_retry_cnt >= MAX_NUM_RETRIES) {
+ dev_err(chg->dev, "chg psy work failed, giving up\n");
+ return;
+ }
+
+ ++chg->psy_work_retry_cnt;
+ dev_dbg(chg->dev, "Retrying %u/%u chg psy_work\n",
+ chg->psy_work_retry_cnt, MAX_NUM_RETRIES);
+ schedule_delayed_work(&chg->psy_work,
+ msecs_to_jiffies(PSY_WORK_RETRY_DELAY_MS));
+ }
+}
+
+static int psy_changed(struct notifier_block *nb, unsigned long evt, void *data)
+{
+ struct max77759_charger *chg = container_of(nb, struct max77759_charger,
+ nb);
+ static const char *psy_name = "tcpm-source";
+ struct power_supply *psy = data;
+
+ if (!strnstr(psy->desc->name, psy_name, strlen(psy_name)) ||
+ evt != PSY_EVENT_PROP_CHANGED)
+ return NOTIFY_OK;
+
+ chg->tcpm_psy = psy;
+ scoped_guard(mutex, &chg->retry_lock)
+ chg->psy_work_retry_cnt = 0;
+
+ schedule_delayed_work(&chg->psy_work, 0);
+
+ return NOTIFY_OK;
+}
+
+static void max_tcpci_unregister_psy_notifier(void *nb)
+{
+ power_supply_unreg_notifier(nb);
+}
+
+static int max77759_charger_probe(struct platform_device *pdev)
+{
+ struct regulator_config chgin_otg_reg_cfg;
+ struct power_supply_config psy_cfg;
+ struct device *dev = &pdev->dev;
+ struct max77759_charger *chg;
+ int ret;
+
+ device_set_of_node_from_dev(dev, dev->parent);
+ chg = devm_kzalloc(dev, sizeof(*chg), GFP_KERNEL);
+ if (!chg)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, chg);
+ chg->dev = dev;
+ chg->regmap = dev_get_regmap(dev->parent, "charger");
+ if (!chg->regmap)
+ return dev_err_probe(dev, -ENODEV, "Missing regmap\n");
+
+ ret = devm_mutex_init(dev, &chg->lock);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to initialize lock\n");
+
+ ret = devm_mutex_init(dev, &chg->retry_lock);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to initialize retry_lock\n");
+
+ psy_cfg.fwnode = dev_fwnode(dev);
+ psy_cfg.drv_data = chg;
+ chg->psy = devm_power_supply_register(dev, &max77759_charger_desc,
+ &psy_cfg);
+ if (IS_ERR(chg->psy))
+ return dev_err_probe(dev, PTR_ERR(chg->psy),
+ "Failed to register psy\n");
+
+ ret = max77759_charger_init(chg);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to initialize max77759 charger\n");
+
+ chgin_otg_reg_cfg.dev = dev;
+ chgin_otg_reg_cfg.driver_data = chg;
+ chgin_otg_reg_cfg.of_node = dev_of_node(dev);
+ chg->chgin_otg_rdev = devm_regulator_register(dev, &chgin_otg_reg_desc,
+ &chgin_otg_reg_cfg);
+ if (IS_ERR(chg->chgin_otg_rdev))
+ return dev_err_probe(dev, PTR_ERR(chg->chgin_otg_rdev),
+ "Failed to register chgin otg regulator\n");
+
+ ret = devm_delayed_work_autocancel(dev, &chg->psy_work, psy_work_item);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to initialize psy work\n");
+
+ chg->nb.notifier_call = psy_changed;
+ ret = power_supply_reg_notifier(&chg->nb);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Unable to register psy notifier\n");
+
+ ret = devm_add_action_or_reset(dev, max_tcpci_unregister_psy_notifier,
+ &chg->nb);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to add devm action to unregister psy notifier\n");
+
+ return max77759_init_irqhandler(chg);
+}
+
+static const struct platform_device_id max77759_charger_id[] = {
+ { .name = "max77759-charger", },
+ { }
+};
+MODULE_DEVICE_TABLE(platform, max77759_charger_id);
+
+static struct platform_driver max77759_charger_driver = {
+ .driver = {
+ .name = "max77759-charger",
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ },
+ .probe = max77759_charger_probe,
+ .id_table = max77759_charger_id,
+};
+module_platform_driver(max77759_charger_driver);
+
+MODULE_AUTHOR("Amit Sunil Dhamne <amitsd@google.com>");
+MODULE_DESCRIPTION("Maxim MAX77759 charger driver");
+MODULE_LICENSE("GPL");
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [PATCH v9 6/6] usb: typec: tcpm/tcpci_maxim: deprecate WAR for setting charger mode
From: Amit Sunil Dhamne via B4 Relay @ 2026-03-25 22:22 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
André Draszik, Lee Jones, Greg Kroah-Hartman,
Badhri Jagan Sridharan, Heikki Krogerus, Peter Griffin,
Tudor Ambarus, Alim Akhtar, Mark Brown, Matti Vaittinen,
Andrew Morton
Cc: linux-kernel, linux-pm, devicetree, linux-usb, linux-arm-kernel,
linux-samsung-soc, RD Babiera, Kyle Tso, Amit Sunil Dhamne
In-Reply-To: <20260325-max77759-charger-v9-0-4486dd297adc@google.com>
From: Amit Sunil Dhamne <amitsd@google.com>
TCPCI maxim driver directly writes to the charger's register space to
set charger mode depending on the power role. As MAX77759 chg driver
exists, this WAR is not required.
Instead, use a regulator interface to source vbus when typec is in
source power mode. In other power modes, this regulator will be turned
off if active.
Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: André Draszik <andre.draszik@linaro.org>
---
drivers/usb/typec/tcpm/tcpci_maxim.h | 1 +
drivers/usb/typec/tcpm/tcpci_maxim_core.c | 54 +++++++++++++++++++------------
2 files changed, 34 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpci_maxim.h b/drivers/usb/typec/tcpm/tcpci_maxim.h
index b33540a42a95..b314606eb0f6 100644
--- a/drivers/usb/typec/tcpm/tcpci_maxim.h
+++ b/drivers/usb/typec/tcpm/tcpci_maxim.h
@@ -60,6 +60,7 @@ struct max_tcpci_chip {
struct tcpm_port *port;
enum contamiant_state contaminant_state;
bool veto_vconn_swap;
+ struct regulator *vbus_reg;
};
static inline int max_tcpci_read16(struct max_tcpci_chip *chip, unsigned int reg, u16 *val)
diff --git a/drivers/usb/typec/tcpm/tcpci_maxim_core.c b/drivers/usb/typec/tcpm/tcpci_maxim_core.c
index 19f638650796..c0ee7e6959ed 100644
--- a/drivers/usb/typec/tcpm/tcpci_maxim_core.c
+++ b/drivers/usb/typec/tcpm/tcpci_maxim_core.c
@@ -10,6 +10,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
#include <linux/usb/pd.h>
#include <linux/usb/tcpci.h>
#include <linux/usb/tcpm.h>
@@ -35,12 +36,6 @@
*/
#define TCPC_RECEIVE_BUFFER_LEN 32
-#define MAX_BUCK_BOOST_SID 0x69
-#define MAX_BUCK_BOOST_OP 0xb9
-#define MAX_BUCK_BOOST_OFF 0
-#define MAX_BUCK_BOOST_SOURCE 0xa
-#define MAX_BUCK_BOOST_SINK 0x5
-
static const struct regmap_range max_tcpci_tcpci_range[] = {
regmap_reg_range(0x00, 0x95)
};
@@ -202,32 +197,49 @@ static void process_rx(struct max_tcpci_chip *chip, u16 status)
tcpm_pd_receive(chip->port, &msg, rx_type);
}
+static int get_vbus_regulator_handle(struct max_tcpci_chip *chip)
+{
+ if (IS_ERR_OR_NULL(chip->vbus_reg)) {
+ chip->vbus_reg = devm_regulator_get_exclusive(chip->dev,
+ "vbus");
+ if (IS_ERR_OR_NULL(chip->vbus_reg)) {
+ dev_err(chip->dev,
+ "Failed to get vbus regulator handle\n");
+ return -ENODEV;
+ }
+ }
+
+ return 0;
+}
+
static int max_tcpci_set_vbus(struct tcpci *tcpci, struct tcpci_data *tdata, bool source, bool sink)
{
struct max_tcpci_chip *chip = tdata_to_max_tcpci(tdata);
- u8 buffer_source[2] = {MAX_BUCK_BOOST_OP, MAX_BUCK_BOOST_SOURCE};
- u8 buffer_sink[2] = {MAX_BUCK_BOOST_OP, MAX_BUCK_BOOST_SINK};
- u8 buffer_none[2] = {MAX_BUCK_BOOST_OP, MAX_BUCK_BOOST_OFF};
- struct i2c_client *i2c = chip->client;
int ret;
- struct i2c_msg msgs[] = {
- {
- .addr = MAX_BUCK_BOOST_SID,
- .flags = i2c->flags & I2C_M_TEN,
- .len = 2,
- .buf = source ? buffer_source : sink ? buffer_sink : buffer_none,
- },
- };
-
if (source && sink) {
dev_err(chip->dev, "Both source and sink set\n");
return -EINVAL;
}
- ret = i2c_transfer(i2c->adapter, msgs, 1);
+ ret = get_vbus_regulator_handle(chip);
+ if (ret) {
+ /*
+ * Regulator is not necessary for sink only applications. Return
+ * success in cases where sink mode is being modified.
+ */
+ return source ? ret : 1;
+ }
+
+ if (source) {
+ if (!regulator_is_enabled(chip->vbus_reg))
+ ret = regulator_enable(chip->vbus_reg);
+ } else {
+ if (regulator_is_enabled(chip->vbus_reg))
+ ret = regulator_disable(chip->vbus_reg);
+ }
- return ret < 0 ? ret : 1;
+ return ret < 0 ? ret : 1;
}
static void process_power_status(struct max_tcpci_chip *chip)
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [PATCH v9 4/6] lib/linear_ranges: Add linear_range_get_selector_high_array
From: Amit Sunil Dhamne via B4 Relay @ 2026-03-25 22:22 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
André Draszik, Lee Jones, Greg Kroah-Hartman,
Badhri Jagan Sridharan, Heikki Krogerus, Peter Griffin,
Tudor Ambarus, Alim Akhtar, Mark Brown, Matti Vaittinen,
Andrew Morton
Cc: linux-kernel, linux-pm, devicetree, linux-usb, linux-arm-kernel,
linux-samsung-soc, RD Babiera, Kyle Tso, Amit Sunil Dhamne
In-Reply-To: <20260325-max77759-charger-v9-0-4486dd297adc@google.com>
From: Amit Sunil Dhamne <amitsd@google.com>
Add a helper function to find the selector for a given value in a linear
range array. The selector should be such that the value it represents
should be higher or equal to the given value.
Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Acked-by: Mark Brown <broonie@kernel.org>
---
include/linux/linear_range.h | 3 +++
lib/linear_ranges.c | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+)
diff --git a/include/linux/linear_range.h b/include/linux/linear_range.h
index 2e4f4c3539c0..0f3037f1a94f 100644
--- a/include/linux/linear_range.h
+++ b/include/linux/linear_range.h
@@ -57,5 +57,8 @@ void linear_range_get_selector_within(const struct linear_range *r,
int linear_range_get_selector_low_array(const struct linear_range *r,
int ranges, unsigned int val,
unsigned int *selector, bool *found);
+int linear_range_get_selector_high_array(const struct linear_range *r,
+ int ranges, unsigned int val,
+ unsigned int *selector, bool *found);
#endif
diff --git a/lib/linear_ranges.c b/lib/linear_ranges.c
index a1a7dfa881de..c85583678f6b 100644
--- a/lib/linear_ranges.c
+++ b/lib/linear_ranges.c
@@ -241,6 +241,42 @@ int linear_range_get_selector_high(const struct linear_range *r,
}
EXPORT_SYMBOL_GPL(linear_range_get_selector_high);
+/**
+ * linear_range_get_selector_high_array - return linear range selector for value
+ * @r: pointer to array of linear ranges where selector is looked from
+ * @ranges: amount of ranges to scan from array
+ * @val: value for which the selector is searched
+ * @selector: address where found selector value is updated
+ * @found: flag to indicate that given value was in the range
+ *
+ * Scan array of ranges for selector for which range value matches given
+ * input value. Value is matching if it is equal or higher than given value
+ * If given value is found to be in a range scanning is stopped and @found is
+ * set true. If a range with values greater than given value is found
+ * but the range min is being greater than given value, then the range's
+ * lowest selector is updated to @selector and scanning is stopped.
+ *
+ * Return: 0 on success, -EINVAL if range array is invalid or does not contain
+ * range with a value greater or equal to given value
+ */
+int linear_range_get_selector_high_array(const struct linear_range *r,
+ int ranges, unsigned int val,
+ unsigned int *selector, bool *found)
+{
+ int i;
+ int ret;
+
+ for (i = 0; i < ranges; i++) {
+ ret = linear_range_get_selector_high(&r[i], val, selector,
+ found);
+ if (!ret)
+ return 0;
+ }
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(linear_range_get_selector_high_array);
+
/**
* linear_range_get_selector_within - return linear range selector for value
* @r: pointer to linear range where selector is looked from
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [PATCH v9 3/6] mfd: max77759: add register bitmasks and modify irq configs for charger
From: Amit Sunil Dhamne via B4 Relay @ 2026-03-25 22:22 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
André Draszik, Lee Jones, Greg Kroah-Hartman,
Badhri Jagan Sridharan, Heikki Krogerus, Peter Griffin,
Tudor Ambarus, Alim Akhtar, Mark Brown, Matti Vaittinen,
Andrew Morton
Cc: linux-kernel, linux-pm, devicetree, linux-usb, linux-arm-kernel,
linux-samsung-soc, RD Babiera, Kyle Tso, Amit Sunil Dhamne
In-Reply-To: <20260325-max77759-charger-v9-0-4486dd297adc@google.com>
From: Amit Sunil Dhamne <amitsd@google.com>
Add register bitmasks for charger function.
In addition split the charger IRQs further such that each bit represents
an IRQ downstream of charger regmap irq chip. In addition populate the
ack_base to offload irq ack to the regmap irq chip framework.
Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
Reviewed-by: André Draszik <andre.draszik@linaro.org>
---
drivers/mfd/max77759.c | 95 ++++++++++++++++++++++---
include/linux/mfd/max77759.h | 166 +++++++++++++++++++++++++++++++++++--------
2 files changed, 222 insertions(+), 39 deletions(-)
diff --git a/drivers/mfd/max77759.c b/drivers/mfd/max77759.c
index a7efe233ec8c..9fa6027a92c4 100644
--- a/drivers/mfd/max77759.c
+++ b/drivers/mfd/max77759.c
@@ -201,8 +201,24 @@ static const struct regmap_config max77759_regmap_config_charger = {
* - SYSUVLO_INT
* - FSHIP_NOT_RD
* - CHGR_INT: charger
- * - CHG_INT
- * - CHG_INT2
+ * - INT1
+ * - AICL
+ * - CHGIN
+ * - WCIN
+ * - CHG
+ * - BAT
+ * - INLIM
+ * - THM2
+ * - BYP
+ * - INT2
+ * - INSEL
+ * - SYS_UVLO1
+ * - SYS_UVLO2
+ * - BAT_OILO
+ * - CHG_STA_CC
+ * - CHG_STA_CV
+ * - CHG_STA_TO
+ * - CHG_STA_DONE
*/
enum {
MAX77759_INT_MAXQ,
@@ -228,8 +244,22 @@ enum {
};
enum {
- MAX77759_CHARGER_INT_1,
- MAX77759_CHARGER_INT_2,
+ MAX77759_CHGR_INT1_AICL,
+ MAX77759_CHGR_INT1_CHGIN,
+ MAX77759_CHGR_INT1_WCIN,
+ MAX77759_CHGR_INT1_CHG,
+ MAX77759_CHGR_INT1_BAT,
+ MAX77759_CHGR_INT1_INLIM,
+ MAX77759_CHGR_INT1_THM2,
+ MAX77759_CHGR_INT1_BYP,
+ MAX77759_CHGR_INT2_INSEL,
+ MAX77759_CHGR_INT2_SYS_UVLO1,
+ MAX77759_CHGR_INT2_SYS_UVLO2,
+ MAX77759_CHGR_INT2_BAT_OILO,
+ MAX77759_CHGR_INT2_CHG_STA_CC,
+ MAX77759_CHGR_INT2_CHG_STA_CV,
+ MAX77759_CHGR_INT2_CHG_STA_TO,
+ MAX77759_CHGR_INT2_CHG_STA_DONE,
};
static const struct regmap_irq max77759_pmic_irqs[] = {
@@ -256,8 +286,38 @@ static const struct regmap_irq max77759_topsys_irqs[] = {
};
static const struct regmap_irq max77759_chgr_irqs[] = {
- REGMAP_IRQ_REG(MAX77759_CHARGER_INT_1, 0, GENMASK(7, 0)),
- REGMAP_IRQ_REG(MAX77759_CHARGER_INT_2, 1, GENMASK(7, 0)),
+ REGMAP_IRQ_REG(MAX77759_CHGR_INT1_AICL, 0,
+ MAX77759_CHGR_REG_CHG_INT_AICL),
+ REGMAP_IRQ_REG(MAX77759_CHGR_INT1_CHGIN, 0,
+ MAX77759_CHGR_REG_CHG_INT_CHGIN),
+ REGMAP_IRQ_REG(MAX77759_CHGR_INT1_WCIN, 0,
+ MAX77759_CHGR_REG_CHG_INT_WCIN),
+ REGMAP_IRQ_REG(MAX77759_CHGR_INT1_CHG, 0,
+ MAX77759_CHGR_REG_CHG_INT_CHG),
+ REGMAP_IRQ_REG(MAX77759_CHGR_INT1_BAT, 0,
+ MAX77759_CHGR_REG_CHG_INT_BAT),
+ REGMAP_IRQ_REG(MAX77759_CHGR_INT1_INLIM, 0,
+ MAX77759_CHGR_REG_CHG_INT_INLIM),
+ REGMAP_IRQ_REG(MAX77759_CHGR_INT1_THM2, 0,
+ MAX77759_CHGR_REG_CHG_INT_THM2),
+ REGMAP_IRQ_REG(MAX77759_CHGR_INT1_BYP, 0,
+ MAX77759_CHGR_REG_CHG_INT_BYP),
+ REGMAP_IRQ_REG(MAX77759_CHGR_INT2_INSEL, 1,
+ MAX77759_CHGR_REG_CHG_INT2_INSEL),
+ REGMAP_IRQ_REG(MAX77759_CHGR_INT2_SYS_UVLO1, 1,
+ MAX77759_CHGR_REG_CHG_INT2_SYS_UVLO1),
+ REGMAP_IRQ_REG(MAX77759_CHGR_INT2_SYS_UVLO2, 1,
+ MAX77759_CHGR_REG_CHG_INT2_SYS_UVLO2),
+ REGMAP_IRQ_REG(MAX77759_CHGR_INT2_BAT_OILO, 1,
+ MAX77759_CHGR_REG_CHG_INT2_BAT_OILO),
+ REGMAP_IRQ_REG(MAX77759_CHGR_INT2_CHG_STA_CC, 1,
+ MAX77759_CHGR_REG_CHG_INT2_CHG_STA_CC),
+ REGMAP_IRQ_REG(MAX77759_CHGR_INT2_CHG_STA_CV, 1,
+ MAX77759_CHGR_REG_CHG_INT2_CHG_STA_CV),
+ REGMAP_IRQ_REG(MAX77759_CHGR_INT2_CHG_STA_TO, 1,
+ MAX77759_CHGR_REG_CHG_INT2_CHG_STA_TO),
+ REGMAP_IRQ_REG(MAX77759_CHGR_INT2_CHG_STA_DONE, 1,
+ MAX77759_CHGR_REG_CHG_INT2_CHG_STA_DONE),
};
static const struct regmap_irq_chip max77759_pmic_irq_chip = {
@@ -297,11 +357,12 @@ static const struct regmap_irq_chip max77759_topsys_irq_chip = {
.num_irqs = ARRAY_SIZE(max77759_topsys_irqs),
};
-static const struct regmap_irq_chip max77759_chrg_irq_chip = {
+static const struct regmap_irq_chip max77759_chgr_irq_chip = {
.name = "max77759-chgr",
.domain_suffix = "CHGR",
.status_base = MAX77759_CHGR_REG_CHG_INT,
.mask_base = MAX77759_CHGR_REG_CHG_INT_MASK,
+ .ack_base = MAX77759_CHGR_REG_CHG_INT,
.num_regs = 2,
.irqs = max77759_chgr_irqs,
.num_irqs = ARRAY_SIZE(max77759_chgr_irqs),
@@ -325,8 +386,22 @@ static const struct resource max77759_gpio_resources[] = {
};
static const struct resource max77759_charger_resources[] = {
- DEFINE_RES_IRQ_NAMED(MAX77759_CHARGER_INT_1, "INT1"),
- DEFINE_RES_IRQ_NAMED(MAX77759_CHARGER_INT_2, "INT2"),
+ DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_AICL, "AICL"),
+ DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_CHGIN, "CHGIN"),
+ DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_WCIN, "WCIN"),
+ DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_CHG, "CHG"),
+ DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_BAT, "BAT"),
+ DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_INLIM, "INLIM"),
+ DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_THM2, "THM2"),
+ DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_BYP, "BYP"),
+ DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_INSEL, "INSEL"),
+ DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_SYS_UVLO1, "SYS_UVLO1"),
+ DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_SYS_UVLO2, "SYS_UVLO2"),
+ DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_BAT_OILO, "BAT_OILO"),
+ DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_CHG_STA_CC, "CHG_STA_CC"),
+ DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_CHG_STA_CV, "CHG_STA_CV"),
+ DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_CHG_STA_TO, "CHG_STA_TO"),
+ DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_CHG_STA_DONE, "CHG_STA_DONE"),
};
static const struct mfd_cell max77759_cells[] = {
@@ -567,7 +642,7 @@ static int max77759_add_chained_charger(struct i2c_client *client,
max77759->regmap_charger,
MAX77759_INT_CHGR,
parent,
- &max77759_chrg_irq_chip,
+ &max77759_chgr_irq_chip,
&irq_chip_data);
if (ret)
return ret;
diff --git a/include/linux/mfd/max77759.h b/include/linux/mfd/max77759.h
index c6face34e385..ad1aa4c2b779 100644
--- a/include/linux/mfd/max77759.h
+++ b/include/linux/mfd/max77759.h
@@ -59,35 +59,65 @@
#define MAX77759_MAXQ_REG_AP_DATAIN0 0xb1
#define MAX77759_MAXQ_REG_UIC_SWRST 0xe0
-#define MAX77759_CHGR_REG_CHG_INT 0xb0
-#define MAX77759_CHGR_REG_CHG_INT2 0xb1
-#define MAX77759_CHGR_REG_CHG_INT_MASK 0xb2
-#define MAX77759_CHGR_REG_CHG_INT2_MASK 0xb3
-#define MAX77759_CHGR_REG_CHG_INT_OK 0xb4
-#define MAX77759_CHGR_REG_CHG_DETAILS_00 0xb5
-#define MAX77759_CHGR_REG_CHG_DETAILS_01 0xb6
-#define MAX77759_CHGR_REG_CHG_DETAILS_02 0xb7
-#define MAX77759_CHGR_REG_CHG_DETAILS_03 0xb8
-#define MAX77759_CHGR_REG_CHG_CNFG_00 0xb9
-#define MAX77759_CHGR_REG_CHG_CNFG_01 0xba
-#define MAX77759_CHGR_REG_CHG_CNFG_02 0xbb
-#define MAX77759_CHGR_REG_CHG_CNFG_03 0xbc
-#define MAX77759_CHGR_REG_CHG_CNFG_04 0xbd
-#define MAX77759_CHGR_REG_CHG_CNFG_05 0xbe
-#define MAX77759_CHGR_REG_CHG_CNFG_06 0xbf
-#define MAX77759_CHGR_REG_CHG_CNFG_07 0xc0
-#define MAX77759_CHGR_REG_CHG_CNFG_08 0xc1
-#define MAX77759_CHGR_REG_CHG_CNFG_09 0xc2
-#define MAX77759_CHGR_REG_CHG_CNFG_10 0xc3
-#define MAX77759_CHGR_REG_CHG_CNFG_11 0xc4
-#define MAX77759_CHGR_REG_CHG_CNFG_12 0xc5
-#define MAX77759_CHGR_REG_CHG_CNFG_13 0xc6
-#define MAX77759_CHGR_REG_CHG_CNFG_14 0xc7
-#define MAX77759_CHGR_REG_CHG_CNFG_15 0xc8
-#define MAX77759_CHGR_REG_CHG_CNFG_16 0xc9
-#define MAX77759_CHGR_REG_CHG_CNFG_17 0xca
-#define MAX77759_CHGR_REG_CHG_CNFG_18 0xcb
-#define MAX77759_CHGR_REG_CHG_CNFG_19 0xcc
+#define MAX77759_CHGR_REG_CHG_INT 0xb0
+#define MAX77759_CHGR_REG_CHG_INT_AICL BIT(7)
+#define MAX77759_CHGR_REG_CHG_INT_CHGIN BIT(6)
+#define MAX77759_CHGR_REG_CHG_INT_WCIN BIT(5)
+#define MAX77759_CHGR_REG_CHG_INT_CHG BIT(4)
+#define MAX77759_CHGR_REG_CHG_INT_BAT BIT(3)
+#define MAX77759_CHGR_REG_CHG_INT_INLIM BIT(2)
+#define MAX77759_CHGR_REG_CHG_INT_THM2 BIT(1)
+#define MAX77759_CHGR_REG_CHG_INT_BYP BIT(0)
+#define MAX77759_CHGR_REG_CHG_INT2 0xb1
+#define MAX77759_CHGR_REG_CHG_INT2_INSEL BIT(7)
+#define MAX77759_CHGR_REG_CHG_INT2_SYS_UVLO1 BIT(6)
+#define MAX77759_CHGR_REG_CHG_INT2_SYS_UVLO2 BIT(5)
+#define MAX77759_CHGR_REG_CHG_INT2_BAT_OILO BIT(4)
+#define MAX77759_CHGR_REG_CHG_INT2_CHG_STA_CC BIT(3)
+#define MAX77759_CHGR_REG_CHG_INT2_CHG_STA_CV BIT(2)
+#define MAX77759_CHGR_REG_CHG_INT2_CHG_STA_TO BIT(1)
+#define MAX77759_CHGR_REG_CHG_INT2_CHG_STA_DONE BIT(0)
+#define MAX77759_CHGR_REG_CHG_INT_MASK 0xb2
+#define MAX77759_CHGR_REG_CHG_INT2_MASK 0xb3
+#define MAX77759_CHGR_REG_CHG_INT_OK 0xb4
+#define MAX77759_CHGR_REG_CHG_DETAILS_00 0xb5
+#define MAX77759_CHGR_REG_CHG_DETAILS_00_CHGIN_DTLS GENMASK(6, 5)
+#define MAX77759_CHGR_REG_CHG_DETAILS_01 0xb6
+#define MAX77759_CHGR_REG_CHG_DETAILS_01_BAT_DTLS GENMASK(6, 4)
+#define MAX77759_CHGR_REG_CHG_DETAILS_01_CHG_DTLS GENMASK(3, 0)
+#define MAX77759_CHGR_REG_CHG_DETAILS_02 0xb7
+#define MAX77759_CHGR_REG_CHG_DETAILS_02_CHGIN_STS BIT(5)
+#define MAX77759_CHGR_REG_CHG_DETAILS_03 0xb8
+#define MAX77759_CHGR_REG_CHG_CNFG_00 0xb9
+#define MAX77759_CHGR_REG_CHG_CNFG_00_MODE GENMASK(3, 0)
+#define MAX77759_CHGR_REG_CHG_CNFG_01 0xba
+#define MAX77759_CHGR_REG_CHG_CNFG_02 0xbb
+#define MAX77759_CHGR_REG_CHG_CNFG_02_CHGCC GENMASK(5, 0)
+#define MAX77759_CHGR_REG_CHG_CNFG_03 0xbc
+#define MAX77759_CHGR_REG_CHG_CNFG_04 0xbd
+#define MAX77759_CHGR_REG_CHG_CNFG_04_CHG_CV_PRM GENMASK(5, 0)
+#define MAX77759_CHGR_REG_CHG_CNFG_05 0xbe
+#define MAX77759_CHGR_REG_CHG_CNFG_06 0xbf
+#define MAX77759_CHGR_REG_CHG_CNFG_06_CHGPROT GENMASK(3, 2)
+#define MAX77759_CHGR_REG_CHG_CNFG_07 0xc0
+#define MAX77759_CHGR_REG_CHG_CNFG_08 0xc1
+#define MAX77759_CHGR_REG_CHG_CNFG_09 0xc2
+#define MAX77759_CHGR_REG_CHG_CNFG_09_CHGIN_ILIM GENMASK(6, 0)
+#define MAX77759_CHGR_REG_CHG_CNFG_10 0xc3
+#define MAX77759_CHGR_REG_CHG_CNFG_11 0xc4
+#define MAX77759_CHGR_REG_CHG_CNFG_12 0xc5
+/* Wireless Charging input channel select */
+#define MAX77759_CHGR_REG_CHG_CNFG_12_WCINSEL BIT(6)
+/* CHGIN/USB input channel select */
+#define MAX77759_CHGR_REG_CHG_CNFG_12_CHGINSEL BIT(5)
+#define MAX77759_CHGR_REG_CHG_CNFG_13 0xc6
+#define MAX77759_CHGR_REG_CHG_CNFG_14 0xc7
+#define MAX77759_CHGR_REG_CHG_CNFG_15 0xc8
+#define MAX77759_CHGR_REG_CHG_CNFG_16 0xc9
+#define MAX77759_CHGR_REG_CHG_CNFG_17 0xca
+#define MAX77759_CHGR_REG_CHG_CNFG_18 0xcb
+#define MAX77759_CHGR_REG_CHG_CNFG_18_WDTEN BIT(0)
+#define MAX77759_CHGR_REG_CHG_CNFG_19 0xcc
/* MaxQ opcodes for max77759_maxq_command() */
#define MAX77759_MAXQ_OPCODE_MAXLENGTH (MAX77759_MAXQ_REG_AP_DATAOUT32 - \
@@ -101,6 +131,84 @@
#define MAX77759_MAXQ_OPCODE_USER_SPACE_READ 0x81
#define MAX77759_MAXQ_OPCODE_USER_SPACE_WRITE 0x82
+/*
+ * enum max77759_chgr_chgin_dtls_status - Charger Input Status
+ * @MAX77759_CHGR_CHGIN_DTLS_VBUS_UNDERVOLTAGE:
+ * Charger input voltage (Vchgin) < Under Voltage Threshold (Vuvlo)
+ * @MAX77759_CHGR_CHGIN_DTLS_VBUS_MARGINAL_VOLTAGE: Vchgin > Vuvlo and
+ * Vchgin < (Battery Voltage (Vbatt) + system voltage (Vsys))
+ * @MAX77759_CHGR_CHGIN_DTLS_VBUS_OVERVOLTAGE:
+ * Vchgin > Over Voltage threshold (Vovlo)
+ * @MAX77759_CHGR_CHGIN_DTLS_VBUS_VALID:
+ * Vchgin > Vuvlo, Vchgin < Vovlo and Vchgin > (Vsys + Vbatt)
+ */
+enum max77759_chgr_chgin_dtls_status {
+ MAX77759_CHGR_CHGIN_DTLS_VBUS_UNDERVOLTAGE,
+ MAX77759_CHGR_CHGIN_DTLS_VBUS_MARGINAL_VOLTAGE,
+ MAX77759_CHGR_CHGIN_DTLS_VBUS_OVERVOLTAGE,
+ MAX77759_CHGR_CHGIN_DTLS_VBUS_VALID,
+};
+
+/*
+ * enum max77759_chgr_bat_dtls_states - Battery Details
+ * @MAX77759_CHGR_BAT_DTLS_NO_BATT_CHG_SUSP: No battery and the charger suspended
+ * @MAX77759_CHGR_BAT_DTLS_DEAD_BATTERY: Vbatt < Vtrickle
+ * @MAX77759_CHGR_BAT_DTLS_BAT_CHG_TIMER_FAULT: Charging suspended due to timer fault
+ * @MAX77759_CHGR_BAT_DTLS_BAT_OKAY: Battery okay and Vbatt > Min Sys Voltage (Vsysmin)
+ * @MAX77759_CHGR_BAT_DTLS_BAT_UNDERVOLTAGE: Battery is okay. Vtrickle < Vbatt < Vsysmin
+ * @MAX77759_CHGR_BAT_DTLS_BAT_OVERVOLTAGE: Battery voltage > Overvoltage threshold
+ * @MAX77759_CHGR_BAT_DTLS_BAT_OVERCURRENT: Battery current exceeds overcurrent threshold
+ * @MAX77759_CHGR_BAT_DTLS_BAT_ONLY_MODE: Battery only mode and battery level not available
+ */
+enum max77759_chgr_bat_dtls_states {
+ MAX77759_CHGR_BAT_DTLS_NO_BATT_CHG_SUSP,
+ MAX77759_CHGR_BAT_DTLS_DEAD_BATTERY,
+ MAX77759_CHGR_BAT_DTLS_BAT_CHG_TIMER_FAULT,
+ MAX77759_CHGR_BAT_DTLS_BAT_OKAY,
+ MAX77759_CHGR_BAT_DTLS_BAT_UNDERVOLTAGE,
+ MAX77759_CHGR_BAT_DTLS_BAT_OVERVOLTAGE,
+ MAX77759_CHGR_BAT_DTLS_BAT_OVERCURRENT,
+ MAX77759_CHGR_BAT_DTLS_BAT_ONLY_MODE,
+};
+
+/*
+ * enum max77759_chgr_chg_dtls_states - Charger Details
+ * @MAX77759_CHGR_CHG_DTLS_PREQUAL: Charger in prequalification mode
+ * @MAX77759_CHGR_CHG_DTLS_CC: Charger in fast charge const curr mode
+ * @MAX77759_CHGR_CHG_DTLS_CV: Charger in fast charge const voltage mode
+ * @MAX77759_CHGR_CHG_DTLS_TO: Charger is in top off mode
+ * @MAX77759_CHGR_CHG_DTLS_DONE: Charger is done
+ * @MAX77759_CHGR_CHG_DTLS_RSVD_1: Reserved
+ * @MAX77759_CHGR_CHG_DTLS_TIMER_FAULT: Charger is in timer fault mode
+ * @MAX77759_CHGR_CHG_DTLS_SUSP_BATT_THM: Charger is suspended as battery removal detected
+ * @MAX77759_CHGR_CHG_DTLS_OFF: Charger is off. Input invalid or charger disabled
+ * @MAX77759_CHGR_CHG_DTLS_RSVD_2: Reserved
+ * @MAX77759_CHGR_CHG_DTLS_RSVD_3: Reserved
+ * @MAX77759_CHGR_CHG_DTLS_OFF_WDOG_TIMER: Charger is off as watchdog timer expired
+ * @MAX77759_CHGR_CHG_DTLS_SUSP_JEITA: Charger is in JEITA control mode
+ */
+enum max77759_chgr_chg_dtls_states {
+ MAX77759_CHGR_CHG_DTLS_PREQUAL,
+ MAX77759_CHGR_CHG_DTLS_CC,
+ MAX77759_CHGR_CHG_DTLS_CV,
+ MAX77759_CHGR_CHG_DTLS_TO,
+ MAX77759_CHGR_CHG_DTLS_DONE,
+ MAX77759_CHGR_CHG_DTLS_RSVD_1,
+ MAX77759_CHGR_CHG_DTLS_TIMER_FAULT,
+ MAX77759_CHGR_CHG_DTLS_SUSP_BATT_THM,
+ MAX77759_CHGR_CHG_DTLS_OFF,
+ MAX77759_CHGR_CHG_DTLS_RSVD_2,
+ MAX77759_CHGR_CHG_DTLS_RSVD_3,
+ MAX77759_CHGR_CHG_DTLS_OFF_WDOG_TIMER,
+ MAX77759_CHGR_CHG_DTLS_SUSP_JEITA,
+};
+
+enum max77759_chgr_mode {
+ MAX77759_CHGR_MODE_OFF,
+ MAX77759_CHGR_MODE_CHG_BUCK_ON = 0x5,
+ MAX77759_CHGR_MODE_OTG_BOOST_ON = 0xA,
+};
+
/**
* struct max77759 - core max77759 internal data structure
*
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [PATCH v9 0/6] Introduce MAX77759 charger driver
From: Amit Sunil Dhamne via B4 Relay @ 2026-03-25 22:22 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
André Draszik, Lee Jones, Greg Kroah-Hartman,
Badhri Jagan Sridharan, Heikki Krogerus, Peter Griffin,
Tudor Ambarus, Alim Akhtar, Mark Brown, Matti Vaittinen,
Andrew Morton
Cc: linux-kernel, linux-pm, devicetree, linux-usb, linux-arm-kernel,
linux-samsung-soc, RD Babiera, Kyle Tso, Amit Sunil Dhamne,
Krzysztof Kozlowski
MAX77759 PMIC is used in Pixel 6 and 6 Pro (Oriole/Raven) boards.
One of the functions of the MAX77759 PMIC is a battery charger. This
patchset introduces a driver for this function. One of the unique
features of this charger driver is that it works with a USB input where
the Type-C controller is TCPCI based.
Changes to the board files will follow soon once this patchset is reviewed.
For reference to the MAX77759 MFD based patchset (present in upstream):
https://lore.kernel.org/all/20250509-max77759-mfd-v10-0-962ac15ee3ef@linaro.org/
Dependency list for patches (directionality indicates depends on):
[6] -> [5] -> [4] & [3]
The changes need to be applied in order. In this case this probably
would be the USB subsystem as that's the leaf in the dependency list.
Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
---
Changes in v9:
- Fixed nits in mfd/max77759.* (Lee Jones)
- s/max77759_chrg_irq_chip/max77759_chgr_irq_chip
- s/bettery/battery
- Fix alignment in descriptions in kerneldoc comments
- Link to v8 resend: https://lore.kernel.org/r/20260314-max77759-charger-v8-0-226ca5f8c7d2@google.com
- Link to v8: https://lore.kernel.org/all/20260224-max77759-charger-v8-0-eb86bd570e9c@google.com/
Changes in v8:
- Add an newline char at the end of dev_* prints. (André Draszik)
- Return PTR_ERR() instead of -EPROBE_DEFER when devm_power_supply_register()
fails in max77759 charger probe. (André Draszik)
- Link to v7: https://lore.kernel.org/r/20260218-max77759-charger-v7-0-e8d907ce69c5@google.com
Changes in v7:
- Add register relock for protected registers in fail path. (André Draszik)
- Switch to usage of scoped_guard instead of guard. (LKP test bot)
- Link to v6: https://lore.kernel.org/r/20260214-max77759-charger-v6-0-28c09bda74b4@google.com
Changes in v6:
- Linear Range usage (André Draszik):
- Dedicate individual arrays for inlim, chgcc & chg_cv_prm to simplify
code.
- Use numerical values instead of macros for linear_range array init.
- Remove macros defining current and voltage limits due to above.
- Didn't use Reviewed-by tag for Patch 3 due to the above.
- Add new linear_ranges api to leverage it for obtaining selector
values.
- Improve voltage and current getters and setters functions by leveraging
existing and new linear_ranges API.
- IRQ related changes (André Draszik)
- Dedicated names for individual irqs.
- Refactor irq handlers.
- Ratelimit prints
- Retry mechanism (André Draszik):
- Initialize error retry counter to 0 when psy work is scheduled on a
new notifier event.
- Protect the counter using a lock.
- Add appropriate prints.
- Link to v5: https://lore.kernel.org/r/20260203-max77759-charger-v5-0-b50395376a5f@google.com
Changes in v5:
- Use linear_range library instead of reinventing it. (André Draszik)
- This requires a selector_max value so modified mfd/max77759.h to
include it for CHGCC and CHG_ILIM.
- Removed "reviewed-by" for Patch 3 (mfd) due to above
- Use asnyc probe type. (André Draszik)
- Retry mechanism for psy_work. (André Draszik)
- Minor nits (André Draszik):
- Use named initializers for instantiating structs.
- Use static qualifier for `psy_name` variable.
- Refactor if-else ladder to remove else handling if return in prior
"if" loop.
- Remove redundant `unlikely`.
- Link to v4: https://lore.kernel.org/r/20260121-max77759-charger-v4-0-694234c8ded1@google.com
Changes in v4:
- Removed a stray tabspace in mfd/max77759.h. (André Draszik)
- Fixed the following issues in Patch 4/5 (André Draszik):
- Re-order Kconfig entry
- Refactored to not use global variable
- Use of clamp() to clamp values instead of duplicating logic
- Return IRQ_NONE for unhandled irqs or error conditions
- Remove debug messages in irq handler
- Refactor code to use dev_err_probe in *_init_irqhandler()
- Remove unneeded irq_flags
- Check return values of regmap ops
- Other nits like newlines, not using greedy init, using print stmnts
- Link to v3: https://lore.kernel.org/r/20251227-max77759-charger-v3-0-54e664f5ca92@google.com
Changes in v3:
- Had incorrectly folded the charger sub-device with the pmic parent.
Corrected it. (Krzysztof Kozlowski)
- Link to v2: https://lore.kernel.org/r/20251218-max77759-charger-v2-0-2b259980a686@google.com
Changes in v2:
- Fold charger binding in maxim,max77759-charger.yaml to its parent
node. (Krzysztof Kozlowski)
- Renamed regulator supplier & consumer. (Krzysztof Kozlowski & Heikki
Krogerus)
- Removed explicit setting of irq trigger types in max77759 driver.
(André Draszik & Krzysztof Kozlowski)
- Complete bit definitions for IRQ registers. (André Draszik)
- Consolidate all bit definitions for charger IP in mfd/max77759.h.
(André Draszik)
- Modify the handling of charger IRQs such that regmap IRQ chip handles
masking, de-mux and acking of interrupts. (André Draszik)
- Remove unused macro definitions relating to Charger modes in tcpci
maxim driver (André Draszik)
- Add dependency on Regulator class in Kconfig definition for max77759
chg. (Kernel Test Robot)
- Link to v1: https://lore.kernel.org/r/20251123-max77759-charger-v1-0-6b2e4b8f7f54@google.com
---
Amit Sunil Dhamne (6):
dt-bindings: mfd: maxim,max77759: reference power-supply schema and add regulator property
dt-bindings: usb: maxim,max33359: Add supply property for vbus
mfd: max77759: add register bitmasks and modify irq configs for charger
lib/linear_ranges: Add linear_range_get_selector_high_array
power: supply: max77759: add charger driver
usb: typec: tcpm/tcpci_maxim: deprecate WAR for setting charger mode
.../devicetree/bindings/mfd/maxim,max77759.yaml | 16 +-
.../devicetree/bindings/usb/maxim,max33359.yaml | 4 +
MAINTAINERS | 6 +
drivers/mfd/max77759.c | 95 ++-
drivers/power/supply/Kconfig | 11 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/max77759_charger.c | 774 +++++++++++++++++++++
drivers/usb/typec/tcpm/tcpci_maxim.h | 1 +
drivers/usb/typec/tcpm/tcpci_maxim_core.c | 54 +-
include/linux/linear_range.h | 3 +
include/linux/mfd/max77759.h | 166 ++++-
lib/linear_ranges.c | 36 +
12 files changed, 1106 insertions(+), 61 deletions(-)
---
base-commit: ecc64d2dc9ff9738d2a896beb68e02c2feaf9a02
change-id: 20251105-max77759-charger-852b626d661a
Best regards,
--
Amit Sunil Dhamne <amitsd@google.com>
^ permalink raw reply
* [PATCH v9 1/6] dt-bindings: mfd: maxim,max77759: reference power-supply schema and add regulator property
From: Amit Sunil Dhamne via B4 Relay @ 2026-03-25 22:22 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
André Draszik, Lee Jones, Greg Kroah-Hartman,
Badhri Jagan Sridharan, Heikki Krogerus, Peter Griffin,
Tudor Ambarus, Alim Akhtar, Mark Brown, Matti Vaittinen,
Andrew Morton
Cc: linux-kernel, linux-pm, devicetree, linux-usb, linux-arm-kernel,
linux-samsung-soc, RD Babiera, Kyle Tso, Amit Sunil Dhamne,
Krzysztof Kozlowski
In-Reply-To: <20260325-max77759-charger-v9-0-4486dd297adc@google.com>
From: Amit Sunil Dhamne <amitsd@google.com>
Extend the max77759 binding to reference power-supply schema, so that
PMIC node can reference its supplier. Also, add regulator property to
control CHGIN (OTG) voltage.
Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: André Draszik <andre.draszik@linaro.org>
---
.../devicetree/bindings/mfd/maxim,max77759.yaml | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77759.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77759.yaml
index 525de9ab3c2b..42e4a84d5204 100644
--- a/Documentation/devicetree/bindings/mfd/maxim,max77759.yaml
+++ b/Documentation/devicetree/bindings/mfd/maxim,max77759.yaml
@@ -16,6 +16,9 @@ description: |
The MAX77759 includes Battery Charger, Fuel Gauge, temperature sensors, USB
Type-C Port Controller (TCPC), NVMEM, and a GPIO expander.
+allOf:
+ - $ref: /schemas/power/supply/power-supply.yaml#
+
properties:
compatible:
const: maxim,max77759
@@ -37,12 +40,18 @@ properties:
nvmem-0:
$ref: /schemas/nvmem/maxim,max77759-nvmem.yaml
+ chgin-otg-regulator:
+ type: object
+ description: Provides Boost for sourcing VBUS.
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
required:
- compatible
- interrupts
- reg
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
@@ -59,6 +68,11 @@ examples:
interrupt-controller;
#interrupt-cells = <2>;
+ power-supplies = <&maxtcpci>;
+
+ chgin-otg-regulator {
+ regulator-name = "chgin-otg";
+ };
gpio {
compatible = "maxim,max77759-gpio";
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [PATCH v9 2/6] dt-bindings: usb: maxim,max33359: Add supply property for vbus
From: Amit Sunil Dhamne via B4 Relay @ 2026-03-25 22:22 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
André Draszik, Lee Jones, Greg Kroah-Hartman,
Badhri Jagan Sridharan, Heikki Krogerus, Peter Griffin,
Tudor Ambarus, Alim Akhtar, Mark Brown, Matti Vaittinen,
Andrew Morton
Cc: linux-kernel, linux-pm, devicetree, linux-usb, linux-arm-kernel,
linux-samsung-soc, RD Babiera, Kyle Tso, Amit Sunil Dhamne,
Krzysztof Kozlowski
In-Reply-To: <20260325-max77759-charger-v9-0-4486dd297adc@google.com>
From: Amit Sunil Dhamne <amitsd@google.com>
Add a regulator supply property for vbus. This notifies the regulator
provider to source vbus when Type-C operates in Source power mode,
while turn off sourcing vbus when operating in Sink mode or
disconnected.
Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/usb/maxim,max33359.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/maxim,max33359.yaml b/Documentation/devicetree/bindings/usb/maxim,max33359.yaml
index 3de4dc40b791..e652a24902ea 100644
--- a/Documentation/devicetree/bindings/usb/maxim,max33359.yaml
+++ b/Documentation/devicetree/bindings/usb/maxim,max33359.yaml
@@ -32,6 +32,9 @@ properties:
description:
Properties for usb c connector.
+ vbus-supply:
+ description: Regulator to control sourcing Vbus.
+
required:
- compatible
- reg
@@ -53,6 +56,7 @@ examples:
reg = <0x25>;
interrupt-parent = <&gpa8>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+ vbus-supply = <&chgin_otg_reg>;
connector {
compatible = "usb-c-connector";
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* Re: [PATCH v10 00/12] barrier: Add smp_cond_load_{relaxed,acquire}_timeout()
From: David Laight @ 2026-03-25 20:23 UTC (permalink / raw)
To: Catalin Marinas
Cc: Ankur Arora, Andrew Morton, linux-kernel, linux-arch,
linux-arm-kernel, linux-pm, bpf, arnd, will, peterz, mark.rutland,
harisokn, cl, ast, rafael, daniel.lezcano, memxor, zhenglifeng1,
xueshuai, rdunlap, joao.m.martins, boris.ostrovsky, konrad.wilk
In-Reply-To: <acQOMZMk0OMfIgFO@arm.com>
On Wed, 25 Mar 2026 16:32:49 +0000
Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Wed, Mar 25, 2026 at 03:42:10PM +0000, David Laight wrote:
...
> > Looking at the code I think the "sevl; wfe" pair should be higher up.
>
> Yes, I replied to your other message. We could move it higher indeed,
> before the condition check, but I can't get my head around the ordering.
> Can need_resched() check be speculated before the WFE? I need to think
> some more.
I don't think speculation can matter.
Both SEVL and WFE must be serialised against any other instructions
that can change the event flag (as well as each other) otherwise
everything is broken.
Apart from that it doesn't matter, what matters is the instruction
boundary the interrupt happens at.
Actually both SEVL and WFE may be synchronising instructions and very slow.
So you may not want to put them in the fast path where the condition
is true on entry (or even true after a retry).
So the code might have to look like:
for (;;) {
VAL = mem;
if (cond(VAL)) return;
SEVL; WFE;
if (cond(VAL)) return;
v1 = LDX(mem);
if (v1 == VAL)
WFE;
}
Definitely needs a comment that both 'return from exception' and
losing the exclusive access set the event flag.
The asm probably ought to have a full "memory" clobber.
Just in case the compiler gets lively with re-ordering.
David
^ permalink raw reply
* Re: [PATCH] thermal: core: fix use-after-free due to init/cancel delayed_work race
From: Rafael J. Wysocki @ 2026-03-25 20:20 UTC (permalink / raw)
To: Mauricio Faria de Oliveira
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
linux-pm, linux-kernel, kernel-dev, syzbot+3b3852c6031d0f30dfaf
In-Reply-To: <a61c19043dcf579e46f7d4f124013e60@igalia.com>
On Wed, Mar 25, 2026 at 4:13 PM Mauricio Faria de Oliveira
<mfo@igalia.com> wrote:
>
> On 2026-03-25 11:28, Mauricio Faria de Oliveira wrote:
> > On 2026-03-25 11:17, Mauricio Faria de Oliveira wrote:
> >> Thanks for looking into this.
> >>
> >> On 2026-03-25 09:47, Rafael J. Wysocki wrote:
> >>> I can see the one between thermal_zone_device_unregister() and
> >>> thermal_zone_device_resume(), but that can be addressed by adding a
> >>> TZ_STATE_FLAG_EXIT check to the latter AFAICS.
> >>
> >
> > Please disregard this paragraph; I incorrectly read/wrote _resume()
> > as thermal_zone_pm_complete() discussed above. The rest should be
> > right. I'll review this and get back shortly.
> >
> >> In the example describe above and detailed below, apparently that
> >> is not sufficient, if I'm not missing anything. See, if _resume()
> >> is reached with thermal_list_lock held, thermal_zone_device_exit()
> >> is waiting for thermal_list_lock before setting TZ_STATE_FLAG_EXIT,
> >> thus a check for it in _resume() would find it clear yet.
>
> Ok, similarly:
>
> Say, thermal_pm_notify() -> thermal_pm_notify_complete() ->
> thermal_zone_pm_complete()
> run before thermal_zone_device_unregister() is called;
> thermal_zone_device_resume()
> starts, and by now thermal_zone_device_unregister() is called.
>
> If thermal_zone_device_resume() wins the race over thermal_zone_exit()
> for guard(thermal_zone(tz) (tz->lock), it sees TZ_STATE_FLAG_EXIT clear;
> note its callees (eg, thermal_zone_device_init()) run with tz->lock
> held,
> so they see it clear as well.
>
> So, thermal_zone_device_init() calls INIT_DELAYED_WORK(), everything
> returns, tz->lock is released and the thermal_zone_device_unregister()
> -> thermal_zone_exit() path can continue to run.
>
> Only now thermal_zone_exit() sets TZ_STATE_FLAG_EXIT (too late),
> returns.
> cancel_delayed_work_sync() does not wait for
> thermal_zone_device_resume()
> due to INIT_DELAYED_WORK() in thermal_zone_device_init(); and kfree(tz).
Wait.
I'm not sure why this matters because the zone lock is dropped at the
end of thermal_zone_device_resume() at which point it has done
everything it had to do. Then, the cancel_delayed_work_sync() in
thermal_zone_device_unregister() should properly wait for the work
item queued up by thermal_zone_device_resume().
> Then, thermal_zone_device_resume() accesses tz and hits use-after-free.
Say thermal_zone_device_resume() has lost the race for tz->lock to
thermal_zone_exit() though. It runs after the latter and
reinitializes the delayed work. Now, thermal_zone_device_unregister()
continues and cancel_delayed_work_sync() doesn't see the
thermal_zone_device_resume() running in parallel with it any more, so
it doesn't wait and if thermal_zone_device_unregister() continues to
run, it may free tz prematurely.
I claim that this can be prevented by adding a tz->state check to
thermal_zone_device_resume() before the reinitialization of the
delayed work. Namely, if it loses the race tz->lock to
thermal_zone_exit(), the new check will trigger and the delayed work
will not be reinitialized, so the cancel_delayed_work_sync() will wait
for it to complete.
^ permalink raw reply
* Re: [PATCH v6 13/27] PCI: of: Remove fwnode_dev_initialized() call for a PCI root bridge node
From: Bjorn Helgaas @ 2026-03-25 20:20 UTC (permalink / raw)
To: Herve Codina
Cc: Andrew Lunn, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Kalle Niemi, Matti Vaittinen,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Michael Turquette, Stephen Boyd, Andi Shyti, Wolfram Sang,
Peter Rosin, Arnd Bergmann, Saravana Kannan, Bjorn Helgaas,
Charles Keepax, Richard Fitzgerald, David Rhodes, Linus Walleij,
Ulf Hansson, Mark Brown, Len Brown, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Davidlohr Bueso,
Jonathan Cameron, Dave Jiang, Alison Schofield, Vishal Verma,
Ira Weiny, Dan Williams, Shawn Guo, Wolfram Sang, linux-kernel,
driver-core, imx, linux-arm-kernel, linux-clk, linux-i2c,
devicetree, linux-pci, linux-sound, patches, linux-gpio, linux-pm,
linux-spi, linux-acpi, linux-cxl, Allan Nielsen, Horatiu Vultur,
Steen Hegelund, Luca Ceresoli, Thomas Petazzoni
In-Reply-To: <20260325143555.451852-14-herve.codina@bootlin.com>
On Wed, Mar 25, 2026 at 03:35:40PM +0100, Herve Codina wrote:
> During the instantiation of devices described by a device-tree overlay
> applied on a PCI device, devlink displays the following kind of debug
> messages instead of creating the expected links:
> 'Not linking xxxx - might never become dev'
>
> Without those expected links, the device removal order cannot be
> correct.
>
> Those debug traces are printed by fw_devlink_create_devlink(). In our
> use case, they are all printed because the supplier of the link has at
> least one of its ancestor with its fwnode flag FWNODE_FLAG_INITIALIZED
> set.
>
> The culprit ancestor is the PCI root bridge.
>
> The fwnode related to the PCI root bridge is created dynamically by the
> of_pci_make_host_bridge_node() function. During this creation
> fwnode_dev_initialized() is called which set the FWNODE_FLAG_INITIALIZED
> flag.
>
> Calling fwnode_dev_initialized() tells devlink that the device related
> to this node is handled out of the driver core. This is not correct in
> our case. Indeed the device related to this firmware node is handled
> using driver core mechanisms and is fully compliant devlink
> expectations.
>
> Simply remove the fwnode_dev_initialized() call. With that done, the
> devlink debug messages are no more displayed and links that were missing
> are correctly created.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
I would ordinarily make sure the person who added
fwnode_dev_initialized() here was ok with its removal, but it looks
like you added this with 1f340724419e ("PCI: of: Create device tree
PCI host bridge node"), so I assume you're ok with removing it :)
I suppose there could be a "Fixes: 1f340724419e" tag, but maybe
there's no need to backport this anywhere?
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> drivers/pci/of.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index b694fcda16b1..0993257fe025 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -811,7 +811,6 @@ void of_pci_make_host_bridge_node(struct pci_host_bridge *bridge)
> */
> of_node_set_flag(np, OF_POPULATED);
> fw_devlink_set_device(&np->fwnode, &bridge->dev);
> - fwnode_dev_initialized(&np->fwnode, true);
>
> ret = of_changeset_apply(cset);
> if (ret)
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v6 12/27] PCI: of: Set fwnode device of newly created PCI device nodes
From: Bjorn Helgaas @ 2026-03-25 20:13 UTC (permalink / raw)
To: Herve Codina
Cc: Andrew Lunn, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Kalle Niemi, Matti Vaittinen,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Michael Turquette, Stephen Boyd, Andi Shyti, Wolfram Sang,
Peter Rosin, Arnd Bergmann, Saravana Kannan, Bjorn Helgaas,
Charles Keepax, Richard Fitzgerald, David Rhodes, Linus Walleij,
Ulf Hansson, Mark Brown, Len Brown, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Davidlohr Bueso,
Jonathan Cameron, Dave Jiang, Alison Schofield, Vishal Verma,
Ira Weiny, Dan Williams, Shawn Guo, Wolfram Sang, linux-kernel,
driver-core, imx, linux-arm-kernel, linux-clk, linux-i2c,
devicetree, linux-pci, linux-sound, patches, linux-gpio, linux-pm,
linux-spi, linux-acpi, linux-cxl, Allan Nielsen, Horatiu Vultur,
Steen Hegelund, Luca Ceresoli, Thomas Petazzoni
In-Reply-To: <20260325143555.451852-13-herve.codina@bootlin.com>
On Wed, Mar 25, 2026 at 03:35:39PM +0100, Herve Codina wrote:
> Device-tree node can be created when CONFIG_PCI_DYNAMIC_OF_NODES. Those
> node are created and filled based on PCI core information but the
> fwnode device field is not set.
s/Those node are/Those nodes are/
> When later an overlay is applied, this confuses fw_devlink. Indeed,
> without any device attached to the node, fw_devlink considers that this
> node will never become a device. When this node is pointed as a
> supplier, devlink looks at its ancestors in order to find a node with a
> device that could be used as the supplier.
>
> In the PCI use case, this leads to links that wrongly use the PCI root
> bridge device as the supplier instead of the expected PCI device.
>
> Setting the fwnode device to the device of the PCI device allows devlink
> to use this device as a supplier and so, correct links are created.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> drivers/pci/of.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index 5fb7f501fd35..b694fcda16b1 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -709,6 +709,13 @@ void of_pci_make_dev_node(struct pci_dev *pdev)
> if (ret)
> goto out_free_node;
>
> + /*
> + * Set the fwnode device in order to have fw_devlink creating links
> + * pointing to this PCI device instead of walking up to the PCI host
> + * bridge.
> + */
> + fw_devlink_set_device(&np->fwnode, &pdev->dev);
> +
> ret = of_changeset_apply(cset);
> if (ret)
> goto out_free_node;
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v6 11/27] PCI: of: Use fw_devlink_set_device()
From: Bjorn Helgaas @ 2026-03-25 20:10 UTC (permalink / raw)
To: Herve Codina
Cc: Andrew Lunn, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Kalle Niemi, Matti Vaittinen,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Michael Turquette, Stephen Boyd, Andi Shyti, Wolfram Sang,
Peter Rosin, Arnd Bergmann, Saravana Kannan, Bjorn Helgaas,
Charles Keepax, Richard Fitzgerald, David Rhodes, Linus Walleij,
Ulf Hansson, Mark Brown, Len Brown, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Davidlohr Bueso,
Jonathan Cameron, Dave Jiang, Alison Schofield, Vishal Verma,
Ira Weiny, Dan Williams, Shawn Guo, Wolfram Sang, linux-kernel,
driver-core, imx, linux-arm-kernel, linux-clk, linux-i2c,
devicetree, linux-pci, linux-sound, patches, linux-gpio, linux-pm,
linux-spi, linux-acpi, linux-cxl, Allan Nielsen, Horatiu Vultur,
Steen Hegelund, Luca Ceresoli, Thomas Petazzoni
In-Reply-To: <20260325143555.451852-12-herve.codina@bootlin.com>
On Wed, Mar 25, 2026 at 03:35:38PM +0100, Herve Codina wrote:
> The code set directly fwnode.dev field.
>
> Use the dedicated fw_devlink_set_device() helper to perform this
> operation.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> drivers/pci/of.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index 9f8eb5df279e..5fb7f501fd35 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -803,7 +803,7 @@ void of_pci_make_host_bridge_node(struct pci_host_bridge *bridge)
> * bus. Avoid any new device creation.
> */
> of_node_set_flag(np, OF_POPULATED);
> - np->fwnode.dev = &bridge->dev;
> + fw_devlink_set_device(&np->fwnode, &bridge->dev);
> fwnode_dev_initialized(&np->fwnode, true);
>
> ret = of_changeset_apply(cset);
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH RESEND v8 3/6] mfd: max77759: add register bitmasks and modify irq configs for charger
From: Amit Sunil Dhamne @ 2026-03-25 20:06 UTC (permalink / raw)
To: Lee Jones, Amit Sunil Dhamne via B4 Relay
Cc: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
André Draszik, Greg Kroah-Hartman, Badhri Jagan Sridharan,
Heikki Krogerus, Peter Griffin, Tudor Ambarus, Alim Akhtar,
Mark Brown, Matti Vaittinen, Andrew Morton, linux-kernel,
linux-pm, devicetree, linux-usb, linux-arm-kernel,
linux-samsung-soc, RD Babiera, Kyle Tso
In-Reply-To: <20260325151004.GD1141718@google.com>
Hi Lee,
Thanks for the review!
On 3/25/26 8:10 AM, Lee Jones wrote:
> On Sat, 14 Mar 2026, Amit Sunil Dhamne via B4 Relay wrote:
>
>> From: Amit Sunil Dhamne <amitsd@google.com>
>>
>> Add register bitmasks for charger function.
>>
>> In addition split the charger IRQs further such that each bit represents
>> an IRQ downstream of charger regmap irq chip. In addition populate the
>> ack_base to offload irq ack to the regmap irq chip framework.
>>
>> Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
>> Reviewed-by: André Draszik <andre.draszik@linaro.org>
>> ---
>> drivers/mfd/max77759.c | 91 ++++++++++++++++++++--
>> include/linux/mfd/max77759.h | 176 ++++++++++++++++++++++++++++++++++++-------
>> 2 files changed, 230 insertions(+), 37 deletions(-)
>>
>> diff --git a/drivers/mfd/max77759.c b/drivers/mfd/max77759.c
>> index a7efe233ec8c..288746f675b8 100644
>> --- a/drivers/mfd/max77759.c
>> +++ b/drivers/mfd/max77759.c
>> @@ -201,8 +201,24 @@ static const struct regmap_config max77759_regmap_config_charger = {
>> * - SYSUVLO_INT
>> * - FSHIP_NOT_RD
>> * - CHGR_INT: charger
>> - * - CHG_INT
>> - * - CHG_INT2
>> + * - INT1
>> + * - AICL
>> + * - CHGIN
>> + * - WCIN
>> + * - CHG
>> + * - BAT
>> + * - INLIM
>> + * - THM2
>> + * - BYP
>> + * - INT2
>> + * - INSEL
>> + * - SYS_UVLO1
>> + * - SYS_UVLO2
>> + * - BAT_OILO
>> + * - CHG_STA_CC
>> + * - CHG_STA_CV
>> + * - CHG_STA_TO
>> + * - CHG_STA_DONE
>> */
>> enum {
>> MAX77759_INT_MAXQ,
>> @@ -256,8 +286,38 @@ static const struct regmap_irq max77759_topsys_irqs[] = {
>> };
>>
>> static const struct regmap_irq max77759_chgr_irqs[] = {
>> - REGMAP_IRQ_REG(MAX77759_CHARGER_INT_1, 0, GENMASK(7, 0)),
>> - REGMAP_IRQ_REG(MAX77759_CHARGER_INT_2, 1, GENMASK(7, 0)),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_AICL, 0,
>> + MAX77759_CHGR_REG_CHG_INT_AICL),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_CHGIN, 0,
>> + MAX77759_CHGR_REG_CHG_INT_CHGIN),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_WCIN, 0,
>> + MAX77759_CHGR_REG_CHG_INT_WCIN),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_CHG, 0,
>> + MAX77759_CHGR_REG_CHG_INT_CHG),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_BAT, 0,
>> + MAX77759_CHGR_REG_CHG_INT_BAT),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_INLIM, 0,
>> + MAX77759_CHGR_REG_CHG_INT_INLIM),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_THM2, 0,
>> + MAX77759_CHGR_REG_CHG_INT_THM2),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT1_BYP, 0,
>> + MAX77759_CHGR_REG_CHG_INT_BYP),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_INSEL, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_INSEL),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_SYS_UVLO1, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_SYS_UVLO1),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_SYS_UVLO2, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_SYS_UVLO2),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_BAT_OILO, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_BAT_OILO),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_CHG_STA_CC, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_CHG_STA_CC),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_CHG_STA_CV, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_CHG_STA_CV),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_CHG_STA_TO, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_CHG_STA_TO),
>> + REGMAP_IRQ_REG(MAX77759_CHGR_INT2_CHG_STA_DONE, 1,
>> + MAX77759_CHGR_REG_CHG_INT2_CHG_STA_DONE),
>> };
>>
>> static const struct regmap_irq_chip max77759_pmic_irq_chip = {
>> @@ -302,6 +362,7 @@ static const struct regmap_irq_chip max77759_chrg_irq_chip = {
> Minor nit: The new code in this patch consistently uses "chgr" as the prefix
> for charger-related names. To improve consistency, how about we rename this
> struct to `max77759_chgr_irq_chip`?
Sure I can rename it for the goal of maintaining consistency.
>
>> .domain_suffix = "CHGR",
>> .status_base = MAX77759_CHGR_REG_CHG_INT,
>> .mask_base = MAX77759_CHGR_REG_CHG_INT_MASK,
>> + .ack_base = MAX77759_CHGR_REG_CHG_INT,
>> .num_regs = 2,
>> .irqs = max77759_chgr_irqs,
>> .num_irqs = ARRAY_SIZE(max77759_chgr_irqs),
>> @@ -325,8 +386,22 @@ static const struct resource max77759_gpio_resources[] = {
>> };
>>
>> static const struct resource max77759_charger_resources[] = {
>> - DEFINE_RES_IRQ_NAMED(MAX77759_CHARGER_INT_1, "INT1"),
>> - DEFINE_RES_IRQ_NAMED(MAX77759_CHARGER_INT_2, "INT2"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_AICL, "AICL"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_CHGIN, "CHGIN"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_WCIN, "WCIN"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_CHG, "CHG"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_BAT, "BAT"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_INLIM, "INLIM"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_THM2, "THM2"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT1_BYP, "BYP"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_INSEL, "INSEL"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_SYS_UVLO1, "SYS_UVLO1"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_SYS_UVLO2, "SYS_UVLO2"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_BAT_OILO, "BAT_OILO"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_CHG_STA_CC, "CHG_STA_CC"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_CHG_STA_CV, "CHG_STA_CV"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_CHG_STA_TO, "CHG_STA_TO"),
>> + DEFINE_RES_IRQ_NAMED(MAX77759_CHGR_INT2_CHG_STA_DONE, "CHG_STA_DONE"),
>> };
>>
>> static const struct mfd_cell max77759_cells[] = {
>> diff --git a/include/linux/mfd/max77759.h b/include/linux/mfd/max77759.h
>> index c6face34e385..fd5aea21ab2e 100644
>> --- a/include/linux/mfd/max77759.h
>> +++ b/include/linux/mfd/max77759.h
>> @@ -59,35 +59,65 @@
>> #define MAX77759_MAXQ_REG_AP_DATAIN0 0xb1
>> #define MAX77759_MAXQ_REG_UIC_SWRST 0xe0
>>
>> -#define MAX77759_CHGR_REG_CHG_INT 0xb0
>> -#define MAX77759_CHGR_REG_CHG_INT2 0xb1
>> -#define MAX77759_CHGR_REG_CHG_INT_MASK 0xb2
>> -#define MAX77759_CHGR_REG_CHG_INT2_MASK 0xb3
>> -#define MAX77759_CHGR_REG_CHG_INT_OK 0xb4
>> -#define MAX77759_CHGR_REG_CHG_DETAILS_00 0xb5
>> -#define MAX77759_CHGR_REG_CHG_DETAILS_01 0xb6
>> -#define MAX77759_CHGR_REG_CHG_DETAILS_02 0xb7
>> -#define MAX77759_CHGR_REG_CHG_DETAILS_03 0xb8
>> -#define MAX77759_CHGR_REG_CHG_CNFG_00 0xb9
>> -#define MAX77759_CHGR_REG_CHG_CNFG_01 0xba
>> -#define MAX77759_CHGR_REG_CHG_CNFG_02 0xbb
>> -#define MAX77759_CHGR_REG_CHG_CNFG_03 0xbc
>> -#define MAX77759_CHGR_REG_CHG_CNFG_04 0xbd
>> -#define MAX77759_CHGR_REG_CHG_CNFG_05 0xbe
>> -#define MAX77759_CHGR_REG_CHG_CNFG_06 0xbf
>> -#define MAX77759_CHGR_REG_CHG_CNFG_07 0xc0
>> -#define MAX77759_CHGR_REG_CHG_CNFG_08 0xc1
>> -#define MAX77759_CHGR_REG_CHG_CNFG_09 0xc2
>> -#define MAX77759_CHGR_REG_CHG_CNFG_10 0xc3
>> -#define MAX77759_CHGR_REG_CHG_CNFG_11 0xc4
>> -#define MAX77759_CHGR_REG_CHG_CNFG_12 0xc5
>> -#define MAX77759_CHGR_REG_CHG_CNFG_13 0xc6
>> -#define MAX77759_CHGR_REG_CHG_CNFG_14 0xc7
>> -#define MAX77759_CHGR_REG_CHG_CNFG_15 0xc8
>> -#define MAX77759_CHGR_REG_CHG_CNFG_16 0xc9
>> -#define MAX77759_CHGR_REG_CHG_CNFG_17 0xca
>> -#define MAX77759_CHGR_REG_CHG_CNFG_18 0xcb
>> -#define MAX77759_CHGR_REG_CHG_CNFG_19 0xcc
>> +#define MAX77759_CHGR_REG_CHG_INT 0xb0
>> +#define MAX77759_CHGR_REG_CHG_INT_AICL BIT(7)
>> +#define MAX77759_CHGR_REG_CHG_INT_CHGIN BIT(6)
>> +#define MAX77759_CHGR_REG_CHG_INT_WCIN BIT(5)
>> +#define MAX77759_CHGR_REG_CHG_INT_CHG BIT(4)
>> +#define MAX77759_CHGR_REG_CHG_INT_BAT BIT(3)
>> +#define MAX77759_CHGR_REG_CHG_INT_INLIM BIT(2)
>> +#define MAX77759_CHGR_REG_CHG_INT_THM2 BIT(1)
>> +#define MAX77759_CHGR_REG_CHG_INT_BYP BIT(0)
>> +#define MAX77759_CHGR_REG_CHG_INT2 0xb1
>> +#define MAX77759_CHGR_REG_CHG_INT2_INSEL BIT(7)
>> +#define MAX77759_CHGR_REG_CHG_INT2_SYS_UVLO1 BIT(6)
>> +#define MAX77759_CHGR_REG_CHG_INT2_SYS_UVLO2 BIT(5)
>> +#define MAX77759_CHGR_REG_CHG_INT2_BAT_OILO BIT(4)
>> +#define MAX77759_CHGR_REG_CHG_INT2_CHG_STA_CC BIT(3)
>> +#define MAX77759_CHGR_REG_CHG_INT2_CHG_STA_CV BIT(2)
>> +#define MAX77759_CHGR_REG_CHG_INT2_CHG_STA_TO BIT(1)
>> +#define MAX77759_CHGR_REG_CHG_INT2_CHG_STA_DONE BIT(0)
>> +#define MAX77759_CHGR_REG_CHG_INT_MASK 0xb2
>> +#define MAX77759_CHGR_REG_CHG_INT2_MASK 0xb3
>> +#define MAX77759_CHGR_REG_CHG_INT_OK 0xb4
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_00 0xb5
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_00_CHGIN_DTLS GENMASK(6, 5)
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_01 0xb6
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_01_BAT_DTLS GENMASK(6, 4)
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_01_CHG_DTLS GENMASK(3, 0)
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_02 0xb7
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_02_CHGIN_STS BIT(5)
>> +#define MAX77759_CHGR_REG_CHG_DETAILS_03 0xb8
>> +#define MAX77759_CHGR_REG_CHG_CNFG_00 0xb9
>> +#define MAX77759_CHGR_REG_CHG_CNFG_00_MODE GENMASK(3, 0)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_01 0xba
>> +#define MAX77759_CHGR_REG_CHG_CNFG_02 0xbb
>> +#define MAX77759_CHGR_REG_CHG_CNFG_02_CHGCC GENMASK(5, 0)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_03 0xbc
>> +#define MAX77759_CHGR_REG_CHG_CNFG_04 0xbd
>> +#define MAX77759_CHGR_REG_CHG_CNFG_04_CHG_CV_PRM GENMASK(5, 0)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_05 0xbe
>> +#define MAX77759_CHGR_REG_CHG_CNFG_06 0xbf
>> +#define MAX77759_CHGR_REG_CHG_CNFG_06_CHGPROT GENMASK(3, 2)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_07 0xc0
>> +#define MAX77759_CHGR_REG_CHG_CNFG_08 0xc1
>> +#define MAX77759_CHGR_REG_CHG_CNFG_09 0xc2
>> +#define MAX77759_CHGR_REG_CHG_CNFG_09_CHGIN_ILIM GENMASK(6, 0)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_10 0xc3
>> +#define MAX77759_CHGR_REG_CHG_CNFG_11 0xc4
>> +#define MAX77759_CHGR_REG_CHG_CNFG_12 0xc5
>> +/* Wireless Charging input channel select */
>> +#define MAX77759_CHGR_REG_CHG_CNFG_12_WCINSEL BIT(6)
>> +/* CHGIN/USB input channel select */
>> +#define MAX77759_CHGR_REG_CHG_CNFG_12_CHGINSEL BIT(5)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_13 0xc6
>> +#define MAX77759_CHGR_REG_CHG_CNFG_14 0xc7
>> +#define MAX77759_CHGR_REG_CHG_CNFG_15 0xc8
>> +#define MAX77759_CHGR_REG_CHG_CNFG_16 0xc9
>> +#define MAX77759_CHGR_REG_CHG_CNFG_17 0xca
>> +#define MAX77759_CHGR_REG_CHG_CNFG_18 0xcb
>> +#define MAX77759_CHGR_REG_CHG_CNFG_18_WDTEN BIT(0)
>> +#define MAX77759_CHGR_REG_CHG_CNFG_19 0xcc
>>
>> /* MaxQ opcodes for max77759_maxq_command() */
>> #define MAX77759_MAXQ_OPCODE_MAXLENGTH (MAX77759_MAXQ_REG_AP_DATAOUT32 - \
>> @@ -101,6 +131,94 @@
>> #define MAX77759_MAXQ_OPCODE_USER_SPACE_READ 0x81
>> #define MAX77759_MAXQ_OPCODE_USER_SPACE_WRITE 0x82
>>
>> +/*
>> + * Charger Input Status
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_UNDERVOLTAGE:
>> + * Charger input voltage (Vchgin) < Under Voltage Threshold (Vuvlo)
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_MARGINAL_VOLTAGE: Vchgin > Vuvlo and
>> + * Vchgin < (Battery Voltage (Vbatt) + system voltage (Vsys))
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_OVERVOLTAGE:
>> + * Vchgin > Over Voltage threshold (Vovlo)
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_VALID:
>> + * Vchgin > Vuvlo, Vchgin < Vovlo and Vchgin > (Vsys + Vbatt)
>> + */
>> +enum max77759_chgr_chgin_dtls_status {
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_UNDERVOLTAGE,
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_MARGINAL_VOLTAGE,
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_OVERVOLTAGE,
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_VALID,
>> +};
>> +
>> +/*
>> + * Battery Details
>> + * @MAX77759_CHGR_BAT_DTLS_NO_BATT_CHG_SUSP:
>> + * No battery and the charger suspended
>> + * @MAX77759_CHGR_BAT_DTLS_DEAD_BATTERY: Vbatt < Vtrickle
>> + * @MAX77759_CHGR_BAT_DTLS_BAT_CHG_TIMER_FAULT:
>> + * Charging suspended due to timer fault
>> + * @MAX77759_CHGR_BAT_DTLS_BAT_OKAY:
>> + * Battery okay and Vbatt > Min Sys Voltage (Vsysmin)
>> + * @MAX77759_CHGR_BAT_DTLS_BAT_UNDERVOLTAGE:
>> + * Battery is okay. Vtrickle < Vbatt < Vsysmin
>> + * @MAX77759_CHGR_BAT_DTLS_BAT_OVERVOLTAGE:
>> + * Battery voltage > Overvoltage threshold
>> + * @MAX77759_CHGR_BAT_DTLS_BAT_OVERCURRENT:
>> + * Battery current exceeds overcurrent threshold
>> + * @MAX77759_CHGR_BAT_DTLS_BAT_ONLY_MODE:
>> + * Battery only mode and battery level not available
>> + */
>> +enum max77759_chgr_bat_dtls_states {
>> + MAX77759_CHGR_BAT_DTLS_NO_BATT_CHG_SUSP,
>> + MAX77759_CHGR_BAT_DTLS_DEAD_BATTERY,
>> + MAX77759_CHGR_BAT_DTLS_BAT_CHG_TIMER_FAULT,
>> + MAX77759_CHGR_BAT_DTLS_BAT_OKAY,
>> + MAX77759_CHGR_BAT_DTLS_BAT_UNDERVOLTAGE,
>> + MAX77759_CHGR_BAT_DTLS_BAT_OVERVOLTAGE,
>> + MAX77759_CHGR_BAT_DTLS_BAT_OVERCURRENT,
>> + MAX77759_CHGR_BAT_DTLS_BAT_ONLY_MODE,
>> +};
>> +
>> +/*
>> + * Charger Details
>> + * @MAX77759_CHGR_CHG_DTLS_PREQUAL: Charger in prequalification mode
>> + * @MAX77759_CHGR_CHG_DTLS_CC: Charger in fast charge const curr mode
>> + * @MAX77759_CHGR_CHG_DTLS_CV: Charger in fast charge const voltage mode
>> + * @MAX77759_CHGR_CHG_DTLS_TO: Charger is in top off mode
>> + * @MAX77759_CHGR_CHG_DTLS_DONE: Charger is done
>> + * @MAX77759_CHGR_CHG_DTLS_RSVD_1: Reserved
>> + * @MAX77759_CHGR_CHG_DTLS_TIMER_FAULT: Charger is in timer fault mode
>> + * @MAX77759_CHGR_CHG_DTLS_SUSP_BATT_THM:
>> + * Charger is suspended as bettery removal detected
> Typo here, s/bettery/battery/.
Will fix.
>
>> + * @MAX77759_CHGR_CHG_DTLS_OFF:
>> + * Charger is off. Input invalid or charger disabled
>> + * @MAX77759_CHGR_CHG_DTLS_RSVD_2: Reserved
>> + * @MAX77759_CHGR_CHG_DTLS_RSVD_3: Reserved
>> + * @MAX77759_CHGR_CHG_DTLS_OFF_WDOG_TIMER:
>> + * Charger is off as watchdog timer expired
>> + * @MAX77759_CHGR_CHG_DTLS_SUSP_JEITA: Charger is in JEITA control mode
>> + */
>> +enum max77759_chgr_chg_dtls_states {
> Just a small style suggestion, could you please align the descriptions in this
> kerneldoc block? It improves readability. Using a consistent number of spaces
> or tabs after the colon helps.
>
> Feel free to use up to 100-chars if it improves readability.
I will try to align the descriptions for enumerators inside each enum.
Since I can use 100 chars I can try to fit the descriptions in a single
line for this and `enum max77759_chgr_bat_dtls_states` as well. Hope
that's okay?
BR,
Amit
^ permalink raw reply
* Re: [PATCH v5 0/4] cpupower: fix various man pages issues
From: Shuah Khan @ 2026-03-25 19:39 UTC (permalink / raw)
To: Roberto Ricci, Thomas Renninger, Shuah Khan, John B. Wyatt IV,
John Kacur
Cc: linux-kernel, linux-pm, Shuah Khan
In-Reply-To: <20260324223921.14317-1-io@r-ricci.it>
On 3/24/26 16:39, Roberto Ricci wrote:
> This patch series fixes a few issues with the cpupower manual pages,
> such as missing or incorrect options and trailing whitespace.
>
> Signed-off-by: Roberto Ricci <io@r-ricci.it>
>
> ---
> Changes in v5:
> - Drop whitespace removal patches
> Link to v4: https://lore.kernel.org/linux-pm/20260324013543.4776-1-io@r-ricci.it/
>
Applied to my cpupower branch - I will send this my next pr to
PM maintainer.
https://web.git.kernel.org/pub/scm/linux/kernel/git/shuah/linux.git/log/?h=cpupower
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH v10 00/12] barrier: Add smp_cond_load_{relaxed,acquire}_timeout()
From: David Laight @ 2026-03-25 19:36 UTC (permalink / raw)
To: Catalin Marinas
Cc: Ankur Arora, Andrew Morton, linux-kernel, linux-arch,
linux-arm-kernel, linux-pm, bpf, arnd, will, peterz, mark.rutland,
harisokn, cl, ast, rafael, daniel.lezcano, memxor, zhenglifeng1,
xueshuai, rdunlap, joao.m.martins, boris.ostrovsky, konrad.wilk
In-Reply-To: <acQFaVR_bGZU2JmJ@arm.com>
On Wed, 25 Mar 2026 15:55:21 +0000
Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Mon, Mar 16, 2026 at 11:37:12PM +0000, David Laight wrote:
...
> > For osq_lock(), while an IPI will wake it up, there is also a small timing
> > window where the IPI can happen before the ldx and so not actually wake up it.
> > This is true whenever 'expr' is non-trivial.
>
> Hmm, I thought this is fine because of the implicit SEVL on exception
> return but the arm64 __cmpwait_relaxed() does a SEVL+WFE which clears
> any prior event, it can wait in theory forever when the event stream is
> disabled.
Not forever, there will be a timer interrupt in the end.
> Expanding smp_cond_load_relaxed() into asm, we have something like:
>
> LDR X0, [PTR]
> condition check for VAL || need_resched() with branch out
> SEVL
> WFE
> LDXR X1, [PTR]
> EOR X1, X1, X0
> CBNZ out
> WFE
> out:
>
> If the condition is updated to become true (need_resched()) after the
> condition check but before the first WFE while *PTR remains unchanged,
> the IPI won't do anything. Maybe we should revert 1cfc63b5ae60 ("arm64:
> cmpwait: Clear event register before arming exclusive monitor"). Not
> great but probably better than reverting f5bfdc8e3947 ("locking/osq: Use
> optimized spinning loop for arm64")).
Could you change the order to:
LDR X0, [PTR]
SEVL
WFE
condition check for VAL || need_resched() with branch out
LDXR X1, [PTR]
EOR X1, X1, X0
CBNZ out
WFE
out:
that closes the timing window for the interrupt provided the condition
check doesn't change the event register.
I must get back to the osq_lock code again.
I'm happy with the code - the per-cpu data is down to two cpu numbers.
(Apart from the acquire/release semantics in a few places.)
But the comments have got out of hand.
Writing succinct and accurate comments is hard - too verbose and they
hide too much code.
David
^ permalink raw reply
* Re: [PATCH] thermal: core: fix use-after-free due to init/cancel delayed_work race
From: Rafael J. Wysocki @ 2026-03-25 19:29 UTC (permalink / raw)
To: Mauricio Faria de Oliveira
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
linux-pm, linux-kernel, kernel-dev, syzbot+3b3852c6031d0f30dfaf
In-Reply-To: <cce6cb6e12b09bc97cf684e378c874f4@igalia.com>
On Wed, Mar 25, 2026 at 8:22 PM Mauricio Faria de Oliveira
<mfo@igalia.com> wrote:
>
> On 2026-03-25 13:24, Rafael J. Wysocki wrote:
> > On Wed, Mar 25, 2026 at 4:13 PM Mauricio Faria de Oliveira
> > <mfo@igalia.com> wrote:
> >>
> >> On 2026-03-25 11:28, Mauricio Faria de Oliveira wrote:
> >> > On 2026-03-25 11:17, Mauricio Faria de Oliveira wrote:
> >> >> Thanks for looking into this.
> >> >>
> >> >> On 2026-03-25 09:47, Rafael J. Wysocki wrote:
> >> >>> I can see the one between thermal_zone_device_unregister() and
> >> >>> thermal_zone_device_resume(), but that can be addressed by adding a
> >> >>> TZ_STATE_FLAG_EXIT check to the latter AFAICS.
> >> >>
> >> >
> >> > Please disregard this paragraph; I incorrectly read/wrote _resume()
> >> > as thermal_zone_pm_complete() discussed above. The rest should be
> >> > right. I'll review this and get back shortly.
> >> >
> >> >> In the example describe above and detailed below, apparently that
> >> >> is not sufficient, if I'm not missing anything. See, if _resume()
> >> >> is reached with thermal_list_lock held, thermal_zone_device_exit()
> >> >> is waiting for thermal_list_lock before setting TZ_STATE_FLAG_EXIT,
> >> >> thus a check for it in _resume() would find it clear yet.
> >>
> >> Ok, similarly:
> >>
> >> Say, thermal_pm_notify() -> thermal_pm_notify_complete() ->
> >> thermal_zone_pm_complete()
> >> run before thermal_zone_device_unregister() is called;
> >> thermal_zone_device_resume()
> >> starts, and by now thermal_zone_device_unregister() is called.
> >>
> >> If thermal_zone_device_resume() wins the race over thermal_zone_exit()
> >> for guard(thermal_zone(tz) (tz->lock), it sees TZ_STATE_FLAG_EXIT clear;
> >> note its callees (eg, thermal_zone_device_init()) run with tz->lock
> >> held,
> >> so they see it clear as well.
> >>
> >> So, thermal_zone_device_init() calls INIT_DELAYED_WORK(), everything
> >> returns, tz->lock is released and the thermal_zone_device_unregister()
> >> -> thermal_zone_exit() path can continue to run.
> >>
> >> Only now thermal_zone_exit() sets TZ_STATE_FLAG_EXIT (too late),
> >> returns.
> >> cancel_delayed_work_sync() does not wait for
> >> thermal_zone_device_resume()
> >> due to INIT_DELAYED_WORK() in thermal_zone_device_init(); and kfree(tz).
> >>
> >> Then, thermal_zone_device_resume() accesses tz and hits use-after-free.
> >>
> >> Hope this clarifies. Please let me know your thoughts. Thanks!
> >
> > Thanks for the analysis, it sounds accurate.
> >
> > I'd say that thermal_zone_device_unregister() needs to flush the
> > workqueue before calling cancel_delayed_work_sync() to get rid of the
> > stuff that may be running out of it that hasn't seen the changes made
> > by thermal_zone_exit().
>
> IIUIC, cancel_delayed_work_sync() has that effect: it waits for
> (specific)
> work that might be running and hasn't seen changes by
> thermal_zone_exit()).
Sure, but you argued yourself that this didn't work if the work item
in question had been reinitialized in the meantime.
Flushing of the workqueue would take care of that.
> > This should take care of all of the existing races because if anything
> > is running out of the workqueue when thermal_zone_device_unregister()
> > runs, it will be waited for after calling thermal_zone_exit() and any
> > leftover stuff will be caught by cancel_delayed_work_sync().
>
> Likewise, the wait-for part is an effect of cancel_delayed_work_sync(),
> and AFAIK, there is no leftover after cancel_delayed_work_sync(), as
> it waits for the running work function to finish.
>
> And no further work is queued in the 2 code paths that can queue work:
>
> 1) thermal_zone_device_check(): even if it misses the tz->state check,
> mod_delayed_work() does not requeue the current work item if it is
> canceled/waited for by cancel_delayed_work_sync() (tested locally).
>
> 2) thermal_zone_pm_complete(): this function will no longer be reached
> because tz is no longer in thermal_tz_list.
>
> > Of course, it's better to switch over to using a dedicated workqueue
> > in the thermal core for that.
>
> Considering the points above, AFAICT, it should be sufficient to call
> cancel_delayed_work_sync() for the 2 code paths in unregister()
> (which thus require the distint work items for each code path).
And I don't want to add another work item to the thermal zone
structure just for the handling of suspend/resume.
^ permalink raw reply
* Re: [PATCH] thermal: core: fix use-after-free due to init/cancel delayed_work race
From: Mauricio Faria de Oliveira @ 2026-03-25 19:22 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Daniel Lezcano, Zhang Rui, Lukasz Luba, linux-pm, linux-kernel,
kernel-dev, syzbot+3b3852c6031d0f30dfaf
In-Reply-To: <CAJZ5v0jcK0eg1fjSmMDDhTqNqFxUmhdNs=exs13nduRivCiLQQ@mail.gmail.com>
On 2026-03-25 13:24, Rafael J. Wysocki wrote:
> On Wed, Mar 25, 2026 at 4:13 PM Mauricio Faria de Oliveira
> <mfo@igalia.com> wrote:
>>
>> On 2026-03-25 11:28, Mauricio Faria de Oliveira wrote:
>> > On 2026-03-25 11:17, Mauricio Faria de Oliveira wrote:
>> >> Thanks for looking into this.
>> >>
>> >> On 2026-03-25 09:47, Rafael J. Wysocki wrote:
>> >>> I can see the one between thermal_zone_device_unregister() and
>> >>> thermal_zone_device_resume(), but that can be addressed by adding a
>> >>> TZ_STATE_FLAG_EXIT check to the latter AFAICS.
>> >>
>> >
>> > Please disregard this paragraph; I incorrectly read/wrote _resume()
>> > as thermal_zone_pm_complete() discussed above. The rest should be
>> > right. I'll review this and get back shortly.
>> >
>> >> In the example describe above and detailed below, apparently that
>> >> is not sufficient, if I'm not missing anything. See, if _resume()
>> >> is reached with thermal_list_lock held, thermal_zone_device_exit()
>> >> is waiting for thermal_list_lock before setting TZ_STATE_FLAG_EXIT,
>> >> thus a check for it in _resume() would find it clear yet.
>>
>> Ok, similarly:
>>
>> Say, thermal_pm_notify() -> thermal_pm_notify_complete() ->
>> thermal_zone_pm_complete()
>> run before thermal_zone_device_unregister() is called;
>> thermal_zone_device_resume()
>> starts, and by now thermal_zone_device_unregister() is called.
>>
>> If thermal_zone_device_resume() wins the race over thermal_zone_exit()
>> for guard(thermal_zone(tz) (tz->lock), it sees TZ_STATE_FLAG_EXIT clear;
>> note its callees (eg, thermal_zone_device_init()) run with tz->lock
>> held,
>> so they see it clear as well.
>>
>> So, thermal_zone_device_init() calls INIT_DELAYED_WORK(), everything
>> returns, tz->lock is released and the thermal_zone_device_unregister()
>> -> thermal_zone_exit() path can continue to run.
>>
>> Only now thermal_zone_exit() sets TZ_STATE_FLAG_EXIT (too late),
>> returns.
>> cancel_delayed_work_sync() does not wait for
>> thermal_zone_device_resume()
>> due to INIT_DELAYED_WORK() in thermal_zone_device_init(); and kfree(tz).
>>
>> Then, thermal_zone_device_resume() accesses tz and hits use-after-free.
>>
>> Hope this clarifies. Please let me know your thoughts. Thanks!
>
> Thanks for the analysis, it sounds accurate.
>
> I'd say that thermal_zone_device_unregister() needs to flush the
> workqueue before calling cancel_delayed_work_sync() to get rid of the
> stuff that may be running out of it that hasn't seen the changes made
> by thermal_zone_exit().
IIUIC, cancel_delayed_work_sync() has that effect: it waits for
(specific)
work that might be running and hasn't seen changes by
thermal_zone_exit()).
> This should take care of all of the existing races because if anything
> is running out of the workqueue when thermal_zone_device_unregister()
> runs, it will be waited for after calling thermal_zone_exit() and any
> leftover stuff will be caught by cancel_delayed_work_sync().
Likewise, the wait-for part is an effect of cancel_delayed_work_sync(),
and AFAIK, there is no leftover after cancel_delayed_work_sync(), as
it waits for the running work function to finish.
And no further work is queued in the 2 code paths that can queue work:
1) thermal_zone_device_check(): even if it misses the tz->state check,
mod_delayed_work() does not requeue the current work item if it is
canceled/waited for by cancel_delayed_work_sync() (tested locally).
2) thermal_zone_pm_complete(): this function will no longer be reached
because tz is no longer in thermal_tz_list.
> Of course, it's better to switch over to using a dedicated workqueue
> in the thermal core for that.
Considering the points above, AFAICT, it should be sufficient to call
cancel_delayed_work_sync() for the 2 code paths in unregister()
(which thus require the distint work items for each code path).
Thanks,
--
Mauricio
^ permalink raw reply
* Re: [PATCH v5 00/21] Virtual Swap Space
From: YoungJun Park @ 2026-03-25 18:53 UTC (permalink / raw)
To: Nhat Pham
Cc: Kairui Song, Liam.Howlett, akpm, apopple, axelrasmussen, baohua,
baolin.wang, bhe, byungchul, cgroups, chengming.zhou, chrisl,
corbet, david, dev.jain, gourry, hannes, hughd, jannh,
joshua.hahnjy, lance.yang, lenb, linux-doc, linux-kernel,
linux-mm, linux-pm, lorenzo.stoakes, matthew.brost, mhocko,
muchun.song, npache, pavel, peterx, peterz, pfalcato, rafael,
rakie.kim, roman.gushchin, rppt, ryan.roberts, shakeel.butt,
shikemeng, surenb, tglx, vbabka, weixugc, ying.huang, yosry.ahmed,
yuanchu, zhengqi.arch, ziy, kernel-team, riel
In-Reply-To: <CAKEwX=PBjMVfMvKkNfqbgiw7o10NFyZBSB62ODzsqogv-WDYKQ@mail.gmail.com>
On Mon, Mar 23, 2026 at 11:32:57AM -0400, Nhat Pham wrote:
> Interesting. Normally "lots of zero-filled page" is a very beneficial
> case for vswap. You don't need a swapfile, or any zram/zswap metadata
> overhead - it's a native swap backend. If production workload has this
> many zero-filled pages, I think the numbers of vswap would be much
> less alarming - perhaps even matching memory overhead because you
> don't need to maintain a zram entry metadata (it's at least 2 words
> per zram entry right?), while there's no reverse map overhead induced
> (so it's 24 bytes on both side), and no need to do zram-side locking
> :)
>
> So I was surprised to see that it's not working out very well here. I
> checked the implementation of memhog - let me know if this is wrong
> place to look:
>
> https://man7.org/linux/man-pages/man8/memhog.8.html
> https://github.com/numactl/numactl/blob/master/memhog.c#L52
>
> I think this is what happened here: memhog was populating the memory
> 0xff, which triggers the full overhead of a swapfile-backed swap entry
> because even though it's "same-filled" it's not zero-filled! I was
> following Usama's observation - "less than 1% of the same-filled pages
> were non-zero" - and so I only handled the zero-filled case here:
>
> https://lore.kernel.org/all/20240530102126.357438-1-usamaarif642@gmail.com/
>
> This sounds a bit artificial IMHO - as Usama pointed out above, I
> think most samefilled pages are zero pages, in real production
> workloads. However, if you think there are real use cases with a lot
> of non-zero samefilled pages, please let me know I can fix this real
> quick. We can support this in vswap with zero extra metadata overhead
> - change the VSWAP_ZERO swap entry type to VSWAP_SAME_FILLED, then use
> the backend field to store that value. I can send you a patch if
> you're interested.
This brings back memories -- I'm pretty sure we talked about
exactly this at LPC. Our custom swap device already handles both
zero-filled and same-filled pages on its own, so what we really
wanted was a way to tell the swap layer "just skip the detection
and let it through."
I looked at two approaches back then but never submitted either:
- A per-swap_info flag to opt out of zero/same-filled handling.
But this felt wrong from vswap's perspective -- if even one
device opts out of the zeromap, the model gets messy.
- Revisiting Usama's patch 2 approach.
Sounded good in theory, but as you said,
it's not as simple to verify in practice. And it is more clean design
swapout time zero check as I see. So, I gave up on it.
Seeing this come up again is actually kind of nice :)
One thought -- maybe a compile-time CONFIG or a boot param to
control the scope? e.g. zero-only, same-filled, or disabled.
That way vendors like us just turn it off, and setups like
Kairui's can opt into broader detection. Just an idea though --
open to other approaches if you have something in mind.
Thanks,
Youngjun Park
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox