* Re: [PATCH 3/4] remoteproc: add helper for optional ELF resource tables
From: Shah, Tanmay @ 2026-05-12 14:53 UTC (permalink / raw)
To: Daniel Baluta, Ben Levinsky, Bjorn Andersson, Mathieu Poirier,
linux-remoteproc
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Patrice Chotard, Maxime Coquelin,
Alexandre Torgue, imx, linux-arm-kernel, linux-kernel,
linux-renesas-soc, linux-stm32, tanmay.shah
In-Reply-To: <3b7f009c-dc4b-4fc0-becc-4d07eb4ff016@oss.nxp.com>
On 5/12/2026 2:55 AM, Daniel Baluta wrote:
> On 5/12/26 00:18, Ben Levinsky wrote:
>> [You don't often get email from ben.levinsky@amd.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Add a small helper around rproc_elf_load_rsc_table() for remoteproc
>> drivers that treat a missing ELF resource table as optional. The helper
>> returns success on -EINVAL and propagates other failures unchanged.
>>
>> Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
>> ---
>> drivers/remoteproc/remoteproc_internal.h | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/remoteproc_internal.h
>> index 3724a47a9748..dff87e468837 100644
>> --- a/drivers/remoteproc/remoteproc_internal.h
>> +++ b/drivers/remoteproc/remoteproc_internal.h
>> @@ -146,6 +146,18 @@ static inline int rproc_mem_entry_iounmap(struct rproc *rproc,
>> return 0;
>> }
>>
>> +static inline int rproc_elf_load_rsc_table_optional(struct rproc *rproc,
>> + const struct firmware *fw)
>> +{
>> + int ret;
>> +
>> + ret = rproc_elf_load_rsc_table(rproc, fw);
>> + if (ret == -EINVAL)
>> + dev_dbg(&rproc->dev, "no resource table found\n");
>
> You are changing loglevel here. Initial drivers use dev_info or dev_warn. At least I'm used
> with seeing this messages in the logs.
>
> So, what do you think on adding at least dev_info to this instead of dev_dbg?
>
Actually can we leave that choice to the platform driver ? There are
many use cases where the remoteproc subsystem is used to load and start
the remote core and the firmware doesn't have the resource table. We
don't want to make info level log for such use cases, as the resource
table is not expected in the first place there.
>> +
>> + return ret == -EINVAL ? 0 : ret;
>> +}
>> +
>> static inline int rproc_prepare_device(struct rproc *rproc)
>> {
>> if (rproc->ops->prepare)
>> --
>> 2.34.1
>>
>>
>
^ permalink raw reply
* Re: [PATCH V2] clk: keystone: sci-clk: fix application of sizeof to pointer
From: Brian Masney @ 2026-05-12 14:53 UTC (permalink / raw)
To: Nishanth Menon
Cc: Stephen Boyd, Michael Turquette, Santosh Shilimkar, Tero Kristo,
linux-clk, linux-kernel, linux-arm-kernel, afd, sozdayvek,
Jing Yangyang, Zeal Robot, kernel test robot, Julia Lawall,
David Yang
In-Reply-To: <20260512110028.2999471-1-nm@ti.com>
On Tue, May 12, 2026 at 06:00:28AM -0500, Nishanth Menon wrote:
> From: Jing Yangyang <jing.yangyang@zte.com.cn>
>
> Coccinelle (scripts/coccinelle/misc/noderef.cocci) reports:
>
> drivers/clk/keystone/sci-clk.c:391:8-14: ERROR: application of
> sizeof to pointer
>
> In sci_clk_get(), 'clk' is declared as 'struct sci_clk **', so
> sizeof(clk) is sizeof(struct sci_clk **) which is the size of a
> pointer rather than the size of an array element. provider->clocks
> is an array of 'struct sci_clk *', so the canonical size argument
> to bsearch() is sizeof(*clk) (i.e. sizeof(struct sci_clk *)).
>
> The two values are equal on every supported architecture, so this
> is correctness/idiom, not a runtime fix, but the new form matches
> the rest of the bsearch() callers in the tree and silences the
> Coccinelle warning the script flagged.
>
> Reported-by: Zeal Robot <zealci@zte.com.cn>
> Closes: https://lore.kernel.org/all/84a6ba16686347099a3dab2e5161a930e792eb6e.1629198281.git.jing.yangyang@zte.com.cn/
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Julia Lawall <julia.lawall@inria.fr>
> Closes: https://lore.kernel.org/all/202512040525.zrHSDl5h-lkp@intel.com/
> Link: https://lore.kernel.org/linux-clk/20211012021931.176727-1-davidcomponentone@gmail.com/
> Reviewed-by: Stepan Ionichev <sozdayvek@gmail.com>
> Reviewed-by: Andrew Davis <afd@ti.com>
> Signed-off-by: Jing Yangyang <jing.yangyang@zte.com.cn>
> Signed-off-by: David Yang <davidcomponentone@gmail.com>
> [nm@ti.com: Improved commit message]
> Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* [PATCH] crypto: atmel - use min3 to simplify atmel_sha_append_sg
From: Thorsten Blum @ 2026-05-12 14:51 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea
Cc: Thorsten Blum, linux-crypto, linux-arm-kernel, linux-kernel
Replace two consecutive min() calls with min3() to simplify the code.
And since count is unsigned and cannot be less than zero, adjust the if
check and update the comment accordingly.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/crypto/atmel-sha.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/atmel-sha.c b/drivers/crypto/atmel-sha.c
index 002b62902553..7e7c83a3d8cd 100644
--- a/drivers/crypto/atmel-sha.c
+++ b/drivers/crypto/atmel-sha.c
@@ -305,12 +305,12 @@ static size_t atmel_sha_append_sg(struct atmel_sha_reqctx *ctx)
size_t count;
while ((ctx->bufcnt < ctx->buflen) && ctx->total) {
- count = min(ctx->sg->length - ctx->offset, ctx->total);
- count = min(count, ctx->buflen - ctx->bufcnt);
+ count = min3(ctx->sg->length - ctx->offset, ctx->total,
+ ctx->buflen - ctx->bufcnt);
- if (count <= 0) {
+ if (count == 0) {
/*
- * Check if count <= 0 because the buffer is full or
+ * Check if count == 0 because the buffer is full or
* because the sg length is 0. In the latest case,
* check if there is another sg in the list, a 0 length
* sg doesn't necessarily mean the end of the sg list.
^ permalink raw reply related
* Re: [PATCH RFC] iommu: Enable per-device SSID space for SVA
From: Joonwon Kang @ 2026-05-12 14:51 UTC (permalink / raw)
To: robin.murphy
Cc: Alexander.Grest, amhetre, baolu.lu, easwar.hariharan, iommu,
jacob.jun.pan, jgg, joonwonkang, joro, jpb, kees, kevin.tian,
linux-arm-kernel, linux-kernel, nicolinc, praan, smostafa, will
In-Reply-To: <b95b42c6-4d10-4701-88e2-9991f3773e6a@arm.com>
> On 12/05/2026 1:40 pm, Jason Gunthorpe wrote:
> > On Tue, May 12, 2026 at 09:57:14AM +0000, Joonwon Kang wrote:
> >>> There is a bit more going on though, I think that is what Joonwon is
> >>> mentioning by asking about ST64B and ST64BV. I *think* the answer is:
> >>>
> >>> - ST64B uses a posted write
> >>> - ST64BV can be restricted so EL0 cannot execute it, it uses a
> >>> non-posted write (AI tells me via EnASR)
> >>> - ST64BV0 can be used by EL0, always uses a non-posted write, and always
> >>> uses ACCDATA_EL1
> >>>
> >>> Which is similar to Intel.
> >>
> >> Ah, I missed that ST64BV is currently being trapped to EL1 while ST64B is
> >> not [1]. However, I am not sure if the trap is to disallow EL0 to use it.
> >> Can it be instead to pass the response value of the non-posted write to
> >> EL0 while using the EL0-given PASID as-is? If so, I believe EL0 still can
> >> specify arbitrary PASID as it wants via ST64BV.
> >
> > I think if an OS implements things this way it is would security
> > broken as far as ENQCMD compatible HW goes.
>
> Yes, I think it's rather the point that the EnALS/EnASR traps to EL1
> allow EL1 to sanitise the data that ST64B/ST64BV are sending, and do
> exactly things like substituting a valid PASID. ST64BV0 offers a way of
> doing so _without_ needing the overhead of trapping, but conversely that
> needs the EnAS0 opt-in all the way down to indicate both EL1's awareness
> of programming ACCDATA_EL1 appropriately and EL2/3's awareness of
> context-switching it.
>
> I've not looked closely at what exactly the arm64 arch code is doing
> today and how well it actually fits the expected ENQCMD usage model, but
> I can well believe it might need a bit of tweaking.
>
> Thanks,
> Robin.
>
> >> Since I guess ST64B* instructions are to serve generic purposes not only
> >> for communication with accelerators with SIOV but also with any memory
> >> location or device without SIOV, I am not sure if it is always okay to
> >> make those instructions work the way Jason mentioned.
> >
> > The end point has to use the posted vs non-posted write distinction
> > for security.
> >
> >>> The device only processes the PASID from a non-posted write,
> >>
> >> Regarding ST64B, are the ARM devices behind ARM SMMU v3 supposed to work
> >> this way too? If not, EL0 can specify arbitrary PASID via ST64B with the
> >> kernel today [1].
> >
> > If you want ENQCMD compatible semantics then yes you have to do all of
> > these things, it is part of the security design.
> >
> > Jason
Appreciate all your clarifications here. So, my understanding is that if
our system does not support ST64BV and ST64BV0 or if our device does not
distinguish between the posted write and the non-posted write regarding
PASID, then we can lift the use of the global PASID space. Can I say this?
If yes, I will create a new patch which checks for that case. It might as
well add a new device tree property to represent if the device supports
the posted write vs. non-posted write distinction.
Thanks,
Joonwon Kang
^ permalink raw reply
* Re: [PATCH v2] clk: keystone: don't cache clock rate
From: Brian Masney @ 2026-05-12 14:51 UTC (permalink / raw)
To: Nishanth Menon
Cc: a-christidis, Tero Kristo, Santosh Shilimkar, Michael Turquette,
Stephen Boyd, linux-arm-kernel, linux-kernel, linux-clk,
Michael Walle, Kevin Hilman, Randolph Sapp
In-Reply-To: <20260512104848.4axgjeto6i7ejvli@retorted>
Hi Nishanth,
On Tue, May 12, 2026 at 05:48:48AM -0500, Nishanth Menon wrote:
> On 10:36-20260511, Brian Masney wrote:
> > On Thu, May 07, 2026 at 11:09:34AM -0500, a-christidis@ti.com wrote:
> > > From: Michael Walle <mwalle@kernel.org>
> > >
> > > The TISCI firmware will return 0 if the clock or consumer is not
> > > enabled although there is a stored value in the firmware. IOW a call to
> > > set rate will work but at get rate will always return 0 if the clock is
> > > disabled.
> > > The clk framework will try to cache the clock rate when it's requested
> > > by a consumer. If the clock or consumer is not enabled at that point,
> > > the cached value is 0, which is wrong. Thus, disable the cache
> > > altogether.
> > >
> > > Signed-off-by: Michael Walle <mwalle@kernel.org>
> > > Reviewed-by: Kevin Hilman <khilman@baylibre.com>
> > > Reviewed-by: Randolph Sapp <rs@ti.com>
> > > Reviewed-by: Nishanth Menon <nm@ti.com>
> > > Signed-off-by: Antonios Christidis <a-christidis@ti.com>
> >
> > Reviewed-by: Brian Masney <bmasney@redhat.com>
> >
>
> Brian,
>
> Could you clarify if I need to take it via my tree to arnd or if this
> patch will go via the clk tree?
Sorry, I'm not sure what Stephen prefers here. An argument could be made
for either approach. I would just go with whatever you have done in the
past.
Brian
^ permalink raw reply
* Re: [RFC PATCH v3 3/7] hq-spinlock: add contention detection
From: WEI-HONG, YE @ 2026-05-12 14:49 UTC (permalink / raw)
To: fedorov.nikita
Cc: linux-kernel, linux-arm-kernel, linux-arch, linux-mm,
virtualization
In-Reply-To: <20260415164459.2904963-4-fedorov.nikita@h-partners.com>
Hi,
I may be missing something, but this patch adds
`update_counters_qspinlock()` for remote handoff accounting.
I tried commenting it out locally, and the kernel still built successfully
with `CONFIG_HQSPINLOCKS=y` and `CONFIG_HQSPINLOCKS_DEBUG=y`. I also could
not find a call site for it in the series, so it looks like this helper may
currently be unreferenced.
Is it still needed, or was the call site possibly missed in this RFC version?
Cheers,
Hong
^ permalink raw reply
* [PATCH v6 05/10] dt-bindings: arm: fsl: Add solidrun lx2160a twins board
From: Josua Mayer @ 2026-05-12 14:39 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
The SolidRun LX2160A Twins board supports two configurations, one with
with a sinle CEX-7 module, and one with two (dual).
The dual configuration was not yet tested.
Add binding for the single variant only.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 0023cd1268075..1f11c1208c248 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1868,6 +1868,7 @@ properties:
- enum:
- solidrun,clearfog-cx
- solidrun,honeycomb
+ - solidrun,twins-single
- const: solidrun,lx2160a-cex7
- const: fsl,lx2160a
--
2.51.0
^ permalink raw reply related
* [PATCH v6 10/10] arm64: dts: Add support for LX2160 Twins board in single configuration
From: Josua Mayer @ 2026-05-12 14:39 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
Add support for the SolidRun LX2160A Twins board in its single cpu
configuration.
The twins board is designed to host a pair of LX2160A CEX-7 modules,
sharing a single PCI-E connector in multi-host mode.
It may be assembled in two configurations (different assembly options
facilitating signal re-routing), with a single or with dual CEX-7
module. Their marketing names are:
- SolidWAN Single LX2160
- SolidWAN Dual LX2160
This patch adds the single configuration, featuring:
- 8x SFP (1Gbps)
- 8x SFP+ (1/10Gbps)
- PCI-E OCP card connector
- USB-3.0 front-panel header with single port
- microSD
- dual hot-swappable power supplies
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
arch/arm64/boot/dts/freescale/Makefile | 2 +
.../boot/dts/freescale/fsl-lx2160a-half-twins.dts | 826 +++++++++++++++++++++
2 files changed, 828 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 711e36cc2c990..59eee431562ef 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -51,6 +51,8 @@ DTC_FLAGS_fsl-lx2160a-bluebox3-rev-a := -Wno-interrupt_map
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-bluebox3-rev-a.dtb
DTC_FLAGS_fsl-lx2160a-clearfog-cx := -Wno-interrupt_map
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-clearfog-cx.dtb
+DTC_FLAGS_fsl-lx2160a-half-twins := -Wno-interrupt_map
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-half-twins.dtb
DTC_FLAGS_fsl-lx2160a-honeycomb := -Wno-interrupt_map
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-honeycomb.dtb
DTC_FLAGS_fsl-lx2160a-qds := -Wno-interrupt_map
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
new file mode 100644
index 0000000000000..ee1867f5b2b6b
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
@@ -0,0 +1,826 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+//
+// Device Tree file for single LX2160A CEX-7 on Twins board.
+//
+// Copyright 2022 SolidRun Ltd.
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+
+#include "fsl-lx2160a-rev2.dtsi"
+#include "fsl-lx2160a-cex7.dtsi"
+
+/ {
+ compatible = "solidrun,twins-single", "solidrun,lx2160a-cex7", "fsl,lx2160a";
+ model = "SolidRun LX2160A SolidWAN Single";
+
+ aliases {
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ gpio2 = &gpio2;
+ gpio3 = &gpio3;
+ gpio4 = &expander0;
+ gpio5 = &expander1;
+ gpio6 = &expander2;
+ gpio7 = &expander3;
+ i2c0 = &i2c0;
+ i2c1 = &i2c2;
+ i2c2 = &i2c4;
+ i2c3 = &fan_i2c;
+ i2c4 = &power_i2c;
+ i2c5 = &i2c_smb;
+ i2c6 = &sfp0_i2c;
+ i2c7 = &sfp1_i2c;
+ i2c8 = &sfp2_i2c;
+ i2c9 = &sfp3_i2c;
+ i2c10 = &twins_sfp_c1_at_i2c;
+ i2c11 = &twins_sfp_c1_ab_i2c;
+ i2c12 = &twins_sfp_c1_bt_i2c;
+ i2c13 = &twins_sfp_c1_bb_i2c;
+ i2c14 = &twins_sfp_c2_at_i2c;
+ i2c15 = &twins_sfp_c2_ab_i2c;
+ i2c16 = &twins_sfp_c2_bt_i2c;
+ i2c17 = &twins_sfp_c2_bb_i2c;
+ i2c18 = &twins_sfp_c3_at_i2c;
+ i2c19 = &twins_sfp_c3_ab_i2c;
+ i2c20 = &twins_sfp_c3_bt_i2c;
+ i2c21 = &twins_sfp_c3_bb_i2c;
+ i2c22 = &htwins_sfp_c3_at_i2c;
+ i2c23 = &htwins_sfp_c3_ab_i2c;
+ i2c24 = &htwins_sfp_c3_bt_i2c;
+ i2c25 = &htwins_sfp_c3_bb_i2c;
+ i2c26 = &ddr_i2c;
+ mmc0 = &esdhc0;
+ mmc1 = &esdhc1;
+ serial0 = &uart0;
+ serial1 = &uart1;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_ht_c3_bt: led-sfp-1 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <1>;
+ gpios = <&expander3 14 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&dpmac5>;
+ linux,default-trigger = "netdev";
+ };
+
+ led_ht_c3_bb: led-sfp-2 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <2>;
+ gpios = <&expander3 13 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&dpmac15>;
+ linux,default-trigger = "netdev";
+ };
+
+ led_ht_c3_at: led-sfp-3 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <3>;
+ gpios = <&expander3 11 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&dpmac6>;
+ linux,default-trigger = "netdev";
+ };
+
+ led_ht_c3_ab: led-sfp-4 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <4>;
+ gpios = <&expander3 12 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&dpmac11>;
+ linux,default-trigger = "netdev";
+ };
+
+ led_c1_bt: led-sfp-9 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <9>;
+ gpios = <&expander1 4 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&dpmac4>;
+ linux,default-trigger = "netdev";
+ };
+
+ led_c1_bb: led-sfp-10 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <10>;
+ gpios = <&expander1 3 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&dpmac17>;
+ linux,default-trigger = "netdev";
+ };
+
+ led_c1_at: led-sfp-11 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <11>;
+ gpios = <&expander1 1 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&dpmac3>;
+ linux,default-trigger = "netdev";
+ };
+
+ led_c1_ab: led-sfp-12 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <12>;
+ gpios = <&expander1 2 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&dpmac12>;
+ linux,default-trigger = "netdev";
+ };
+
+ led_c2_bt: led-sfp-13 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <13>;
+ gpios = <&expander1 10 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&dpmac8>;
+ linux,default-trigger = "netdev";
+ };
+
+ led_c2_bb: led-sfp-14 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <14>;
+ gpios = <&expander1 9 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&dpmac16>;
+ linux,default-trigger = "netdev";
+ };
+
+ led_c2_at: led-sfp-15 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <15>;
+ gpios = <&expander1 5 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&dpmac7>;
+ linux,default-trigger = "netdev";
+ };
+
+ led_c2_ab: led-sfp-16 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <16>;
+ gpios = <&expander1 6 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&dpmac18>;
+ linux,default-trigger = "netdev";
+ };
+
+ led_c3_bt: led-sfp-17 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <17>;
+ gpios = <&expander1 14 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&dpmac10>;
+ linux,default-trigger = "netdev";
+ };
+
+ led_c3_bb: led-sfp-18 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <18>;
+ gpios = <&expander1 13 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&dpmac14>;
+ linux,default-trigger = "netdev";
+ };
+
+ led_c3_at: led-sfp-19 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <19>;
+ gpios = <&expander1 11 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&dpmac9>;
+ linux,default-trigger = "netdev";
+ };
+
+ led_c3_ab: led-sfp-20 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <20>;
+ gpios = <&expander1 12 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&dpmac13>;
+ linux,default-trigger = "netdev";
+ };
+
+ led-status {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <0>;
+ gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-status-twin {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <1>;
+ gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-fault {
+ color = <LED_COLOR_ID_YELLOW>;
+ default-state = "off";
+ function = LED_FUNCTION_FAULT;
+ function-enumerator = <0>;
+ gpios = <&gpio2 11 GPIO_ACTIVE_LOW>;
+ panic-indicator;
+ };
+
+ led-fault-twin {
+ color = <LED_COLOR_ID_YELLOW>;
+ default-state = "off";
+ function = LED_FUNCTION_FAULT;
+ function-enumerator = <1>;
+ gpios = <&gpio2 9 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ mux-controller {
+ compatible = "gpio-mux";
+ #mux-control-cells = <0>;
+ /*
+ * This gpio controlled mux can route the tacho signals of 6 PWM FAN connectors
+ * to the tacho inputs of both CEX-7 modules (twins).
+ *
+ * The first twin controls this mux and monitors four fan connectors, two intended
+ * for itself, and two for the OCP card.
+ *
+ * The second twin monitors only two fan connectors intended for itself.
+ *
+ * The table below maps selector GPIO states to monitored fan connector per twin:
+ *
+ * | SEL1 | SEL0 | Twin 1 | Twin 2 |
+ * | ---: | ---: | :------| ------ |
+ * | 0 | 0 | J10 | J5024 |
+ * | 0 | 1 | J5016 | J5024 |
+ * | 1 | 0 | J5026 | J5025 |
+ * | 1 | 1 | J5013 | J5025 |
+ */
+ mux-gpios = <&expander0 8 GPIO_ACTIVE_HIGH>, /* SEL0 */
+ <&expander0 15 GPIO_ACTIVE_HIGH>; /* SEL1 */
+ };
+
+ ht_c3_bt_sfp: sfp-1 {
+ compatible = "sff,sfp";
+ i2c-bus = <&htwins_sfp_c3_bt_i2c>;
+ maximum-power-milliwatt = <2000>;
+ mod-def0-gpios = <&expander2 13 GPIO_ACTIVE_LOW>;
+ };
+
+ ht_c3_bb_sfp: sfp-2 {
+ compatible = "sff,sfp";
+ i2c-bus = <&htwins_sfp_c3_bb_i2c>;
+ maximum-power-milliwatt = <2000>;
+ mod-def0-gpios = <&expander2 14 GPIO_ACTIVE_LOW>;
+ };
+
+ ht_c3_at_sfp: sfp-3 {
+ compatible = "sff,sfp";
+ i2c-bus = <&htwins_sfp_c3_at_i2c>;
+ maximum-power-milliwatt = <2000>;
+ mod-def0-gpios = <&expander2 11 GPIO_ACTIVE_LOW>;
+ };
+
+ ht_c3_ab_sfp: sfp-4 {
+ compatible = "sff,sfp";
+ i2c-bus = <&htwins_sfp_c3_ab_i2c>;
+ maximum-power-milliwatt = <2000>;
+ mod-def0-gpios = <&expander2 12 GPIO_ACTIVE_LOW>;
+ };
+
+ c1_bt_sfp: sfp-9 {
+ compatible = "sff,sfp";
+ i2c-bus = <&twins_sfp_c1_bt_i2c>;
+ maximum-power-milliwatt = <2000>;
+ mod-def0-gpios = <&expander0 3 GPIO_ACTIVE_LOW>;
+ };
+
+ c1_bb_sfp: sfp-10 {
+ compatible = "sff,sfp";
+ i2c-bus = <&twins_sfp_c1_bb_i2c>;
+ maximum-power-milliwatt = <2000>;
+ mod-def0-gpios = <&expander0 4 GPIO_ACTIVE_LOW>;
+ };
+
+ c1_at_sfp: sfp-11 {
+ compatible = "sff,sfp";
+ i2c-bus = <&twins_sfp_c1_at_i2c>;
+ maximum-power-milliwatt = <2000>;
+ mod-def0-gpios = <&expander0 1 GPIO_ACTIVE_LOW>;
+ };
+
+ c1_ab_sfp: sfp-12 {
+ compatible = "sff,sfp";
+ i2c-bus = <&twins_sfp_c1_ab_i2c>;
+ maximum-power-milliwatt = <2000>;
+ mod-def0-gpios = <&expander0 2 GPIO_ACTIVE_LOW>;
+ };
+
+ c2_bt_sfp: sfp-13 {
+ compatible = "sff,sfp";
+ i2c-bus = <&twins_sfp_c2_bt_i2c>;
+ maximum-power-milliwatt = <2000>;
+ mod-def0-gpios = <&expander0 9 GPIO_ACTIVE_LOW>;
+ };
+
+ c2_bb_sfp: sfp-14 {
+ compatible = "sff,sfp";
+ i2c-bus = <&twins_sfp_c2_bb_i2c>;
+ maximum-power-milliwatt = <2000>;
+ mod-def0-gpios = <&expander0 10 GPIO_ACTIVE_LOW>;
+ };
+
+ c2_at_sfp: sfp-15 {
+ compatible = "sff,sfp";
+ i2c-bus = <&twins_sfp_c2_at_i2c>;
+ maximum-power-milliwatt = <2000>;
+ mod-def0-gpios = <&expander0 5 GPIO_ACTIVE_LOW>;
+ };
+
+ c2_ab_sfp: sfp-16 {
+ compatible = "sff,sfp";
+ i2c-bus = <&twins_sfp_c2_ab_i2c>;
+ maximum-power-milliwatt = <2000>;
+ mod-def0-gpios = <&expander0 6 GPIO_ACTIVE_LOW>;
+ };
+
+ c3_bt_sfp: sfp-17 {
+ compatible = "sff,sfp";
+ i2c-bus = <&twins_sfp_c3_bt_i2c>;
+ maximum-power-milliwatt = <2000>;
+ mod-def0-gpios = <&expander0 13 GPIO_ACTIVE_LOW>;
+ };
+
+ c3_bb_sfp: sfp-18 {
+ compatible = "sff,sfp";
+ i2c-bus = <&twins_sfp_c3_bb_i2c>;
+ maximum-power-milliwatt = <2000>;
+ mod-def0-gpios = <&expander0 14 GPIO_ACTIVE_LOW>;
+ };
+
+ c3_at_sfp: sfp-19 {
+ compatible = "sff,sfp";
+ i2c-bus = <&twins_sfp_c3_at_i2c>;
+ maximum-power-milliwatt = <2000>;
+ mod-def0-gpios = <&expander0 11 GPIO_ACTIVE_LOW>;
+ };
+
+ c3_ab_sfp: sfp-20 {
+ compatible = "sff,sfp";
+ i2c-bus = <&twins_sfp_c3_ab_i2c>;
+ maximum-power-milliwatt = <2000>;
+ mod-def0-gpios = <&expander0 12 GPIO_ACTIVE_LOW>;
+ };
+};
+
+/*
+ * This board supports industrial grade temperatures,
+ * the LX2160A SoC maximum junction temperature is 105°C.
+ *
+ * Raise thermal thresholds to allow operation near maximum temperature.
+ */
+&ccn_dpaa_alert {
+ temperature = <100000>;
+};
+
+&ccn_dpaa_crit {
+ temperature = <105000>;
+};
+
+&cluster2_3_alert {
+ temperature = <100000>;
+};
+
+&cluster2_3_crit {
+ temperature = <105000>;
+};
+
+&cluster4_alert {
+ temperature = <100000>;
+};
+
+&cluster4_crit {
+ temperature = <105000>;
+};
+
+&cluster5_alert {
+ temperature = <100000>;
+};
+
+&cluster5_crit {
+ temperature = <105000>;
+};
+
+&cluster6_7_alert {
+ temperature = <100000>;
+};
+
+&cluster6_7_crit {
+ temperature = <105000>;
+};
+
+&dce_qbman_alert {
+ temperature = <100000>;
+};
+
+&dce_qbman_crit {
+ temperature = <105000>;
+};
+
+/* sfp port 11 */
+&dpmac3 {
+ managed = "in-band-status";
+ phys = <&serdes_1 7>;
+ sfp = <&c1_at_sfp>;
+};
+
+/* sfp port 9 */
+&dpmac4 {
+ managed = "in-band-status";
+ phys = <&serdes_1 6>;
+ sfp = <&c1_bt_sfp>;
+};
+
+/* sfp port 1 */
+&dpmac5 {
+ managed = "in-band-status";
+ phys = <&serdes_1 5>;
+ sfp = <&ht_c3_bt_sfp>;
+};
+
+/* sfp port 3 */
+&dpmac6 {
+ managed = "in-band-status";
+ phys = <&serdes_1 4>;
+ sfp = <&ht_c3_at_sfp>;
+};
+
+/* sfp port 15 */
+&dpmac7 {
+ managed = "in-band-status";
+ phys = <&serdes_1 3>;
+ sfp = <&c2_at_sfp>;
+};
+
+/* sfp port 13 */
+&dpmac8 {
+ managed = "in-band-status";
+ phys = <&serdes_1 2>;
+ sfp = <&c2_bt_sfp>;
+};
+
+/* sfp port 19 */
+&dpmac9 {
+ managed = "in-band-status";
+ phys = <&serdes_1 1>;
+ sfp = <&c3_at_sfp>;
+};
+
+/* sfp port 17 */
+&dpmac10 {
+ managed = "in-band-status";
+ phys = <&serdes_1 0>;
+ sfp = <&c3_bt_sfp>;
+};
+
+/* sfp port 4 */
+&dpmac11 {
+ managed = "in-band-status";
+ phys = <&serdes_2 0>;
+ sfp = <&ht_c3_ab_sfp>;
+};
+
+/* sfp port 12 */
+&dpmac12 {
+ managed = "in-band-status";
+ phys = <&serdes_2 1>;
+ sfp = <&c1_ab_sfp>;
+};
+
+/* sfp port 20 */
+&dpmac13 {
+ managed = "in-band-status";
+ phys = <&serdes_2 6>;
+ sfp = <&c3_ab_sfp>;
+};
+
+/* sfp port 18 */
+&dpmac14 {
+ managed = "in-band-status";
+ phys = <&serdes_2 7>;
+ sfp = <&c3_bb_sfp>;
+};
+
+/* sfp port 2 */
+&dpmac15 {
+ managed = "in-band-status";
+ phys = <&serdes_2 4>;
+ sfp = <&ht_c3_bb_sfp>;
+};
+
+/* sfp port 14 */
+&dpmac16 {
+ managed = "in-band-status";
+ phys = <&serdes_2 5>;
+ sfp = <&c2_bb_sfp>;
+};
+
+/* sfp port 10 */
+&dpmac17 {
+ /* override connection to on-COM phy */
+ /delete-property/ phy-handle;
+ /delete-property/ phy-connection-type;
+ managed = "in-band-status";
+ phys = <&serdes_2 2>;
+ sfp = <&c1_bb_sfp>;
+};
+
+/* sfp port 16 */
+&dpmac18 {
+ managed = "in-band-status";
+ phys = <&serdes_2 3>;
+ sfp = <&c2_ab_sfp>;
+};
+
+&esdhc0 {
+ pinctrl-0 = <&esdhc0_cd_wp_pins>, <&esdhc0_cmd_data30_clk_vsel_pins>;
+ pinctrl-names = "default";
+ /*
+ * Disable 1.8V modes so that microsd state is same between
+ * power-on-reset, u-boot and linux.
+ * This avoids sporadic read errors after hard reset with some cards.
+ */
+ no-1-8-v;
+ status = "okay";
+};
+
+&i2c2 {
+ expander0: gpio@20 {
+ compatible = "nxp,pca9555";
+ reg = <0x20>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ expander1: gpio@21 {
+ compatible = "nxp,pca9555";
+ reg = <0x21>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ expander2: gpio@24 {
+ compatible = "nxp,pca9555";
+ reg = <0x24>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ expander3: gpio@25 {
+ compatible = "nxp,pca9555";
+ reg = <0x25>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ /* Half twins configuration; take over c3 from the other twin side */
+ i2c-mux@73 {
+ compatible = "nxp,pca9547";
+ reg = <0x73>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-mux-idle-disconnect;
+
+ htwins_sfp_c3_at_i2c: i2c@3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ htwins_sfp_c3_ab_i2c: i2c@4 {
+ reg = <4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ htwins_sfp_c3_bt_i2c: i2c@5 {
+ reg = <5>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ htwins_sfp_c3_bb_i2c: i2c@6 {
+ reg = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ i2c-mux@76 {
+ compatible = "nxp,pca9547";
+ reg = <0x76>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-mux-idle-disconnect;
+
+ twins_sfp_c1_at_i2c: i2c@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ twins_sfp_c1_ab_i2c: i2c@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ twins_sfp_c1_bt_i2c: i2c@3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ twins_sfp_c1_bb_i2c: i2c@4 {
+ reg = <4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ twins_sfp_c2_at_i2c: i2c@5 {
+ reg = <5>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ twins_sfp_c2_ab_i2c: i2c@6 {
+ reg = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9547";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-mux-idle-disconnect;
+
+ twins_sfp_c2_bt_i2c: i2c@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ twins_sfp_c2_bb_i2c: i2c@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ twins_sfp_c3_at_i2c: i2c@3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ twins_sfp_c3_ab_i2c: i2c@4 {
+ reg = <4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ twins_sfp_c3_bt_i2c: i2c@5 {
+ reg = <5>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ twins_sfp_c3_bb_i2c: i2c@6 {
+ reg = <6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
+
+&pcie5 {
+ status = "okay";
+};
+
+&pcs_mdio3 {
+ status = "okay";
+};
+
+&pcs_mdio4 {
+ status = "okay";
+};
+
+&pcs_mdio5 {
+ status = "okay";
+};
+
+&pcs_mdio6 {
+ status = "okay";
+};
+
+&pcs_mdio7 {
+ status = "okay";
+};
+
+&pcs_mdio8 {
+ status = "okay";
+};
+
+&pcs_mdio9 {
+ status = "okay";
+};
+
+&pcs_mdio10 {
+ status = "okay";
+};
+
+&pcs_mdio11 {
+ status = "okay";
+};
+
+&pcs_mdio12 {
+ status = "okay";
+};
+
+&pcs_mdio13 {
+ status = "okay";
+};
+
+&pcs_mdio14 {
+ status = "okay";
+};
+
+&pcs_mdio15 {
+ status = "okay";
+};
+
+&pcs_mdio16 {
+ status = "okay";
+};
+
+&pcs_mdio17 {
+ status = "okay";
+};
+
+&pcs_mdio18 {
+ status = "okay";
+};
+
+&rgmii_phy1 {
+ /*
+ * COM has a phy at address 1 connected to SoC Ethernet Controller 1.
+ * It competes for WRIOP MAC17, and no connector has been wired.
+ */
+ status = "disabled";
+};
+
+&serdes_2 {
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&wriop_alert {
+ temperature = <100000>;
+};
+
+&wriop_crit {
+ temperature = <105000>;
+};
--
2.51.0
^ permalink raw reply related
* [PATCH v6 01/10] arm64: dts: lx2160a: extend 32-bit, and add 64-bit pci regions
From: Josua Mayer @ 2026-05-12 14:38 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
LX2160 SoC pci-e controller supports 64-bit memory regions up to 16GB,
32-bit regions up to 3GB and 16-bit regions up to 64k.
For each pci-e controller:
- extend the existing 32-bit regions to 3GB size
- drop IORESOURCE_BUSY flag
- add 64-bit region
See [1] and [2] for boot messages showing ranges before and after.
IORESOURCE_BUSY is dropped since it has no effect when specified in dts.
Setting IORESOURCE_MEM_64 flag on 64-bit region causes bootloader pci
patching logic and bar initialisation to fail [4], therefore it is
omitted.
For LX2160A Silicon revision 1, the 16GB 64-bit area is split into 4
pieces, because the layerscape pcie driver fails to program atu for
larger ranges [3].
Similar memory allocation with similar flags was tested with UEFI and ACPI
on pcie3 and pcie5, on a variety of nxp vendor fork versions.
This patch was tested on Linux v7.1-rc1 and u-boot, with two pcie cards:
- pcie5: Radeon Pro WX2100
- pcie3: ADATA NVME
This fixes allocation of large, and 64-bit BARs as requested by many pci
cards - especially graphics processors or AI accelerators, e.g.:
[ 2.941187] pci 0000:01:00.0: BAR 0: no space for [mem size 0x200000000 64bit pref]
[ 2.948834] pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x200000000 64bit pref]
[1] example of new allocations (pcie5):
[ 1.182745] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges:
[ 1.182760] layerscape-pcie 3800000.pcie: MEM 0xa400000000..0xa7ffffffff -> 0xa400000000
[ 1.182771] layerscape-pcie 3800000.pcie: MEM 0xa040000000..0xa0ffffffff -> 0x0040000000
[ 1.182778] layerscape-pcie 3800000.pcie: IO 0xa000010000..0xa00001ffff -> 0x0000000000
[ 1.183642] layerscape-pcie 3800000.pcie: iATU: unroll F, 256 ob, 24 ib, align 4K, limit 4G
[ 1.385429] layerscape-pcie 3800000.pcie: PCIe Gen.3 x8 link up
[ 1.385481] layerscape-pcie 3800000.pcie: PCI host bridge to bus 0001:00
[ 1.385484] pci_bus 0001:00: root bus resource [bus 00-ff]
[ 1.385488] pci_bus 0001:00: root bus resource [mem 0xa400000000-0xa7ffffffff pref]
[ 1.385491] pci_bus 0001:00: root bus resource [mem 0xa040000000-0xa0ffffffff] (bus address [0x40000000-0xffffffff])
[ 1.385494] pci_bus 0001:00: root bus resource [io 0x10000-0x1ffff] (bus address [0x0000-0xffff])
[ 1.385516] pci 0001:00:00.0: [1957:8d80] type 01 class 0x060400 PCIe Root Port
[ 1.385538] pci 0001:00:00.0: PCI bridge to [bus 01-ff]
[ 1.385544] pci 0001:00:00.0: bridge window [io 0x11000-0x11fff]
[ 1.385548] pci 0001:00:00.0: bridge window [mem 0xa040000000-0xa0502fffff]
[ 1.385605] pci 0001:00:00.0: supports D1 D2
[ 1.385607] pci 0001:00:00.0: PME# supported from D0 D1 D2 D3hot
[ 1.386778] pci 0001:01:00.0: [1002:6995] type 00 class 0x030000 PCIe Legacy Endpoint
[ 1.387336] pci 0001:01:00.0: BAR 0 [mem 0xa040000000-0xa04fffffff 64bit pref]
[ 1.387368] pci 0001:01:00.0: BAR 2 [mem 0xa050000000-0xa0501fffff 64bit pref]
[ 1.387385] pci 0001:01:00.0: BAR 4 [io 0x11000-0x110ff]
[ 1.387402] pci 0001:01:00.0: BAR 5 [mem 0xa050200000-0xa05023ffff]
[ 1.387418] pci 0001:01:00.0: ROM [mem 0xa050240000-0xa05025ffff pref]
[ 1.387493] pci 0001:01:00.0: enabling Extended Tags
[ 1.388960] pci 0001:01:00.0: supports D1 D2
[2] example of previous allocations (pcie5):
[ 1.716744] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges:
[ 1.724060] layerscape-pcie 3800000.pcie: MEM 0xa040000000..0xa07fffffff -> 0x0040000000
[ 1.733277] layerscape-pcie 3800000.pcie: iATU: unroll F, 256 ob, 24 ib, align 4K, limit 4G
[ 1.836220] layerscape-pcie 3800000.pcie: PCIe Gen.3 x8 link up
[ 1.842186] layerscape-pcie 3800000.pcie: PCI host bridge to bus 0001:00
[ 1.848883] pci_bus 0001:00: root bus resource [bus 00-ff]
[ 1.854363] pci_bus 0001:00: root bus resource [mem 0xa040000000-0xa07fffffff] (bus address [0x40000000-0x7fffffff])
[ 1.864892] pci 0001:00:00.0: [1957:8d80] type 01 class 0x060400 PCIe Root Port
[ 1.872216] pci 0001:00:00.0: PCI bridge to [bus 01-ff]
[ 1.877438] pci 0001:00:00.0: bridge window [io 0x1000-0x1fff]
[ 1.883526] pci 0001:00:00.0: bridge window [mem 0xa040000000-0xa0502fffff]
[3] error programming atu beyond 4GB:
[ 1.716762] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges:
[ 1.724080] layerscape-pcie 3800000.pcie: MEM 0xa400000000..0xa7ffffffff -> 0xa400000000
[ 1.732615] layerscape-pcie 3800000.pcie: MEM 0xa040000000..0xa0ffffffff -> 0x0040000000
[ 1.741142] layerscape-pcie 3800000.pcie: IO 0xa010000000..0xa01000ffff -> 0x0000000000
[ 1.750379] layerscape-pcie 3800000.pcie: iATU: unroll F, 256 ob, 24 ib, align 4K, limit 4G
[ 1.759089] layerscape-pcie 3800000.pcie: Failed to set MEM range [mem 0xa400000000-0xa7ffffffff flags 0x2200]
[ 1.769089] layerscape-pcie 3800000.pcie: probe with driver layerscape-pcie failed with error -22
[4] pci bootloaderp atching related errors with IORESOURCE_MEM_64 flag:
[ 0.967809] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges:
[ 0.967830] layerscape-pcie 3800000.pcie: MEM 0xa400000000..0xa7ffffffff -> 0xa400000000
[ 0.967842] layerscape-pcie 3800000.pcie: MEM 0xa040000000..0xa0ffffffff -> 0x0040000000
[ 0.967849] layerscape-pcie 3800000.pcie: IO 0xa000010000..0xa00001ffff -> 0x0000000000
[ 1.169315] pci 0000:01:00.0: [8086:1572] type 00 class 0x020000 PCIe Endpoint
[ 1.169733] pci 0000:01:00.0: BAR 0 [mem 0x00000000-0x00ffffff 64bit pref]
[ 1.169771] pci 0000:01:00.0: BAR 3 [mem 0x00000000-0x00007fff 64bit pref]
[ 1.169796] pci 0000:01:00.0: ROM [mem 0x00000000-0x0007ffff pref]
[ 1.173389] OF: /soc/pcie@3800000: no msi-map translation for id 0x100 on (null)
[ 1.173515] OF: /soc/pcie@3800000: no iommu-map translation for id 0x100 on (null)
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
.../arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi | 30 +++++++++++-------
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 37 ++++++++++++++++++----
2 files changed, 49 insertions(+), 18 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
index f54005e37924b..b5f52f3f84c7d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
@@ -14,8 +14,9 @@ &pcie1 {
0x80 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- ranges = <0x81000000 0x0 0x00000000 0x80 0x00010000 0x0 0x00010000
- 0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>;
+ ranges = <0x42000000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>, /* 64-Bit - prefetchable - 16GB */
+ <0x02000000 0x00 0x40000000 0x80 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
+ <0x01000000 0x00 0x00000000 0x80 0x00010000 0x00 0x00010000>; /* 16-Bit IO Window */
interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "intr";
@@ -30,8 +31,9 @@ &pcie2 {
0x88 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- ranges = <0x81000000 0x0 0x00000000 0x88 0x00010000 0x0 0x00010000
- 0x82000000 0x0 0x40000000 0x88 0x40000000 0x0 0x40000000>;
+ ranges = <0x42000000 0x8c 0x00000000 0x8c 0x00000000 0x04 0x00000000>, /* 64-Bit - prefetchable - 16GB */
+ <0x02000000 0x00 0x40000000 0x88 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
+ <0x01000000 0x00 0x00000000 0x88 0x00010000 0x00 0x00010000>; /* 16-Bit IO Window */
interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "intr";
@@ -46,8 +48,9 @@ &pcie3 {
0x90 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- ranges = <0x81000000 0x0 0x00000000 0x90 0x00010000 0x0 0x00010000
- 0x82000000 0x0 0x40000000 0x90 0x40000000 0x0 0x40000000>;
+ ranges = <0x42000000 0x94 0x00000000 0x94 0x00000000 0x04 0x00000000>, /* 64-Bit - prefetchable - 16GB */
+ <0x02000000 0x00 0x40000000 0x90 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
+ <0x01000000 0x00 0x00000000 0x90 0x00010000 0x00 0x00010000>; /* 16-Bit IO Window */
interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "intr";
@@ -63,8 +66,9 @@ &pcie4 {
0x98 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- ranges = <0x81000000 0x0 0x00000000 0x98 0x00010000 0x0 0x00010000
- 0x82000000 0x0 0x40000000 0x98 0x40000000 0x0 0x40000000>;
+ ranges = <0x42000000 0x9c 0x00000000 0x9c 0x00000000 0x04 0x00000000>, /* 64-Bit - prefetchable - 16GB */
+ <0x02000000 0x00 0x40000000 0x98 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
+ <0x01000000 0x00 0x00000000 0x98 0x00010000 0x00 0x00010000>; /* 16-Bit IO Window */
interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "intr";
@@ -79,8 +83,9 @@ &pcie5 {
0xa0 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- ranges = <0x81000000 0x0 0x00000000 0xa0 0x00010000 0x0 0x00010000
- 0x82000000 0x0 0x40000000 0xa0 0x40000000 0x0 0x40000000>;
+ ranges = <0x42000000 0xa4 0x00000000 0xa4 0x00000000 0x04 0x00000000>, /* 64-Bit - prefetchable - 16GB */
+ <0x02000000 0x00 0x40000000 0xa0 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
+ <0x01000000 0x00 0x00000000 0xa0 0x00010000 0x00 0x00010000>; /* 16-Bit IO Window */
interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "intr";
@@ -95,8 +100,9 @@ &pcie6 {
0xa8 0x00000000 0x0 0x00002000>; /* configuration space */
reg-names = "regs", "config";
- ranges = <0x81000000 0x0 0x00000000 0xa8 0x00010000 0x0 0x00010000
- 0x82000000 0x0 0x40000000 0xa8 0x40000000 0x0 0x40000000>;
+ ranges = <0x42000000 0xac 0x00000000 0xac 0x00000000 0x04 0x00000000>, /* 64-Bit - prefetchable - 16GB */
+ <0x02000000 0x00 0x40000000 0xa8 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
+ <0x01000000 0x00 0x00000000 0xa8 0x00010000 0x00 0x00010000>; /* 16-Bit IO Window */
interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "intr";
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 479982948ee53..3f63fbf2485e5 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -1193,7 +1193,12 @@ pcie1: pcie@3400000 {
apio-wins = <8>;
ppio-wins = <8>;
bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ ranges = <0x42000000 0x87 0x00000000 0x87 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x86 0x00000000 0x86 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x85 0x00000000 0x85 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x84 0x00000000 0x84 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x02000000 0x00 0x40000000 0x80 0x40000000 0x00 0xc0000000>; /* 32-Bit - non-prefetchable */
+
msi-parent = <&its 0>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
@@ -1221,7 +1226,11 @@ pcie2: pcie@3500000 {
apio-wins = <8>;
ppio-wins = <8>;
bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0x88 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ ranges = <0x42000000 0x8f 0x00000000 0x8f 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x8e 0x00000000 0x8e 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x8d 0x00000000 0x8d 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x8c 0x00000000 0x8c 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x02000000 0x00 0x40000000 0x88 0x40000000 0x00 0xc0000000>; /* 32-Bit - non-prefetchable */
msi-parent = <&its 0>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
@@ -1249,7 +1258,11 @@ pcie3: pcie@3600000 {
apio-wins = <256>;
ppio-wins = <24>;
bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0x90 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ ranges = <0x42000000 0x97 0x00000000 0x97 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x96 0x00000000 0x96 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x95 0x00000000 0x95 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x94 0x00000000 0x94 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x02000000 0x00 0x40000000 0x90 0x40000000 0x00 0xc0000000>; /* 32-Bit - non-prefetchable */
msi-parent = <&its 0>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
@@ -1277,7 +1290,11 @@ pcie4: pcie@3700000 {
apio-wins = <8>;
ppio-wins = <8>;
bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0x98 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ ranges = <0x42000000 0x9f 0x00000000 0x9f 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x9e 0x00000000 0x9e 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x9d 0x00000000 0x9d 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0x9c 0x00000000 0x9c 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x02000000 0x00 0x40000000 0x98 0x40000000 0x00 0xc0000000>; /* 32-Bit - non-prefetchable */
msi-parent = <&its 0>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
@@ -1305,7 +1322,11 @@ pcie5: pcie@3800000 {
apio-wins = <256>;
ppio-wins = <24>;
bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0xa0 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ ranges = <0x42000000 0xa7 0x00000000 0xa7 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0xa6 0x00000000 0xa6 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0xa5 0x00000000 0xa5 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0xa4 0x00000000 0xa4 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x02000000 0x00 0x40000000 0xa0 0x40000000 0x00 0xc0000000>; /* 32-Bit - non-prefetchable */
msi-parent = <&its 0>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
@@ -1333,7 +1354,11 @@ pcie6: pcie@3900000 {
apio-wins = <8>;
ppio-wins = <8>;
bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0xa8 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ ranges = <0x42000000 0xaf 0x00000000 0xaf 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0xae 0x00000000 0xae 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0xad 0x00000000 0xad 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x42000000 0xac 0x00000000 0xac 0x00000000 0x01 0x00000000>, /* 64-Bit - prefetchable - 4GB chunk */
+ <0x02000000 0x00 0x40000000 0xa8 0x40000000 0x00 0xc0000000>; /* 32-Bit - non-prefetchable */
msi-parent = <&its 0>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
--
2.51.0
^ permalink raw reply related
* [PATCH v6 08/10] arm64: dts: lx2160a: add labels to thermal trip-point nodes
From: Josua Mayer @ 2026-05-12 14:39 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
LX2160A SoC dtsi defines rather conservative thermal trip points,
alert at 85°C and critical at 95°C.
This is okay for most boards, however the SoC maximum junction
temperature is 105°C in both commercial and industrial version.
Industrial grade boards need to change the thresholds to avoid premature
thermal shutdown in high-temeprature environments.
Add labels to all thermal trip point nodes, enabling board dts to
reference them and modify properties.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 3f63fbf2485e5..e2de7e596d2b6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -499,13 +499,13 @@ ddr-ctrl5-thermal {
thermal-sensors = <&tmu 1>;
trips {
- ddr-cluster5-alert {
+ cluster5_alert: ddr-cluster5-alert {
temperature = <85000>;
hysteresis = <2000>;
type = "passive";
};
- ddr-cluster5-crit {
+ cluster5_crit: ddr-cluster5-crit {
temperature = <95000>;
hysteresis = <2000>;
type = "critical";
@@ -519,13 +519,13 @@ wriop-thermal {
thermal-sensors = <&tmu 2>;
trips {
- wriop-alert {
+ wriop_alert: wriop-alert {
temperature = <85000>;
hysteresis = <2000>;
type = "passive";
};
- wriop-crit {
+ wriop_crit: wriop-crit {
temperature = <95000>;
hysteresis = <2000>;
type = "critical";
@@ -539,13 +539,13 @@ dce-thermal {
thermal-sensors = <&tmu 3>;
trips {
- dce-qbman-alert {
+ dce_qbman_alert: dce-qbman-alert {
temperature = <85000>;
hysteresis = <2000>;
type = "passive";
};
- dce-qbman-crit {
+ dce_qbman_crit: dce-qbman-crit {
temperature = <95000>;
hysteresis = <2000>;
type = "critical";
@@ -559,13 +559,13 @@ ccn-thermal {
thermal-sensors = <&tmu 4>;
trips {
- ccn-dpaa-alert {
+ ccn_dpaa_alert: ccn-dpaa-alert {
temperature = <85000>;
hysteresis = <2000>;
type = "passive";
};
- ccn-dpaa-crit {
+ ccn_dpaa_crit: ccn-dpaa-crit {
temperature = <95000>;
hysteresis = <2000>;
type = "critical";
@@ -579,13 +579,13 @@ cluster4-thermal {
thermal-sensors = <&tmu 5>;
trips {
- clust4-hsio3-alert {
+ cluster4_alert: clust4-hsio3-alert {
temperature = <85000>;
hysteresis = <2000>;
type = "passive";
};
- clust4-hsio3-crit {
+ cluster4_crit: clust4-hsio3-crit {
temperature = <95000>;
hysteresis = <2000>;
type = "critical";
@@ -599,13 +599,13 @@ cluster2-3-thermal {
thermal-sensors = <&tmu 6>;
trips {
- cluster2-3-alert {
+ cluster2_3_alert: cluster2-3-alert {
temperature = <85000>;
hysteresis = <2000>;
type = "passive";
};
- cluster2-3-crit {
+ cluster2_3_crit: cluster2-3-crit {
temperature = <95000>;
hysteresis = <2000>;
type = "critical";
--
2.51.0
^ permalink raw reply related
* [PATCH v6 09/10] arm64: dts: lx2160a-cex7: add labels to i2c buses behind mux
From: Josua Mayer @ 2026-05-12 14:39 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
The LX2160 CEX-7 module integrates in i2c bus multiplexer. Some of its
channel nodes have labels, others do not.
Add descriptive labels to the unlabeled channels, allowing other board
dts to reference them for example in aliases.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
index 7df93bb37d13c..ce63545abb6e6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
@@ -58,7 +58,7 @@ i2c-mux@77 {
#size-cells = <0>;
reg = <0x77>;
- i2c@0 {
+ ddr_i2c: i2c@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
@@ -84,7 +84,7 @@ eeprom@57 {
};
};
- i2c@1 {
+ fan_i2c: i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
@@ -95,7 +95,7 @@ fan-temperature-ctrlr@18 {
};
};
- i2c@2 {
+ power_i2c: i2c@2 {
#address-cells = <1>;
#size-cells = <0>;
reg = <2>;
@@ -106,7 +106,7 @@ regulator@5c {
};
};
- i2c@3 {
+ i2c_smb: i2c@3 {
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
--
2.51.0
^ permalink raw reply related
* [PATCH v6 07/10] arm64: dts: lx2160a-clearfog-itx: move shared includes to dts
From: Josua Mayer @ 2026-05-12 14:39 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
Originally includes were defined hierarchically:
- CEX-7 Module includes SoC
- Clearfog-CX & Honeycomb common parts include CEX-7 Module
- Boards include common parts
This makes it difficult to modify the includes on a per-board level,
e.g. when adding a new board based on CEX-7 module but revision 2 SoC
(which now has its own soc dtsi).
Move includes of both SoC and CEX-7 module out of common parts and into
each board dts.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi | 2 --
arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-cx.dts | 2 ++
arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi | 1 -
arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts | 2 ++
4 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
index 56b74837ddd48..7df93bb37d13c 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
@@ -4,8 +4,6 @@
//
// Copyright 2019 SolidRun Ltd.
-#include "fsl-lx2160a.dtsi"
-
/ {
model = "SolidRun LX2160A COM Express Type 7 module";
compatible = "solidrun,lx2160a-cex7", "fsl,lx2160a";
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-cx.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-cx.dts
index 86a9b771428dc..802d7611c6479 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-cx.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-cx.dts
@@ -6,6 +6,8 @@
/dts-v1/;
+#include "fsl-lx2160a.dtsi"
+#include "fsl-lx2160a-cex7.dtsi"
#include "fsl-lx2160a-clearfog-itx.dtsi"
/ {
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
index 6388bd60ffdf5..170e5b0034f19 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
@@ -5,7 +5,6 @@
//
// Copyright 2019 SolidRun Ltd.
-#include "fsl-lx2160a-cex7.dtsi"
#include <dt-bindings/input/linux-event-codes.h>
/ {
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts
index fe19f3009ea58..2b1e13053422b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts
@@ -6,6 +6,8 @@
/dts-v1/;
+#include "fsl-lx2160a.dtsi"
+#include "fsl-lx2160a-cex7.dtsi"
#include "fsl-lx2160a-clearfog-itx.dtsi"
/ {
--
2.51.0
^ permalink raw reply related
* [PATCH v6 04/10] arm64: dts: lx2162a-clearfog: specify sfp ports led colour and function
From: Josua Mayer @ 2026-05-12 14:38 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
The LX2162A Clearfog board has a green LED on each of four SFP ports.
Describe in device-tree that their colour is green and function "lan".
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
index 6fd85a5cac94e..99ee2b1c0f13b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
@@ -6,6 +6,8 @@
/dts-v1/;
+#include <dt-bindings/leds/common.h>
+
#include "fsl-lx2160a-rev2.dtsi"
#include "fsl-lx2162a-sr-som.dtsi"
@@ -38,6 +40,9 @@ leds {
compatible = "gpio-leds";
led_sfp_at: led-sfp-at {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <1>;
gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* PROC_IRQ5 */
default-state = "off";
linux,default-trigger = "netdev";
@@ -45,6 +50,9 @@ led_sfp_at: led-sfp-at {
};
led_sfp_ab: led-sfp-ab {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <2>;
gpios = <&gpio2 11 GPIO_ACTIVE_HIGH>; /* PROC_IRQ11 */
default-state = "off";
linux,default-trigger = "netdev";
@@ -52,6 +60,9 @@ led_sfp_ab: led-sfp-ab {
};
led_sfp_bt: led-sfp-bt {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <3>;
gpios = <&gpio2 13 GPIO_ACTIVE_HIGH>; /* EVT1_B */
default-state = "off";
linux,default-trigger = "netdev";
@@ -59,6 +70,9 @@ led_sfp_bt: led-sfp-bt {
};
led_sfp_bb: led-sfp-bb {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <4>;
gpios = <&gpio2 14 GPIO_ACTIVE_HIGH>; /* EVT2_B */
default-state = "off";
linux,default-trigger = "netdev";
--
2.51.0
^ permalink raw reply related
* [PATCH v6 06/10] arm64: dts: lx2160a-clearfog-itx: remove redundant dts version tag
From: Josua Mayer @ 2026-05-12 14:39 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
The dts version tag should only appear in the top level dts file.
Since the cex-7 module and clearfog-itx are shared code intended for
inclusion, drop their dts version tags.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi | 2 --
arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi | 2 --
2 files changed, 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
index 90956ffb8ea9a..56b74837ddd48 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
@@ -4,8 +4,6 @@
//
// Copyright 2019 SolidRun Ltd.
-/dts-v1/;
-
#include "fsl-lx2160a.dtsi"
/ {
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
index 580ee9b3026e3..6388bd60ffdf5 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
@@ -5,8 +5,6 @@
//
// Copyright 2019 SolidRun Ltd.
-/dts-v1/;
-
#include "fsl-lx2160a-cex7.dtsi"
#include <dt-bindings/input/linux-event-codes.h>
--
2.51.0
^ permalink raw reply related
* [PATCH v6 00/10] arm64: dts: lx2160a: cleanups, add new board, large pci bars
From: Josua Mayer @ 2026-05-12 14:38 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
This patch-set is made of 3 parts:
1. Extend lx2160 pci node ranges to support 16-bit, and large 64-bit
bars. LX2160A SoC has always supported this, and SolidRun carried it
in vendor fork for several years now.
2. Cleanup some status properties in LX2162A Clearfog dts.
3. Add description for solidrun twins baord with single LX2160A CEX-7
module.
There are no inter-dependencies between the parts and they may apply
individually if necessary.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Changes in v6:
- Add explanation why IORESOURCE_MEM_64 flag is not set.
- Fixed pci bar size 1GB/4GB typo in pcie4 node.
- Enable twins board pcie controller node.
- Fixed function-enumerator value for led-sfp-3.
- Reverted accidental change of clearfog-cx soc revision.
- Link to v5: https://lore.kernel.org/r/20260510-lx2160-pci-v5-0-540b83852227@solid-run.com
Changes in v5:
- add new board
- add cleanups to existing solidrun boards
- pci: extend to lx2160a-rev2 dtsi
- pci: remove non-standard flags to pass dtbs_check
- Link to v4: https://lore.kernel.org/r/20260302-lx2160-pci-v4-1-30a30dc47ec6@solid-run.com
Changes in v4
- dropped accidentally added empty line at top of file:
- actually drop RFC prefix
- rebased on v7.0-rc1 and re-tested on v7.0-rc2
- Link to v3: https://lore.kernel.org/r/20250907-lx2160-pci-v3-1-bb66cc41b8f9@solid-run.com
Changes in v3:
- dropped rfc label
- adjusted flags
- split 16GB area into 4x4GB sections.
- enhance commit description with details explanation
- Link to v2: https://lore.kernel.org/r/20240429-lx2160-pci-v2-1-1b94576d6263@solid-run.com
Changes in v2:
- adjusted flags to fix several errors during probe and bar allocation
- explicitly tested with 2 pci cards on Debian (Linux 6.1)
- still rfc because a limitation in designware pci driver
- Link to v1: https://lore.kernel.org/r/20240321-lx2160-pci-v1-1-3673708f7eb6@solid-run.com
---
Josua Mayer (10):
arm64: dts: lx2160a: extend 32-bit, and add 64-bit pci regions
arm64: dts: lx2162a-clearfog: use rev2 SoC dtsi
arm64: dts: lx2162a-clearfog: cleanup superfluous status properties
arm64: dts: lx2162a-clearfog: specify sfp ports led colour and function
dt-bindings: arm: fsl: Add solidrun lx2160a twins board
arm64: dts: lx2160a-clearfog-itx: remove redundant dts version tag
arm64: dts: lx2160a-clearfog-itx: move shared includes to dts
arm64: dts: lx2160a: add labels to thermal trip-point nodes
arm64: dts: lx2160a-cex7: add labels to i2c buses behind mux
arm64: dts: Add support for LX2160 Twins board in single configuration
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
arch/arm64/boot/dts/freescale/Makefile | 2 +
.../arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi | 12 +-
.../boot/dts/freescale/fsl-lx2160a-clearfog-cx.dts | 2 +
.../dts/freescale/fsl-lx2160a-clearfog-itx.dtsi | 3 -
.../boot/dts/freescale/fsl-lx2160a-half-twins.dts | 826 +++++++++++++++++++++
.../boot/dts/freescale/fsl-lx2160a-honeycomb.dts | 2 +
.../arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi | 30 +-
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 61 +-
.../boot/dts/freescale/fsl-lx2162a-clearfog.dts | 37 +-
10 files changed, 913 insertions(+), 63 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20240118-lx2160-pci-4bdb196e58f3
Best regards,
--
Josua Mayer <josua@solid-run.com>
^ permalink raw reply
* [PATCH v6 03/10] arm64: dts: lx2162a-clearfog: cleanup superfluous status properties
From: Josua Mayer @ 2026-05-12 14:38 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
The SoC dtsi has always enabled serdes block 1, enabled dpmac and
disabled pcie nodes.
Drop the superfluous status properties on these nodes.
Further drop crypto alias as SoM dtsi already set it.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
.../boot/dts/freescale/fsl-lx2162a-clearfog.dts | 21 ---------------------
1 file changed, 21 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
index f95e9c19bfc75..6fd85a5cac94e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
@@ -14,7 +14,6 @@ / {
compatible = "solidrun,lx2162a-clearfog", "solidrun,lx2162a-som", "fsl,lx2160a";
aliases {
- crypto = &crypto;
i2c0 = &i2c0;
i2c1 = &i2c2;
i2c2 = &i2c4;
@@ -124,42 +123,36 @@ &dpmac11 {
phys = <&serdes_2 0>;
phy-handle = <ðernet_phy3>;
phy-connection-type = "sgmii";
- status = "okay";
};
&dpmac12 {
phys = <&serdes_2 1>;
phy-handle = <ðernet_phy1>;
phy-connection-type = "sgmii";
- status = "okay";
};
&dpmac13 {
phys = <&serdes_2 6>;
phy-handle = <ðernet_phy6>;
phy-connection-type = "sgmii";
- status = "okay";
};
&dpmac14 {
phys = <&serdes_2 7>;
phy-handle = <ðernet_phy8>;
phy-connection-type = "sgmii";
- status = "okay";
};
&dpmac15 {
phys = <&serdes_2 4>;
phy-handle = <ðernet_phy4>;
phy-connection-type = "sgmii";
- status = "okay";
};
&dpmac16 {
phys = <&serdes_2 5>;
phy-handle = <ðernet_phy2>;
phy-connection-type = "sgmii";
- status = "okay";
};
&dpmac17 {
@@ -170,14 +163,12 @@ &dpmac17 {
phys = <&serdes_2 2>;
phy-handle = <ðernet_phy5>;
phy-connection-type = "sgmii";
- status = "okay";
};
&dpmac18 {
phys = <&serdes_2 3>;
phy-handle = <ðernet_phy7>;
phy-connection-type = "sgmii";
- status = "okay";
};
&emdio1 {
@@ -314,14 +305,6 @@ pcieclk_i2c: i2c@2 {
};
};
-&pcie3 {
- status = "disabled";
-};
-
-&pcie4 {
- status = "disabled";
-};
-
&pcs_mdio3 {
status = "okay";
};
@@ -370,10 +353,6 @@ &pcs_mdio18 {
status = "okay";
};
-&serdes_1 {
- status = "okay";
-};
-
&serdes_2 {
status = "okay";
};
--
2.51.0
^ permalink raw reply related
* [PATCH v6 02/10] arm64: dts: lx2162a-clearfog: use rev2 SoC dtsi
From: Josua Mayer @ 2026-05-12 14:38 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Yazan Shhady, Jon Nettleton, linux-arm-kernel, devicetree,
linux-kernel, imx, Josua Mayer
In-Reply-To: <20260512-lx2160-pci-v6-0-d0ff72d3c983@solid-run.com>
LX2160A and LX2162A are different pakages of the same silicon.
While LX2160A had two revisions, LX2162A was released later based on
LX2160A revision 2.
Commit a8fe6c8dfc40 ("arm64: dts: fsl-lx2160a: add rev2 support") has
added a new soc dtsi for revision 2.
Update LX2162A Clearfog description to use revision 2 dtsi.
Fixes: 5093b190f9ce ("arm64: dts: freescale: Add support for LX2162 SoM & Clearfog Board") # no-stable
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
index 9d50d3e2761da..f95e9c19bfc75 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
@@ -6,7 +6,7 @@
/dts-v1/;
-#include "fsl-lx2160a.dtsi"
+#include "fsl-lx2160a-rev2.dtsi"
#include "fsl-lx2162a-sr-som.dtsi"
/ {
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v4 2/2] coco: guest: arm64: Drop dummy RSI platform device stub
From: Catalin Marinas @ 2026-05-12 14:38 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm)
Cc: linux-kernel, linux-arm-kernel, Greg KH, Jeremy Linton,
Jonathan Cameron, Lorenzo Pieralisi, Mark Rutland, Sudeep Holla,
Will Deacon, Jonathan Cameron, Suzuki K Poulose
In-Reply-To: <20260427061615.905018-3-aneesh.kumar@kernel.org>
+ Suzuki again
On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
> The SMCCC firmware driver now creates the `arm-smccc` platform device
> and also creates the CCA auxiliary devices once the RSI ABI is
> discovered. This makes the arch-specific arm64_create_dummy_rsi_dev()
> helper redundant. Remove the arm-cca-dev platform device registration
> and let the SMCCC probe manage the RSI device.
>
> systemd match on platform:arm-cca-dev for confidential vm detection [1].
> Losing the platform device registration can break that. Keeping this
> removal in its own change makes it easy to revert if that regression
> blocks the rollout.
>
> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
I wouldn't merge this now given that systemd checks this file. Could we
have a symbolic link instead for some time until systemd eventually gets
updated (years?).
--
Catalin
^ permalink raw reply
* Re: [PATCH v3 3/7] gpio: regmap: Add gpio_regmap_operation and write-enable support
From: Jonathan Cameron @ 2026-05-12 14:37 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, wbg,
mathieu.dubois-briand, mwalle, lars, Michael.Hennerich, nuno.sa,
andy, dlechner, tychang, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel, linux-realtek-soc, linux-iio, cy.huang,
stanley_chang, james.tai, Linus Walleij
In-Reply-To: <20260512033317.1602537-4-eleanor.lin@realtek.com>
On Tue, 12 May 2026 11:33:13 +0800
Yu-Chun Lin <eleanor.lin@realtek.com> wrote:
> Extend the reg_mask_xlate callback with an operation type parameter
> (gpio_regmap_operation) to allow drivers to return different
> register/mask combinations for different GPIO operations.
>
> Also add write-enable mechanism for hardware that requires setting a
> write-enable bit before modifying GPIO control registers.
>
> Consequently, update all existing drivers utilizing the gpio-regmap
> framework (across drivers/gpio, drivers/iio, and drivers/pinctrl)
> to accommodate the new reg_mask_xlate function signature.
What is the reasoning behind setting *mask = 0 for unsupported operations?
If it is a special value why not just return an error code to indicate
not supported? This seems to come from the assumption that you will want
to | that with masks for another operation.
I'm coming into this late but to me there look to be a bunch of undocumented
assumptions. Why do the operations have to share a register for example?
Perhaps an interface where you provide a single operation for write_enable
and whatever else and hence t here is only one 'reg' would work better?
>
> Suggested-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> diff --git a/drivers/gpio/gpio-regmap.c b/drivers/gpio/gpio-regmap.c
> index deb9eebb58de..c76eef20e412 100644
> --- a/drivers/gpio/gpio-regmap.c
> +++ b/drivers/gpio/gpio-regmap.c
> @@ -38,9 +38,10 @@ struct gpio_regmap {
> struct regmap_irq_chip_data *irq_chip_data;
> #endif
>
> - int (*reg_mask_xlate)(struct gpio_regmap *gpio, unsigned int base,
> - unsigned int offset, unsigned int *reg,
> - unsigned int *mask);
> + int (*reg_mask_xlate)(struct gpio_regmap *gpio,
> + enum gpio_regmap_operation op,
> + unsigned int base, unsigned int offset,
> + unsigned int *reg, unsigned int *mask);
>
> void *driver_data;
> };
> @@ -54,6 +55,7 @@ static unsigned int gpio_regmap_addr(unsigned int addr)
> }
>
> static int gpio_regmap_simple_xlate(struct gpio_regmap *gpio,
> + enum gpio_regmap_operation op,
> unsigned int base, unsigned int offset,
> unsigned int *reg, unsigned int *mask)
> {
> @@ -61,7 +63,16 @@ static int gpio_regmap_simple_xlate(struct gpio_regmap *gpio,
> unsigned int stride = offset / gpio->ngpio_per_reg;
>
> *reg = base + stride * gpio->reg_stride;
> - *mask = BIT(line);
> +
> + switch (op) {
> + case GPIO_REGMAP_SET_WREN_OP:
> + case GPIO_REGMAP_SET_DIR_WREN_OP:
> + *mask = 0;
> + break;
> + default:
> + *mask = BIT(line);
> + break;
> + }
>
> return 0;
> }
> @@ -69,7 +80,7 @@ static int gpio_regmap_simple_xlate(struct gpio_regmap *gpio,
> static int gpio_regmap_get(struct gpio_chip *chip, unsigned int offset)
> {
> struct gpio_regmap *gpio = gpiochip_get_data(chip);
> - unsigned int base, val, reg, mask;
> + unsigned int base, val, reg, mask, dir_mask;
> int ret;
>
> /* we might not have an output register if we are input only */
> @@ -78,10 +89,24 @@ static int gpio_regmap_get(struct gpio_chip *chip, unsigned int offset)
> else
> base = gpio_regmap_addr(gpio->reg_set_base);
>
> - ret = gpio->reg_mask_xlate(gpio, base, offset, ®, &mask);
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_GET_OP, base, offset, ®, &dir_mask);
> if (ret)
> return ret;
>
> + ret = regmap_read(gpio->regmap, reg, &val);
> + if (ret)
> + return ret;
> +
> + if (val & dir_mask) {
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_OUT, base, offset, ®, &mask);
> + if (ret)
> + return ret;
> + } else {
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_IN, base, offset, ®, &mask);
> + if (ret)
> + return ret;
> + }
> +
> /* ensure we don't spoil any register cache with pin input values */
> if (gpio->reg_dat_base == gpio->reg_set_base)
> ret = regmap_read_bypassed(gpio->regmap, reg, &val);
> @@ -98,10 +123,14 @@ static int gpio_regmap_set(struct gpio_chip *chip, unsigned int offset,
> {
> struct gpio_regmap *gpio = gpiochip_get_data(chip);
> unsigned int base = gpio_regmap_addr(gpio->reg_set_base);
> - unsigned int reg, mask, mask_val;
> + unsigned int reg, mask, mask_val, wren_mask;
> int ret;
>
> - ret = gpio->reg_mask_xlate(gpio, base, offset, ®, &mask);
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_WREN_OP, base, offset, ®, &wren_mask);
> + if (ret)
> + return ret;
> +
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_OP, base, offset, ®, &mask);
> if (ret)
> return ret;
>
> @@ -112,9 +141,9 @@ static int gpio_regmap_set(struct gpio_chip *chip, unsigned int offset,
>
> /* ignore input values which shadow the old output value */
> if (gpio->reg_dat_base == gpio->reg_set_base)
> - ret = regmap_write_bits(gpio->regmap, reg, mask, mask_val);
> + ret = regmap_write_bits(gpio->regmap, reg, mask | wren_mask, mask_val | wren_mask);
> else
> - ret = regmap_update_bits(gpio->regmap, reg, mask, mask_val);
> + ret = regmap_update_bits(gpio->regmap, reg, mask | wren_mask, mask_val | wren_mask);
>
> return ret;
> }
> @@ -123,7 +152,7 @@ static int gpio_regmap_set_with_clear(struct gpio_chip *chip,
> unsigned int offset, int val)
> {
> struct gpio_regmap *gpio = gpiochip_get_data(chip);
> - unsigned int base, reg, mask;
> + unsigned int base, reg, mask, wren_mask;
> int ret;
>
> if (val)
> @@ -131,11 +160,15 @@ static int gpio_regmap_set_with_clear(struct gpio_chip *chip,
> else
> base = gpio_regmap_addr(gpio->reg_clr_base);
>
> - ret = gpio->reg_mask_xlate(gpio, base, offset, ®, &mask);
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_WREN_OP, base, offset, ®, &wren_mask);
> if (ret)
> return ret;
>
> - return regmap_write(gpio->regmap, reg, mask);
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_WITH_CLEAR_OP, base, offset, ®, &mask);
> + if (ret)
> + return ret;
> +
> + return regmap_write(gpio->regmap, reg, mask | wren_mask);
> }
>
> static int gpio_regmap_get_direction(struct gpio_chip *chip,
> @@ -167,7 +200,7 @@ static int gpio_regmap_get_direction(struct gpio_chip *chip,
> return -ENOTSUPP;
> }
>
> - ret = gpio->reg_mask_xlate(gpio, base, offset, ®, &mask);
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_GET_DIR_OP, base, offset, ®, &mask);
> if (ret)
> return ret;
>
> @@ -185,7 +218,7 @@ static int gpio_regmap_set_direction(struct gpio_chip *chip,
> unsigned int offset, bool output)
> {
> struct gpio_regmap *gpio = gpiochip_get_data(chip);
> - unsigned int base, val, reg, mask;
> + unsigned int base, val, reg, mask, wren_mask;
> int invert, ret;
>
> if (gpio->reg_dir_out_base) {
> @@ -198,7 +231,12 @@ static int gpio_regmap_set_direction(struct gpio_chip *chip,
> return -ENOTSUPP;
> }
>
> - ret = gpio->reg_mask_xlate(gpio, base, offset, ®, &mask);
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_DIR_OP, base, offset, ®, &mask);
> + if (ret)
> + return ret;
> +
> + ret = gpio->reg_mask_xlate(gpio, GPIO_REGMAP_SET_DIR_WREN_OP, base, offset, ®,
> + &wren_mask);
What constrains these two to provide the same value back for reg?
To me it seems like the write enable might well be in a different register.
> if (ret)
> return ret;
>
> @@ -207,7 +245,7 @@ static int gpio_regmap_set_direction(struct gpio_chip *chip,
> else
> val = output ? mask : 0;
>
> - return regmap_update_bits(gpio->regmap, reg, mask, val);
> + return regmap_update_bits(gpio->regmap, reg, mask | wren_mask, val | wren_mask);
> }
>
> static int gpio_regmap_direction_input(struct gpio_chip *chip,
^ permalink raw reply
* Re: [PATCH v4 1/2] firmware: smccc: coco: Manage arm-smccc platform device and CCA auxiliary drivers
From: Catalin Marinas @ 2026-05-12 14:36 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm)
Cc: linux-kernel, linux-arm-kernel, Greg KH, Jeremy Linton,
Jonathan Cameron, Lorenzo Pieralisi, Mark Rutland, Sudeep Holla,
Will Deacon, Suzuki K Poulose
In-Reply-To: <20260427061615.905018-2-aneesh.kumar@kernel.org>
+ Suzuki
On Mon, Apr 27, 2026 at 11:46:14AM +0530, Aneesh Kumar K.V (Arm) wrote:
> diff --git a/arch/arm64/include/asm/rsi.h b/arch/arm64/include/asm/rsi.h
> index 88b50d660e85..2d2d363aaaee 100644
> --- a/arch/arm64/include/asm/rsi.h
> +++ b/arch/arm64/include/asm/rsi.h
> @@ -10,7 +10,7 @@
> #include <linux/jump_label.h>
> #include <asm/rsi_cmds.h>
>
> -#define RSI_PDEV_NAME "arm-cca-dev"
> +#define RSI_DEV_NAME "arm-rsi-dev"
[...]
> diff --git a/drivers/firmware/smccc/smccc.c b/drivers/firmware/smccc/smccc.c
> index bdee057db2fd..fc9b44b7c687 100644
> --- a/drivers/firmware/smccc/smccc.c
> +++ b/drivers/firmware/smccc/smccc.c
> @@ -12,6 +12,8 @@
> #include <linux/platform_device.h>
> #include <asm/archrandom.h>
>
> +#include "rmm.h"
> +
> static u32 smccc_version = ARM_SMCCC_VERSION_1_0;
> static enum arm_smccc_conduit smccc_conduit = SMCCC_CONDUIT_NONE;
>
> @@ -85,6 +87,18 @@ static int __init smccc_devices_init(void)
> {
> struct platform_device *pdev;
>
> + pdev = platform_device_register_simple("arm-smccc",
> + PLATFORM_DEVID_NONE, NULL, 0);
> + if (IS_ERR(pdev)) {
> + pr_err("arm-smccc: could not register device: %ld\n", PTR_ERR(pdev));
> + } else {
> + /*
> + * Register the RMI and RSI devices only when firmware exposes
> + * the required SMCCC function IDs at a supported revision.
> + */
> + register_rsi_device(pdev);
> + }
So as per the cover letter, instead of "arm-cca-dev" as a platform
device, we get "arm-smccc" as a platform device with an auxiliary
"arm-rsi-dev" child device. This does not get rid of the platform
device, it just creates a synthetic platform device to represent the
SMCCC firmware interface.
Looking at the earlier discussion, I think this is what Greg/Jason were
suggesting, except that we do not currently have an SMCCC platform
device:
https://lore.kernel.org/all/2025101534-frosty-shank-00b1@gregkh/
If we go this route, shouldn't the platform device above be created only
if !SMCCC_CONDUIT_NONE?
"smccc_trng" would also fit this model (together with the driver),
assuming we don't break any user-space (searching the Debian codebase
did not find any use).
--
Catalin
^ permalink raw reply
* Re: [PATCH v2 05/16] iio: adc: mediatek: add mt6323 PMIC AUXADC driver
From: Roman Vivchar @ 2026-05-12 14:34 UTC (permalink / raw)
To: Jonathan Cameron, Andy Shevchenko
Cc: David Lechner, Nuno Sá, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Srinivas Kandagatla,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
linux-iio, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-pm, Ben Grisdale
In-Reply-To: <20260512142932.5c6801d1@jic23-huawei>
On Tuesday, May 12th, 2026 at 4:29 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> On Tue, 12 May 2026 08:18:19 +0300
> Roman Vivchar via B4 Relay <devnull+rva333.protonmail.com@kernel.org> wrote:
...
> > +#define VOLTAGE_FULL_RANGE 1800
> Probably better to have this inline - however if you do keep it
> prefix t he define VOLTAGE_FULL_RANGE sounds too generic!
>
> > +#define AUXADC_PRECISE 32768
> I'd put that inline. Little benefit it in having it up here...
There was a mention about magic values in the v1 for the thermal patch [1].
Andy, would it be better to use an inline style or a #define here?
If the former, I'll rename the first constant to something like
AUXADC_VOLTAGE_FULL_RANGE.
[1]: https://lore.kernel.org/linux-mediatek/afmnUG8dG0N0HpV6@ashevche-desk.local/
Best regards,
Roman
^ permalink raw reply
* Re: [PATCH v3 3/3] iio: adc: xilinx-ams: refactor alarm mapping to table-driven approach
From: Salih Erim @ 2026-05-12 14:34 UTC (permalink / raw)
To: Guilherme Ivo Bozi, Conall O'Griofa, Jonathan Cameron,
Michal Simek
Cc: David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260414224245.8493-4-guilherme.bozi@usp.br>
Hi,
On 4/14/2026 11:40 PM, Guilherme Ivo Bozi wrote:
> Replace multiple open-coded switch statements that map between
> scan_index, alarm bits, and register offsets with a centralized
> table-driven approach.
>
> Introduce a struct-based alarm_map to describe the relationship
> between scan indices and alarm offsets, and add a helper to
> translate scan_index to event IDs. This removes duplicated logic
> across ams_get_alarm_offset(), ams_event_to_channel(), and
> ams_get_alarm_mask().
>
> The new approach improves maintainability, reduces code size,
> and makes it easier to extend or modify alarm mappings in the
> future, while preserving existing behavior.
>
> Signed-off-by: Guilherme Ivo Bozi <guilherme.bozi@usp.br>
> ---
> drivers/iio/adc/xilinx-ams.c | 161 +++++++++++++----------------------
> 1 file changed, 58 insertions(+), 103 deletions(-)
Two issues:
1) Same tabs-vs-spaces indentation problem as patches 1 and 2.
2) In ams_event_to_channel():
> + if (event < 0 || event >= ARRAY_SIZE(alarm_map))
> + return NULL;
The 'event' parameter is u32, so 'event < 0' is always false.
Either drop the < 0 check or change the parameter type to int
if you intend to handle negative values.
Salih
^ permalink raw reply
* [PATCH v4 11/20] drm/atomic-state-helper: Rename __drm_atomic_helper_crtc_state_reset()
From: Maxime Ripard @ 2026-05-12 13:06 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard,
Laurent Pinchart, Laurent Pinchart
In-Reply-To: <20260512-drm-mode-config-init-v4-0-591dfdcc1bf9@kernel.org>
__drm_atomic_helper_crtc_state_reset() is used to initialize a newly
allocated drm_crtc_state, and is being typically called by the
drm_crtc_funcs.reset implementation.
Since we want to consolidate DRM objects state allocation around the
atomic_create_state callback that will only allocate and initialize a
new drm_crtc_state instance, we will need to call
__drm_atomic_helper_crtc_state_reset() from both the reset and
atomic_create hooks.
To avoid any confusion, we can thus rename
__drm_atomic_helper_crtc_state_reset() to
__drm_atomic_helper_crtc_state_init().
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
drivers/gpu/drm/drm_atomic_state_helper.c | 10 +++++-----
drivers/gpu/drm/i915/display/intel_crtc.c | 2 +-
include/drm/drm_atomic_state_helper.h | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index ab171bfe6e86..b277f92f4532 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -61,25 +61,25 @@
* For other drivers the building blocks are split out, see the documentation
* for these functions.
*/
/**
- * __drm_atomic_helper_crtc_state_reset - reset the CRTC state
+ * __drm_atomic_helper_crtc_state_init - Initialize the CRTC state
* @crtc_state: atomic CRTC state, must not be NULL
* @crtc: CRTC object, must not be NULL
*
* Initializes the newly allocated @crtc_state with default
* values. This is useful for drivers that subclass the CRTC state.
*/
void
-__drm_atomic_helper_crtc_state_reset(struct drm_crtc_state *crtc_state,
- struct drm_crtc *crtc)
+__drm_atomic_helper_crtc_state_init(struct drm_crtc_state *crtc_state,
+ struct drm_crtc *crtc)
{
crtc_state->crtc = crtc;
crtc_state->background_color = DRM_ARGB64_PREP(0xffff, 0, 0, 0);
}
-EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_reset);
+EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_init);
/**
* __drm_atomic_helper_crtc_reset - reset state on CRTC
* @crtc: drm CRTC
* @crtc_state: CRTC state to assign
@@ -94,11 +94,11 @@ EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_reset);
void
__drm_atomic_helper_crtc_reset(struct drm_crtc *crtc,
struct drm_crtc_state *crtc_state)
{
if (crtc_state)
- __drm_atomic_helper_crtc_state_reset(crtc_state, crtc);
+ __drm_atomic_helper_crtc_state_init(crtc_state, crtc);
if (drm_dev_has_vblank(crtc->dev))
drm_crtc_vblank_reset(crtc);
crtc->state = crtc_state;
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
index 03de219f7a64..7486f2dc60ef 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -179,11 +179,11 @@ struct intel_crtc_state *intel_crtc_state_alloc(struct intel_crtc *crtc)
void intel_crtc_state_reset(struct intel_crtc_state *crtc_state,
struct intel_crtc *crtc)
{
memset(crtc_state, 0, sizeof(*crtc_state));
- __drm_atomic_helper_crtc_state_reset(&crtc_state->uapi, &crtc->base);
+ __drm_atomic_helper_crtc_state_init(&crtc_state->uapi, &crtc->base);
crtc_state->cpu_transcoder = INVALID_TRANSCODER;
crtc_state->master_transcoder = INVALID_TRANSCODER;
crtc_state->hsw_workaround_pipe = INVALID_PIPE;
crtc_state->scaler_state.scaler_id = -1;
diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
index 8d1ef268fdef..0bb72453464a 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -38,11 +38,11 @@ struct drm_connector_state;
struct drm_private_obj;
struct drm_private_state;
struct drm_modeset_acquire_ctx;
struct drm_device;
-void __drm_atomic_helper_crtc_state_reset(struct drm_crtc_state *state,
+void __drm_atomic_helper_crtc_state_init(struct drm_crtc_state *state,
struct drm_crtc *crtc);
void __drm_atomic_helper_crtc_reset(struct drm_crtc *crtc,
struct drm_crtc_state *state);
void drm_atomic_helper_crtc_reset(struct drm_crtc *crtc);
void __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc,
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 1/4] ARM: dts: imx6qdl-sabrelite: add mdio phy address 0
From: Frank Li @ 2026-05-12 14:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <f04fadf2-8d73-435b-b713-9d07e48e80ae@lunn.ch>
On Tue, May 12, 2026 at 12:15:08AM +0200, Andrew Lunn wrote:
> On Mon, May 11, 2026 at 05:04:56PM -0400, Frank Li wrote:
> > According to IEEE 802.3 Clause 22.2.4.5.5 PHYAD (PHY Address), A PHY that
> > is connected to the station management entity via the mechanical interface
> > defined in 22.6 shall always respond to transactions addressed to PHY
> > Address zero <00000>.
>
> Did you read 22.6? I've not seen a mechanical interface as defined in
> 22.6 for at least 20 years, maybe 30 years.
>
> That cause does not apply in this context.
Thanks, I missed understand it. This board is still alive, let me double
check it.
Frank
>
> > - ethphy: ethernet-phy {
> > + ethphy: ethernet-phy@0 {
> > compatible = "ethernet-phy-ieee802.3-c22";
> > + reg = <0>;
>
> This could very well break this board. Without a reg value, the core
> will find the first PHY on the bus, at whatever address it is at. If
> you hard code 0, the PHY must be at 0, otherwise it will not be found.
>
> Andrew
^ permalink raw reply
* Re: [PATCH v3 2/3] iio: adc: xilinx-ams: use guard(mutex) for automatic locking
From: Salih Erim @ 2026-05-12 14:25 UTC (permalink / raw)
To: Guilherme Ivo Bozi, Conall O'Griofa, Jonathan Cameron,
Michal Simek
Cc: David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel, Andy Shevchenko
In-Reply-To: <20260414224245.8493-3-guilherme.bozi@usp.br>
Hi,
On 4/14/2026 11:40 PM, Guilherme Ivo Bozi wrote:
> Replace open-coded mutex_lock()/mutex_unlock() pairs with
> guard(mutex) to simplify locking and ensure proper unlock on
> all control flow paths.
>
> This removes explicit unlock handling, reduces boilerplate,
> and avoids potential mistakes in error paths while keeping
> the behavior unchanged.
>
> Signed-off-by: Guilherme Ivo Bozi <guilherme.bozi@usp.br>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> ---
> drivers/iio/adc/xilinx-ams.c | 24 ++++++++----------------
> 1 file changed, 8 insertions(+), 16 deletions(-)
Same indentation issue -- spaces instead of tabs on all new lines.
Salih
^ 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