* Re: [PATCH v3 1/2] dt-bindings: power: supply: gpio-charger: add support for fast-charge timer
From: Krzysztof Kozlowski @ 2026-03-24 8:55 UTC (permalink / raw)
To: Dimitri Fedrau
Cc: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-pm, devicetree, linux-kernel, Dimitri Fedrau
In-Reply-To: <20260323-gpio-charger-timer-v3-1-885796d681a5@liebherr.com>
On Mon, Mar 23, 2026 at 05:04:06PM +0100, Dimitri Fedrau wrote:
> charger-type:
> enum:
> @@ -62,6 +67,10 @@ properties:
> description: Default charge current limit. Must be listed in
> charge-current-limit-mapping.
>
> + fast-charge-timer-gpios:
> + maxItems: 1
> + description: GPIO used for enabling/disabling the fast-charge timer
> +
So where is the solution for "and then only allow
'fast-charge-timer-gpios' for the BQ24081."?
See example-schema or other bindings for the "if:not:...then:...
fast-charge-timer-gpios: false"
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 0/2] power: supply: gpio-charger: add support for fast-charge timer
From: Krzysztof Kozlowski @ 2026-03-24 8:56 UTC (permalink / raw)
To: Dimitri Fedrau
Cc: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-pm, devicetree, linux-kernel, Dimitri Fedrau
In-Reply-To: <20260323-gpio-charger-timer-v3-0-885796d681a5@liebherr.com>
On Mon, Mar 23, 2026 at 05:04:05PM +0100, Dimitri Fedrau wrote:
> On some devices like TIs BQ24081 battery charger it is possible to activate
> or deactivate a fast-charge timer that provides a backup safety for charge
> termination. In case of the BQ24081 it is a fixed 7-hour timer. Add support
> for enabling/disabling the fast-charge timer via GPIO.
>
> Signed-off-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com>
> ---
> Changes in v3:
> - Add documentation for fast_charge_timer
> - Add a compatible for the BQ24081 (using gpio-charger as fallback) and
> then only allow 'fast-charge-timer-gpios' for the BQ24081.
Where do you "only allow" it? Please point me to specific code.
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH v2 0/9] gpio: remove uneeded Kconfig dependencies on OF_GPIO
From: Bartosz Golaszewski @ 2026-03-24 9:04 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Linus Walleij, Lee Jones, Pavel Machek,
Wim Van Sebroeck, Guenter Roeck, Mauro Carvalho Chehab,
Greg Kroah-Hartman, Sebastian Reichel, Bartosz Golaszewski
Cc: brgl, linux-arm-kernel, linux-kernel, netdev, linux-gpio,
linux-leds, linux-watchdog, linux-media, linux-staging, linux-pm
In-Reply-To: <20260316-gpio-of-kconfig-v2-0-de2f4b00a0e4@oss.qualcomm.com>
On Mon, 16 Mar 2026 10:45:20 +0100, Bartosz Golaszewski wrote:
> NOTE: Each patch in this series can be picked up independently into
> maintainer trees.
>
> CONFIG_OF_GPIO is a switch that enables the compilation of the gpiolib-of
> module. The module itself handles GPIO lookup via the OF-node tree and
> is automatically enabled on all OF systems. It does not export any
> public symbols to drivers. There is no reason for them to select or
> depend on it in Kconfig.
>
> [...]
Applied, thanks!
[3/9] gpio: drop unneeded Kconfig dependencies on OF_GPIO
https://git.kernel.org/brgl/c/7803501e5754dc4b295ab22b20562e2b965358ba
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v2] cpufreq: acpi-cpufreq: use DMI max speed when CPPC is unavailable
From: Henry Tseng @ 2026-03-24 9:09 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar
Cc: Len Brown, linux-pm, linux-acpi, SW Chen, Kevin Ko, Henry Tseng
On AMD Ryzen Embedded V1780B (Family 17h, Zen 1), the BIOS does not
provide ACPI _CPC objects and the CPU does not support MSR-based CPPC
(X86_FEATURE_CPPC). The _PSS table only lists nominal P-states
(P0 = 3350 MHz), so when get_max_boost_ratio() fails at
cppc_get_perf_caps(), cpuinfo_max_freq reports only the base frequency
instead of the rated boost frequency (3600 MHz).
dmesg:
ACPI CPPC: No CPC descriptor for CPU:0
acpi_cpufreq: CPU0: Unable to get performance capabilities (-19)
cppc-cpufreq already has a DMI fallback (cppc_get_dmi_max_khz()) that
reads the processor max speed from SMBIOS Type 4. Export it and reuse
it in acpi-cpufreq as a last-resort source for the boost frequency.
A sanity check ensures the DMI value is above the _PSS P0 frequency
and within 2x of it; values outside that range are ignored and the
existing arch_set_max_freq_ratio() path is taken instead. The 2x
upper bound is based on a survey of the AMD Ryzen Embedded V1000
series, where the highest boost-to-base ratio is 1.8x (V1404I:
2.0 GHz base / 3.6 GHz boost).
The DMI lookup and sanity check are wrapped in a helper,
acpi_cpufreq_resolve_max_freq(), which falls through to
arch_set_max_freq_ratio() if the DMI value is absent or
out of range.
Tested on AMD Ryzen Embedded V1780B with v7.0-rc4:
Before: cpuinfo_max_freq = 3350000 (base only)
After: cpuinfo_max_freq = 3600000 (includes boost)
Link: https://www.amd.com/en/products/embedded/ryzen/ryzen-v1000-series.html#specifications
Signed-off-by: Henry Tseng <henrytseng@qnap.com>
---
v2:
- Extract else block into acpi_cpufreq_resolve_max_freq()
to avoid #ifdef in the main init path (Rafael)
v1:
- https://lore.kernel.org/linux-pm/20260320095648.3598007-1-henrytseng@qnap.com/
drivers/acpi/cppc_acpi.c | 3 ++-
drivers/cpufreq/acpi-cpufreq.c | 31 ++++++++++++++++++++++++-------
include/acpi/cppc_acpi.h | 1 +
3 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index f0e513e9ed5d..f53de414acf2 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -1944,7 +1944,7 @@ static void cppc_find_dmi_mhz(const struct dmi_header *dm, void *private)
}
/* Look up the max frequency in DMI */
-static u64 cppc_get_dmi_max_khz(void)
+u64 cppc_get_dmi_max_khz(void)
{
u16 mhz = 0;
@@ -1958,6 +1958,7 @@ static u64 cppc_get_dmi_max_khz(void)
return KHZ_PER_MHZ * mhz;
}
+EXPORT_SYMBOL_GPL(cppc_get_dmi_max_khz);
/*
* If CPPC lowest_freq and nominal_freq registers are exposed then we can
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index e7eff6c2f092..21639d9ac753 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -675,6 +675,29 @@ static inline u64 get_max_boost_ratio(unsigned int cpu, u64 *nominal_freq)
}
#endif
+static void acpi_cpufreq_resolve_max_freq(struct cpufreq_policy *policy,
+ unsigned int pss_max_freq)
+{
+#ifdef CONFIG_ACPI_CPPC_LIB
+ u64 max_speed = cppc_get_dmi_max_khz();
+ /*
+ * Use DMI "Max Speed" if it looks plausible: must be
+ * above _PSS P0 frequency and within 2x of it.
+ */
+ if (max_speed > pss_max_freq && max_speed < pss_max_freq * 2) {
+ policy->cpuinfo.max_freq = max_speed;
+ return;
+ }
+#endif
+ /*
+ * If the maximum "boost" frequency is unknown, ask the arch
+ * scale-invariance code to use the "nominal" performance for
+ * CPU utilization scaling so as to prevent the schedutil
+ * governor from selecting inadequate CPU frequencies.
+ */
+ arch_set_max_freq_ratio(true);
+}
+
static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
struct cpufreq_frequency_table *freq_table;
@@ -849,13 +872,7 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
policy->cpuinfo.max_freq = freq * max_boost_ratio >> SCHED_CAPACITY_SHIFT;
} else {
- /*
- * If the maximum "boost" frequency is unknown, ask the arch
- * scale-invariance code to use the "nominal" performance for
- * CPU utilization scaling so as to prevent the schedutil
- * governor from selecting inadequate CPU frequencies.
- */
- arch_set_max_freq_ratio(true);
+ acpi_cpufreq_resolve_max_freq(policy, freq_table[0].frequency);
}
policy->freq_table = freq_table;
diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
index 4d644f03098e..e6c5ef3173c5 100644
--- a/include/acpi/cppc_acpi.h
+++ b/include/acpi/cppc_acpi.h
@@ -156,6 +156,7 @@ extern int cppc_set_enable(int cpu, bool enable);
extern int cppc_get_perf_caps(int cpu, struct cppc_perf_caps *caps);
extern bool cppc_perf_ctrs_in_pcc_cpu(unsigned int cpu);
extern bool cppc_perf_ctrs_in_pcc(void);
+extern u64 cppc_get_dmi_max_khz(void);
extern unsigned int cppc_perf_to_khz(struct cppc_perf_caps *caps, unsigned int perf);
extern unsigned int cppc_khz_to_perf(struct cppc_perf_caps *caps, unsigned int freq);
extern bool acpi_cpc_valid(void);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 09/11] mfd: bq257xx: Add BQ25792 support
From: Alexey Charkov @ 2026-03-24 9:20 UTC (permalink / raw)
To: Lee Jones
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chris Morgan,
Liam Girdwood, Mark Brown, Sebastian Reichel, devicetree,
linux-kernel, Sebastian Reichel, linux-pm
In-Reply-To: <20260319170118.GP554736@google.com>
On Thu, Mar 19, 2026 at 9:01 PM Lee Jones <lee@kernel.org> wrote:
>
> On Wed, 11 Mar 2026, Alexey Charkov wrote:
>
> > Add register definitions and a new 'type' enum to be passed via MFD
> > private data to support the BQ25792, which is a newer variant of the
> > BQ257xx family.
> >
> > BQ25792 shares similar logic of operation with the already supported
> > BQ25703A but has a completely different register map and different
> > electrical constraints.
> >
> > Tested-by: Chris Morgan <macromorgan@hotmail.com>
> > Signed-off-by: Alexey Charkov <alchark@flipper.net>
> > ---
> > drivers/mfd/bq257xx.c | 54 +++++-
> > include/linux/mfd/bq257xx.h | 414 ++++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 465 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/mfd/bq257xx.c b/drivers/mfd/bq257xx.c
> > index e9d49dac0a16..4445ded5b2eb 100644
> > --- a/drivers/mfd/bq257xx.c
> > +++ b/drivers/mfd/bq257xx.c
> > @@ -39,13 +39,47 @@ static const struct regmap_config bq25703_regmap_config = {
> > .val_format_endian = REGMAP_ENDIAN_LITTLE,
> > };
> >
> > -static const struct mfd_cell cells[] = {
> > +static const struct regmap_range bq25792_writeable_reg_ranges[] = {
> > + regmap_reg_range(BQ25792_REG00_MIN_SYS_VOLTAGE,
> > + BQ25792_REG18_NTC_CONTROL_1),
> > + regmap_reg_range(BQ25792_REG28_CHARGER_MASK_0,
> > + BQ25792_REG30_ADC_FUNCTION_DISABLE_1),
> > +};
> > +
> > +static const struct regmap_access_table bq25792_writeable_regs = {
> > + .yes_ranges = bq25792_writeable_reg_ranges,
> > + .n_yes_ranges = ARRAY_SIZE(bq25792_writeable_reg_ranges),
> > +};
> > +
> > +static const struct regmap_range bq25792_volatile_reg_ranges[] = {
> > + regmap_reg_range(BQ25792_REG19_ICO_CURRENT_LIMIT,
> > + BQ25792_REG27_FAULT_FLAG_1),
> > + regmap_reg_range(BQ25792_REG31_IBUS_ADC,
> > + BQ25792_REG47_DPDM_DRIVER),
> > +};
> > +
> > +static const struct regmap_access_table bq25792_volatile_regs = {
> > + .yes_ranges = bq25792_volatile_reg_ranges,
> > + .n_yes_ranges = ARRAY_SIZE(bq25792_volatile_reg_ranges),
> > +};
> > +
> > +static const struct regmap_config bq25792_regmap_config = {
> > + .reg_bits = 8,
> > + .val_bits = 8,
> > + .max_register = BQ25792_REG48_PART_INFORMATION,
> > + .cache_type = REGCACHE_MAPLE,
> > + .wr_table = &bq25792_writeable_regs,
> > + .volatile_table = &bq25792_volatile_regs,
> > +};
> > +
> > +static struct mfd_cell cells[] = {
>
> This was `static const` before. And I don't see any code in here making
> changes to it. Was the `const` dropped intentionally?
Thanks for spotting this, Lee. It was removed in a prior version when
I was passing the type as platform data, which is no longer the case,
so the const can be reinstated. Will do.
> > MFD_CELL_NAME("bq257xx-regulator"),
> > MFD_CELL_NAME("bq257xx-charger"),
> > };
> >
> > static int bq257xx_probe(struct i2c_client *client)
> > {
> > + const struct regmap_config *rcfg;
> > struct bq257xx_device *ddata;
> > int ret;
> >
> > @@ -53,9 +87,21 @@ static int bq257xx_probe(struct i2c_client *client)
> > if (!ddata)
> > return -ENOMEM;
> >
> > + ddata->type = (uintptr_t)device_get_match_data(&client->dev);
>
> This logic seems a bit fragile. For non-DeviceTree platforms,
> `device_get_match_data()` will return `NULL` since the `i2c_device_id`
> table doesn't provide any match data. Casting `NULL` to `uintptr_t` will
> result in `0`, which corresponds to `BQ25703A`. This means the new
> `bq25792` will be misidentified as a `bq25703a` when instantiated
> without a DeviceTree node. Even with DeviceTree, if a compatible string
> is matched but has no `.data` property, the same misidentification will
> occur.
>
> Perhaps it would be safer to explicitly handle the `NULL` case and make the
> identification logic more robust? Or perhaps start your IDs from 1.
Guess I'll do both: add matches to the `i2c_device_id` to enable
non-OF use, and make IDs 1-based to avoid misinterpreting a failed
match as a valid BQ25703A match. Thanks for the pointers!
> > ddata->client = client;
> >
> > - ddata->regmap = devm_regmap_init_i2c(client, &bq25703_regmap_config);
> > + switch (ddata->type) {
> > + case BQ25703A:
> > + rcfg = &bq25703_regmap_config;
> > + break;
> > + case BQ25792:
> > + rcfg = &bq25792_regmap_config;
> > + break;
> > + default:
> > + return dev_err_probe(&client->dev, -EINVAL, "Unsupported device type\n");
>
> Given the potential for `device_get_match_data()` to return `NULL` (which
> becomes `0`), this `default` case might not be reachable for invalid or
> un-matchable devices. A more explicit check on the match data before this
> `switch` might be better.
I'll shift the enum values to start at 1, then an extra check on the
match data shouldn't be necessary, as NULL will fall through to the
error in `default`.
Thanks a lot,
Alexey
^ permalink raw reply
* Re: [PATCH] PM: hibernate: call preallocate_image after freeze prepare
From: Matthew Leach @ 2026-03-24 9:22 UTC (permalink / raw)
To: YoungJun Park
Cc: Rafael J. Wysocki, Pavel Machek, Len Brown, Mario Limonciello,
linux-pm, linux-kernel, kernel
In-Reply-To: <acFa5+ihROC9/0Va@yjaykim-PowerEdge-T330>
YoungJun Park <youngjun.park@lge.com> writes:
> On Sat, Mar 21, 2026 at 08:51:31AM +0000, Matthew Leach wrote:
>
> Hi Matthew,
Hi Youngjun,
Thanks for the review.
>> + /* Preallocate image memory before shutting down devices. */
>> + error = hibernate_preallocate_memory();
>
> The shrink_shmem_memory() below is also intended to run after
> dpm_prepare(), and the motivation is the same. Since
> hibernate_preallocate_memory() already does shrinking internally,
> how about pulling out the shrink-related parts and consolidating
> them together?
Agreed. I'll remove shrink_shmem_memory() completely since
hibernate_preallocate_memory() will have swapped out as many pages as is
required to construct the image in system RAM. There's no point doing
another reclaim.
>> + if (error)
>> + goto Thaw;
>
> Don't we need to call dpm_complete(PMSG_RECOVER) in this error path?
Yes, good catch.
Regards,
--
Matt
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: st: spear: fix dtbs warning on spear thermal sensor
From: Krzysztof Kozlowski @ 2026-03-24 9:26 UTC (permalink / raw)
To: Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260323133814.14152-3-krishnagopi487@gmail.com>
On Mon, Mar 23, 2026 at 07:08:09PM +0530, Gopi Krishna Menon wrote:
> Running DTBS checks on st/spear1340-evb.dtb results in the following
> warning:
>
> thermal@e07008c4 (st,thermal-spear1340): Unevaluated properties are not allowed ('thermal_flags' was unexpected)
> from schema $id: http://devicetree.org/schemas/thermal/st,thermal-spear1340.yaml
How is it possible if there is no such file?
Did you just add new warning in patch #1 and then claim in patch #2 that
you fix it?
You completely miss the point why this change is needed: how could the
DTS work before? It could not. And that should be your justification for
the patch, with explanation why it could not work.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: st: spear: fix dtbs warning on spear thermal sensor
From: Krzysztof Kozlowski @ 2026-03-24 9:27 UTC (permalink / raw)
To: Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260324-smoky-radical-hyrax-1274a9@quoll>
On 24/03/2026 10:26, Krzysztof Kozlowski wrote:
> On Mon, Mar 23, 2026 at 07:08:09PM +0530, Gopi Krishna Menon wrote:
>> Running DTBS checks on st/spear1340-evb.dtb results in the following
>> warning:
>>
>> thermal@e07008c4 (st,thermal-spear1340): Unevaluated properties are not allowed ('thermal_flags' was unexpected)
>> from schema $id: http://devicetree.org/schemas/thermal/st,thermal-spear1340.yaml
>
> How is it possible if there is no such file?
>
> Did you just add new warning in patch #1 and then claim in patch #2 that
> you fix it?
>
> You completely miss the point why this change is needed: how could the
> DTS work before? It could not. And that should be your justification for
> the patch, with explanation why it could not work.
... or you would notice that code was working and this part is just
redundant. Then fix would be completely different, though.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Krzysztof Kozlowski @ 2026-03-24 9:30 UTC (permalink / raw)
To: Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260323133814.14152-2-krishnagopi487@gmail.com>
On Mon, Mar 23, 2026 at 07:08:08PM +0530, Gopi Krishna Menon wrote:
> +properties:
> + compatible:
> + const: st,thermal-spear1340
> +
> + reg:
> + maxItems: 1
> +
> + st,thermal-flags:
> + description: flags used to enable thermal sensor
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> +required:
> + - compatible
> + - reg
> + - st,thermal-flags
> +
> +unevaluatedProperties: false
additionalProperties: true
Best regards,
Krzysztof
^ permalink raw reply
* [rafael-pm:bleeding-edge] BUILD SUCCESS a1570ef54de30553c1ff751f0454ba83608c68f8
From: kernel test robot @ 2026-03-24 9:34 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-acpi, linux-pm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: a1570ef54de30553c1ff751f0454ba83608c68f8 Merge branch 'pm-powercap' into bleeding-edge
elapsed time: 819m
configs tested: 151
configs skipped: 1
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260324 gcc-8.5.0
arc randconfig-002-20260324 gcc-8.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001-20260324 gcc-8.5.0
arm randconfig-002-20260324 gcc-8.5.0
arm randconfig-003-20260324 gcc-8.5.0
arm randconfig-004-20260324 gcc-8.5.0
arm u8500_defconfig gcc-15.2.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260324 gcc-13.4.0
arm64 randconfig-002-20260324 gcc-13.4.0
arm64 randconfig-003-20260324 gcc-13.4.0
arm64 randconfig-004-20260324 gcc-13.4.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260324 gcc-13.4.0
csky randconfig-002-20260324 gcc-13.4.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260324 gcc-12
i386 buildonly-randconfig-002-20260324 gcc-12
i386 buildonly-randconfig-003-20260324 gcc-12
i386 buildonly-randconfig-004-20260324 gcc-12
i386 buildonly-randconfig-005-20260324 gcc-12
i386 buildonly-randconfig-006-20260324 gcc-12
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260324 clang-20
i386 randconfig-002-20260324 clang-20
i386 randconfig-003-20260324 clang-20
i386 randconfig-004-20260324 clang-20
i386 randconfig-005-20260324 clang-20
i386 randconfig-006-20260324 clang-20
i386 randconfig-007-20260324 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips rb532_defconfig clang-18
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc randconfig-001-20260324 gcc-8.5.0
parisc randconfig-002-20260324 gcc-8.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc randconfig-001-20260324 gcc-8.5.0
powerpc randconfig-002-20260324 gcc-8.5.0
powerpc64 randconfig-001-20260324 gcc-8.5.0
powerpc64 randconfig-002-20260324 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv randconfig-001-20260324 clang-23
riscv randconfig-002-20260324 clang-23
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 randconfig-001-20260324 clang-23
s390 randconfig-002-20260324 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260324 clang-23
sh randconfig-002-20260324 clang-23
sparc allnoconfig clang-23
sparc randconfig-001-20260324 gcc-14
sparc randconfig-002-20260324 gcc-14
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260324 gcc-14
sparc64 randconfig-002-20260324 gcc-14
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260324 gcc-14
um randconfig-002-20260324 gcc-14
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260324 gcc-14
x86_64 buildonly-randconfig-002-20260324 gcc-14
x86_64 buildonly-randconfig-003-20260324 gcc-14
x86_64 buildonly-randconfig-004-20260324 gcc-14
x86_64 buildonly-randconfig-005-20260324 gcc-14
x86_64 buildonly-randconfig-006-20260324 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260324 clang-20
x86_64 randconfig-002-20260324 clang-20
x86_64 randconfig-003-20260324 clang-20
x86_64 randconfig-004-20260324 clang-20
x86_64 randconfig-005-20260324 clang-20
x86_64 randconfig-006-20260324 clang-20
x86_64 randconfig-011-20260324 gcc-14
x86_64 randconfig-012-20260324 gcc-14
x86_64 randconfig-013-20260324 gcc-14
x86_64 randconfig-014-20260324 gcc-14
x86_64 randconfig-015-20260324 gcc-14
x86_64 randconfig-016-20260324 gcc-14
x86_64 randconfig-071-20260324 gcc-12
x86_64 randconfig-072-20260324 gcc-12
x86_64 randconfig-073-20260324 gcc-12
x86_64 randconfig-074-20260324 gcc-12
x86_64 randconfig-075-20260324 gcc-12
x86_64 randconfig-076-20260324 gcc-12
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260324 gcc-14
xtensa randconfig-002-20260324 gcc-14
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 5/5] fpga: m10bmc-sec: switch show_canceled_csk() to using sysfs_emit()
From: Xu Yilun @ 2026-03-24 9:15 UTC (permalink / raw)
To: Yury Norov
Cc: linux-kernel, Christophe Leroy (CS GROUP), Peter Zijlstra (Intel),
Rafael J. Wysocki, Alexander Shishkin, Daniel Lezcano,
Ingo Molnar, James Clark, Kees Cook, Lukasz Luba,
Madhavan Srinivasan, Michael Ellerman, Mike Leach, Moritz Fischer,
Nicholas Piggin, Russ Weight, Shrikanth Hegde, Suki K Poulose,
Tom Rix, Thomas Weißschuh, Xu Yilun, Yury Norov, Zhang Rui,
coresight, linux-arm-kernel, linux-fpga, linux-pm, linuxppc-dev,
Jakub Kicinski
In-Reply-To: <20260303200842.124996-6-ynorov@nvidia.com>
On Tue, Mar 03, 2026 at 03:08:41PM -0500, Yury Norov wrote:
> Switch show_canceled_csk() to use the proper sysfs_emit("%*pbl").
>
> Reviewed-by: Russ Weight <russ.weight@linux.dev>
> Suggested-by: Thomas Weißschuh <linux@weissschuh.net>
> Signed-off-by: Yury Norov <ynorov@nvidia.com>
> ---
> drivers/fpga/intel-m10-bmc-sec-update.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/fpga/intel-m10-bmc-sec-update.c b/drivers/fpga/intel-m10-bmc-sec-update.c
> index 10f678b9ed36..ae364c6636eb 100644
> --- a/drivers/fpga/intel-m10-bmc-sec-update.c
> +++ b/drivers/fpga/intel-m10-bmc-sec-update.c
> @@ -10,6 +10,7 @@
> #include <linux/firmware.h>
> #include <linux/mfd/intel-m10-bmc.h>
> #include <linux/mod_devicetable.h>
> +#include <linux/mm.h>
Why add this header file?
Thanks,
Yilun
> #include <linux/module.h>
> #include <linux/platform_device.h>
> #include <linux/slab.h>
> @@ -183,7 +184,7 @@ show_canceled_csk(struct device *dev, u32 addr, char *buf)
>
> bitmap_from_arr32(csk_map, csk32, CSK_BIT_LEN);
> bitmap_complement(csk_map, csk_map, CSK_BIT_LEN);
> - return bitmap_print_to_pagebuf(1, buf, csk_map, CSK_BIT_LEN);
> + return sysfs_emit(buf, "%*pbl\n", CSK_BIT_LEN, csk_map);
> }
>
> #define DEVICE_ATTR_SEC_CSK_RO(_name) \
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH v2 9/9] ARM: dts: qcom: msm8974: Drop RPM bus clocks
From: Konrad Dybcio @ 2026-03-24 9:40 UTC (permalink / raw)
To: Dmitry Baryshkov, Georgi Djakov, Konrad Dybcio, Bjorn Andersson,
Luca Weiss, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Brian Masney
Cc: linux-arm-msm, linux-pm, devicetree, linux-kernel
In-Reply-To: <20260324-msm8974-icc-v2-9-527280043ad8@oss.qualcomm.com>
On 3/24/26 1:10 AM, Dmitry Baryshkov wrote:
> Some nodes are abusingly referencing some of the internal bus clocks,
> that were recently removed in Linux (because the original implementation
> did not make much sense), managing them as if they were the only devices
> on an NoC bus.
>
> These clocks are now handled from within the icc framework and are
> no longer registered from within the CCF. Remove them.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 3/9] interconnect: qcom: drop unused is_on flag
From: Konrad Dybcio @ 2026-03-24 9:40 UTC (permalink / raw)
To: Dmitry Baryshkov, Georgi Djakov, Konrad Dybcio, Bjorn Andersson,
Luca Weiss, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Brian Masney
Cc: linux-arm-msm, linux-pm, devicetree, linux-kernel
In-Reply-To: <20260324-msm8974-icc-v2-3-527280043ad8@oss.qualcomm.com>
On 3/24/26 1:10 AM, Dmitry Baryshkov wrote:
> The commit 2e2113c8a64f ("interconnect: qcom: rpm: Handle interface
> clocks") has added the is_on flag to the qcom_icc_provider, but failed
> to actually utilize it. Drop the flag.
>
> Fixes: 2e2113c8a64f ("interconnect: qcom: rpm: Handle interface clocks")
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: st: spear: fix dtbs warning on spear thermal sensor
From: Daniel Baluta @ 2026-03-24 10:00 UTC (permalink / raw)
To: Krzysztof Kozlowski, Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, simona.toaca, d-gole, m-chawdhry
In-Reply-To: <20260324-smoky-radical-hyrax-1274a9@quoll>
On 3/24/26 11:26, Krzysztof Kozlowski wrote:
> On Mon, Mar 23, 2026 at 07:08:09PM +0530, Gopi Krishna Menon wrote:
>> Running DTBS checks on st/spear1340-evb.dtb results in the following
>> warning:
>>
>> thermal@e07008c4 (st,thermal-spear1340): Unevaluated properties are not allowed ('thermal_flags' was unexpected)
>> from schema $id: http://devicetree.org/schemas/thermal/st,thermal-spear1340.yaml
> How is it possible if there is no such file?
>
> Did you just add new warning in patch #1 and then claim in patch #2 that
> you fix it?
>
> You completely miss the point why this change is needed: how could the
> DTS work before? It could not. And that should be your justification for
> the patch, with explanation why it could not work.
Correct me if I'm wrong but I think there was a hidden bug here
drivers/thermal/spear_thermal.c:spear_thermal_probe:
if (!np || !of_property_read_u32(np, "st,thermal-flags", &val)) {
» » dev_err(&pdev->dev, "Failed: DT Pdata not passed\n");
» » return -EINVAL;
» }
So, the driver was checking for the correct property as pointed by
bindings/thermal/spear-thermal.txt but the dts was using the wrong
property name: arch/arm/boot/dts/st/spear13xx.dtsi » » » thermal@e07008c4 { » » » » compatible = "st,thermal-spear1340"; » » » » reg = <0xe07008c4 0x4>; » » » » thermal_flags = <0x7000>; » » » }; And because this check is wrong:
if (!np || !of_property_read_u32(np, "st,thermal-flags", &val)) {
people really didn't notice it.
The check should be:
if (!np || of_property_read_u32(np, "st,thermal-flags", &val)) {
» » dev_err(&pdev->dev, "Failed: DT Pdata not passed\n");
» » return -EINVAL;
» }
So, this actual patch has uncovered a bug!
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: st: spear: fix dtbs warning on spear thermal sensor
From: Krzysztof Kozlowski @ 2026-03-24 10:01 UTC (permalink / raw)
To: Daniel Baluta, Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, simona.toaca, d-gole, m-chawdhry
In-Reply-To: <cd3400ce-295e-450f-b650-6715142ccbde@nxp.com>
On 24/03/2026 11:00, Daniel Baluta wrote:
> On 3/24/26 11:26, Krzysztof Kozlowski wrote:
>> On Mon, Mar 23, 2026 at 07:08:09PM +0530, Gopi Krishna Menon wrote:
>>> Running DTBS checks on st/spear1340-evb.dtb results in the following
>>> warning:
>>>
>>> thermal@e07008c4 (st,thermal-spear1340): Unevaluated properties are not allowed ('thermal_flags' was unexpected)
>>> from schema $id: http://devicetree.org/schemas/thermal/st,thermal-spear1340.yaml
>> How is it possible if there is no such file?
>>
>> Did you just add new warning in patch #1 and then claim in patch #2 that
>> you fix it?
>>
>> You completely miss the point why this change is needed: how could the
>> DTS work before? It could not. And that should be your justification for
>> the patch, with explanation why it could not work.
>
> Correct me if I'm wrong but I think there was a hidden bug here
>
> drivers/thermal/spear_thermal.c:spear_thermal_probe:
>
> if (!np || !of_property_read_u32(np, "st,thermal-flags", &val)) {
> » » dev_err(&pdev->dev, "Failed: DT Pdata not passed\n");
> » » return -EINVAL;
> » }
>
> So, the driver was checking for the correct property as pointed by
Yes
>
> bindings/thermal/spear-thermal.txt but the dts was using the wrong
No, DTS had two properties - correct one and incorrect.
>
> property name: arch/arm/boot/dts/st/spear13xx.dtsi » » » thermal@e07008c4 { » » » » compatible = "st,thermal-spear1340"; » » » » reg = <0xe07008c4 0x4>; » » » » thermal_flags = <0x7000>; » » » }; And because this check is wrong:
>
> if (!np || !of_property_read_u32(np, "st,thermal-flags", &val)) {
>
> people really didn't notice it.
>
> The check should be:
>
> if (!np || of_property_read_u32(np, "st,thermal-flags", &val)) {
> » » dev_err(&pdev->dev, "Failed: DT Pdata not passed\n");
> » » return -EINVAL;
> » }
>
> So, this actual patch has uncovered a bug!
Yes. Driver also has bug, so probably was never working. The point is
whatever commit is doing, the dtbs_check warning is not the
justification, because it was introduced by this patchset.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH 1/2] thermal/cpufreq_cooling: remove unused cpu_idx in get_load()
From: Lukasz Luba @ 2026-03-24 10:46 UTC (permalink / raw)
To: Xuewen Yan
Cc: Viresh Kumar, Xuewen Yan, rui.zhang, rafael, linux-pm,
amit.kachhap, daniel.lezcano, linux-kernel, ke.wang, di.shen,
jeson.gao
In-Reply-To: <CAB8ipk_7MGUza9_izMypMxPFUjAoB34ZZp0-ts4w6eJ+tr+MDw@mail.gmail.com>
On 3/24/26 02:20, Xuewen Yan wrote:
> On Mon, Mar 23, 2026 at 9:25 PM Lukasz Luba <lukasz.luba@arm.com> wrote:
>>
>>
>>
>> On 3/23/26 11:06, Viresh Kumar wrote:
>>> On 23-03-26, 10:52, Lukasz Luba wrote:
>>>>> How is that okay ? What am I missing ?
>>>
>>> I was missing !SMP :)
>>>
>>>> Right, there is a mix of two things.
>>>> The 'i' left but should be removed as well, since
>>>> this is !SMP code with only 1 cpu and i=0.
>
> That's also why we sent out patch 1/2; after all, it is always 0 on
> !SMP systems.
>
>>>>
>>>> The whole split which has been made for getting
>>>> the load or utilization from CPU(s) needs to be
>>>> cleaned. The compiled code looks different since
>>>> it knows there is non-SMP config used.
>>>
>>> Right, we are allocating that for num_cpus (which should be 1 CPU
>>> anyway). The entire thing must be cleaned.
>>>
>>>> Do you want to clean that or I should do this?
>>>
>>> It would be helpful if you can do it :)
>>>
>>
>> OK, I will. Thanks for your involvement Viresh!
>>
>> Xuewen please wait with your v2, I will send
>> a redesign of this left code today.
>
> Okay, and Qais's point is also worth considering: do we actually need
> sched_cpu_util()?
> The way I see it, generally speaking, the request_power derived from
> idle_time might be higher than what we get from sched_cpu_util().
> Take this scenario as an example:
> Consider a CPU running at the lowest frequency with 50% idle time,
> versus one running at the highest frequency with the same 50% idle
> time.
> In this case, using idle_time yields the same load value for both.
> However, sched_cpu_util() would report a lower load when the CPU
> frequency is low. This results in a smaller request_power...
Right, there are 2 things to consider:
1. what is the utilization when the CPU still have idle time, e.g.
this 50% that you mentioned
2. what is the utilization when there is no idle time and CPU
is fully busy (and starts throttling due to heat)
In this thermal fwk we are mostly in the 2nd case. In that case the
utilization on CPU's runqueue goes to 1024 no mater the CPU's frequency.
We know which highest frequency was allowed to run and we pick the power
value from EM for it. That's why the estimation is not that bad (apart
from power variation for different flavors of workloads: heavy SIMD vs.
normal integer/load).
In 1st case scenario we might underestimate the power, but that
is not the thermal stress situation anyway, so the max OPP is
still allowed.
So far it is hard to find the best power model to use and robust CPU
load mechanisms. Adding more complexity and creating some
over-engineered code in the kernel to maintain might not have sense.
The thermal solutions are solved in the Firmware nowadays since the
kernel won't react that fast for some rapid changes.
We have to balance the complexity here.
Let's improve the situation a bit. It would be very much appreciated if
you could share information if those changes help your platform
(some older boards might not show any benefit with the new code).
Regards,
Lukasz
^ permalink raw reply
* Re: [PATCH v2 4/9] interconnect: qcom: icc-rpm: allow overwriting get_bw callback
From: Konrad Dybcio @ 2026-03-24 10:54 UTC (permalink / raw)
To: Dmitry Baryshkov, Georgi Djakov, Konrad Dybcio, Bjorn Andersson,
Luca Weiss, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Brian Masney
Cc: linux-arm-msm, linux-pm, devicetree, linux-kernel
In-Reply-To: <20260324-msm8974-icc-v2-4-527280043ad8@oss.qualcomm.com>
On 3/24/26 1:10 AM, Dmitry Baryshkov wrote:
> MSM8974 requires a separate get_bw callback, since on that platform
> increasing the clock rate for some of the NoCs during boot may lead to
> hangs. For the details see commit 9caf2d956cfa ("interconnect: qcom:
> msm8974: Don't boost the NoC rate during boot").
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 0/9] interconnect: qcom: let MSM8974 interconnect work again
From: Luca Weiss @ 2026-03-24 11:04 UTC (permalink / raw)
To: Alexandre Messier, Dmitry Baryshkov, Georgi Djakov, Konrad Dybcio,
Bjorn Andersson, Luca Weiss, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Brian Masney
Cc: linux-arm-msm, linux-pm, devicetree, linux-kernel, Brian Masney,
Konrad Dybcio
In-Reply-To: <b09a51bf-26b8-4c88-ab23-c92ddc1fb801@me.ssier.org>
On Tue Mar 24, 2026 at 3:09 AM CET, Alexandre Messier wrote:
> On 2026-03-23 20:10, Dmitry Baryshkov wrote:
>> Commit d6edc31f3a68 ("clk: qcom: smd-rpm: Separate out interconnect bus
>> clocks") moved control over several RPM resources from the clk-smd-rpm
>> driver to the icc-rpm.c interconnect helpers. Most of the platforms were
>> fixed before that commit or shortly after. However the MSM8974 was left
>> as a foster child in broken state. Fix the loose ends and reenable
>> interconnects on that platform.
>>
>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>> ---
>> Changes in v2:
>> - Swapped order of clocks and clock-names properties (Konrad)
>> - Corrected the ocmem comment regarding core clock (Konrad)
>> - Link to v1: https://lore.kernel.org/r/20260323-msm8974-icc-v1-0-7892b8d5f2ea@oss.qualcomm.com
>>
>> ---
>> Dmitry Baryshkov (9):
>> dt-bindings: interconnect: qcom,msm8974: drop bus clocks
>> dt-bindings: interconnect: qcom,msm8974: use qcom,rpm-common
>> interconnect: qcom: drop unused is_on flag
>> interconnect: qcom: icc-rpm: allow overwriting get_bw callback
>> interconnect: qcom: define OCMEM bus resource
>> interconnect: qcom: let platforms declare their bugginess
>> interconnect: qcom: msm8974: switch to the main icc-rpm driver
>> interconnect: qcom: msm8974: expand DEFINE_QNODE macros
>> ARM: dts: qcom: msm8974: Drop RPM bus clocks
>>
>> .../bindings/interconnect/qcom,msm8974.yaml | 28 +-
>> arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 21 +-
>> drivers/interconnect/qcom/icc-rpm-clocks.c | 6 +
>> drivers/interconnect/qcom/icc-rpm.c | 18 +-
>> drivers/interconnect/qcom/icc-rpm.h | 7 +-
>> drivers/interconnect/qcom/msm8974.c | 1637 +++++++++++++++-----
>> 6 files changed, 1274 insertions(+), 443 deletions(-)
>> ---
>> base-commit: 8e5a478b6d6a5bb0a3d52147862b15e4d826af19
>> change-id: 20260322-msm8974-icc-0ac4c28e139a
>>
>> Best regards,
>> --
>> With best wishes
>> Dmitry
>>
>>
>
> Tried this patch series on top of 7.0-rc5, using "htc,m8", and can confirm the device boots properly now!
Thanks for testing!
> I do see these messages in the kernel log now:
>
> [ 0.692540] ocmem fdd00000.sram: error -ENOENT: Unable to get core clock
> [ 0.692582] ocmem fdd00000.sram: probe with driver ocmem failed with error -2
> [ 24.173125] mmcc-msm8974 fd8c0000.clock-controller: sync_state() pending due to fdd00000.sram
For that you need this patch series
https://lore.kernel.org/linux-arm-msm/20260323-ocmem-v1-0-ad9bcae44763@oss.qualcomm.com/t/
Then ocmem probes again correctly:
[ 0.859855] ocmem fdd00000.sram: 8 ports, 3 regions, 24 macros, interleaved
Regards
Luca
^ permalink raw reply
* Re: [PATCH v2 0/9] interconnect: qcom: let MSM8974 interconnect work again
From: Luca Weiss @ 2026-03-24 11:07 UTC (permalink / raw)
To: Dmitry Baryshkov, Georgi Djakov, Konrad Dybcio, Bjorn Andersson,
Luca Weiss, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Brian Masney
Cc: linux-arm-msm, linux-pm, devicetree, linux-kernel, Brian Masney,
Konrad Dybcio
In-Reply-To: <20260324-msm8974-icc-v2-0-527280043ad8@oss.qualcomm.com>
On Tue Mar 24, 2026 at 1:10 AM CET, Dmitry Baryshkov wrote:
> Commit d6edc31f3a68 ("clk: qcom: smd-rpm: Separate out interconnect bus
> clocks") moved control over several RPM resources from the clk-smd-rpm
> driver to the icc-rpm.c interconnect helpers. Most of the platforms were
> fixed before that commit or shortly after. However the MSM8974 was left
> as a foster child in broken state. Fix the loose ends and reenable
> interconnects on that platform.
Thanks for taking the time to fix this, really appreciate it! I've been
carrying a partial revert of Konrad's commit for a while to get things
moving again, without taking the time to properly fix this.
I can confirm that my msm8974 phone boots fine on v7.0-rc5 with this
series and your ocmem series applied. Not much possible to test on
display/GPU since that was broken since a few releases ago. I will
probably be applying this on 6.15/6.16 branch which still had
display+GPU support.
Tested-by: Luca Weiss <luca.weiss@fairphone.com> # fairphone-fp2
Regards
Luca
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> Changes in v2:
> - Swapped order of clocks and clock-names properties (Konrad)
> - Corrected the ocmem comment regarding core clock (Konrad)
> - Link to v1: https://lore.kernel.org/r/20260323-msm8974-icc-v1-0-7892b8d5f2ea@oss.qualcomm.com
>
> ---
> Dmitry Baryshkov (9):
> dt-bindings: interconnect: qcom,msm8974: drop bus clocks
> dt-bindings: interconnect: qcom,msm8974: use qcom,rpm-common
> interconnect: qcom: drop unused is_on flag
> interconnect: qcom: icc-rpm: allow overwriting get_bw callback
> interconnect: qcom: define OCMEM bus resource
> interconnect: qcom: let platforms declare their bugginess
> interconnect: qcom: msm8974: switch to the main icc-rpm driver
> interconnect: qcom: msm8974: expand DEFINE_QNODE macros
> ARM: dts: qcom: msm8974: Drop RPM bus clocks
>
> .../bindings/interconnect/qcom,msm8974.yaml | 28 +-
> arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 21 +-
> drivers/interconnect/qcom/icc-rpm-clocks.c | 6 +
> drivers/interconnect/qcom/icc-rpm.c | 18 +-
> drivers/interconnect/qcom/icc-rpm.h | 7 +-
> drivers/interconnect/qcom/msm8974.c | 1637 +++++++++++++++-----
> 6 files changed, 1274 insertions(+), 443 deletions(-)
> ---
> base-commit: 8e5a478b6d6a5bb0a3d52147862b15e4d826af19
> change-id: 20260322-msm8974-icc-0ac4c28e139a
>
> Best regards,
> --
> With best wishes
> Dmitry
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: clock: qcom,milos-camcc: Document interconnect path
From: Konrad Dybcio @ 2026-03-24 11:13 UTC (permalink / raw)
To: Mike Tipton
Cc: Krzysztof Kozlowski, Luca Weiss, Taniya Das, Georgi Djakov,
Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, ~postmarketos/upstreaming,
phone-devel, linux-pm, linux-kernel, linux-arm-msm, linux-clk,
devicetree
In-Reply-To: <acH7aEBvSbiNwhBz@hu-mdtipton-lv.qualcomm.com>
On 3/24/26 3:48 AM, Mike Tipton wrote:
> On Mon, Jan 19, 2026 at 11:28:07AM +0100, Konrad Dybcio wrote:
>>
>>
>> On 1/19/26 11:20 AM, Konrad Dybcio wrote:
>>> On 1/17/26 12:46 PM, Krzysztof Kozlowski wrote:
>>>> On Fri, Jan 16, 2026 at 02:17:21PM +0100, Luca Weiss wrote:
>>>>> Document an interconnect path for camcc that's required to enable
>>>>> the CAMSS_TOP_GDSC power domain.
>>>>
>>>> I find it confusing. Enabling GDSC power domains is done via power
>>>> domains, not via interconnects. Do not represent power domains as
>>>> interconnects, it's something completely different.
>>>
>>> The name of the power domains is CAMSS_TOP_GDSC (seems you misread)
>>>
>>> For the power domain to successfully turn on, the MNoC needs to be
>>> turned on (empirical evidence). The way to do it is to request a
>>> nonzero vote on this interconnect path
>>>
>>> (presumably because the GDSC or its invisible providers require
>>> something connected over that bus to carry out their enable sequences).
>
> The GDSC itself shouldn't depend on MMNOC in order to turn on properly.
> It should turn on just fine without it. There *is* a dependency between
> CAM_TOP_GDSC and MMNOC, but it's in the opposite direction.
>
> For MMNOC to turn off properly when all BW votes are removed, the
> CAM_TOP_GDSC must already be off. If CAM_TOP_GDSC is still on when MMNOC
> starts turning off, then MMNOC will get stuck in its collapse sequence.
> MMNOC waits for all HW clients to de-assert their active signals before
> it'll allow itself to collapse. Most HW blocks assert this active signal
> more dynamically than camera does rather than tying it to GDSC state.
> The GDSC asserting active signals to RPMh that prevent NOC collapse is
> unique to this particular camera GDSC.
>
> If MMNOC BW is removed when CAM_TOP_GDSC is still enabled, then it
> should reproduce as an icc_set_bw() failure on MMNOC rather than a GDSC
> enable failure. The icc_set_bw(0) request would succeed because RPMh
> immediately ACKs down requests, but the collapse sequence would get
> stuck in the background. Later, when someone calls icc_set_bw() again
> with a non-zero BW to enable MMNOC, then that request would fail because
> MMNOC is still stuck in the prior collapse sequence.
>
> Note I haven't explicitly confirmed the Milos behavior, but this has
> been the HW dependency for at least several generations of chips now.
> I've never seen this GDSC get stuck turning on because MMNOC if off, nor
> would I be able to explain offhand why that would happen. But MMNOC
> certainly does depend on this GDSC for the reasons stated above.
In case that helps, I believe Luca originally observed that keeping the
display on, specifically voting on the:
&mmss_noc MASTER_MDP <-> &mc_virt SLAVE_EBI1
path made the GDSC power on successfully, lacking that made the problem
come back
The nodes that are hit on the way are:
qnm_mdp (mmss_noc)
qns_mem_noc_hf (mmss_noc)
qnm_mnoc_hf (gem_noc)
qns_llcc (gem_noc)
llcc_mc (mc_virt)
ebi (mc_virt)
That translates into
mmss_noc -> MM0, MM1
gem_noc -> SH0, SH1
mc_virt -> ACV, MC0
Notably, all of the foo_camnoc_bar nodes reside on mmss_noc as well.
May it be that voting on them ungates a clock that (perhaps recursively)
feeds the GDSC?
Because the platform is not suspended, the latter two buses are already
online, so I'd assume it's one of the MM BCMs that's causing something
I can't see any details about its inputs.. In case that's useful, the
GCC driver enables the following camera branches as always-on:
GCC_CAMERA_AHB_CLK
GCC_CAMERA_HF_XO_CLK
GCC_CAMERA_SF_XO_CLK
Konrad
^ permalink raw reply
* Re: [PATCH 4/9] interconnect: qcom: icc-rpm: allow overwriting get_bw callback
From: Konrad Dybcio @ 2026-03-24 11:34 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Georgi Djakov, Konrad Dybcio, Bjorn Andersson, Luca Weiss,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Brian Masney,
linux-arm-msm, linux-pm, devicetree, linux-kernel
In-Reply-To: <75zgkrwvjsmnvjeyosl326vcudklj6yhhyskdrsm23kbzhgve3@64nezs6c54kz>
On 3/24/26 12:14 AM, Dmitry Baryshkov wrote:
> On Mon, Mar 23, 2026 at 11:32:33AM +0100, Konrad Dybcio wrote:
>> On 3/23/26 2:17 AM, Dmitry Baryshkov wrote:
>>> MSM8974 requires a separate get_bw callback, since on that platform
>>> increasing the clock rate for some of the NoCs during boot may lead to
>>> hangs. For the details see commit 9caf2d956cfa ("interconnect: qcom:
>>> msm8974: Don't boost the NoC rate during boot").
>>
>> Is there a single specific bus where this causes an issue, or is
>> setting *any* resource to INT_MAX problematic?
>
> I'd refer this to Luca. I didn't experiment that much (and also note,
> this behaviour might be firmware-specific).
In case anyone's interested, it _seems like_ it's
(RPM_KEY_BW + RPM_BUS_MASTER_REQ/RPM_BUS_SLAVE_REQ) failing with certain
nodes
> My goal for this patchset was to port as close as possible. We can drop
> the get_bw later, after enabling more interconnects, writing the QoS,
> etc.
That's fine
Konrad
^ permalink raw reply
* [PATCH v5 00/11] Add support for the TI BQ25792 battery charger
From: Alexey Charkov @ 2026-03-24 11:38 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Morgan, Liam Girdwood, Mark Brown, Sebastian Reichel
Cc: devicetree, linux-kernel, Sebastian Reichel, linux-pm,
Alexey Charkov, Krzysztof Kozlowski, stable
This adds support for the TI BQ25792 battery charger, which is similar in
overall logic to the BQ25703A, but has a different register layout and
slightly different lower-level programming logic.
The series is organized as follows:
- Patch 1 adds the new variant to the existing DT binding, including the
changes in electrical characteristics
- Patches 2-4 are minor cleanups to the existing BQ25703A OTG regulator
driver, slimming down the code and making it more reusable for the new
BQ25792 variant
- Patch 5 is a logical fix to the BQ25703A clamping logic for VSYSMIN
(this is a standalone fix which can be applied independently and may be
backported to stable)
- Patches 6-8 are slight refactoring of the existing BQ25703A charger
driver to make it more reusable for the new BQ25792 variant
- Patch 9 adds platform data to distinguish between the two variants in
the parent MFD driver, and binds it to the new compatible string
- Patches 10-11 add variant-specific code to support the new BQ25792
variant in the regulator part and the charger part respectively,
selected by the platform data added in patch 9
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
Changes in v5:
- Added non-OF match data and switched to i2c_get_match_data() to support
non-OF platforms (Lee Jones)
- Shifted the types in the enum to start at 1 to avoid confusion with
zero-initialized data and non-match cases (Lee Jones)
- Reinstated the const qualifier on the MFD cell array (Lee Jones)
- Link to v4: https://lore.kernel.org/r/20260311-bq25792-v4-0-7213415d9eec@flipper.net
Changes in v4:
- Avoid additional data structures and pass 'type' within the existing
struct bq257xx_device instead (Lee Jones)
- Move comments for new struct fields to the patches where those fields
are added (Sebastian Reichel)
- Collect tags from Sebastian Reichel (thanks!)
- Link to v3: https://lore.kernel.org/r/20260310-bq25792-v3-0-02f8e232d63b@flipper.net
Changes in v3:
- Move MFD cell definitions back out of the probe function (Lee Jones)
- Collect tags from Mark Brown, Krzysztof Kozlowski and Chris Morgan (thanks!)
- Enable ship FET functionality at init for BQ25792
- Link to v2: https://lore.kernel.org/r/20260306-bq25792-v2-0-6595249d6e6f@flipper.net
Changes in v2:
- Fix an error in DT schema (thanks Rob's bot)
- Ensure the broadest constraints for all variants remain in the common
part of the schema, per writing-schema doc (thanks Krzysztof)
- Link to v1: https://lore.kernel.org/r/20260303-bq25792-v1-0-e6e5e0033458@flipper.net
---
Alexey Charkov (11):
dt-bindings: mfd: ti,bq25703a: Expand to include BQ25792
regulator: bq257xx: Remove reference to the parent MFD's dev
regulator: bq257xx: Drop the regulator_dev from the driver data
regulator: bq257xx: Make OTG enable GPIO really optional
power: supply: bq257xx: Fix VSYSMIN clamping logic
power: supply: bq257xx: Make the default current limit a per-chip attribute
power: supply: bq257xx: Consistently use indirect get/set helpers
power: supply: bq257xx: Add fields for 'charging' and 'overvoltage' states
mfd: bq257xx: Add BQ25792 support
regulator: bq257xx: Add support for BQ25792
power: supply: bq257xx: Add support for BQ25792
.../devicetree/bindings/mfd/ti,bq25703a.yaml | 73 ++-
drivers/mfd/bq257xx.c | 54 ++-
drivers/power/supply/bq257xx_charger.c | 534 ++++++++++++++++++++-
drivers/regulator/bq257xx-regulator.c | 121 ++++-
include/linux/mfd/bq257xx.h | 412 ++++++++++++++++
5 files changed, 1156 insertions(+), 38 deletions(-)
---
base-commit: 09c0f7f1bcdbc3c37a5a760cbec76bf18f278406
change-id: 20260303-bq25792-0132ac86846d
Best regards,
--
Alexey Charkov <alchark@flipper.net>
^ permalink raw reply
* [PATCH v5 01/11] dt-bindings: mfd: ti,bq25703a: Expand to include BQ25792
From: Alexey Charkov @ 2026-03-24 11:38 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Morgan, Liam Girdwood, Mark Brown, Sebastian Reichel
Cc: devicetree, linux-kernel, Sebastian Reichel, linux-pm,
Alexey Charkov, Krzysztof Kozlowski
In-Reply-To: <20260324-bq25792-v5-0-0a2eb58cf11d@flipper.net>
TI BQ25792 is similar in operation to BQ25703A, but has a different
register layout and different current/voltage capabilities.
Expand the existing BQ25703A binding to include BQ25792, and move the
voltage and current limits into per-variant conditional statements.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Tested-by: Chris Morgan <macromorgan@hotmail.com>
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
.../devicetree/bindings/mfd/ti,bq25703a.yaml | 73 +++++++++++++++++++---
1 file changed, 63 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/ti,bq25703a.yaml b/Documentation/devicetree/bindings/mfd/ti,bq25703a.yaml
index ba14663c9266..cdce83f05804 100644
--- a/Documentation/devicetree/bindings/mfd/ti,bq25703a.yaml
+++ b/Documentation/devicetree/bindings/mfd/ti,bq25703a.yaml
@@ -4,17 +4,16 @@
$id: http://devicetree.org/schemas/mfd/ti,bq25703a.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: BQ25703A Charger Manager/Buck/Boost Converter
+title: BQ257xx Charger Manager/Buck/Boost Converter
maintainers:
- Chris Morgan <macromorgan@hotmail.com>
-allOf:
- - $ref: /schemas/power/supply/power-supply.yaml#
-
properties:
compatible:
- const: ti,bq25703a
+ enum:
+ - ti,bq25703a
+ - ti,bq25792
reg:
const: 0x6b
@@ -25,7 +24,6 @@ properties:
powering the device.
minimum: 50000
maximum: 6400000
- default: 3250000
interrupts:
maxItems: 1
@@ -57,11 +55,11 @@ properties:
minimum: 0
maximum: 6350000
regulator-min-microvolt:
- minimum: 4480000
- maximum: 20800000
+ minimum: 2800000
+ maximum: 22000000
regulator-max-microvolt:
- minimum: 4480000
- maximum: 20800000
+ minimum: 2800000
+ maximum: 22000000
enable-gpios:
description:
The BQ25703 may require both a register write and a GPIO
@@ -74,6 +72,61 @@ properties:
- regulator-min-microvolt
- regulator-max-microvolt
+allOf:
+ - $ref: /schemas/power/supply/power-supply.yaml#
+ - if:
+ properties:
+ compatible:
+ const: ti,bq25703a
+ then:
+ properties:
+ input-current-limit-microamp:
+ minimum: 50000
+ maximum: 6400000
+ default: 3250000
+ regulators:
+ properties:
+ vbus:
+ properties:
+ regulator-min-microamp:
+ minimum: 0
+ maximum: 6350000
+ regulator-max-microamp:
+ minimum: 0
+ maximum: 6350000
+ regulator-min-microvolt:
+ minimum: 4480000
+ maximum: 20800000
+ regulator-max-microvolt:
+ minimum: 4480000
+ maximum: 20800000
+ - if:
+ properties:
+ compatible:
+ const: ti,bq25792
+ then:
+ properties:
+ input-current-limit-microamp:
+ minimum: 100000
+ maximum: 3300000
+ default: 3000000
+ regulators:
+ properties:
+ vbus:
+ properties:
+ regulator-min-microamp:
+ minimum: 0
+ maximum: 3320000
+ regulator-max-microamp:
+ minimum: 0
+ maximum: 3320000
+ regulator-min-microvolt:
+ minimum: 2800000
+ maximum: 22000000
+ regulator-max-microvolt:
+ minimum: 2800000
+ maximum: 22000000
+
unevaluatedProperties: false
required:
--
2.52.0
^ permalink raw reply related
* [PATCH v5 02/11] regulator: bq257xx: Remove reference to the parent MFD's dev
From: Alexey Charkov @ 2026-03-24 11:38 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Morgan, Liam Girdwood, Mark Brown, Sebastian Reichel
Cc: devicetree, linux-kernel, Sebastian Reichel, linux-pm,
Alexey Charkov
In-Reply-To: <20260324-bq25792-v5-0-0a2eb58cf11d@flipper.net>
Drop the ->bq field from the platform data of the bq257xx regulator driver,
which was only used to get the regmap of the parent MFD device, and use the
regmap from the regulator_dev instead, slimming down the code a bit.
Acked-by: Mark Brown <broonie@kernel.org>
Tested-by: Chris Morgan <macromorgan@hotmail.com>
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
drivers/regulator/bq257xx-regulator.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/regulator/bq257xx-regulator.c b/drivers/regulator/bq257xx-regulator.c
index dab8f1ab4450..812938e565e3 100644
--- a/drivers/regulator/bq257xx-regulator.c
+++ b/drivers/regulator/bq257xx-regulator.c
@@ -15,7 +15,6 @@
#include <linux/regulator/of_regulator.h>
struct bq257xx_reg_data {
- struct bq257xx_device *bq;
struct regulator_dev *bq257xx_reg;
struct gpio_desc *otg_en_gpio;
struct regulator_desc desc;
@@ -23,11 +22,11 @@ struct bq257xx_reg_data {
static int bq25703_vbus_get_cur_limit(struct regulator_dev *rdev)
{
- struct bq257xx_reg_data *pdata = rdev_get_drvdata(rdev);
+ struct regmap *regmap = rdev_get_regmap(rdev);
int ret;
unsigned int reg;
- ret = regmap_read(pdata->bq->regmap, BQ25703_OTG_CURRENT, ®);
+ ret = regmap_read(regmap, BQ25703_OTG_CURRENT, ®);
if (ret)
return ret;
return FIELD_GET(BQ25703_OTG_CUR_MASK, reg) * BQ25703_OTG_CUR_STEP_UA;
@@ -40,7 +39,7 @@ static int bq25703_vbus_get_cur_limit(struct regulator_dev *rdev)
static int bq25703_vbus_set_cur_limit(struct regulator_dev *rdev,
int min_uA, int max_uA)
{
- struct bq257xx_reg_data *pdata = rdev_get_drvdata(rdev);
+ struct regmap *regmap = rdev_get_regmap(rdev);
unsigned int reg;
if ((min_uA > BQ25703_OTG_CUR_MAX_UA) || (max_uA < 0))
@@ -52,7 +51,7 @@ static int bq25703_vbus_set_cur_limit(struct regulator_dev *rdev,
if ((reg * BQ25703_OTG_CUR_STEP_UA) < min_uA)
return -EINVAL;
- return regmap_write(pdata->bq->regmap, BQ25703_OTG_CURRENT,
+ return regmap_write(regmap, BQ25703_OTG_CURRENT,
FIELD_PREP(BQ25703_OTG_CUR_MASK, reg));
}
@@ -137,7 +136,6 @@ static void bq257xx_reg_dt_parse_gpio(struct platform_device *pdev)
static int bq257xx_regulator_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- struct bq257xx_device *bq = dev_get_drvdata(pdev->dev.parent);
struct bq257xx_reg_data *pdata;
struct device_node *np = dev->of_node;
struct regulator_config cfg = {};
@@ -149,7 +147,6 @@ static int bq257xx_regulator_probe(struct platform_device *pdev)
if (!pdata)
return -ENOMEM;
- pdata->bq = bq;
pdata->desc = bq25703_vbus_desc;
platform_set_drvdata(pdev, pdata);
--
2.52.0
^ permalink raw reply related
* [PATCH v5 03/11] regulator: bq257xx: Drop the regulator_dev from the driver data
From: Alexey Charkov @ 2026-03-24 11:38 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Morgan, Liam Girdwood, Mark Brown, Sebastian Reichel
Cc: devicetree, linux-kernel, Sebastian Reichel, linux-pm,
Alexey Charkov
In-Reply-To: <20260324-bq25792-v5-0-0a2eb58cf11d@flipper.net>
The field was not used anywhere in the driver, so just drop it. This helps
further slim down the platform data structure.
Acked-by: Mark Brown <broonie@kernel.org>
Tested-by: Chris Morgan <macromorgan@hotmail.com>
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
drivers/regulator/bq257xx-regulator.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/bq257xx-regulator.c b/drivers/regulator/bq257xx-regulator.c
index 812938e565e3..674dae6109e9 100644
--- a/drivers/regulator/bq257xx-regulator.c
+++ b/drivers/regulator/bq257xx-regulator.c
@@ -15,7 +15,6 @@
#include <linux/regulator/of_regulator.h>
struct bq257xx_reg_data {
- struct regulator_dev *bq257xx_reg;
struct gpio_desc *otg_en_gpio;
struct regulator_desc desc;
};
@@ -139,6 +138,7 @@ static int bq257xx_regulator_probe(struct platform_device *pdev)
struct bq257xx_reg_data *pdata;
struct device_node *np = dev->of_node;
struct regulator_config cfg = {};
+ struct regulator_dev *rdev;
pdev->dev.of_node = pdev->dev.parent->of_node;
pdev->dev.of_node_reused = true;
@@ -159,9 +159,9 @@ static int bq257xx_regulator_probe(struct platform_device *pdev)
if (!cfg.regmap)
return -ENODEV;
- pdata->bq257xx_reg = devm_regulator_register(dev, &pdata->desc, &cfg);
- if (IS_ERR(pdata->bq257xx_reg)) {
- return dev_err_probe(&pdev->dev, PTR_ERR(pdata->bq257xx_reg),
+ rdev = devm_regulator_register(dev, &pdata->desc, &cfg);
+ if (IS_ERR(rdev)) {
+ return dev_err_probe(&pdev->dev, PTR_ERR(rdev),
"error registering bq257xx regulator");
}
--
2.52.0
^ permalink raw reply related
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