* Re: [PATCH v5 3/3] MAINTAINERS: add entry for MAX86150 IIO health driver
From: Krzysztof Kozlowski @ 2026-06-24 6:22 UTC (permalink / raw)
To: Md Shofiqul Islam, linux-iio
Cc: jic23, lars, conor, conor+dt, robh, krzk+dt, devicetree,
linux-kernel
In-Reply-To: <20260623201124.18271-4-shofiqtest@gmail.com>
On 23/06/2026 22:11, Md Shofiqul Islam wrote:
> Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>
> ---
> MAINTAINERS | 7 +++++++
> 1 file changed, 7 insertions(+)
>
You need to slow down, please. One version per 24h.
And the last one is not even correct anymore...
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v4 2/2] arm64: dts: socfpga: agilex5: Add dma-coherent to XGMAC nodes
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-24 6:22 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
In-Reply-To: <20260624062203.12221-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
The SMMU is enabled and transactions going through it are cache
coherent. Add the dma-coherent property to the XGMAC nodes to prevent
redundant cache flush/invalidate operations and potential stale data
issues.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
Changes in v3:
- Fix commit header to follow subsystem naming convention (add agilex5: prefix)
Changes in v2:
- Move dma-coherent property into the base DTSI file instead of individual DTS files
---
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
index daa1f9e0d1f5..3822f06c2694 100644
--- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
@@ -576,6 +576,7 @@ gmac0: ethernet@10810000 {
altr,sysmgr-syscon = <&sysmgr 0x44 0>;
snps,clk-csr = <0>;
iommus = <&smmu 1>;
+ dma-coherent;
status = "disabled";
stmmac_axi_emac0_setup: stmmac-axi-config {
@@ -689,6 +690,7 @@ gmac1: ethernet@10820000 {
altr,sysmgr-syscon = <&sysmgr 0x48 0>;
snps,clk-csr = <0>;
iommus = <&smmu 2>;
+ dma-coherent;
status = "disabled";
stmmac_axi_emac1_setup: stmmac-axi-config {
@@ -802,6 +804,7 @@ gmac2: ethernet@10830000 {
altr,sysmgr-syscon = <&sysmgr 0x4c 0>;
snps,clk-csr = <0>;
iommus = <&smmu 3>;
+ dma-coherent;
status = "disabled";
stmmac_axi_emac2_setup: stmmac-axi-config {
--
2.43.7
^ permalink raw reply related
* [PATCH v4 1/2] arm64: dts: socfpga: agilex5: Enable the SMMU
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-24 6:22 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
In-Reply-To: <20260624062203.12221-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
The SMMU is disabled in socfpga_agilex5.dtsi. The SoC uses a different
memory-mapped base address for its peripherals, which requires the SMMU
to be active so that the Secure Device Manager (SDM) can correctly
access those regions through address translation.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
Changes in v4:
- Remove status = "disabled" instead of setting status = "okay", as nodes
without a status property are enabled by default
Changes in v3:
- Fix commit header to follow subsystem naming convention
- Remove commit body line that restated the subject
- Clarify which file had the SMMU disabled
Changes in v2:
- Move SMMU enable into the base DTSI file instead of individual DTS files
---
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
index b06c6d5d60ee..daa1f9e0d1f5 100644
--- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
@@ -385,7 +385,6 @@ smmu: iommu@16000000 {
interrupt-names = "eventq", "gerror", "priq";
dma-coherent;
#iommu-cells = <1>;
- status = "disabled";
};
spi0: spi@10da4000 {
--
2.43.7
^ permalink raw reply related
* [PATCH v4 0/2] arm64: dts: socfpga: Enable SMMU and add DMA coherency for XGMAC
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-24 6:22 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
This series enables the SMMU and adds DMA coherency support for the
XGMAC nodes across the affected board device trees.
Patch 1 enables the SMMU for the SoCFPGA board device trees where it
was missing. The SoC uses a different memory-mapped base address for
its peripherals, which requires the SMMU to be active so that the
Secure Device Manager (SDM) can correctly access those regions through
address translation.
Patch 2 adds the dma-coherent property to the XGMAC nodes. The SMMU
is enabled and transactions going through it are cache coherent.
Adding dma-coherent prevents redundant cache flush/invalidate
operations and potential stale data issues.
Changes in v4:
- Remove status = "disabled" instead of setting status = "okay", as nodes
without a status property are enabled by default
Changes in v3:
- Fix commit header to follow subsystem naming convention (patches 1 and 2)
- Remove commit body line that restated the subject
- Clarify which file had the SMMU disabled
Changes in v2:
- Move SMMU enable into the base DTSI file instead of individual DTS files
- Move dma-coherent property into the base DTSI file instead of individual DTS files
- Improve commit messages and cover letter descriptions with more context on why the changes are needed
Nazim Amirul (2):
arm64: dts: socfpga: agilex5: Enable the SMMU
arm64: dts: socfpga: agilex5: Add dma-coherent to XGMAC nodes
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--
2.43.7
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: socfpga: agilex72: Add initial device tree
From: sashiko-bot @ 2026-06-24 6:15 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260624055644.7508-3-muhammad.nazim.amirul.nazle.asmade@altera.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Missing VGIC maintenance interrupt breaks KVM virtualization support.
- [Medium] Invalid properties in static `reserved-memory` nodes (ATF and service buffers).
- [Medium] Missing CPU capacity properties for heterogeneous ARMv9 scheduling.
--
commit aab0b211863fe0abf5dfd65b45d11637ecf3a3d5
Author: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
arm64: dts: socfpga: agilex72: Add initial device tree
This commit introduces the initial device tree support for the Intel
SoCFPGA Agilex72 platform, including the SoC DTSI and the SoCDK board
DTS.
> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
> new file mode 100644
> index 0000000000000..2a4ad4130f37e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
> @@ -0,0 +1,128 @@
[ ... ]
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + atf_reserved: atf@80000000 {
> + compatible = "shared-dma-pool";
> + reg = <0x0 0x80000000 0x0 0x100000>;
> + alignment = <0x1000>;
> + no-map;
> + };
> +
> + service_reserved: svcbuffer@80100000 {
> + compatible = "shared-dma-pool";
> + reg = <0x0 0x80100000 0x0 0xf00000>;
> + alignment = <0x1000>;
> + no-map;
> + };
> + };
[Severity: Medium]
Is it intentional to expose the Arm Trusted Firmware secure memory region
as a shared DMA pool? The compatible = "shared-dma-pool" property here could
expose secure EL3 memory as a Linux DMA pool, which could trigger a fatal
secure monitor abort if a driver attempts to attach and access it.
Also, both the atf_reserved and service_reserved nodes define a static
physical address using the reg property, but they also include the alignment
property. Does this violate the devicetree schema? The reserved-memory.yaml
schema dictates that alignment is strictly for dynamically placed allocations
and is mutually exclusive with reg.
[ ... ]
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a520";
> + device_type = "cpu";
> + enable-method = "psci";
> + reg = <0x0>;
> + };
[ ... ]
> + cpu2: cpu@200 {
> + compatible = "arm,cortex-a720";
> + device_type = "cpu";
> + enable-method = "psci";
> + reg = <0x200>;
> + };
[Severity: Medium]
Since the Agilex72 features a heterogeneous cluster with Cortex-A520
and Cortex-A720 cores, does this cpus node need capacity-dmips-mhz
properties?
Without these properties or an active OPP table, the Energy Aware Scheduling
(EAS) subsystem cannot discover the relative compute capacities, and might
assume all cores are identical. This could cause heavy workloads to be
scheduled suboptimally on the slower A520 cores.
[ ... ]
> + intc: interrupt-controller@7000000 {
> + compatible = "arm,gic-v3";
> + reg = <0x0 0x7000000 0x0 0x10000>,
> + <0x0 0x7080000 0x0 0x100000>;
> + ranges;
> + #interrupt-cells = <3>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + interrupt-controller;
[Severity: High]
Is the VGIC maintenance interrupt missing from this node?
KVM relies on this interrupt (typically GIC_PPI 9) to populate gic_v3_kvm_info
during the GICv3 driver initialization in drivers/irqchip/irq-gic-v3.c.
Without it, the driver skips VGIC setup, which leaves hardware virtualization
support broken on this platform.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624055644.7508-1-muhammad.nazim.amirul.nazle.asmade@altera.com?part=2
^ permalink raw reply
* [PATCH] spi: dt-bindings: microchip,pic32mzda-sqi: Convert to DT schema
From: Udaya Kiran Challa @ 2026-06-24 6:13 UTC (permalink / raw)
To: tsbogend, robh, krzk+dt, conor+dt
Cc: skhan, me, linux-rtc, devicetree, linux-kernel,
Udaya Kiran Challa
Convert Microchip PIC32 Quad SPI controller devicetree binding
from legacy text format to DT schema.
Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
---
.../bindings/spi/microchip,pic32mzda-sqi.yaml | 53 +++++++++++++++++++
.../devicetree/bindings/spi/sqi-pic32.txt | 18 -------
2 files changed, 53 insertions(+), 18 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/microchip,pic32mzda-sqi.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/sqi-pic32.txt
diff --git a/Documentation/devicetree/bindings/spi/microchip,pic32mzda-sqi.yaml b/Documentation/devicetree/bindings/spi/microchip,pic32mzda-sqi.yaml
new file mode 100644
index 000000000000..39f06b61e894
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/microchip,pic32mzda-sqi.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/microchip,pic32mzda-sqi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC32MZDA Quad SPI controller
+
+maintainers:
+ - Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ const: microchip,pic32mzda-sqi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: spi_ck
+ - const: reg_ck
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/microchip,pic32-clock.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ sqi1: spi@1f8e2000 {
+ compatible = "microchip,pic32mzda-sqi";
+ reg = <0x1f8e2000 0x200>;
+ interrupts = <169 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&rootclk REF2CLK>, <&rootclk PB5CLK>;
+ clock-names = "spi_ck", "reg_ck";
+ };
diff --git a/Documentation/devicetree/bindings/spi/sqi-pic32.txt b/Documentation/devicetree/bindings/spi/sqi-pic32.txt
deleted file mode 100644
index c82d021bce50..000000000000
--- a/Documentation/devicetree/bindings/spi/sqi-pic32.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Microchip PIC32 Quad SPI controller
------------------------------------
-Required properties:
-- compatible: Should be "microchip,pic32mzda-sqi".
-- reg: Address and length of SQI controller register space.
-- interrupts: Should contain SQI interrupt.
-- clocks: Should contain phandle of two clocks in sequence, one that drives
- clock on SPI bus and other that drives SQI controller.
-- clock-names: Should be "spi_ck" and "reg_ck" in order.
-
-Example:
- sqi1: spi@1f8e2000 {
- compatible = "microchip,pic32mzda-sqi";
- reg = <0x1f8e2000 0x200>;
- clocks = <&rootclk REF2CLK>, <&rootclk PB5CLK>;
- clock-names = "spi_ck", "reg_ck";
- interrupts = <169 IRQ_TYPE_LEVEL_HIGH>;
- };
--
2.34.1
^ permalink raw reply related
* RE: [PATCH v9 2/2] i3c: master: Add driver for AMD AXI I3C master controller
From: Guntupalli, Manikanta @ 2026-06-24 6:06 UTC (permalink / raw)
To: Patil, Shubham Sanjay, git (AMD-Xilinx), Simek, Michal,
alexandre.belloni@bootlin.com, Frank.Li@nxp.com, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, pgaj@cadence.com,
wsa+renesas@sang-engineering.com,
tommaso.merciai.xr@bp.renesas.com, arnd@arndb.de,
quic_msavaliy@quicinc.com, S-k, Shyam-sundar,
sakari.ailus@linux.intel.com, billy_tsai@aspeedtech.com,
kees@kernel.org, gustavoars@kernel.org,
jarkko.nikula@linux.intel.com, jorge.marques@analog.com,
linux-i3c@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-hardening@vger.kernel.org
Cc: Pandey, Radhey Shyam, Goud, Srinivas, Datta, Shubhrajyoti,
Patil, Shubham Sanjay
In-Reply-To: <20260623114417.2578189-3-shubhamsanjay.patil@amd.com>
AMD General
Hi,
> -----Original Message-----
> From: Shubham Patil <shubhamsanjay.patil@amd.com>
> Sent: Tuesday, June 23, 2026 5:14 PM
> To: git (AMD-Xilinx) <git@amd.com>; Simek, Michal <michal.simek@amd.com>;
> alexandre.belloni@bootlin.com; Frank.Li@nxp.com; robh@kernel.org;
> krzk+dt@kernel.org; conor+dt@kernel.org; pgaj@cadence.com;
> wsa+renesas@sang-engineering.com; tommaso.merciai.xr@bp.renesas.com;
> arnd@arndb.de; quic_msavaliy@quicinc.com; S-k, Shyam-sundar <Shyam-
> sundar.S-k@amd.com>; sakari.ailus@linux.intel.com; billy_tsai@aspeedtech.com;
> kees@kernel.org; gustavoars@kernel.org; jarkko.nikula@linux.intel.com;
> jorge.marques@analog.com; linux-i3c@lists.infradead.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> arch@vger.kernel.org; linux-hardening@vger.kernel.org
> Cc: Pandey, Radhey Shyam <radhey.shyam.pandey@amd.com>; Goud, Srinivas
> <srinivas.goud@amd.com>; Datta, Shubhrajyoti <shubhrajyoti.datta@amd.com>;
> Patil, Shubham Sanjay <ShubhamSanjay.Patil@amd.com>; Guntupalli, Manikanta
> <manikanta.guntupalli@amd.com>
> Subject: [PATCH v9 2/2] i3c: master: Add driver for AMD AXI I3C master controller
>
> From: Manikanta Guntupalli <manikanta.guntupalli@amd.com>
>
> Add an I3C master driver and maintainers fragment for the AMD I3C bus controller.
>
> The driver currently supports the I3C bus operating in SDR mode, with features
> including Dynamic Address Assignment, private data transfers, and CCC transfers in
> both broadcast and direct modes. It also supports operation in I2C mode.
>
> The controller's data FIFOs are accessed big-endian; the driver performs this
> conversion locally using ioread32be()/iowrite32be() with the helpers, so it does not
> depend on any core FIFO-endianness helpers.
>
> Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli@amd.com>
> Co-developed-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
> Co-developed-by: Shubham Patil <shubhamsanjay.patil@amd.com>
> Signed-off-by: Shubham Patil <shubhamsanjay.patil@amd.com>
> ---
> Changes for V9:
> Updated commit description to note that the driver performs big-endian FIFO
> accesses locally (the v8 core-helper patches were dropped).
> Dropped the big-endian MMIO infrastructure patches from the series
> ("asm-generic/io.h: Add big-endian MMIO accessors", "i3c: fix big-endian FIFO
> transfers", and "i3c: master: Add endianness support for
> i3c_readl_fifo()/i3c_writel_fifo()"). The driver now performs big-endian FIFO
> accesses locally using ioread32be()/iowrite32be() with
> get_unaligned()/put_unaligned(), so the series is self-contained and no longer
> includes internals.h.
> Replaced the async completion/transfer-queue machinery with a simple
> synchronous transfer path under the existing mutex.
> Reworked response handling: added enum i3c_error_code to struct xi3c_cmd,
> named the response codes, return -ENODEV/-EIO as appropriate and set err =
> I3C_ERROR_M2/M0 so the i3c core and callers can tell a NACK apart from a bus
> error; propagate err to CCC commands and to each priv xfer (including actual_len).
> Switched from .priv_xfers to the new .i3c_xfers op; reject non-SDR modes with -
> EOPNOTSUPP and report actual_len.
> Reworked DAA: assign addresses incrementally, bound the device count (-
> ENOSPC), detect end-of-enumeration via -ENODEV, zero-initialize the PID buffers,
> and check i3c_master_add_i3c_dev_locked().
> Avoid busy-spinning: sleep with usleep_range() in the FIFO drain/fill loops.
> Use FIELD_PREP() with named command-FIFO field masks instead of open-coded
> shifts, and convert the register-accessor macros to inline functions.
> Split the overloaded timeout macro into XI3C_RESP_TIMEOUT_US and
> XI3C_XFER_TIMEOUT_MS with documented units, and add
> XI3C_POLL_INTERVAL_US.
> xi3c_clk_cfg(): use NSEC_PER_SEC and named timing constants, guard against
> unsigned underflow, and handle I3C_BUS_MODE_MIXED_SLOW.
> Dropped ENTHDR from supports_ccc_cmd() (SDR-only), and dispatch CCCs using
> the I3C_CCC_DIRECT bit.
> Use const for TX buffers and drop the related casts; use parity8() for the DAA parity
> bit.
> Updated MODULE_DESCRIPTION and authors, the copyright year, renamed the
> Kconfig symbol to AMD_AXI_I3C_MASTER, and fixed the MAINTAINERS entry
> (title, mailing list, and the correct binding filename).
>
> Changes for V8:
> Used time_left instead of timeout.
> Used __free(kfree) for xfer to simplify err path in multiple places.
>
> Changes for V7:
> Updated timeout macro name.
> Updated xi3c_master_wr_to_tx_fifo() and xi3c_master_rd_from_rx_fifo() to use
> i3c_writel_fifo() and i3c_readl_fifo().
>
> Changes for V6:
> Removed typecast for xi3c_getrevisionnumber(), xi3c_wrfifolevel(), and
> xi3c_rdfifolevel().
> Replaced dynamic allocation with a static variable for pid_bcr_dcr.
> Fixed sparse warning in do_daa by typecasting the address parity value to u8.
> Fixed sparse warning in xi3c_master_bus_init by typecasting the pid value to u64 in
> info.pid calculation.
>
> Changes for V5:
> Used GENMASK_ULL for PID mask as it's 64bit mask.
>
> Changes for V4:
> Updated timeout macros.
> Removed type casting for xi3c_is_resp_available() macro.
> Used ioread32() and iowrite32() instead of readl() and writel() to keep consistency.
> Read XI3C_RESET_OFFSET reg before udelay().
> Removed xi3c_master_free_xfer() and directly used kfree().
> Skipped checking return value of i3c_master_add_i3c_dev_locked().
> Used devm_mutex_init() instead of mutex_init().
>
> Changes for V3:
> Resolved merge conflicts.
>
> Changes for V2:
> Updated commit description.
> Added mixed mode support with clock configuration.
> Converted smaller functions into inline functions.
> Used FIELD_GET() in xi3c_get_response().
> Updated xi3c_master_rd_from_rx_fifo() to use cmd->rx_buf.
> Used parity8() for address parity calculation.
> Added guards for locks.
> Dropped num_targets and updated xi3c_master_do_daa().
> Used __free(kfree) in xi3c_master_send_bdcast_ccc_cmd().
> Dropped PM runtime support.
> Updated xi3c_master_read() and xi3c_master_write() with
> xi3c_is_resp_available() check.
> Created separate functions: xi3c_master_init() and xi3c_master_reinit().
> Used xi3c_master_init() in bus initialization and xi3c_master_reinit() in error paths.
> Added DAA structure to xi3c_master structure.
> ---
> MAINTAINERS | 8 +
> drivers/i3c/master/Kconfig | 15 +
> drivers/i3c/master/Makefile | 1 +
> drivers/i3c/master/amd-i3c-master.c | 1060 +++++++++++++++++++++++++++
> 4 files changed, 1084 insertions(+)
> create mode 100644 drivers/i3c/master/amd-i3c-master.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 461a3eed6129..bfaa6999913c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1035,6 +1035,14 @@ L: linux-sound@vger.kernel.org
> S: Supported
> F: sound/soc/amd/
>
> +AMD AXI I3C MASTER DRIVER
> +M: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
> +M: Shubham Patil <shubhamsanjay.patil@amd.com>
> +L: linux-i3c@lists.infradead.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/i3c/xlnx,axi-i3c-1.0.yaml
> +F: drivers/i3c/master/amd-i3c-master.c
> +
> AMD AXI W1 DRIVER
> M: Kris Chaplin <kris.chaplin@amd.com>
> R: Thomas Delev <thomas.delev@amd.com>
> diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig index
> 2609f2b18e0a..da96d2aaa399 100644
> --- a/drivers/i3c/master/Kconfig
> +++ b/drivers/i3c/master/Kconfig
> @@ -86,3 +86,18 @@ config RENESAS_I3C
>
> This driver can also be built as a module. If so, the module will be
> called renesas-i3c.
> +
> +config AMD_AXI_I3C_MASTER
> + tristate "AMD AXI I3C Master driver"
> + depends on HAS_IOMEM
> + help
> + Support for the AMD AXI I3C master controller, a soft IP used on
> + AMD (Xilinx) FPGAs and adaptive SoCs with ARM or MicroBlaze
> + processors.
> +
> + The controller currently supports Standard Data Rate (SDR) mode.
> + Features include Dynamic Address Assignment, private transfers,
> + and CCC transfers in both broadcast and direct modes.
> +
> + This driver can also be built as a module. If so, the module
> + will be called amd-i3c-master.
> diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile index
> 816a227b6f7a..8d82196dcf83 100644
> --- a/drivers/i3c/master/Makefile
> +++ b/drivers/i3c/master/Makefile
> @@ -6,3 +6,4 @@ obj-$(CONFIG_AST2600_I3C_MASTER) += ast2600-i3c-
> master.o
> obj-$(CONFIG_SVC_I3C_MASTER) += svc-i3c-master.o
> obj-$(CONFIG_MIPI_I3C_HCI) += mipi-i3c-hci/
> obj-$(CONFIG_RENESAS_I3C) += renesas-i3c.o
> +obj-$(CONFIG_AMD_AXI_I3C_MASTER) += amd-i3c-master.o
> diff --git a/drivers/i3c/master/amd-i3c-master.c b/drivers/i3c/master/amd-i3c-master.c
> new file mode 100644
> index 000000000000..34ab1028c3ce
> --- /dev/null
> +++ b/drivers/i3c/master/amd-i3c-master.c
> @@ -0,0 +1,1060 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * I3C master driver for the AMD I3C controller.
> + *
> + * Copyright (C) 2026, Advanced Micro Devices, Inc.
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/bitops.h>
> +#include <linux/cleanup.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/i3c/master.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/time.h>
> +#include <linux/unaligned.h>
> +
> +#define XI3C_VERSION_OFFSET 0x00 /* Version Register */
> +#define XI3C_RESET_OFFSET 0x04 /* Soft Reset Register */
> +#define XI3C_CR_OFFSET 0x08 /* Control Register */
> +#define XI3C_ADDRESS_OFFSET 0x0C /* Target Address
> Register */
> +#define XI3C_SR_OFFSET 0x10 /* Status Register */
> +#define XI3C_CMD_FIFO_OFFSET 0x20 /* I3C Command
> FIFO Register */
> +#define XI3C_WR_FIFO_OFFSET 0x24 /* I3C Write Data FIFO
> Register */
> +#define XI3C_RD_FIFO_OFFSET 0x28 /* I3C Read Data FIFO
> Register */
> +#define XI3C_RESP_STATUS_FIFO_OFFSET 0x2C /* I3C Response
> status FIFO Register */
> +#define XI3C_FIFO_LVL_STATUS_OFFSET 0x30 /* CMD slots free
> | WR-FIFO free (words) */
> +#define XI3C_FIFO_LVL_STATUS_1_OFFSET 0x34 /* RESP fill | RD-
> FIFO fill level (words) */
> +#define XI3C_SCL_HIGH_TIME_OFFSET 0x38 /* I3C SCL HIGH
> Register */
> +#define XI3C_SCL_LOW_TIME_OFFSET 0x3C /* I3C SCL LOW
> Register */
> +#define XI3C_SDA_HOLD_TIME_OFFSET 0x40 /* I3C SDA
> HOLD Register */
> +#define XI3C_TSU_START_OFFSET 0x48 /* I3C START
> SETUP Register */
> +#define XI3C_THD_START_OFFSET 0x4C /* I3C START
> HOLD Register */
> +#define XI3C_TSU_STOP_OFFSET 0x50 /* I3C STOP
> Setup Register */
> +#define XI3C_OD_SCL_HIGH_TIME_OFFSET 0x54 /* I3C OD SCL
> HIGH Register */
> +#define XI3C_OD_SCL_LOW_TIME_OFFSET 0x58 /* I3C OD SCL
> LOW Register */
> +#define XI3C_PID0_OFFSET 0x6C /* LSB 4 bytes of the
> PID */
> +#define XI3C_PID1_BCR_DCR 0x70 /* MSB 2 bytes of the
> PID, BCR and DCR */
> +
> +#define XI3C_CR_EN_MASK BIT(0) /* Core Enable */
> +#define XI3C_CR_RESUME_MASK BIT(2) /* Core Resume
> */
> +#define XI3C_SR_RESP_NOT_EMPTY_MASK BIT(4) /* Resp Fifo not
> empty status mask */
> +#define XI3C_RD_FIFO_NOT_EMPTY_MASK BIT(15) /* Read
> Fifo not empty status mask */
> +
> +#define XI3C_BCR_MASK GENMASK(23, 16)
> +#define XI3C_DCR_MASK GENMASK(31, 24)
> +#define XI3C_PID_MASK GENMASK_ULL(63, 16)
> +#define XI3C_TIMING_MASK GENMASK(17, 0)
> +#define XI3C_REV_NUM_MASK GENMASK(15, 8)
> +#define XI3C_PID1_MASK GENMASK(15, 0)
> +#define XI3C_FIFO_LEVEL_MASK GENMASK(15, 0)
> +#define XI3C_RESP_CODE_MASK GENMASK(8, 5)
> +#define XI3C_RESP_CODE_SUCCESS 0 /* Transfer
> completed OK */
> +#define XI3C_RESP_CODE_NO_TARGET 2 /* 7E NACK: no
> target on bus */
> +#define XI3C_RESP_CODE_NACK 3 /* Target NACK /
> CE2 / DAA end */
> +#define XI3C_ADDR_MASK GENMASK(6, 0)
> +#define XI3C_FIFOS_RST_MASK GENMASK(4, 1)
> +
> +/* Command FIFO word layout (bit ranges encoded in the GENMASK/BIT args) */
> +#define XI3C_CMD_TYPE GENMASK(3, 0) /*
> command type */
> +#define XI3C_CMD_TERMINATE BIT(4) /* terminate (last
> cmd of xfer) */
> +#define XI3C_CMD_ADDR GENMASK(15, 8) /* target
> address << 1 | RnW */
> +#define XI3C_CMD_LEN GENMASK(27, 16) /*
> payload length in bytes */
> +#define XI3C_CMD_TID GENMASK(31, 28) /* transfer
> ID */
> +
> +#define XI3C_OD_TLOW_NS 500000
> +#define XI3C_OD_THIGH_NS 41000
> +#define XI3C_I2C_TCASMIN_NS 600000
> +#define XI3C_TCASMIN_NS 260000
> +#define XI3C_MAXDATA_LENGTH 4095
> +#define XI3C_MAX_DEVS 32
> +#define XI3C_DAA_SLAVEINFO_READ_BYTECOUNT 8
> +
> +#define XI3C_THOLD_MIN_REV0 5 /* Min SDA hold cycles,
> rev 0 IP */
> +#define XI3C_THOLD_MIN_REV1 6 /* Min SDA hold cycles,
> rev >= 1 IP */
> +#define XI3C_CYCLE_ADJUST 2 /* SCL/SDA pre-bias for
> HW pipeline */
> +#define XI3C_FIFO_RESET_DELAY_US 10 /* HW settling time after
> FIFO reset */
> +#define XI3C_POLL_INTERVAL_US 10 /*
> readl_poll_timeout() sleep slice */
> +
> +#define XI3C_I2C_MODE 0
> +#define XI3C_I2C_TID 0
> +#define XI3C_SDR_MODE 1
> +#define XI3C_SDR_TID 1
> +
> +#define XI3C_WORD_LEN 4
> +
> +/*
> + * XI3C_RESP_TIMEOUT_US is in microseconds because it is passed as the
> + * timeout_us argument of readl_poll_timeout(). XI3C_XFER_TIMEOUT_MS is
> +in
> + * milliseconds because it feeds msecs_to_jiffies(). Keep the two units
> + * distinct in the names so callers cannot mix them up.
> + */
> +#define XI3C_RESP_TIMEOUT_US 500000
> +#define XI3C_XFER_TIMEOUT_MS 1000
> +
> +struct xi3c_cmd {
> + const void *tx_buf;
> + void *rx_buf;
> + u16 tx_len;
> + u16 rx_len;
> + u8 addr;
> + u8 type;
> + u8 tid;
> + bool rnw;
> + bool is_daa;
> + bool continued;
> + enum i3c_error_code err;
> +};
> +
> +struct xi3c_xfer {
> + unsigned int ncmds;
> + struct xi3c_cmd cmds[] __counted_by(ncmds); };
> +
> +/**
> + * struct xi3c_master - I3C master controller state.
> + * @base: I3C master controller embedded by the framework.
> + * @dev: Pointer to the backing device structure.
> + * @membase: Memory base of the HW registers.
> + * @pclk: Input clock driving the controller.
> + * @lock: Serializes transfers and CCC submission.
> + * @daa: ENTDAA enumeration state.
> + * @daa.addrs: Dynamic addresses assigned in enumeration order.
> + * @daa.index: Number of responders enumerated so far.
> + */
> +struct xi3c_master {
> + struct i3c_master_controller base;
> + struct device *dev;
> + void __iomem *membase;
> + struct clk *pclk;
> + struct mutex lock; /* serializes transfers and CCC submission */
> + struct {
> + u8 addrs[XI3C_MAX_DEVS];
> + u8 index;
> + } daa;
> +};
> +
> +static inline struct xi3c_master *
> +to_xi3c_master(struct i3c_master_controller *master) {
> + return container_of(master, struct xi3c_master, base); }
> +
> +static inline u8 xi3c_get_revision_number(struct xi3c_master *master) {
> + return FIELD_GET(XI3C_REV_NUM_MASK,
> + ioread32(master->membase + XI3C_VERSION_OFFSET)); }
> +
> +static inline u16 xi3c_wr_fifo_level(struct xi3c_master *master) {
> + return ioread32(master->membase + XI3C_FIFO_LVL_STATUS_OFFSET) &
> + XI3C_FIFO_LEVEL_MASK;
> +}
> +
> +static inline u16 xi3c_rd_fifo_level(struct xi3c_master *master) {
> + return ioread32(master->membase +
> XI3C_FIFO_LVL_STATUS_1_OFFSET) &
> + XI3C_FIFO_LEVEL_MASK;
> +}
> +
> +static inline bool xi3c_is_resp_available(struct xi3c_master *master) {
> + return FIELD_GET(XI3C_SR_RESP_NOT_EMPTY_MASK,
> + ioread32(master->membase + XI3C_SR_OFFSET)); }
> +
> +static int xi3c_get_response(struct xi3c_master *master, struct
> +xi3c_cmd *cmd) {
> + u32 response_data;
> + u32 resp_reg;
> + u8 code;
> + int ret;
> +
> + ret = readl_poll_timeout(master->membase + XI3C_SR_OFFSET,
> + resp_reg,
> + resp_reg & XI3C_SR_RESP_NOT_EMPTY_MASK,
> + XI3C_POLL_INTERVAL_US,
> XI3C_RESP_TIMEOUT_US);
> + if (ret) {
> + dev_err(master->dev, "XI3C response timeout\n");
> + return ret;
> + }
> +
> + response_data = ioread32(master->membase +
> XI3C_RESP_STATUS_FIFO_OFFSET);
> + code = FIELD_GET(XI3C_RESP_CODE_MASK, response_data);
> +
> + switch (code) {
> + case XI3C_RESP_CODE_SUCCESS:
> + cmd->err = I3C_ERROR_UNKNOWN;
> + return 0;
> + case XI3C_RESP_CODE_NO_TARGET:
> + case XI3C_RESP_CODE_NACK:
> + /*
> + * Target did not ACK. Record it as I3C_ERROR_M2 so callers
> + * (and the i3c core, which keys on err == I3C_ERROR_M2) can
> + * tell a NACK apart from other failures. A normal transfer
> + * surfaces this as -EIO per the i3c_xfer contract; the DAA
> + * path instead expects -ENODEV as its enumeration terminator.
> + */
> + cmd->err = I3C_ERROR_M2;
> + return cmd->is_daa ? -ENODEV : -EIO;
> + default:
> + cmd->err = I3C_ERROR_M0;
> + dev_err(master->dev, "XI3C transfer error, response code %u\n",
> + code);
> + return -EIO;
> + }
> +}
> +
> +static inline void xi3c_writesl_be(void __iomem *addr, const void *buffer,
> + unsigned int count)
> +{
> + const u32 *buf = buffer;
> +
> + while (count--)
> + iowrite32be(get_unaligned(buf++), addr); }
> +
> +static inline void xi3c_readsl_be(const void __iomem *addr, void *buffer,
> + unsigned int count)
> +{
> + u32 *buf = buffer;
> +
> + while (count--)
> + put_unaligned(ioread32be(addr), buf++); }
> +
> +static inline void xi3c_writel_fifo(void __iomem *addr, const void *buf,
> + int nbytes)
> +{
> + xi3c_writesl_be(addr, buf, nbytes / 4);
> + if (nbytes & 3) {
> + u32 tmp = 0;
> +
> + memcpy(&tmp, (const u8 *)buf + (nbytes & ~3), nbytes & 3);
> + xi3c_writesl_be(addr, &tmp, 1);
> + }
> +}
> +
> +static inline void xi3c_readl_fifo(const void __iomem *addr, void *buf,
> + int nbytes)
> +{
> + xi3c_readsl_be(addr, buf, nbytes / 4);
> + if (nbytes & 3) {
> + u32 tmp;
> +
> + xi3c_readsl_be(addr, &tmp, 1);
> + memcpy((u8 *)buf + (nbytes & ~3), &tmp, nbytes & 3);
> + }
> +}
> +
> +static void xi3c_master_write_to_cmdfifo(struct xi3c_master *master,
> + struct xi3c_cmd *cmd, u16 len)
> +{
> + u32 transfer_cmd;
> + u8 addr;
> +
> + addr = ((cmd->addr & XI3C_ADDR_MASK) << 1) | (u8)cmd->rnw;
> +
> + transfer_cmd = FIELD_PREP(XI3C_CMD_TYPE, cmd->type);
> + transfer_cmd |= FIELD_PREP(XI3C_CMD_TERMINATE, !cmd->continued);
> + transfer_cmd |= FIELD_PREP(XI3C_CMD_ADDR, addr);
> + transfer_cmd |= FIELD_PREP(XI3C_CMD_TID, cmd->tid);
> +
> + /*
> + * For dynamic addressing, an additional 1-byte length must be added
> + * to the command FIFO to account for the address present in the TX FIFO
> + */
> + if (cmd->is_daa) {
> + xi3c_writel_fifo(master->membase + XI3C_WR_FIFO_OFFSET,
> + cmd->tx_buf, cmd->tx_len);
> +
> + len++;
> + }
> +
> + transfer_cmd |= FIELD_PREP(XI3C_CMD_LEN, len);
> + iowrite32(transfer_cmd, master->membase + XI3C_CMD_FIFO_OFFSET); }
> +
> +static inline void xi3c_master_enable(struct xi3c_master *master) {
> + iowrite32(ioread32(master->membase + XI3C_CR_OFFSET) |
> XI3C_CR_EN_MASK,
> + master->membase + XI3C_CR_OFFSET);
> +}
> +
> +static inline void xi3c_master_disable(struct xi3c_master *master) {
> + iowrite32(ioread32(master->membase + XI3C_CR_OFFSET) &
> ~XI3C_CR_EN_MASK,
> + master->membase + XI3C_CR_OFFSET);
> +}
> +
> +static inline void xi3c_master_resume(struct xi3c_master *master) {
> + iowrite32(ioread32(master->membase + XI3C_CR_OFFSET) |
> + XI3C_CR_RESUME_MASK, master->membase +
> XI3C_CR_OFFSET); }
> +
> +static void xi3c_master_reset_fifos(struct xi3c_master *master) {
> + u32 data;
> +
> + /* Assert FIFO reset. */
> + data = ioread32(master->membase + XI3C_RESET_OFFSET);
> + data |= XI3C_FIFOS_RST_MASK;
> + iowrite32(data, master->membase + XI3C_RESET_OFFSET);
> + /* Read-back flushes the posted write before the settling delay below. */
> + ioread32(master->membase + XI3C_RESET_OFFSET);
> + udelay(XI3C_FIFO_RESET_DELAY_US);
> +
> + /* De-assert FIFO reset, then wait for the FIFOs to come back up. */
> + data &= ~XI3C_FIFOS_RST_MASK;
> + iowrite32(data, master->membase + XI3C_RESET_OFFSET);
> + ioread32(master->membase + XI3C_RESET_OFFSET);
> + udelay(XI3C_FIFO_RESET_DELAY_US);
> +}
> +
> +static inline void xi3c_master_init(struct xi3c_master *master) {
> + /* Reset fifos */
> + xi3c_master_reset_fifos(master);
> +
> + /* Enable controller */
> + xi3c_master_enable(master);
> +}
> +
> +static inline void xi3c_master_reinit(struct xi3c_master *master) {
> + /* Reset fifos */
> + xi3c_master_reset_fifos(master);
> +
> + /* Resume controller */
> + xi3c_master_resume(master);
> +}
> +
> +static struct xi3c_xfer *xi3c_master_alloc_xfer(unsigned int ncmds) {
> + struct xi3c_xfer *xfer;
> +
> + xfer = kzalloc(struct_size(xfer, cmds, ncmds), GFP_KERNEL);
> + if (!xfer)
> + return NULL;
> +
> + xfer->ncmds = ncmds;
> +
> + return xfer;
> +}
> +
> +static void xi3c_master_rd_from_rx_fifo(struct xi3c_master *master,
> + struct xi3c_cmd *cmd)
> +{
> + u16 rx_data_available;
> + u16 copy_len;
> + u16 len;
> +
> + rx_data_available = xi3c_rd_fifo_level(master);
> + len = rx_data_available * XI3C_WORD_LEN;
> +
> + if (!len)
> + return;
> +
> + copy_len = min_t(u16, len, cmd->rx_len);
> + xi3c_readl_fifo(master->membase + XI3C_RD_FIFO_OFFSET,
> + (u8 *)cmd->rx_buf, copy_len);
> +
> + cmd->rx_buf = (u8 *)cmd->rx_buf + copy_len;
> + cmd->rx_len -= copy_len;
> +}
> +
> +static int xi3c_master_read(struct xi3c_master *master, struct xi3c_cmd
> +*cmd) {
> + unsigned long timeout;
> + u32 status_reg;
> + int ret;
> +
> + if (!cmd->rx_buf || cmd->rx_len > XI3C_MAXDATA_LENGTH)
> + return -EINVAL;
> +
> + /* Fill command fifo */
> + xi3c_master_write_to_cmdfifo(master, cmd, cmd->rx_len);
> +
> + if (!cmd->rx_len)
> + return 0;
> +
> + ret = readl_poll_timeout(master->membase + XI3C_SR_OFFSET,
> + status_reg,
> + status_reg & (XI3C_RD_FIFO_NOT_EMPTY_MASK
> |
> + XI3C_SR_RESP_NOT_EMPTY_MASK),
> + XI3C_POLL_INTERVAL_US,
> XI3C_RESP_TIMEOUT_US);
> + if (ret) {
> + dev_err(master->dev, "XI3C read timeout\n");
> + return ret;
> + }
> +
> + if (!(status_reg & XI3C_RD_FIFO_NOT_EMPTY_MASK))
> + return 0;
> +
> + timeout = jiffies + msecs_to_jiffies(XI3C_XFER_TIMEOUT_MS);
> +
> + /* Read data from rx fifo */
> + while (cmd->rx_len > 0 && !xi3c_is_resp_available(master)) {
> + if (time_after(jiffies, timeout)) {
> + dev_err(master->dev, "XI3C read timeout\n");
> + return -EIO;
> + }
> + xi3c_master_rd_from_rx_fifo(master, cmd);
> + usleep_range(XI3C_POLL_INTERVAL_US, 2 *
> XI3C_POLL_INTERVAL_US);
> + }
> +
> + /* Read remaining data */
> + xi3c_master_rd_from_rx_fifo(master, cmd);
> +
> + return 0;
> +}
> +
> +static void xi3c_master_wr_to_tx_fifo(struct xi3c_master *master,
> + struct xi3c_cmd *cmd)
> +{
> + u16 wrfifo_space;
> + u16 len;
> +
> + wrfifo_space = xi3c_wr_fifo_level(master);
> + if (cmd->tx_len > wrfifo_space * XI3C_WORD_LEN)
> + len = wrfifo_space * XI3C_WORD_LEN;
> + else
> + len = cmd->tx_len;
> +
> + if (len) {
> + xi3c_writel_fifo(master->membase + XI3C_WR_FIFO_OFFSET,
> cmd->tx_buf,
> + len);
> +
> + cmd->tx_buf = (const u8 *)cmd->tx_buf + len;
> + cmd->tx_len -= len;
> + }
> +}
> +
> +static int xi3c_master_write(struct xi3c_master *master, struct
> +xi3c_cmd *cmd) {
> + unsigned long timeout;
> + u16 cmd_len;
> +
> + if (!cmd->tx_buf || cmd->tx_len > XI3C_MAXDATA_LENGTH)
> + return -EINVAL;
> +
> + cmd_len = cmd->tx_len;
> +
> + /* Fill Tx fifo */
> + xi3c_master_wr_to_tx_fifo(master, cmd);
> +
> + /* Write to command fifo */
> + xi3c_master_write_to_cmdfifo(master, cmd, cmd_len);
> +
> + timeout = jiffies + msecs_to_jiffies(XI3C_XFER_TIMEOUT_MS);
> + /* Fill if any remaining data to tx fifo */
> + while (cmd->tx_len > 0 && !xi3c_is_resp_available(master)) {
> + if (time_after(jiffies, timeout)) {
> + dev_err(master->dev, "XI3C write timeout\n");
> + return -EIO;
> + }
> +
> + xi3c_master_wr_to_tx_fifo(master, cmd);
> + usleep_range(XI3C_POLL_INTERVAL_US, 2 *
> XI3C_POLL_INTERVAL_US);
> + }
> +
> + return 0;
> +}
> +
> +static int xi3c_master_xfer(struct xi3c_master *master, struct xi3c_cmd
> +*cmd) {
> + int ret;
> +
> + if (cmd->rnw)
> + ret = xi3c_master_read(master, cmd);
> + else
> + ret = xi3c_master_write(master, cmd);
> +
> + if (ret)
> + goto err_xfer_out;
> +
> + ret = xi3c_get_response(master, cmd);
> + if (ret)
> + goto err_xfer_out;
> +
> + return 0;
> +
> +err_xfer_out:
> + xi3c_master_reinit(master);
> + return ret;
> +}
> +
> +static int xi3c_master_common_xfer(struct xi3c_master *master,
> + struct xi3c_xfer *xfer)
> +{
> + unsigned int i;
> + int ret;
> +
> + guard(mutex)(&master->lock);
> +
> + for (i = 0; i < xfer->ncmds; i++) {
> + ret = xi3c_master_xfer(master, &xfer->cmds[i]);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int xi3c_master_do_daa(struct i3c_master_controller *m) {
> + u8
> pid_bufs[XI3C_MAX_DEVS][XI3C_DAA_SLAVEINFO_READ_BYTECOUNT] = {};
> + struct xi3c_master *master = to_xi3c_master(m);
> + struct xi3c_xfer *xfer __free(kfree) = NULL;
> + struct xi3c_cmd *daa_cmd;
> + int addr, ret, i;
> + u8 last_addr = 0;
> + u8 *pid_buf;
> + u8 ccc_id;
> +
> + xfer = xi3c_master_alloc_xfer(1);
> + if (!xfer)
> + return -ENOMEM;
> +
> + /* Fill ENTDAA CCC */
> + ccc_id = I3C_CCC_ENTDAA;
> + daa_cmd = &xfer->cmds[0];
> + daa_cmd->addr = I3C_BROADCAST_ADDR;
> + daa_cmd->rnw = false;
> + daa_cmd->tx_buf = &ccc_id;
> + daa_cmd->tx_len = 1;
> + daa_cmd->type = XI3C_SDR_MODE;
> + daa_cmd->tid = XI3C_SDR_TID;
> + daa_cmd->continued = true;
> +
> + ret = xi3c_master_common_xfer(master, xfer);
> + /*
> + * A NACK on the ENTDAA broadcast (I3C_ERROR_M2) means no slaves
> are
> + * present to enter DAA. Treat as a successful no-op after letting
> + * err_daa reinitialize the controller.
> + */
> + if (ret && daa_cmd->err == I3C_ERROR_M2) {
> + ret = 0;
> + goto err_daa;
> + }
> + if (ret)
> + goto err_daa;
> +
> + master->daa.index = 0;
> +
> + while (true) {
> + struct xi3c_cmd *cmd = &xfer->cmds[0];
> + u8 daa_byte;
> +
> + if (master->daa.index >= XI3C_MAX_DEVS) {
> + ret = -ENOSPC;
> + goto err_daa;
> + }
> +
> + addr = i3c_master_get_free_addr(m, last_addr + 1);
> + if (addr < 0) {
> + ret = addr;
> + goto err_daa;
> + }
> +
> + pid_buf = pid_bufs[master->daa.index];
> +
> + daa_byte = (addr << 1) | (parity8(addr) ^ 1);
> +
> + cmd->tx_buf = &daa_byte;
> + cmd->tx_len = 1;
> + cmd->addr = I3C_BROADCAST_ADDR;
> + cmd->rnw = true;
> + cmd->rx_buf = pid_buf;
> + cmd->rx_len = XI3C_DAA_SLAVEINFO_READ_BYTECOUNT;
> + cmd->is_daa = true;
> + cmd->type = XI3C_SDR_MODE;
> + cmd->tid = XI3C_SDR_TID;
> + cmd->continued = true;
> +
> + ret = xi3c_master_common_xfer(master, xfer);
> +
> + /*
> + * End of enumeration: the next responder NACK'd the
> + * dynamic-address grant, surfaced as -ENODEV.
> + * xi3c_master_xfer() has already reset the FIFOs and
> + * resumed the core for us; just exit the loop and
> + * register the responders collected so far.
> + */
> + if (ret == -ENODEV) {
> + ret = 0;
> + break;
> + }
> + if (ret)
> + goto err_daa;
> +
> + master->daa.addrs[master->daa.index] = addr;
> + last_addr = addr;
> + master->daa.index++;
> + }
> +
> + for (i = 0; i < master->daa.index; i++) {
> + u64 pid;
> +
> + ret = i3c_master_add_i3c_dev_locked(m, master->daa.addrs[i]);
> + if (ret)
> + goto err_daa;
> +
> + pid = FIELD_GET(XI3C_PID_MASK,
> + get_unaligned_be64(pid_bufs[i]));
> + dev_dbg(master->dev, "Client %d: PID: 0x%llx\n", i, pid);
> + }
> +
> + return 0;
> +
> +err_daa:
> + xi3c_master_reinit(master);
> + return ret;
> +}
> +
> +static bool
> +xi3c_master_supports_ccc_cmd(struct i3c_master_controller *master,
> + const struct i3c_ccc_cmd *cmd)
> +{
> + if (cmd->ndests > 1)
> + return false;
> +
> + switch (cmd->id) {
> + case I3C_CCC_ENEC(true):
> + case I3C_CCC_ENEC(false):
> + case I3C_CCC_DISEC(true):
> + case I3C_CCC_DISEC(false):
> + case I3C_CCC_ENTAS(0, true):
> + case I3C_CCC_ENTAS(0, false):
> + case I3C_CCC_RSTDAA(true):
> + case I3C_CCC_RSTDAA(false):
> + case I3C_CCC_ENTDAA:
> + case I3C_CCC_SETMWL(true):
> + case I3C_CCC_SETMWL(false):
> + case I3C_CCC_SETMRL(true):
> + case I3C_CCC_SETMRL(false):
> + case I3C_CCC_SETDASA:
> + case I3C_CCC_SETNEWDA:
> + case I3C_CCC_GETMWL:
> + case I3C_CCC_GETMRL:
> + case I3C_CCC_GETPID:
> + case I3C_CCC_GETBCR:
> + case I3C_CCC_GETDCR:
> + case I3C_CCC_GETSTATUS:
> + case I3C_CCC_GETMXDS:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static int xi3c_master_send_bdcast_ccc_cmd(struct xi3c_master *master,
> + struct i3c_ccc_cmd *ccc)
> +{
> + struct xi3c_xfer *xfer __free(kfree) = NULL;
> + u8 *buf __free(kfree) = NULL;
> + struct xi3c_cmd *cmd;
> + u16 xfer_len;
> + int ret;
> +
> + if (ccc->dests[0].payload.len >= XI3C_MAXDATA_LENGTH)
> + return -EINVAL;
> +
> + xfer_len = ccc->dests[0].payload.len + 1;
> +
> + xfer = xi3c_master_alloc_xfer(1);
> + if (!xfer)
> + return -ENOMEM;
> +
> + buf = kmalloc(xfer_len, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + buf[0] = ccc->id;
> + memcpy(&buf[1], ccc->dests[0].payload.data,
> +ccc->dests[0].payload.len);
> +
> + cmd = &xfer->cmds[0];
> + cmd->addr = ccc->dests[0].addr;
> + cmd->rnw = ccc->rnw;
> + cmd->tx_buf = buf;
> + cmd->tx_len = xfer_len;
> + cmd->type = XI3C_SDR_MODE;
> + cmd->tid = XI3C_SDR_TID;
> + cmd->continued = false;
> +
> + ret = xi3c_master_common_xfer(master, xfer);
> + ccc->err = cmd->err;
> +
> + return ret;
> +}
> +
> +static int xi3c_master_send_direct_ccc_cmd(struct xi3c_master *master,
> + struct i3c_ccc_cmd *ccc)
> +{
> + struct xi3c_xfer *xfer __free(kfree) = NULL;
> + struct xi3c_cmd *cmd;
> + int ret;
> +
> + if (ccc->dests[0].payload.len > XI3C_MAXDATA_LENGTH)
> + return -EINVAL;
> +
> + xfer = xi3c_master_alloc_xfer(2);
> + if (!xfer)
> + return -ENOMEM;
> +
> + /* Broadcasted message */
> + cmd = &xfer->cmds[0];
> + cmd->addr = I3C_BROADCAST_ADDR;
> + cmd->rnw = false;
> + cmd->tx_buf = &ccc->id;
> + cmd->tx_len = 1;
> + cmd->type = XI3C_SDR_MODE;
> + cmd->tid = XI3C_SDR_TID;
> + cmd->continued = true;
> +
> + /* Directed message */
> + cmd = &xfer->cmds[1];
> + cmd->addr = ccc->dests[0].addr;
> + cmd->rnw = ccc->rnw;
> + if (cmd->rnw) {
> + cmd->rx_buf = ccc->dests[0].payload.data;
> + cmd->rx_len = ccc->dests[0].payload.len;
> + } else {
> + cmd->tx_buf = ccc->dests[0].payload.data;
> + cmd->tx_len = ccc->dests[0].payload.len;
> + }
> + cmd->type = XI3C_SDR_MODE;
> + cmd->tid = XI3C_SDR_TID;
> + cmd->continued = false;
> +
> + ret = xi3c_master_common_xfer(master, xfer);
> +
> + /*
> + * Report the broadcast command's error if it failed, otherwise the
> + * directed command's, so a NACK on either phase reaches the caller.
> + */
> + ccc->err = xfer->cmds[0].err ? xfer->cmds[0].err : xfer->cmds[1].err;
> +
> + return ret;
> +}
> +
> +static int xi3c_master_send_ccc_cmd(struct i3c_master_controller *m,
> + struct i3c_ccc_cmd *cmd)
> +{
> + struct xi3c_master *master = to_xi3c_master(m);
> +
> + if (cmd->id & I3C_CCC_DIRECT)
> + return xi3c_master_send_direct_ccc_cmd(master, cmd);
> +
> + return xi3c_master_send_bdcast_ccc_cmd(master, cmd); }
> +
> +static int xi3c_master_i3c_xfers(struct i3c_dev_desc *dev,
> + struct i3c_xfer *xfers,
> + int nxfers, enum i3c_xfer_mode mode) {
> + struct i3c_master_controller *m = i3c_dev_get_master(dev);
> + struct xi3c_master *master = to_xi3c_master(m);
> + struct xi3c_xfer *xfer __free(kfree) = NULL;
> + int i, ret;
> +
> + if (!nxfers)
> + return 0;
> +
> + if (mode != I3C_SDR)
> + return -EOPNOTSUPP;
> +
> + for (i = 0; i < nxfers; i++)
> + if (xfers[i].len > XI3C_MAXDATA_LENGTH)
> + return -EINVAL;
> +
> + xfer = xi3c_master_alloc_xfer(nxfers);
> + if (!xfer)
> + return -ENOMEM;
> +
> + for (i = 0; i < nxfers; i++) {
> + struct xi3c_cmd *cmd = &xfer->cmds[i];
> +
> + cmd->addr = dev->info.dyn_addr;
> + cmd->rnw = xfers[i].rnw;
> +
> + if (cmd->rnw) {
> + cmd->rx_buf = xfers[i].data.in;
> + cmd->rx_len = xfers[i].len;
> + } else {
> + cmd->tx_buf = xfers[i].data.out;
> + cmd->tx_len = xfers[i].len;
> + }
> +
> + cmd->type = XI3C_SDR_MODE;
> + cmd->tid = XI3C_SDR_TID;
> + cmd->continued = (i + 1) < nxfers;
> + }
> +
> + ret = xi3c_master_common_xfer(master, xfer);
> +
> + for (i = 0; i < nxfers; i++) {
> + xfers[i].err = xfer->cmds[i].err;
> + if (xfers[i].rnw)
> + xfers[i].actual_len = xfers[i].len - xfer->cmds[i].rx_len;
> + }
> +
> + return ret;
> +}
> +
> +static int xi3c_master_i2c_xfers(struct i2c_dev_desc *dev,
> + struct i2c_msg *xfers,
> + int nxfers)
> +{
> + struct i3c_master_controller *m = i2c_dev_get_master(dev);
> + struct xi3c_master *master = to_xi3c_master(m);
> + struct xi3c_xfer *xfer __free(kfree) = NULL;
> + int i;
> +
> + if (!nxfers)
> + return 0;
> +
> + for (i = 0; i < nxfers; i++)
> + if (xfers[i].len > XI3C_MAXDATA_LENGTH)
> + return -EINVAL;
> +
> + xfer = xi3c_master_alloc_xfer(nxfers);
> + if (!xfer)
> + return -ENOMEM;
> +
> + for (i = 0; i < nxfers; i++) {
> + struct xi3c_cmd *cmd = &xfer->cmds[i];
> +
> + cmd->addr = xfers[i].addr & XI3C_ADDR_MASK;
> + cmd->rnw = !!(xfers[i].flags & I2C_M_RD);
> +
> + if (cmd->rnw) {
> + cmd->rx_buf = xfers[i].buf;
> + cmd->rx_len = xfers[i].len;
> + } else {
> + cmd->tx_buf = xfers[i].buf;
> + cmd->tx_len = xfers[i].len;
> + }
> +
> + cmd->type = XI3C_I2C_MODE;
> + cmd->tid = XI3C_I2C_TID;
> + cmd->continued = (i + 1) < nxfers;
> + }
> +
> + return xi3c_master_common_xfer(master, xfer); }
> +
> +static int xi3c_clk_cfg(struct xi3c_master *master, unsigned long
> +sclhz, u8 mode) {
> + unsigned long core_rate, core_periodns;
> + u32 tcasmin, tsustart, tsustop, thdstart;
> + u32 thigh, tlow, thold;
> + u32 odthigh, odtlow;
> +
> + core_rate = clk_get_rate(master->pclk);
> + if (!core_rate)
> + return -EINVAL;
> +
> + if (!sclhz)
> + return -EINVAL;
> +
> + core_periodns = DIV_ROUND_UP(NSEC_PER_SEC, core_rate);
> +
> + thigh = DIV_ROUND_UP(core_rate, sclhz) >> 1;
> + tlow = thigh;
> +
> + if (thigh <= XI3C_CYCLE_ADJUST)
> + return -EINVAL;
> +
> + /* Hold time : 40% of tlow time */
> + thold = (tlow * 4) / 10;
> +
> + if (xi3c_get_revision_number(master) == 0)
> + thold = max_t(u32, thold, XI3C_THOLD_MIN_REV0);
> + else
> + thold = max_t(u32, thold, XI3C_THOLD_MIN_REV1);
> +
> + iowrite32((thigh - XI3C_CYCLE_ADJUST) & XI3C_TIMING_MASK,
> + master->membase + XI3C_SCL_HIGH_TIME_OFFSET);
> + iowrite32((tlow - XI3C_CYCLE_ADJUST) & XI3C_TIMING_MASK,
> + master->membase + XI3C_SCL_LOW_TIME_OFFSET);
> + iowrite32((thold - XI3C_CYCLE_ADJUST) & XI3C_TIMING_MASK,
> + master->membase + XI3C_SDA_HOLD_TIME_OFFSET);
> +
> + if (mode == XI3C_I2C_MODE) {
> + iowrite32((thigh - XI3C_CYCLE_ADJUST) & XI3C_TIMING_MASK,
> + master->membase +
> XI3C_OD_SCL_HIGH_TIME_OFFSET);
> + iowrite32((tlow - XI3C_CYCLE_ADJUST) & XI3C_TIMING_MASK,
> + master->membase +
> XI3C_OD_SCL_LOW_TIME_OFFSET);
> +
> + tcasmin = DIV_ROUND_UP(XI3C_I2C_TCASMIN_NS,
> core_periodns);
> + } else {
> + odtlow = DIV_ROUND_UP(XI3C_OD_TLOW_NS, core_periodns);
> + odthigh = DIV_ROUND_UP(XI3C_OD_THIGH_NS, core_periodns);
> +
> + odtlow = max(tlow, odtlow);
> + odthigh = min(thigh, odthigh);
> +
> + if (odthigh <= XI3C_CYCLE_ADJUST)
> + return -EINVAL;
> +
> + iowrite32((odthigh - XI3C_CYCLE_ADJUST) &
> XI3C_TIMING_MASK,
> + master->membase +
> XI3C_OD_SCL_HIGH_TIME_OFFSET);
> + iowrite32((odtlow - XI3C_CYCLE_ADJUST) & XI3C_TIMING_MASK,
> + master->membase +
> XI3C_OD_SCL_LOW_TIME_OFFSET);
> +
> + tcasmin = DIV_ROUND_UP(XI3C_TCASMIN_NS, core_periodns);
> + }
> +
> + thdstart = max(thigh, tcasmin);
> + tsustart = max(tlow, tcasmin);
> + tsustop = max(tlow, tcasmin);
> +
> + iowrite32((tsustart - XI3C_CYCLE_ADJUST) & XI3C_TIMING_MASK,
> + master->membase + XI3C_TSU_START_OFFSET);
> + iowrite32((thdstart - XI3C_CYCLE_ADJUST) & XI3C_TIMING_MASK,
> + master->membase + XI3C_THD_START_OFFSET);
> + iowrite32((tsustop - XI3C_CYCLE_ADJUST) & XI3C_TIMING_MASK,
> + master->membase + XI3C_TSU_STOP_OFFSET);
> +
> + return 0;
> +}
> +
> +static int xi3c_master_bus_init(struct i3c_master_controller *m) {
> + struct xi3c_master *master = to_xi3c_master(m);
> + struct i3c_bus *bus = i3c_master_get_bus(m);
> + struct i3c_device_info info = {};
> + unsigned long sclhz;
> + u32 pid1_bcr_dcr;
> + u8 mode;
> + int ret;
> +
> + switch (bus->mode) {
> + case I3C_BUS_MODE_MIXED_FAST:
> + case I3C_BUS_MODE_MIXED_LIMITED:
> + case I3C_BUS_MODE_MIXED_SLOW:
> + mode = XI3C_I2C_MODE;
> + sclhz = bus->scl_rate.i2c;
> + break;
> + case I3C_BUS_MODE_PURE:
> + mode = XI3C_SDR_MODE;
> + sclhz = bus->scl_rate.i3c;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + ret = xi3c_clk_cfg(master, sclhz, mode);
> + if (ret)
> + return ret;
> +
> + xi3c_master_init(master);
> +
> + /* Get an address for the master. */
> + ret = i3c_master_get_free_addr(m, 0);
> + if (ret < 0)
> + return ret;
> +
> + info.dyn_addr = ret;
> +
> + /* Write the dynamic address value to the address register. */
> + iowrite32(info.dyn_addr, master->membase + XI3C_ADDRESS_OFFSET);
> +
> + /* Read PID, BCR and DCR values, and assign to i3c device info. */
> + pid1_bcr_dcr = ioread32(master->membase + XI3C_PID1_BCR_DCR);
> + info.pid = ((u64)FIELD_GET(XI3C_PID1_MASK, pid1_bcr_dcr) << 32) |
> + ioread32(master->membase + XI3C_PID0_OFFSET);
> + info.bcr = FIELD_GET(XI3C_BCR_MASK, pid1_bcr_dcr);
> + info.dcr = FIELD_GET(XI3C_DCR_MASK, pid1_bcr_dcr);
> +
> + return i3c_master_set_info(&master->base, &info); }
> +
> +static void xi3c_master_bus_cleanup(struct i3c_master_controller *m) {
> + struct xi3c_master *master = to_xi3c_master(m);
> +
> + xi3c_master_disable(master);
> +}
> +
> +static const struct i3c_master_controller_ops xi3c_master_ops = {
> + .bus_init = xi3c_master_bus_init,
> + .bus_cleanup = xi3c_master_bus_cleanup,
> + .do_daa = xi3c_master_do_daa,
> + .supports_ccc_cmd = xi3c_master_supports_ccc_cmd,
> + .send_ccc_cmd = xi3c_master_send_ccc_cmd,
> + .i3c_xfers = xi3c_master_i3c_xfers,
> + .i2c_xfers = xi3c_master_i2c_xfers,
> +};
> +
> +static int xi3c_master_probe(struct platform_device *pdev) {
> + struct xi3c_master *master;
> + int ret;
> +
> + master = devm_kzalloc(&pdev->dev, sizeof(*master), GFP_KERNEL);
> + if (!master)
> + return -ENOMEM;
> +
> + master->dev = &pdev->dev;
> +
> + master->membase = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(master->membase))
> + return dev_err_probe(master->dev, PTR_ERR(master->membase),
> + "Failed to map registers\n");
> +
> + master->pclk = devm_clk_get_enabled(master->dev, NULL);
> + if (IS_ERR(master->pclk))
> + return dev_err_probe(master->dev, PTR_ERR(master->pclk),
> + "Failed to get and enable clock\n");
> +
> + ret = devm_mutex_init(master->dev, &master->lock);
> + if (ret)
> + return ret;
> +
> + platform_set_drvdata(pdev, master);
> +
> + return i3c_master_register(&master->base, master->dev,
> + &xi3c_master_ops, false);
> +}
> +
> +static void xi3c_master_remove(struct platform_device *pdev) {
> + struct xi3c_master *master = platform_get_drvdata(pdev);
> +
> + i3c_master_unregister(&master->base);
> +}
> +
> +static const struct of_device_id xi3c_master_of_ids[] = {
> + { .compatible = "xlnx,axi-i3c-1.0" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, xi3c_master_of_ids);
> +
> +static struct platform_driver xi3c_master_driver = {
> + .probe = xi3c_master_probe,
> + .remove = xi3c_master_remove,
> + .driver = {
> + .name = "axi-i3c-master",
> + .of_match_table = xi3c_master_of_ids,
> + },
> +};
> +module_platform_driver(xi3c_master_driver);
> +
> +MODULE_AUTHOR("Manikanta Guntupalli <manikanta.guntupalli@amd.com>");
> +MODULE_AUTHOR("Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>");
> +MODULE_AUTHOR("Shubham Patil <shubhamsanjay.patil@amd.com>");
I don't agree with adding new authors in V9.
This driver is already part of the downstream kernel and is being used:
https://github.com/Xilinx/linux-xlnx/blob/master/drivers/i3c/master/amd-i3c-master.c
The main purpose of V9 is to drop the framework-level support added in recent versions. The current V9 patch is mostly aligned with the initial patch versions (without framework support changes).
Thanks,
Manikanta
> +MODULE_DESCRIPTION("AMD AXI I3C master driver");
> MODULE_LICENSE("GPL");
> --
> 2.34.1
^ permalink raw reply
* [PATCH v2] dt-bindings: watchdog: microchip,pic32mzda-wdt: Convert to DT schema
From: Udaya Kiran Challa @ 2026-06-24 5:56 UTC (permalink / raw)
To: tsbogend, robh, krzk+dt, conor+dt
Cc: skhan, me, linux-rtc, devicetree, linux-kernel,
Udaya Kiran Challa, Krzysztof Kozlowski
Convert Microchip PIC32 Watchdog Timer devicetree binding
from legacy text format to DT schema.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
---
Changelog:
Changes since v1:
- Fix example indentation
- Correct example clock specifier from REF2CLK to LPRCCLK
Link to v1:https://lore.kernel.org/all/20260620172354.155565-1-challauday369@gmail.com/
---
.../bindings/watchdog/microchip,pic32-wdt.txt | 18 --------
.../watchdog/microchip,pic32mzda-wdt.yaml | 44 +++++++++++++++++++
2 files changed, 44 insertions(+), 18 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/watchdog/microchip,pic32-wdt.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/microchip,pic32mzda-wdt.yaml
diff --git a/Documentation/devicetree/bindings/watchdog/microchip,pic32-wdt.txt b/Documentation/devicetree/bindings/watchdog/microchip,pic32-wdt.txt
deleted file mode 100644
index f03a29a1b323..000000000000
--- a/Documentation/devicetree/bindings/watchdog/microchip,pic32-wdt.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-* Microchip PIC32 Watchdog Timer
-
-When enabled, the watchdog peripheral can be used to reset the device if the
-WDT is not cleared periodically in software.
-
-Required properties:
-- compatible: must be "microchip,pic32mzda-wdt".
-- reg: physical base address of the controller and length of memory mapped
- region.
-- clocks: phandle of source clk. Should be <&rootclk LPRCCLK>.
-
-Example:
-
- watchdog@1f800800 {
- compatible = "microchip,pic32mzda-wdt";
- reg = <0x1f800800 0x200>;
- clocks = <&rootclk LPRCCLK>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/microchip,pic32mzda-wdt.yaml b/Documentation/devicetree/bindings/watchdog/microchip,pic32mzda-wdt.yaml
new file mode 100644
index 000000000000..a5dd633c3e78
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/microchip,pic32mzda-wdt.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/microchip,pic32mzda-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC32MZDA Watchdog Timer
+
+maintainers:
+ - Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+
+description:
+ The PIC32 watchdog timer can be used to reset the device if software fails
+ to periodically service the watchdog.
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ const: microchip,pic32mzda-wdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/microchip,pic32-clock.h>
+
+ watchdog@1f800800 {
+ compatible = "microchip,pic32mzda-wdt";
+ reg = <0x1f800800 0x200>;
+ clocks = <&rootclk LPRCCLK>;
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/2] arm64: dts: socfpga: agilex72: Add initial device tree support
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-24 5:56 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
This series introduces initial device tree support for the Intel
SoCFPGA Agilex72 platform.
The first patch registers the new SoC and board compatible strings in
the DT binding. The second patch adds the SoC DTSI and board DTS with
basic platform nodes.
Changes in v2:
- Rename platform from agilex7-gen2 to agilex72
- Add arm,armv8-timer node (was mistakenly removed in v1); other
review comments from Shashiko are either addressed or confirmed as false positives
consistent with existing SoCFPGA platform conventions
Nazim Amirul (2):
dt-bindings: arm: altera: Add Agilex72 SoCFPGA compatible strings
arm64: dts: socfpga: agilex72: Add initial device tree
.../devicetree/bindings/arm/altera.yaml | 6 +
arch/arm64/boot/dts/intel/Makefile | 1 +
.../boot/dts/intel/socfpga_agilex72.dtsi | 128 ++++++++++++++++++
.../boot/dts/intel/socfpga_agilex72_socdk.dts | 15 ++
4 files changed, 150 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts
--
2.43.7
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: arm: altera: Add Agilex72 SoCFPGA compatible strings
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-24 5:56 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
In-Reply-To: <20260624055644.7508-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Add the SoC and board compatible strings for the Intel SoCFPGA
Agilex72 platform.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
Changes in v2:
- Rename platform from agilex7-gen2 to agilex72
---
Documentation/devicetree/bindings/arm/altera.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml
index 4b096e52243e..cc03fb437a9a 100644
--- a/Documentation/devicetree/bindings/arm/altera.yaml
+++ b/Documentation/devicetree/bindings/arm/altera.yaml
@@ -115,6 +115,12 @@ properties:
- intel,socfpga-agilex5-socdk-nand
- const: intel,socfpga-agilex5
+ - description: Agilex72 boards
+ items:
+ - enum:
+ - intel,socfpga-agilex72-socdk
+ - const: intel,socfpga-agilex72
+
- description: Agilex7m boards
items:
- enum:
--
2.43.7
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: socfpga: agilex72: Add initial device tree
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-24 5:56 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
In-Reply-To: <20260624055644.7508-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Add initial device tree support for the Intel SoCFPGA Agilex72
platform. This introduces the SoC DTSI and the SoCDK board DTS as
the first upstream submission for this platform.
The Agilex72 SoC features a heterogeneous CPU cluster with
Cortex-A520 and Cortex-A720 cores, and includes an SMMU v3 for
memory management.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
Changes in v2:
- Rename platform from agilex7-gen2 to agilex72
- Add arm,armv8-timer node (was mistakenly removed in v1); other
review comments from Shashiko are either addressed or confirmed as false positives
consistent with existing SoCFPGA platform conventions
---
arch/arm64/boot/dts/intel/Makefile | 1 +
.../boot/dts/intel/socfpga_agilex72.dtsi | 128 ++++++++++++++++++
.../boot/dts/intel/socfpga_agilex72_socdk.dts | 15 ++
3 files changed, 144 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts
diff --git a/arch/arm64/boot/dts/intel/Makefile b/arch/arm64/boot/dts/intel/Makefile
index 088a03b89c99..270c70fdf084 100644
--- a/arch/arm64/boot/dts/intel/Makefile
+++ b/arch/arm64/boot/dts/intel/Makefile
@@ -8,6 +8,7 @@ dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_n6000.dtb \
socfpga_agilex5_socdk_013b.dtb \
socfpga_agilex5_socdk_modular.dtb \
socfpga_agilex5_socdk_nand.dtb \
+ socfpga_agilex72_socdk.dtb \
socfpga_agilex7m_socdk.dtb \
socfpga_n5x_socdk.dtb
dtb-$(CONFIG_ARCH_KEEMBAY) += keembay-evm.dtb
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
new file mode 100644
index 000000000000..2a4ad4130f37
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex72.dtsi
@@ -0,0 +1,128 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026, Altera Corporation
+ */
+/dts-v1/;
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+ compatible = "intel,socfpga-agilex72";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ atf_reserved: atf@80000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x80000000 0x0 0x100000>;
+ alignment = <0x1000>;
+ no-map;
+ };
+
+ service_reserved: svcbuffer@80100000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x80100000 0x0 0xf00000>;
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a520";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x0>;
+ };
+
+ cpu1: cpu@100 {
+ compatible = "arm,cortex-a520";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x100>;
+ };
+
+ cpu2: cpu@200 {
+ compatible = "arm,cortex-a720";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x200>;
+ };
+
+ cpu3: cpu@300 {
+ compatible = "arm,cortex-a720";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x300>;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupt-parent = <&intc>;
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ intc: interrupt-controller@7000000 {
+ compatible = "arm,gic-v3";
+ reg = <0x0 0x7000000 0x0 0x10000>,
+ <0x0 0x7080000 0x0 0x100000>;
+ ranges;
+ #interrupt-cells = <3>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-controller;
+ #redistributor-regions = <1>;
+ redistributor-stride = <0x0 0x40000>;
+
+ its: msi-controller@7040000 {
+ compatible = "arm,gic-v3-its";
+ reg = <0x0 0x7040000 0x0 0x20000>;
+ msi-controller;
+ #msi-cells = <1>;
+ };
+ };
+
+ soc: soc@0 {
+ compatible = "simple-bus";
+ ranges = <0 0 0 0xffffffff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ interrupt-parent = <&intc>;
+
+ smmu: iommu@c100000 {
+ compatible = "arm,smmu-v3";
+ reg = <0x0c100000 0x30000>;
+ interrupts = <GIC_SPI 134 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 129 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 132 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "eventq", "gerror", "priq";
+ dma-coherent;
+ #iommu-cells = <1>;
+ };
+
+ ocram: sram@0 {
+ compatible = "mmio-sram";
+ reg = <0x00000000 0x80000>;
+ ranges = <0 0 0x80000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts b/arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts
new file mode 100644
index 000000000000..336e12a88cb4
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex72_socdk.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026, Altera Corporation
+ */
+#include "socfpga_agilex72.dtsi"
+
+/ {
+ model = "Altera SoCFPGA Agilex72 SoCDK";
+ compatible = "intel,socfpga-agilex72-socdk", "intel,socfpga-agilex72";
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x0 0x80000000 0x0 0x80000000>;
+ };
+};
--
2.43.7
^ permalink raw reply related
* [PATCH 2/2] clk: aspeed: add AST2700 PECI clock
From: Ryan Chen @ 2026-06-24 5:45 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery
Cc: linux-clk, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen
In-Reply-To: <20260624-peci_clk-v1-0-ee28b92e22e9@aspeedtech.com>
Register the SoC1 PECI clock as a mux selected by SCU1_CLK_SEL2 bit 16,
choosing between the 25MHz CLKIN and HPLL/4. Add the HPLL/4 fixed factor
clock to serve as the second mux parent.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
drivers/clk/aspeed/clk-ast2700.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/clk/aspeed/clk-ast2700.c b/drivers/clk/aspeed/clk-ast2700.c
index 8b7b382f6f3e..5f499ec0e1d1 100644
--- a/drivers/clk/aspeed/clk-ast2700.c
+++ b/drivers/clk/aspeed/clk-ast2700.c
@@ -273,6 +273,13 @@ static const unsigned int sdclk_parent_ids[] = {
static const struct clk_hw *sdclk_parent_hws[ARRAY_SIZE(sdclk_parent_ids)];
+static const unsigned int peciclk_parent_ids[] = {
+ SCU1_CLKIN,
+ SCU1_CLK_HPLL_DIV4
+};
+
+static const struct clk_hw *peciclk_parent_hws[ARRAY_SIZE(peciclk_parent_ids)];
+
#define FIXED_CLK(_id, _name, _rate) \
{ \
.id = _id, \
@@ -458,6 +465,7 @@ static const struct ast2700_clk_info ast2700_scu1_clk_info[] __initconst = {
PLL_CLK(SCU1_CLK_HPLL, CLK_PLL, "soc1-hpll", SCU1_CLKIN, SCU1_HPLL_PARAM),
PLL_CLK(SCU1_CLK_APLL, CLK_PLL, "soc1-apll", SCU1_CLKIN, SCU1_APLL_PARAM),
PLL_CLK(SCU1_CLK_DPLL, CLK_PLL, "soc1-dpll", SCU1_CLKIN, SCU1_DPLL_PARAM),
+ FIXED_FACTOR_CLK(SCU1_CLK_HPLL_DIV4, "soc1-hpll_div4", SCU1_CLK_HPLL, 1, 4),
FIXED_FACTOR_CLK(SCU1_CLK_APLL_DIV2, "soc1-apll_div2", SCU1_CLK_APLL, 1, 2),
FIXED_FACTOR_CLK(SCU1_CLK_APLL_DIV4, "soc1-apll_div4", SCU1_CLK_APLL, 1, 4),
FIXED_FACTOR_CLK(SCU1_CLK_CAN, "canclk", SCU1_CLK_APLL, 1, 10),
@@ -481,6 +489,8 @@ static const struct ast2700_clk_info ast2700_scu1_clk_info[] __initconst = {
uxclk_parent_hws, SCU1_CLK_SEL2, 0, 2),
MUX_CLK(SCU1_CLK_HUXCLK, "huxclk", uxclk_parent_ids, ARRAY_SIZE(uxclk_parent_ids),
uxclk_parent_hws, SCU1_CLK_SEL2, 3, 2),
+ MUX_CLK(SCU1_CLK_PECI, "peciclk", peciclk_parent_ids, ARRAY_SIZE(peciclk_parent_ids),
+ peciclk_parent_hws, SCU1_CLK_SEL2, 16, 1),
DIVIDER_CLK(SCU1_CLK_SDCLK, "sdclk", SCU1_CLK_SDMUX,
SCU1_CLK_SEL1, 14, 3, ast2700_clk_div_table),
PLL_CLK(SCU1_CLK_UARTX, CLK_UART_PLL, "uartxclk", SCU1_CLK_UXCLK, SCU1_UXCLK_CTRL),
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: clock: ast2700: add PECI clock
From: Ryan Chen @ 2026-06-24 5:44 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery
Cc: linux-clk, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen
In-Reply-To: <20260624-peci_clk-v1-0-ee28b92e22e9@aspeedtech.com>
Add SCU1_CLK_PECI for the SoC1 PECI controller clock source, and
SCU1_CLK_HPLL_DIV4 which serves as one of the PECI clock mux parents.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
include/dt-bindings/clock/aspeed,ast2700-scu.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/dt-bindings/clock/aspeed,ast2700-scu.h b/include/dt-bindings/clock/aspeed,ast2700-scu.h
index bacf712e8e04..138f78ce5f07 100644
--- a/include/dt-bindings/clock/aspeed,ast2700-scu.h
+++ b/include/dt-bindings/clock/aspeed,ast2700-scu.h
@@ -163,5 +163,7 @@
#define SCU1_CLK_GATE_PORTDUSB2CLK 85
#define SCU1_CLK_GATE_LTPI1TXCLK 86
#define SCU1_CLK_I3C 87
+#define SCU1_CLK_HPLL_DIV4 88
+#define SCU1_CLK_PECI 89
#endif
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] Add AST2700 PECI clock support
From: Ryan Chen @ 2026-06-24 5:44 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery
Cc: linux-clk, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen
Add the PECI clock for the AST2700 SoC1. The PECI clock is a mux
controlled by SCU1_CLK_SEL2 bit 16, selecting between the 25MHz CLKIN
and HPLL/4.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
Ryan Chen (2):
dt-bindings: clock: ast2700: add PECI clock
clk: aspeed: add AST2700 PECI clock
drivers/clk/aspeed/clk-ast2700.c | 10 ++++++++++
include/dt-bindings/clock/aspeed,ast2700-scu.h | 2 ++
2 files changed, 12 insertions(+)
---
base-commit: 948efecf22e49aa4bf55bb73ec79a0ddcfd38571
change-id: 20260623-peci_clk-ba87e043ee5f
Best regards,
--
Ryan Chen <ryan_chen@aspeedtech.com>
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: Dmitry Torokhov @ 2026-06-24 4:28 UTC (permalink / raw)
To: David Heidelberg
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jason A. Donenfeld, Matthias Schiffer, Vincent Huang,
Bjorn Andersson, Konrad Dybcio, linux-input, devicetree,
linux-kernel, linux-arm-msm, phone-devel, Krzysztof Kozlowski,
Konrad Dybcio
In-Reply-To: <742c7a13-9465-40e8-8990-e679712e9784@ixit.cz>
Hi David,
On Sun, Jun 21, 2026 at 07:11:45PM +0200, David Heidelberg wrote:
> On 28/05/2026 00:13, David Heidelberg wrote:
> > On 27/05/2026 23:56, Dmitry Torokhov wrote:
> > > Hi David,
> > >
> > > On Sat, May 23, 2026 at 11:45:35AM +0200, David Heidelberg via B4 Relay wrote:
> > > > From: David Heidelberg <david@ixit.cz>
> > > >
> > > > We know the driver is reporting s3706b, introduce the compatible so we
> > > > can more easily introduce quirks for weird touchscreen replacements in
> > > > followup series.
> > > >
> > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > > > Signed-off-by: David Heidelberg <david@ixit.cz>
> > > > ---
> > > > arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > b/arch/ arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > index 6b7378cf4d493..148164d456a5a 100644
> > > > --- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > +++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > @@ -475,17 +475,17 @@ bq27441_fg: bq27441-battery@55 {
> > > > };
> > > > };
> > > > &i2c12 {
> > > > status = "okay";
> > > > clock-frequency = <400000>;
> > > > synaptics-rmi4-i2c@20 {
> > > > - compatible = "syna,rmi4-i2c";
> > > > + compatible = "syna,rmi4-s3706b", "syna,rmi4-i2c";
> > >
> > > So I believe we established that this device (s3706b) does not in fact
> > > implement rmi4 protocol properly. Why do we have "syna,rmi4-i2c" as a
> > > fallback? Shouldn't it be just "syna,rmi4-s3706b"?
> >
> > The vendor supplies s3706b which does implement the RMI4 properly.
> >
> > The 3rd party replacement impersonating original parts may not implement
> > it properly, but I don't address this issue in this initial submission.
> >
> > With this compatible we know which original part is used by the vendor
> > and installed in the phones, so later we can deduct specific sequences
> > for the replacement aftermarket parts to keep phone touchscreen working
> > same as they do on Android without affecting other devices.
>
> Hello Dmitry.
>
> May I ask what is currently preventing this series from moving forward?
>
> The first version was posted in 2023 [1]. I picked it up again in 2025 [2]
> and am now on the 9th iteration (this patchset). At this point, the series
> has been under discussion for well over a year, with relatively little
> feedback and increasingly long gaps between review rounds.
>
> The current approach is based on the guidance I have received so far,
> including suggestions from the device-tree maintainers. When concerns were
> raised, I tried to address them and rework the series accordingly.
>
> What I am struggling with is understanding what specific issue still needs
> to be resolved before these patches can be accepted. If there are remaining
> requirements, objections to the approach, or technical concerns that I have
> not addressed, I would appreciate having them stated explicitly so I can
> work on them.
>
> I also split out the straightforward, self-contained changes in the hope
> that at least those could progress independently while I continued working
> on any follow-up requirements. However, even those patches do not appear to
> be moving forward.
>
> Could you please clarify what outcome you would like to see from this
> series, and what concrete changes would be required to get it accepted?
I am still confused about how you want to differentiate between the full
RMI4 support vs the OnePlus flavor. The "syna,rmi4-s3706b", as you
mentioned, implements RMI4 protocol properly, so we do not need to
actually have it documented neither in binding nor in DTS.
The issue you have with after-market parts that are not compliant and we
need to figure out how to deal with them. Inside the driver I
essentially need a"incomplete protocol" flag that we can use to
implement additional checks or skip known to be not implemented
functions/queries. In DT we could introduce something like
"oneplus,rmi4-i2c" that is decidedly not compatible with "syna,rmi4-i2c"
and neither one should be a fallback for the other.
This of course needs buy-in from DT maintainers.
Does this make sense?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 3/3] iio: magnetometer: st_magn: honour st,fullscale-milligauss DT property
From: me @ 2026-06-24 4:18 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, Herman van Hazendonk, David Lechner,
Nuno Sá, Andy Shevchenko, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, Denis Ciocca,
Lars-Peter Clausen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Denis Ciocca, Linus Walleij, linux-iio,
linux-kernel, llvm, devicetree
In-Reply-To: <ajrjRdEkZAho8h1E@ashevche-desk.local>
On 2026-06-23 21:49, Andy Shevchenko wrote:
> On Tue, Jun 23, 2026 at 08:29:16PM +0100, Jonathan Cameron wrote:
>> On Tue, 16 Jun 2026 15:02:06 +0200
>> Herman van Hazendonk <github.com@herrie.org> wrote:
>>
>> > The ST magnetometer core's common probe hardcodes fs_avl[0] -- the
>> > highest-sensitivity full-scale supported by the chip -- as the
>> > starting range. For the LSM303DLH that is +/-1.3 G; for the
>> > LSM303DLHC and LSM303DLM it is +/-2 G; for the LIS3MDL it is +/-4 G.
>> >
>> > That is the right default for "minimal noise floor at a desk", but
>> > it leaves no margin for boards that pick up appreciable DC bias from
>> > nearby PCB structures. On the HP TouchPad (apq8060 / tenderloin) the
>> > LSM303DLH magnetometer is mounted close enough to the surrounding
>> > power planes that X reads back as the chip's 0xF000 overflow
>> > sentinel (== -4096 raw, the value the chip publishes when the ADC
>> > saturates) on every sample at the chip-default range, while Y and Z
>> > fall well within the +/-1.3 G window.
>> >
>> > Parse the st,fullscale-milligauss device-tree property (documented
>> > separately in dt-bindings/iio/st,st-sensors.yaml) in the
>> > magnetometer common probe to select the initial fs_avl entry by its
>> > mg value. The DT binding pins the accepted value set per compatible
>> > via allOf/if-then enum clauses, so a malformed mg value fails
>> > dt_binding_check rather than reaching the driver. Sensors with a
>> > fixed full-scale (fs.addr == 0: LSM303AGR, LIS2MDL, IIS2MDC) have no
>> > register to switch and the property is rejected outright for them
>> > in the binding; the parse block is additionally gated on fs.addr as
>> > defence in depth against stale DTBs.
>> >
>> > Per-sensor mg ranges are listed in st_magn_sensors_settings[]. For
>> > LSM303DLH and LSM303DLHC/DLM the valid values are 1300, 1900, 2500,
>> > 4000, 4700, 5600 and 8100; for LIS3MDL, LSM9DS1-magn and LSM303C-magn
>> > they are 4000, 8000, 12000, 16000.
>> >
>> > Empirical scale sweep on the HP TouchPad confirmed that on this
>> > board any fs_avl >= 1 produces non-saturated X readings:
>> >
>> > scale (0.001 G/LSB) | X raw Y raw Z raw
>> > --------------------+-------------------------------
>> > 1.100 | -4096 44 46 (X saturated)
>> > 0.855 | -547 37 37 (clean)
>> > 0.670 | -433 94 103 (clean)
>> > 0.450 | -266 44 71 (clean)
>> > 0.400 | -235 34 65 (clean)
>> > 0.330 | -196 27 56 (clean)
>> > 0.230 | -145 15 40 (clean)
>> >
>> > 2500 mg is the natural choice for tenderloin: comfortably outside
>> > the saturation regime while keeping useful precision for compass
>> > applications.
>> >
>> > Assisted-by: Claude:claude-opus-4-7 sparse smatch clang-analyzer coccinelle checkpatch
>> > Assisted-by: Sashiko:claude-opus-4-7
>> Hmm. First time I remember seeing Sashiko credited like this. Seems
>> like pretty much
>> every patch series of any complexity would end up crediting sashiko.
>> Out of curiosity were you just looking at reports, or were you running
>> it locally to
>> help with development?
>
> I believe it's the second one, because LKML version uses Gemini (as far
> as I
> understand the case). At least that's why I haven't commented on this
> tag.
I have the whole toolchain running locally to avoid too many submissions
and
feedback from Sashiko with Gemini after submitting. For small drivers I
can run
Gemini locally as well, usually stick with Claude Opus 4.7 since that's
what I
have a subscription for. For very complicated and large drivers Claude
Opus
tends to time out even with 1 or 2 hour, so I fall back to Claude Haiku
4.5
(which catches quite a few things, but is not as thorough as Opus or
Gemini).
Seeing Sashiko tends to provide different feedback on different rounds,
I try
to only submit when Sashiko and all others are clean.
Hope this clarifies!
Herman
^ permalink raw reply
* RE: [PATCH 0/7] soc: aspeed: Add AST2600 eSPI controller support
From: YH Chung @ 2026-06-24 3:59 UTC (permalink / raw)
To: Shulzhenko, Oleksandr, Arnd Bergmann, Andrew Jeffery,
Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Ryan Chen, Philipp Zabel, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, maciej.lawniczak@intel.com, Mark Brown
In-Reply-To: <KL1PR0601MB4276452D09689C90B04209C190EF2@KL1PR0601MB4276.apcprd06.prod.outlook.com>
Hi Mark,
> (1) Reuse the existing SPI subsystem and treat eSPI packets as pure signals.
> (2) Maintain the driver under the SoC subsystem, since there is currently no
> eSPI subsystem.
> (3) Create a new eSPI subsystem and rewrite the eSPI driver accordingly.
>
> For option 1, we do not think this would be a good fit, because eSPI has clearly
> defined semantics for each channel, and our hardware exposes different sets of
> registers for each of them.
Regarding option 1, could you kindly share your feedback on whether this
patch set should be modified to fit under the SPI subsystem, or whether a new
eSPI subsystem would be more appropriate?
For option 2, Arnd has indicated that he does not want to take this through
the SoC subsystem. Therefore, if the SPI subsystem is also not a good fit, we
think a new eSPI subsystem may be needed to provide a common home for channel
handling, even though the individual channels are relatively independent.
For example, the VW and OOB channel handling could potentially be integrated
with existing subsystems such as GPIO or net/mctp. However, the Flash channel
would still need an eSPI-specific interface to configure the backing store.
Placing that code under MTD feels awkward, since the driver is not really an
MTD device or a flash controller.
If this direction sounds reasonable, we would like to explore introducing a
new drivers/espi subsystem and moving the eSPI driver there. Please let us
know if you think we should take a different approach.
Thanks,
Yun Hsuan.
^ permalink raw reply
* Re: [PATCH v7 0/3] Add driver support for ESWIN EIC7700 HSP clock and reset generator
From: Xuyang Dong @ 2026-06-24 3:01 UTC (permalink / raw)
To: mturquette, sboyd, bmasney, benoit.monin
Cc: robh, krzk+dt, conor+dt, linux-clk, devicetree, linux-kernel,
p.zabel, huangyifeng, ningyu, linmin, pinkesh.vaghela
In-Reply-To: <20260605060730.1605-1-dongxuyang@eswincomputing.com>
>
> From: Xuyang Dong <dongxuyang@eswincomputing.com>
>
> Add support for the ESWIN EIC7700 HSP (high-speed peripherals). The drivers
> provide basic functionality to manage and control the clock and reset
> signals for EIC7700 HSP, including mmc, USB, ethernet, SATA and DMAC.
>
> The clock and reset registers are mapped to overlapping I/O address ranges.
> This causes a resource conflict when two drivers attempt to request the
> same region. Use the auxiliary device framework: the main driver
> allocates the shared register region and passes it to auxiliary
> devices, avoiding resource contention and duplicate remapping.
>
> Features:
> Implements support for the ESWIN EIC7700 HSP clock and reset controller.
> Provide API to manage clock and reset signals for the EIC7700 HSP.
>
> Supported chips:
> ESWIN EIC7700 series SoC.
>
> Test:
> Test this patch on the Sifive HiFive Premier P550 (which used the EIC7700
> SoC), include USB and other peripherals. All the drivers of these modules
> use the clock module and reset module.
>
Hi Stephen and Michael,
Just a gentle ping on this thread.
v7 now has Reviewed-by tags from Brian for the clock part, and from
Philipp for the reset part. Do you have any further comments on v7?
Best regards,
Xuyang Dong
> Updates:
> Changes in v7:
> - Clock driver:
> - Add the 'CLK_IGNORE_UNUSED' flag to all gate clocks; otherwise,
> board bring-up fails unless 'clk_ignore_unused' is passed on the
> kernel command line.
> - Sashiko's comments: not addressed in this version
> (see email for explanation)
>
> - Link to v6: https://lore.kernel.org/all/20260519081431.1424-1-dongxuyang@eswincomputing.com/
>
> Changes in v6:
> - Clock driver:
> - Add 'select REGMAP_MMIO' for Kconfig entry (Sashiko review of v5).
> - Reset driver:
> - Add <linux/module.h> (Sashiko review of v5).
>
> - Link to v5: https://lore.kernel.org/all/20260514114212.903-1-dongxuyang@eswincomputing.com/
>
> Changes in v5:
> - Clock driver:
> - Add check for regmap_read().
> - Add "Reviewed-by: Brian Masney <bmasney@redhat.com>".
>
> - Link to v4: https://lore.kernel.org/all/20260512020432.671-1-dongxuyang@eswincomputing.com/
>
> Changes in v4:
> - Clock driver:
> - Remove "Reviewed-by: Benoît Monin <benoit.monin@bootlin.com>" and
> "Reviewed-by: Brian Masney <bmasney@redhat.com>", because the clock
> driver has been updated.
> - Remove inclusion of io.h.
> - Add struct regmap to eic7700_hsp_clk_gate.
> Replace 'void __iomem *reg' with 'unsigned int reg'.
> Replace 'void __iomem *ref_reg' with 'unsigned int ref_reg'.
> Replace long with int for 'offset' and 'ref_offset'.
> Remove 'spinlock_t *lock'.
> Apply the same changes to hsp_clk_register_gate().
> - Remove the structure eic7700_hsp_regmap_lock, and the functions
> eic7700_hsp_regmap_lock() and eic7700_hsp_regmap_unlock().
> - Remove the 'guard(spinlock_irqsave)(gate->lock)' in
> hsp_clk_gate_endisable().
> - Replace readl() and writel() with regmap_assign_bits() in
> hsp_clk_gate_endisable().
> - Change the parameter enable from int to bool.
> - Replace readl() with regmap_read() in hsp_clk_gate_is_enabled().
> - Remove the lock_ctx variable.
> - Move eic7700_hsp_regmap_config from inside the probe function to global
> scope.
> Remove '.lock', '.unlock' and 'lock_arg'.
> Add '.fast_io = true' and '.use_raw_spinlock = true'.
> - Reset driver:
> - Add "Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>" for reset.
> - Drop the temporary variable, just return regmap_assign_bits(...) directly.
> - Replace -EINVAL with -ENODEV for dev_get_regmap() check.
> - Drop the '_dt'.
>
> - Link to v3: https://lore.kernel.org/all/20260423090904.2108-1-dongxuyang@eswincomputing.com/
>
> Changes in v3:
> - Bindings:
> - Added "Acked-by: Conor Dooley <conor.dooley@microchip.com>" for bindings.
> - Clock driver:
> - Remove 'gate_flags'.
> - Add __acquires for eic7700_hsp_regmap_lock() and add __releases for
> eic7700_hsp_regmap_unlock().
> - Move writel(USB_REF_XTAL24M, gate->ref_reg) into enable. Because this
> is only used for USB gate clock on the enable path. And modify the
> comments.
> - Simplify to: 'return !!(readl(gate->reg) & BIT(gate->bit_idx));'.
> - Drop const from eic7700_hsp_regmap_config.
> - Declare eic7700_hsp_regmap_config as a regular variable at the top.
>
> - Link to v2: https://lore.kernel.org/all/20260420093929.1895-1-dongxuyang@eswincomputing.com/
>
> Changes in v2:
> - Bindings:
> - Remove "hsp_" from clock-names.
> - Replace "eswin,eic7700-clock.yaml" and "eswin,eic7700-hspcrg.yaml" with
> "eswin,eic7700*".
> - Replace "eswin,eic7700-clock.h" and "eswin,eic7700-hspcrg.h" with
> "eswin,eic7700*".
> - Clock driver:
> - Use guard(spinlock_irqsave)(gate->lock) instead of spin_lock_irqsave()
> and remove spin_unlock_irqrestore().
> - Remove the newline in function hsp_clk_gate_is_enabled().
> - Use struct clk_init_data init = {}.
> - Replace 'static struct clk_parent_data' with
> 'static const struct clk_parent_data'.
> - Change '.fw_name' to '.index', because the function
> eswin_clk_register_fixed_factor() uses .index.
> - The structures of clocks should use static struct. When registering a clock,
> the 'hw' field in the structure will be assigned.
> - Remove __force.
> - Create the regmap in the clock driver and remove (__force void*)data->base.
> The reset driver uses dev_get_regmap() to get the regmap from the clock.
> - Move 'const struct regmap_config eic7700_hsp_regmap_config' from reset
> driver to clock driver.
> - The USB clock gate (hsp_clk_gate_endisable) and the reset driver both
> perform read-modify-write cycles on registers 0x800 and 0x900. Use
> custom regmap lock callbacks so that regmap operations hold data->lock
> with IRQs disabled, the same lock the clock gate path uses, preventing
> concurrent RMW races on those shared registers.
> - Change to 'ret = eswin_clk_register_fixed_factor(dev, eic7700_hsp_factor_clks,'.
> The next line will be over 80 characters and under 100 characters.
> - Reset driver:
> - Remove 'depends on COMMON_CLK_EIC7700_HSP' and 'default COMMON_CLK_EIC7700_HSP'.
> - Use regmap_assign_bits() in assert and deassert functions.
> - Remove eic7700_hsp_reset_reset().
> - The clock driver creates the regmap, and the reset driver uses dev_get_regmap().
> - Remove of_reset_n_cells.
>
> - Link to v1: https://lore.kernel.org/all/20260403093459.612-1-dongxuyang@eswincomputing.com/
>
> Xuyang Dong (3):
> dt-bindings: clock: Add ESWIN eic7700 HSP clock and reset generator
> clk: eswin: Add eic7700 HSP clock driver
> reset: eswin: Add eic7700 HSP reset driver
>
> .../bindings/clock/eswin,eic7700-hspcrg.yaml | 63 ++++
> MAINTAINERS | 5 +-
> drivers/clk/eswin/Kconfig | 13 +
> drivers/clk/eswin/Makefile | 1 +
> drivers/clk/eswin/clk-eic7700-hsp.c | 345 ++++++++++++++++++
> drivers/reset/Kconfig | 11 +
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-eic7700-hsp.c | 113 ++++++
> .../dt-bindings/clock/eswin,eic7700-hspcrg.h | 33 ++
> .../dt-bindings/reset/eswin,eic7700-hspcrg.h | 21 ++
> 10 files changed, 604 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/clock/eswin,eic7700-hspcrg.yaml
> create mode 100644 drivers/clk/eswin/clk-eic7700-hsp.c
> create mode 100644 drivers/reset/reset-eic7700-hsp.c
> create mode 100644 include/dt-bindings/clock/eswin,eic7700-hspcrg.h
> create mode 100644 include/dt-bindings/reset/eswin,eic7700-hspcrg.h
>
> --
> 2.34.1
^ permalink raw reply
* Re: [PATCH 5/6] dt-bindings: clock: qcom: Document Nord GPU clock controllers
From: Shawn Guo @ 2026-06-24 2:52 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Bartosz Golaszewski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Konrad Dybcio, Ajit Pandey,
Imran Shaik, Jagadeesh Kona, linux-arm-msm, linux-clk,
linux-kernel, devicetree
In-Reply-To: <20260623-nords_mm_v1-v1-5-860c84539804@oss.qualcomm.com>
On Tue, Jun 23, 2026 at 04:24:08PM +0530, Taniya Das wrote:
> Add Device Tree binding documentation for the GPU clock controllers
> on the Qualcomm Nord platform.
>
> The platform includes two GPU clock controller instances, GPUCC and
> GPUCC2. Document the compatible strings for both controllers.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> .../bindings/clock/qcom,sm8450-gpucc.yaml | 3 ++
> include/dt-bindings/clock/qcom,nord-gpucc.h | 51 ++++++++++++++++++++++
> 2 files changed, 54 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml
> index fdbdf605ee695637512ce4f98c9b6fcfacb9154f..ba85692240e07a4ed8e69c6b61847c5601b32fa0 100644
> --- a/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml
> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml
> @@ -18,6 +18,7 @@ description: |
> include/dt-bindings/clock/qcom,glymur-gpucc.h
> include/dt-bindings/clock/qcom,kaanapali-gpucc.h
> include/dt-bindings/clock/qcom,milos-gpucc.h
> + include/dt-bindings/clock/qcom,nord-gpucc.h
> include/dt-bindings/clock/qcom,sar2130p-gpucc.h
> include/dt-bindings/clock/qcom,sm4450-gpucc.h
> include/dt-bindings/clock/qcom,sm8450-gpucc.h
> @@ -33,6 +34,8 @@ properties:
> - qcom,glymur-gpucc
> - qcom,kaanapali-gpucc
> - qcom,milos-gpucc
> + - qcom,nord-gpu2cc
> + - qcom,nord-gpucc
I see inconsistency in naming between dispcc0/dispcc1 and gpucc/gpu2cc.
Shawn
^ permalink raw reply
* Re: [PATCH 4/6] clk: qcom: Add Nord display clock controller support
From: Shawn Guo @ 2026-06-24 2:42 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Bartosz Golaszewski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Konrad Dybcio, Ajit Pandey,
Imran Shaik, Jagadeesh Kona, linux-arm-msm, linux-clk,
linux-kernel, devicetree
In-Reply-To: <20260623-nords_mm_v1-v1-4-860c84539804@oss.qualcomm.com>
On Tue, Jun 23, 2026 at 04:24:07PM +0530, Taniya Das wrote:
> Add support for the display clock controllers (DISPCC) on the
> Qualcomm Nord platform.
>
> The platform includes two display clock controller instances,
> display0 and display1. Register support for both controllers.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> drivers/clk/qcom/Kconfig | 11 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/dispcc0-nord.c | 2006 +++++++++++++++++++++++++++++++++++++++
> drivers/clk/qcom/dispcc1-nord.c | 2006 +++++++++++++++++++++++++++++++++++++++
> 4 files changed, 4024 insertions(+)
>
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index 7d84c2f1d911a35430bba7670409f59972dcca0f..874136a2ad9aaa117df2c7ad5c8abc5280b76339 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -145,6 +145,17 @@ config CLK_KAANAPALI_VIDEOCC
> Say Y if you want to support video devices and functionality such as
> video encode/decode.
>
> +config CLK_NORD_DISPCC
> + tristate "Nord Display Clock Controller"
> + depends on ARM64 || COMPILE_TEST
> + select CLK_NORD_GCC
> + default m if ARCH_QCOM
> + help
> + Support for the display clock controllers on Qualcomm Technologies, Inc
> + Nord devices. There are two display clock controllers on Nord SoC.
> + Say Y if you want to support display devices and functionality such as
> + splash screen.
> +
> config CLK_NORD_GCC
> tristate "Nord Global Clock Controller"
> depends on ARM64 || COMPILE_TEST
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index 58f9a5eb6fd7fc457607a179d8bab5623fedf706..4282f43e7078f1fe0dde6f942040eb6bd122d7ce 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -37,6 +37,7 @@ obj-$(CONFIG_CLK_KAANAPALI_GCC) += gcc-kaanapali.o
> obj-$(CONFIG_CLK_KAANAPALI_GPUCC) += gpucc-kaanapali.o gxclkctl-kaanapali.o
> obj-$(CONFIG_CLK_KAANAPALI_TCSRCC) += tcsrcc-kaanapali.o
> obj-$(CONFIG_CLK_KAANAPALI_VIDEOCC) += videocc-kaanapali.o
> +obj-$(CONFIG_CLK_NORD_DISPCC) += dispcc0-nord.o dispcc1-nord.o
> obj-$(CONFIG_CLK_NORD_GCC) += gcc-nord.o negcc-nord.o nwgcc-nord.o segcc-nord.o
> obj-$(CONFIG_CLK_NORD_TCSRCC) += tcsrcc-nord.o
> obj-$(CONFIG_CLK_X1E80100_CAMCC) += camcc-x1e80100.o
> diff --git a/drivers/clk/qcom/dispcc0-nord.c b/drivers/clk/qcom/dispcc0-nord.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..c0097482a1a94a99a05767726b5a7405cf014fea
> --- /dev/null
> +++ b/drivers/clk/qcom/dispcc0-nord.c
> @@ -0,0 +1,2006 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
This include shouldn't be needed.
Shawn
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
^ permalink raw reply
* Re: [PATCH 0/3] SM8450 IPA support
From: Esteban Urrutia @ 2026-06-24 1:57 UTC (permalink / raw)
To: Alex Elder, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alex Elder
Cc: linux-arm-msm, devicetree, linux-kernel, netdev
In-Reply-To: <959db395-ae71-4a50-bd46-ac5add545a52@riscstar.com>
On 6/23/26 11:56 AM, Alex Elder wrote:
> I assume you have implemented this based on what you found in
> some downstream code. And if so, could you please indicate
> where to find that (so I can do some cross-referencing myself).
> I no longer have access to any Qualcomm internal documentation.
Hello. Yes, that would be the case. What I used goes as follows.
1. My personal findings regarding IPA:
https://gist.github.com/esteuwu/bd49ed67ed9290f41612bdae1cacb5bc
Note that these may be subject to errors since I mostly cross-checked
values to get here.
2. SM8450 downstream device tree:
https://github.com/LineageOS/android_kernel_qcom_sm8450-devicetrees/blob/lineage-20/qcom/waipio.dtsi#L3304
3. SM8475 downstream device tree:
https://github.com/LineageOS/android_kernel_qcom_sm8450-devicetrees/blob/lineage-20/qcom/cape.dtsi#L2624
It's worth mentioning that between SM8450 and SM8475, IPA SRAM size is
different, so I used the smaller SRAM size to support SM8475 as well. Hence
the reason why I included SM8475's downstream device tree as well.
4. SM8450/SM8475 downstream IPA driver:
https://github.com/LineageOS/android_kernel_qcom_sm8450-modules/tree/lineage-20/qcom/opensource/dataipa
Most of my cross-checking came from the source code in this folder.
Finally, for some values such as qmap, aggregation, tre_count and
event_count, I had to cross-check on the same folder that all
ipa_data-vX.Y.c files reside, since I couldn't find any reference to these
values in downstream code.
Regards,
Esteban
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: qcom: sm8450: Add IPA support
From: Esteban Urrutia @ 2026-06-24 1:52 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alex Elder
Cc: linux-arm-msm, devicetree, linux-kernel, netdev
In-Reply-To: <806046b2-20ed-437e-a7e6-b3c0699f5a2d@oss.qualcomm.com>
On 6/23/26 5:37 AM, Konrad Dybcio wrote:
> size = 0xb0000 for the RAM and uC regions that the driver seems
> to poke at (at a glance anyway..)
Sorry, I don't quite understand. Could you please clarify?
> base=0x1468_0000
> size=0x40_000
Noted, will fix in v2.
Regards,
Esteban
^ permalink raw reply
* Re: [PATCH 3/3] net: ipa: Add IPA v5.1 data
From: sashiko-bot @ 2026-06-24 1:44 UTC (permalink / raw)
To: Esteban Urrutia via B4 Relay; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260622-sm8450-ipa-v1-3-532f0299f96e@proton.me>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Driver probe failure on SM8450 due to intentional SMEM size mismatch.
- [High] Overlapping IPA local memory regions will cause silent data corruption between filter tables and routing statistics.
- [Medium] The AP_MODEM_RX endpoint is incorrectly assigned to the DST_UL resource group, causing resource starvation and unused DST_DL resources.
--
commit 6da897f459f64d1618e077cb44111c9397ad478b
Author: Esteban Urrutia <esteuwu@proton.me>
net: ipa: Add IPA v5.1 data
Add the required ipa_data-v5.1.c file for IPA v5.1 along with changes
that declare IPA v5.1 support. This version of IPA is used in both SM8450
and SM8475 SoCs.
> diff --git a/drivers/net/ipa/data/ipa_data-v5.1.c b/drivers/net/ipa/data/ipa_data-v5.1.c
> new file mode 100644
> index 0000000000000..85b21efa1224d
> --- /dev/null
> +++ b/drivers/net/ipa/data/ipa_data-v5.1.c
[ ... ]
> + [IPA_ENDPOINT_AP_MODEM_RX] = {
> + .ee_id = GSI_EE_AP,
> + .channel_id = 1,
> + .endpoint_id = 23,
> + .toward_ipa = false,
> + .channel = {
> + .tre_count = 256,
> + .event_count = 256,
> + .tlv_count = 9,
> + },
> + .endpoint = {
> + .config = {
> + .resource_group = IPA_RSRC_GROUP_DST_UL,
[Severity: Medium]
Will assigning this downlink endpoint to the UL resource group cause
resource starvation?
Since this is the AP_MODEM_RX endpoint, should it be assigned to
IPA_RSRC_GROUP_DST_DL instead?
Later in the ipa_resource_dst[] configuration, 5 data sectors are allocated
to IPA_RSRC_GROUP_DST_DL. If no endpoints are assigned to the DL group,
those sectors will remain unused while AP_MODEM_RX competes with AP_LAN_RX
for the limited DST_UL resources.
[ ... ]
> +/* IPA-resident memory region data for an SoC having IPA v5.1 */
> +static const struct ipa_mem ipa_mem_local_data[] = {
[ ... ]
> + {
> + .id = IPA_MEM_STATS_TETHERING,
> + .offset = 0x2910,
> + .size = 0x03c0,
> + .canary_count = 0,
> + },
> + {
> + .id = IPA_MEM_AP_V4_FILTER,
> + .offset = 0x29b8,
> + .size = 0x0188,
> + .canary_count = 2,
> + },
> + {
> + .id = IPA_MEM_AP_V6_FILTER,
> + .offset = 0x2b40,
> + .size = 0x0228,
> + .canary_count = 0,
> + },
> + {
> + .id = IPA_MEM_STATS_FILTER_ROUTE,
> + .offset = 0x2cd0,
> + .size = 0x0ba0,
> + .canary_count = 2,
> + },
[Severity: High]
Do these memory region offsets overlap and lead to data corruption?
IPA_MEM_STATS_TETHERING starts at 0x2910 and has a size of 0x03c0, which
means it extends up to 0x2cd0.
However, IPA_MEM_AP_V4_FILTER begins at 0x29b8, placing it entirely inside
the tethering region. Similarly, IPA_MEM_AP_V6_FILTER starts at 0x2b40,
which overlaps both the end of the tethering region and the start of
IPA_MEM_STATS_FILTER_ROUTE.
Could hardware updates to the routing and filter stats corrupt the AP
filter tables here?
[ ... ]
> +/* Memory configuration data for an SoC having IPA v5.1 */
> +static const struct ipa_mem_data ipa_mem_data = {
> + .local_count = ARRAY_SIZE(ipa_mem_local_data),
> + .local = ipa_mem_local_data,
> + .imem_addr = 0x146a8000,
> + .imem_size = 0x00002000,
> + /*
> + * While this value is 0xb000 on SM8450 and 0x9000 on SM8475,
> + * it has been left set to 0x9000 for compatibility with SM8475
> + */
> + .smem_size = 0x00009000,
[Severity: High]
Will this hardcoded SMEM size cause the driver probe to fail on SM8450?
When the SM8450 bootloader or modem pre-allocates 0xb000 bytes,
qcom_smem_get() will return that actual size.
Looking at ipa_smem_init() in drivers/net/ipa/ipa_mem.c:
if (ret && actual != size) {
dev_err(dev, "SMEM item has size %zu, expected %zu\n",
actual, size);
return -EINVAL;
}
Because this strictly validates the returned size against
ipa->mem_data->smem_size, setting this to 0x9000 for SM8475 compatibility
would cause the size check to fail and abort the driver probe.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260622-sm8450-ipa-v1-0-532f0299f96e@proton.me?part=3
^ permalink raw reply
* RE: [PATCH 3/3] hwmon: (pmbus/fd5121): Add support FD5121, FD5123 and FD5125
From: Selvamani Rajagopal @ 2026-06-23 23:12 UTC (permalink / raw)
To: Guenter Roeck, Jonathan Corbet, Shuah Khan, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-hwmon@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <320c44c9-924f-4b7e-a46a-37a72fa7267f@roeck-us.net>
> -----Original Message-----
> From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
> Subject: Re: [PATCH 3/3] hwmon: (pmbus/fd5121): Add support FD5121, FD5123 and
> FD5125
>
>
> > + &sensor_dev_attr_vout_transition_rate.dev_attr.attr,
> > + NULL
>
> This is a complete no-go. We do not explose raw register data as sysfs
> attributes. You may expose essential register data as debugfs files,
> but only those deemed necessary. The above is just "let's blindly
> expose everything". Most of the above should be programmed in manufacturing
> and not be touched subsequently, much less as writeable attributes.
> Writing bad/unexpected values into many of those attributes can turn
> a board into a brick. It is bad enough that/if this is even possible,
> but exposing it as sysfs attribute would be a terrible idea.
>
> I am not going to review this driver any further at this point.
>
> Guenter
>
Thanks for your comment. Understood and agree on comment on exposing everything without enforcing what is being written/read.
We will discuss internally to see how to go about it. We need some custom registers for customers. We will identify those and
expose under debugfs, if needed.
> >
^ permalink raw reply
* Re: [PATCH v3 1/3] spi: dt-bindings: snps,dw-apb-ssi: add 'power-domains' property
From: Wolfram Sang @ 2026-06-23 23:07 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-renesas-soc, Herve Codina, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-spi, devicetree
In-Reply-To: <20260623-banana-bettong-from-saturn-417cce@quoll>
[-- Attachment #1: Type: text/plain, Size: 385 bytes --]
> > + power-domains:
> > + maxItems: 1
>
> You should explain in the commit msg that likely other devices belong to
> power domain as well or likely can belong. Otherwise based on the commit
> msg I would suggest restricting it per variant... except that indeed
> these other variants could have a power domain.
Okay, if 'likely' is enough for you, I can reword it.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ 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