* [PATCH 5/5] cpufreq: ti: Add device link to k3-socinfo
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260330120105.2985200-1-a-kaur@ti.com>
Create explicit device link when OPP table has ti,soc-info property.
Prevents unbinding k3-socinfo while ti-cpufreq is using it.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
drivers/cpufreq/ti-cpufreq.c | 48 ++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
index 88f7912ef6a8..60c34b0da0c5 100644
--- a/drivers/cpufreq/ti-cpufreq.c
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -12,6 +12,7 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/of.h>
+#include <linux/of_platform.h>
#include <linux/platform_device.h>
#include <linux/pm_opp.h>
#include <linux/regmap.h>
@@ -111,6 +112,7 @@ struct ti_cpufreq_data {
struct device_node *opp_node;
struct regmap *syscon;
const struct ti_cpufreq_soc_data *soc_data;
+ struct device_link *soc_link;
};
static unsigned long amx3_efuse_xlate(struct ti_cpufreq_data *opp_data,
@@ -542,6 +544,7 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
return -ENOMEM;
opp_data->soc_data = match->data;
+ platform_set_drvdata(pdev, opp_data);
opp_data->cpu_dev = get_cpu_device(0);
if (!opp_data->cpu_dev) {
@@ -560,6 +563,42 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
if (ret)
goto fail_put_node;
+ /* Create device link to k3-socinfo if specified in DT */
+ if (opp_data->soc_data == &am625_soc_data ||
+ opp_data->soc_data == &am62a7_soc_data ||
+ opp_data->soc_data == &am62l3_soc_data ||
+ opp_data->soc_data == &am62p5_soc_data) {
+ struct device_node *socinfo_np;
+
+ socinfo_np = of_parse_phandle(opp_data->opp_node, "ti,soc-info", 0);
+ if (socinfo_np) {
+ struct platform_device *socinfo_pdev;
+ struct device_link *link;
+
+ socinfo_pdev = of_find_device_by_node(socinfo_np);
+ of_node_put(socinfo_np);
+
+ if (!socinfo_pdev) {
+ ret = -EPROBE_DEFER;
+ goto fail_put_node;
+ }
+
+ if (!socinfo_pdev->dev.driver) {
+ put_device(&socinfo_pdev->dev);
+ ret = -EPROBE_DEFER;
+ goto fail_put_node;
+ }
+
+ link = device_link_add(opp_data->cpu_dev,
+ &socinfo_pdev->dev,
+ DL_FLAG_STATELESS);
+ if (link)
+ opp_data->soc_link = link;
+
+ put_device(&socinfo_pdev->dev);
+ }
+ }
+
/*
* OPPs determine whether or not they are supported based on
* two metrics:
@@ -600,6 +639,14 @@ static int ti_cpufreq_probe(struct platform_device *pdev)
return ret;
}
+static void ti_cpufreq_remove(struct platform_device *pdev)
+{
+ struct ti_cpufreq_data *opp_data = platform_get_drvdata(pdev);
+
+ if (opp_data && opp_data->soc_link)
+ device_link_del(opp_data->soc_link);
+}
+
static int __init ti_cpufreq_init(void)
{
const struct of_device_id *match;
@@ -616,6 +663,7 @@ module_init(ti_cpufreq_init);
static struct platform_driver ti_cpufreq_driver = {
.probe = ti_cpufreq_probe,
+ .remove = ti_cpufreq_remove,
.driver = {
.name = "ti-cpufreq",
},
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v8 04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children
From: Krzysztof Kozlowski @ 2026-03-30 12:10 UTC (permalink / raw)
To: André Draszik, Alim Akhtar, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, Ulf Hansson, Liam Girdwood, Mark Brown
Cc: Peter Griffin, Tudor Ambarus, Juan Yescas, Will McVicker,
kernel-team, linux-arm-kernel, linux-samsung-soc, devicetree,
linux-kernel, linux-pm
In-Reply-To: <dcf2c447d9bbe16e800a4dd7e74ecc26d3ade3db.camel@linaro.org>
On 30/03/2026 14:00, André Draszik wrote:
> On Sat, 2026-03-21 at 20:14 +0100, Krzysztof Kozlowski wrote:
>>
>> This causes warnings, so I dropped the patches.
>
> I assume warnings are because I didn't make it clear enough that patch
> 2 is actually required?
No, these are obvious errors coming from bindings. You can try yourself
instead of asking maintainer to run the commands for you...
>
>> I really do not
>> understand how this is organized. This is not a dependency for pm
>> domains driver but it is included here.
>
> The binding is being updated, and the driver follows suit.
> I particular, the driver needs to be aware that pd is (can be) a child
> of pmu.
>
> Yes, the driver does not depend on this binding update, but it shows what
> the driver must support. I believe this is what we have done in the past:
> binding and driver updates in same series.
Yes, foo-binding goes with foo-driver to foo-subsystem. It does not mean
you put here completely different bindings. Why? Because just like foo
goes to foo-subsystem, then bar-binding goes with bar-driver to
bar-subsystem.
>
> I could move patches 3 and 4 from this series together with a DTS
> update patch into a separate series, if that would be deemed a better
> approach?
I asked you what are the dependencies and you answer there are some but
you can move it outside of patchset. So are there or are there not
dependencies? If there are, then you cannot move out. But then I ask
what are the dependencies.
It feels like question to trick the maintainer. Maintainer complained,
so you propose whatever he objected to without understanding whether
this is correct or not correct approach.
>
>> It is a soft dependency for DTS,
>> but that is nowhere to be found.
>
> I was waiting for review of all binding changes before posting DTS.
That would be fine explanation, if you also read maintainer soc profile
for Samsung and try what is written there. You would see that you
introduced new warnings without any fix possible as far as next is
concerned.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Geert Uytterhoeven @ 2026-03-30 12:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Russell King, Christian Schrefl, Miguel Ojeda, Alice Ryhl,
Ard Biesheuvel, Jamie Cunliffe, Will Deacon, Catalin Marinas,
Miguel Ojeda, Andreas Hindborg, acourbot, Andrew Morton,
Anton Ivanov, Björn Roy Baron, Boqun Feng, Danilo Krummrich,
David Gow, Gary Guo, Johannes Berg, Justin Stitt,
linux-arm-kernel, linux-kbuild, linux-kernel, linux-mm, linux-um,
llvm, Benno Lossin, Mark Rutland, mmaurer, Bill Wendling,
Nathan Chancellor, Nick Desaulniers, Nicolas Schier,
Nicolas Schier, Peter Zijlstra, Richard Weinberger,
rust-for-linux, Trevor Gross, Uladzislau Rezki (Sony),
John Paul Adrian Glaubitz
In-Reply-To: <93439e91-cf81-477b-b880-a813bb01ad7c@app.fastmail.com>
Hi Arnd,
On Fri, 27 Mar 2026 at 10:02, Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Mar 27, 2026, at 08:56, Geert Uytterhoeven wrote:
> >> I noticed a similar issue with m68k-linux, which has a bitfield
> >> alignment different from anything else on gcc, but uses the normal
> >> behavior on clang.
> >
> > Ugh, I wasn't aware of that. Adrian, did you know?
>
> To clarify, this illustrates what I mean here:
>
> echo 'struct { short a : 3; short b :15; short c :14; } x; int y = sizeof(x);' | m68k-linux-gcc -xc - -S -o-
>
> this produces '4' on m68k-linux-gcc, but '6' everywhere else. I originally
> thought this was related to this 2009 change in both compilers
Oh, now I remember. AFAIK (holding wood and a rabbit leg) we don't
have any bitfield members spanning multiple base type instances in
the kernel.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Arnd Bergmann @ 2026-03-30 12:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King, Christian Schrefl, Miguel Ojeda, Alice Ryhl,
Ard Biesheuvel, Jamie Cunliffe, Will Deacon, Catalin Marinas,
Miguel Ojeda, Andreas Hindborg, acourbot, Andrew Morton,
Anton Ivanov, Björn Roy Baron, Boqun Feng, Danilo Krummrich,
David Gow, Gary Guo, Johannes Berg, Justin Stitt,
linux-arm-kernel, linux-kbuild, linux-kernel, linux-mm, linux-um,
llvm, Benno Lossin, Mark Rutland, mmaurer, Bill Wendling,
Nathan Chancellor, Nick Desaulniers, Nicolas Schier,
Nicolas Schier, Peter Zijlstra, Richard Weinberger,
rust-for-linux, Trevor Gross, Uladzislau Rezki (Sony),
John Paul Adrian Glaubitz
In-Reply-To: <CAMuHMdU-+dm83TVttfarT7QxE5ySpQ2LJ_k6oFKMWRcbaWcCdA@mail.gmail.com>
On Mon, Mar 30, 2026, at 14:03, Geert Uytterhoeven wrote:
> On Fri, 27 Mar 2026 at 10:02, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> echo 'struct { short a : 3; short b :15; short c :14; } x; int y = sizeof(x);' | m68k-linux-gcc -xc - -S -o-
>>
>> this produces '4' on m68k-linux-gcc, but '6' everywhere else. I originally
>> thought this was related to this 2009 change in both compilers
>
> Oh, now I remember. AFAIK (holding wood and a rabbit leg) we don't
> have any bitfield members spanning multiple base type instances in
> the kernel.
There are certainly very few of those, but two example I found in
UAPI are
struct dvd_layer {
__u8 book_version : 4;
__u8 book_type : 4;
__u8 min_rate : 4;
__u8 disc_size : 4;
__u8 layer_type : 4;
__u8 track_path : 1;
__u8 nlayers : 2;
__u8 track_density : 4; // crosses u8 boundary
__u8 linear_density : 4;
__u8 bca : 1;
__u32 start_sector;
__u32 end_sector;
__u32 end_sector_l0;
};
struct usb_raw_ep_caps {
__u32 type_control : 1;
__u32 type_iso : 1;
__u32 type_bulk : 1;
__u32 type_int : 1;
__u32 dir_in : 1;
__u32 dir_out : 1;
// 2 bit padding on m68k, 26 bits elsewhere
};
Arnd
^ permalink raw reply
* [PATCH v2] arm64: dts: amlogic: t7: khadas-vim4: Remove invalid property
From: Ronald Claveau @ 2026-03-30 12:11 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
kernel test robot, Krzysztof Kozlowski, Ronald Claveau
Fix introduced invalid property for Khadas VIM4 sdcard regulator.
arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: regulator-sdcard-3v3 (regulator-fixed): Unevaluated properties are not allowed ('enable-active-low' was unexpected)
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603290828.5gt393t6-lkp@intel.com/
Fixes: 60eff75ac67b ("arm64: dts: amlogic: t7: khadas-vim4: Add power regulators")
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Changes in v2:
- Add Fixes tag according to Krzysztof's review.
- Link to v1: https://lore.kernel.org/r/20260330-fix-invalid-property-v1-1-e829c4d806cb@aliel.fr
---
arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index 11bfbc99191b6..003b3bcdaf2bc 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -65,7 +65,6 @@ sd_3v3: regulator-sdcard-3v3 {
vin-supply = <&vddao_3v3>;
gpio = <&gpio GPIOD_11 GPIO_ACTIVE_LOW>;
regulator-boot-on;
- enable-active-low;
regulator-always-on;
};
---
base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
change-id: 20260330-fix-invalid-property-bbe54d933f71
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: ti: k3-am62p5: Add ti,soc-info to OPP table
From: Akashdeep Kaur @ 2026-03-30 12:01 UTC (permalink / raw)
To: praneeth, nm, vigneshr, kristo, robh, krzk+dt, conor+dt, rafael,
viresh.kumar, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, d-gole
Cc: vishalm, sebin.francis, k-willis, a-kaur
In-Reply-To: <20260330120105.2985200-1-a-kaur@ti.com>
Link CPU OPP table to k3-socinfo driver for dependency tracking.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62p5.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p5.dtsi b/arch/arm64/boot/dts/ti/k3-am62p5.dtsi
index 8982a7b9f1a6..1a498c5eb3d1 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p5.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p5.dtsi
@@ -108,6 +108,7 @@ a53_opp_table: opp-table {
compatible = "operating-points-v2-ti-cpu";
opp-shared;
syscon = <&opp_efuse_table>;
+ ti,soc-info = <&chipid>;
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 35/49] KVM: arm64: GICv3: nv: Plug L1 LR sync into deactivation primitive
From: Marc Zyngier @ 2026-03-30 12:17 UTC (permalink / raw)
To: Vishnu Pajjuri
Cc: Fuad Tabba, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Christoffer Dall, Mark Brown, kvm, linux-arm-kernel,
kvmarm
In-Reply-To: <2e12c5c2-a1b6-47b7-b54c-7281a77bbe0a@os.amperecomputing.com>
On Mon, 30 Mar 2026 12:51:51 +0100,
Vishnu Pajjuri <vishnu@os.amperecomputing.com> wrote:
>
> Hi Fuad Tabba,
To be brutally honest, I doubt Fuad really cares about NV,
> I'm trying to run nested VMs on Ampere platforms after this patch
> series(v6.19+) but nested VMs are not booting and triggering soft
> lockups on L0 and L0 hang. But just before this patch I could able to
> successfully boot the Nested VMs.
So the host dies? There isn't much here that interacts with the host
at all. Worse case, the L1 dies by not making progress.
>
> I bisected the failure to a single commit which is this patch which is
> causing the issue.
>
> I would like to understand from you that did you observed anything
> like that?
No. If I had, I wouldn't have merged the series.
>
> Were you able to boot Nested VMs successfully after v6.19+?
I boot L3s every day.
> LOG:
> [ 164.647367] Call trace:
> [ 164.647368] smp_call_function_many_cond+0x334/0x7a0 (P)
> [ 164.647372] smp_call_function_many+0x20/0x40
> [ 164.647374] kvm_make_all_cpus_request+0xec/0x1b8
> [ 164.647377] vgic_queue_irq_unlock+0x1c8/0x2c8
> [ 164.647380] kvm_vgic_inject_irq+0x194/0x1e0
> [ 164.647381] kvm_vm_ioctl_irq_line+0x170/0x400
> [ 164.647386] kvm_vm_ioctl+0x7b8/0xc88
> [ 164.647389] __arm64_sys_ioctl+0xb4/0x118
> [ 164.647393] invoke_syscall+0x6c/0x100
> [ 164.647397] el0_svc_common.constprop.0+0x48/0xf0
> [ 164.647398] do_el0_svc+0x24/0x38
> [ 164.647400] el0_svc+0x3c/0x170
> [ 164.647403] el0t_64_sync_handler+0xa0/0xe8
> [ 164.647405] el0t_64_sync+0x1b0/0x1b8
This trace is about interrupt injection from userspace, not
deactivation of a HW interrupt.
None of that makes much sense.
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH RFC net-next] net: stmmac: qcom-ethqos: set clk_csr
From: Russell King (Oracle) @ 2026-03-30 12:20 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Mohd Ayaan Anwar, Alexandre Torgue, Andrew Lunn, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, linux-arm-kernel,
linux-arm-msm, linux-stm32, netdev, Paolo Abeni
In-Reply-To: <9d0a529a-d065-4f46-a93b-23195a4f9727@oss.qualcomm.com>
On Mon, Mar 30, 2026 at 01:18:56PM +0200, Konrad Dybcio wrote:
> On 3/27/26 6:02 PM, Russell King (Oracle) wrote:
> > The clocks for qcom-ethqos return a rate of zero as firmware manages
> > their rate. According to hardware documentation, the clock which is
> > fed to the slave AHB interface can crange between 50 and 100MHz.
>
> FWIW this __may__ possibly differ between platforms, but I'm not sure
> to what degree. Will there be visible impact if we e.g. have a 200 or
> 300 MHz clock somewhere?
When you add other platforms, you're going to have to deal with their
differences.
IEEE 802.3 states that the maximum clock rate for the MDIO bus is
2.5MHz. You need to ensure that is the case.
Current qcom-ethqos code doesn't set clk_csr, and returns zero for
clk_get_rate() on the stmmac clocks because they are managed entirely
in firmware.
This leads to the GMII_Address register field CR "CSR Clock Range"
being programmed with a value of 15, which, according to some
documentation, states that the clock divisor is CSR clock / 18.
With the /18 divisor (assuming your dwmac uses that divisor):
CSR clock MDIO MDC clock rate
50MHz 2.78MHz (exceeds IEEE 802.3 maximum)
100MHz 5.56MHz (exceeds IEEE 802.3 maximum)
200MHz 11.1MHz (exceeds IEEE 802.3 maximum)
300MHz 16.7MHz (exceeds IEEE 802.3 maximum)
Do you think this is acceptable, or do you think this should be
fixed before anything else happens with the driver?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [RFC PATCH] dmaengine: xilinx_dma: Fix per-channel direction reporting via device_caps
From: Rahul Navale @ 2026-03-30 12:21 UTC (permalink / raw)
To: marex
Cc: Rahul Navale, dmaengine, dev, linux-arm-kernel, linux-kernel,
vkoul, Frank.Li, michal.simek, suraj.gupta2, thomas.gessler,
radhey.shyam.pandey, tomi.valkeinen, rahulnavale04, marex
In-Reply-To: <DGHGTCJRRZCW.9TGXQW44V6RR@folker-schwesinger.de>
From: Rahul Navale <rahul.navale@ifm.com>
Hello Marek,
>Can you please add [1] to the patch stack and let me know whether that
>improves the behavior ?
I added the patch to the patch stack and retested audio is working now.
Thank you for your support.
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Geert Uytterhoeven @ 2026-03-30 12:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Russell King, Christian Schrefl, Miguel Ojeda, Alice Ryhl,
Ard Biesheuvel, Jamie Cunliffe, Will Deacon, Catalin Marinas,
Miguel Ojeda, Andreas Hindborg, acourbot, Andrew Morton,
Anton Ivanov, Björn Roy Baron, Boqun Feng, Danilo Krummrich,
David Gow, Gary Guo, Johannes Berg, Justin Stitt,
linux-arm-kernel, linux-kbuild, linux-kernel, linux-mm, linux-um,
llvm, Benno Lossin, Mark Rutland, mmaurer, Bill Wendling,
Nathan Chancellor, Nick Desaulniers, Nicolas Schier,
Nicolas Schier, Peter Zijlstra, Richard Weinberger,
rust-for-linux, Trevor Gross, Uladzislau Rezki (Sony),
John Paul Adrian Glaubitz
In-Reply-To: <26d690ab-d68f-401f-ae2d-7aa4de081bce@app.fastmail.com>
Hi Arnd,
On Mon, 30 Mar 2026 at 14:14, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Mar 30, 2026, at 14:03, Geert Uytterhoeven wrote:
> > On Fri, 27 Mar 2026 at 10:02, Arnd Bergmann <arnd@arndb.de> wrote:
> >>
> >> echo 'struct { short a : 3; short b :15; short c :14; } x; int y = sizeof(x);' | m68k-linux-gcc -xc - -S -o-
> >>
> >> this produces '4' on m68k-linux-gcc, but '6' everywhere else. I originally
> >> thought this was related to this 2009 change in both compilers
> >
> > Oh, now I remember. AFAIK (holding wood and a rabbit leg) we don't
> > have any bitfield members spanning multiple base type instances in
> > the kernel.
>
> There are certainly very few of those, but two example I found in
> UAPI are
>
> struct dvd_layer {
> __u8 book_version : 4;
> __u8 book_type : 4;
>
> __u8 min_rate : 4;
> __u8 disc_size : 4;
>
> __u8 layer_type : 4;
> __u8 track_path : 1;
> __u8 nlayers : 2;
>
> __u8 track_density : 4; // crosses u8 boundary
> __u8 linear_density : 4;
> __u8 bca : 1;
> __u32 start_sector;
> __u32 end_sector;
> __u32 end_sector_l0;
> };
>
> struct usb_raw_ep_caps {
> __u32 type_control : 1;
> __u32 type_iso : 1;
> __u32 type_bulk : 1;
> __u32 type_int : 1;
> __u32 dir_in : 1;
> __u32 dir_out : 1;
> // 2 bit padding on m68k, 26 bits elsewhere
> };
So we just need to make padding explicit? Sounds familiar ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
From: Bartosz Golaszewski @ 2026-03-30 12:26 UTC (permalink / raw)
To: Heikki Krogerus
Cc: Andy Shevchenko, Aaro Koskinen, Janusz Krzysztofik, Arnd Bergmann,
Bartosz Golaszewski, Tony Lindgren, Russell King, Dmitry Torokhov,
Hans de Goede, Linux-OMAP, linux-arm-kernel, linux-kernel,
Kevin Hilman
In-Reply-To: <aco3YBCQsT2BN2_N@kuha>
On Mon, Mar 30, 2026 at 10:43 AM Heikki Krogerus
<heikki.krogerus@linux.intel.com> wrote:
>
> > > Thanks. This makes sense. Both omap16xx_gpio_init() and
> > > software_node_init() run as postcore_initcall() so if the order is not
> > > right, it will fail.
> > >
> > > Cc'ing Andy who's a reviewer for software nodes. Andy: is there any
> > > reason to run software_node_init() as a postcore initcall? It only
> > > allocates the kset, can we move it to core_initcall() by any chance?
> >
> > Good question. I don't know why it's chosen like this.
> > Let ask Heikki, who is the author of the code.
>
> I don't remember why it was it made a postcore initcall (I only
> remember that there was some reason at the time). It's probable
> fine to just make it a core initcall.
>
We can't really make it a core_initcall() either - kernel_kobj on
which software nodes depend is currently initialized in a
core_initcall() which could have been the reason for putting
software_node_init() in a postcore_initcall(). I think both
kernel_kobj and software nodes should be made available earlier.
Bart
^ permalink raw reply
* Re: [PATCH RFC net-next] net: stmmac: qcom-ethqos: set clk_csr
From: Andrew Lunn @ 2026-03-30 12:35 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Konrad Dybcio, Mohd Ayaan Anwar, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, linux-arm-kernel,
linux-arm-msm, linux-stm32, netdev, Paolo Abeni
In-Reply-To: <acpqgpCsbo3lJs3l@shell.armlinux.org.uk>
On Mon, Mar 30, 2026 at 01:20:18PM +0100, Russell King (Oracle) wrote:
> On Mon, Mar 30, 2026 at 01:18:56PM +0200, Konrad Dybcio wrote:
> > On 3/27/26 6:02 PM, Russell King (Oracle) wrote:
> > > The clocks for qcom-ethqos return a rate of zero as firmware manages
> > > their rate. According to hardware documentation, the clock which is
> > > fed to the slave AHB interface can crange between 50 and 100MHz.
> >
> > FWIW this __may__ possibly differ between platforms, but I'm not sure
> > to what degree. Will there be visible impact if we e.g. have a 200 or
> > 300 MHz clock somewhere?
>
> When you add other platforms, you're going to have to deal with their
> differences.
>
> IEEE 802.3 states that the maximum clock rate for the MDIO bus is
> 2.5MHz. You need to ensure that is the case.
>
> Current qcom-ethqos code doesn't set clk_csr, and returns zero for
> clk_get_rate() on the stmmac clocks because they are managed entirely
> in firmware.
Could a fixed clock be used in DT to represent clk_csr? Different
platforms then set it to different frequencies, to represent whatever
the firmware is doing.
Andrew
^ permalink raw reply
* [PATCH AUTOSEL 6.19-6.1] media: rkvdec: reduce stack usage in rkvdec_init_v4l2_vp9_count_tbl()
From: Sasha Levin @ 2026-03-30 12:38 UTC (permalink / raw)
To: patches, stable
Cc: Arnd Bergmann, Nicolas Dufresne, Mauro Carvalho Chehab,
Sasha Levin, detlev.casanova, ezequiel, mchehab, heiko,
linux-media, linux-rockchip, linux-arm-kernel, linux-kernel
In-Reply-To: <20260330123842.756154-1-sashal@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit c03b7dec3c4ddc97872fa12bfca75bae9cb46510 ]
The deeply nested loop in rkvdec_init_v4l2_vp9_count_tbl() needs a lot
of registers, so when the clang register allocator runs out, it ends up
spilling countless temporaries to the stack:
drivers/media/platform/rockchip/rkvdec/rkvdec-vp9.c:966:12: error: stack frame size (1472) exceeds limit (1280) in 'rkvdec_vp9_start' [-Werror,-Wframe-larger-than]
Marking this function as noinline_for_stack keeps it out of
rkvdec_vp9_start(), giving the compiler more room for optimization.
The resulting code is good enough that both the total stack usage
and the loop get enough better to stay under the warning limit,
though it's still slow, and would need a larger rework if this
function ends up being called in a fast path.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
No existing stack fix in stable 6.6.y for this file. All the
investigation is complete. Let me now compile the full analysis.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject Line**
Record: [media: rkvdec:] [reduce] [reduce stack usage in
rkvdec_init_v4l2_vp9_count_tbl() to fix Clang build failure with
-Wframe-larger-than]
**Step 1.2: Tags**
Record:
- Signed-off-by: Arnd Bergmann (author, well-known kernel build-fix
expert)
- Reviewed-by: Nicolas Dufresne (Collabora, rkvdec contributor)
- Signed-off-by: Nicolas Dufresne (subsystem co-maintainer)
- Signed-off-by: Mauro Carvalho Chehab (media subsystem top-level
maintainer)
- No Fixes:, Reported-by:, Tested-by:, Acked-by:, Link:, or Cc: stable
(absence expected for this pipeline)
**Step 1.3: Commit Body**
Record: Bug: The deeply nested 5-level loop in
`rkvdec_init_v4l2_vp9_count_tbl()` uses many registers. When Clang
inlines it into `rkvdec_vp9_start()`, the combined stack frame reaches
1472 bytes, exceeding the 1280-byte `-Wframe-larger-than` limit.
Symptom: Build failure with `-Werror,-Wframe-larger-than`. Fix: Mark the
function `noinline_for_stack` to prevent inlining. Author notes the
resulting code is "good enough" and the function is not on a fast path.
**Step 1.4: Hidden Bug Fix Detection**
Record: This is an explicit build fix, not a disguised runtime fix. The
commit message is transparent about the problem and solution.
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
Record: 1 file changed (`drivers/media/platform/rockchip/rkvdec/rkvdec-
vp9.c`), ~2 lines modified (function signature only: `static void` ->
`static noinline_for_stack void` split across 2 lines). Function
modified: `rkvdec_init_v4l2_vp9_count_tbl()`. Scope: single-file,
absolutely surgical.
**Step 2.2: Code Flow Change**
Record: Before: `rkvdec_init_v4l2_vp9_count_tbl()` was a plain `static
void` function eligible for inlining into `rkvdec_vp9_start()`. After:
The `noinline_for_stack` attribute prevents inlining, so the function
gets its own stack frame. No logic, data flow, or error path changes
whatsoever.
**Step 2.3: Bug Mechanism**
Record: Category: build fix / compiler stack-usage mitigation. The
deeply nested loop (5 levels: `i`, `j`, `k`, `l`, `m`) with 6 pointer
dereference assignments per iteration exhausts Clang's register
allocator when inlined, causing heavy stack spilling that pushes the
caller's frame past the warning limit.
**Step 2.4: Fix Quality**
Record: Obviously correct. `noinline_for_stack` is a well-established,
documented kernel pattern (`include/linux/compiler_types.h` line
276-278: `#define noinline_for_stack noinline`). Zero regression risk --
the only effect is preventing inlining of a function called once during
VP9 decoder initialization, which is not a hot path. No API or
behavioral changes.
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: Blame**
Record: `git blame` shows the entire function body traces to commit
`f25709c4ff151f` ("media: rkvdec: Add the VP9 backend") by Andrzej
Pietrasiewicz, dated 2021-11-17. This was included in
`v5.17-rc1~171^2~201`, so the code has been present since v5.17. The
same deeply nested loop and all 5 loop variables have been there since
introduction.
**Step 3.2: Fixes Tag**
Record: No Fixes: tag present (expected for commits under manual
review).
**Step 3.3: File History**
Record: On current tree, only 2 mainline commits modified `rkvdec-vp9.c`
in the non-staging path: the unstaging move (`d968e50b5c266`) and a QoS
disable (`664b42898db79`). The staging path has a few more minor
changes. No existing stack-usage or noinline fix for this file anywhere
in the history. The candidate is standalone.
**Step 3.4: Author Context**
Record: Arnd Bergmann is a prolific kernel contributor especially well-
known for build fixes, cross-compilation, architecture portability, and
stack-usage reduction patches. His media subsystem commits include
multiple similar `noinline_for_stack` fixes (e.g., `5954ad7d1af92` for
st-delta, `8b55f8818900c` for mediatek VP9). This is his core expertise.
**Step 3.5: Dependencies**
Record: No dependencies. `noinline_for_stack` is defined as `#define
noinline_for_stack noinline` in `include/linux/compiler_types.h` and has
existed since at least v4.x. The function signature is identical in all
stable trees (6.1.y, 6.6.y, 6.12.y) -- verified via `git show` on each
stable branch.
## PHASE 4: MAILING LIST RESEARCH
Record: Direct WebFetch to lore.kernel.org was blocked by Anubis proof-
of-work. However, the commit has proper review/signoff chain (Reviewed-
by from Nicolas Dufresne, Signed-off-by from both Nicolas Dufresne and
Mauro Carvalho Chehab), confirming it went through standard review.
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: Functions**
Record: Only `rkvdec_init_v4l2_vp9_count_tbl()` modified (signature
only).
**Step 5.2: Callers**
Record: Called exactly once from `rkvdec_vp9_start()` at line 1034.
Verified in all stable trees (6.1.y line 1031, 6.6.y/6.12.y line 1030).
**Step 5.3: Callees**
Record: The function sets up pointer tables and runs a 5-level nested
loop (`INNERMOST_LOOP` macro) performing array pointer assignments. No
dynamic allocations, no locks, no side effects beyond pointer setup.
**Step 5.4: Call Chain**
Record: `rkvdec_vp9_fmt_ops.start` -> `rkvdec_vp9_start()` ->
`rkvdec_init_v4l2_vp9_count_tbl()`. Called during VP9 streaming setup,
not per-frame. The author explicitly notes it is not a fast path.
**Step 5.5: Similar Patterns**
Record: `noinline_for_stack` is used in 7+ files under `drivers/media/`
for the same class of issue. The nearly identical mediatek VP9 commit
(`8b55f8818900c`) by the same author is the closest precedent.
## PHASE 6: STABLE TREE ANALYSIS
**Step 6.1: Code Existence**
Record: The file exists in all active stable trees:
- 6.1.y: `drivers/staging/media/rkvdec/rkvdec-vp9.c` (verified, function
at line 927)
- 6.6.y: `drivers/staging/media/rkvdec/rkvdec-vp9.c` (verified, function
at line 926)
- 6.12.y: `drivers/staging/media/rkvdec/rkvdec-vp9.c` (verified,
function at line 926)
The function signature and the deeply nested loop are identical in all
branches.
**Step 6.2: Backport Complications**
Record: The file path differs in stable trees (staging vs non-staging),
requiring a trivial path adjustment. The actual code is functionally
identical -- the patch applies cleanly with a path change.
**Step 6.3: Precedent -- Critical Finding**
Record: The nearly identical mediatek VP9 `noinline_for_stack` commit by
the same author (`8b55f8818900c`) **was backported to all three stable
trees**:
- 6.1.y: `89e1132bbf713`
- 6.6.y: `fa43166f2e8ba`
- 6.12.y: `f87626a55c215`
This is extremely strong precedent. The rkvdec fix is the same type of
change (same author, same compiler issue, same annotation, same VP9
decoder context).
## PHASE 7: SUBSYSTEM CONTEXT
**Step 7.1: Subsystem**
Record: `drivers/media/platform/rockchip/rkvdec/` -- Video decoder
driver for Rockchip SoCs. Criticality: PERIPHERAL (hardware-specific),
but Rockchip platforms are widely deployed in Chromebooks, single-board
computers, and embedded systems.
**Step 7.2: Activity**
Record: Low-moderate activity. The driver is mature. Recent changes are
minor (QoS fix, unstaging move).
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: Who is Affected**
Record: Anyone building the kernel with Clang (especially with KASAN
enabled, based on the mediatek precedent) who enables
`CONFIG_VIDEO_ROCKCHIP_VDEC` or `COMPILE_TEST`. This includes CI
systems, distribution kernel builds, and embedded/Chromebook builders.
**Step 8.2: Trigger Conditions**
Record: Triggered at compile time with Clang + `-Wframe-larger-than` +
`-Werror`. Deterministic build failure. The specific Clang version and
configuration matter (KASAN amplifies the issue per the mediatek
precedent), but the fix is purely defensive and safe regardless.
**Step 8.3: Failure Mode**
Record: Build failure -- kernel cannot be compiled. For anyone who needs
this driver, it is a hard blocker. Severity: MEDIUM-HIGH (build failure,
not runtime crash, but prevents compilation entirely).
**Step 8.4: Risk-Benefit Ratio**
Record: BENEFIT: Fixes a real build failure for Clang users with common
warning configurations. The identical class of fix was already deemed
worthy of backport for the mediatek VP9 driver. RISK: Essentially zero.
Adding `noinline_for_stack` has no behavioral effect; it only affects
compiler inlining decisions. The function is called exactly once during
initialization. Ratio: Very favorable.
## PHASE 9: FINAL SYNTHESIS
**Step 9.1: Evidence**
FOR backporting:
- Fixes a documented Clang `-Werror,-Wframe-larger-than` build failure
- Build fixes are an explicit exception category for stable backporting
- Extremely minimal change: single attribute annotation, no logic change
- Zero runtime regression risk
- Well-established kernel pattern (`noinline_for_stack`)
- Author is the recognized expert for this type of fix (Arnd Bergmann)
- Reviewed by subsystem co-maintainer, signed off by media subsystem
top-level maintainer
- **Strong precedent**: nearly identical fix by same author for mediatek
VP9 was backported to 6.1.y, 6.6.y, and 6.12.y
- Code exists in all active stable trees with identical function
signature
- `noinline_for_stack` macro exists in all stable trees
AGAINST backporting:
- File path differs in stable (staging vs non-staging) -- requires
trivial path adjustment
- Only affects Clang builds with specific configurations (not all build
environments)
- The exact compiler version/config triggering the issue may vary
**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** -- trivially correct, reviewed
by maintainers
2. Fixes a real bug? **YES** -- build failure with Clang
3. Important issue? **YES** -- build failure prevents compilation
4. Small and contained? **YES** -- 2-line signature change
5. No new features or APIs? **YES** -- no new features
6. Can apply to stable? **YES** -- with path adjustment for staging
directory
**Step 9.3: Exception Category**
Record: **BUILD FIX** -- explicitly listed as a valid stable exception
in the rules.
**Step 9.4: Decision**
This is a clear YES. It is a minimal, obviously correct build fix that
follows a well-established kernel pattern, was created by the foremost
expert in this area, and has direct precedent: the nearly identical
mediatek VP9 `noinline_for_stack` fix by the same author was already
backported to all active stable trees.
## Verification
- [Phase 1] Parsed subject: "media: rkvdec: reduce stack usage" -- build
fix for Clang -Wframe-larger-than
- [Phase 1] Parsed tags: Reviewed-by Nicolas Dufresne, SOBs from
subsystem and top-level maintainers, no Fixes/Reported-by (expected)
- [Phase 2] Diff analysis: 2-line change adding `noinline_for_stack` to
`rkvdec_init_v4l2_vp9_count_tbl()` signature; no logic change
- [Phase 3] git blame: function introduced by `f25709c4ff151f` ("media:
rkvdec: Add the VP9 backend", 2021-11-17), included since v5.17-rc1
- [Phase 3] git describe --contains f25709c4ff151f: confirmed
`v5.17-rc1~171^2~201`
- [Phase 3] Verified `noinline_for_stack` defined in
`include/linux/compiler_types.h` line 278 as `#define
noinline_for_stack noinline`
- [Phase 3] Author check: Arnd Bergmann has multiple similar
`noinline_for_stack` commits in drivers/media/
- [Phase 5] grep: `rkvdec_init_v4l2_vp9_count_tbl` called from exactly 1
place: `rkvdec_vp9_start()` at line 1034
- [Phase 5] Read: confirmed 5-level nested loop (lines 973-997) with
INNERMOST_LOOP macro causing heavy register pressure
- [Phase 6] git cat-file -e: verified file exists in 6.1.y, 6.6.y,
6.12.y at staging path
- [Phase 6] git show on stable branches: verified function signature
`static void rkvdec_init_v4l2_vp9_count_tbl(struct rkvdec_ctx *ctx)`
is identical in 6.1.y (line 927), 6.6.y (line 926), 6.12.y (line 926)
-- no `noinline_for_stack` present
- [Phase 6] Verified call site in 6.6.y stable at line 1030
- [Phase 6] **Critical precedent**: mediatek VP9 `noinline_for_stack`
commit `8b55f8818900c` by same author backported to 6.1.y
(`89e1132bbf713`), 6.6.y (`fa43166f2e8ba`), 6.12.y (`f87626a55c215`)
- [Phase 6] No existing stack-usage fix for rkvdec-vp9.c in any stable
branch (verified via git log --grep="stack" on 6.6.y)
- [Phase 4] lore.kernel.org inaccessible (Anubis protection); review
chain verified from commit tags
- UNVERIFIED: Mailing list discussion details beyond the commit tags
- UNVERIFIED: Exact Clang version/config that triggers the failure;
however, the fix is defensive and safe regardless
**YES**
drivers/media/platform/rockchip/rkvdec/rkvdec-vp9.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec-vp9.c b/drivers/media/platform/rockchip/rkvdec/rkvdec-vp9.c
index b4bf01e839eff..8fb6a1624a14f 100644
--- a/drivers/media/platform/rockchip/rkvdec/rkvdec-vp9.c
+++ b/drivers/media/platform/rockchip/rkvdec/rkvdec-vp9.c
@@ -927,7 +927,8 @@ static void rkvdec_vp9_done(struct rkvdec_ctx *ctx,
update_ctx_last_info(vp9_ctx);
}
-static void rkvdec_init_v4l2_vp9_count_tbl(struct rkvdec_ctx *ctx)
+static noinline_for_stack void
+rkvdec_init_v4l2_vp9_count_tbl(struct rkvdec_ctx *ctx)
{
struct rkvdec_vp9_ctx *vp9_ctx = ctx->priv;
struct rkvdec_vp9_intra_frame_symbol_counts *intra_cnts = vp9_ctx->count_tbl.cpu;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770
From: Bartosz Golaszewski @ 2026-03-30 12:40 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann
Cc: brgl, driver-core, linux-kernel, linux-acpi, linux-arm-kernel,
linux-omap, Bartosz Golaszewski
This converts Nokia 770 to using real firmware node lookup for GPIOs by
attaching the software nodes describing GPIO controllers to their target
devices.
As determined by Aaro's testing, both omap16xx_gpio_init() and
software_node_init() run in postcore_initcall() so we need to make
software nodes available earlier hence the new patches in v4.
Please note that while the goal of this series is to allow Nokia 770 to
use software nodes earlier, we're not modifying core kernel code just to
accomodate an old ARM platform - more such conversions are coming up so
the change will be useful to more consumers of the software node API.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Changes in v4:
- Add patches making software nodes available earlier
- Remove stray newline
- Link to v3: https://lore.kernel.org/all/20260212112508.73500-1-bartosz.golaszewski@oss.qualcomm.com/
Changes in v3:
- fix references to the MPU node
Changes in v2:
- fix build with CONFIG_I2C_CBUS_GPIO
- only export the two symbols that are actually required by the nokia
board file
---
Bartosz Golaszewski (3):
kernel: ksysfs: initialize kernel_kobj earlier
driver core: make software nodes available earlier
ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
arch/arm/mach-omap1/board-nokia770.c | 30 +++++-------------------------
arch/arm/mach-omap1/common.h | 3 +++
arch/arm/mach-omap1/gpio16xx.c | 28 +++++++++++++++++++++++++++-
drivers/base/base.h | 1 +
drivers/base/init.c | 1 +
drivers/base/swnode.c | 13 ++-----------
include/linux/kobject.h | 2 ++
init/main.c | 1 +
kernel/ksysfs.c | 8 +++-----
9 files changed, 45 insertions(+), 42 deletions(-)
---
base-commit: e80f5dcc54bf5d494b725e2932571488daac33b8
change-id: 20260330-nokia770-gpio-swnodes-5da8ba35946e
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v4 2/3] driver core: make software nodes available earlier
From: Bartosz Golaszewski @ 2026-03-30 12:40 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann
Cc: brgl, driver-core, linux-kernel, linux-acpi, linux-arm-kernel,
linux-omap, Bartosz Golaszewski
In-Reply-To: <20260330-nokia770-gpio-swnodes-v4-0-b68592e977d0@oss.qualcomm.com>
Software nodes are currently initialized in a function registered as
a postcore_initcall(). However, some devices may want to register
software nodes earlier than that (or also in a postcore_initcall() where
they're at the merci of the link order). Move the initialization to
driver_init() making swnode available much earlier as well as making
their initialization time deterministic.
Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/base/base.h | 1 +
drivers/base/init.c | 1 +
drivers/base/swnode.c | 13 ++-----------
3 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/base/base.h b/drivers/base/base.h
index afeda89fd4710c4c5492b5f19134e2aa8e1e581e..30b416588617bbc3fb433654c999c9b533d73752 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -312,6 +312,7 @@ static inline int devtmpfs_create_node(struct device *dev) { return 0; }
static inline int devtmpfs_delete_node(struct device *dev) { return 0; }
#endif
+void software_node_init(void);
void software_node_notify(struct device *dev);
void software_node_notify_remove(struct device *dev);
diff --git a/drivers/base/init.c b/drivers/base/init.c
index 9d2b06d65dfc6bf8759f6c232e2d3f753da139ac..af8014416c2460fac91b08ce919c082bf961fcce 100644
--- a/drivers/base/init.c
+++ b/drivers/base/init.c
@@ -34,6 +34,7 @@ void __init driver_init(void)
*/
faux_bus_init();
of_core_init();
+ software_node_init();
platform_bus_init();
auxiliary_bus_init();
memory_dev_init();
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 51320837f3a9f1bf4f65aa161d9b941affc74936..a80575bf598b509eb1469cae8a09c601726ce0c8 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -1127,18 +1127,9 @@ void software_node_notify_remove(struct device *dev)
}
}
-static int __init software_node_init(void)
+void __init software_node_init(void)
{
swnode_kset = kset_create_and_add("software_nodes", NULL, kernel_kobj);
if (!swnode_kset)
- return -ENOMEM;
- return 0;
-}
-postcore_initcall(software_node_init);
-
-static void __exit software_node_exit(void)
-{
- ida_destroy(&swnode_root_ids);
- kset_unregister(swnode_kset);
+ pr_err("failed to register software nodes\n");
}
-__exitcall(software_node_exit);
--
2.47.3
^ permalink raw reply related
* [PATCH v4 3/3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
From: Bartosz Golaszewski @ 2026-03-30 12:40 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann
Cc: brgl, driver-core, linux-kernel, linux-acpi, linux-arm-kernel,
linux-omap, Bartosz Golaszewski
In-Reply-To: <20260330-nokia770-gpio-swnodes-v4-0-b68592e977d0@oss.qualcomm.com>
Currently the board file for Nokia 770 creates dummy software nodes not
attached in any way to the actual GPIO controller devices and uses the
fact that GPIOLIB matching swnode's name to the GPIO chip's label during
software node lookup. This behavior is wrong and we want to remove it.
To that end, we need to first convert all existing users to creating
actual fwnode links.
Create real software nodes for GPIO controllers on OMAP16xx and
reference them from the software nodes in the nokia board file.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
arch/arm/mach-omap1/board-nokia770.c | 30 +++++-------------------------
arch/arm/mach-omap1/common.h | 3 +++
arch/arm/mach-omap1/gpio16xx.c | 28 +++++++++++++++++++++++++++-
3 files changed, 35 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c
index a5bf5554800fe17b430e84ae421ffa8da2bb11a0..46f817f6316b70ff37bb9dfde86c675fd692999b 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -36,25 +36,6 @@
#include "clock.h"
#include "mmc.h"
-static const struct software_node nokia770_mpuio_gpiochip_node = {
- .name = "mpuio",
-};
-
-static const struct software_node nokia770_gpiochip1_node = {
- .name = "gpio-0-15",
-};
-
-static const struct software_node nokia770_gpiochip2_node = {
- .name = "gpio-16-31",
-};
-
-static const struct software_node *nokia770_gpiochip_nodes[] = {
- &nokia770_mpuio_gpiochip_node,
- &nokia770_gpiochip1_node,
- &nokia770_gpiochip2_node,
- NULL
-};
-
#define ADS7846_PENDOWN_GPIO 15
static const unsigned int nokia770_keymap[] = {
@@ -112,7 +93,7 @@ static const struct omap_lcd_config nokia770_lcd_config __initconst = {
};
static const struct property_entry nokia770_mipid_props[] = {
- PROPERTY_ENTRY_GPIO("reset-gpios", &nokia770_gpiochip1_node,
+ PROPERTY_ENTRY_GPIO("reset-gpios", &omap16xx_gpio1_swnode,
13, GPIO_ACTIVE_LOW),
{ }
};
@@ -138,7 +119,7 @@ static const struct property_entry nokia770_ads7846_props[] = {
PROPERTY_ENTRY_U16("ti,x-plate-ohms", 180),
PROPERTY_ENTRY_U16("ti,debounce-tol", 3),
PROPERTY_ENTRY_U16("ti,debounce-rep", 1),
- PROPERTY_ENTRY_GPIO("pendown-gpios", &nokia770_gpiochip1_node,
+ PROPERTY_ENTRY_GPIO("pendown-gpios", &omap16xx_gpio1_swnode,
ADS7846_PENDOWN_GPIO, GPIO_ACTIVE_LOW),
{ }
};
@@ -225,9 +206,9 @@ static inline void nokia770_mmc_init(void)
#if IS_ENABLED(CONFIG_I2C_CBUS_GPIO)
static const struct software_node_ref_args nokia770_cbus_gpio_refs[] = {
- SOFTWARE_NODE_REFERENCE(&nokia770_mpuio_gpiochip_node, 9, 0),
- SOFTWARE_NODE_REFERENCE(&nokia770_mpuio_gpiochip_node, 10, 0),
- SOFTWARE_NODE_REFERENCE(&nokia770_mpuio_gpiochip_node, 11, 0),
+ SOFTWARE_NODE_REFERENCE(&omap16xx_mpu_gpio_swnode, 9, 0),
+ SOFTWARE_NODE_REFERENCE(&omap16xx_mpu_gpio_swnode, 10, 0),
+ SOFTWARE_NODE_REFERENCE(&omap16xx_mpu_gpio_swnode, 11, 0),
};
static const struct property_entry nokia770_cbus_props[] = {
@@ -318,7 +299,6 @@ static void __init omap_nokia770_init(void)
/* Unmask SleepX signal */
omap_writew((omap_readw(0xfffb5004) & ~2), 0xfffb5004);
- software_node_register_node_group(nokia770_gpiochip_nodes);
platform_add_devices(nokia770_devices, ARRAY_SIZE(nokia770_devices));
gpiod_add_lookup_table(&nokia770_irq_gpio_table);
diff --git a/arch/arm/mach-omap1/common.h b/arch/arm/mach-omap1/common.h
index 7a7c3d9eb84a06c18fbc70e7c94a161b487cd002..c0f6e231fdb4422c5d2c1aa3e33dd6dd99d2710e 100644
--- a/arch/arm/mach-omap1/common.h
+++ b/arch/arm/mach-omap1/common.h
@@ -35,6 +35,9 @@
#include "soc.h"
#include "i2c.h"
+extern const struct software_node omap16xx_mpu_gpio_swnode;
+extern const struct software_node omap16xx_gpio1_swnode;
+
#ifdef CONFIG_OMAP_SERIAL_WAKE
int omap_serial_wakeup_init(void);
#else
diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
index 55acec22fef4e73f20935473602ef6cb2f4f379c..e371183e0213912ebfa7edd34ca7e7683869ab12 100644
--- a/arch/arm/mach-omap1/gpio16xx.c
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -9,6 +9,7 @@
*/
#include <linux/platform_data/gpio-omap.h>
+#include <linux/property.h>
#include <linux/soc/ti/omap1-io.h>
#include "hardware.h"
@@ -55,6 +56,8 @@ static struct omap_gpio_platform_data omap16xx_mpu_gpio_config = {
.regs = &omap16xx_mpuio_regs,
};
+const struct software_node omap16xx_mpu_gpio_swnode = { };
+
static struct platform_device omap16xx_mpu_gpio = {
.name = "omap_gpio",
.id = 0,
@@ -99,6 +102,8 @@ static struct omap_gpio_platform_data omap16xx_gpio1_config = {
.regs = &omap16xx_gpio_regs,
};
+const struct software_node omap16xx_gpio1_swnode = { };
+
static struct platform_device omap16xx_gpio1 = {
.name = "omap_gpio",
.id = 1,
@@ -122,6 +127,8 @@ static struct resource omap16xx_gpio2_resources[] = {
},
};
+static const struct software_node omap16xx_gpio2_swnode = { };
+
static struct omap_gpio_platform_data omap16xx_gpio2_config = {
.bank_width = 16,
.regs = &omap16xx_gpio_regs,
@@ -155,6 +162,8 @@ static struct omap_gpio_platform_data omap16xx_gpio3_config = {
.regs = &omap16xx_gpio_regs,
};
+static const struct software_node omap16xx_gpio3_swnode = { };
+
static struct platform_device omap16xx_gpio3 = {
.name = "omap_gpio",
.id = 3,
@@ -183,6 +192,8 @@ static struct omap_gpio_platform_data omap16xx_gpio4_config = {
.regs = &omap16xx_gpio_regs,
};
+static const struct software_node omap16xx_gpio4_swnode = { };
+
static struct platform_device omap16xx_gpio4 = {
.name = "omap_gpio",
.id = 4,
@@ -201,6 +212,14 @@ static struct platform_device *omap16xx_gpio_dev[] __initdata = {
&omap16xx_gpio4,
};
+static const struct software_node *omap16xx_gpio_swnodes[] __initconst = {
+ &omap16xx_mpu_gpio_swnode,
+ &omap16xx_gpio1_swnode,
+ &omap16xx_gpio2_swnode,
+ &omap16xx_gpio3_swnode,
+ &omap16xx_gpio4_swnode,
+};
+
/*
* omap16xx_gpio_init needs to be done before
* machine_init functions access gpio APIs.
@@ -208,7 +227,7 @@ static struct platform_device *omap16xx_gpio_dev[] __initdata = {
*/
static int __init omap16xx_gpio_init(void)
{
- int i;
+ int i, ret;
void __iomem *base;
struct resource *res;
struct platform_device *pdev;
@@ -244,6 +263,13 @@ static int __init omap16xx_gpio_init(void)
iounmap(base);
platform_device_register(omap16xx_gpio_dev[i]);
+
+ ret = device_add_software_node(&omap16xx_gpio_dev[i]->dev,
+ omap16xx_gpio_swnodes[i]);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to add software node.\n");
+ return ret;
+ }
}
return 0;
--
2.47.3
^ permalink raw reply related
* [PATCH v4 1/3] kernel: ksysfs: initialize kernel_kobj earlier
From: Bartosz Golaszewski @ 2026-03-30 12:40 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann
Cc: brgl, driver-core, linux-kernel, linux-acpi, linux-arm-kernel,
linux-omap, Bartosz Golaszewski
In-Reply-To: <20260330-nokia770-gpio-swnodes-v4-0-b68592e977d0@oss.qualcomm.com>
Software nodes depend on kernel_kobj which is initialized pretty late
into the boot process - as a core_initcall(). Ahead of moving the
software node initialization to driver_init() we must first make
kernel_kobj available before it.
Make ksysfs_init() visible in the kobject.h header and call it in
do_basic_setup() right before driver_init().
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
include/linux/kobject.h | 2 ++
init/main.c | 1 +
kernel/ksysfs.c | 8 +++-----
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index c8219505a79f98bc370e52997efc8af51833cfda..71b9086621c35b7e4ef99b9d3b6707db23faf58c 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -219,4 +219,6 @@ int kobject_synth_uevent(struct kobject *kobj, const char *buf, size_t count);
__printf(2, 3)
int add_uevent_var(struct kobj_uevent_env *env, const char *format, ...);
+void ksysfs_init(void);
+
#endif /* _KOBJECT_H_ */
diff --git a/init/main.c b/init/main.c
index 8b7633b7ab720b9c13a231d64291d35d3852602c..1a9046b563e469057cca72ce39a0701c9c4d49e1 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1482,6 +1482,7 @@ static void __init do_initcalls(void)
static void __init do_basic_setup(void)
{
cpuset_init_smp();
+ ksysfs_init();
driver_init();
init_irq_proc();
do_ctors();
diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
index a9e6354d9e2579317d3b1bcb54223432d3ce0950..ac546562a6a1202a752de2d36719c6a193520a79 100644
--- a/kernel/ksysfs.c
+++ b/kernel/ksysfs.c
@@ -213,7 +213,7 @@ static const struct attribute_group kernel_attr_group = {
.attrs = kernel_attrs,
};
-static int __init ksysfs_init(void)
+void __init ksysfs_init(void)
{
int error;
@@ -234,14 +234,12 @@ static int __init ksysfs_init(void)
goto group_exit;
}
- return 0;
+ return;
group_exit:
sysfs_remove_group(kernel_kobj, &kernel_attr_group);
kset_exit:
kobject_put(kernel_kobj);
exit:
- return error;
+ pr_err("failed to initialize the kernel kobject: %d\n", error);
}
-
-core_initcall(ksysfs_init);
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3 2/3] PCI: Allow ATS to be always on for pre-CXL devices
From: Jason Gunthorpe @ 2026-03-30 12:49 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, bhelgaas, joro, praan, baolu.lu, kevin.tian,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, linux-pci,
dan.j.williams, jonathan.cameron, vsethi, linux-cxl
In-Reply-To: <c715b10b49d50eea5429454108d4221c1a78efaf.1772833963.git.nicolinc@nvidia.com>
On Fri, Mar 06, 2026 at 03:41:16PM -0800, Nicolin Chen wrote:
> Some NVIDIA GPU/NIC devices, although don't implement the CXL config space,
> they have many CXL-like properties. Call this kind "pre-CXL".
>
> Similar to CXL.cache capaiblity, these pre-CXL devices also require the ATS
> function even when their RIDs are IOMMU bypassed, i.e. keep ATS "always on"
> v.s. "on demand" when a non-zero PASID line gets enabled in SVA use cases.
>
> Introduce pci_dev_specific_ats_always_on() quirk function to scan a list of
> IDs for these device. Then, include it pci_ats_always_on().
>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/pci/pci.h | 9 +++++++++
> drivers/pci/ats.c | 3 ++-
> drivers/pci/quirks.c | 26 ++++++++++++++++++++++++++
> 3 files changed, 37 insertions(+), 1 deletion(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH v3 3/3] iommu/arm-smmu-v3: Allow ATS to be always on
From: Jason Gunthorpe @ 2026-03-30 12:51 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, bhelgaas, joro, praan, baolu.lu, kevin.tian,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, linux-pci,
dan.j.williams, jonathan.cameron, vsethi, linux-cxl
In-Reply-To: <0e8d1ee1557c54943dd15ff836576de4c3aa58b6.1772833963.git.nicolinc@nvidia.com>
On Fri, Mar 06, 2026 at 03:41:17PM -0800, Nicolin Chen wrote:
> When a device's default substream attaches to an identity domain, the SMMU
> driver currently sets the device's STE between two modes:
>
> Mode 1: Cfg=Translate, S1DSS=Bypass, EATS=1
> Mode 2: Cfg=bypass (EATS is ignored by HW)
>
> When there is an active PASID (non-default substream), mode 1 is used. And
> when there is no PASID support or no active PASID, mode 2 is used.
>
> The driver will also downgrade an STE from mode 1 to mode 2, when the last
> active substream becomes inactive.
>
> However, there are PCIe devices that demand ATS to be always on. For these
> devices, their STEs have to use the mode 1 as HW ignores EATS with mode 2.
>
> Change the driver accordingly:
> - always use the mode 1
> - never downgrade to mode 2
> - allocate and retain a CD table (see note below)
>
> Note that these devices might not support PASID, i.e. doing non-PASID ATS.
> In such a case, the ssid_bits is set to 0. However, s1cdmax must be set to
> a !0 value in order to keep the S1DSS field effective. Thus, when a master
> requires ats_always_on, set its s1cdmax to minimal 1, meaning the CD table
> will have a dummy entry (SSID=1) that will be never used.
>
> Now, for these device, arm_smmu_cdtab_allocated() will always return true,
> v.s. false prior to this change. When its default substream is attached to
> an IDENTITY domain, its first CD is NULL in the table, which is a totally
> valid case. Thus, add "!master->ats_always_on" to the condition.
>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 72 ++++++++++++++++++---
> 2 files changed, 65 insertions(+), 8 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH v14 05/12] dmaengine: qcom: bam_dma: add support for BAM locking
From: Manivannan Sadhasivam @ 2026-03-30 12:54 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Stephan Gerhold, Bjorn Andersson, Peter Ujfalusi, Michal Simek,
Frank Li, dmaengine, linux-doc, linux-kernel, linux-arm-msm,
linux-crypto, linux-arm-kernel, brgl, Bartosz Golaszewski
In-Reply-To: <20260323-qcom-qce-cmd-descr-v14-5-f323af411274@oss.qualcomm.com>
On Mon, Mar 23, 2026 at 04:17:11PM +0100, Bartosz Golaszewski wrote:
> Add support for BAM pipe locking. To that end: when starting DMA on an RX
> channel - prepend the existing queue of issued descriptors with an
> additional "dummy" command descriptor with the LOCK bit set. Once the
> transaction is done (no more issued descriptors), issue one more dummy
> descriptor with the UNLOCK bit.
>
> We *must* wait until the transaction is signalled as done because we
> must not perform any writes into config registers while the engine is
> busy.
>
> The dummy writes must be issued into a scratchpad register of the client
> so provide a mechanism to communicate the right address via descriptor
> metadata.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> drivers/dma/qcom/bam_dma.c | 165 ++++++++++++++++++++++++++++++++++++++-
> include/linux/dma/qcom_bam_dma.h | 10 +++
> 2 files changed, 171 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index 83491e7c2f17d8c9d12a1a055baea7e3a0a75a53..309681e798d2e44992e3d20679c3a7564ad8f29e 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -28,11 +28,13 @@
> #include <linux/clk.h>
> #include <linux/device.h>
> #include <linux/dma-mapping.h>
> +#include <linux/dma/qcom_bam_dma.h>
> #include <linux/dmaengine.h>
> #include <linux/init.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
> #include <linux/kernel.h>
> +#include <linux/lockdep.h>
> #include <linux/module.h>
> #include <linux/of_address.h>
> #include <linux/of_dma.h>
> @@ -60,6 +62,8 @@ struct bam_desc_hw {
> #define DESC_FLAG_EOB BIT(13)
> #define DESC_FLAG_NWD BIT(12)
> #define DESC_FLAG_CMD BIT(11)
> +#define DESC_FLAG_LOCK BIT(10)
> +#define DESC_FLAG_UNLOCK BIT(9)
>
> struct bam_async_desc {
> struct virt_dma_desc vd;
> @@ -391,6 +395,13 @@ struct bam_chan {
> struct list_head desc_list;
>
> struct list_head node;
> +
> + /* BAM locking infrastructure */
> + phys_addr_t scratchpad_addr;
> + struct scatterlist lock_sg;
> + struct scatterlist unlock_sg;
> + struct bam_cmd_element lock_ce;
> + struct bam_cmd_element unlock_ce;
> };
>
> static inline struct bam_chan *to_bam_chan(struct dma_chan *common)
> @@ -652,6 +663,32 @@ static int bam_slave_config(struct dma_chan *chan,
> return 0;
> }
>
> +static int bam_metadata_attach(struct dma_async_tx_descriptor *desc, void *data, size_t len)
> +{
> + struct bam_chan *bchan = to_bam_chan(desc->chan);
> + const struct bam_device_data *bdata = bchan->bdev->dev_data;
> + struct bam_desc_metadata *metadata = data;
> +
> + if (!data)
> + return -EINVAL;
> +
> + if (!bdata->pipe_lock_supported)
> + /*
> + * The client wants to use locking but this BAM version doesn't
> + * support it. Don't return an error here as this will stop the
> + * client from using DMA at all for no reason.
> + */
> + return 0;
> +
> + bchan->scratchpad_addr = metadata->scratchpad_addr;
> +
> + return 0;
> +}
> +
> +static const struct dma_descriptor_metadata_ops bam_metadata_ops = {
> + .attach = bam_metadata_attach,
> +};
> +
> /**
> * bam_prep_slave_sg - Prep slave sg transaction
> *
> @@ -668,6 +705,7 @@ static struct dma_async_tx_descriptor *bam_prep_slave_sg(struct dma_chan *chan,
> void *context)
> {
> struct bam_chan *bchan = to_bam_chan(chan);
> + struct dma_async_tx_descriptor *tx_desc;
> struct bam_device *bdev = bchan->bdev;
> struct bam_async_desc *async_desc;
> struct scatterlist *sg;
> @@ -723,7 +761,12 @@ static struct dma_async_tx_descriptor *bam_prep_slave_sg(struct dma_chan *chan,
> } while (remainder > 0);
> }
>
> - return vchan_tx_prep(&bchan->vc, &async_desc->vd, flags);
> + tx_desc = vchan_tx_prep(&bchan->vc, &async_desc->vd, flags);
> + if (!tx_desc)
> + return NULL;
> +
> + tx_desc->metadata_ops = &bam_metadata_ops;
> + return tx_desc;
> }
>
> /**
> @@ -1012,13 +1055,116 @@ static void bam_apply_new_config(struct bam_chan *bchan,
> bchan->reconfigure = 0;
> }
>
> +static struct bam_async_desc *
> +bam_make_lock_desc(struct bam_chan *bchan, struct scatterlist *sg,
> + struct bam_cmd_element *ce, unsigned long flag)
> +{
> + struct dma_chan *chan = &bchan->vc.chan;
> + struct bam_async_desc *async_desc;
> + struct bam_desc_hw *desc;
> + struct virt_dma_desc *vd;
> + struct virt_dma_chan *vc;
> + unsigned int mapped;
> + dma_cookie_t cookie;
> + int ret;
> +
> + sg_init_table(sg, 1);
> +
> + async_desc = kzalloc_flex(*async_desc, desc, 1, GFP_NOWAIT);
> + if (!async_desc) {
> + dev_err(bchan->bdev->dev, "failed to allocate the BAM lock descriptor\n");
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + async_desc->num_desc = 1;
> + async_desc->curr_desc = async_desc->desc;
> + async_desc->dir = DMA_MEM_TO_DEV;
> +
> + desc = async_desc->desc;
> +
> + bam_prep_ce_le32(ce, bchan->scratchpad_addr, BAM_WRITE_COMMAND, 0);
> + sg_set_buf(sg, ce, sizeof(*ce));
> +
> + mapped = dma_map_sg_attrs(chan->slave, sg, 1, DMA_TO_DEVICE, DMA_PREP_CMD);
> + if (!mapped) {
> + kfree(async_desc);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + desc->flags |= cpu_to_le16(DESC_FLAG_CMD | flag);
> + desc->addr = sg_dma_address(sg);
> + desc->size = sizeof(struct bam_cmd_element);
> +
> + vc = &bchan->vc;
> + vd = &async_desc->vd;
> +
> + dma_async_tx_descriptor_init(&vd->tx, &vc->chan);
> + vd->tx.flags = DMA_PREP_CMD;
> + vd->tx.desc_free = vchan_tx_desc_free;
> + vd->tx_result.result = DMA_TRANS_NOERROR;
> + vd->tx_result.residue = 0;
> +
> + cookie = dma_cookie_assign(&vd->tx);
> + ret = dma_submit_error(cookie);
> + if (ret) {
> + dma_unmap_sg(chan->slave, sg, 1, DMA_TO_DEVICE);
> + kfree(async_desc);
> + return ERR_PTR(ret);
> + }
> +
> + return async_desc;
> +}
> +
> +static int bam_do_setup_pipe_lock(struct bam_chan *bchan, bool lock)
> +{
> + struct bam_device *bdev = bchan->bdev;
> + const struct bam_device_data *bdata = bdev->dev_data;
> + struct bam_async_desc *lock_desc;
> + struct bam_cmd_element *ce;
> + struct scatterlist *sgl;
> + unsigned long flag;
> +
> + lockdep_assert_held(&bchan->vc.lock);
> +
> + if (!bdata->pipe_lock_supported || !bchan->scratchpad_addr ||
> + bchan->slave.direction != DMA_MEM_TO_DEV)
> + return 0;
> +
> + if (lock) {
> + sgl = &bchan->lock_sg;
> + ce = &bchan->lock_ce;
> + flag = DESC_FLAG_LOCK;
> + } else {
> + sgl = &bchan->unlock_sg;
> + ce = &bchan->unlock_ce;
> + flag = DESC_FLAG_UNLOCK;
> + }
> +
> + lock_desc = bam_make_lock_desc(bchan, sgl, ce, flag);
> + if (IS_ERR(lock_desc))
> + return PTR_ERR(lock_desc);
> +
> + if (lock)
> + list_add(&lock_desc->vd.node, &bchan->vc.desc_issued);
> + else
> + list_add_tail(&lock_desc->vd.node, &bchan->vc.desc_issued);
> +
> + return 0;
> +}
> +
> +static void bam_setup_pipe_lock(struct bam_chan *bchan)
> +{
> + if (bam_do_setup_pipe_lock(bchan, true) || bam_do_setup_pipe_lock(bchan, false))
> + dev_err(bchan->vc.chan.slave, "Failed to setup BAM pipe lock descriptors");
> +}
> +
> /**
> * bam_start_dma - start next transaction
> * @bchan: bam dma channel
> */
> static void bam_start_dma(struct bam_chan *bchan)
> {
> - struct virt_dma_desc *vd = vchan_next_desc(&bchan->vc);
> + struct virt_dma_desc *vd;
> struct bam_device *bdev = bchan->bdev;
> struct bam_async_desc *async_desc = NULL;
> struct bam_desc_hw *desc;
> @@ -1030,6 +1176,9 @@ static void bam_start_dma(struct bam_chan *bchan)
>
> lockdep_assert_held(&bchan->vc.lock);
>
> + bam_setup_pipe_lock(bchan);
> +
> + vd = vchan_next_desc(&bchan->vc);
> if (!vd)
> return;
>
> @@ -1157,8 +1306,15 @@ static void bam_issue_pending(struct dma_chan *chan)
> */
> static void bam_dma_free_desc(struct virt_dma_desc *vd)
> {
> - struct bam_async_desc *async_desc = container_of(vd,
> - struct bam_async_desc, vd);
> + struct bam_async_desc *async_desc = container_of(vd, struct bam_async_desc, vd);
> + struct bam_desc_hw *desc = async_desc->desc;
> + struct dma_chan *chan = vd->tx.chan;
> + struct bam_chan *bchan = to_bam_chan(chan);
> +
> + if (le16_to_cpu(desc->flags) & DESC_FLAG_LOCK)
> + dma_unmap_sg(chan->slave, &bchan->lock_sg, 1, DMA_TO_DEVICE);
> + else if (le16_to_cpu(desc->flags) & DESC_FLAG_UNLOCK)
> + dma_unmap_sg(chan->slave, &bchan->unlock_sg, 1, DMA_TO_DEVICE);
>
> kfree(async_desc);
> }
> @@ -1350,6 +1506,7 @@ static int bam_dma_probe(struct platform_device *pdev)
> bdev->common.device_terminate_all = bam_dma_terminate_all;
> bdev->common.device_issue_pending = bam_issue_pending;
> bdev->common.device_tx_status = bam_tx_status;
> + bdev->common.desc_metadata_modes = DESC_METADATA_CLIENT;
> bdev->common.dev = bdev->dev;
>
> ret = dma_async_device_register(&bdev->common);
> diff --git a/include/linux/dma/qcom_bam_dma.h b/include/linux/dma/qcom_bam_dma.h
> index 68fc0e643b1b97fe4520d5878daa322b81f4f559..5f0d2a27face8223ecb77da33d9e050c1ff2622f 100644
> --- a/include/linux/dma/qcom_bam_dma.h
> +++ b/include/linux/dma/qcom_bam_dma.h
> @@ -34,6 +34,16 @@ enum bam_command_type {
> BAM_READ_COMMAND,
> };
>
> +/**
> + * struct bam_desc_metadata - DMA descriptor metadata specific to the BAM driver.
> + *
> + * @scratchpad_addr: Physical address to use for dummy write operations when
> + * queuing command descriptors with LOCK/UNLOCK bits set.
> + */
> +struct bam_desc_metadata {
> + phys_addr_t scratchpad_addr;
> +};
> +
> /*
> * prep_bam_ce_le32 - Wrapper function to prepare a single BAM command
> * element with the data already in le32 format.
>
> --
> 2.47.3
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 3/4] elf: align ET_DYN base to max folio size for PTE coalescing
From: Matthew Wilcox @ 2026-03-30 12:56 UTC (permalink / raw)
To: WANG Rui
Cc: usama.arif, Liam.Howlett, ajd, akpm, apopple, baohua, baolin.wang,
brauner, catalin.marinas, david, dev.jain, jack, kees,
kevin.brodsky, lance.yang, linux-arm-kernel, linux-fsdevel,
linux-kernel, linux-mm, lorenzo.stoakes, mhocko, npache,
pasha.tatashin, rmclure, rppt, ryan.roberts, surenb, vbabka, viro
In-Reply-To: <20260329043700.19355-1-r@hev.cc>
On Sun, Mar 29, 2026 at 12:37:00PM +0800, WANG Rui wrote:
> > mapping_max_folio_size() reflects what the page cache will actually
> > allocate for a given filesystem, since readahead caps folio allocation
> > at mapping_max_folio_order() (in page_cache_ra_order()). If btrfs
> > reports PAGE_SIZE, readahead won't allocate large folios for it, so
> > there are no large folios to coalesce PTEs for, aligning the binary
> > beyond that would only reduce ASLR entropy for no benefit.
> >
> > I don't think we should over-align binaries on filesystems that can't
> > take advantage of it.
>
> Ah, it looks like this might be overlooking another path that can create
> huge page mappings for read-only code segments: even when the filesystem
> (e.g. btrfs without experimental) didn't support large folios,
> READ_ONLY_THP_FOR_FS still allowed read-only file-backed code segments
> to be collapsed into huge page mappings via khugepaged.
>
> As Wilcox pointed out, it may take quite some time for many filesystems
> to gain full large folio support? So what I'm trying to clarify is that
> using mapping_max_folio_size() on this path is not favorable for
> khugepaged-based optimizations.
Nono, that's not what I'm pointing out! btrfs is simply not putting
in the effort to support large folios, and that needs to change.
READ_ONLY_THP_FOR_FS unnecessaily burdens the rest of the kernel.
It was a great hack for its time and paved the path for a lot of what
we have today, but it's time to remove it.
^ permalink raw reply
* Re: [PATCH 4/5] xor/arm64: Use shared NEON intrinsics implementation from 32-bit ARM
From: Christoph Hellwig @ 2026-03-30 13:02 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Christoph Hellwig, Ard Biesheuvel, linux-raid, linux-arm-kernel,
linux-crypto, Russell King, Arnd Bergmann, Eric Biggers
In-Reply-To: <6bedf98e-a424-4baa-890c-806345c067c1@app.fastmail.com>
On Mon, Mar 30, 2026 at 11:38:15AM +0200, Ard Biesheuvel wrote:
> > This avoid the including of .c files which is always a bit ugly.
> > But if there is a strong argument to prefer including of the .c file I
> > can live with that as well.
> >
>
> I've respun it without the include. Instead, I've added this to arm/xor-neon.c
>
> +#ifdef CONFIG_ARM64
> +extern typeof(__xor_neon_2) __xor_eor3_2 __alias(__xor_neon_2);
> +#endif
>
> so that __xor_eor3_2() exists in the arm64 build as an alias. That way, the arm64-only EOR3 implementation can just remain a separate compilation unit.
Ok.
^ permalink raw reply
* Re: [PATCH v3 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
From: Jason Gunthorpe @ 2026-03-30 12:48 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, bhelgaas, joro, praan, baolu.lu, kevin.tian,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, linux-pci,
dan.j.williams, jonathan.cameron, vsethi, linux-cxl
In-Reply-To: <a0dd3e4cc5260f55bbec5b3ed6791def33028735.1772833963.git.nicolinc@nvidia.com>
On Fri, Mar 06, 2026 at 03:41:15PM -0800, Nicolin Chen wrote:
> Controlled by the IOMMU driver, ATS is usually enabled "on demand" when a
> device requests a translation service from its associated IOMMU HW running
> on the channel of a given PASID. This is working even when a device has no
> translation on its RID (i.e., the RID is IOMMU bypassed).
>
> However, certain PCIe devices require non-PASID ATS on their RID even when
> the RID is IOMMU bypassed. Call this "always on".
>
> For instance, the CXL spec notes in "3.2.5.13 Memory Type on CXL.cache":
> "To source requests on CXL.cache, devices need to get the Host Physical
> Address (HPA) from the Host by means of an ATS request on CXL.io."
>
> In other words, the CXL.cache capability requires ATS; otherwise, it can't
> access host physical memory.
>
> Introduce a new pci_ats_always_on() helper for the IOMMU driver to scan a
> PCI device and shift ATS policies between "on demand" and "always on".
>
> Add the support for CXL.cache devices first. Pre-CXL devices will be added
> in quirks.c file.
>
> Note that pci_ats_always_on() validates against pci_ats_supported(), so we
> ensure that untrusted devices (e.g. external ports) will not be always on.
> This maintains the existing ATS security policy regarding potential side-
> channel attacks via ATS.
>
> Cc: linux-cxl@vger.kernel.org
> Suggested-by: Vikram Sethi <vsethi@nvidia.com>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> include/linux/pci-ats.h | 3 +++
> include/uapi/linux/pci_regs.h | 1 +
> drivers/pci/ats.c | 42 +++++++++++++++++++++++++++++++++++
> 3 files changed, 46 insertions(+)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH] clk: visconti: pll: use kzalloc_flex
From: Brian Masney @ 2026-03-30 13:07 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-clk, Michael Turquette, Stephen Boyd, Nobuhiro Iwamatsu,
Kees Cook, Gustavo A. R. Silva,
moderated list:ARM/TOSHIBA VISCONTI ARCHITECTURE, open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260326042317.122536-1-rosenp@gmail.com>
On Wed, Mar 25, 2026 at 09:23:17PM -0700, Rosen Penev wrote:
> Simplify allocation by using a flexible array member and kzalloc_flex.
>
> Add __counted_by for extra runtime analysis. Assign after allocation as
> required by __counted_by.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Note: Sashiko reported a separate issue related to the struct clk_init_data
not fully initialized to zero, and parent_data and parent_hws fields are
left containing stack garbage.
https://sashiko.dev/#/patchset/20260326042317.122536-1-rosenp%40gmail.com
I'll post a fix for this.
Brian
^ permalink raw reply
* Re: [PATCH v14 12/12] crypto: qce - Communicate the base physical address to the dmaengine
From: Manivannan Sadhasivam @ 2026-03-30 13:08 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Stephan Gerhold, Bjorn Andersson, Peter Ujfalusi, Michal Simek,
Frank Li, dmaengine, linux-doc, linux-kernel, linux-arm-msm,
linux-crypto, linux-arm-kernel, brgl, Bartosz Golaszewski
In-Reply-To: <20260323-qcom-qce-cmd-descr-v14-12-f323af411274@oss.qualcomm.com>
On Mon, Mar 23, 2026 at 04:17:18PM +0100, Bartosz Golaszewski wrote:
> In order to communicate to the BAM DMA engine which address should be
> used as a scratchpad for dummy writes related to BAM pipe locking,
> fill out and attach the provided metadata struct to the descriptor as
> well as mark the RX channel as such using the slave config struct.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> drivers/crypto/qce/dma.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/crypto/qce/dma.c b/drivers/crypto/qce/dma.c
> index 5c42fc7ddf01e11a6562d272ba7c90c906e0e312..635208947668667765e6accf9ef02100746c0f9a 100644
> --- a/drivers/crypto/qce/dma.c
> +++ b/drivers/crypto/qce/dma.c
> @@ -11,6 +11,7 @@
>
> #include "core.h"
> #include "dma.h"
> +#include "regs-v5.h"
>
> #define QCE_IGNORE_BUF_SZ (2 * QCE_BAM_BURST_SIZE)
> #define QCE_BAM_CMD_SGL_SIZE 128
> @@ -43,6 +44,7 @@ void qce_clear_bam_transaction(struct qce_device *qce)
>
> int qce_submit_cmd_desc(struct qce_device *qce)
> {
> + struct bam_desc_metadata meta = { .scratchpad_addr = qce->base_phys + REG_VERSION };
> struct qce_desc_info *qce_desc = qce->dma.bam_txn->desc;
> struct qce_bam_transaction *bam_txn = qce->dma.bam_txn;
> struct dma_async_tx_descriptor *dma_desc;
> @@ -64,6 +66,12 @@ int qce_submit_cmd_desc(struct qce_device *qce)
> return -ENOMEM;
> }
>
> + ret = dmaengine_desc_attach_metadata(dma_desc, &meta, 0);
> + if (ret) {
> + dma_unmap_sg(qce->dev, bam_txn->wr_sgl, bam_txn->wr_sgl_cnt, DMA_TO_DEVICE);
> + return ret;
> + }
> +
> qce_desc->dma_desc = dma_desc;
> cookie = dmaengine_submit(qce_desc->dma_desc);
>
> @@ -107,7 +115,9 @@ void qce_write_dma(struct qce_device *qce, unsigned int offset, u32 val)
> int devm_qce_dma_request(struct qce_device *qce)
> {
> struct qce_dma_data *dma = &qce->dma;
> + struct dma_slave_config cfg = { };
> struct device *dev = qce->dev;
> + int ret;
>
> dma->txchan = devm_dma_request_chan(dev, "tx");
> if (IS_ERR(dma->txchan))
> @@ -119,6 +129,11 @@ int devm_qce_dma_request(struct qce_device *qce)
> return dev_err_probe(dev, PTR_ERR(dma->rxchan),
> "Failed to get RX DMA channel\n");
>
> + cfg.direction = DMA_MEM_TO_DEV;
> + ret = dmaengine_slave_config(dma->rxchan, &cfg);
> + if (ret)
> + return ret;
> +
I don't think this part is necessary. You are already passing the metadata above
and that should be sufficient for the BAM DMA driver to get the scratchpad
address. If any client drivers call dmaengine_slave_config() without
dmaengine_desc_attach_metadata(), and if the BAM DMA supports locking, then the
BAM driver should fail. Otherwise, continuing so would cause race conditions
among the BAM clients, which we are seeing right now on Qcom SDX targets with
both NAND driver in Linux and Modem trying to access NAND memory over BAM.
So please drop this and just use dmaengine_desc_attach_metadata().
- Mani
--
மணிவண்ணன் சதாசிவம்
^ 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