* Re: [PATCH v4 1/5] dt-bindings: soc: cix,sky1-system-control: add audss system control
From: Conor Dooley @ 2026-06-17 15:54 UTC (permalink / raw)
To: joakim.zhang
Cc: mturquette, sboyd, bmasney, robh, krzk+dt, conor+dt, p.zabel,
gary.yang, cix-kernel-upstream, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260617060437.1474816-2-joakim.zhang@cixtech.com>
[-- Attachment #1: Type: text/plain, Size: 4379 bytes --]
On Wed, Jun 17, 2026 at 02:04:33PM +0800, joakim.zhang@cixtech.com wrote:
> From: Joakim Zhang <joakim.zhang@cixtech.com>
>
> The Cix Sky1 Audio Subsystem (AUDSS) groups audio-related clock, reset
> and control registers in a dedicated CRU block. Software reset lines are
> exposed on the syscon parent via #reset-cells, following the same model
> as the existing Sky1 FCH and S5 system control bindings.
>
> A clock-controller child node is required under the audss syscon. It has
> no reg property of its own and accesses the parent register block for mux,
> divider and gate fields.
>
> The AUDSS is also controlled by one power domain and reset part.
>
> Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
> ---
> .../soc/cix/cix,sky1-system-control.yaml | 48 +++++++++++++++++++
> .../reset/cix,sky1-audss-system-control.h | 25 ++++++++++
> 2 files changed, 73 insertions(+)
> create mode 100644 include/dt-bindings/reset/cix,sky1-audss-system-control.h
>
> diff --git a/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.yaml b/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.yaml
> index a01a515222c6..5a1cd5c24ade 100644
> --- a/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.yaml
> +++ b/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.yaml
> @@ -19,6 +19,7 @@ properties:
> - enum:
> - cix,sky1-system-control
> - cix,sky1-s5-system-control
> + - cix,sky1-audss-system-control
> - const: syscon
If the only thing these share are being a reset controller and having a
syscon fallback, I think it should be in a different file.
pw-bot: changes-requested
Cheers,
Conor.
>
> reg:
> @@ -27,6 +28,38 @@ properties:
> '#reset-cells':
> const: 1
>
> + power-domains:
> + maxItems: 1
> +
> + resets:
> + maxItems: 1
> +
> + clock-controller:
> + type: object
> + properties:
> + compatible:
> + const: cix,sky1-audss-clock
> + required:
> + - compatible
> + additionalProperties: true
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: cix,sky1-audss-system-control
> + then:
> + required:
> + - clock-controller
> + - power-domains
> + - resets
> + else:
> + properties:
> + clock-controller: false
> + power-domains: false
> + resets: false
> +
> required:
> - compatible
> - reg
> @@ -40,3 +73,18 @@ examples:
> reg = <0x4160000 0x100>;
> #reset-cells = <1>;
> };
> + - |
> + audss_syscon: system-controller@7110000 {
> + compatible = "cix,sky1-audss-system-control", "syscon";
> + reg = <0x7110000 0x10000>;
> + power-domains = <&smc_devpd 0>;
> + resets = <&s5_syscon 31>;
> + #reset-cells = <1>;
> +
> + clock-controller {
> + compatible = "cix,sky1-audss-clock";
> + #clock-cells = <1>;
> + clocks = <&scmi_clk 0>, <&scmi_clk 2>, <&scmi_clk 4>, <&scmi_clk 5>;
> + clock-names = "x8k", "x11k", "sys", "48m";
> + };
> + };
> diff --git a/include/dt-bindings/reset/cix,sky1-audss-system-control.h b/include/dt-bindings/reset/cix,sky1-audss-system-control.h
> new file mode 100644
> index 000000000000..aabdce60b094
> --- /dev/null
> +++ b/include/dt-bindings/reset/cix,sky1-audss-system-control.h
> @@ -0,0 +1,25 @@
> +/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */
> +/*
> + * Copyright 2026 Cix Technology Group Co., Ltd.
> + */
> +#ifndef DT_BINDING_RESET_CIX_SKY1_AUDSS_SYSTEM_CONTROL_H
> +#define DT_BINDING_RESET_CIX_SKY1_AUDSS_SYSTEM_CONTROL_H
> +
> +#define AUDSS_I2S0_SW_RST 0
> +#define AUDSS_I2S1_SW_RST 1
> +#define AUDSS_I2S2_SW_RST 2
> +#define AUDSS_I2S3_SW_RST 3
> +#define AUDSS_I2S4_SW_RST 4
> +#define AUDSS_I2S5_SW_RST 5
> +#define AUDSS_I2S6_SW_RST 6
> +#define AUDSS_I2S7_SW_RST 7
> +#define AUDSS_I2S8_SW_RST 8
> +#define AUDSS_I2S9_SW_RST 9
> +#define AUDSS_WDT_SW_RST 10
> +#define AUDSS_TIMER_SW_RST 11
> +#define AUDSS_MB0_SW_RST 12
> +#define AUDSS_MB1_SW_RST 13
> +#define AUDSS_HDA_SW_RST 14
> +#define AUDSS_DMAC_SW_RST 15
> +
> +#endif
> --
> 2.50.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss clock controller
From: Conor Dooley @ 2026-06-17 15:55 UTC (permalink / raw)
To: joakim.zhang
Cc: mturquette, sboyd, bmasney, robh, krzk+dt, conor+dt, p.zabel,
gary.yang, cix-kernel-upstream, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260617060437.1474816-4-joakim.zhang@cixtech.com>
[-- Attachment #1: Type: text/plain, Size: 5626 bytes --]
On Wed, Jun 17, 2026 at 02:04:35PM +0800, joakim.zhang@cixtech.com wrote:
> From: Joakim Zhang <joakim.zhang@cixtech.com>
>
> The AUDSS CRU contains an internal clock tree of muxes, dividers and
> gates for DSP, I2S, HDA, DMAC and related blocks. The clock provider is
> a child node of the cix,sky1-audss-system-control syscon and accesses
> registers through the parent MMIO region.
Why can this not just be part of the parent syscon node?
Cheers,
Conor.
>
> Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
> ---
> .../bindings/clock/cix,sky1-audss-clock.yaml | 72 +++++++++++++++++++
> .../dt-bindings/clock/cix,sky1-audss-clock.h | 60 ++++++++++++++++
> 2 files changed, 132 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/cix,sky1-audss-clock.yaml
> create mode 100644 include/dt-bindings/clock/cix,sky1-audss-clock.h
>
> diff --git a/Documentation/devicetree/bindings/clock/cix,sky1-audss-clock.yaml b/Documentation/devicetree/bindings/clock/cix,sky1-audss-clock.yaml
> new file mode 100644
> index 000000000000..ea813c5a2307
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/cix,sky1-audss-clock.yaml
> @@ -0,0 +1,72 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/cix,sky1-audss-clock.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Cix Sky1 audio subsystem clock controller
> +
> +maintainers:
> + - Joakim Zhang <joakim.zhang@cixtech.com>
> +
> +description: |
> + Clock provider for the Cix Sky1 audio subsystem (AUDSS).
> +
> + This node is a child of a cix,sky1-audss-system-control syscon node
> + (see cix,sky1-system-control.yaml). It does not have a reg property; clock
> + mux, divider and gate fields are accessed through the parent register block.
> +
> + Software reset lines for AUDSS blocks are exposed on the parent syscon via
> + #reset-cells (provider). Reset indices are defined in
> + include/dt-bindings/reset/cix,sky1-audss-system-control.h.
> +
> + Four SoC-level reference clocks listed in clocks/clock-names feed the AUDSS
> + clock tree. The provider exposes the internal AUDSS clocks to other devices
> + via #clock-cells; indices are defined in cix,sky1-audss-clock.h.
> +
> + The parent cix,sky1-audss-system-control node describes the SoC syscon
> + NoC (or bus) reset via resets and the audio subsystem power domain via
> + power-domains.
> +
> +properties:
> + compatible:
> + const: cix,sky1-audss-clock
> +
> + '#clock-cells':
> + const: 1
> + description:
> + Clock indices are defined in include/dt-bindings/clock/cix,sky1-audss-clock.h.
> +
> + clocks:
> + items:
> + - description: I2S parent clock for sampling rates multiple of 8kHz.
> + - description: I2S parent clock for sampling rates multiple of 11.025kHz.
> + - description: clock feeding most devices in audss (NOC, DSP, SRAM, HDA, DMAC, I2S, and Mailbox).
> + - description: clock feeding for HDA, Timer and Watchdog, which is a delicated 48MHz clock.
> +
> + clock-names:
> + items:
> + - const: x8k
> + - const: x11k
> + - const: sys
> + - const: 48m
> +
> +required:
> + - compatible
> + - '#clock-cells'
> + - clocks
> + - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/cix,sky1.h>
> +
> + clock-controller {
> + compatible = "cix,sky1-audss-clock";
> + #clock-cells = <1>;
> + clocks = <&scmi_clk CLK_TREE_AUDIO_CLK0>, <&scmi_clk CLK_TREE_AUDIO_CLK2>,
> + <&scmi_clk CLK_TREE_AUDIO_CLK4>, <&scmi_clk CLK_TREE_AUDIO_CLK5>;
> + clock-names = "x8k", "x11k", "sys", "48m";
> + };
> diff --git a/include/dt-bindings/clock/cix,sky1-audss-clock.h b/include/dt-bindings/clock/cix,sky1-audss-clock.h
> new file mode 100644
> index 000000000000..7e9bd3e6c7a1
> --- /dev/null
> +++ b/include/dt-bindings/clock/cix,sky1-audss-clock.h
> @@ -0,0 +1,60 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * Copyright 2026 Cix Technology Group Co., Ltd.
> + */
> +
> +#ifndef _DT_BINDINGS_CLK_CIX_SKY1_AUDSS_CLOCK_H
> +#define _DT_BINDINGS_CLK_CIX_SKY1_AUDSS_CLOCK_H
> +
> +#define CLK_AUD_CLK4_DIV2 0
> +#define CLK_AUD_CLK4_DIV4 1
> +#define CLK_AUD_CLK5_DIV2 2
> +
> +#define CLK_DSP_CLK 3
> +#define CLK_DSP_BCLK 4
> +#define CLK_DSP_PBCLK 5
> +
> +#define CLK_SRAM_AXI 6
> +
> +#define CLK_HDA_SYS 7
> +#define CLK_HDA_HDA 8
> +
> +#define CLK_DMAC_AXI 9
> +
> +#define CLK_WDG_APB 10
> +#define CLK_WDG_WDG 11
> +
> +#define CLK_TIMER_APB 12
> +#define CLK_TIMER_TIMER 13
> +
> +#define CLK_MB_0_APB 14 /* MB0: ap->dsp */
> +#define CLK_MB_1_APB 15 /* MB1: dsp->ap */
> +
> +#define CLK_I2S0_APB 16
> +#define CLK_I2S1_APB 17
> +#define CLK_I2S2_APB 18
> +#define CLK_I2S3_APB 19
> +#define CLK_I2S4_APB 20
> +#define CLK_I2S5_APB 21
> +#define CLK_I2S6_APB 22
> +#define CLK_I2S7_APB 23
> +#define CLK_I2S8_APB 24
> +#define CLK_I2S9_APB 25
> +#define CLK_I2S0 26
> +#define CLK_I2S1 27
> +#define CLK_I2S2 28
> +#define CLK_I2S3 29
> +#define CLK_I2S4 30
> +#define CLK_I2S5 31
> +#define CLK_I2S6 32
> +#define CLK_I2S7 33
> +#define CLK_I2S8 34
> +#define CLK_I2S9 35
> +
> +#define CLK_MCLK0 36
> +#define CLK_MCLK1 37
> +#define CLK_MCLK2 38
> +#define CLK_MCLK3 39
> +#define CLK_MCLK4 40
> +
> +#endif
> --
> 2.50.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: clock: ultrarisc: Add DP1000 Clock Controller
From: Conor Dooley @ 2026-06-17 15:56 UTC (permalink / raw)
To: wangjia
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-clk, devicetree,
linux-kernel
In-Reply-To: <20260617-ultrarisc-clock-v2-1-9cb16083e15e@ultrarisc.com>
[-- Attachment #1: Type: text/plain, Size: 4541 bytes --]
On Wed, Jun 17, 2026 at 02:02:54PM +0800, Jia Wang via B4 Relay wrote:
> From: Jia Wang <wangjia@ultrarisc.com>
>
> Add doc for the clock controller on the UltraRISC DP1000 RISC-V SoC.
>
> Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
Cheers,
Conor.
> ---
> .../bindings/clock/ultrarisc,dp1000-clk.yaml | 60 ++++++++++++++++++++++
> MAINTAINERS | 7 +++
> include/dt-bindings/clock/ultrarisc,dp1000-clk.h | 27 ++++++++++
> 3 files changed, 94 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/ultrarisc,dp1000-clk.yaml b/Documentation/devicetree/bindings/clock/ultrarisc,dp1000-clk.yaml
> new file mode 100644
> index 000000000000..ede565ec440c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ultrarisc,dp1000-clk.yaml
> @@ -0,0 +1,60 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/ultrarisc,dp1000-clk.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: UltraRISC DP1000 Clock Controller
> +
> +maintainers:
> + - Jia Wang <wangjia@ultrarisc.com>
> +
> +description: |
> + The UltraRISC DP1000 clock controller is driven from a single external
> + oscillator input. It provides a system PLL with fractional multiplier
> + and post-divider stages, several fixed-ratio derived clocks for
> + the on-chip subsystem, Clock Configuration Register (CCR) divider
> + outputs for GMAC and the UART, I2C, and SPI root clocks, and
> + per-instance gate clocks for UART0-3, I2C0-3, and SPI0-1.
> +
> + All available clocks are defined as preprocessor macros in
> + include/dt-bindings/clock/ultrarisc,dp1000-clk.h
> +
> +properties:
> + compatible:
> + const: ultrarisc,dp1000-clk
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> + description:
> + External oscillator input clock used as the parent of the PLLs.
> +
> + "#clock-cells":
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - "#clock-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/ultrarisc,dp1000-clk.h>
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + clock-controller@11080000 {
> + compatible = "ultrarisc,dp1000-clk";
> + reg = <0x0 0x11080000 0x0 0x1000>;
> + clocks = <&osc>;
> + #clock-cells = <1>;
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3d6db8cb608f..b7e43313c65f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -27439,6 +27439,13 @@ S: Maintained
> F: drivers/usb/common/ulpi.c
> F: include/linux/ulpi/
>
> +ULTRARISC DP1000 CLOCK DRIVER
> +M: Jia Wang <wangjia@ultrarisc.com>
> +L: linux-clk@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/clock/ultrarisc,dp1000-clk.yaml
> +F: include/dt-bindings/clock/ultrarisc,dp1000-clk.h
> +
> ULTRATRONIK BOARD SUPPORT
> M: Goran Rađenović <goran.radni@gmail.com>
> M: Börge Strümpfel <boerge.struempfel@gmail.com>
> diff --git a/include/dt-bindings/clock/ultrarisc,dp1000-clk.h b/include/dt-bindings/clock/ultrarisc,dp1000-clk.h
> new file mode 100644
> index 000000000000..751125f99965
> --- /dev/null
> +++ b/include/dt-bindings/clock/ultrarisc,dp1000-clk.h
> @@ -0,0 +1,27 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +#ifndef _DT_BINDINGS_CLOCK_ULTRARISC_DP1000_CLK_H
> +#define _DT_BINDINGS_CLOCK_ULTRARISC_DP1000_CLK_H
> +
> +#define DP1000_CLK_SYSPLL 0
> +#define DP1000_CLK_SYSPLL_DIV2 1
> +#define DP1000_CLK_SUBSYS 2
> +#define DP1000_CLK_GMAC 3
> +#define DP1000_CLK_UART_ROOT 4
> +#define DP1000_CLK_I2C_ROOT 5
> +#define DP1000_CLK_SPI_ROOT 6
> +#define DP1000_CLK_PCIE_DBI 7
> +#define DP1000_CLK_PCIEX4_CORE 8
> +#define DP1000_CLK_PCIEX16_CORE 9
> +#define DP1000_CLK_PCIE_AUX 10
> +#define DP1000_CLK_UART0 11
> +#define DP1000_CLK_UART1 12
> +#define DP1000_CLK_UART2 13
> +#define DP1000_CLK_UART3 14
> +#define DP1000_CLK_I2C0 15
> +#define DP1000_CLK_I2C1 16
> +#define DP1000_CLK_I2C2 17
> +#define DP1000_CLK_I2C3 18
> +#define DP1000_CLK_SPI0 19
> +#define DP1000_CLK_SPI1 20
> +
> +#endif /* _DT_BINDINGS_CLOCK_ULTRARISC_DP1000_CLK_H */
>
> --
> 2.34.1
>
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v7 0/4] PCI: tegra: Add Tegra264 support
From: Thierry Reding @ 2026-06-17 16:01 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár, Michal Simek,
Kevin Xie, Thierry Reding, Aksh Garg
Cc: linux-pci, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, Thierry Reding, Manikanta Maddireddy
Hi,
this series adds support for the PCIe controllers found on the Tegra264
SoC. There are six instances, one of which is for internal purposes only
and the other five are general purpose.
The first patch tweaks the DT bindings slightly to avoid new DT compiler
warnings that slipped through because they are now disabled by default
(-Wno-unit_address_vs_reg).
Before adding the driver in patch 3, patch 2 introduces some new common
wait times for PCIe and unifies the way that drivers use them. Finally,
patch 4 reorders the reg and reg-names property entries to match the
bindings changes from patch 1.
All of the prerequisites were merged in v7.1-rc1, so this can be applied
to the PCI tree directly. Optionally I can also pick up patch 4 into the
Tegra tree, but there should be no conflicts, so feel free to pick this
up with the rest.
Thanks,
Thierry
Changes in v7:
- fix build dependency on PCI_ECAM
- remove pre-silicon support code
- Link to v6: https://patch.msgid.link/20260602-tegra264-pcie-v6-0-edbcfa7a78fe@nvidia.com
Changes in v6:
- address review comments from Sashiko
- rebase onto v7.1-rc1, adjust DT bindings patch accordingly
- Link to v5: https://patch.msgid.link/20260526-tegra264-pcie-v5-0-84a813b979d7@nvidia.com
Changes in v5:
- address review comments for the PCI driver patch
- Link to v4: https://patch.msgid.link/20260402-tegra264-pcie-v4-0-21e2e19987e8@nvidia.com
Changes in v4:
- strip out dependencies that are going in through the ARM SoC tree
- revert bindings to oneOf construct so that we don't produce new DTC
warnings
- Link to v3: https://patch.msgid.link/20260326135855.2795149-1-thierry.reding@kernel.org
Changes in v3:
- integrate PCI standard wait times patch into the series to maintain
bisectability
- fix review comments from Mikko
- Link to v2: https://patch.msgid.link/20260320225443.2571920-1-thierry.reding@kernel.org
Changes in v2:
- fix an issue with sanity-checking disabled BARs
- address review comments
- Link to v1: https://patch.msgid.link/20260319160110.2131954-1-thierry.reding@kernel.org
Thanks,
Thierry
---
Thierry Reding (4):
dt-bindings: pci: Strictly distinguish C0 from C1-C5
PCI: Use standard wait times for PCIe link monitoring
PCI: tegra: Add Tegra264 support
arm64: tegra: Reorder reg and reg-names to match bindings
.../bindings/pci/nvidia,tegra264-pcie.yaml | 75 ++-
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 48 +-
drivers/pci/controller/Kconfig | 10 +-
drivers/pci/controller/Makefile | 1 +
.../controller/cadence/pcie-cadence-host-common.c | 6 +-
.../pci/controller/cadence/pcie-cadence-lga-regs.h | 5 -
drivers/pci/controller/mobiveil/pcie-mobiveil.c | 4 +-
drivers/pci/controller/mobiveil/pcie-mobiveil.h | 5 -
drivers/pci/controller/pci-aardvark.c | 7 +-
drivers/pci/controller/pcie-tegra264.c | 538 +++++++++++++++++++++
drivers/pci/controller/pcie-xilinx-nwl.c | 9 +-
drivers/pci/controller/plda/pcie-starfive.c | 9 +-
12 files changed, 634 insertions(+), 83 deletions(-)
---
base-commit: 8f5b04d01f6fbbb5537a0979182acf820766660d
change-id: 20260402-tegra264-pcie-e30abe23da07
Best regards,
--
Thierry Reding <treding@nvidia.com>
^ permalink raw reply
* [PATCH v7 1/4] dt-bindings: pci: Strictly distinguish C0 from C1-C5
From: Thierry Reding @ 2026-06-17 16:01 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár, Michal Simek,
Kevin Xie, Thierry Reding, Aksh Garg
Cc: linux-pci, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, Thierry Reding
In-Reply-To: <20260617-tegra264-pcie-v7-0-eae7ae964629@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
Instead of using the ECAM registers as the first entry, strictly make a
distinction between C0 and C1-C5. This is needed because otherwise the
unit address doesn't match the first "reg" entry. We also cannot change
the ordering of these nodes to follow the ECAM addresses because that
would put them outside of their "control bus" hierarchy since the ECAM
address space is a global one outside of any of the control busses.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v7:
- undo changes suggested by Sashiko, should've trust the dedicated tool
rather than the AI
Changes in v6:
- add maxItems as suggested by Sashiko
Changes in v5:
- rebase on top of v7.1-rc1, make it into a fix
Changes in v4:
- ECAM is outside of the controller's region, so it cannot be the first
reg entry, otherwise we get warnings because it doesn't match the
unit-address, so revert back to oneOf construct
Changes in v2:
- move ECAM region first and unify C0 vs. C1-C5
- move unevaluatedProperties to right before the examples
- add description to clarify the two types of controllers
- add examples for C0 and C1-C5
---
.../bindings/pci/nvidia,tegra264-pcie.yaml | 75 ++++++++++++++--------
1 file changed, 50 insertions(+), 25 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
index dc4f8725c9f5..acb677d477fb 100644
--- a/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/nvidia,tegra264-pcie.yaml
@@ -10,32 +10,23 @@ maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jon Hunter <jonathanh@nvidia.com>
+description: |
+ Of the six PCIe controllers found on Tegra264, one (C0) is used for the
+ internal GPU and the other five (C1-C5) are routed to connectors such as
+ PCI or M.2 slots. Therefore the UPHY registers (XPL) exist only for C1
+ through C5, but not for C0.
+
properties:
compatible:
const: nvidia,tegra264-pcie
reg:
- description: |
- Of the six PCIe controllers found on Tegra264, one (C0) is used for the
- internal GPU and the other five (C1-C5) are routed to connectors such as
- PCI or M.2 slots. Therefore the UPHY registers (XPL) exist only for C1
- through C5, but not for C0.
minItems: 4
- items:
- - description: ECAM-compatible configuration space
- - description: application layer registers
- - description: transaction layer registers
- - description: privileged transaction layer registers
- - description: data link/physical layer registers (not available on C0)
+ maxItems: 5
reg-names:
minItems: 4
- items:
- - const: ecam
- - const: xal
- - const: xtl
- - const: xtl-pri
- - const: xpl
+ maxItems: 5
interrupts:
minItems: 1
@@ -70,6 +61,40 @@ required:
allOf:
- $ref: /schemas/pci/pci-host-bridge.yaml#
+ - oneOf:
+ - description: C0 controller (no UPHY)
+ properties:
+ reg:
+ items:
+ - description: application layer registers
+ - description: transaction layer registers
+ - description: privileged transaction layer registers
+ - description: ECAM compatible configuration space
+
+ reg-names:
+ items:
+ - const: xal
+ - const: xtl
+ - const: xtl-pri
+ - const: ecam
+
+ - description: C1-C5 controllers (with UPHY)
+ properties:
+ reg:
+ items:
+ - description: application layer registers
+ - description: transaction layer registers
+ - description: privileged transaction layer registers
+ - description: data link/physical layer registers
+ - description: ECAM compatible configuration space
+
+ reg-names:
+ items:
+ - const: xal
+ - const: xtl
+ - const: xtl-pri
+ - const: xpl
+ - const: ecam
unevaluatedProperties: false
@@ -81,11 +106,11 @@ examples:
pci@c000000 {
compatible = "nvidia,tegra264-pcie";
- reg = <0xd0 0xb0000000 0x0 0x10000000>,
- <0x00 0x0c000000 0x0 0x00004000>,
+ reg = <0x00 0x0c000000 0x0 0x00004000>,
<0x00 0x0c004000 0x0 0x00001000>,
- <0x00 0x0c005000 0x0 0x00001000>;
- reg-names = "ecam", "xal", "xtl", "xtl-pri";
+ <0x00 0x0c005000 0x0 0x00001000>,
+ <0xd0 0xb0000000 0x0 0x10000000>;
+ reg-names = "xal", "xtl", "xtl-pri", "ecam";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -118,12 +143,12 @@ examples:
pci@8400000 {
compatible = "nvidia,tegra264-pcie";
- reg = <0xa8 0xb0000000 0x0 0x10000000>,
- <0x00 0x08400000 0x0 0x00004000>,
+ reg = <0x00 0x08400000 0x0 0x00004000>,
<0x00 0x08404000 0x0 0x00001000>,
<0x00 0x08405000 0x0 0x00001000>,
- <0x00 0x08410000 0x0 0x00010000>;
- reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
+ <0x00 0x08410000 0x0 0x00010000>,
+ <0xa8 0xb0000000 0x0 0x10000000>;
+ reg-names = "xal", "xtl", "xtl-pri", "xpl", "ecam";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
--
2.54.0
^ permalink raw reply related
* [PATCH v7 2/4] PCI: Use standard wait times for PCIe link monitoring
From: Thierry Reding @ 2026-06-17 16:01 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár, Michal Simek,
Kevin Xie, Thierry Reding, Aksh Garg
Cc: linux-pci, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, Thierry Reding
In-Reply-To: <20260617-tegra264-pcie-v7-0-eae7ae964629@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
Instead of defining the wait values for each driver, use common values
defined in the core pci.h header file. Note that while most drivers use
the usleep_range(), it looks like these were mostly cargo culted and
msleep() is a better choice given the fixed delay that the specification
calls for. Convert all drivers to msleep() and use the existing
definition.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v7:
- rebase on top of next-20260615 (resolve pci-aardvark.c conflict)
Changes in v6:
- convert all drivers to use msleep() (Lukas Wunner)
Changes in v2:
- fix build for Cadence
---
drivers/pci/controller/cadence/pcie-cadence-host-common.c | 6 ++++--
drivers/pci/controller/cadence/pcie-cadence-lga-regs.h | 5 -----
drivers/pci/controller/mobiveil/pcie-mobiveil.c | 4 ++--
drivers/pci/controller/mobiveil/pcie-mobiveil.h | 5 -----
drivers/pci/controller/pci-aardvark.c | 7 ++-----
drivers/pci/controller/pcie-xilinx-nwl.c | 9 ++-------
drivers/pci/controller/plda/pcie-starfive.c | 9 ++-------
7 files changed, 12 insertions(+), 33 deletions(-)
diff --git a/drivers/pci/controller/cadence/pcie-cadence-host-common.c b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
index 18e4b6c760b5..0ef4396151b4 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-host-common.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-host-common.c
@@ -16,6 +16,8 @@
#include "pcie-cadence-host-common.h"
#include "../pci-host-common.h"
+#include "../../pci.h"
+
#define LINK_RETRAIN_TIMEOUT HZ
u64 bar_max_size[] = {
@@ -54,12 +56,12 @@ int cdns_pcie_host_wait_for_link(struct cdns_pcie *pcie,
int retries;
/* Check if the link is up or not */
- for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
+ for (retries = 0; retries < PCIE_LINK_WAIT_MAX_RETRIES; retries++) {
if (pcie_link_up(pcie)) {
dev_info(dev, "Link up\n");
return 0;
}
- usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
+ msleep(PCIE_LINK_WAIT_SLEEP_MS);
}
return -ETIMEDOUT;
diff --git a/drivers/pci/controller/cadence/pcie-cadence-lga-regs.h b/drivers/pci/controller/cadence/pcie-cadence-lga-regs.h
index 857b2140c5d2..15dc4fcaf45d 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-lga-regs.h
+++ b/drivers/pci/controller/cadence/pcie-cadence-lga-regs.h
@@ -10,11 +10,6 @@
#include <linux/bitfield.h>
-/* Parameters for the waiting for link up routine */
-#define LINK_WAIT_MAX_RETRIES 10
-#define LINK_WAIT_USLEEP_MIN 90000
-#define LINK_WAIT_USLEEP_MAX 100000
-
/* Local Management Registers */
#define CDNS_PCIE_LM_BASE 0x00100000
diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil.c b/drivers/pci/controller/mobiveil/pcie-mobiveil.c
index 62ecbaeb0a60..e8346851c49b 100644
--- a/drivers/pci/controller/mobiveil/pcie-mobiveil.c
+++ b/drivers/pci/controller/mobiveil/pcie-mobiveil.c
@@ -218,11 +218,11 @@ int mobiveil_bringup_link(struct mobiveil_pcie *pcie)
int retries;
/* check if the link is up or not */
- for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
+ for (retries = 0; retries < PCIE_LINK_WAIT_MAX_RETRIES; retries++) {
if (mobiveil_pcie_link_up(pcie))
return 0;
- usleep_range(LINK_WAIT_MIN, LINK_WAIT_MAX);
+ msleep(PCIE_LINK_WAIT_SLEEP_MS);
}
dev_err(&pcie->pdev->dev, "link never came up\n");
diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil.h b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
index 7246de6a7176..11010a99e27c 100644
--- a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
+++ b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
@@ -122,11 +122,6 @@
#define IB_WIN_SIZE ((u64)256 * 1024 * 1024 * 1024)
#define MAX_PIO_WINDOWS 8
-/* Parameters for the waiting for link up routine */
-#define LINK_WAIT_MAX_RETRIES 10
-#define LINK_WAIT_MIN 90000
-#define LINK_WAIT_MAX 100000
-
#define PAGED_ADDR_BNDRY 0xc00
#define OFFSET_TO_PAGE_ADDR(off) \
((off & PAGE_LO_MASK) | PAGED_ADDR_BNDRY)
diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
index fd9c7d53e8a7..272c5c8fc1e5 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -256,9 +256,6 @@ enum {
#define PIO_RETRY_CNT 750000 /* 1.5 s */
#define PIO_RETRY_DELAY 2 /* 2 us*/
-#define LINK_WAIT_MAX_RETRIES 10
-#define LINK_WAIT_USLEEP_MIN 90000
-#define LINK_WAIT_USLEEP_MAX 100000
#define RETRAIN_WAIT_MAX_RETRIES 10
#define RETRAIN_WAIT_USLEEP_US 2000
@@ -350,13 +347,13 @@ static int advk_pcie_wait_for_link(struct advk_pcie *pcie)
int retries;
/* check if the link is up or not */
- for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
+ for (retries = 0; retries < PCIE_LINK_WAIT_MAX_RETRIES; retries++) {
if (advk_pcie_link_up(pcie)) {
pci_host_common_link_train_delay(pcie->link_gen);
return 0;
}
- usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
+ msleep(PCIE_LINK_WAIT_SLEEP_MS);
}
return -ETIMEDOUT;
diff --git a/drivers/pci/controller/pcie-xilinx-nwl.c b/drivers/pci/controller/pcie-xilinx-nwl.c
index 7db2c96c6cec..0dee19fa24ca 100644
--- a/drivers/pci/controller/pcie-xilinx-nwl.c
+++ b/drivers/pci/controller/pcie-xilinx-nwl.c
@@ -140,11 +140,6 @@
#define PCIE_PHY_LINKUP_BIT BIT(0)
#define PHY_RDY_LINKUP_BIT BIT(1)
-/* Parameters for the waiting for link up routine */
-#define LINK_WAIT_MAX_RETRIES 10
-#define LINK_WAIT_USLEEP_MIN 90000
-#define LINK_WAIT_USLEEP_MAX 100000
-
struct nwl_msi { /* MSI information */
DECLARE_BITMAP(bitmap, INT_PCI_MSI_NR);
struct irq_domain *dev_domain;
@@ -203,10 +198,10 @@ static int nwl_wait_for_link(struct nwl_pcie *pcie)
int retries;
/* check if the link is up or not */
- for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
+ for (retries = 0; retries < PCIE_LINK_WAIT_MAX_RETRIES; retries++) {
if (nwl_phy_link_up(pcie))
return 0;
- usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
+ msleep(PCIE_LINK_WAIT_SLEEP_MS);
}
dev_err(dev, "PHY link never came up\n");
diff --git a/drivers/pci/controller/plda/pcie-starfive.c b/drivers/pci/controller/plda/pcie-starfive.c
index 298036c3e7f9..2835c7af965e 100644
--- a/drivers/pci/controller/plda/pcie-starfive.c
+++ b/drivers/pci/controller/plda/pcie-starfive.c
@@ -45,11 +45,6 @@
#define STG_SYSCON_LNKSTA_OFFSET 0x170
#define DATA_LINK_ACTIVE BIT(5)
-/* Parameters for the waiting for link up routine */
-#define LINK_WAIT_MAX_RETRIES 10
-#define LINK_WAIT_USLEEP_MIN 90000
-#define LINK_WAIT_USLEEP_MAX 100000
-
struct starfive_jh7110_pcie {
struct plda_pcie_rp plda;
struct reset_control *resets;
@@ -217,12 +212,12 @@ static int starfive_pcie_host_wait_for_link(struct starfive_jh7110_pcie *pcie)
int retries;
/* Check if the link is up or not */
- for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
+ for (retries = 0; retries < PCIE_LINK_WAIT_MAX_RETRIES; retries++) {
if (starfive_pcie_link_up(&pcie->plda)) {
dev_info(pcie->plda.dev, "port link up\n");
return 0;
}
- usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
+ msleep(PCIE_LINK_WAIT_SLEEP_MS);
}
return -ETIMEDOUT;
--
2.54.0
^ permalink raw reply related
* [PATCH v7 3/4] PCI: tegra: Add Tegra264 support
From: Thierry Reding @ 2026-06-17 16:01 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár, Michal Simek,
Kevin Xie, Thierry Reding, Aksh Garg
Cc: linux-pci, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, Thierry Reding, Manikanta Maddireddy
In-Reply-To: <20260617-tegra264-pcie-v7-0-eae7ae964629@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
Add a driver for the PCIe controller found on NVIDIA Tegra264 SoCs. The
driver is very small, with its main purpose being to set up the address
translation registers and then creating a standard PCI host using ECAM.
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v7:
- select PCI_ECAM to satisfy the build dependency (Jonathan Hunter)
- remove pre-silicon support patch to avoid extra build dependency
Changes in v6:
- remove unneeded pm_runtime_disable() call (Sashiko)
- do not use noirq suspend/resume callbacks (Sashiko)
- wrap PM ops in pm_ptr() macro (Sashiko)
- use standard wait times with msleep() (Lukas Wunner)
- properly check errors for wake IRQs
- fix build failures /o\
Changes in v5:
- make PCIE_TEGRA264 symbol tristate
- drop dependency on PCI_MSI
- reorganize tegra264_pcie struct
- use standard wake-gpios property
- rename tegra264_pcie_bpmp_set_rp_state() to tegra264_pcie_power_off()
- use dev_err() instead of dev_info() for some error messages
- add clarifying comment as to why bandwidth requests aren't fatal
- address some compiler warnings on 32-bit physical address platforms
- drop needless comments
- explicitly deinitialize controller on suspend
- use devm_pm_runtime_active_enabled()
- rename "free" label to "free_ecam"
- use dev_err_probe() in more places
- reselect default pin state during resume, not probe
- return early on absence of wake GPIO
- simplify BW value calculation
Changes in v2:
- specify generations applicable for PCI_TEGRA driver to avoid confusion
- drop SPDX-FileCopyrightText tag
- rename link_state to link_up to clarify meaning
- replace memset() by an empty initializer
- sanity-check only enable BAR regions
- bring PCI link out of reset in case firmware didn't
- use common wait times instead of defining our own
- use core helpers to parse and print PCI link speed
- fix multi-line comment
- use dev_err_probe() more ubiquitously
- fix probe sequence and error cleanup
- use DEFINE_NOIRQ_DEV_PM_OPS() to avoid warnings for !PM_SUSPEND
- reuse more standard registers and remove unused register definitions
- use %pe and ERR_PTR() to print symbolic errors
- add signed-off-by from Manikanta as the original author
- add myself as author after significantly modifying the driver
pcie: remove pre-silicon conditionals
---
drivers/pci/controller/Kconfig | 10 +-
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pcie-tegra264.c | 538 +++++++++++++++++++++++++++++++++
3 files changed, 548 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 2247709ef6d6..3045c8aecc7e 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -255,7 +255,15 @@ config PCI_TEGRA
select IRQ_MSI_LIB
help
Say Y here if you want support for the PCIe host controller found
- on NVIDIA Tegra SoCs.
+ on NVIDIA Tegra SoCs (Tegra20 through Tegra186).
+
+config PCIE_TEGRA264
+ tristate "NVIDIA Tegra264 PCIe controller"
+ depends on ARCH_TEGRA || COMPILE_TEST
+ select PCI_ECAM
+ help
+ Say Y here if you want support for the PCIe host controller found
+ on NVIDIA Tegra264 SoCs.
config PCIE_RCAR_HOST
bool "Renesas R-Car PCIe controller (host mode)"
diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
index ac8db283f0fe..d478743b5142 100644
--- a/drivers/pci/controller/Makefile
+++ b/drivers/pci/controller/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PCI_HYPERV_INTERFACE) += pci-hyperv-intf.o
obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
obj-$(CONFIG_PCI_AARDVARK) += pci-aardvark.o
obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
+obj-$(CONFIG_PCIE_TEGRA264) += pcie-tegra264.o
obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
obj-$(CONFIG_PCIE_RCAR_HOST) += pcie-rcar.o pcie-rcar-host.o
obj-$(CONFIG_PCIE_RCAR_EP) += pcie-rcar.o pcie-rcar-ep.o
diff --git a/drivers/pci/controller/pcie-tegra264.c b/drivers/pci/controller/pcie-tegra264.c
new file mode 100644
index 000000000000..e2d295ea4403
--- /dev/null
+++ b/drivers/pci/controller/pcie-tegra264.c
@@ -0,0 +1,538 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * PCIe host controller driver for Tegra264 SoC
+ *
+ * Copyright (c) 2022-2026, NVIDIA CORPORATION. All rights reserved.
+ */
+
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/init.h>
+#include <linux/interconnect.h>
+#include <linux/interrupt.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of.h>
+#include <linux/of_pci.h>
+#include <linux/of_platform.h>
+#include <linux/pci-ecam.h>
+#include <linux/pci.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/pm_wakeirq.h>
+
+#include <soc/tegra/bpmp.h>
+#include <soc/tegra/bpmp-abi.h>
+#include <soc/tegra/fuse.h>
+
+#include "../pci.h"
+
+/* XAL registers */
+#define XAL_RC_ECAM_BASE_HI 0x00
+#define XAL_RC_ECAM_BASE_LO 0x04
+#define XAL_RC_ECAM_BUSMASK 0x08
+#define XAL_RC_IO_BASE_HI 0x0c
+#define XAL_RC_IO_BASE_LO 0x10
+#define XAL_RC_IO_LIMIT_HI 0x14
+#define XAL_RC_IO_LIMIT_LO 0x18
+#define XAL_RC_MEM_32BIT_BASE_HI 0x1c
+#define XAL_RC_MEM_32BIT_BASE_LO 0x20
+#define XAL_RC_MEM_32BIT_LIMIT_HI 0x24
+#define XAL_RC_MEM_32BIT_LIMIT_LO 0x28
+#define XAL_RC_MEM_64BIT_BASE_HI 0x2c
+#define XAL_RC_MEM_64BIT_BASE_LO 0x30
+#define XAL_RC_MEM_64BIT_LIMIT_HI 0x34
+#define XAL_RC_MEM_64BIT_LIMIT_LO 0x38
+#define XAL_RC_BAR_CNTL_STANDARD 0x40
+#define XAL_RC_BAR_CNTL_STANDARD_IOBAR_EN BIT(0)
+#define XAL_RC_BAR_CNTL_STANDARD_32B_BAR_EN BIT(1)
+#define XAL_RC_BAR_CNTL_STANDARD_64B_BAR_EN BIT(2)
+
+/* XTL registers */
+#define XTL_RC_PCIE_CFG_LINK_STATUS 0x5a
+
+#define XTL_RC_MGMT_PERST_CONTROL 0x218
+#define XTL_RC_MGMT_PERST_CONTROL_PERST_O_N BIT(0)
+
+#define XTL_RC_MGMT_CLOCK_CONTROL 0x47c
+#define XTL_RC_MGMT_CLOCK_CONTROL_PEX_CLKREQ_I_N_PIN_USE_CONV_TO_PRSNT BIT(9)
+
+struct tegra264_pcie {
+ struct device *dev;
+
+ /* I/O memory */
+ void __iomem *xal;
+ void __iomem *xtl;
+ void __iomem *ecam;
+
+ /* bridge configuration */
+ struct pci_config_window *cfg;
+ struct pci_host_bridge *bridge;
+
+ /* wake IRQ */
+ struct gpio_desc *wake_gpio;
+ unsigned int wake_irq;
+
+ /* BPMP and bandwidth management */
+ struct icc_path *icc_path;
+ struct tegra_bpmp *bpmp;
+ u32 ctl_id;
+
+ bool link_up;
+};
+
+static int tegra264_pcie_parse_dt(struct tegra264_pcie *pcie)
+{
+ struct device *dev = pcie->dev;
+ int err;
+
+ pcie->wake_gpio = devm_gpiod_get_optional(dev, "wake", GPIOD_IN);
+ if (IS_ERR(pcie->wake_gpio))
+ return PTR_ERR(pcie->wake_gpio);
+
+ if (!pcie->wake_gpio)
+ return 0;
+
+ err = gpiod_to_irq(pcie->wake_gpio);
+ if (err < 0)
+ return dev_err_probe(dev, err, "failed to get wake IRQ\n");
+
+ pcie->wake_irq = (unsigned int)err;
+
+ err = devm_device_init_wakeup(dev);
+ if (err < 0)
+ return dev_err_probe(dev, err, "failed to initialize wakeup\n");
+
+ err = devm_pm_set_wake_irq(dev, pcie->wake_irq);
+ if (err < 0)
+ return dev_err_probe(dev, err, "failed to set wakeup IRQ\n");
+
+ return 0;
+}
+
+static void tegra264_pcie_power_off(struct tegra264_pcie *pcie)
+{
+ struct tegra_bpmp_message msg = {};
+ struct mrq_pcie_request req = {};
+ int err;
+
+ req.cmd = CMD_PCIE_RP_CONTROLLER_OFF;
+ req.rp_ctrlr_off.rp_controller = pcie->ctl_id;
+
+ msg.mrq = MRQ_PCIE;
+ msg.tx.data = &req;
+ msg.tx.size = sizeof(req);
+
+ err = tegra_bpmp_transfer(pcie->bpmp, &msg);
+ if (err)
+ dev_err(pcie->dev, "failed to turn off PCIe #%u: %pe\n",
+ pcie->ctl_id, ERR_PTR(err));
+
+ if (msg.rx.ret)
+ dev_err(pcie->dev, "failed to turn off PCIe #%u: %d\n",
+ pcie->ctl_id, msg.rx.ret);
+}
+
+static void tegra264_pcie_icc_set(struct tegra264_pcie *pcie)
+{
+ u32 value, speed, width;
+ int err;
+
+ value = readw(pcie->ecam + XTL_RC_PCIE_CFG_LINK_STATUS);
+ speed = FIELD_GET(PCI_EXP_LNKSTA_CLS, value);
+ width = FIELD_GET(PCI_EXP_LNKSTA_NLW, value);
+
+ value = Mbps_to_icc(width * PCIE_SPEED2MBS_ENC(pcie_link_speed[speed]));
+
+ /*
+ * We don't want to error out here because a boot-critical device
+ * could be connected to this root port. Failure to set the bandwidth
+ * request may have an adverse impact on performance, but it is not
+ * generally fatal, so we opt to continue regardless so that users
+ * get a chance to fix things.
+ */
+ err = icc_set_bw(pcie->icc_path, value, value);
+ if (err < 0)
+ dev_err(pcie->dev,
+ "failed to request bandwidth (%u MBps): %pe\n",
+ value, ERR_PTR(err));
+}
+
+/*
+ * The various memory regions used by the controller (I/O, memory, ECAM) are
+ * set up during early boot and have hardware-level protections in place. If
+ * the DT ranges don't match what's been setup, the controller won't be able
+ * to write the address endpoints properly, so make sure to validate that DT
+ * and firmware programming agree on these ranges.
+ */
+static bool tegra264_pcie_check_ranges(struct platform_device *pdev)
+{
+ struct tegra264_pcie *pcie = platform_get_drvdata(pdev);
+ struct device_node *np = pcie->dev->of_node;
+ struct of_pci_range_parser parser;
+ phys_addr_t phys, limit, hi, lo;
+ struct of_pci_range range;
+ struct resource *res;
+ bool status = true;
+ u32 value;
+ int err;
+
+ err = of_pci_range_parser_init(&parser, np);
+ if (err < 0)
+ return false;
+
+ for_each_of_pci_range(&parser, &range) {
+ unsigned int addr_hi, addr_lo, limit_hi, limit_lo, enable;
+ unsigned long type = range.flags & IORESOURCE_TYPE_BITS;
+ phys_addr_t start, end, mask;
+ const char *region = NULL;
+
+ end = range.cpu_addr + range.size - 1;
+ start = range.cpu_addr;
+
+ switch (type) {
+ case IORESOURCE_IO:
+ addr_hi = XAL_RC_IO_BASE_HI;
+ addr_lo = XAL_RC_IO_BASE_LO;
+ limit_hi = XAL_RC_IO_LIMIT_HI;
+ limit_lo = XAL_RC_IO_LIMIT_LO;
+ enable = XAL_RC_BAR_CNTL_STANDARD_IOBAR_EN;
+ mask = SZ_64K - 1;
+ region = "I/O";
+ break;
+
+ case IORESOURCE_MEM:
+ if (range.flags & IORESOURCE_PREFETCH) {
+ addr_hi = XAL_RC_MEM_64BIT_BASE_HI;
+ addr_lo = XAL_RC_MEM_64BIT_BASE_LO;
+ limit_hi = XAL_RC_MEM_64BIT_LIMIT_HI;
+ limit_lo = XAL_RC_MEM_64BIT_LIMIT_LO;
+ enable = XAL_RC_BAR_CNTL_STANDARD_64B_BAR_EN;
+ region = "prefetchable memory";
+ } else {
+ addr_hi = XAL_RC_MEM_32BIT_BASE_HI;
+ addr_lo = XAL_RC_MEM_32BIT_BASE_LO;
+ limit_hi = XAL_RC_MEM_32BIT_LIMIT_HI;
+ limit_lo = XAL_RC_MEM_32BIT_LIMIT_LO;
+ enable = XAL_RC_BAR_CNTL_STANDARD_32B_BAR_EN;
+ region = "memory";
+ }
+
+ mask = SZ_1M - 1;
+ break;
+ }
+
+ /* not interested in anything that's not I/O or memory */
+ if (!region)
+ continue;
+
+ /* don't check regions that haven't been enabled */
+ value = readl(pcie->xal + XAL_RC_BAR_CNTL_STANDARD);
+ if ((value & enable) == 0)
+ continue;
+
+ hi = readl(pcie->xal + addr_hi);
+ lo = readl(pcie->xal + addr_lo);
+ phys = ((hi << 16) << 16) | lo;
+
+ hi = readl(pcie->xal + limit_hi);
+ lo = readl(pcie->xal + limit_lo);
+ limit = ((hi << 16) << 16) | lo | mask;
+
+ if (phys != start || limit != end) {
+ dev_err(pcie->dev,
+ "%s region mismatch: %pap-%pap -> %pap-%pap\n",
+ region, &phys, &limit, &start, &end);
+ status = false;
+ }
+ }
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam");
+ if (!res)
+ return false;
+
+ hi = readl(pcie->xal + XAL_RC_ECAM_BASE_HI);
+ lo = readl(pcie->xal + XAL_RC_ECAM_BASE_LO);
+ phys = ((hi << 16) << 16) | lo;
+
+ value = readl(pcie->xal + XAL_RC_ECAM_BUSMASK);
+ limit = phys + ((value + 1) << 20) - 1;
+
+ if (phys != res->start || limit != res->end) {
+ dev_err(pcie->dev,
+ "ECAM region mismatch: %pap-%pap -> %pap-%pap\n",
+ &phys, &limit, &res->start, &res->end);
+ status = false;
+ }
+
+ return status;
+}
+
+static bool tegra264_pcie_link_up(struct tegra264_pcie *pcie,
+ enum pci_bus_speed *speed)
+{
+ u16 value = readw(pcie->ecam + XTL_RC_PCIE_CFG_LINK_STATUS);
+
+ if (value & PCI_EXP_LNKSTA_DLLLA) {
+ if (speed)
+ *speed = pcie_link_speed[FIELD_GET(PCI_EXP_LNKSTA_CLS,
+ value)];
+
+ return true;
+ }
+
+ return false;
+}
+
+static void tegra264_pcie_init(struct tegra264_pcie *pcie)
+{
+ enum pci_bus_speed speed;
+ unsigned int i;
+ u32 value;
+
+ /* bring the endpoint out of reset */
+ value = readl(pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
+ value |= XTL_RC_MGMT_PERST_CONTROL_PERST_O_N;
+ writel(value, pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
+
+ for (i = 0; i < PCIE_LINK_WAIT_MAX_RETRIES; i++) {
+ if (tegra264_pcie_link_up(pcie, NULL))
+ break;
+
+ msleep(PCIE_LINK_WAIT_SLEEP_MS);
+ }
+
+ if (tegra264_pcie_link_up(pcie, &speed)) {
+ msleep(PCIE_RESET_CONFIG_WAIT_MS);
+ dev_info(pcie->dev, "PCIe #%u link is up (speed: %s)\n",
+ pcie->ctl_id, pci_speed_string(speed));
+ tegra264_pcie_icc_set(pcie);
+ pcie->link_up = true;
+ } else {
+ dev_info(pcie->dev, "PCIe #%u link is down\n", pcie->ctl_id);
+
+ value = readl(pcie->xtl + XTL_RC_MGMT_CLOCK_CONTROL);
+
+ /*
+ * Set link state only when link fails and no hot-plug feature
+ * is present.
+ */
+ if ((value & XTL_RC_MGMT_CLOCK_CONTROL_PEX_CLKREQ_I_N_PIN_USE_CONV_TO_PRSNT) == 0) {
+ dev_info(pcie->dev,
+ "PCIe #%u link is down and not hotplug-capable, turning off\n",
+ pcie->ctl_id);
+ tegra264_pcie_power_off(pcie);
+ pcie->link_up = false;
+ } else {
+ pcie->link_up = true;
+ }
+ }
+}
+
+static void tegra264_pcie_deinit(struct tegra264_pcie *pcie)
+{
+ u32 value;
+
+ /* take the endpoint into reset */
+ value = readl(pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
+ value &= ~XTL_RC_MGMT_PERST_CONTROL_PERST_O_N;
+ writel(value, pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
+}
+
+static int tegra264_pcie_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct pci_host_bridge *bridge;
+ struct tegra264_pcie *pcie;
+ struct resource_entry *bus;
+ struct resource *res;
+ int err;
+
+ bridge = devm_pci_alloc_host_bridge(dev, sizeof(struct tegra264_pcie));
+ if (!bridge)
+ return dev_err_probe(dev, -ENOMEM,
+ "failed to allocate host bridge\n");
+
+ pcie = pci_host_bridge_priv(bridge);
+ platform_set_drvdata(pdev, pcie);
+ pcie->bridge = bridge;
+ pcie->dev = dev;
+
+ err = tegra264_pcie_parse_dt(pcie);
+ if (err < 0)
+ return dev_err_probe(dev, err, "failed to parse device tree\n");
+
+ pcie->xal = devm_platform_ioremap_resource_byname(pdev, "xal");
+ if (IS_ERR(pcie->xal))
+ return dev_err_probe(dev, PTR_ERR(pcie->xal),
+ "failed to map XAL memory\n");
+
+ pcie->xtl = devm_platform_ioremap_resource_byname(pdev, "xtl-pri");
+ if (IS_ERR(pcie->xtl))
+ return dev_err_probe(dev, PTR_ERR(pcie->xtl),
+ "failed to map XTL-PRI memory\n");
+
+ bus = resource_list_first_type(&bridge->windows, IORESOURCE_BUS);
+ if (!bus)
+ return dev_err_probe(dev, -ENODEV,
+ "failed to get bus resources\n");
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam");
+ if (!res)
+ return dev_err_probe(dev, -ENXIO,
+ "failed to get ECAM resource\n");
+
+ pcie->icc_path = devm_of_icc_get(dev, "write");
+ if (IS_ERR(pcie->icc_path))
+ return dev_err_probe(dev, PTR_ERR(pcie->icc_path),
+ "failed to get ICC\n");
+
+ pcie->bpmp = tegra_bpmp_get_with_id(dev, &pcie->ctl_id);
+ if (IS_ERR(pcie->bpmp))
+ return dev_err_probe(dev, PTR_ERR(pcie->bpmp),
+ "failed to get BPMP\n");
+
+ err = devm_pm_runtime_set_active_enabled(dev);
+ if (err < 0) {
+ dev_err_probe(dev, err, "failed to enable runtime PM\n");
+ goto put_bpmp;
+ }
+
+ err = pm_runtime_get_sync(dev);
+ if (err < 0) {
+ dev_err_probe(dev, err, "failed to power on device\n");
+ goto put_bpmp;
+ }
+
+ /* sanity check that programmed ranges match what's in DT */
+ if (!tegra264_pcie_check_ranges(pdev)) {
+ err = -EINVAL;
+ goto put_pm;
+ }
+
+ pcie->cfg = pci_ecam_create(dev, res, bus->res, &pci_generic_ecam_ops);
+ if (IS_ERR(pcie->cfg)) {
+ err = dev_err_probe(dev, PTR_ERR(pcie->cfg),
+ "failed to create ECAM\n");
+ goto put_pm;
+ }
+
+ bridge->ops = (struct pci_ops *)&pci_generic_ecam_ops.pci_ops;
+ bridge->sysdata = pcie->cfg;
+ pcie->ecam = pcie->cfg->win;
+
+ tegra264_pcie_init(pcie);
+
+ if (!pcie->link_up)
+ return 0;
+
+ err = pci_host_probe(bridge);
+ if (err < 0) {
+ dev_err_probe(dev, err, "failed to register host\n");
+ goto free_ecam;
+ }
+
+ return 0;
+
+free_ecam:
+ pci_ecam_free(pcie->cfg);
+put_pm:
+ pm_runtime_put_sync(dev);
+put_bpmp:
+ tegra_bpmp_put(pcie->bpmp);
+
+ return err;
+}
+
+static void tegra264_pcie_remove(struct platform_device *pdev)
+{
+ struct tegra264_pcie *pcie = platform_get_drvdata(pdev);
+
+ /*
+ * If we undo tegra264_pcie_init() then link goes down and need
+ * controller reset to bring up the link again. Remove intention is
+ * to clean up the root bridge and re-enumerate during bind.
+ */
+ pci_lock_rescan_remove();
+ pci_stop_root_bus(pcie->bridge->bus);
+ pci_remove_root_bus(pcie->bridge->bus);
+ pci_unlock_rescan_remove();
+
+ pm_runtime_put_sync(&pdev->dev);
+ tegra_bpmp_put(pcie->bpmp);
+ pci_ecam_free(pcie->cfg);
+}
+
+static int tegra264_pcie_suspend(struct device *dev)
+{
+ struct tegra264_pcie *pcie = dev_get_drvdata(dev);
+ int err;
+
+ tegra264_pcie_deinit(pcie);
+
+ if (pcie->wake_gpio && device_may_wakeup(dev)) {
+ err = enable_irq_wake(pcie->wake_irq);
+ if (err < 0)
+ dev_err(dev, "failed to enable wake IRQ: %pe\n",
+ ERR_PTR(err));
+ }
+
+ return 0;
+}
+
+static int tegra264_pcie_resume(struct device *dev)
+{
+ struct tegra264_pcie *pcie = dev_get_drvdata(dev);
+ int err;
+
+ err = pinctrl_pm_select_default_state(dev);
+ if (err < 0)
+ dev_err(dev, "failed to configure sideband pins: %pe\n",
+ ERR_PTR(err));
+
+ if (pcie->wake_gpio && device_may_wakeup(dev)) {
+ err = disable_irq_wake(pcie->wake_irq);
+ if (err < 0)
+ dev_err(dev, "failed to disable wake IRQ: %pe\n",
+ ERR_PTR(err));
+ }
+
+ if (pcie->link_up == false)
+ return 0;
+
+ tegra264_pcie_init(pcie);
+
+ return 0;
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(tegra264_pcie_pm_ops,
+ tegra264_pcie_suspend,
+ tegra264_pcie_resume);
+
+static const struct of_device_id tegra264_pcie_of_match[] = {
+ {
+ .compatible = "nvidia,tegra264-pcie",
+ },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, tegra264_pcie_of_match);
+
+static struct platform_driver tegra264_pcie_driver = {
+ .probe = tegra264_pcie_probe,
+ .remove = tegra264_pcie_remove,
+ .driver = {
+ .name = "tegra264-pcie",
+ .pm = pm_ptr(&tegra264_pcie_pm_ops),
+ .of_match_table = tegra264_pcie_of_match,
+ },
+};
+module_platform_driver(tegra264_pcie_driver);
+
+MODULE_AUTHOR("Manikanta Maddireddy <mmaddireddy@nvidia.com>");
+MODULE_AUTHOR("Thierry Reding <treding@nvidia.com>");
+MODULE_DESCRIPTION("NVIDIA Tegra264 PCIe host controller driver");
+MODULE_LICENSE("GPL");
--
2.54.0
^ permalink raw reply related
* [PATCH v7 4/4] arm64: tegra: Reorder reg and reg-names to match bindings
From: Thierry Reding @ 2026-06-17 16:01 UTC (permalink / raw)
To: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Karthikeyan Mitran,
Hou Zhiqiang, Thomas Petazzoni, Pali Rohár, Michal Simek,
Kevin Xie, Thierry Reding, Aksh Garg
Cc: linux-pci, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, Thierry Reding
In-Reply-To: <20260617-tegra264-pcie-v7-0-eae7ae964629@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
The ECAM region cannot be the first entry in the "reg" property, because
in that case the unit-address wouldn't match the first entry. The order
of the nodes can also not be changed to match the ECAM entry because the
ECAM region is global and outside of any of the control busses.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v5:
- rebase onto v7.1-rc1
Changes in v4:
- revert ECAM "reg" entry order
Changes in v2:
- order ECAM "reg" entry before others
---
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 48 ++++++++++++++++----------------
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra264.dtsi b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
index 8f4350c7793b..4c701abd25a8 100644
--- a/arch/arm64/boot/dts/nvidia/tegra264.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
@@ -3513,11 +3513,11 @@ cmdqv4: cmdqv@b200000 {
pci@c000000 {
compatible = "nvidia,tegra264-pcie";
- reg = <0xd0 0xb0000000 0x0 0x10000000>,
- <0x00 0x0c000000 0x0 0x00004000>,
+ reg = <0x00 0x0c000000 0x0 0x00004000>,
<0x00 0x0c004000 0x0 0x00001000>,
- <0x00 0x0c005000 0x0 0x00001000>;
- reg-names = "ecam", "xal", "xtl", "xtl-pri";
+ <0x00 0x0c005000 0x0 0x00001000>,
+ <0xd0 0xb0000000 0x0 0x10000000>;
+ reg-names = "xal", "xtl", "xtl-pri", "ecam";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -3893,12 +3893,12 @@ gpio_uphy: gpio@8300000 {
pci@8400000 {
compatible = "nvidia,tegra264-pcie";
- reg = <0xa8 0xb0000000 0x0 0x10000000>,
- <0x00 0x08400000 0x0 0x00004000>,
+ reg = <0x00 0x08400000 0x0 0x00004000>,
<0x00 0x08404000 0x0 0x00001000>,
<0x00 0x08405000 0x0 0x00001000>,
- <0x00 0x08410000 0x0 0x00010000>;
- reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
+ <0x00 0x08410000 0x0 0x00010000>,
+ <0xa8 0xb0000000 0x0 0x10000000>;
+ reg-names = "xal", "xtl", "xtl-pri", "xpl", "ecam";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -3925,12 +3925,12 @@ pci@8400000 {
pci@8420000 {
compatible = "nvidia,tegra264-pcie";
- reg = <0xb0 0xb0000000 0x0 0x10000000>,
- <0x00 0x08420000 0x0 0x00004000>,
+ reg = <0x00 0x08420000 0x0 0x00004000>,
<0x00 0x08424000 0x0 0x00001000>,
<0x00 0x08425000 0x0 0x00001000>,
- <0x00 0x08430000 0x0 0x00010000>;
- reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
+ <0x00 0x08430000 0x0 0x00010000>,
+ <0xb0 0xb0000000 0x0 0x10000000>;
+ reg-names = "xal", "xtl", "xtl-pri", "xpl", "ecam";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -3957,12 +3957,12 @@ pci@8420000 {
pci@8440000 {
compatible = "nvidia,tegra264-pcie";
- reg = <0xb8 0xb0000000 0x0 0x10000000>,
- <0x00 0x08440000 0x0 0x00004000>,
+ reg = <0x00 0x08440000 0x0 0x00004000>,
<0x00 0x08444000 0x0 0x00001000>,
<0x00 0x08445000 0x0 0x00001000>,
- <0x00 0x08450000 0x0 0x00010000>;
- reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
+ <0x00 0x08450000 0x0 0x00010000>,
+ <0xb8 0xb0000000 0x0 0x10000000>;
+ reg-names = "xal", "xtl", "xtl-pri", "xpl", "ecam";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -3989,12 +3989,12 @@ pci@8440000 {
pci@8460000 {
compatible = "nvidia,tegra264-pcie";
- reg = <0xc0 0xb0000000 0x0 0x10000000>,
- <0x00 0x08460000 0x0 0x00004000>,
+ reg = <0x00 0x08460000 0x0 0x00004000>,
<0x00 0x08464000 0x0 0x00001000>,
<0x00 0x08465000 0x0 0x00001000>,
- <0x00 0x08470000 0x0 0x00010000>;
- reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
+ <0x00 0x08470000 0x0 0x00010000>,
+ <0xc0 0xb0000000 0x0 0x10000000>;
+ reg-names = "xal", "xtl", "xtl-pri", "xpl", "ecam";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -4021,12 +4021,12 @@ pci@8460000 {
pci@8480000 {
compatible = "nvidia,tegra264-pcie";
- reg = <0xc8 0xb0000000 0x0 0x10000000>,
- <0x00 0x08480000 0x0 0x00004000>,
+ reg = <0x00 0x08480000 0x0 0x00004000>,
<0x00 0x08484000 0x0 0x00001000>,
<0x00 0x08485000 0x0 0x00001000>,
- <0x00 0x08490000 0x0 0x00010000>;
- reg-names = "ecam", "xal", "xtl", "xtl-pri", "xpl";
+ <0x00 0x08490000 0x0 0x00010000>,
+ <0xc8 0xb0000000 0x0 0x10000000>;
+ reg-names = "xal", "xtl", "xtl-pri", "xpl", "ecam";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3 1/5] dt-bindings: iio: adc: Add ltc2378
From: Conor Dooley @ 2026-06-17 16:05 UTC (permalink / raw)
To: Marcelo Schmitt
Cc: linux-iio, devicetree, linux-kernel, jic23, nuno.sa,
Michael.Hennerich, dlechner, andy, robh, krzk+dt, conor+dt,
pop.ioan-daniel, marcelo.schmitt1
In-Reply-To: <f9e88abdbd23df8039282497a81d3c8698a10665.1781661028.git.marcelo.schmitt@analog.com>
[-- Attachment #1: Type: text/plain, Size: 6691 bytes --]
On Tue, Jun 16, 2026 at 11:03:11PM -0300, Marcelo Schmitt wrote:
> Document how to describe LTC2378-20 and similar ADCs in device tree.
>
> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> ---
> Change log v2 -> v3:
> - Re-added device tree fallback compatibles for LTC2378 chips, now with options
> to provide a single compatible string or a pair of single compatible string
> plus a fallback string to a slower sample rate spec in case a driver for the
> specific part is not found.
>
> .../bindings/iio/adc/adi,ltc2378.yaml | 160 ++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 167 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml
> new file mode 100644
> index 000000000000..7d30a2cade8f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ltc2378.yaml
> @@ -0,0 +1,160 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/adc/adi,ltc2378.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices LTC2378 and similar Analog to Digital Converters
> +
> +maintainers:
> + - Marcelo Schmitt <marcelo.schmitt@analog.com>
> +
> +description: |
> + Analog Devices LTC2378 series of ADCs.
> + Specifications can be found at:
> + https://www.analog.com/media/en/technical-documentation/data-sheets/233818fa.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/236416fa.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/236418f.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/236716fa.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/236718f.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/236816f.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/236818f.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/236918fa.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/237016fa.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/237616fa.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/237618fa.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/237620fb.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/237716fa.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/237718fa.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/237720fb.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/237816fa.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/237818fa.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/237820fb.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/237918fb.pdf
> + https://www.analog.com/media/en/technical-documentation/data-sheets/238016fb.pdf
> +
> +$ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +properties:
> + compatible:
> + oneOf:
> + # Single compatible string match.
> + - enum:
> + - adi,ltc2338-18
> + - adi,ltc2364-16
> + - adi,ltc2364-18
> + - adi,ltc2367-16
> + - adi,ltc2367-18
> + - adi,ltc2368-16
> + - adi,ltc2368-18
> + - adi,ltc2369-18
> + - adi,ltc2370-16
> + - adi,ltc2376-16
> + - adi,ltc2376-18
> + - adi,ltc2376-20
> + - adi,ltc2377-16
> + - adi,ltc2377-18
> + - adi,ltc2377-20
> + - adi,ltc2378-16
> + - adi,ltc2378-18
> + - adi,ltc2378-20
> + - adi,ltc2379-18
> + - adi,ltc2380-16
> +
> + # Low sample rate fallback for 16-bit unipolar sensors.
> + - items:
> + - enum:
> + - adi,ltc2370-16 # 2 MSPS
> + - adi,ltc2368-16 # 1 MSPS
> + - adi,ltc2367-16 # 500 kSPS
> + - const: adi,ltc2364-16 # fallback (250 kSPS)
Your driver still matches on ltc2370-16, which makes me question the
value of these fallbacks. That said, the chip info struct contains no
information about sampling rate. What actually is the impact of the
sample rate on the programming model?
Is there actually a benefit to matching on ltc2370-16, or can you just
match on the fallback?
+static const struct ltc2378_chip_info ltc2370_16_chip_info = {
+ .name = "ltc2370-16",
+ .resolution = 16,
+ .bipolar = false,
+};
+static const struct ltc2378_chip_info ltc2368_16_chip_info = {
+ .name = "ltc2368-16",
+ .resolution = 16,
+ .bipolar = false,
+};
+static const struct ltc2378_chip_info ltc2367_16_chip_info = {
+ .name = "ltc2367-16",
+ .resolution = 16,
+ .bipolar = false,
+};
+static const struct ltc2378_chip_info ltc2364_16_chip_info = {
+ .name = "ltc2364-16",
+ .resolution = 16,
+ .bipolar = false,
+};
All the devices have the same match data, other than the name, as the
fallback.
> +
> + # Low sample rate fallback for 18-bit unipolar sensors.
> + - items:
> + - enum:
> + - adi,ltc2369-18 # 1.6 MSPS
> + - adi,ltc2368-18 # 1 MSPS
> + - adi,ltc2367-18 # 500 kSPS
> + - const: adi,ltc2364-18 # fallback (250 kSPS)
> +
> + # Low sample rate fallback for 16-bit bipolar sensors.
> + - items:
> + - enum:
> + - adi,ltc2380-16 # 2 MSPS
> + - adi,ltc2378-16 # 1 MSPS
> + - adi,ltc2377-16 # 500 kSPS
> + - const: adi,ltc2376-16 # fallback (250 kSPS)
> +
> + # Low sample rate fallback for 18-bit bipolar sensors.
> + - items:
> + - enum:
> + - adi,ltc2379-18 # 1.6 MSPS
> + - adi,ltc2338-18 # 1 MSPS
> + - adi,ltc2378-18 # 1 MSPS
> + - adi,ltc2377-18 # 500 kSPS
> + - const: adi,ltc2376-18 # fallback (250 kSPS)
> +
> + # Low sample rate fallback for 20-bit bipolar sensors.
> + - items:
> + - enum:
> + - adi,ltc2378-20 # 1 MSPS
> + - adi,ltc2377-20 # 500 kSPS
> + - const: adi,ltc2376-20 # fallback (250 kSPS)
I didn't check these, but I assume they are the same.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v4 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings
From: Conor Dooley @ 2026-06-17 16:08 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260616-zx29clk-v4-1-ca994bd22e9d@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5389 bytes --]
On Tue, Jun 16, 2026 at 11:26:21PM +0300, Stefan Dösinger wrote:
> These SoCs have 3 clock and reset controllers: Top, Matrix and LSP. The
> separation of concerns between Top and Matrix and the interface between
> them is poorly defined in the hardware, so the bindings list all
> potential PLL clocks that might be passed between them.
>
> Generally every device has two clocks (one work clock, and one that
> connects it to the bus, I call it PCLK), two reset bits (I don't know
> what the difference is - sometimes asserting one is enough to reset the
> device, sometimes both need to be asserted). PCLK and WCLK are
> controlled by individual gates. Some devices have a mux and/or a
> divider for their work clock. Some devices, like the GPIO controller,
> only have reset bits and no clocks.
>
> The top clock controller is fed by a 26mhz external oscillator and has 4
> PLLs to generate other clock rates. ZTE's kernel mostly relies on the
> boot ROM to set up PLLs, but one LTE-Related PLL is not configured
> on some boards. Therefore my driver contains code to program PLLs. It
> produces identical settings as the boot ROM for the pre-programmed
> frequencies.
>
> Not all clocks will have an explicit user in the end. I am defining a
> lot of them simply to shut them off. The boot loader sets up a few of
> the proprietary timers, which will send regular IRQs (although the
> kernel of course doesn't need to listen to them). I don't plan to add a
> driver for the proprietary timer as I see no use for them - the ARM arch
> timer works just fine. I will add a driver for the very similar
> proprietary watchdog though.
>
> The clock list in this patch is pretty complete but not exhaustive.
> There are other bits that are enabled, but I couldn't deduce what they
> are controlling by trial and error. Some of them seem to do nothing.
> Others cause an instant hang of the board when disabled. It is quite
> likely that a handful more clocks will be added in the future, but not a
> large number.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
> ---
> .../bindings/clock/zte,zx297520v3-topclk.yaml | 70 ++++++++++++
> MAINTAINERS | 2 +
> include/dt-bindings/clock/zte,zx297520v3-clk.h | 118 +++++++++++++++++++++
> 3 files changed, 190 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/zte,zx297520v3-topclk.yaml b/Documentation/devicetree/bindings/clock/zte,zx297520v3-topclk.yaml
> new file mode 100644
> index 000000000000..374f63891288
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/zte,zx297520v3-topclk.yaml
> @@ -0,0 +1,70 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/zte,zx297520v3-topclk.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ZTE zx297520v3 SoC top clock and reset controller
> +
> +maintainers:
> + - Stefan Dösinger <stefandoesinger@gmail.com>
> +
> +description: |
> + The zx297520v3's top clock controller generates clocks for core devices on the
> + board like the main bus, USB and timers. In addition to clocks it has reset
> + controls for peripherals, a global board reset and watchdog reset controls.
> +
> + The controller has two clock inputs: a 26 MHz and a 32 KHz external
> + oscillator. They need to be provided as input clocks. The controller provides
> + clocks to the downstream Matrix clock controller.
> +
> + All available clocks are defined as preprocessor macros in the
> + 'dt-bindings/clock/zte,zx297520v3-clk.h' header.
> +
> +properties:
> + compatible:
> + items:
> + - const: zte,zx297520v3-topclk
> + - const: syscon
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: 26 MHz external oscillator
> + - description: 32 KHz external oscillator
> +
> + clock-names:
> + items:
> + - const: osc26m
> + - const: osc32k
> +
> + "#clock-cells":
> + const: 1
> +
> + "#reset-cells":
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - '#clock-cells'
> + - '#reset-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/zte,zx297520v3-clk.h>
> +
> + clock-controller@13b000 {
> + compatible = "zte,zx297520v3-topclk", "syscon";
> + reg = <0x0013b000 0x400>;
> + clocks = <&osc26m>, <&osc32k>;
> + clock-names = "osc26m", "osc32k";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8629ed2aa82f..0cc1ede3c80c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3867,8 +3867,10 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> S: Odd fixes
> F: Documentation/arch/arm/zte/
> F: Documentation/devicetree/bindings/arm/zte.yaml
> +F: Documentation/devicetree/zte,zx297520v3-*
Sashiko complaint here looks valid.
FWIW
/scripts/get_maintainer.pl --self-test=patterns
will catch these kinds of things.
pw-bot: changes-requested
Cheers,
Conor.
> F: arch/arm/boot/dts/zte/
> F: arch/arm/mach-zte/
> +F: include/dt-bindings/clock/zte,zx297520v3-clk.h
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v4 02/12] dt-bindings: clk: zte: Add zx297520v3 matrix clock and reset bindings
From: Conor Dooley @ 2026-06-17 16:11 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260616-zx29clk-v4-2-ca994bd22e9d@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3959 bytes --]
On Tue, Jun 16, 2026 at 11:26:22PM +0300, Stefan Dösinger wrote:
> I split matrixclk into its own controller again because syscon/regmap
> deals poorly with device nodes that have more than one memory region. As
> a consequence I am passing all PLL outputs generated on Topclk down to
> Matrixclk.
This type of commentary FWIW can go below the --- line and instead just
write a normal commit message.
I do appreciate though that you put the information in the individual
patch.
> The syscon is used to generate the regmap shared between the clock and
> auxiliary reset drivers. The register space also contains at least one
> extra block of functionality, hardware spinlocks, that I expect will be
> necessary to communicate correctly with the LTE DSP firmware blob.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
> ---
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/zte,zx297520v3-clk.h>
> +
> + topclk: clock-controller@13b000 {
> + compatible = "zte,zx297520v3-topclk", "syscon";
> + reg = <0x0013b000 0x400>;
> + clocks = <&osc26m>, <&osc32k>;
> + clock-names = "osc26m", "osc32k";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
This should be removed from here, the tooling will satisfy the topclk
references, just as it has done for osc26m and osc32k. The example
should just contain the node the binding documents (and its children).
pw-bot: changes-requested
Looks fine otherwise.
Cheers,
Conor.
> +
> + clock-controller@1306000 {
> + compatible = "zte,zx297520v3-matrixclk", "syscon";
> + reg = <0x01306000 0x400>;
> + clocks = <&osc26m>, <&osc32k>,
> + <&topclk ZX297520V3_MPLL>, <&topclk ZX297520V3_MPLL_D2>,
> + <&topclk ZX297520V3_MPLL_D3>, <&topclk ZX297520V3_MPLL_D4>,
> + <&topclk ZX297520V3_MPLL_D5>, <&topclk ZX297520V3_MPLL_D6>,
> + <&topclk ZX297520V3_MPLL_D8>, <&topclk ZX297520V3_MPLL_D12>,
> + <&topclk ZX297520V3_MPLL_D16>, <&topclk ZX297520V3_MPLL_D26>,
> + <&topclk ZX297520V3_UPLL>, <&topclk ZX297520V3_UPLL_D2>,
> + <&topclk ZX297520V3_UPLL_D3>, <&topclk ZX297520V3_UPLL_D4>,
> + <&topclk ZX297520V3_UPLL_D5>, <&topclk ZX297520V3_UPLL_D6>,
> + <&topclk ZX297520V3_UPLL_D8>, <&topclk ZX297520V3_UPLL_D12>,
> + <&topclk ZX297520V3_UPLL_D16>,
> + <&topclk ZX297520V3_DPLL>, <&topclk ZX297520V3_DPLL_D2>,
> + <&topclk ZX297520V3_DPLL_D3>, <&topclk ZX297520V3_DPLL_D4>,
> + <&topclk ZX297520V3_DPLL_D5>, <&topclk ZX297520V3_DPLL_D6>,
> + <&topclk ZX297520V3_DPLL_D8>, <&topclk ZX297520V3_DPLL_D12>,
> + <&topclk ZX297520V3_DPLL_D16>,
> + <&topclk ZX297520V3_GPLL>, <&topclk ZX297520V3_GPLL_D2>,
> + <&topclk ZX297520V3_GPLL_D3>, <&topclk ZX297520V3_GPLL_D4>,
> + <&topclk ZX297520V3_GPLL_D5>, <&topclk ZX297520V3_GPLL_D6>,
> + <&topclk ZX297520V3_GPLL_D8>, <&topclk ZX297520V3_GPLL_D12>,
> + <&topclk ZX297520V3_GPLL_D16>;
> + clock-names = "osc26m", "osc32k", "mpll", "mpll_d2", "mpll_d3",
> + "mpll_d4", "mpll_d5", "mpll_d6", "mpll_d8", "mpll_d12",
> + "mpll_d16", "mpll_d26", "upll", "upll_d2", "upll_d3",
> + "upll_d4", "upll_d5", "upll_d6", "upll_d8", "upll_d12",
> + "upll_d16", "dpll", "dpll_d2", "dpll_d3", "dpll_d4",
> + "dpll_d5", "dpll_d6", "dpll_d8", "dpll_d12", "dpll_d16",
> + "gpll", "gpll_d2", "gpll_d3", "gpll_d4", "gpll_d5",
> + "gpll_d6", "gpll_d8", "gpll_d12", "gpll_d16";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v4 03/12] dt-bindings: clk: zte: Add zx297520v3 LSP clock and reset bindings
From: Conor Dooley @ 2026-06-17 16:12 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260616-zx29clk-v4-3-ca994bd22e9d@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3599 bytes --]
On Tue, Jun 16, 2026 at 11:26:23PM +0300, Stefan Dösinger wrote:
> +
> + matrixclk: clock-controller@1306000 {
> + compatible = "zte,zx297520v3-matrixclk", "syscon";
> + reg = <0x01306000 0x400>;
> + clocks = <&osc26m>, <&osc32k>,
> + <&topclk ZX297520V3_MPLL>, <&topclk ZX297520V3_MPLL_D2>,
> + <&topclk ZX297520V3_MPLL_D3>, <&topclk ZX297520V3_MPLL_D4>,
> + <&topclk ZX297520V3_MPLL_D5>, <&topclk ZX297520V3_MPLL_D6>,
> + <&topclk ZX297520V3_MPLL_D8>, <&topclk ZX297520V3_MPLL_D12>,
> + <&topclk ZX297520V3_MPLL_D16>, <&topclk ZX297520V3_MPLL_D26>,
> + <&topclk ZX297520V3_UPLL>, <&topclk ZX297520V3_UPLL_D2>,
> + <&topclk ZX297520V3_UPLL_D3>, <&topclk ZX297520V3_UPLL_D4>,
> + <&topclk ZX297520V3_UPLL_D5>, <&topclk ZX297520V3_UPLL_D6>,
> + <&topclk ZX297520V3_UPLL_D8>, <&topclk ZX297520V3_UPLL_D12>,
> + <&topclk ZX297520V3_UPLL_D16>,
> + <&topclk ZX297520V3_DPLL>, <&topclk ZX297520V3_DPLL_D2>,
> + <&topclk ZX297520V3_DPLL_D3>, <&topclk ZX297520V3_DPLL_D4>,
> + <&topclk ZX297520V3_DPLL_D5>, <&topclk ZX297520V3_DPLL_D6>,
> + <&topclk ZX297520V3_DPLL_D8>, <&topclk ZX297520V3_DPLL_D12>,
> + <&topclk ZX297520V3_DPLL_D16>,
> + <&topclk ZX297520V3_GPLL>, <&topclk ZX297520V3_GPLL_D2>,
> + <&topclk ZX297520V3_GPLL_D3>, <&topclk ZX297520V3_GPLL_D4>,
> + <&topclk ZX297520V3_GPLL_D5>, <&topclk ZX297520V3_GPLL_D6>,
> + <&topclk ZX297520V3_GPLL_D8>, <&topclk ZX297520V3_GPLL_D12>,
> + <&topclk ZX297520V3_GPLL_D16>;
> + clock-names = "osc26m", "osc32k", "mpll", "mpll_d2", "mpll_d3",
> + "mpll_d4", "mpll_d5", "mpll_d6", "mpll_d8", "mpll_d12",
> + "mpll_d16", "mpll_d26", "upll", "upll_d2", "upll_d3",
> + "upll_d4", "upll_d5", "upll_d6", "upll_d8", "upll_d12",
> + "upll_d16", "dpll", "dpll_d2", "dpll_d3", "dpll_d4",
> + "dpll_d5", "dpll_d6", "dpll_d8", "dpll_d12", "dpll_d16",
> + "gpll", "gpll_d2", "gpll_d3", "gpll_d4", "gpll_d5",
> + "gpll_d6", "gpll_d8", "gpll_d12", "gpll_d16";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> + clock-controller@1400000 {
> + compatible = "zte,zx297520v3-lspclk";
> + reg = <0x01400000 0x100>;
> + clocks = <&matrixclk ZX297520V3_LSP_MPLL_D5_WCLK>,
> + <&matrixclk ZX297520V3_LSP_MPLL_D4_WCLK>,
> + <&matrixclk ZX297520V3_LSP_MPLL_D6_WCLK>,
> + <&matrixclk ZX297520V3_LSP_MPLL_D8_WCLK>,
> + <&matrixclk ZX297520V3_LSP_MPLL_D12_WCLK>,
> + <&matrixclk ZX297520V3_LSP_OSC26M_WCLK>,
> + <&matrixclk ZX297520V3_LSP_OSC32K_WCLK>,
> + <&matrixclk ZX297520V3_LSP_PCLK>,
> + <&matrixclk ZX297520V3_LSP_TDM_WCLK>,
> + <&matrixclk ZX297520V3_LSP_DPLL_D4_WCLK>;
> + clock-names = "mpll_d5", "mpll_d4", "mpll_d6", "mpll_d8", "mpll_d12",
> + "osc26m", "osc32k", "pclk", "tdm_wclk", "dpll_d4";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
Same comment here on what's in scope.
pw-bot: changes-requested
Otherwise, once again, looks okay.
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v9 3/3] riscv: clocksource: Add p8700-gcru driver
From: Julian Braha @ 2026-06-17 16:17 UTC (permalink / raw)
To: aleksa.paunovic, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Paul Walmsley, John Stultz,
Stephen Boyd, Vivian Wang
Cc: linux-kernel, devicetree, linux-riscv, Djordje Todorovic,
Chao-ying Fu
In-Reply-To: <20260616-riscv-time-mmio-v9-3-03af7bc8f2d8@htecgroup.com>
Hi Aleksa,
On 6/16/26 17:03, Aleksa Paunovic via B4 Relay wrote:
> +config P8700_TIMER
> + bool "MIPS P8700 timer driver"
> + depends on GENERIC_SCHED_CLOCK && RISCV && RISCV_SBI && 64BIT
> + select CLKSRC_MMIO
> + select TIMER_PROBE
> + select TIMER_OF
You don't need to select TIMER_OF here, it's already enabled by
TIMER_PROBE. You could consider using a comment there, if you'd like.
- Julian Braha
^ permalink raw reply
* Re: [PATCH v12 1/7] i3c: master: Add APIs for I3C hub support
From: Frank Li @ 2026-06-17 16:18 UTC (permalink / raw)
To: sashiko-reviews
Cc: Lakshay Piplani, Frank.Li, linux-i3c, conor+dt, devicetree, robh
In-Reply-To: <20260617112035.86E7E1F000E9@smtp.kernel.org>
On Wed, Jun 17, 2026 at 11:20:35AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Critical] Bypassing core state tracking in `direct_attach` / `direct_detach` causes Use-After-Free, NULL pointer dereferences, and Memory Leaks.
> - [High] Bypassing address slot reservation in `direct_attach` leads to unrecoverable I3C bus address collisions.
> --
>
> commit ce08f4a6bc0d82c966d4e3337e6b4d082a9d09d2
> Author: Aman Kumar Pandey <aman.kumarpandey@nxp.com>
>
> i3c: master: Add APIs for I3C hub support
>
> This commit introduces helper functions for attaching and detaching I3C
> devices, alongside CCC command helpers. These additions prepare the core
> framework for handling I3C hubs.
>
> > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> > --- a/drivers/i3c/master.c
> > +++ b/drivers/i3c/master.c
> > @@ -1775,6 +1775,70 @@ static int i3c_master_attach_i3c_dev(struct i3c_master_controller *master,
>
> [ ... ]
>
> > +int i3c_master_direct_attach_i3c_dev_locked(struct i3c_master_controller *master,
> > + struct i3c_dev_desc *dev)
> > +{
> > + int ret = 0;
> > +
> > + /*
> > + * We don't attach devices to the controller until they are
> > + * addressable on the bus.
> > + */
> > +
> > + if (!dev->info.static_addr && !dev->info.dyn_addr)
> > + return 0;
> > +
> > + /* Do not attach the master device itself. */
> > + if (master->this != dev && master->ops->attach_i3c_dev)
> > + ret = master->ops->attach_i3c_dev(dev);
>
> [Severity: High]
> Does bypassing address slot reservation here lead to I3C bus collisions?
>
> In the standard attachment flow, i3c_master_get_i3c_addrs() is called to
> reserve the address slot in the controller's bus.addrslots bitmap. Because
> this direct helper skips that reservation, the parent controller's address
> map is never updated to reflect the newly occupied address.
>
> Since the parent controller and the virtual hub share the physical I3C bus,
> the parent might still believe the downstream device's address is free. If
> a new device hot-joins, could the parent controller allocate the exact same
> address, resulting in an unrecoverable address collision?
Should check address before attached.
>
> > +
> > + return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(i3c_master_direct_attach_i3c_dev_locked);
> > +
> > +/**
> > + * i3c_master_direct_detach_i3c_dev_locked() - Detach an I3C device from its
> > + * master controller.
>
> [ ... ]
>
> > +void i3c_master_direct_detach_i3c_dev_locked(struct i3c_dev_desc *dev)
> > +{
> > + struct i3c_master_controller *master = i3c_dev_get_master(dev);
> > +
> > + /*
> > + * We don't attach devices to the controller until they are
> > + * addressable on the bus, so skip detach for unaddressed devices.
> > + */
> > + if (!dev->info.static_addr && !dev->info.dyn_addr)
> > + return;
> > +
> > + /* Do not detach the master device itself. */
> > + if (master->this != dev && master->ops->detach_i3c_dev)
> > + master->ops->detach_i3c_dev(dev);
>
> [Severity: Critical]
> Can this lead to a use-after-free or a NULL pointer dereference by bypassing
> the core state tracking?
>
> When i3c_master_direct_detach_i3c_dev_locked() invokes the controller's
> detach callback, master drivers typically free the master_priv data. However,
> the dev->common.master_priv pointer is never cleared here.
It'd better clean it and free dyn_addr.
Frank
>
> If i3c_hub_free_ibi() calls this detach helper, and later a transfer is sent
> via i3c_hub_master_priv_xfers():
>
> drivers/i3c/hub.c:i3c_hub_master_priv_xfers() {
> ...
> xfer_ret = i3c_master_priv_xfers(dev, xfers, nxfers, mode);
> ...
> }
>
> Will the parent controller end up dereferencing the freed master_priv
> pointer?
>
> Additionally, if a device is never explicitly attached via the direct helper
> (leaving master_priv NULL), would a standard transfer immediately cause a
> NULL pointer dereference when forwarded to the parent driver?
>
> > +}
> > +EXPORT_SYMBOL_GPL(i3c_master_direct_detach_i3c_dev_locked);
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260617110355.1591844-1-lakshay.piplani@nxp.com?part=1
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
From: Gerald Loacker @ 2026-06-17 16:20 UTC (permalink / raw)
To: Conor Dooley
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel, devicetree
In-Reply-To: <20260617-deviate-sulk-c57104ef939f@spud>
Hi Conor,
Am 17.06.2026 um 17:51 schrieb Conor Dooley:
> On Wed, Jun 17, 2026 at 02:23:14PM +0200, Gerald Loacker wrote:
>> Add support for the optional rockchip,clk-lane-phase device tree property
>> to allow board-specific tuning of the clock lane sampling phase for
>> improved signal integrity across supported data rates.
>>
>> Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
>> ---
>> Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
>> index 03950b3cad08c..0d824d1511bc0 100644
>> --- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
>> +++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
>> @@ -56,6 +56,13 @@ properties:
>> description:
>> Some additional phy settings are access through GRF regs.
>>
>> + rockchip,clk-lane-phase:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + minimum: 0
>> + maximum: 7
>> + description:
>> + Clock lane sampling phase in 40 ps steps. The hardware default is 3.
>
> Can this instead become rockchip,clk-lane-phase-ps and be listed in the
> actual unit?
> With the -ps suffix, you can then drop the $ref.
> The default should be listed as "default: 3" (or default: 120)
>
> pw-bot: changes-requested
>
Thanks for the suggestion.
The phase setting is a hardware tap index (0–7) selecting a delay line
position. The datasheet mentions “about 40 ps” per step, but this is not
a calibrated or guaranteed value and may vary with PVT.
Because of that, I’d prefer to keep the property as an index and
document the approximate delay in the description:
Clock lane sampling phase selection (hardware tap index 0–7). Each step
corresponds to an approximately 40 ps delay as described in the hardware
specification.
This matches the hardware model more closely. Happy to adjust if needed.
>> +
>> required:
>> - compatible
>> - reg
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH v2 3/6] arm64: dts: qcom: kodiak: Add GEM_NOC interconnect for adreno SMMU
From: Bibek Kumar Patro @ 2026-06-17 16:20 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <zhdacu4upv5kyvyqx5hcm6im4p7r3z5bsnup7hqu2okxyxmeib@snpseurpvhtc>
On 6/16/2026 5:49 AM, Dmitry Baryshkov wrote:
> On Mon, Jun 08, 2026 at 08:07:07PM +0530, Bibek Kumar Patro wrote:
>>
>>
>> On 6/8/2026 7:27 PM, Dmitry Baryshkov wrote:
>>> On Tue, May 26, 2026 at 08:12:04PM +0530, Bibek Kumar Patro wrote:
>>>> On Kodiak platforms, the Adreno SMMU requires a bandwidth vote on
>>>> the GEM_NOC path (MASTER_GPU_TCU -> SLAVE_EBI1) before its registers
>>>> are accessible. Without this vote, the SMMU may become unreachable,
>>>> leading to intermittent probe failures and runtime issues.
>>>>
>>>> Add the required interconnect to ensure reliable register access.
>>>
>>> Does it only concern the GPU SMMU? What about the APPS SMMU? Should it
>>> be voting on other interconnects too? I guess so, because currently I
>>> see that TBUs vote for various interconnects. BTW: should apps_smmu also
>>> vote on the power domains?
>>>
>>
>> This race mainly occurs in GPU SMMU, where the GDSC can have an
>> independent vote on the Adreno SMMU. However, the GEM_NOC vote may
>> already have been removed by the GPU (or any consumer of adreno_smmu,
>> e.g gmu), unless it is explicitly voted by the GPU SMMU (which acts as a
>> supplier for the GPU). This mismatch can lead to SHUB timeouts or NoC
>> errors.
>>
>> Mostly this race reported in suspend/resume cycle (when gpu/gmu devices
>> moves to slumber/suspend state before adreno_smmu powers down
>> and the later doesn't have explicit interconnect voting).
>>
>> In the case of APPS SMMU, such a race is not expected for any known
>> use case. APPS SMMU is part of a shared infrastructure block, and its
>> power is typically kept enabled as long as attached master devices are
>> active. Therefore, explicit power-domain voting from APPS SMMU may not
>> be required.
>
> This looks like a good part of the commit message. Please add it where
> it belongs.
>
Ack, thanks for this suggestion. It seems like i haven't explained this
specific info in any of the patches in this series.
Will take care of this in the next revision.
Thanks & regards,
Bibek
>>
>> Thanks,
>> Bibek
>>
>>
>>>>
>>>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> index fa540d8c2615dc02d941eb16bc7253204c2750bd..eefa4b836a81374ff437ab4bbcbc3fecc1590ab6 100644
>>>> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> @@ -3386,6 +3386,8 @@ adreno_smmu: iommu@3da0000 {
>>>> power-domains = <&gpucc GPU_CC_CX_GDSC>;
>>>> dma-coherent;
>>>> + interconnects = <&gem_noc MASTER_GPU_TCU QCOM_ICC_TAG_ALWAYS
>>>> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
>>>> };
>>>> gfx_0_tbu: tbu@3dd9000 {
>>>>
>>>> --
>>>> 2.34.1
>>>>
>>>
>>
>
^ permalink raw reply
* Re: [PATCH v8 2/5] iio: adc: add Versal SysMon driver
From: Erim, Salih @ 2026-06-17 16:23 UTC (permalink / raw)
To: Andy Shevchenko
Cc: jic23, andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt,
conall.ogriofa, michal.simek, linux, erimsalih, linux-iio,
devicetree, linux-kernel
In-Reply-To: <ajK0phP9-pt9njrb@ashevche-desk.local>
Hi Andy,
On 17/06/2026 15:52, Andy Shevchenko wrote:
> On Tue, Jun 16, 2026 at 02:15:56PM +0100, Salih Erim wrote:
>> Add the core driver and MMIO platform driver for the AMD/Xilinx Versal
>> System Monitor (SysMon) block.
>>
>> The SysMon block resides in the platform management controller (PMC) and
>> provides on-chip voltage and temperature monitoring through a 10-bit,
>> 200 kSPS ADC. It can monitor up to 160 voltage channels and 64
>> temperature satellites distributed across the SoC, with a consistent
>> sample rate of 8 kSPS per channel regardless of how many channels are
>> enabled.
>>
>> The hardware also provides four aggregate temperature registers that
>> are always present regardless of the device tree configuration: the
>> current max and min across all active satellites, and the peak and
>> trough values recorded since the last hardware reset.
>>
>> The driver is split into two compilation units:
>> - versal-sysmon-core: Channel parsing, IIO registration, read_raw
>> - versal-sysmon: MMIO platform driver with custom regmap accessors
>>
>> Voltage results are stored in a 19-bit modified floating-point format
>> and converted to millivolts. Temperature results are stored in Q8.7
>> signed fixed-point Celsius format and converted to millicelsius.
>>
>> The MMIO regmap backend uses a custom reg_write accessor that
>> automatically unlocks the NPI (NoC programming interface) lock
>> register before each write, as required by the hardware. The regmap
>> is configured with fast_io since the underlying MMIO accessors are
>> safe to call from atomic context.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>
> with a caveat of using namespaced exports (see below).
Thank you for the review!
>
> ...
>
>> +EXPORT_SYMBOL_GPL(devm_versal_sysmon_core_probe);
>
> Please, also use symbol namespace.
Will use EXPORT_SYMBOL_NS_GPL(devm_versal_sysmon_core_probe,
"VERSAL_SYSMON") and add MODULE_IMPORT_NS("VERSAL_SYSMON") to both
platform and I2C drivers.
>
> ...
>
>> +static int sysmon_mmio_reg_read(void *context, unsigned int reg,
>> + unsigned int *val)
>
> Make it a single line. It will be more readable.
>
> static int sysmon_mmio_reg_read(void *context, unsigned int reg, unsigned int *val)
Done.
>
> ...
>
>> +static int sysmon_mmio_reg_write(void *context, unsigned int reg,
>> + unsigned int val)
>
> In the similar way.
>
> static int sysmon_mmio_reg_write(void *context, unsigned int reg, unsigned int val)
Done.
Thanks,
Salih
>
> In both cases it's only 83 characters.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v8 3/5] iio: adc: versal-sysmon: add I2C driver
From: Erim, Salih @ 2026-06-17 16:24 UTC (permalink / raw)
To: Andy Shevchenko
Cc: jic23, andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt,
conall.ogriofa, michal.simek, linux, erimsalih, linux-iio,
devicetree, linux-kernel
In-Reply-To: <ajK0-KmjxDPW_g4M@ashevche-desk.local>
Hi,
On 17/06/2026 15:53, Andy Shevchenko wrote:
> On Tue, Jun 16, 2026 at 02:15:57PM +0100, Salih Erim wrote:
>> Add an I2C transport driver for the Versal SysMon block. The SysMon
>> provides an I2C slave interface that allows an external master to
>> read voltage and temperature measurements through the same register
>> map used by the MMIO path.
>>
>> The I2C command frame is an 8-byte structure containing a 4-byte data
>> payload, a 2-byte register offset, and a 1-byte instruction field.
>> Read operations send the frame with a read instruction, then receive
>> a 4-byte response containing the register value.
>>
>> Events are not supported on the I2C path because there is no
>> interrupt line and the I2C regmap backend cannot be called from
>> atomic context.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Thank you!
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v3 4/5] iio: adc: ltc2378: Enable high-speed data capture
From: Julian Braha @ 2026-06-17 16:26 UTC (permalink / raw)
To: Marcelo Schmitt, linux-iio, devicetree, linux-kernel
Cc: jic23, nuno.sa, Michael.Hennerich, dlechner, andy, robh, krzk+dt,
conor+dt, pop.ioan-daniel, marcelo.schmitt1
In-Reply-To: <9f173c47928446aa3e900cf0becb6130dd76846b.1781661028.git.marcelo.schmitt@analog.com>
Hi Marcelo,
On 6/17/26 03:04, Marcelo Schmitt wrote:
> + select LTC2378_LIB_OFFLOAD_BUFFER if SPI_OFFLOAD && PWM && SPI_OFFLOAD_TRIGGER_PWM && IIO_BUFFER && IIO_BUFFER_DMAENGINE
The PWM in this expression is unnecessary since you're && it with
SPI_OFFLOAD_TRIGGER_PWM.
- Julian Braha
^ permalink raw reply
* Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Bibek Kumar Patro @ 2026-06-17 16:32 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <2i6yzwu2yk5bngq723g75yeqzeg4ihvtbuydzunceltl526tjp@vnt6nmxxkfut>
On 6/16/2026 5:52 AM, Dmitry Baryshkov wrote:
> On Mon, Jun 15, 2026 at 06:55:45PM +0530, Bibek Kumar Patro wrote:
>>
>>
>> On 6/8/2026 7:25 PM, Dmitry Baryshkov wrote:
>>> On Tue, May 26, 2026 at 08:12:03PM +0530, Bibek Kumar Patro wrote:
>>>> On some SoCs the SMMU registers require an active interconnect
>>>> bandwidth vote to be accessible. While other clients typically
>>>> satisfy this requirement implicitly, certain corner cases (e.g.
>>>> during sleep/wakeup transitions) can leave the SMMU without a
>>>> vote, causing intermittent register access failures.
>>>>
>>>> Add support for an optional interconnect path to the arm-smmu
>>>> driver and vote for bandwidth while the SMMU is active. The path
>>>> is acquired from DT if present and ignored otherwise.
>>>>
>>>> The bandwidth vote is enabled before accessing SMMU registers
>>>> during probe and runtime resume, and released during runtime
>>>> suspend and on error paths.
>>>>
>>>> Generally, from an architectural perspective, GEM_NOC and DDR are
>>>> expected to have an active vote whenever the adreno_smmu block is
>>>> powered on. In most common use cases, this requirement is implicitly
>>>> satisfied because other GPU-related clients (for example, the GMU
>>>> device) already hold a GEM_NOC vote when adreno_smmu is enabled.
>>>>
>>>> However, there are certain corner cases, such as during sleep/wakeup
>>>> transitions, where the GEM_NOC vote can be removed before adreno_smmu
>>>> is powered down. If adreno_smmu is then accessed while the interconnect
>>>> vote is missing, it can lead to the observed failures. Because of the
>>>> precise ordering involved, this scenario is difficult to reproduce
>>>> consistently.
>>>> (also GDSC is involved in adreno usecases can have an independent vote)
>>>>
>>>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>>> ---
>>>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 57 +++++++++++++++++++++++++++++++++--
>>>> drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 ++
>>>> 2 files changed, 57 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>> index 0bd21d206eb3e75c3b9fb1364cdc92e82c5aa499..07c7e44ec6a5bd1488f00f87d859a20495e46601 100644
>>>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>>>> @@ -53,6 +53,11 @@
>>>> #define MSI_IOVA_BASE 0x8000000
>>>> #define MSI_IOVA_LENGTH 0x100000
>>>> +/* Interconnect bandwidth vote values for the SMMU register access path */
>>>> +#define ARM_SMMU_ICC_AVG_BW 0
>>>> +#define ARM_SMMU_ICC_PEAK_BW_HIGH 1000
>>>
>>> totally random numbers, which might be different for non-Qualcomm platform.
>>>
>>>> +#define ARM_SMMU_ICC_PEAK_BW_LOW 0
>>>> +
>>>> static int force_stage;
>>>> module_param(force_stage, int, S_IRUGO);
>>>> MODULE_PARM_DESC(force_stage,
>>>> @@ -86,6 +91,36 @@ static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu)
>>>> }
>>>> }
>>>> +static int arm_smmu_icc_get(struct arm_smmu_device *smmu)
>>>> +{
>>>> + smmu->icc_path = devm_of_icc_get(smmu->dev, NULL);
>>>
>>> Is there always only one bus / path in question?
>>>
>>
>> <Apologies, missed to respond to this query>
>> Yes for TCU, it needs to only have a vote on GEM_NOC interconnect
>> while accessing the DDR in downstream path (client->TCU->DDR), which we are
>> addressing here.
>> Hence it's only one icc path in question here.
>
> Again, you are describing Qualcomm platform, while the code part is
> generic.
>
ah yes, single icc path is specific to Qualcomm platforms as of now.
As per my assumption, it's possible for other vendors/ARM-SMMU users to
have one or more than one icc path to reach DDR in downstream flow
(similar to clocks).
I will revisit the logic for icc_voting to check for possibility on
additional icc path as well, so the generic code can cater to other arm-
smmu users.
Thanks & regards,
Bibek
>
^ permalink raw reply
* Re: [PATCH v2 3/3] irqchip/qcom-pdc: Add puwra compatible for PDC secondary mode
From: Thomas Gleixner @ 2026-06-17 16:32 UTC (permalink / raw)
To: Maulik Shah, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, devicetree, Konrad Dybcio,
Maulik Shah
In-Reply-To: <20260616-purwa-pdc-v2-3-8dda7ef25ce5@oss.qualcomm.com>
On Tue, Jun 16 2026 at 15:57, Maulik Shah wrote:
> --- a/drivers/irqchip/qcom-pdc.c
> +++ b/drivers/irqchip/qcom-pdc.c
> @@ -704,7 +704,10 @@ static int qcom_pdc_probe(struct platform_device *pdev, struct device_node *pare
> }
>
> pdc->x1e_quirk = true;
> + }
>
> + if (of_device_is_compatible(node, "qcom,x1e80100-pdc") ||
> + of_device_is_compatible(node, "qcom,x1p42100-pdc")) {
> if (!qcom_scm_is_available())
> return -EPROBE_DEFER;
Bah. Can you please prominently tell in the cover letter that the series
has dependencies on some other series instead of hiding that information
in a lump of sha1 references which do not exist for me?
^ permalink raw reply
* Re: [PATCH v8 4/5] iio: adc: versal-sysmon: add threshold event support
From: Erim, Salih @ 2026-06-17 16:34 UTC (permalink / raw)
To: Andy Shevchenko
Cc: jic23, andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt,
conall.ogriofa, michal.simek, linux, erimsalih, linux-iio,
devicetree, linux-kernel
In-Reply-To: <ajK_kmZMfdLaVyIj@ashevche-desk.local>
Hi Andy,
All accepted, all will be fixed in v9.
On 17/06/2026 16:38, Andy Shevchenko wrote:
> On Tue, Jun 16, 2026 at 02:15:58PM +0100, Salih Erim wrote:
>> Add threshold event support for temperature and supply voltage
>> channels.
>>
>> Temperature events:
>> - Rising threshold with configurable value on the device
>> temperature channel (current max across all satellites)
>> - Per-channel hysteresis as a millicelsius value
>> - Event direction is IIO_EV_DIR_RISING (hysteresis mode)
>>
>> Supply voltage events:
>> - Rising/falling threshold per supply channel
>> - Per-channel alarm enable via alarm configuration registers
>>
>> The hardware supports both window and hysteresis alarm modes for
>> temperature. This driver uses hysteresis mode, where the upper
>> threshold triggers the alarm and the lower threshold clears it
>> (re-arm point). The hardware has a single ISR bit per temperature
>> channel with no indication of which threshold was crossed, so
>> hysteresis mode is the natural fit. The lower threshold register
>> is computed internally as (upper - hysteresis).
>>
>> Hysteresis is stored in the driver as a millicelsius value,
>> initialized from the hardware registers at probe. Writing the
>> rising threshold or hysteresis recomputes the lower register.
>> ALARM_CONFIG is hard-coded to hysteresis mode during init.
>>
>> The hardware also provides a separate over-temperature (OT)
>> threshold, but it is not exposed through IIO as it serves as a
>> hardware safety mechanism for platform shutdown. OT will be
>> exposed through the thermal framework in a follow-up series.
>>
>> The interrupt handler masks active threshold interrupts (which are
>> level-sensitive) and schedules a delayed worker to poll for condition
>> clear before unmasking. When no hardware IRQ is available, event
>> specs are not attached and interrupt init is skipped, since the
>> I2C regmap backend cannot be called from atomic context.
>>
>> When disabling a supply channel alarm, the group interrupt remains
>> active if any other channel in the same alarm group still has an
>> alarm enabled.
>>
>> A devm cleanup action masks all interrupts on driver unbind to
>> prevent unhandled interrupt storms after the IRQ handler is freed.
>
> ...
>
>> +static void sysmon_supply_processedtoraw(int val, u32 reg_val, u32 *raw_data)
>> +{
>> + int exponent = FIELD_GET(SYSMON_MODE_MASK, reg_val);
>> + int format = FIELD_GET(SYSMON_FMT_MASK, reg_val);
>> + int scale, tmp;
>> +
>> + scale = BIT(SYSMON_SUPPLY_MANTISSA_BITS - exponent);
>> + tmp = (val * scale) / (int)MILLI;
>> +
>> + if (format)
>> + tmp = clamp(tmp, S16_MIN, S16_MAX);
>> + else
>> + tmp = clamp(tmp, 0, U16_MAX);
>
> Double check that minmax.h is included.
Accepted. Will add <linux/minmax.h>
>
>> + *raw_data = (u16)tmp;
>> +}
>
> ...
>
>> +static int sysmon_supply_thresh_offset(int address,
>> + enum iio_event_direction dir)
>
> Make it a single line. OTOH why is 'address' signed? Perhaps u32?
> Or for some reason unsigned long as per _alarm_config()?
Accepted. Will Join to one line. Changed to unsigned long for
consistency with sysmon_read_alarm_config() and sysmon_write_alarm_config().
>
>> +{
>> + if (dir == IIO_EV_DIR_RISING)
>> + return (address * SYSMON_REG_STRIDE) + SYSMON_SUPPLY_TH_UP;
>> + if (dir == IIO_EV_DIR_FALLING)
>> + return (address * SYSMON_REG_STRIDE) + SYSMON_SUPPLY_TH_LOW;
>> +
>> + return -EINVAL;
>> +}
>
> ...
>
>> +static int sysmon_read_event_config(struct iio_dev *indio_dev,
>> + const struct iio_chan_spec *chan,
>> + enum iio_event_type type,
>> + enum iio_event_direction dir)
>> +{
>> + struct sysmon *sysmon = iio_priv(indio_dev);
>> + unsigned int imr;
>> + int config_value;
>
>> + u32 mask;
>> + int ret;
>> +
>> + mask = sysmon_get_event_mask(chan);
>
> Just make it together, as we don't validate the value of 'mask'.
Accepted.
>
> struct sysmon *sysmon = iio_priv(indio_dev);
> u32 mask = sysmon_get_event_mask(chan);
> ...
> int ret;
>
>> + ret = regmap_read(sysmon->regmap, SYSMON_IMR, &imr);
>> + if (ret)
>> + return ret;
>> +
>> + /* IMR bits are 1=masked, invert to get 1=enabled */
>> + imr = ~imr;
>> +
>> + switch (chan->type) {
>> + case IIO_VOLTAGE:
>> + config_value = sysmon_read_alarm_config(sysmon, chan->address);
>> + if (config_value < 0)
>> + return config_value;
>> + return config_value && (imr & mask);
>> +
>> + case IIO_TEMP:
>> + /*
>> + * Return the administrative state, not the hardware IMR.
>> + * The IRQ handler temporarily masks the interrupt during
>> + * the polling window; reading IMR would show it as disabled.
>> + * temp_mask bit is set when administratively disabled.
>> + */
>> + return !(sysmon->temp_mask & mask);
>> +
>> + default:
>> + return -EINVAL;
>> + }
>> +}
>
> ...
>
>> +static int sysmon_write_event_config(struct iio_dev *indio_dev,
>> + const struct iio_chan_spec *chan,
>> + enum iio_event_type type,
>> + enum iio_event_direction dir,
>> + bool state)
>> +{
>> + u32 offset = SYSMON_ALARM_OFFSET(chan->address);
>> + struct sysmon *sysmon = iio_priv(indio_dev);
>> + u32 ier = sysmon_get_event_mask(chan);
>
> Here you call the variable 'ier'. Please, make this consistent in the related
> APIs (see above).
Accepted. Will rename to 'mask' in write_event_config to match
read_event_config
>
>> + unsigned int alarm_config;
>> + int ret;
>> +
>> + guard(mutex)(&sysmon->lock);
>> +
>> + switch (chan->type) {
>> + case IIO_VOLTAGE:
>> + ret = sysmon_write_alarm_config(sysmon, chan->address, state);
>> + if (ret)
>> + return ret;
>> +
>> + ret = regmap_read(sysmon->regmap, offset, &alarm_config);
>> + if (ret)
>> + return ret;
>> +
>> + if (alarm_config)
>> + return regmap_write(sysmon->regmap, SYSMON_IER, ier);
>> +
>> + return regmap_write(sysmon->regmap, SYSMON_IDR, ier);
>> +
>> + case IIO_TEMP:
>> + if (state) {
>> + ret = regmap_write(sysmon->regmap, SYSMON_IER, ier);
>> + if (ret)
>> + return ret;
>> +
>> + scoped_guard(spinlock_irq, &sysmon->irq_lock)
>> + sysmon->temp_mask &= ~ier;
>> + } else {
>> + ret = regmap_write(sysmon->regmap, SYSMON_IDR, ier);
>> + if (ret)
>> + return ret;
>> +
>> + scoped_guard(spinlock_irq, &sysmon->irq_lock)
>> + sysmon->temp_mask |= ier;
>> + }
>> + return 0;
>> +
>> + default:
>> + return -EINVAL;
>> + }
>> +}
>
> ...
>
>> +static int sysmon_update_temp_lower(struct sysmon *sysmon)
>> +{
>> + unsigned int upper_reg;
>> + int upper_mc, lower_mc;
>> + u32 raw_val;
>> + int ret;
>> +
>> + ret = regmap_read(sysmon->regmap, SYSMON_TEMP_TH_UP, &upper_reg);
>> + if (ret)
>> + return ret;
>> +
>> + sysmon_q8p7_to_millicelsius(upper_reg, &upper_mc);
>
>> +
>
> ^^^
>
>> + lower_mc = upper_mc - sysmon->temp_hysteresis;
>
> Either add a blank line here, or remove the one above as these three is kinda
> semantically coupled.
Accepted. Will removed the blank line, the three lines are a single
conversion sequence.
>
>> + sysmon_millicelsius_to_q8p7(&raw_val, lower_mc);
>> +
>> + return regmap_write(sysmon->regmap, SYSMON_TEMP_TH_LOW, raw_val);
>> +}
>
> ...
>
>> +static void sysmon_unmask_temp(struct sysmon *sysmon, unsigned int isr)
>> +{
>> + unsigned int unmask, status;
>
> As per above perhaps name 'unmask' as 'u32 ier'? Or did I miss the use case?
Accepted. Will rename to 'u32 ier', this is the value written to the IER
register, so the name fits.
>
>> + status = isr & SYSMON_TEMP_INTR_MASK;
>> +
>> + unmask = ~status & sysmon->masked_temp;
>> + sysmon->masked_temp &= status;
>> +
>> + /* Only unmask if not administratively disabled by userspace */
>> + unmask &= ~sysmon->temp_mask;
>> +
>> + regmap_write(sysmon->regmap, SYSMON_IER, unmask);
>> +}
>
> Also looking at all this, please double check variable names in all functions
> and make types and names consistent across the whole driver code.
Accepted. Will audited. To be consistent: 'mask' for the event interrupt
bitmask in read/write_event_config, 'ier' for values written to the IER
register in sysmon_unmask_temp.
>
>> + }
>
> ...
>
>> - num_chan = size_add(num_temp, size_add(ARRAY_SIZE(temp_channels), num_supply));
>> + num_static = ARRAY_SIZE(temp_channels);
>> + num_chan = size_add(num_temp, size_add(num_static, num_supply));
>
> At glance I don't see any additional arguments, can we introduce num_static in
> the previous patch to reduce a churn here?
Accepted. Will move num_static introduction to P2.
Thanks,
Salih
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v8 5/5] iio: adc: versal-sysmon: add oversampling support
From: Erim, Salih @ 2026-06-17 16:34 UTC (permalink / raw)
To: Andy Shevchenko
Cc: jic23, andy, dlechner, nuno.sa, robh, krzk+dt, conor+dt,
conall.ogriofa, michal.simek, linux, erimsalih, linux-iio,
devicetree, linux-kernel
In-Reply-To: <ajLAUJPpdaf8lJqG@ashevche-desk.local>
Hi Andy,
On 17/06/2026 16:42, Andy Shevchenko wrote:
> On Tue, Jun 16, 2026 at 02:15:59PM +0100, Salih Erim wrote:
>> Add support for reading and writing the oversampling ratio through
>> the IIO oversampling_ratio attribute. The hardware supports averaging
>> 2, 4, 8, or 16 samples, plus a ratio of 1 (no averaging).
>>
>> Temperature and supply channels share oversampling configuration at
>> the type level (all temperature channels share one ratio, all supply
>> channels share another), exposed through info_mask_shared_by_type.
>>
>> The hardware encoding uses sample_count / 2 in a 4-bit field within
>> the CONFIG register. Per-channel averaging enable registers must also
>> be updated to activate or deactivate averaging.
>
> This one LGTM now,
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Thank you!
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v4 1/3] dt-bindings: net: add Realtek RTL8125 PCIe Ethernet
From: Heiner Kallweit @ 2026-06-17 16:43 UTC (permalink / raw)
To: ricardo, nic_swsd, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner
Cc: Sebastian Reichel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20260617-rk3588-dts-rtl-eth-describe-dt-alias-v4-1-2bd38922d129@pardini.net>
On 17.06.2026 14:58, Ricardo Pardini via B4 Relay wrote:
> From: Ricardo Pardini <ricardo@pardini.net>
>
> Add a binding for fixed/soldered Realtek RTL8125 PCIe Ethernet
> controller.
>
> The "pciVVVV,DDDD" compatibles are the Open Firmware PCI Bus Binding
> spelling, auto-derived from PCI-SIG vendor/device IDs, but they still
> need a binding when used in a board DT - analogous to "usbVVVV,PPPP"
> compatibles documented in their own bindings (e.g. microchip,lan95xx)
> so board DTs attaching properties (fixed MAC, nvmem cell, ...) to
> these PCI function nodes can be validated.
>
> Suggested-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
> ---
> .../devicetree/bindings/net/realtek,rtl8125.yaml | 43 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 44 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/realtek,rtl8125.yaml b/Documentation/devicetree/bindings/net/realtek,rtl8125.yaml
> new file mode 100644
> index 0000000000000..eee13fbc1e6a6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/realtek,rtl8125.yaml
> @@ -0,0 +1,43 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/realtek,rtl8125.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Realtek RTL8125 2.5 Gigabit PCIe Ethernet Controller
> +
> +maintainers:
> + - Heiner Kallweit <hkallweit1@gmail.com>
> +
> +description:
> + The Realtek RTL8125 is a 2.5GBASE-T Ethernet controller with a PCIe host
> + interface.
> +
> +allOf:
> + - $ref: ethernet-controller.yaml#
> +
> +properties:
> + compatible:
> + const: pci10ec,8125
IIRC we came to the conclusion that the compatible string isn't used in the
relevant code path. Then why add it here? Is there an alignment on this?
If it should be added here, then an explaining comment would be helpful.
> +
> + reg:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + pcie {
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
> + ethernet@0,0 {
> + compatible = "pci10ec,8125";
> + reg = <0x10000 0 0 0 0>;
> + local-mac-address = [00 00 00 00 00 00];
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c8d4b913f26c1..e5fbd82946aec 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -134,6 +134,7 @@ M: Heiner Kallweit <hkallweit1@gmail.com>
> M: nic_swsd@realtek.com
> L: netdev@vger.kernel.org
> S: Maintained
> +F: Documentation/devicetree/bindings/net/realtek,rtl8125.yaml
> F: drivers/net/ethernet/realtek/r8169*
>
> 8250/16?50 (AND CLONE UARTS) SERIAL DRIVER
>
^ permalink raw reply
* Re: [PATCH 07/12] rtc: rzn1: fix alarm range check truncation on 32-bit systems
From: Alexandre Belloni @ 2026-06-17 16:55 UTC (permalink / raw)
To: Prabhakar
Cc: Miquel Raynal, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Wolfram Sang, linux-rtc,
linux-renesas-soc, devicetree, linux-kernel, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-8-prabhakar.mahadev-lad.rj@bp.renesas.com>
On 15/06/2026 16:48:00+0100, Prabhakar wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> alarm and farest were declared as unsigned long, but
> rtc_tm_to_time64() returns time64_t (s64). On 32-bit systems where
> unsigned long is 32 bits, the assignment silently truncates the upper
> 32 bits of the timestamp.
>
> Fix by declaring alarm and farest as time64_t and replacing
> time_after() with a direct signed comparison, which is correct for
> time64_t values that will never realistically overflow.
>
I'd argue that this is never going to overflow ever as unsigned long
gets you to 2106 which is way past the usable range of the RTC so there
is a trade off between the size you are going to take on the stack and
the actual usefulness of the fix.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ 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