* Re: [PATCH v1 2/4] arm64: dts: qcom: sm8550: Add JPEG encoder node
From: Bryan O'Donoghue @ 2026-06-13 9:52 UTC (permalink / raw)
To: Atanas Filipov, linux-media
Cc: mchehab, robh, krzk+dt, conor+dt, andersson, konradybcio,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <3d4e0147-8e62-4872-b881-1452f5e09e85@oss.qualcomm.com>
On 13/06/2026 10:24, Atanas Filipov wrote:
> Thank you for the feedback. I understand the reasoning, but I
> respectfully disagree with this approach for the following reasons.
>
> While it is true that the JPEG encoder shares the same camera NOC and
> power domain infrastructure as CAMSS, that is a hardware topology detail
> — not a sufficient justification for imposing a software dependency. The
> driver is a fully
> self-contained V4L2 mem2mem encoder, implemented like every other JPEG
> encoder driver currently in the kernel (imx-jpeg, s5p-jpeg, mtk-jpeg,
> nxp-jpeg). None of those are sub-nodes of a parent ISP or camera
> subsystem driver.
That's a backwards understanding of the ethos of DT, which is to
describe hardware architecture, to describe hardware, not to subscribe
to or proscribe a particular software architecture.
Those jpeg blocks are standalone, whereas the CAMSS jpeg encoder lives
inside of the CAMSS power-island.
> Making the JPEG encoder a sub-node of camss would introduce an
> unnecessary and artificial coupling: the JPEG encoder cannot be probed,
> built, or used independently of the CAMSS driver, even on platforms
> where CAMSS is disabled. This directly contradicts the kernel's
> principle of independent, single-purpose drivers.
- Probed true
- Built true
- Used untrue
Once probed your current driver can chug along pretty much unperturbed,
however I don't believe that statement can hold true as more of the
camera hardware gets enabled.
> The shared hardware resources (clocks, interconnects, IOMMU stream IDs,
> power domain) are already fully described in the device tree node and
> handled by the standard kernel frameworks — there is no functional
> reason to nest the node under camss.
Except that it is a real description of the hardware. "We can model it
separately != we have modeled it correctly".
And at least one thing you are leaving out here is the cam noc - which
eventually we will have to start to enable and will almost certainly
have to be controlled by the core driver which also owns the
power-collapse and muxes, the thing that will also program CPAs - the
core CAMSS driver.
Perhaps we choose to model that NOC as a separate driver or perhaps we
expose an API in CAMSS to vote, either way its an intrinsic part of the
voltage and clocks in this block.
Either way sure we could model it as a fully separate node but, that is
not really how/where the block lives. It lives inside of a defined CAMSS
block, which is its own power-island.
Switching on the JPEG part of it by inference switches on the top-level
of the island so, its not separate at all.
> For these reasons I would prefer to keep the JPEG encoder as a
> standalone platform device with its own DT node, consistent with how all
> comparable JPEG encoder drivers are structured in the kernel today.
>
> afilipov
>
> On 6/13/2026 2:14 AM, Bryan O'Donoghue wrote:
>> On 12/06/2026 20:44, Atanas Filipov wrote:
>>> + qcom_jpeg_enc: jpeg-encoder@ac4e000 {
>>
>> One key bit of review feedback I gave in the previous leaked version of
>> this driver is that since the jpeg-encoder is part of the CAMSS block it
>> should be a sub-node of camss as OPE, CSIPHY and other blocks will be.
>>
>> Please take that feedback onboard in your v2.
>>
>> ---
>> bod
>
>
And please no top posting !
---
bod
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: allwinner: add Radxa Cubie A7S
From: sashiko-bot @ 2026-06-13 9:50 UTC (permalink / raw)
To: Enzo Adriano via B4 Relay; +Cc: robh, devicetree, conor+dt, linux-sunxi
In-Reply-To: <20260613-a733-dts-v1-public-ready-v1-4-7787c94681db@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The `&mmc0` node is missing the `cd-gpios` property (or `broken-cd` / `non-removable`), which may be necessary for proper SD card detection.
- [Low] The new DTB entry in the Makefile breaks alphabetical ordering.
- [Low] The fixed regulator node name does not match the required device tree schema.
--
commit f3152d16f1d4c4fabab01c5ee230d7994c9a7898
Author: Enzo Adriano <enzo.adriano.code@gmail.com>
arm64: dts: allwinner: add Radxa Cubie A7S
Add the Radxa Cubie A7S board description with serial console and SD card
boot support. Ethernet remains disabled until prerequisites are proven.
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index d116864b6c2b3..824cc35152db8 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -56,6 +56,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h700-anbernic-rg35xx-2024.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h700-anbernic-rg35xx-h.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h700-anbernic-rg35xx-plus.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h700-anbernic-rg35xx-sp.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun60i-a733-cubie-a7s.dtb
[Severity: Low]
This isn't a bug, but should this entry be placed further down?
Strict alphabetical sorting dictates that sun60i should appear after all
the sun55i entries to avoid merge conflicts.
> dtb-$(CONFIG_ARCH_SUNXI) += sun55i-a527-cubie-a5e.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun55i-h728-x96qpro+.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun55i-t527-avaota-a1.dtb
[ ... ]
> diff --git a/arch/arm64/boot/dts/allwinner/sun60i-a733-cubie-a7s.dts b/arch/arm64/boot/dts/allwinner/sun60i-a733-cubie-a7s.dts
> new file mode 100644
> index 0000000000000..453761a963237
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun60i-a733-cubie-a7s.dts
> @@ -0,0 +1,48 @@
> +// SPDX-License-Identifier: (GPL-2.0-only OR MIT)
> +
> +/dts-v1/;
> +
> +#include "sun60i-a733.dtsi"
> +
> +/ {
> + model = "Radxa Cubie A7S";
> + compatible = "radxa,cubie-a7s", "allwinner,sun60i-a733";
[ ... ]
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + reg_vcc3v3: vcc3v3 {
> + compatible = "regulator-fixed";
[Severity: Low]
This isn't a bug, but does this regulator name trigger a dtbs_check warning?
The standard device tree binding expects the node name to match the pattern
^regulator(-[0-9]+v[0-9]+|-[0-9a-z-]+)?$. A standard name like regulator-3v3
or regulator-vcc-3v3 should be used instead.
> + regulator-name = "vcc-3v3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +};
> +
> +&mmc0 {
> + vmmc-supply = <®_vcc3v3>;
> + bus-width = <4>;
> + no-mmc;
> + no-sdio;
> + status = "okay";
> +};
[Severity: Medium]
The commit message states this adds SD card boot support, but is the
cd-gpios property missing from this node?
Without cd-gpios or an explicit broken-cd fallback, the MMC core might fail
to detect card presence. If the kernel assumes the slot is empty, it will
not probe the SD card, causing root filesystem mounting to fail.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260613-a733-dts-v1-public-ready-v1-0-7787c94681db@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH v4 1/2] arm: dts: st: align node patterns with established convention
From: sashiko-bot @ 2026-06-13 9:48 UTC (permalink / raw)
To: Charan Pedumuru; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260613-st-mmc-v4-1-b3c385617c16@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Renaming 'sdhci@...' nodes to 'mmc@...' in the base dtsi file leaves overrides in derived dtsi and dts files orphaned, causing node duplication and completely breaking MMC functionality.
--
commit 40b6fa41749cf01adbee4227ca47061d9fbb6688
Author: Charan Pedumuru <charan.pedumuru@gmail.com>
arm: dts: st: align node patterns with established convention
This commit updates ST MMC DTS node patterns to match established convention
by renaming the base sdhci nodes to mmc.
> diff --git a/arch/arm/boot/dts/st/stih407-family.dtsi b/arch/arm/boot/dts/st/stih407-family.dtsi
> index 3e6a0542e3aea..08acba209c564 100644
> --- a/arch/arm/boot/dts/st/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/st/stih407-family.dtsi
> @@ -596,7 +596,7 @@ spi@9542000 {
> status = "disabled";
> };
>
> - mmc0: sdhci@9060000 {
> + mmc0: mmc@9060000 {
[Severity: High]
Does renaming these base nodes to mmc@... leave downstream overrides
orphaned?
Looking at board files like arch/arm/boot/dts/st/stih410-b2260.dts and
arch/arm/boot/dts/st/stih418-b2199.dts, there are still overrides using
the old names:
mmc0: sdhci@9060000 {
pinctrl-0 = <&pinctrl_sd0>;
bus-width = <4>;
status = "okay";
};
Because the base node is renamed here without updating the downstream files,
will the DTC compiler treat the downstream overrides as new node declarations
rather than property merges?
This would leave the base mmc@9060000 node disabled, while the new
sdhci@9060000 node would lack essential properties like compatible and reg,
preventing the kernel from binding the MMC driver to the hardware.
> compatible = "st,sdhci-stih407", "st,sdhci";
> status = "disabled";
> reg = <0x09060000 0x7ff>, <0x9061008 0x20>;
[ ... ]
> - mmc1: sdhci@9080000 {
> + mmc1: mmc@9080000 {
[Severity: High]
Are there similar orphaned overrides for this node?
Checking arch/arm/boot/dts/st/stih418-b2199.dts, it appears this node is
also overridden using the old name:
mmc1: sdhci@9080000 {
status = "okay";
};
Would this result in the same missing compatible properties and disabled
base node?
> compatible = "st,sdhci-stih407", "st,sdhci";
> status = "disabled";
> reg = <0x09080000 0x7ff>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260613-st-mmc-v4-0-b3c385617c16@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v4 2/2] dt-bindings: mmc: st,sdhci: Convert to DT schema
From: sashiko-bot @ 2026-06-13 9:48 UTC (permalink / raw)
To: Charan Pedumuru; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260613-st-mmc-v4-2-b3c385617c16@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The DT schema fails to conditionally require `reg-names` when multiple `reg` entries are provided, which can lead to silent runtime misconfiguration.
- [Medium] The YAML schema loses the original specific allowed values constraint for `max-frequency`.
--
commit e2c333948a6b09aa2bb42febade330d8715b076f
Author: Charan Pedumuru <charan.pedumuru@gmail.com>
dt-bindings: mmc: st,sdhci: Convert to DT schema
This commit converts the STMicroelectronics sdhci-st MMC/SD controller
binding from a text format to a YAML DT schema. It preserves the flexibility
of optional clocks and registers from the original binding.
> diff --git a/Documentation/devicetree/bindings/mmc/st,sdhci.yaml b/Documentation/devicetree/bindings/mmc/st,sdhci.yaml
> new file mode 100644
> index 0000000000000..0bf4fc3ca699f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/st,sdhci.yaml
[ ... ]
> +allOf:
> + - $ref: mmc-controller.yaml#
> +
> +properties:
> + compatible:
> + oneOf:
> + - const: st,sdhci
> + - items:
> + - const: st,sdhci-stih407
> + - const: st,sdhci
[Severity: Medium]
Is this a regression from the strict constraints of the text binding?
The original text binding restricted max-frequency to 200000000, 100000000,
or 50000000, which matches the driver's behavior in sdhci-st.c. Since this
new YAML schema omits max-frequency entirely, it falls back to the generic
mmc-controller.yaml which permits any integer.
Should this explicitly define max-frequency under properties with an enum
constraint to prevent unsupported frequencies from passing validation and
silently falling back to 50MHz at runtime?
> +
> + reg:
> + minItems: 1
> + items:
> + - description: MMC controller base registers
> + - description: FlashSS Top registers for TX/RX DLL delay configuration
> +
> + reg-names:
> + minItems: 1
> + items:
> + - const: mmc
> + - const: top-mmc-delay
[Severity: Medium]
Does this omission create a regression where the schema validation silently
accepts an invalid device tree?
The previous text binding explicitly stated that if the FlashSS Top register
is provided, reg-names must also be specified.
Without an allOf conditional block making reg-names required when the reg
property contains two items, won't the schema validation pass even if
reg-names is missing? If the driver relies on
devm_platform_ioremap_resource_byname() for top-mmc-delay, could this result
in a silent runtime misconfiguration?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260613-st-mmc-v4-0-b3c385617c16@gmail.com?part=2
^ permalink raw reply
* [PATCH 4/4] arm64: dts: allwinner: add Radxa Cubie A7S
From: Enzo Adriano via B4 Relay @ 2026-06-13 9:42 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Maxime Ripard, Ulf Hansson
Cc: devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-mmc, Enzo Adriano
In-Reply-To: <20260613-a733-dts-v1-public-ready-v1-0-7787c94681db@gmail.com>
From: Enzo Adriano <enzo.adriano.code@gmail.com>
Add the Radxa Cubie A7S board description with serial console and SD card
boot support.
Ethernet remains disabled until the GMAC210 wrapper, clocks, resets,
MDIO, PHY reset, PHY power, and link behavior are proven.
Signed-off-by: Enzo Adriano <enzo.adriano.code@gmail.com>
---
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../boot/dts/allwinner/sun60i-a733-cubie-a7s.dts | 48 ++++++++++++++++++++++
2 files changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index d116864b6c2b..824cc35152db 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -56,6 +56,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h700-anbernic-rg35xx-2024.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h700-anbernic-rg35xx-h.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h700-anbernic-rg35xx-plus.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h700-anbernic-rg35xx-sp.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun60i-a733-cubie-a7s.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun55i-a527-cubie-a5e.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun55i-h728-x96qpro+.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun55i-t527-avaota-a1.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun60i-a733-cubie-a7s.dts b/arch/arm64/boot/dts/allwinner/sun60i-a733-cubie-a7s.dts
new file mode 100644
index 000000000000..453761a96323
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun60i-a733-cubie-a7s.dts
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR MIT)
+
+/dts-v1/;
+
+#include "sun60i-a733.dtsi"
+
+/ {
+ model = "Radxa Cubie A7S";
+ compatible = "radxa,cubie-a7s", "allwinner,sun60i-a733";
+
+ aliases {
+ serial0 = &uart0;
+ mmc0 = &mmc0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_vcc3v3: vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+};
+
+&mmc0 {
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ no-mmc;
+ no-sdio;
+ status = "okay";
+};
+
+&pio {
+ uart0_pb9_pb10_pins: uart0-pb9-pb10-pins {
+ pins = "PB9", "PB10";
+ function = "uart0";
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pb9_pb10_pins>;
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: allwinner: add Allwinner A733 SoC
From: Enzo Adriano via B4 Relay @ 2026-06-13 9:42 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Maxime Ripard, Ulf Hansson
Cc: devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-mmc, Enzo Adriano
In-Reply-To: <20260613-a733-dts-v1-public-ready-v1-0-7787c94681db@gmail.com>
From: Enzo Adriano <enzo.adriano.code@gmail.com>
Add the initial A733 SoC description with CPUs, timers, interrupt
controller, clocks, pinctrl, UART0, and MMC0.
Keep peripherals disabled by default. Board DTS files can enable only the
devices that are proven on their hardware.
Signed-off-by: Enzo Adriano <enzo.adriano.code@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun60i-a733.dtsi | 198 +++++++++++++++++++++++++
1 file changed, 198 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun60i-a733.dtsi b/arch/arm64/boot/dts/allwinner/sun60i-a733.dtsi
new file mode 100644
index 000000000000..3721aa9e8573
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun60i-a733.dtsi
@@ -0,0 +1,198 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR MIT)
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/sun60i-a733-ccu.h>
+#include <dt-bindings/reset/sun60i-a733-ccu.h>
+
+/ {
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a55";
+ device_type = "cpu";
+ reg = <0x000>;
+ enable-method = "psci";
+ capacity-dmips-mhz = <530>;
+ };
+
+ cpu1: cpu@100 {
+ compatible = "arm,cortex-a55";
+ device_type = "cpu";
+ reg = <0x100>;
+ enable-method = "psci";
+ capacity-dmips-mhz = <530>;
+ };
+
+ cpu2: cpu@200 {
+ compatible = "arm,cortex-a55";
+ device_type = "cpu";
+ reg = <0x200>;
+ enable-method = "psci";
+ capacity-dmips-mhz = <530>;
+ };
+
+ cpu3: cpu@300 {
+ compatible = "arm,cortex-a55";
+ device_type = "cpu";
+ reg = <0x300>;
+ enable-method = "psci";
+ capacity-dmips-mhz = <530>;
+ };
+
+ cpu4: cpu@400 {
+ compatible = "arm,cortex-a55";
+ device_type = "cpu";
+ reg = <0x400>;
+ enable-method = "psci";
+ capacity-dmips-mhz = <530>;
+ };
+
+ cpu5: cpu@500 {
+ compatible = "arm,cortex-a55";
+ device_type = "cpu";
+ reg = <0x500>;
+ enable-method = "psci";
+ capacity-dmips-mhz = <530>;
+ };
+
+ cpu6: cpu@600 {
+ compatible = "arm,cortex-a76";
+ device_type = "cpu";
+ reg = <0x600>;
+ enable-method = "psci";
+ capacity-dmips-mhz = <1024>;
+ };
+
+ cpu7: cpu@700 {
+ compatible = "arm,cortex-a76";
+ device_type = "cpu";
+ reg = <0x700>;
+ enable-method = "psci";
+ capacity-dmips-mhz = <1024>;
+ };
+ };
+
+ osc24M: osc24M-clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ clock-output-names = "osc24M";
+ };
+
+ osc32k: osc32k-clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ clock-output-names = "osc32k";
+ };
+
+ iosc: internal-osc-clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <16000000>;
+ clock-output-names = "iosc";
+ };
+
+ psci {
+ compatible = "arm,psci-1.0", "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ arm,no-tick-in-suspend;
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x0 0x40000000>;
+
+ pio: pinctrl@2000000 {
+ compatible = "allwinner,sun60i-a733-pinctrl";
+ reg = <0x02000000 0x600>;
+ interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_APB1>, <&osc24M>, <&osc32k>;
+ clock-names = "apb", "hosc", "losc";
+ gpio-controller;
+ #gpio-cells = <3>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+
+ mmc0_pins: mmc0-pins {
+ pins = "PF0", "PF1", "PF2",
+ "PF3", "PF4", "PF5";
+ function = "mmc0";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+ };
+
+ ccu: clock-controller@2002000 {
+ compatible = "allwinner,sun60i-a733-ccu";
+ reg = <0x02002000 0x2000>;
+ clocks = <&osc24M>, <&osc32k>, <&iosc>;
+ clock-names = "hosc", "losc", "iosc";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ uart0: serial@2500000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x02500000 0x400>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART0>;
+ resets = <&ccu RST_BUS_UART0>;
+ status = "disabled";
+ };
+
+ gic: interrupt-controller@3400000 {
+ compatible = "arm,gic-v3";
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x03400000 0x10000>,
+ <0x03460000 0x100000>;
+ };
+
+ mmc0: mmc@4020000 {
+ compatible = "allwinner,sun60i-a733-mmc",
+ "allwinner,sun20i-d1-mmc";
+ reg = <0x04020000 0x1000>;
+ interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_MMC0>, <&ccu CLK_MMC0>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu RST_BUS_MMC0>;
+ reset-names = "ahb";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>;
+ max-frequency = <200000000>;
+ cap-sd-highspeed;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
--
2.53.0
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: arm: sunxi: add Radxa Cubie A7S
From: Enzo Adriano via B4 Relay @ 2026-06-13 9:42 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Maxime Ripard, Ulf Hansson
Cc: devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-mmc, Enzo Adriano
In-Reply-To: <20260613-a733-dts-v1-public-ready-v1-0-7787c94681db@gmail.com>
From: Enzo Adriano <enzo.adriano.code@gmail.com>
Document the Radxa Cubie A7S board compatible for the Allwinner A733 SoC.
Signed-off-by: Enzo Adriano <enzo.adriano.code@gmail.com>
---
Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index e6443c266fa1..9f603681c78e 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -850,6 +850,11 @@ properties:
- const: radxa,cubie-a5e
- const: allwinner,sun55i-a527
+ - description: Radxa Cubie A7S
+ items:
+ - const: radxa,cubie-a7s
+ - const: allwinner,sun60i-a733
+
- description: Remix Mini PC
items:
- const: jide,remix-mini-pc
--
2.53.0
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: mmc: add Allwinner A733 compatible
From: Enzo Adriano via B4 Relay @ 2026-06-13 9:42 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Maxime Ripard, Ulf Hansson
Cc: devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-mmc, Enzo Adriano
In-Reply-To: <20260613-a733-dts-v1-public-ready-v1-0-7787c94681db@gmail.com>
From: Enzo Adriano <enzo.adriano.code@gmail.com>
Document the A733 MMC controller compatible with the existing D1-style
fallback.
Signed-off-by: Enzo Adriano <enzo.adriano.code@gmail.com>
---
Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
index 9f3b1edacaa0..9e9590521210 100644
--- a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
+++ b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
@@ -58,6 +58,9 @@ properties:
- items:
- const: allwinner,sun55i-a523-mmc
- const: allwinner,sun20i-d1-mmc
+ - items:
+ - const: allwinner,sun60i-a733-mmc
+ - const: allwinner,sun20i-d1-mmc
reg:
maxItems: 1
--
2.53.0
^ permalink raw reply related
* [PATCH 0/4] arm64: dts: allwinner: add A733/Cubie A7S DTS support
From: Enzo Adriano via B4 Relay @ 2026-06-13 9:42 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Maxime Ripard, Ulf Hansson
Cc: devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-mmc, Enzo Adriano
This series adds initial devicetree support for the Allwinner A733 SoC and
Radxa Cubie A7S board.
It includes the Radxa Cubie A7S board compatible, the A733 MMC compatible,
an initial A733 SoC DTSI with CPUs, timer, GICv3, RTC oscillator provider,
CCU/R-CCU, pinctrl, UART0, and SDMMC0, and a board DTS enabling UART0 console
and SD card boot storage.
This series intentionally does not carry local CCU/PRCM or pinctrl driver
patches. Those areas overlap active A733 RFC work and remain external
prerequisites unless maintainers ask for a different plan. The A733 CCU RFC
also depends on the A733 RTC series.
Ethernet, VPU/Cedrus, display, Wi-Fi, Bluetooth, USB-C, PCIe, and other board
peripherals are intentionally out of scope. Vendor U-Boot workarounds used for
local proof collection are not encoded in these device trees.
Cubie A7S runtime proof has shown the v4 Image and DTB loading, Linux
7.1.0-rc6-gabc8d07b0a63, Radxa Cubie A7S machine model, 8 CPUs, GICv3
redistributors, A733 pinctrl/UART0, SDMMC0 enumeration, mmcblk0 partition
discovery, and a read-only mmcblk0p3 root mount via the corrected PARTUUID
path.
Signed-off-by: Enzo Adriano <enzo.adriano.code@gmail.com>
---
Enzo Adriano (4):
dt-bindings: arm: sunxi: add Radxa Cubie A7S
dt-bindings: mmc: add Allwinner A733 compatible
arm64: dts: allwinner: add Allwinner A733 SoC
arm64: dts: allwinner: add Radxa Cubie A7S
Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +
.../bindings/mmc/allwinner,sun4i-a10-mmc.yaml | 3 +
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../boot/dts/allwinner/sun60i-a733-cubie-a7s.dts | 48 +++++
arch/arm64/boot/dts/allwinner/sun60i-a733.dtsi | 198 +++++++++++++++++++++
5 files changed, 255 insertions(+)
---
base-commit: 1626ce5bc85bd3faaa92877d1b65c924d86a9546
change-id: 20260613-a733-dts-v1-public-ready-8cbb37133b64
prerequisite-message-id: <20260121-a733-rtc-v1-0-d359437f23a7@pigmoral.tech>
prerequisite-patch-id: 042a3289f0d794493871f52adbd992a9f4de1f95
prerequisite-patch-id: a133b49e027edbb982e1e0e6c5712416ffa8512a
prerequisite-patch-id: c512a7bc19f2d6d8cd54eb0950db302cc71795df
prerequisite-patch-id: 1ea3a72e957d15a896a95127908c9c2a188bd46c
prerequisite-patch-id: df374a147afb6d96e5c3c9ee9f0d3085c57a9076
prerequisite-patch-id: cd4375ce65c5b79a1c67b33dc373c0bc0af6d308
prerequisite-patch-id: 4ec938bcd2096388f4c1928b0aa1a9c72ef6fe35
prerequisite-message-id: <20260310-a733-clk-v1-0-36b4e9b24457@pigmoral.tech>
prerequisite-patch-id: 42a81ed9298600d95a32d3d61bbfb632580413e7
prerequisite-patch-id: c5736d2edbcad45007995bcdc6a61e2e1953f87a
prerequisite-patch-id: 3dc8be31aade04035ca759e75e9c67efd9dcafce
prerequisite-patch-id: c24ddc9c08cfc410f38f595a8000b4f7dedc74b3
prerequisite-patch-id: 9fac441fc346bc54b1f09130849aa320c0b912d2
prerequisite-patch-id: 7c36a3a750676915eec3b1927158d9d61209a460
prerequisite-patch-id: ed8a7bba18ba5e7c88f6f546fa9fc582aecabc82
prerequisite-patch-id: ac155f53daee5eaa9f893704d4c3fbb9ff4a184c
prerequisite-message-id: <20250821004232.8134-1-andre.przywara@arm.com>
prerequisite-patch-id: 03fdbd2faff5bdeff1e7bfb7b4844cf3fafd655d
prerequisite-patch-id: 15e73fad7383f55ad6d0592294dcc9e8274c1c02
prerequisite-patch-id: bea03fba87ae3dffc5ad9920ef5a045d74c6dbd7
prerequisite-patch-id: c29b0eb9119cb6ea38e3babd689463cc26b66894
prerequisite-patch-id: 639bf50ff42c85812716fb5dc89b616284481867
prerequisite-patch-id: 9fc3b375667be361f1279d9f9b976c7f2698136c
prerequisite-patch-id: 75fc07dc2648e6610e80b21b910d9ae00d31c304
prerequisite-patch-id: 3214731f042dd5eb1aa1d38388384428548a053f
prerequisite-patch-id: 69702560a13f180161afb5a48c2ea7ebb3f9ec5c
Best regards,
--
Enzo Adriano <enzo.adriano.code@gmail.com>
^ permalink raw reply
* [PATCH v4 2/2] dt-bindings: mmc: st,sdhci: Convert to DT schema
From: Charan Pedumuru @ 2026-06-13 9:39 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Griffin, Patrice Chotard
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
Charan Pedumuru
In-Reply-To: <20260613-st-mmc-v4-0-b3c385617c16@gmail.com>
Convert STMicroelectronics sdhci-st MMC/SD controller binding to
DT schema.
The 'icn' clock and 'top-mmc-delay' register region are optional in
the text binding and remain so in the YAML schema. minItems: 1 is
set on clock-names and reg-names to match the flexibility of their
paired clocks and reg properties, preserving compatibility with
existing in-tree DTS nodes that provide only a single clock or
register entry.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
Documentation/devicetree/bindings/mmc/sdhci-st.txt | 110 ---------------------
.../devicetree/bindings/mmc/st,sdhci.yaml | 92 +++++++++++++++++
2 files changed, 92 insertions(+), 110 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-st.txt b/Documentation/devicetree/bindings/mmc/sdhci-st.txt
deleted file mode 100644
index ccf82b4ee838..000000000000
--- a/Documentation/devicetree/bindings/mmc/sdhci-st.txt
+++ /dev/null
@@ -1,110 +0,0 @@
-* STMicroelectronics sdhci-st MMC/SD controller
-
-This file documents the differences between the core properties in
-Documentation/devicetree/bindings/mmc/mmc.txt and the properties
-used by the sdhci-st driver.
-
-Required properties:
-- compatible: Must be "st,sdhci" and it can be compatible to "st,sdhci-stih407"
- to set the internal glue logic used for configuring the MMC
- subsystem (mmcss) inside the FlashSS (available in STiH407 SoC
- family).
-
-- clock-names: Should be "mmc" and "icn". (NB: The latter is not compulsory)
- See: Documentation/devicetree/bindings/resource-names.txt
-- clocks: Phandle to the clock.
- See: Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-- interrupts: One mmc interrupt should be described here.
-- interrupt-names: Should be "mmcirq".
-
-- pinctrl-names: A pinctrl state names "default" must be defined.
-- pinctrl-0: Phandle referencing pin configuration of the sd/emmc controller.
- See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
-
-- reg: This must provide the host controller base address and it can also
- contain the FlashSS Top register for TX/RX delay used by the driver
- to configure DLL inside the flashSS, if so reg-names must also be
- specified.
-
-Optional properties:
-- reg-names: Should be "mmc" and "top-mmc-delay". "top-mmc-delay" is optional
- for eMMC on stih407 family silicon to configure DLL inside FlashSS.
-
-- non-removable: Non-removable slot. Also used for configuring mmcss in STiH407 SoC
- family.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- bus-width: Number of data lines.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- max-frequency: Can be 200MHz, 100MHz or 50MHz (default) and used for
- configuring the CCONFIG3 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- resets: Phandle and reset specifier pair to softreset line of HC IP.
- See: Documentation/devicetree/bindings/reset/reset.txt
-
-- vqmmc-supply: Phandle to the regulator dt node, mentioned as the vcc/vdd
- supply in eMMC/SD specs.
-
-- sd-uhs-sdr50: To enable the SDR50 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- sd-uhs-sdr104: To enable the SDR104 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-- sd-uhs-ddr50: To enable the DDR50 in the mmcss.
- See: Documentation/devicetree/bindings/mmc/mmc.txt.
-
-Example:
-
-/* Example stih416e eMMC configuration */
-
-mmc0: sdhci@fe81e000 {
- compatible = "st,sdhci";
- reg = <0xfe81e000 0x1000>;
- interrupts = <GIC_SPI 127 IRQ_TYPE_NONE>;
- interrupt-names = "mmcirq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_mmc0>;
- clock-names = "mmc";
- clocks = <&clk_s_a1_ls 1>;
- bus-width = <8>
-
-/* Example SD stih407 family configuration */
-
-mmc1: sdhci@9080000 {
- compatible = "st,sdhci-stih407", "st,sdhci";
- reg = <0x09080000 0x7ff>;
- reg-names = "mmc";
- interrupts = <GIC_SPI 90 IRQ_TYPE_NONE>;
- interrupt-names = "mmcirq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_sd1>;
- clock-names = "mmc";
- clocks = <&clk_s_c0_flexgen CLK_MMC_1>;
- resets = <&softreset STIH407_MMC1_SOFTRESET>;
- bus-width = <4>;
-};
-
-/* Example eMMC stih407 family configuration */
-
-mmc0: sdhci@9060000 {
- compatible = "st,sdhci-stih407", "st,sdhci";
- reg = <0x09060000 0x7ff>, <0x9061008 0x20>;
- reg-names = "mmc", "top-mmc-delay";
- interrupts = <GIC_SPI 92 IRQ_TYPE_NONE>;
- interrupt-names = "mmcirq";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_mmc0>;
- clock-names = "mmc";
- clocks = <&clk_s_c0_flexgen CLK_MMC_0>;
- vqmmc-supply = <&vmmc_reg>;
- max-frequency = <200000000>;
- bus-width = <8>;
- non-removable;
- sd-uhs-sdr50;
- sd-uhs-sdr104;
- sd-uhs-ddr50;
-};
diff --git a/Documentation/devicetree/bindings/mmc/st,sdhci.yaml b/Documentation/devicetree/bindings/mmc/st,sdhci.yaml
new file mode 100644
index 000000000000..0bf4fc3ca699
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/st,sdhci.yaml
@@ -0,0 +1,92 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/st,sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics SDHCI-ST MMC/SD Controller
+
+maintainers:
+ - Peter Griffin <peter.griffin@linaro.org>
+
+description:
+ The STMicroelectronics SDHCI-ST MMC/SD host controller is compliant with
+ the SD Host Controller Interface (SDHCI) specification and is used to
+ interface with MMC, SD and SDIO cards. The ST SDHCI controller extends the
+ standard SDHCI capabilities with platform-specific configurations such as
+ additional register regions, clock inputs, and delay control mechanisms
+ required for signal timing adjustments to support high-speed modes across
+ different ST SoCs.
+
+allOf:
+ - $ref: mmc-controller.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: st,sdhci
+ - items:
+ - const: st,sdhci-stih407
+ - const: st,sdhci
+
+ reg:
+ minItems: 1
+ items:
+ - description: MMC controller base registers
+ - description: FlashSS Top registers for TX/RX DLL delay configuration
+
+ reg-names:
+ minItems: 1
+ items:
+ - const: mmc
+ - const: top-mmc-delay
+
+ clocks:
+ minItems: 1
+ items:
+ - description: Clock for the MMC controller
+ - description: Interconnect (ICN) clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: mmc
+ - const: icn
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: mmcirq
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/stih407-clks.h>
+ mmc@9060000 {
+ compatible = "st,sdhci-stih407", "st,sdhci";
+ reg = <0x09060000 0x7ff>, <0x9061008 0x20>;
+ reg-names = "mmc", "top-mmc-delay";
+ interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "mmcirq";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc0>;
+ clock-names = "mmc", "icn";
+ clocks = <&clk_s_c0_flexgen CLK_MMC_0>,
+ <&clk_s_c0_flexgen CLK_RX_ICN_HVA>;
+ bus-width = <8>;
+ };
+...
--
2.54.0
^ permalink raw reply related
* [PATCH v4 1/2] arm: dts: st: align node patterns with established convention
From: Charan Pedumuru @ 2026-06-13 9:39 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Griffin, Patrice Chotard
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
Charan Pedumuru
In-Reply-To: <20260613-st-mmc-v4-0-b3c385617c16@gmail.com>
Update ST MMC DTS node patterns to match established convention.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
arch/arm/boot/dts/st/stih407-family.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/st/stih407-family.dtsi b/arch/arm/boot/dts/st/stih407-family.dtsi
index 3e6a0542e3ae..08acba209c56 100644
--- a/arch/arm/boot/dts/st/stih407-family.dtsi
+++ b/arch/arm/boot/dts/st/stih407-family.dtsi
@@ -596,7 +596,7 @@ spi@9542000 {
status = "disabled";
};
- mmc0: sdhci@9060000 {
+ mmc0: mmc@9060000 {
compatible = "st,sdhci-stih407", "st,sdhci";
status = "disabled";
reg = <0x09060000 0x7ff>, <0x9061008 0x20>;
@@ -611,7 +611,7 @@ mmc0: sdhci@9060000 {
bus-width = <8>;
};
- mmc1: sdhci@9080000 {
+ mmc1: mmc@9080000 {
compatible = "st,sdhci-stih407", "st,sdhci";
status = "disabled";
reg = <0x09080000 0x7ff>;
--
2.54.0
^ permalink raw reply related
* [PATCH v4 0/2] dt-bindings: mmc: st,sdhci: convert STMicroelectronics SDHCI-ST MMC/SD Controller controller binding to YAML
From: Charan Pedumuru @ 2026-06-13 9:39 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Griffin, Patrice Chotard
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
Charan Pedumuru
This patch series converts the legacy text-based Device Tree binding for
STMicroelectronics SDHCI-ST MMC/SD controller to DT schema (YAML) format.
Note:
The patch "dt-bindings: mmc: st,sdhci: convert to DT schema"
depends on the patch "arm: dts: st: align node patterns with established
convention". If the DT schema patch is applied before the DTS
cleanup patch, `dtbs_check` will fail due to the presence of the removed
properties in the existing DTS.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
Changes in v4:
- st,sdhci: Add minItems: 1 to clock-names and reg-names to allow single-entry
configurations, fixing dtbs_check failures on nodes that omit the
optional 'icn' clock or 'top-mmc-delay' register region.
- st,sdhci: Modify the commit message to explain the changes.
- Link to v3: https://patch.msgid.link/20260508-st-mmc-v3-0-81c329ed28e8@gmail.com
Changes in v3:
- st,sdhci: Edit description of reg property. Modify reg-names. Add
"minItems" for clocks and clock-names properties.
- Modify the commit message to match with the updated changes.
- Link to v2: https://patch.msgid.link/20260503-st-mmc-v2-0-11ae3216d2ce@gmail.com
Changes in v2:
- Fix node name in DTS for the MMC to match with the estableshed convention.
- st,sdhci: drop unnecessary properties, modify "reg", "reg-names" and
"clock-names" properties, include an allOf with $ref to mmc-controller.
- Link to v1: https://patch.msgid.link/20260409-st-mmc-v1-1-4c54321c3535@gmail.com
---
Charan Pedumuru (2):
arm: dts: st: align node patterns with established convention
dt-bindings: mmc: st,sdhci: Convert to DT schema
Documentation/devicetree/bindings/mmc/sdhci-st.txt | 110 ---------------------
.../devicetree/bindings/mmc/st,sdhci.yaml | 92 +++++++++++++++++
arch/arm/boot/dts/st/stih407-family.dtsi | 4 +-
3 files changed, 94 insertions(+), 112 deletions(-)
---
base-commit: cf2cd8efd046c561191b8541d32a8bfe845bf06b
change-id: 20260327-st-mmc-c906ad95ff83
Best regards,
--
Charan Pedumuru <charan.pedumuru@gmail.com>
^ permalink raw reply
* Re: [PATCH v4 6/7] arm64: dts: allwinner: a100: reserve RAM for ATF
From: Jernej Škrabec @ 2026-06-13 9:38 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Hans de Goede, Dmitry Torokhov, Andre Przywara,
Jun Yan, Lukas Schmid, J. Neuschäfer, Eric Biggers,
Michal Simek, Luca Weiss, Sven Peter, Maxime Ripard, devicetree,
linux-kernel, linux-input
In-Reply-To: <b428d57ba5464f1226daf099877f4c25fa4fc191.camel@gmail.com>
Dne sobota, 13. junij 2026 ob 10:34:42 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> Hi Jernej,
>
> On Sat, 2026-06-13 at 10:22 +0200, Jernej Škrabec wrote:
> > Dne petek, 5. junij 2026 ob 09:09:20 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> > > Add reserved-memory node carving out Trusted Firmware-A region spanning
> > > fixed 256K from physical address 0x40000000. Even though Allwinner ATF
> > > itself passes the address range in the fdt to U-Boot, U-Boot currently
> > > only reserves this memory internally, but doesn't carve out the region
> > > in the fdt passed to Linux.
> > >
> > > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> >
> > NAK. It is job of boot procedure to properly inject TF-A reserved node.
> > Any issue should be fixed there.
>
>
> like in commit 0d17c865118881609ea7e381c7cadbb7979cc596
> ("arm64: dts: allwinner: Add Allwinner H616 .dtsi file")
> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
>
> ? ;-)
I was against that too.
It's time to be fixed in bootloader.
Best regards,
Jernej
>
> > Best regards,
> > Jernej Skrabec
> >
> > > ---
> > > Changelog:
> > > v4:
> > > - new patch
> > >
> > > arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > > index 7cb06b19b5a5..d8391663fd1d 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > > @@ -87,6 +87,22 @@ osc32k: osc32k-clk {
> > > #clock-cells = <0>;
> > > };
> > >
> > > + reserved-memory {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + ranges;
> > > +
> > > + /*
> > > + * 256 KiB reserved for Trusted Firmware-A (BL31).
> > > + * This is added by BL31 itself, but some bootloaders fail
> > > + * to propagate this into the DTB handed to kernels.
> > > + */
> > > + secmon@40000000 {
> > > + reg = <0x0 0x40000000 0x0 0x40000>;
> > > + no-map;
> > > + };
> > > + };
> > > +
> > > timer {
> > > compatible = "arm,armv8-timer";
> > > interrupts = <GIC_PPI 13
>
>
^ permalink raw reply
* Re: [PATCH 4/7] drivers: staging: media: sunxi: cedrus: add H616 variant
From: Jernej Škrabec @ 2026-06-13 9:33 UTC (permalink / raw)
To: wens
Cc: Maxime Ripard, Paul Kocialkowski, Mauro Carvalho Chehab,
Jernej Skrabec, Samuel Holland, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, linux-media, linux-staging,
devicetree, linux-sunxi, linux-arm-kernel, linux-kernel
In-Reply-To: <CAGb2v64wDvLMFn9DYs-kH1S2PpHJat-imxR5eJSQAUYjOp=Xdg@mail.gmail.com>
Dne sobota, 30. maj 2026 ob 18:43:05 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
> On Tue, May 5, 2026 at 7:18 PM Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> >
> > Dne torek, 5. maj 2026 ob 15:48:08 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
> > > The Allwinner H616 SoC has a video engine hardware block like the one
> > > found on previous generations such as the H6. In addition to the
> > > currently supported features of the H6, it is also supposed to include
> >
> > Remove "supposed".
>
> I can't actually verify that, so "supposed" is accurate from my point of
> view.
Isn't info from manual good enough?
In the interest of unblocking this, I would be fine with "supposed" too,
but manual and all my experiments show VP9 is supported.
Best regards,
Jernej
>
> ChenYu
>
> > > a VP9 decoder. However software support for this is currently missing
> > > and still needs to be reverse engineered from the vendor BSP.
> > >
> > > Add the compatible for the H616 variant, using the H6 variant data.
> > >
> > > Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
> >
> > With that:
> > Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> >
> > Best regards,
> > Jernej
> >
> >
>
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] arm64: dts: renesas: r8a779g0: Add gPTP node
From: sashiko-bot @ 2026-06-13 9:29 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: devicetree, robh, wsa+renesas, conor+dt
In-Reply-To: <20260612092851.2141782-4-niklas.soderlund+renesas@ragnatech.se>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Adding the standalone `gptp` node without updating the `tsn0` node creates overlapping `reg` memory regions in the device tree, which will cause `-EBUSY` probe failures.
- [Low] The `gptp: ptp@e6449000` node is placed out of order with respect to its unit address.
--
commit b1efd0e5ff9459d7a25c1c76a2bb7ef3ccffd5d2
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
arm64: dts: renesas: r8a779g0: Add gPTP node
This commit adds the gPTP module node to the r8a779g0 device tree, sharing
it between the RAVB and RTSN Ethernet devices on the SoC.
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> index 82a7278836e57..4f2844995c44d 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
[ ... ]
> @@ -603,6 +603,15 @@ tsn0: ethernet@e6460000 {
> status = "disabled";
> };
>
> + gptp: ptp@e6449000 {
[Severity: Low]
This isn't a bug, but should the gptp node be placed before the tsn0 node?
Device tree nodes within a simple-bus are conventionally sorted in ascending
order by their unit address. Placing ptp@e6449000 after ethernet@e6460000
violates this ascending unit address order.
> + compatible = "renesas,r8a779g0-gptp", "renesas,rcar-gen4-gptp";
> + reg = <0 0xe6449000 0 0x500>;
[Severity: High]
Will this cause a resource request conflict with the tsn0 node?
The tsn0 node currently defines the same memory region:
tsn0: ethernet@e6460000 {
compatible = "renesas,r8a779g0-ethertsn", "renesas,rcar-gen4-ethertsn";
reg = <0 0xe6460000 0 0x7000>,
<0 0xe6449000 0 0x500>;
reg-names = "tsnes", "gptp";
When both nodes are enabled, their respective drivers will attempt to request
exclusive access to the 0xe6449000 region. This will result in an -EBUSY
probe failure for whichever driver initializes second.
Does the tsn0 node need to be updated to remove this overlapping region now
that a standalone gptp node is being added?
> + clocks = <&cpg CPG_MOD 2723>;
> + power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
> + resets = <&cpg 2723>;
> + status = "disabled";
> + };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612092851.2141782-1-niklas.soderlund+renesas@ragnatech.se?part=3
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] ptp: Add driver for R-Car Gen4
From: sashiko-bot @ 2026-06-13 9:29 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: conor+dt, robh, wsa+renesas, devicetree
In-Reply-To: <20260612092851.2141782-3-niklas.soderlund+renesas@ragnatech.se>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] Missing return value check for pm_runtime_get_sync() before hardware access.
- [High] Potential divide-by-zero kernel panic due to unchecked clk_get_rate().
- [High] The driver lacks system PM callbacks to restore hardware register state after a suspend/resume cycle.
- [Medium] Missing PM runtime cleanup on the ptp_clock_register() error path.
- [Medium] The PTP clock is registered and exposed to userspace before the hardware timer is enabled.
--
commit 0a2d69b0a8fcc58f8e457187381c743ade641986
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
ptp: Add driver for R-Car Gen4
This commit adds a new driver for the gPTP timer found on R-Car Gen4
devices. The clock can be used by Ethernet drivers for PTP time
synchronization.
> diff --git a/drivers/ptp/ptp_rcar_gen4.c b/drivers/ptp/ptp_rcar_gen4.c
> new file mode 100644
> index 0000000000000..ab0be2431be8d
> --- /dev/null
> +++ b/drivers/ptp/ptp_rcar_gen4.c
[ ... ]
> +static int ptp_rcar_gen4_probe(struct platform_device *pdev)
> +{
> + struct ptp_rcar_gen4_priv *priv;
> + struct device *dev = &pdev->dev;
[ ... ]
> + /* Default timer increment in ns.
> + * bit[31:27] - integer
> + * bit[26:0] - decimal
> + * increment[ns] = perid[ns] * 2^27 => (1ns * 2^27) / rate[hz]
> + */
> + priv->default_addend =
> + div_s64(1000000000LL << 27, clk_get_rate(priv->clk));
[Severity: High]
If clk_get_rate() returns 0 because the hardware clock is unconfigured or
fails to determine the rate, does this div_s64() result in a divide-by-zero
panic during the probe sequence?
Would it be better to verify the rate is strictly greater than zero before
performing the division?
> +
> + pm_runtime_enable(dev);
> + pm_runtime_get_sync(dev);
[Severity: High]
Does this code need to check the return value of pm_runtime_get_sync()?
If the device fails to resume, perhaps due to a power domain failure,
could accessing its registers via iowrite32() cause a synchronous external
abort and lead to a kernel crash?
> +
> + iowrite32(priv->default_addend, priv->base + PTPTIVC0_REG);
> +
> + priv->clock = ptp_clock_register(&priv->info, dev);
> + if (IS_ERR(priv->clock))
> + return PTR_ERR(priv->clock);
[Severity: Medium]
If ptp_clock_register() fails and the function returns the error directly,
does this leave the runtime PM reference permanently incremented?
It looks like pm_runtime_put_sync() and pm_runtime_disable() are not called
on this error path.
[Severity: Medium]
Is it possible for userspace to interact with the device before the hardware
timer is enabled?
The ptp_clock_register() function exposes the PTP character device, but the
timer is only enabled via PTPTMEC_REG after this succeeds. Could a process
open the device and read invalid time values during this race window?
> +
> + iowrite32(1, priv->base + PTPTMEC_REG);
> +
> + return 0;
> +}
[ ... ]
> +static struct platform_driver ptp_rcar_gen4_driver = {
> + .driver = {
> + .name = "ptp-rcar-gen4",
> + .of_match_table = ptp_rcar_gen4_of_match,
> + },
> + .probe = ptp_rcar_gen4_probe,
> + .remove = ptp_rcar_gen4_remove,
> +};
[Severity: High]
Does this driver need system PM callbacks to handle suspend and resume?
Without them, if the system enters deep sleep and the SoC power domain
shuts off the device, the internal register state, such as the default
addend and enable bit, might be lost. Would the PTP clock hardware remain
stopped and broken after the system wakes up?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612092851.2141782-1-niklas.soderlund+renesas@ragnatech.se?part=2
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] dt-bindings: ptp: renesas,rcar-gen4-gptp: Add R-Car Gen4
From: sashiko-bot @ 2026-06-13 9:29 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: wsa+renesas, robh, conor+dt, devicetree
In-Reply-To: <20260612092851.2141782-2-niklas.soderlund+renesas@ragnatech.se>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The device tree changes introduce a standalone node for the gPTP timer which maps the exact same physical memory region already mapped by the existing Ethernet controller, leading to a resource conflict during probe.
--
commit b3e38755e98012153ce2a29973eff93cb0cf332d
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
dt-bindings: ptp: renesas,rcar-gen4-gptp: Add R-Car Gen4
This commit adds device tree bindings for the R-Car Gen4 gPTP timer. The
timer enables system-wide clock synchronization and is shared by different
Ethernet devices across Gen4 platforms.
> diff --git a/Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml b/Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml
> new file mode 100644
> index 0000000000000..3edd64d400387
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml
> @@ -0,0 +1,64 @@
[ ... ]
> +properties:
> + compatible:
> + items:
> + - enum:
> + - renesas,r8a779f0-gptp # S4-8
> + - renesas,r8a779g0-gptp # V4H
> + - renesas,r8a779h0-gptp # V4M
> + - const: renesas,rcar-gen4-gptp
> +
> + reg:
> + maxItems: 1
[Severity: High]
Will this standalone reg mapping conflict with the existing Ethernet TSN
node?
The device tree bindings introduce a standalone node for the gPTP timer
which maps the exact same physical memory region (e.g. 0xe6449000) already
claimed by the existing renesas,ethertsn device node via its gptp reg
resource.
At runtime, the new ptp_rcar_gen4 driver maps this with:
drivers/ptp/ptp_rcar_gen4.c:ptp_rcar_gen4_probe() {
...
priv->base = devm_platform_ioremap_resource(pdev, 0);
...
}
And the existing rtsn driver does the same:
drivers/net/ethernet/renesas/rtsn.c:rtsn_probe() {
...
ptpaddr = devm_ioremap_resource(&pdev->dev, res);
...
}
Since devm_ioremap_resource() internally calls request_mem_region(), which
claims exclusive access to the physical memory, the second driver to probe
will be rejected with -EBUSY and fail to load.
Should shared hardware registers be modeled using a provider-consumer
pattern with phandles instead of duplicating reg mappings across distinct
nodes?
> +
> + clocks:
> + maxItems: 1
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612092851.2141782-1-niklas.soderlund+renesas@ragnatech.se?part=1
^ permalink raw reply
* Re: [PATCH net-next v4 13/13] net: ethernet: adi: Add a driver for the ADIN1140 MACPHY
From: Paolo Abeni @ 2026-06-13 9:26 UTC (permalink / raw)
To: ciprian.regus
Cc: parthiban.veerasooran, andrew+netdev, davem, edumazet, kuba,
pabeni, horms, corbet, skhan, andrew, hkallweit1, linux, robh,
krzk+dt, conor+dt, netdev, linux-kernel, linux-doc, devicetree
In-Reply-To: <20260609-adin1140-driver-v4-13-0753e28ee004@analog.com>
From: AI Reviewer <ai@example.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://netdev-ai.bots.linux.dev/sashiko/
---
net: ethernet: adi: Add a driver for the ADIN1140 MACPHY
This patch adds a driver for the ADIN1140 10BASE-T1S MAC-PHY which talks
to the host over SPI using the OA TC6 protocol. It introduces a custom
mii_bus to work around two hardware issues, and exposes both rtnl link
stats and ethtool MAC stats from periodically polled hardware counters.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 50f795dfa880..c3cab8f7b9ef 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1858,6 +1858,14 @@ S: Supported
> W: https://ez.analog.com/linux-software-drivers
> F: drivers/dma/dma-axi-dmac.c
>
> +ANALOG DEVICES INC ETHERNET DRIVERS
> +M: Ciprian Regus <ciprian.regus@analog.com>
> +L: netdev@vger.kernel.org
> +S: Maintained
> +W: https://ez.analog.com/linux-software-drivers
> +F: Documentation/devicetree/bindings/net/adi,ad3306.yaml
> +F: drivers/net/ethernet/adi/adin1140.c
[Medium]
The MAINTAINERS entry references
Documentation/devicetree/bindings/net/adi,ad3306.yaml, but that file is
not added by this patch and does not appear elsewhere in the tree.
The driver also introduces two new of compatibles:
{ .compatible = "adi,ad3306" },
{ .compatible = "adi,adin1140" },
with no YAML schema. Should the binding document be added in this same
series so that the F: line resolves and dt_binding_check can validate
the new compatibles?
> diff --git a/drivers/net/ethernet/adi/adin1140.c b/drivers/net/ethernet/adi/adin1140.c
> new file mode 100644
> index 000000000000..306e5de6faa5
> --- /dev/null
> +++ b/drivers/net/ethernet/adi/adin1140.c
[ ... ]
> +static int adin1140_mac_filter_set(struct adin1140_priv *priv,
> + const u8 *addr, const u8 *mask,
> + u8 slot)
> +{
> + u32 reg_address;
> + u32 val;
> + int ret;
> +
> + if (slot >= ADIN1140_MAC_FILT_MAX_SLOT)
> + return -ENOSPC;
> +
> + reg_address = ADIN1140_MAC_ADDR_FILT_UPR_REG + 2 * slot;
> +
> + ret = oa_tc6_write_register_mms(priv->tc6, OA_TC6_MAC_MMS1,
> + reg_address,
> + get_unaligned_be16(&addr[0]) |
> + ADIN1140_MAC_ADDR_FILT_APPLY2PORT1 |
> + ADIN1140_MAC_ADDR_FILT_TO_HOST);
> + if (ret)
> + return ret;
> +
> + reg_address = ADIN1140_MAC_ADDR_FILT_LWR_REG + 2 * slot;
> + ret = oa_tc6_write_register_mms(priv->tc6, OA_TC6_MAC_MMS1,
> + reg_address,
> + get_unaligned_be32(&addr[2]));
> + if (ret)
> + return ret;
> +
> + /* Only the first 2 destination MAC filter slots support masking.
> + * For the other entries, the destination address in the received
> + * frame must match exactly.
> + */
> + if (slot >= ADIN1140_MAC_FILT_MASK_LIMIT)
> + return 0;
> +
> + val = get_unaligned_be16(&mask[0]);
> + reg_address = ADIN1140_MAC_ADDR_MASK_UPR_REG + (2 * slot);
> +
> + ret = oa_tc6_write_register_mms(priv->tc6, OA_TC6_MAC_MMS1,
> + reg_address, val);
> + if (ret)
> + return ret;
> +
> + val = get_unaligned_be32(&mask[2]);
> + reg_address = ADIN1140_MAC_ADDR_MASK_LWR_REG + (2 * slot);
> +
> + return oa_tc6_write_register_mms(priv->tc6, OA_TC6_MAC_MMS1,
> + reg_address, val);
> +}
[Medium]
adin1140_mac_filter_set() performs up to four sequential
oa_tc6_write_register_mms() calls (filter upper, filter lower, mask
upper, mask lower) and returns at the first error without rolling back
the writes that already succeeded.
If the upper-half write of a new MAC succeeds and the lower-half write
fails, the slot is left programmed with (new high | old low). Callers
treat this as single-shot:
ret = adin1140_mac_filter_set(priv, address->sa_data, mask,
ADIN1140_MAC_FILT_UC_SLOT);
if (ret)
return ret;
eth_commit_mac_addr_change(netdev, addr);
so adin1140_set_mac_address() leaves netdev->dev_addr at the old value
while the hardware filter now matches a third, hybrid address. The same
applies to adin1140_rx_mode_work() which just returns on the first
error and leaves the dynamic filter table inconsistent with
netdev->uc/mc.
Should this function stage the writes (or perform a rollback / clear of
the affected slot) so a partial failure cannot leave the hardware
filter in a state that does not match the driver's view?
[ ... ]
> +static void adin1140_rx_mode_work(struct work_struct *work)
> +{
> + struct adin1140_priv *priv = container_of(work, struct adin1140_priv,
> + rx_mode_work);
> + struct netdev_hw_addr *ha;
> + bool all_multi, promisc;
> + u8 mask[ETH_ALEN];
> + u8 start, end;
> + u32 mac_addrs;
> + u8 slot, i;
> + int ret;
> +
> + /* The ADIN1140 has 16 dest MAC address filter slots:
> + * 0 - reserved for all multicast filter.
> + * 1 - reserved for broadcast filter.
> + * 2 - reserved for the device's own unicast MAC.
> + * 3 -> 15 - available for other unicast/multicast filters.
> + */
> +
> + mac_addrs = netdev_uc_count(priv->netdev) +
> + netdev_mc_count(priv->netdev);
> +
> + if (priv->netdev->flags & IFF_PROMISC) {
> + promisc = true;
> + all_multi = false;
> + } else if (priv->netdev->flags & IFF_ALLMULTI) {
> + promisc = false;
> + all_multi = true;
> + } else if (mac_addrs <= ADIN1140_MAC_FILT_AVAIL) {
> + promisc = false;
> + all_multi = false;
> +
> + slot = ADIN1140_MAC_FILT_UC_SLOT + 1;
> + memset(mask, 0xFF, ETH_ALEN);
> +
> + netdev_for_each_uc_addr(ha, priv->netdev) {
> + ret = adin1140_mac_filter_set(priv, ha->addr, mask,
> + slot);
> + if (ret)
> + return;
> +
> + slot++;
> + }
> +
> + netdev_for_each_mc_addr(ha, priv->netdev) {
> + ret = adin1140_mac_filter_set(priv, ha->addr, mask,
> + slot);
> + if (ret)
> + return;
> +
> + slot++;
> + }
> +
> + for (i = slot; i < ADIN1140_MAC_FILT_MAX_SLOT; i++) {
> + ret = adin1140_mac_filter_clear(priv, i);
> + if (ret)
> + return;
> + }
> +
> + } else {
> + /* The filter table is full. Enable promisc mode. */
> + promisc = true;
> + all_multi = false;
> +
> + start = ADIN1140_MAC_FILT_UC_SLOT + 1;
> + end = ADIN1140_MAC_FILT_MAX_SLOT;
> + for (i = start; i < end; i++) {
> + ret = adin1140_mac_filter_clear(priv, i);
> + if (ret)
> + return;
> + }
> + }
> +
> + ret = adin1140_promiscuous_mode(priv, promisc);
> + if (ret)
> + return;
> +
> + adin1140_filter_all_multicast(priv, all_multi);
> +}
[High]
This work iterates priv->netdev->uc and ->mc with no synchronization:
netdev_for_each_uc_addr(ha, priv->netdev) {
ret = adin1140_mac_filter_set(priv, ha->addr, mask, slot);
...
}
netdev_for_each_mc_addr(ha, priv->netdev) {
...
}
netdev_for_each_uc_addr() and netdev_for_each_mc_addr() expand to
plain list_for_each_entry() over dev->uc.list / dev->mc.list. Callers
are required to hold netif_addr_lock_bh() (or rtnl) because dev_uc_add
/ dev_uc_del / dev_mc_add / dev_mc_del can mutate those lists from
user-space ip address/maddr changes.
Inside the loop ha->addr is then handed to adin1140_mac_filter_set(),
which performs SPI register writes that can sleep, so taking
netif_addr_lock_bh() across the iteration is not directly viable.
Can this race with a concurrent dev_uc_del() / dev_mc_del() and
dereference freed list entries (or skip / duplicate filter slots)?
Other ethernet drivers that need to issue sleeping ops while syncing
the address lists use __dev_uc_sync() / __dev_mc_sync() which copy
state under netif_addr_lock; would that pattern be more appropriate
here?
[Medium]
In the IFF_PROMISC and IFF_ALLMULTI branches, slots 3..15 are not
cleared:
if (priv->netdev->flags & IFF_PROMISC) {
promisc = true;
all_multi = false;
} else if (priv->netdev->flags & IFF_ALLMULTI) {
promisc = false;
all_multi = true;
} else if (mac_addrs <= ADIN1140_MAC_FILT_AVAIL) {
...
for (i = slot; i < ADIN1140_MAC_FILT_MAX_SLOT; i++) {
ret = adin1140_mac_filter_clear(priv, i);
...
}
} else {
...
for (i = start; i < end; i++) {
ret = adin1140_mac_filter_clear(priv, i);
...
}
}
If a previous invocation populated slots 3..N with extra unicast or
multicast filters and the user then enables IFF_ALLMULTI, those
previously installed unicast filters remain active in hardware
(carrying APPLY2PORT1 | TO_HOST). Should the IFF_ALLMULTI path also
clear slots 3..15 so traffic for addresses no longer in netdev->uc/mc
is not still forwarded to the host?
[ ... ]
> +static void adin1140_stats_work(struct work_struct *work)
> +{
> + struct delayed_work *dwork = to_delayed_work(work);
> + u64 stat_buff[ADIN1140_STATS_CNT] = {};
> + struct adin1140_priv *priv;
> + u32 reg_val;
> + int ret;
> + u32 i;
> +
> + priv = container_of(dwork, struct adin1140_priv, stats_work);
> +
> + for (i = 0; i < ARRAY_SIZE(adin1140_stat_regs); i++) {
> + ret = oa_tc6_read_register_mms(priv->tc6, OA_TC6_MAC_MMS1,
> + adin1140_stat_regs[i],
> + ®_val);
> + if (ret)
> + break;
> +
> + stat_buff[i] = reg_val;
> + }
> +
> + scoped_guard(spinlock, &priv->stat_lock)
> + memcpy(&priv->stats, stat_buff, sizeof(priv->stats));
> +
> + schedule_delayed_work(dwork, ADIN1140_STATS_CHECK_DELAY);
> +}
[Medium]
stat_buff is zero-initialized and the loop break on a read error is
followed unconditionally by:
scoped_guard(spinlock, &priv->stat_lock)
memcpy(&priv->stats, stat_buff, sizeof(priv->stats));
If oa_tc6_read_register_mms() fails partway through, every entry from
the failing index onwards is still zero, and that all-zero tail is
copied over the previously valid u64 counters. Since priv->stats[] is
read directly by adin1140_ndo_get_stats64(),
adin1140_get_eth_mac_stats() and adin1140_get_ethtool_stats(), a
single transient SPI/TC6 hiccup makes the rtnl_link_stats64 and
ethtool_eth_mac_stats counters drop to zero before climbing again.
Should the memcpy be skipped on error, or should partial updates be
merged into priv->stats[] only for the indices that were read
successfully?
[Medium]
The hardware counters at MMS1 0xA1..0xBA are read into u32 reg_val and
then stored as-is into the u64 stat_buff[i]:
ret = oa_tc6_read_register_mms(priv->tc6, OA_TC6_MAC_MMS1,
adin1140_stat_regs[i],
®_val);
...
stat_buff[i] = reg_val;
priv->stats[] feeds rtnl_link_stats64 and ethtool_eth_mac_stats, both
of which document monotonic u64 counters. On 32-bit hardware register
wrap (0xFFFFFFFF -> 0) the user-visible u64 value will go backwards,
and with a 3-second poll interval a fast counter (e.g.
FramesReceivedOK on a busy 10BASE-T1S segment) can wrap entirely
between samples. Should the driver compute deltas with 32-bit wrap
handling and accumulate them into a software u64 counter rather than
overwriting?
[ ... ]
> +static void adin1140_get_ethtool_stats(struct net_device *netdev,
> + struct ethtool_stats *stats, u64 *data)
> +{
> + struct adin1140_priv *priv = netdev_priv(netdev);
> + u32 i;
> +
> + scoped_guard(spinlock, &priv->stat_lock) {
> + for (i = 0; i < ARRAY_SIZE(adin1140_stats); i++)
> + data[i] = priv->stats[adin1140_stats[i].idx];
> + }
> +}
> +
> +static void adin1140_get_ethtool_strings(struct net_device *netdev, u32 sset,
> + u8 *p)
> +{
> + u32 i;
> +
> + switch (sset) {
> + case ETH_SS_STATS:
> + for (i = 0; i < ARRAY_SIZE(adin1140_stats); i++)
> + ethtool_puts(&p, adin1140_stats[i].name);
> +
> + break;
> + }
> +}
[Medium]
The driver implements both .ndo_get_stats64 and .get_eth_mac_stats,
yet adin1140_stats[] adds private ethtool -S strings whose values are
already exposed (or trivially derivable) through those standard uAPIs:
{.name = "rx_unicast_frames", .idx = rx_uc_frames},
{.name = "rx_preamble_errors", .idx = rx_preamble_errors},
{.name = "rx_ifg_errors", .idx = rx_ifg_errors},
{.name = "rx_addr_filter_dropped", .idx = rx_addr_filter_dropped},
{.name = "tx_unicast_frames", .idx = tx_uc_frames},
rx_addr_filter_dropped is already aggregated into
rtnl_link_stats64.rx_dropped by this same driver:
storage->rx_dropped = priv->stats[rx_fifo_full_dropped] +
priv->stats[rx_addr_filter_dropped];
rx_unicast_frames and tx_unicast_frames are derivable from
ethtool_eth_mac_stats (FramesReceivedOK minus broadcast minus
multicast, and the Xmitted equivalents) which are populated in
__adin1140_eth_mac_stats.
Per Documentation/networking/statistics.rst, should these counters be
left out of ethtool -S since standard uAPIs already cover them?
--
This is an AI-generated review.
^ permalink raw reply
* Re: [PATCH v1 2/4] arm64: dts: qcom: sm8550: Add JPEG encoder node
From: Atanas Filipov @ 2026-06-13 9:24 UTC (permalink / raw)
To: Bryan O'Donoghue, linux-media
Cc: mchehab, robh, krzk+dt, conor+dt, andersson, konradybcio,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <8d230cca-2023-4a13-876f-d5db8eb200a1@kernel.org>
Thank you for the feedback. I understand the reasoning, but I
respectfully disagree with this approach for the following reasons.
While it is true that the JPEG encoder shares the same camera NOC and
power domain infrastructure as CAMSS, that is a hardware topology detail
— not a sufficient justification for imposing a software dependency. The
driver is a fully
self-contained V4L2 mem2mem encoder, implemented like every other JPEG
encoder driver currently in the kernel (imx-jpeg, s5p-jpeg, mtk-jpeg,
nxp-jpeg). None of those are sub-nodes of a parent ISP or camera
subsystem driver.
Making the JPEG encoder a sub-node of camss would introduce an
unnecessary and artificial coupling: the JPEG encoder cannot be probed,
built, or used independently of the CAMSS driver, even on platforms
where CAMSS is disabled. This directly contradicts the kernel's
principle of independent, single-purpose drivers.
The shared hardware resources (clocks, interconnects, IOMMU stream IDs,
power domain) are already fully described in the device tree node and
handled by the standard kernel frameworks — there is no functional
reason to nest the node under camss.
For these reasons I would prefer to keep the JPEG encoder as a
standalone platform device with its own DT node, consistent with how all
comparable JPEG encoder drivers are structured in the kernel today.
afilipov
On 6/13/2026 2:14 AM, Bryan O'Donoghue wrote:
> On 12/06/2026 20:44, Atanas Filipov wrote:
>> + qcom_jpeg_enc: jpeg-encoder@ac4e000 {
>
> One key bit of review feedback I gave in the previous leaked version of
> this driver is that since the jpeg-encoder is part of the CAMSS block it
> should be a sub-node of camss as OPE, CSIPHY and other blocks will be.
>
> Please take that feedback onboard in your v2.
>
> ---
> bod
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: iio: magnetometer: add QST QMC5883L Sensor
From: Sirat @ 2026-06-13 8:57 UTC (permalink / raw)
To: Jonathan Cameron
Cc: robh, krzk+dt, conor+dt, dlechner, nuno.sa, andy, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260612173013.64f435ab@jic23-huawei>
On Fri, Jun 12, 2026 at 10:30 PM Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Fri, 12 Jun 2026 18:45:26 +0600
> Siratul Islam <email@sirat.me> wrote:
>
> > Add devicetree binding for the QST QMC5883L 3-Axis Magnetic Sensor
> > connected via i2c.
> > Interrupt not implemented in driver but kept in the binding for future
> > addition.
> No need to mention that
Got it. In the past I was advised to mention certain choices in the
commit message. I am still looking for the balance.
>
> The rest looks good to me.
>
> Thanks,
>
> Jonathan
>
Thanks
Sirat
^ permalink raw reply
* Re: [PATCH 3/3] iio: magnetometer: add driver for QST QMC5883L Sensor
From: Sirat @ 2026-06-13 8:47 UTC (permalink / raw)
To: Jonathan Cameron
Cc: robh, krzk+dt, conor+dt, dlechner, nuno.sa, andy, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260612180235.3e505c66@jic23-huawei>
On Fri, Jun 12, 2026 at 11:02 PM Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Fri, 12 Jun 2026 18:45:27 +0600
> Siratul Islam <email@sirat.me> wrote:
>
> > Add driver for the QST QMC5883L 3-Axis Magnetic Sensor
> > connected via i2c.
> >
> > Signed-off-by: Siratul Islam <email@sirat.me>
>
> Trying to avoid repeating stuff Joshua already covered.
> Various comments inline.
>
> Thanks,
>
> Jonathan
>
> > diff --git a/drivers/iio/magnetometer/qmc5883l.c b/drivers/iio/magnetometer/qmc5883l.c
> > new file mode 100644
> > index 000000000000..055e51570635
> > --- /dev/null
> > +++ b/drivers/iio/magnetometer/qmc5883l.c
...
> > +#define QMC5883L_OSR_512 FIELD_PREP_CONST(QMC5883L_OSR_MASK, 0x00)
> > +#define QMC5883L_OSR_256 FIELD_PREP_CONST(QMC5883L_OSR_MASK, 0x01)
> > +#define QMC5883L_OSR_128 FIELD_PREP_CONST(QMC5883L_OSR_MASK, 0x02)
> > +#define QMC5883L_OSR_64 FIELD_PREP_CONST(QMC5883L_OSR_MASK, 0x03)
> These are used for matching - normally we'd add defines for the filed value and
> then use FIELD_GET() to extract it for matching.
> e.g.
> #define QMC5883L_OSR_512 0x0
> #define QMC5883L_OSR_256 0x1
> rather these.
>
I thought using _CONST would be better for compile time checks and not
needing to use FIELD_GET everywhere. The values 0x01, 0x02 don't have
a lot of meaning in a vacuum. But of course you would have more
experience about it and I'd love to know why we shouldn't use const.
> > +
...
> > +static const int qmc5883l_rng_avail[] = {
> > + 0, QMC5883L_SCALE_2G, /* 2G */
>
> I'm not sure the defines really help. Perhaps push the value down here
> and then look it up from this array when matching.
>
But then the array will be serving more than 1 purpose? kind of like a
side effect I think.
>
...
> > +
> > + /* DRDY pin no used in this version of the driver */
> > + ret = regmap_write(data->regmap, QMC5883L_REG_CTRL2,
> > + QMC5883L_INT_DISABLE);
> I don't mind if these sorts of cases go a little over 80 chars as sometimes
> it helps readability.
>
I try to disable clang-format for cases like this. It's an oversight on my side.
>
> Does it really reset with interrupts on? That's odd. Mind you the
> INT_ENB sounds like it would be an enable but as you have named it here
> it is actually a disable so all bets are off when it comes to sensible ;)
>
The datasheet says "The interrupt can be disabled by set 0AH[0] = 1"
which I took as it's enabled by default.
I explicitly disable it just to be safe.
>
...
> > +static const struct of_device_id qmc5883l_match[] = {
> > + { .compatible = "qstcorp,qmc5883l" },
> > + { },
>
> As below, no comma.
>
I did it so that clang-format doesn't wrap it all in 1 line. I forgot
to remove the comma before sending the patch. Sorry.
> > +};
>
Thanks
Sirat
^ permalink raw reply
* Re: [PATCH] dt-bindings: sound: nvidia,tegra30-ahub: Convert to DT schema
From: sashiko-bot @ 2026-06-13 8:35 UTC (permalink / raw)
To: Charan Pedumuru; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260613-nvidia-ahub-v1-1-5b7e85301736@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The `allOf` conditional block for `nvidia,tegra124-ahub` fails to constrain the `reg` property count, allowing missing register regions to silently pass validation.
--
commit 9a0f1d546144b78d414e177cfaf59f6770e9ba9b
Author: Charan Pedumuru <charan.pedumuru@gmail.com>
dt-bindings: sound: nvidia,tegra30-ahub: Convert to DT schema
Converts the NVIDIA Tegra Audio Hub (AHUB) binding from text to DT schema.
The patch enforces per-SoC differences in reset-names, dma-names, and reg
entry counts using allOf conditionals.
> diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.yaml
> new file mode 100644
> index 0000000000000..82738058f6722
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.yaml
[ ... ]
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: nvidia,tegra124-ahub
> + then:
> + properties:
> + "#address-cells":
> + const: 2
[Severity: Low]
Does the tegra124-ahub conditional need to enforce the reg property count?
The commit message mentions that reg entry counts described in the text
binding are now enforced via allOf conditionals, but this block omits the
reg constraints for tegra124-ahub. It falls back to the top-level
minItems: 2, maxItems: 3, which could allow a tegra124-ahub node with only
2 register entries to incorrectly pass schema validation. Since tegra114-ahub
enforces minItems: 3 and maxItems: 3, should this block do the same?
> +
> + "#size-cells":
> + const: 2
> +
> + resets:
> + minItems: 21
> + maxItems: 21
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260613-nvidia-ahub-v1-1-5b7e85301736@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v4 6/7] arm64: dts: allwinner: a100: reserve RAM for ATF
From: Alexander Sverdlin @ 2026-06-13 8:34 UTC (permalink / raw)
To: Jernej Škrabec, linux-arm-kernel, linux-sunxi
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Hans de Goede, Dmitry Torokhov, Andre Przywara,
Jun Yan, Lukas Schmid, J. Neuschäfer, Eric Biggers,
Michal Simek, Luca Weiss, Sven Peter, Maxime Ripard, devicetree,
linux-kernel, linux-input
In-Reply-To: <_6NEZ78hR8a_3V2bhBAGoQ@gmail.com>
Hi Jernej,
On Sat, 2026-06-13 at 10:22 +0200, Jernej Škrabec wrote:
> Dne petek, 5. junij 2026 ob 09:09:20 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> > Add reserved-memory node carving out Trusted Firmware-A region spanning
> > fixed 256K from physical address 0x40000000. Even though Allwinner ATF
> > itself passes the address range in the fdt to U-Boot, U-Boot currently
> > only reserves this memory internally, but doesn't carve out the region
> > in the fdt passed to Linux.
> >
> > Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
>
> NAK. It is job of boot procedure to properly inject TF-A reserved node.
> Any issue should be fixed there.
like in commit 0d17c865118881609ea7e381c7cadbb7979cc596
("arm64: dts: allwinner: Add Allwinner H616 .dtsi file")
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
? ;-)
> Best regards,
> Jernej Skrabec
>
> > ---
> > Changelog:
> > v4:
> > - new patch
> >
> > arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > index 7cb06b19b5a5..d8391663fd1d 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> > @@ -87,6 +87,22 @@ osc32k: osc32k-clk {
> > #clock-cells = <0>;
> > };
> >
> > + reserved-memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + /*
> > + * 256 KiB reserved for Trusted Firmware-A (BL31).
> > + * This is added by BL31 itself, but some bootloaders fail
> > + * to propagate this into the DTB handed to kernels.
> > + */
> > + secmon@40000000 {
> > + reg = <0x0 0x40000000 0x0 0x40000>;
> > + no-map;
> > + };
> > + };
> > +
> > timer {
> > compatible = "arm,armv8-timer";
> > interrupts = <GIC_PPI 13
--
Alexander Sverdlin.
^ permalink raw reply
* [PATCH] dt-bindings: sound: nvidia,tegra30-ahub: Convert to DT schema
From: Charan Pedumuru @ 2026-06-13 8:24 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter
Cc: linux-sound, devicetree, linux-tegra, linux-kernel,
Charan Pedumuru
Convert NVIDIA Tegra Audio Hub (AHUB) binding to DT schema.
The per-SoC differences in reset-names, dma-names, and reg entry
counts described in the text binding are now enforced via allOf
conditionals, making previously prose-only constraints machine
validatable.
Child node CIF ID properties are formally declared under
patternProperties to allow dtschema to validate i2s subnodes.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
.../bindings/sound/nvidia,tegra30-ahub.txt | 88 ------
.../bindings/sound/nvidia,tegra30-ahub.yaml | 299 +++++++++++++++++++++
2 files changed, 299 insertions(+), 88 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
deleted file mode 100644
index 0e9a1895d7fb..000000000000
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
+++ /dev/null
@@ -1,88 +0,0 @@
-NVIDIA Tegra30 AHUB (Audio Hub)
-
-Required properties:
-- compatible : For Tegra30, must contain "nvidia,tegra30-ahub". For Tegra114,
- must contain "nvidia,tegra114-ahub". For Tegra124, must contain
- "nvidia,tegra124-ahub". Otherwise, must contain "nvidia,<chip>-ahub",
- plus at least one of the above, where <chip> is tegra132.
-- reg : Should contain the register physical address and length for each of
- the AHUB's register blocks.
- - Tegra30 requires 2 entries, for the APBIF and AHUB/AUDIO register blocks.
- - Tegra114 requires an additional entry, for the APBIF2 register block.
-- interrupts : Should contain AHUB interrupt
-- clocks : Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-- clock-names : Must include the following entries:
- - d_audio
- - apbif
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- Tegra30 and later:
- - d_audio
- - apbif
- - i2s0
- - i2s1
- - i2s2
- - i2s3
- - i2s4
- - dam0
- - dam1
- - dam2
- - spdif
- Tegra114 and later additionally require:
- - amx
- - adx
- Tegra124 and later additionally require:
- - amx1
- - adx1
- - afc0
- - afc1
- - afc2
- - afc3
- - afc4
- - afc5
-- ranges : The bus address mapping for the configlink register bus.
- Can be empty since the mapping is 1:1.
-- dmas : Must contain an entry for each entry in clock-names.
- See ../dma/dma.txt for details.
-- dma-names : Must include the following entries:
- - rx0 .. rx<n>
- - tx0 .. tx<n>
- ... where n is:
- Tegra30: 3
- Tegra114, Tegra124: 9
-- #address-cells : For the configlink bus. Should be <1>;
-- #size-cells : For the configlink bus. Should be <1>.
-
-AHUB client modules need to specify the IDs of their CIFs (Client InterFaces).
-For RX CIFs, the numbers indicate the register number within AHUB routing
-register space (APBIF 0..3 RX, I2S 0..5 RX, DAM 0..2 RX 0..1, SPDIF RX 0..1).
-For TX CIFs, the numbers indicate the bit position within the AHUB routing
-registers (APBIF 0..3 TX, I2S 0..5 TX, DAM 0..2 TX, SPDIF TX 0..1).
-
-Example:
-
-ahub@70080000 {
- compatible = "nvidia,tegra30-ahub";
- reg = <0x70080000 0x200 0x70080200 0x100>;
- interrupts = < 0 103 0x04 >;
- nvidia,dma-request-selector = <&apbdma 1>;
- clocks = <&tegra_car 106>, <&tegra_car 107>;
- clock-names = "d_audio", "apbif";
- resets = <&tegra_car 106>, <&tegra_car 107>, <&tegra_car 30>,
- <&tegra_car 11>, <&tegra_car 18>, <&tegra_car 101>,
- <&tegra_car 102>, <&tegra_car 108>, <&tegra_car 109>,
- <&tegra_car 110>, <&tegra_car 10>;
- reset-names = "d_audio", "apbif", "i2s0", "i2s1", "i2s2",
- "i2s3", "i2s4", "dam0", "dam1", "dam2",
- "spdif";
- dmas = <&apbdma 1>, <&apbdma 1>;
- <&apbdma 2>, <&apbdma 2>;
- <&apbdma 3>, <&apbdma 3>;
- <&apbdma 4>, <&apbdma 4>;
- dma-names = "rx0", "tx0", "rx1", "tx1", "rx2", "tx2", "rx3", "tx3";
- ranges;
- #address-cells = <1>;
- #size-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.yaml
new file mode 100644
index 000000000000..82738058f672
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.yaml
@@ -0,0 +1,299 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nvidia,tegra30-ahub.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra Audio Hub (AHUB)
+
+maintainers:
+ - Jonathan Hunter <jonathanh@nvidia.com>
+
+description:
+ The NVIDIA Tegra AHUB (Audio Hub) is an audio interconnect block used to
+ route data between various audio clients such as I2S, DAM, SPDIF, and
+ APBIF. It exposes multiple register regions and supports different
+ configurations depending on the Tegra SoC generation. The AHUB also
+ provides a configlink bus for child audio components, which use CIF
+ (Client Interface) IDs to identify their data paths. The number of DMA
+ channels, reset lines, and additional modules varies across Tegra30,
+ Tegra114, and Tegra124 platforms.
+
+properties:
+ compatible:
+ oneOf:
+ - const: nvidia,tegra30-ahub
+ - const: nvidia,tegra114-ahub
+ - const: nvidia,tegra124-ahub
+ - items:
+ - const: nvidia,tegra132-ahub
+ - const: nvidia,tegra124-ahub
+
+ reg:
+ minItems: 2
+ maxItems: 3
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Clock for the D_AUDIO domain
+ - description: Clock for the APBIF interface
+
+ clock-names:
+ items:
+ - const: d_audio
+ - const: apbif
+
+ resets:
+ minItems: 11
+ maxItems: 21
+
+ reset-names:
+ oneOf:
+ # Tegra30: d_audio apbif i2s0-4 dam0-2 spdif
+ - items:
+ - const: d_audio
+ - const: apbif
+ - const: i2s0
+ - const: i2s1
+ - const: i2s2
+ - const: i2s3
+ - const: i2s4
+ - const: dam0
+ - const: dam1
+ - const: dam2
+ - const: spdif
+
+ # Tegra114: adds amx adx
+ - items:
+ - const: d_audio
+ - const: apbif
+ - const: i2s0
+ - const: i2s1
+ - const: i2s2
+ - const: i2s3
+ - const: i2s4
+ - const: dam0
+ - const: dam1
+ - const: dam2
+ - const: spdif
+ - const: amx
+ - const: adx
+
+ # Tegra124: adds amx1 adx1 afc0-5
+ - items:
+ - const: d_audio
+ - const: apbif
+ - const: i2s0
+ - const: i2s1
+ - const: i2s2
+ - const: i2s3
+ - const: i2s4
+ - const: dam0
+ - const: dam1
+ - const: dam2
+ - const: spdif
+ - const: amx
+ - const: amx1
+ - const: adx
+ - const: adx1
+ - const: afc0
+ - const: afc1
+ - const: afc2
+ - const: afc3
+ - const: afc4
+ - const: afc5
+
+ dmas:
+ minItems: 8
+ maxItems: 20
+
+ dma-names:
+ oneOf:
+ # Tegra30: rx0..rx3 tx0..tx3 (n=3)
+ - items:
+ - const: rx0
+ - const: tx0
+ - const: rx1
+ - const: tx1
+ - const: rx2
+ - const: tx2
+ - const: rx3
+ - const: tx3
+
+ # Tegra114/124: rx0..rx9 tx0..tx9 (n=9)
+ - items:
+ - const: rx0
+ - const: tx0
+ - const: rx1
+ - const: tx1
+ - const: rx2
+ - const: tx2
+ - const: rx3
+ - const: tx3
+ - const: rx4
+ - const: tx4
+ - const: rx5
+ - const: tx5
+ - const: rx6
+ - const: tx6
+ - const: rx7
+ - const: tx7
+ - const: rx8
+ - const: tx8
+ - const: rx9
+ - const: tx9
+
+ "#address-cells":
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ "#size-cells":
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ ranges: true
+
+patternProperties:
+ "^i2s@[0-9a-f]+$":
+ type: object
+
+ allOf:
+ - $ref: /schemas/sound/nvidia,tegra30-i2s.yaml#
+
+ properties:
+ nvidia,ahub-cif-ids:
+ description: Pair of AHUB CIF IDs for the RX and TX data paths.
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 2
+ maxItems: 2
+
+ required:
+ - nvidia,ahub-cif-ids
+
+ unevaluatedProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra124-ahub
+ then:
+ properties:
+ "#address-cells":
+ const: 2
+
+ "#size-cells":
+ const: 2
+
+ resets:
+ minItems: 21
+ maxItems: 21
+
+ dmas:
+ minItems: 20
+ maxItems: 20
+
+ else:
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra30-ahub
+ then:
+ properties:
+ reg:
+ maxItems: 2
+
+ resets:
+ minItems: 11
+ maxItems: 11
+
+ dmas:
+ minItems: 8
+ maxItems: 8
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra114-ahub
+ then:
+ properties:
+ reg:
+ minItems: 3
+ maxItems: 3
+
+ resets:
+ minItems: 13
+ maxItems: 13
+
+ dmas:
+ minItems: 20
+ maxItems: 20
+
+required:
+ - reg
+ - compatible
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - dmas
+ - dma-names
+ - "#address-cells"
+ - "#size-cells"
+ - ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/tegra30-car.h>
+ ahub@70080000 {
+ compatible = "nvidia,tegra30-ahub";
+ reg = <0x70080000 0x200>, <0x70080200 0x100>;
+ interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&tegra_car TEGRA30_CLK_D_AUDIO>,
+ <&tegra_car TEGRA30_CLK_APBIF>;
+ clock-names = "d_audio", "apbif";
+ resets = <&tegra_car 106>, <&tegra_car 107>,
+ <&tegra_car 30>, <&tegra_car 11>,
+ <&tegra_car 18>, <&tegra_car 101>,
+ <&tegra_car 102>, <&tegra_car 108>,
+ <&tegra_car 109>, <&tegra_car 110>,
+ <&tegra_car 10>;
+ reset-names = "d_audio", "apbif",
+ "i2s0", "i2s1", "i2s2", "i2s3", "i2s4",
+ "dam0", "dam1", "dam2",
+ "spdif";
+ dmas = <&apbdma 1>, <&apbdma 1>,
+ <&apbdma 2>, <&apbdma 2>,
+ <&apbdma 3>, <&apbdma 3>,
+ <&apbdma 4>, <&apbdma 4>;
+ dma-names = "rx0", "tx0", "rx1", "tx1",
+ "rx2", "tx2", "rx3", "tx3";
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ i2s@70080300 {
+ compatible = "nvidia,tegra30-i2s";
+ reg = <0x70080300 0x100>;
+ nvidia,ahub-cif-ids = <4 4>;
+ clocks = <&tegra_car TEGRA30_CLK_I2S0>;
+ resets = <&tegra_car 30>;
+ reset-names = "i2s";
+ };
+ };
+...
---
base-commit: db7efce4ae23ad5e42f5f55428f529ff62b86fab
change-id: 20260422-nvidia-ahub-d2ceb0372744
Best regards,
--
Charan Pedumuru <charan.pedumuru@gmail.com>
^ permalink raw reply related
* Re: [PATCH v4 6/7] arm64: dts: allwinner: a100: reserve RAM for ATF
From: Jernej Škrabec @ 2026-06-13 8:22 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Alexander Sverdlin, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Samuel Holland, Hans de Goede,
Dmitry Torokhov, Andre Przywara, Jun Yan, Lukas Schmid,
J. Neuschäfer, Eric Biggers, Michal Simek, Luca Weiss,
Sven Peter, Maxime Ripard, devicetree, linux-kernel, linux-input
In-Reply-To: <20260605070923.3045073-7-alexander.sverdlin@gmail.com>
Dne petek, 5. junij 2026 ob 09:09:20 Srednjeevropski poletni čas je Alexander Sverdlin napisal(a):
> Add reserved-memory node carving out Trusted Firmware-A region spanning
> fixed 256K from physical address 0x40000000. Even though Allwinner ATF
> itself passes the address range in the fdt to U-Boot, U-Boot currently
> only reserves this memory internally, but doesn't carve out the region
> in the fdt passed to Linux.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
NAK. It is job of boot procedure to properly inject TF-A reserved node.
Any issue should be fixed there.
Best regards,
Jernej Skrabec
> ---
> Changelog:
> v4:
> - new patch
>
> arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> index 7cb06b19b5a5..d8391663fd1d 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
> @@ -87,6 +87,22 @@ osc32k: osc32k-clk {
> #clock-cells = <0>;
> };
>
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /*
> + * 256 KiB reserved for Trusted Firmware-A (BL31).
> + * This is added by BL31 itself, but some bootloaders fail
> + * to propagate this into the DTB handed to kernels.
> + */
> + secmon@40000000 {
> + reg = <0x0 0x40000000 0x0 0x40000>;
> + no-map;
> + };
> + };
> +
> timer {
> compatible = "arm,armv8-timer";
> interrupts = <GIC_PPI 13
>
^ 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