* [PATCH v4 01/10] dt-bindings: dma: nvidia,tegra186-gpc-dma: Make reset optional
From: Akhil R @ 2026-03-26 11:09 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Laxman Dewangan,
Philipp Zabel, dmaengine, devicetree, linux-tegra, linux-kernel
Cc: Akhil R
In-Reply-To: <20260326110948.68908-1-akhilrajeev@nvidia.com>
On Tegra264, GPCDMA reset control is not exposed to Linux and is handled
by the boot firmware.
Although reset was not exposed in Tegra234 as well, the firmware supported
a dummy reset which just returns success on reset without doing an actual
reset. This is also not supported in Tegra264 BPMP. Therefore mark 'reset'
and 'reset-names' properties as required only for devices prior to
Tegra264.
This also necessitates that the Tegra264 compatible be standalone and
cannot have the fallback compatible of Tegra186. Since there is no
functional impact, we keep reset as required for Tegra234 to avoid
breaking the ABI.
Fixes: bb8c97571db5 ("dt-bindings: dma: Add Tegra264 compatible string")
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
.../bindings/dma/nvidia,tegra186-gpc-dma.yaml | 25 +++++++++++++------
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
index 0dabe9bbb219..9f9f1a30e139 100644
--- a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
@@ -15,16 +15,14 @@ maintainers:
- Jon Hunter <jonathanh@nvidia.com>
- Rajesh Gumasta <rgumasta@nvidia.com>
-allOf:
- - $ref: dma-controller.yaml#
-
properties:
compatible:
oneOf:
- - const: nvidia,tegra186-gpcdma
+ - enum:
+ - nvidia,tegra264-gpcdma
+ - nvidia,tegra186-gpcdma
- items:
- enum:
- - nvidia,tegra264-gpcdma
- nvidia,tegra234-gpcdma
- nvidia,tegra194-gpcdma
- const: nvidia,tegra186-gpcdma
@@ -60,12 +58,25 @@ required:
- compatible
- reg
- interrupts
- - resets
- - reset-names
- "#dma-cells"
- iommus
- dma-channel-mask
+allOf:
+ - $ref: dma-controller.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra186-gpcdma
+ - nvidia,tegra194-gpcdma
+ - nvidia,tegra234-gpcdma
+ then:
+ required:
+ - resets
+ - reset-names
+
additionalProperties: false
examples:
--
2.50.1
^ permalink raw reply related
* [PATCH v4 00/10] Add GPCDMA support in Tegra264
From: Akhil R @ 2026-03-26 11:09 UTC (permalink / raw)
To: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Laxman Dewangan,
Philipp Zabel, dmaengine, devicetree, linux-tegra, linux-kernel
Cc: Akhil R
This series adds support for GPCDMA in Tegra264 with additional
support for separate stream ID for each channel. Tegra264 GPCDMA
controller has changes in the register offsets and uses 41-bit
addressing for memory. Add changes in the tegra186-gpc-dma driver
to support these.
v3->v4:
- Split device tree changes to two patches.
- Reordered patches to have fixes first.
- Added fixes tag to dt-bindings and device tree changes.
v2->v3:
- Add description for iommu-map property and update commit descriptions.
- Use enum for compatible string instead of const.
- Remove unused registers from struct tegra_dma_channel_regs.
- Use devm_of_dma_controller_register() to register the DMA controller.
- Remove return value check for mask setting in the driver as the bitmask
value is always greater than 32.
v1->v2:
- Fix dt_bindings_check warnings
- Drop fallback compatible "nvidia,tegra186-gpcdma" from Tegra264 DT
- Use dma_addr_t for sg_req src/dst fields and drop separate high_add
variable and check for the addr_bits only when programming the
registers.
- Update address width to 39 bits for Tegra234 and before since the SMMU
supports only up to 39 bits till Tegra234.
- Add a patch to do managed DMA controller registration.
- Describe the second iteration in the probe.
- Update commit descriptions.
Akhil R (10):
dt-bindings: dma: nvidia,tegra186-gpc-dma: Make reset optional
arm64: tegra: Remove fallback compatible for GPCDMA
dt-bindings: dma: nvidia,tegra186-gpc-dma: Add iommu-map property
dmaengine: tegra: Make reset control optional
dmaengine: tegra: Use struct for register offsets
dmaengine: tegra: Support address width > 39 bits
dmaengine: tegra: Use managed DMA controller registration
dmaengine: tegra: Use iommu-map for stream ID
dmaengine: tegra: Add Tegra264 support
arm64: tegra: Enable GPCDMA in Tegra264 and add iommu-map
.../bindings/dma/nvidia,tegra186-gpc-dma.yaml | 34 +-
.../arm64/boot/dts/nvidia/tegra264-p3834.dtsi | 4 +
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 3 +-
drivers/dma/tegra186-gpc-dma.c | 435 +++++++++++-------
4 files changed, 292 insertions(+), 184 deletions(-)
--
2.50.1
^ permalink raw reply
* Re: [PATCH 4/4] arm64: tegra: add e2426-1099+e2423-1099 support
From: Thierry Reding @ 2026-03-26 11:03 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Chun Ng, linux-tegra, devicetree, linux-kernel, robh, krzk+dt,
conor+dt, thierry.reding, jonathanh, ankitag
In-Reply-To: <20260326-valiant-marmot-of-variation-9df0be@quoll>
[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]
On Thu, Mar 26, 2026 at 11:18:17AM +0100, Krzysztof Kozlowski wrote:
> On Wed, Mar 25, 2026 at 09:26:28PM +0000, Chun Ng wrote:
> > Add the Tegra238 SoC device tree (tegra238.dtsi) and a minimal device
> > tree for the Tegra238 E2426-1099+E2423-1099 engineering reference
> > platform. The device-tree is not yet bootable and further enablement
>
> Then drop it. If this cannot be booted then it is pointless in the
> kernel, no benefit, no one can ever use it.
The purpose of this series is to establish a common baseline that people
can use to work on top off. We expect the non-bootable state to be very
temporary, but for practical reasons I want to get this merged so we can
make quicker progress.
[...]
> > + hsp_top0: tegra-hsp@3c00000 {
> > + compatible = "nvidia,tegra234-hsp", "nvidia,tegra194-hsp";
>
> DTSI says 238, compatible says 234.
Tegra238 is a derivative of Tegra234, so there's even more similarities
than we typically have across generational gaps. Your recent comments
suggested that you'd like to see new compatible strings no matter how
minimal (or even non-existent) the differences might be, so I suppose we
could prepend a Tegra238-specific compatible to this.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 4/5] PCI: tegra: Add Tegra264 support
From: Thierry Reding @ 2026-03-26 10:45 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jon Hunter, linux-pci, devicetree, linux-tegra
In-Reply-To: <177441053067.494795.3366002972241434311.b4-review@b4>
[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]
On Wed, Mar 25, 2026 at 12:48:50PM +0900, Mikko Perttunen wrote:
> On Fri, 20 Mar 2026 23:54:36 +0100, Thierry Reding <thierry.reding@kernel.org> wrote:
> > diff --git a/drivers/pci/controller/pcie-tegra264.c b/drivers/pci/controller/pcie-tegra264.c
> > new file mode 100644
> > index 000000000000..3ce1ad971bdb
> > --- /dev/null
> > +++ b/drivers/pci/controller/pcie-tegra264.c
> > @@ -0,0 +1,527 @@
> > [ ... skip 123 lines ... ]
> > + err = tegra_bpmp_transfer(pcie->bpmp, &msg);
> > + if (err)
> > + dev_info(pcie->dev, "failed to turn off PCIe #%u: %pe\n",
> > + pcie->ctl_id, ERR_PTR(err));
> > +
> > + if (msg.rx.ret)
> > + dev_info(pcie->dev, "failed to turn off PCIe #%u: %d\n",
> > + pcie->ctl_id, msg.rx.ret);
> > +}
>
> Ideally we would distinguish by message in these two cases. I suppose
> the %pe vs. %d does that, but it's not quite obvious.
Agreed. I think something like:
"BPMP transfer failed for PCIe #%u: %pe"
would work better for the first message. That's roughly in line with
other error messages for BPMP message transfer errors (as opposed to the
errors returned from BPMP as a result of a successful transfer).
>
> > +
> > +static void tegra264_pcie_icc_set(struct tegra264_pcie *pcie)
> > +{
> > + u32 value, speed, width, bw;
> > + 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);
> > +
> > + bw = width * (PCIE_SPEED2MBS_ENC(speed) / BITS_PER_BYTE);
>
> PCIE_SPEED2MBS_ENC takes enum pci_bus_speed values rather than
> LNKSTA_CLS values. Perhaps it should be converted to a static inline
> function to catch such issues.
Nice catch. speed should be indexing pcie_link_speed to get the right
enum value. I've fixed that up.
>
> > + value = MBps_to_icc(bw);
>
> The result of this is unused.
Ugh... this is supposed to be the value that's passed to icc_set_bw()
but I forgot to plumb that through. Fixed now.
>
> > [ ... skip 271 lines ... ]
> > + pcie->ecam = pcie->cfg->win;
> > +
> > + tegra264_pcie_init(pcie);
> > +
> > + if (!pcie->link_up)
> > + goto free;
>
> This path causes things to be freed, but the driver still probes. The
> remove callback will then try to remove things again.
I think the intent of the original code was to allow the driver to
continue to probe, so that the root complex would show up, but with no
devices enumerated. I don't know if we really need that, since we also
have no hotplug support there's never going to be any devices added to
the bus if the initial link up fails, as far as I can tell. I'll turn
this into a failure for now, we can revisit this if we ever need hotplug
support.
Thanks,
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] dt-bindings: mailbox: tegra186-hsp: allow doorbell+shared or shared-only
From: Krzysztof Kozlowski @ 2026-03-26 10:22 UTC (permalink / raw)
To: Chun Ng
Cc: linux-tegra, devicetree, linux-kernel, robh, krzk+dt, conor+dt,
thierry.reding, jonathanh, ankitag
In-Reply-To: <20260325212628.1234082-4-chunn@nvidia.com>
On Wed, Mar 25, 2026 at 09:26:27PM +0000, Chun Ng wrote:
> On Tegra238, hsp_top0 mailbox has doorbell plus shared0, while hsp_top1
> and aon_hsp mailboxes expose only a single shared interrupt (shared0 and
> shared1 respectively) with no doorbell.
>
> Update the schema to support Tegra238 by adding an extra oneOf options for:
NAK, there is no Tegra238 in that file nor in youro diff. Just open it
and look around.
> - doorbell with one shared interrupt (shared0..shared15)
> - single shared interrupt only (no doorbell)
>
> Signed-off-by: Chun Ng <chunn@nvidia.com>
> ---
> .../devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml
> index f833b845de0d..274480a04c70 100644
> --- a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml
> +++ b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml
> @@ -82,6 +82,13 @@ properties:
> - items:
> - const: doorbell
>
> + - items:
> + - const: doorbell
> + - pattern: "^shared([0-9]|1[0-5])$"
Here and...
> +
> + - items:
> + - pattern: "^shared([0-9]|1[0-5])$"
here: Commit msg says shared0, here you say up to shared15.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: tegra: Add Tegra238 clock and reset definitions
From: Krzysztof Kozlowski @ 2026-03-26 10:19 UTC (permalink / raw)
To: Chun Ng
Cc: linux-tegra, devicetree, linux-kernel, robh, krzk+dt, conor+dt,
thierry.reding, jonathanh, ankitag
In-Reply-To: <20260325212628.1234082-2-chunn@nvidia.com>
On Wed, Mar 25, 2026 at 09:26:25PM +0000, Chun Ng wrote:
> Add device tree binding headers for Tegra238 that define the clock and
> reset resource IDs used by the BPMP firmware. The IDs are defined by
> hardware and are not software enumerations; 0 is reserved, so numbering
> starts at 1. The reset header documents reserved ID ranges where no
> reset line is present.
>
> Signed-off-by: Chun Ng <chunn@nvidia.com>
> ---
> include/dt-bindings/clock/nvidia,tegra238.h | 279 ++++++++++++++++++++
> include/dt-bindings/reset/nvidia,tegra238.h | 125 +++++++++
Where is the bindings change with compatible?
You have entire commit msg to explain unusual things. Or cover letter -
nothing useful there.
> 2 files changed, 404 insertions(+)
> create mode 100644 include/dt-bindings/clock/nvidia,tegra238.h
> create mode 100644 include/dt-bindings/reset/nvidia,tegra238.h
So how can I verify that this matches compatible?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/4] arm64: tegra: add e2426-1099+e2423-1099 support
From: Krzysztof Kozlowski @ 2026-03-26 10:18 UTC (permalink / raw)
To: Chun Ng
Cc: linux-tegra, devicetree, linux-kernel, robh, krzk+dt, conor+dt,
thierry.reding, jonathanh, ankitag
In-Reply-To: <20260325212628.1234082-5-chunn@nvidia.com>
On Wed, Mar 25, 2026 at 09:26:28PM +0000, Chun Ng wrote:
> Add the Tegra238 SoC device tree (tegra238.dtsi) and a minimal device
> tree for the Tegra238 E2426-1099+E2423-1099 engineering reference
> platform. The device-tree is not yet bootable and further enablement
Then drop it. If this cannot be booted then it is pointless in the
kernel, no benefit, no one can ever use it.
> will be added in follow-up patches.
>
> Signed-off-by: Chun Ng <chunn@nvidia.com>
> ---
> arch/arm64/boot/dts/nvidia/Makefile | 2 +
> .../nvidia/tegra238-e2426-1099+e2423-1099.dts | 16 ++
> arch/arm64/boot/dts/nvidia/tegra238.dtsi | 190 ++++++++++++++++++
> 3 files changed, 208 insertions(+)
> create mode 100644 arch/arm64/boot/dts/nvidia/tegra238-e2426-1099+e2423-1099.dts
> create mode 100644 arch/arm64/boot/dts/nvidia/tegra238.dtsi
>
> diff --git a/arch/arm64/boot/dts/nvidia/Makefile b/arch/arm64/boot/dts/nvidia/Makefile
> index b139cbd14442..a5357809e222 100644
> --- a/arch/arm64/boot/dts/nvidia/Makefile
> +++ b/arch/arm64/boot/dts/nvidia/Makefile
> @@ -13,6 +13,7 @@ DTC_FLAGS_tegra234-p3737-0000+p3701-0000 := -@
> DTC_FLAGS_tegra234-p3740-0002+p3701-0008 := -@
> DTC_FLAGS_tegra234-p3768-0000+p3767-0000 := -@
> DTC_FLAGS_tegra234-p3768-0000+p3767-0005 := -@
> +DTC_FLAGS_tegra238-e2426-1099+e2423-1099 := -@
> DTC_FLAGS_tegra264-p3971-0089+p3834-0008 := -@
>
> dtb-$(CONFIG_ARCH_TEGRA_132_SOC) += tegra132-norrin.dtb
> @@ -34,4 +35,5 @@ dtb-$(CONFIG_ARCH_TEGRA_234_SOC) += tegra234-p3737-0000+p3701-0008.dtb
> dtb-$(CONFIG_ARCH_TEGRA_234_SOC) += tegra234-p3740-0002+p3701-0008.dtb
> dtb-$(CONFIG_ARCH_TEGRA_234_SOC) += tegra234-p3768-0000+p3767-0000.dtb
> dtb-$(CONFIG_ARCH_TEGRA_234_SOC) += tegra234-p3768-0000+p3767-0005.dtb
> +dtb-$(CONFIG_ARCH_TEGRA_238_SOC) += tegra238-e2426-1099+e2423-1099.dtb
> dtb-$(CONFIG_ARCH_TEGRA_264_SOC) += tegra264-p3971-0089+p3834-0008.dtb
> diff --git a/arch/arm64/boot/dts/nvidia/tegra238-e2426-1099+e2423-1099.dts b/arch/arm64/boot/dts/nvidia/tegra238-e2426-1099+e2423-1099.dts
> new file mode 100644
> index 000000000000..d69ea2114e23
> --- /dev/null
> +++ b/arch/arm64/boot/dts/nvidia/tegra238-e2426-1099+e2423-1099.dts
> @@ -0,0 +1,16 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +
> +/dts-v1/;
> +
> +#include "tegra238.dtsi"
> +
> +/ {
> + model = "NVIDIA Tegra238 E2426-1099+E2423-1099";
> + compatible = "nvidia,e2426-1099+e2423-1099", "nvidia,tegra238";
> +
> + bus@0 {
> + uarta: serial@3100000 {
> + status = "okay";
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/nvidia/tegra238.dtsi b/arch/arm64/boot/dts/nvidia/tegra238.dtsi
> new file mode 100644
> index 000000000000..0570c3b20e62
> --- /dev/null
> +++ b/arch/arm64/boot/dts/nvidia/tegra238.dtsi
> @@ -0,0 +1,190 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +
> +#include <dt-bindings/clock/nvidia,tegra238.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/mailbox/tegra186-hsp.h>
> +#include <dt-bindings/reset/nvidia,tegra238.h>
> +
> +/ {
> + compatible = "nvidia,tegra238";
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + bus@0 {
> + compatible = "simple-bus";
> +
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0x0 0x0 0x0 0x0 0x0 0x80000000>;
> +
> + uarta: serial@3100000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x0 0x3100000 0x0 0x10000>;
> + interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&bpmp TEGRA238_CLK_UARTA>,
> + <&bpmp TEGRA238_CLK_PLLP_OUT0>;
> + clock-names = "uartclk", "apb_pclk";
> + assigned-clocks = <&bpmp TEGRA238_CLK_UARTA>;
> + assigned-clock-parents = <&bpmp TEGRA238_CLK_PLLP_OUT0>;
> + resets = <&bpmp TEGRA238_RESET_UARTA>;
> + arm,primecell-periphid = <0x00051011>;
> + status = "disabled";
> + };
> +
> + fuse@3810000 {
> + compatible = "nvidia,tegra234-efuse";
> + reg = <0x0 0x03810000 0x0 0x19000>;
> + clocks = <&bpmp TEGRA238_CLK_FUSE>;
> + clock-names = "fuse";
> + };
> +
> + hsp_top0: tegra-hsp@3c00000 {
> + compatible = "nvidia,tegra234-hsp", "nvidia,tegra194-hsp";
DTSI says 238, compatible says 234.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] ARM: tegra: paz00: configure WiFi rfkill switch through device tree
From: Bartosz Golaszewski @ 2026-03-26 10:16 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Marc Dietrich, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
Jonathan Hunter, Bartosz Golaszewski, devicetree, linux-tegra,
linux-kernel, linux-arm-kernel, Thierry Reding
In-Reply-To: <acRtWZohqfDLbMKE@google.com>
On Thu, 26 Mar 2026 00:29:54 +0100, Dmitry Torokhov
<dmitry.torokhov@gmail.com> said:
> As of d64c732dfc9e ("net: rfkill: gpio: add DT support") rfkill-gpio
> device can be instantiated via device tree.
>
> Add the declaration there and drop board-paz00.c file and relevant
> Makefile fragments.
>
> Tested-by: Marc Dietrich <marvin24@gmx.de>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
But now I need to find another victim of my auto secondary fwnode experiments
for OF systems. :)
^ permalink raw reply
* Re: [PATCH v2 2/5] firmware: tegra: bpmp: Add tegra_bpmp_get_with_id() function
From: Thierry Reding @ 2026-03-26 10:00 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jon Hunter, linux-pci, devicetree, linux-tegra
In-Reply-To: <24777801.6Emhk5qWAg@senjougahara>
[-- Attachment #1: Type: text/plain, Size: 2601 bytes --]
On Wed, Mar 25, 2026 at 11:28:41AM +0900, Mikko Perttunen wrote:
> On Saturday, March 21, 2026 7:54 AM Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Some device tree bindings need to specify a parameter along with a BPMP
> > phandle reference to designate the ID associated with a given controller
> > that needs to interoperate with BPMP. Typically this is specified as an
> > extra cell in the nvidia,bpmp property, so add a helper to parse this ID
> > while resolving the phandle reference.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > drivers/firmware/tegra/bpmp.c | 34 ++++++++++++++++++++++++++++++++++
> > include/soc/tegra/bpmp.h | 1 +
> > 2 files changed, 35 insertions(+)
> >
> > diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
> > index e74bba7ccc44..753472b53bd8 100644
> > --- a/drivers/firmware/tegra/bpmp.c
> > +++ b/drivers/firmware/tegra/bpmp.c
> > @@ -32,6 +32,40 @@ channel_to_ops(struct tegra_bpmp_channel *channel)
> > return bpmp->soc->ops;
> > }
> >
> > +struct tegra_bpmp *tegra_bpmp_get_with_id(struct device *dev, unsigned int
> *id)
> > +{
> > + struct platform_device *pdev;
> > + struct of_phandle_args args;
> > + struct tegra_bpmp *bpmp;
> > + int err;
> > +
> > + err = __of_parse_phandle_with_args(dev->of_node, "nvidia,bpmp", NULL,
> > + 1, 0, &args);
> > + if (err < 0)
> > + return ERR_PTR(err);
> > +
> > + pdev = of_find_device_by_node(args.np);
> > + if (!pdev) {
> > + bpmp = ERR_PTR(-ENODEV);
> > + goto put;
> > + }
> > +
> > + bpmp = platform_get_drvdata(pdev);
> > + if (!bpmp) {
> > + bpmp = ERR_PTR(-EPROBE_DEFER);
> > + put_device(&pdev->dev);
> > + goto put;
> > + }
> > +
> > + if (id)
> > + *id = args.args[0];
> > +
> > +put:
> > + of_node_put(args.np);
> > + return bpmp;
> > +}
> > +EXPORT_SYMBOL_GPL(tegra_bpmp_get_with_id);
> > +
> > struct tegra_bpmp *tegra_bpmp_get(struct device *dev)
> > {
> > struct platform_device *pdev;
> > diff --git a/include/soc/tegra/bpmp.h b/include/soc/tegra/bpmp.h
> > index f5e4ac5b8cce..424188c100d9 100644
> > --- a/include/soc/tegra/bpmp.h
> > +++ b/include/soc/tegra/bpmp.h
> > @@ -127,6 +127,7 @@ struct tegra_bpmp_message {
> >
> > #if IS_ENABLED(CONFIG_TEGRA_BPMP)
> > struct tegra_bpmp *tegra_bpmp_get(struct device *dev);
> > +struct tegra_bpmp *tegra_bpmp_get_with_id(struct device *dev, unsigned int
> *id);
>
> Should add a stub function in the #else branch, as well.
Good point. Done.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 4/7] pwm: tegra: Parametrize enable register offset
From: Thierry Reding @ 2026-03-26 9:47 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pwm,
linux-tegra, linux-kernel, devicetree, Yi-Wei Wang
In-Reply-To: <20260325-t264-pwm-v2-4-998d885984b3@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]
On Wed, Mar 25, 2026 at 07:17:02PM +0900, Mikko Perttunen wrote:
> On Tegra264, the PWM enablement bit is not located at the base address
> of the PWM controller. Hence, introduce an enablement offset field in
> the tegra_pwm_soc structure to describe the offset of the register.
>
> Co-developed-by: Yi-Wei Wang <yiweiw@nvidia.com>
> Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com>
> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> ---
> drivers/pwm/pwm-tegra.c | 17 ++++++++++++-----
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pwm/pwm-tegra.c b/drivers/pwm/pwm-tegra.c
> index cf54f75d92a5..22d709986e8c 100644
> --- a/drivers/pwm/pwm-tegra.c
> +++ b/drivers/pwm/pwm-tegra.c
> @@ -61,6 +61,7 @@
>
> struct tegra_pwm_soc {
> unsigned int num_channels;
> + unsigned int enable_reg;
> };
>
> struct tegra_pwm_chip {
> @@ -197,8 +198,9 @@ static int tegra_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> err = pm_runtime_resume_and_get(pwmchip_parent(chip));
> if (err)
> return err;
> - } else
> + } else if (pc->soc->enable_reg == PWM_CSR_0) {
> val |= PWM_ENABLE;
> + }
This looks incomplete for the Tegra264 case where
pc->soc->enable_reg == PWM_CSR_1
>
> pwm_writel(pwm, PWM_CSR_0, val);
I think we need another write for PWM_CSR_1 here to properly toggle the
PWM_ENABLE bit on Tegra264.
Or am I missing something?
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 5/7] pwm: tegra: Parametrize duty and scale field widths
From: Thierry Reding @ 2026-03-26 9:42 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pwm,
linux-tegra, linux-kernel, devicetree, Yi-Wei Wang
In-Reply-To: <20260325-t264-pwm-v2-5-998d885984b3@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 625 bytes --]
On Wed, Mar 25, 2026 at 07:17:03PM +0900, Mikko Perttunen wrote:
> Tegra264 has wider fields for the duty and scale register fields.
> Parameterize the driver in preparation. The depth value also
> becomes disconnected from the width of the duty field, so define
> it separately.
>
> Co-developed-by: Yi-Wei Wang <yiweiw@nvidia.com>
> Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com>
> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> ---
> drivers/pwm/pwm-tegra.c | 29 ++++++++++++++++++-----------
> 1 file changed, 18 insertions(+), 11 deletions(-)
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: pwm: Document Tegra194 and Tegra264 controllers
From: Thierry Reding @ 2026-03-26 9:41 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pwm,
linux-tegra, linux-kernel, devicetree, Thierry Reding
In-Reply-To: <177448605080.767719.1955302882683123394.b4-reply@b4>
[-- Attachment #1: Type: text/plain, Size: 2196 bytes --]
On Thu, Mar 26, 2026 at 09:47:30AM +0900, Mikko Perttunen wrote:
> On 2026-03-25 15:22 +0100, Thierry Reding wrote:
> > On Wed, Mar 25, 2026 at 07:16:59PM +0900, Mikko Perttunen wrote:
> > > From: Thierry Reding <treding@nvidia.com>
> > >
> > > The PWM controller found on Tegra264 is largely compatible with the one
> > > on prior generations, but it comes with some extra features, hence a new
> > > compatible string is needed.
> > >
> > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > > Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> > > ---
> > > Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
> > > index 41cea4979132..15706d2a808d 100644
> > > --- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
> > > +++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
> > > @@ -16,6 +16,8 @@ properties:
> > > - enum:
> > > - nvidia,tegra20-pwm
> > > - nvidia,tegra186-pwm
> > > + - nvidia,tegra194-pwm
> > > + - nvidia,tegra264-pwm
> >
> > I think this was lost during the earlier conversation we had on the
> > split of these patches. Krzysztof had pointed out that tegra194-pwm is
> > now a duplicate entry. I don't know exactly how it ended up like this,
> > but I'm pretty sure what I meant was:
> >
> > - items:
> > - const: tegra264-pwm
> > - const: tegra194-pwm
>
> Ah, I see now.
>
> >
> > This mirrors the fact that this is in fact backwards-compatible with
> > Tegra194 but also has additional features that we need the Tegra264
> > compatible string for.
>
> The Tegra264 PWM controller is in fact not backwards compatible with
> Tegra194. It is close but not quite. I will drop the duplicate tegra194
> compatible string and update the commit message accordingly.
Ah... I remembered this wrongly. Yes, since the enable bit was moved to
a different register, we cannot claim backwards-compatibility.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/7] pwm: tegra: Modify read/write accessors for multi-register channel
From: Thierry Reding @ 2026-03-26 9:37 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pwm,
linux-tegra, linux-kernel, devicetree
In-Reply-To: <20260325-t264-pwm-v2-3-998d885984b3@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 526 bytes --]
On Wed, Mar 25, 2026 at 07:17:01PM +0900, Mikko Perttunen wrote:
> On Tegra264, each PWM instance has two registers (per channel, of which
> there is one). Update the pwm_readl/pwm_writel helper functions to
> take channel (as struct pwm_device *) and offset separately.
>
> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> ---
> drivers/pwm/pwm-tegra.c | 26 +++++++++++++++-----------
> 1 file changed, 15 insertions(+), 11 deletions(-)
Makes sense:
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/7] pwm: tegra: Avoid hard-coded max clock frequency
From: Thierry Reding @ 2026-03-26 9:35 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pwm,
linux-tegra, linux-kernel, devicetree, Yi-Wei Wang
In-Reply-To: <20260325-t264-pwm-v2-2-998d885984b3@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 743 bytes --]
On Wed, Mar 25, 2026 at 07:17:00PM +0900, Mikko Perttunen wrote:
> From: Yi-Wei Wang <yiweiw@nvidia.com>
>
> The clock driving the Tegra PWM IP can be sourced from different parent
> clocks. Hence, let dev_pm_opp_set_rate() set the max clock rate based
> upon the current parent clock that can be specified via device-tree.
>
> After this, the Tegra194 SoC data becomes redundant, so get rid of it.
>
> Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com>
> Co-developed-by: Mikko Perttunen <mperttunen@nvidia.com>
> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> ---
> drivers/pwm/pwm-tegra.c | 16 +++-------------
> 1 file changed, 3 insertions(+), 13 deletions(-)
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: pwm: Document Tegra194 and Tegra264 controllers
From: Krzysztof Kozlowski @ 2026-03-26 8:41 UTC (permalink / raw)
To: Thierry Reding
Cc: Mikko Perttunen, Thierry Reding, Uwe Kleine-König,
Jonathan Hunter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-pwm, linux-tegra, linux-kernel, devicetree, Thierry Reding
In-Reply-To: <acPuMGhPw74roB1E@orome>
On Wed, Mar 25, 2026 at 03:22:13PM +0100, Thierry Reding wrote:
> On Wed, Mar 25, 2026 at 07:16:59PM +0900, Mikko Perttunen wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > The PWM controller found on Tegra264 is largely compatible with the one
> > on prior generations, but it comes with some extra features, hence a new
> > compatible string is needed.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> > ---
> > Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
> > index 41cea4979132..15706d2a808d 100644
> > --- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
> > +++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
> > @@ -16,6 +16,8 @@ properties:
> > - enum:
> > - nvidia,tegra20-pwm
> > - nvidia,tegra186-pwm
> > + - nvidia,tegra194-pwm
> > + - nvidia,tegra264-pwm
>
> I think this was lost during the earlier conversation we had on the
> split of these patches. Krzysztof had pointed out that tegra194-pwm is
> now a duplicate entry. I don't know exactly how it ended up like this,
> but I'm pretty sure what I meant was:
>
> - items:
> - const: tegra264-pwm
> - const: tegra194-pwm
>
> This mirrors the fact that this is in fact backwards-compatible with
> Tegra194 but also has additional features that we need the Tegra264
> compatible string for.
If the devices are compatible. You have quite a lot of differences in
the driver, so the question is whether driver will work fine when bound
via old interface.
This was EXACTLY explained in DTS101 last year. I really focused on that
because after repeating for few years and two previous speeches people
still claim compatibility is something else. :(
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: pwm: Document Tegra194 and Tegra264 controllers
From: Krzysztof Kozlowski @ 2026-03-26 8:36 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Thierry Reding, Uwe Kleine-König, Jonathan Hunter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pwm,
linux-tegra, linux-kernel, devicetree, Thierry Reding
In-Reply-To: <20260325-t264-pwm-v2-1-998d885984b3@nvidia.com>
On Wed, Mar 25, 2026 at 07:16:59PM +0900, Mikko Perttunen wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> The PWM controller found on Tegra264 is largely compatible with the one
> on prior generations, but it comes with some extra features, hence a new
> compatible string is needed.
Same comments as before.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH V3 1/3] net: stmmac: Fix PTP ref clock for Tegra234
From: Krzysztof Kozlowski @ 2026-03-26 8:32 UTC (permalink / raw)
To: Jon Hunter
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, netdev, devicetree, linux-tegra
In-Reply-To: <20260325135811.148480-2-jonathanh@nvidia.com>
On Wed, Mar 25, 2026 at 01:58:09PM +0000, Jon Hunter wrote:
> Since commit 030ce919e114 ("net: stmmac: make sure that ptp_rate is not
> 0 before configuring timestamping") was added the following error is
> observed on Tegra234:
>
> ERR KERN tegra-mgbe 6800000.ethernet eth0: Invalid PTP clock rate
> WARNING KERN tegra-mgbe 6800000.ethernet eth0: PTP init failed
>
> It turns out that the Tegra234 device-tree binding defines the PTP ref
> clock name as 'ptp-ref' and not 'ptp_ref' and the above commit now
> exposes this and that the PTP clock is not configured correctly.
>
> In order to update device-tree to use the correct 'ptp_ref' name, update
> the Tegra MGBE driver to use 'ptp_ref' by default and fallback to using
> 'ptp-ref' if 'ptp_ref' is not found.
>
> Fixes: d8ca113724e7 ("net: stmmac: tegra: Add MGBE support")
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> ---
> .../net/ethernet/stmicro/stmmac/dwmac-tegra.c | 19 +++++++++++++++++--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c
> index b4b39e6a169e..ec18ee46889f 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c
> @@ -9,7 +9,7 @@
> #include "stmmac_platform.h"
>
> static const char *const mgbe_clks[] = {
> - "rx-pcs", "tx", "tx-pcs", "mac-divider", "mac", "mgbe", "ptp-ref", "mac"
> + "rx-pcs", "tx", "tx-pcs", "mac-divider", "mac", "mgbe", "ptp_ref", "mac"
> };
>
> struct tegra_mgbe {
> @@ -216,6 +216,7 @@ static int tegra_mgbe_probe(struct platform_device *pdev)
> struct plat_stmmacenet_data *plat;
> struct stmmac_resources res;
> struct tegra_mgbe *mgbe;
> + bool use_legacy_ptp;
> int irq, err, i;
> u32 value;
>
> @@ -257,9 +258,23 @@ static int tegra_mgbe_probe(struct platform_device *pdev)
> if (!mgbe->clks)
> return -ENOMEM;
>
> - for (i = 0; i < ARRAY_SIZE(mgbe_clks); i++)
> + /*
> + * Older device-trees use 'ptp-ref' rather than 'ptp_ref'.
> + * Fall back to the legacy name when 'ptp_ref' is absent.
> + */
> + use_legacy_ptp = of_property_match_string(pdev->dev.of_node,
> + "clock-names", "ptp_ref") < 0;
> +
> + for (i = 0; i < ARRAY_SIZE(mgbe_clks); i++) {
> mgbe->clks[i].id = mgbe_clks[i];
>
> + if (use_legacy_ptp && !strcmp(mgbe_clks[i], "ptp_ref")) {
Why index 0 is not valid? And why -EINVAL would be considered as legacy
clock present?
> + dev_warn(mgbe->dev,
> + "Device-tree update needed for PTP clock!\n");
> + mgbe->clks[i].id = "ptp-ref";
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH V3 3/3] arm64: tegra: Fix Tegra234 MGBE PTP clock
From: Krzysztof Kozlowski @ 2026-03-26 8:30 UTC (permalink / raw)
To: Jon Hunter
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, netdev, devicetree, linux-tegra
In-Reply-To: <20260325135811.148480-4-jonathanh@nvidia.com>
On Wed, Mar 25, 2026 at 01:58:11PM +0000, Jon Hunter wrote:
> The Tegra MGBE PTP clock is incorrectly named as 'ptp-ref' and not
> 'ptp_ref' and this causing the initialisation of the PTP clock to fail.
> The device-tree binding doc for the device and the Tegra MGBE driver
> have been updated to use the correct name and so update the device-tree
> for Tegra234 as well.
>
> Fixes: 610cdf3186bc ("arm64: tegra: Add MGBE nodes on Tegra234")
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> ---
> arch/arm64/boot/dts/nvidia/tegra234.dtsi | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH V3 2/3] dt-bindings: net: Fix Tegra234 MGBE PTP clock
From: Krzysztof Kozlowski @ 2026-03-26 8:30 UTC (permalink / raw)
To: Jon Hunter
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, netdev, devicetree, linux-tegra
In-Reply-To: <20260325135811.148480-3-jonathanh@nvidia.com>
On Wed, Mar 25, 2026 at 01:58:10PM +0000, Jon Hunter wrote:
> The PTP clock for the Tegra234 MGBE device is incorrectly named
> 'ptp-ref' and should be 'ptp_ref'. This is causing the following
> warning to be observed on Tegra234 platforms that use this device:
>
> ERR KERN tegra-mgbe 6800000.ethernet eth0: Invalid PTP clock rate
> WARNING KERN tegra-mgbe 6800000.ethernet eth0: PTP init failed
>
> Although this constitutes an ABI breakage in the binding for this
> device, PTP support has clearly never worked and so fix this now
> so we can correct the device-tree for this device. Note that the
> MGBE driver still supports the legacy 'ptp-ref' clock name and so
> older/existing device-trees will still work, but given that this
> is not the correct name, there is no point to advertise this in the
> binding.
>
> Fixes: 189c2e5c7669 ("dt-bindings: net: Add Tegra234 MGBE")
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> ---
> .../devicetree/bindings/net/nvidia,tegra234-mgbe.yaml | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 phy-next 10/27] scsi: ufs: qcom: keep parallel track of PHY power state
From: Vladimir Oltean @ 2026-03-26 8:04 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, James E.J. Bottomley, Martin K. Petersen,
Nitin Rawat
In-Reply-To: <20260325115731.genmq2yew2p4dvbs@skbuf>
[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]
On Wed, Mar 25, 2026 at 01:57:31PM +0200, Vladimir Oltean wrote:
> On Wed, Mar 25, 2026 at 05:21:14PM +0530, Manivannan Sadhasivam wrote:
> > I believe I added the power_count check for phy_exit(). But since that got
> > moved, the check becomes no longer necessary.
>
> FYI, the power_count keeps track of the balance of phy_power_on() and
> phy_power_off() calls, whereas it is the init_count keeps track of
> phy_init() and phy_exit() calls. They are only related to the extent
> that you must respect the phy_init() -> phy_power_on() -> phy_power_off()
> -> phy_exit() sequence. But in any case, both should be considered
> PHY-internal fields. The "Order of API calls" section from
> Documentation/driver-api/phy/phy.rst mentions the order that I just
> described above, and consumers should just ensure they follow that.
Ok, so we can close this topic of "checking the power_count not needed"
by linking to the conversation which spun off here:
https://lore.kernel.org/lkml/20260325120122.265973-1-manivannan.sadhasivam@oss.qualcomm.com/
Mani, I spent some more time to figure out what's really going on with
this unexpected phy_power_off() call. Do you think you could
regression-test the patch attached?
Thanks!
[-- Attachment #2: 0001-scsi-ufs-qcom-don-t-call-phy_power_on-before-phy_ini.patch --]
[-- Type: text/x-diff, Size: 7996 bytes --]
From 50dfff3541566eb094e931bd56c80011f29b9817 Mon Sep 17 00:00:00 2001
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Thu, 26 Mar 2026 10:01:55 +0200
Subject: [PATCH] scsi: ufs: qcom: don't call phy_power_on() before phy_init()
The Qualcomm UFS host controller driver violates the Generic PHY API
expectation, documented in section "Order of API calls" from
Documentation/driver-api/phy/phy.rst, and then tries to hide it.
The expectation is that calls must be made in the phy_init() ->
phy_power_on() -> phy_power_off() -> phy_exit() sequence.
What we actually have is:
ufshcd_init()
-> ufshcd_hba_init()
-> ufshcd_setup_clocks(hba, true)
-> ufshcd_vops_setup_clocks(hba, true, POST_CHANGE)
-> ufs_qcom_setup_clocks(hba, true, POST_CHANGE)
-> phy_power_on(phy)
-> ufshcd_variant_hba_init()
-> ufs_qcom_init()
-> ufs_qcom_setup_clocks(hba, true, POST_CHANGE)
-> phy_power_on(phy)
-> ufshcd_hba_enable()
-> ufshcd_vops_hce_enable_notify()
-> ufs_qcom_hce_enable_notify()
-> ufs_qcom_power_up_sequence()
-> if (phy->power_count) phy_power_off(phy)
-> phy_init(phy)
This "works" because the way that the "phy_power_on was called before
phy_init\n" condition is detected in phy-core.c is if the power_count is
positive at the phy_init() call time.
By having that "if (phy->power_count) phy_power_off(phy)" logic, the
ufs-qcom.c technically sidesteps the test, but actually violates the
Generic PHY API even more (calls phy_power_on() *and* phy_power_off()
before phy_init()).
The reason why I stumbled upon this was that I was trying to remove
dereferences of phy->power_count from drivers. This is a PHY-internal
field, and using it from drivers is highly likely to be incorrect, as
this case showcases rather well.
As commit 77d2fa54a945 ("scsi: ufs: qcom : Refactor phy_power_on/off
calls") shows, this driver tries to couple the PHY power state with the
HBA clocks, for power saving reasons. I won't try to change that, I will
just move the phy_init() call earlier, to ufs_qcom_init().
After the phy_init() movement, ufs_qcom_power_up_sequence() should no
longer need to do either phy_init() nor the conditional phy_power_down().
Because the UFS variant operations are not balanced, but the PHY API
calls need to be, create wrappers for all Generic PHY API calls, and
keep a "phy_initialized" and a "phy_powered_on" boolean, so that we call
these only once, and they properly get paired with their phy_exit()/
phy_power_off() counterparts rather than leave the phy->init_count and
phy->power_count elevated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Cc: Manivannan Sadhasivam <mani@kernel.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Nitin Rawat <quic_nitirawa@quicinc.com>
v5->v6: rewrite after actually understanding the core issue
v4->v5: patch is new
---
drivers/ufs/host/ufs-qcom.c | 104 ++++++++++++++++++++++++++----------
drivers/ufs/host/ufs-qcom.h | 2 +
2 files changed, 79 insertions(+), 27 deletions(-)
diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index 375fd24ba458..ed067247d72a 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -485,11 +485,70 @@ static u32 ufs_qcom_get_hs_gear(struct ufs_hba *hba)
return UFS_HS_G3;
}
+static int ufs_qcom_phy_init(struct ufs_qcom_host *host)
+{
+ struct phy *phy = host->generic_phy;
+ int err;
+
+ if (host->phy_initialized)
+ return 0;
+
+ err = phy_init(phy);
+ if (err)
+ return err;
+
+ host->phy_initialized = true;
+
+ return 0;
+}
+
+static void ufs_qcom_phy_exit(struct ufs_qcom_host *host)
+{
+ if (host->phy_initialized) {
+ phy_exit(host->generic_phy);
+ host->phy_initialized = false;
+ }
+}
+
+static int ufs_qcom_phy_power_on(struct ufs_qcom_host *host)
+{
+ int err;
+
+ if (host->phy_powered_on)
+ return 0;
+
+ err = phy_power_on(host->generic_phy);
+ if (err)
+ return err;
+
+ host->phy_powered_on = true;
+
+ return 0;
+}
+
+static int ufs_qcom_phy_set_gear(struct ufs_qcom_host *host,
+ enum phy_mode mode)
+{
+ return phy_set_mode_ext(host->generic_phy, mode, host->phy_gear);
+}
+
+static int ufs_qcom_phy_calibrate(struct ufs_qcom_host *host)
+{
+ return phy_calibrate(host->generic_phy);
+}
+
+static void ufs_qcom_phy_power_off(struct ufs_qcom_host *host)
+{
+ if (host->phy_powered_on) {
+ phy_power_off(host->generic_phy);
+ host->phy_powered_on = false;
+ }
+}
+
static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
{
struct ufs_qcom_host *host = ufshcd_get_variant(hba);
struct ufs_host_params *host_params = &host->host_params;
- struct phy *phy = host->generic_phy;
enum phy_mode mode;
int ret;
@@ -508,31 +567,22 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
if (ret)
return ret;
- if (phy->power_count)
- phy_power_off(phy);
-
-
- /* phy initialization - calibrate the phy */
- ret = phy_init(phy);
+ ret = ufs_qcom_phy_set_gear(host, mode);
if (ret) {
- dev_err(hba->dev, "%s: phy init failed, ret = %d\n",
+ dev_err(hba->dev, "%s: phy_set_mode_ext() failed, ret = %d\n",
__func__, ret);
- return ret;
- }
-
- ret = phy_set_mode_ext(phy, mode, host->phy_gear);
- if (ret)
goto out_disable_phy;
+ }
/* power on phy - start serdes and phy's power and clocks */
- ret = phy_power_on(phy);
+ ret = ufs_qcom_phy_power_on(host);
if (ret) {
dev_err(hba->dev, "%s: phy power on failed, ret = %d\n",
__func__, ret);
goto out_disable_phy;
}
- ret = phy_calibrate(phy);
+ ret = ufs_qcom_phy_calibrate(host);
if (ret) {
dev_err(hba->dev, "Failed to calibrate PHY: %d\n", ret);
goto out_disable_phy;
@@ -543,7 +593,7 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
return 0;
out_disable_phy:
- phy_exit(phy);
+ ufs_qcom_phy_power_off(host);
return ret;
}
@@ -1233,7 +1283,6 @@ static int ufs_qcom_setup_clocks(struct ufs_hba *hba, bool on,
enum ufs_notify_change_status status)
{
struct ufs_qcom_host *host = ufshcd_get_variant(hba);
- struct phy *phy;
int err;
/*
@@ -1244,8 +1293,6 @@ static int ufs_qcom_setup_clocks(struct ufs_hba *hba, bool on,
if (!host)
return 0;
- phy = host->generic_phy;
-
switch (status) {
case PRE_CHANGE:
if (on) {
@@ -1263,16 +1310,12 @@ static int ufs_qcom_setup_clocks(struct ufs_hba *hba, bool on,
ufs_qcom_dev_ref_clk_ctrl(host, false);
}
- err = phy_power_off(phy);
- if (err) {
- dev_err(hba->dev, "phy power off failed, ret=%d\n", err);
- return err;
- }
+ ufs_qcom_phy_power_off(host);
}
break;
case POST_CHANGE:
if (on) {
- err = phy_power_on(phy);
+ err = ufs_qcom_phy_power_on(host);
if (err) {
dev_err(hba->dev, "phy power on failed, ret = %d\n", err);
return err;
@@ -1441,6 +1484,13 @@ static int ufs_qcom_init(struct ufs_hba *hba)
if (err)
goto out_variant_clear;
+ err = ufs_qcom_phy_init(host);
+ if (err) {
+ dev_err(hba->dev, "%s: phy_init failed, ret = %d\n",
+ __func__, err);
+ goto out_variant_clear;
+ }
+
ufs_qcom_setup_clocks(hba, true, POST_CHANGE);
ufs_qcom_get_default_testbus_cfg(host);
@@ -1466,8 +1516,8 @@ static void ufs_qcom_exit(struct ufs_hba *hba)
struct ufs_qcom_host *host = ufshcd_get_variant(hba);
ufs_qcom_disable_lane_clks(host);
- phy_power_off(host->generic_phy);
- phy_exit(host->generic_phy);
+ ufs_qcom_phy_power_off(host);
+ ufs_qcom_phy_exit(host);
}
static int ufs_qcom_fw_managed_init(struct ufs_hba *hba)
diff --git a/drivers/ufs/host/ufs-qcom.h b/drivers/ufs/host/ufs-qcom.h
index 1111ab34da01..33b1b1521916 100644
--- a/drivers/ufs/host/ufs-qcom.h
+++ b/drivers/ufs/host/ufs-qcom.h
@@ -282,6 +282,8 @@ struct ufs_qcom_host {
struct clk_bulk_data *clks;
u32 num_clks;
bool is_lane_clks_enabled;
+ bool phy_initialized;
+ bool phy_powered_on;
struct icc_path *icc_ddr;
struct icc_path *icc_cpu;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 3/3] PCI: dwc: Enable MSI affinity support
From: Tsai Sung-Fu @ 2026-03-26 3:48 UTC (permalink / raw)
To: Jon Hunter
Cc: Thomas Gleixner, Radu Rendec, Manivannan Sadhasivam,
Marek Behún, Krishna Chaitanya Chundru, Bjorn Helgaas,
Rob Herring, Krzysztof Wilczyński, Lorenzo Pieralisi,
Jingoo Han, Brian Masney, Eric Chanudet, Alessandro Carminati,
Jared Kangas, linux-pci, linux-kernel,
linux-tegra@vger.kernel.org
In-Reply-To: <b5e33957-1b8d-436b-888e-2b6f13d30782@nvidia.com>
Hi,
Do we have plan to land this feature upstream ?
Thanks
On Wed, Jan 28, 2026 at 1:09 AM Jon Hunter <jonathanh@nvidia.com> wrote:
>
> Hi Thomas,
>
> On 27/01/2026 13:34, Thomas Gleixner wrote:
> > On Tue, Jan 27 2026 at 11:30, Thomas Gleixner wrote:
> >> The below untested hack should confirm that theory.
> >
> > Actually looking at it deeper the solution is trivial because in this
> > case writing the MSI message to the device is not required when the
> > affinity changes because the message does not change. It is set once via
> > msi_domain_activate() and stays the same for the life time of the
> > interrupt.
> >
> > So the below prevents the invocation of irq_chip_write_msi_msg() in
> > msi_domain_set_affinity(), but I would recommend to investigate the
> > actual underlying problem nevertheless:
> >
> > It is going to roar its ugly head at some other place sooner than later
> > as there are tons of other places which guard against
> > pci_dev::current_state != PCI_D0.
> >
> > Thanks,
> >
> > tglx
> > ---
> > --- a/kernel/irq/chip.c
> > +++ b/kernel/irq/chip.c
> > @@ -1495,7 +1495,7 @@ int irq_chip_redirect_set_affinity(struc
> > WRITE_ONCE(redir->target_cpu, cpumask_first(dest));
> > irq_data_update_effective_affinity(data, dest);
> >
> > - return IRQ_SET_MASK_OK;
> > + return IRQ_SET_MASK_OK_DONE;
> > }
> > EXPORT_SYMBOL_GPL(irq_chip_redirect_set_affinity);
> > #endif
> >
>
> Yes that does fix it!
>
> Tested-by: Jon Hunter <jonathanh@nvidia.com>
>
> Thanks!
> Jon
>
> --
> nvpublic
>
^ permalink raw reply
* [PATCHv3] firmware/tegra: add COMPILE_TEST
From: Rosen Penev @ 2026-03-26 2:47 UTC (permalink / raw)
To: linux-tegra
Cc: Michael Turquette, Stephen Boyd, Thierry Reding, Jonathan Hunter,
open list:COMMON CLK FRAMEWORK, open list
For this driver specifically, there's no arch specific stuff needed.
Build the tegra clk stuff as tegra_bpmp_init_clocks is defined there.
CLK_TEGRA_BPMP also depends on TEGRA_BPMP.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
v3: add a Kconfig symbol instead.
v2: also build the tegra clk stuff.
drivers/clk/Kconfig | 7 +++++++
drivers/clk/Makefile | 2 +-
drivers/firmware/tegra/Kconfig | 4 ++--
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 8cc300b90b5f..56295cc2b74f 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -335,6 +335,13 @@ config CLK_LS1028A_PLLDIG
features of the PLL are currently supported by the driver. By default,
configured bypass mode with this PLL.
+config CLK_TEGRA
+ bool "Clock driver for Nvidia Tegra platforms"
+ depends on ARCH_TEGRA || COMPILE_TEST
+ help
+ This adds the clock driver support for Nvidia Tegra platforms
+ using common clock framework.
+
config COMMON_CLK_XGENE
bool "Clock driver for APM XGene SoC"
default ARCH_XGENE
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 3416eea558c6..0e1331bd6295 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -154,7 +154,7 @@ obj-$(CONFIG_ARCH_STM32) += stm32/
obj-y += starfive/
obj-$(CONFIG_ARCH_SUNXI) += sunxi/
obj-y += sunxi-ng/
-obj-$(CONFIG_ARCH_TEGRA) += tegra/
+obj-$(CONFIG_CLK_TEGRA) += tegra/
obj-y += tenstorrent/
obj-$(CONFIG_ARCH_THEAD) += thead/
obj-y += ti/
diff --git a/drivers/firmware/tegra/Kconfig b/drivers/firmware/tegra/Kconfig
index 91f2320c0d0f..ae21f460807d 100644
--- a/drivers/firmware/tegra/Kconfig
+++ b/drivers/firmware/tegra/Kconfig
@@ -3,7 +3,7 @@ menu "Tegra firmware driver"
config TEGRA_IVC
bool "Tegra IVC protocol" if COMPILE_TEST
- depends on ARCH_TEGRA
+ depends on ARCH_TEGRA || COMPILE_TEST
help
IVC (Inter-VM Communication) protocol is part of the IPC
(Inter Processor Communication) framework on Tegra. It maintains the
@@ -13,7 +13,7 @@ config TEGRA_IVC
config TEGRA_BPMP
bool "Tegra BPMP driver"
- depends on ARCH_TEGRA && TEGRA_HSP_MBOX
+ depends on (ARCH_TEGRA && TEGRA_HSP_MBOX) || COMPILE_TEST
depends on !CPU_BIG_ENDIAN
select TEGRA_IVC
help
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 1/7] dt-bindings: pwm: Document Tegra194 and Tegra264 controllers
From: Mikko Perttunen @ 2026-03-26 0:47 UTC (permalink / raw)
To: Thierry Reding
Cc: Mikko Perttunen, Thierry Reding, Uwe Kleine-König,
Jonathan Hunter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-pwm, linux-tegra, linux-kernel, devicetree, Thierry Reding
In-Reply-To: <acPuMGhPw74roB1E@orome>
On 2026-03-25 15:22 +0100, Thierry Reding wrote:
> On Wed, Mar 25, 2026 at 07:16:59PM +0900, Mikko Perttunen wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > The PWM controller found on Tegra264 is largely compatible with the one
> > on prior generations, but it comes with some extra features, hence a new
> > compatible string is needed.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> > ---
> > Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
> > index 41cea4979132..15706d2a808d 100644
> > --- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
> > +++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.yaml
> > @@ -16,6 +16,8 @@ properties:
> > - enum:
> > - nvidia,tegra20-pwm
> > - nvidia,tegra186-pwm
> > + - nvidia,tegra194-pwm
> > + - nvidia,tegra264-pwm
>
> I think this was lost during the earlier conversation we had on the
> split of these patches. Krzysztof had pointed out that tegra194-pwm is
> now a duplicate entry. I don't know exactly how it ended up like this,
> but I'm pretty sure what I meant was:
>
> - items:
> - const: tegra264-pwm
> - const: tegra194-pwm
Ah, I see now.
>
> This mirrors the fact that this is in fact backwards-compatible with
> Tegra194 but also has additional features that we need the Tegra264
> compatible string for.
The Tegra264 PWM controller is in fact not backwards compatible with
Tegra194. It is close but not quite. I will drop the duplicate tegra194
compatible string and update the commit message accordingly.
Mikko
>
> Krzysztof also requested that we drop the latter part of, or reword, the
> commit message because we always want the compatible string to be added,
> regardless of backwards-compatibility, etc.
>
> So I think maybe something like this would be better for the commit
> message:
>
> The PWM controller found on Tegra264 is largely compatible with the one
> on prior generations, but it comes with some extra features. The new
> Tegra264-specific compatible string can be used to distinguish between
> the feature sets.
>
> Thierry
^ permalink raw reply
* [PATCH v2] ARM: tegra: paz00: configure WiFi rfkill switch through device tree
From: Dmitry Torokhov @ 2026-03-25 23:29 UTC (permalink / raw)
To: Thierry Reding
Cc: Marc Dietrich, Krzysztof Kozlowski, Rob Herring, Conor Dooley,
Jonathan Hunter, Bartosz Golaszewski, devicetree, linux-tegra,
linux-kernel, linux-arm-kernel
As of d64c732dfc9e ("net: rfkill: gpio: add DT support") rfkill-gpio
device can be instantiated via device tree.
Add the declaration there and drop board-paz00.c file and relevant
Makefile fragments.
Tested-by: Marc Dietrich <marvin24@gmx.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
V2:
- added Marc's Tested-by
V1:
- https://lore.kernel.org/r/aY_BpRQmLdqOOW2K@google.com
arch/arm/boot/dts/nvidia/tegra20-paz00.dts | 8 ++++
arch/arm/mach-tegra/Makefile | 2 -
arch/arm/mach-tegra/board-paz00.c | 56 ----------------------
arch/arm/mach-tegra/board.h | 2 -
arch/arm/mach-tegra/tegra.c | 4 --
5 files changed, 8 insertions(+), 64 deletions(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra20-paz00.dts b/arch/arm/boot/dts/nvidia/tegra20-paz00.dts
index 1408e1e00759..d1093ad569e6 100644
--- a/arch/arm/boot/dts/nvidia/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/nvidia/tegra20-paz00.dts
@@ -706,6 +706,14 @@ vdd_pnl_reg: regulator-3v0 {
enable-active-high;
};
+ rfkill {
+ compatible = "rfkill-gpio";
+ label = "wifi_rfkill";
+ radio-type = "wlan";
+ reset-gpios = <&gpio TEGRA_GPIO(D, 1) GPIO_ACTIVE_HIGH>;
+ shutdown-gpios = <&gpio TEGRA_GPIO(K, 5) GPIO_ACTIVE_HIGH>;
+ };
+
sound {
compatible = "nvidia,tegra-audio-alc5632-paz00",
"nvidia,tegra-audio-alc5632";
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index a2bb55bc0081..9e3abb14fbc1 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -15,5 +15,3 @@ obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
obj-$(CONFIG_ARCH_TEGRA_114_SOC) += pm-tegra30.o
obj-$(CONFIG_ARCH_TEGRA_124_SOC) += pm-tegra30.o
-
-obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += board-paz00.o
diff --git a/arch/arm/mach-tegra/board-paz00.c b/arch/arm/mach-tegra/board-paz00.c
deleted file mode 100644
index 3ec810b6f1a7..000000000000
--- a/arch/arm/mach-tegra/board-paz00.c
+++ /dev/null
@@ -1,56 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * arch/arm/mach-tegra/board-paz00.c
- *
- * Copyright (C) 2011 Marc Dietrich <marvin24@gmx.de>
- *
- * Based on board-harmony.c
- * Copyright (C) 2010 Google, Inc.
- */
-
-#include <linux/err.h>
-#include <linux/gpio/machine.h>
-#include <linux/gpio/property.h>
-#include <linux/platform_device.h>
-#include <linux/printk.h>
-#include <linux/property.h>
-
-#include "board.h"
-
-static const struct software_node tegra_gpiochip_node = {
- .name = "tegra-gpio",
-};
-
-static const struct property_entry wifi_rfkill_prop[] __initconst = {
- PROPERTY_ENTRY_STRING("name", "wifi_rfkill"),
- PROPERTY_ENTRY_STRING("type", "wlan"),
- PROPERTY_ENTRY_GPIO("reset-gpios",
- &tegra_gpiochip_node, 25, GPIO_ACTIVE_HIGH),
- PROPERTY_ENTRY_GPIO("shutdown-gpios",
- &tegra_gpiochip_node, 85, GPIO_ACTIVE_HIGH),
- { }
-};
-
-static const struct platform_device_info wifi_rfkill_info __initconst = {
- .name = "rfkill_gpio",
- .id = PLATFORM_DEVID_NONE,
- .properties = wifi_rfkill_prop,
-};
-
-void __init tegra_paz00_wifikill_init(void)
-{
- struct platform_device *pd;
- int err;
-
- err = software_node_register(&tegra_gpiochip_node);
- if (err) {
- pr_err("failed to register %s node: %d\n",
- tegra_gpiochip_node.name, err);
- return;
- }
-
- pd = platform_device_register_full(&wifi_rfkill_info);
- err = PTR_ERR_OR_ZERO(pd);
- if (err)
- pr_err("failed to register WiFi rfkill device: %d\n", err);
-}
diff --git a/arch/arm/mach-tegra/board.h b/arch/arm/mach-tegra/board.h
index 7b3ef0dc9be1..86c3ea0d6b30 100644
--- a/arch/arm/mach-tegra/board.h
+++ b/arch/arm/mach-tegra/board.h
@@ -19,6 +19,4 @@
void __init tegra_map_common_io(void);
void __init tegra_init_irq(void);
-void __init tegra_paz00_wifikill_init(void);
-
#endif
diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c
index 9ef1dfa7b926..f324a7e491d8 100644
--- a/arch/arm/mach-tegra/tegra.c
+++ b/arch/arm/mach-tegra/tegra.c
@@ -83,10 +83,6 @@ static void __init tegra_dt_init(void)
static void __init tegra_dt_init_late(void)
{
- if (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC) &&
- of_machine_is_compatible("compal,paz00"))
- tegra_paz00_wifikill_init();
-
if (IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC) &&
of_machine_is_compatible("nvidia,tegra20"))
platform_device_register_simple("tegra20-cpufreq", -1, NULL, 0);
--
2.53.0.1018.g2bb0e51243-goog
--
Dmitry
^ permalink raw reply related
* Re: [PATCH] ata: ahci_tegra: remove kcalloc
From: Rosen Penev @ 2026-03-25 23:29 UTC (permalink / raw)
To: Jon Hunter
Cc: Niklas Cassel, linux-ide, Damien Le Moal, Thierry Reding,
open list:TEGRA ARCHITECTURE SUPPORT, open list
In-Reply-To: <63d71f4c-97c0-4c2f-ac92-0a643fcdf75f@nvidia.com>
On Wed, Mar 25, 2026 at 3:17 AM Jon Hunter <jonathanh@nvidia.com> wrote:
>
>
> On 25/03/2026 07:30, Niklas Cassel wrote:
> > Hello Rosen,
> >
> > subject is a bit misleading:
> > "remove kcalloc"
> > you are removing devm_kcalloc(), so device managed.
> >
> >
> > On Tue, Mar 24, 2026 at 02:16:29PM -0700, Rosen Penev wrote:
> >> Combine allocations into one by using a flexible array member.
> >>
> >> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> >> ---
> >> drivers/ata/ahci_tegra.c | 15 ++++++---------
> >> 1 file changed, 6 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/ata/ahci_tegra.c b/drivers/ata/ahci_tegra.c
> >> index 44584eed6374..5972fe04ff3f 100644
> >> --- a/drivers/ata/ahci_tegra.c
> >> +++ b/drivers/ata/ahci_tegra.c
> >> @@ -175,8 +175,9 @@ struct tegra_ahci_priv {
> >> struct reset_control *sata_cold_rst;
> >> /* Needs special handling, cannot use ahci_platform */
> >> struct clk *sata_clk;
> >> - struct regulator_bulk_data *supplies;
> >> const struct tegra_ahci_soc *soc;
> >> +
> >> + struct regulator_bulk_data supplies[];
> >
> > Personally I'm not a big fan of flexible array members, as there can be
> > only one. And if you use it you want to use counted_by().
> >
> > Yes, there are two device managed allocations. But is that so bad?
> >
> > Since it is device managed, it will get freed on device removal anyway.
>
> FWIW I am not a big fan of this either. It is not an obvious bang for
> the buck for me. The one downside I see is that it does leave the door
> open for someone accidentally putting another variable after the
> flexible array member. Yes we should catch this in review, but there
> really should be at least a comment saying this must be the final member
> of the struct.
That will eventually become a compile time error. Currently there are
a bunch of those cases that need to get fixed before that happens.
Hardening people are working on it.
>
> Jon
>
> --
> nvpublic
>
^ 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