* Re: [PATCH 0/3] soc/tegra: cbb: Bug fixes for CBB 2.0 driver
From: Thierry Reding @ 2026-03-27 14:31 UTC (permalink / raw)
To: Sumit Gupta; +Cc: treding, jonathanh, linux-tegra, linux-kernel, bbasu
In-Reply-To: <20260121101205.3186310-1-sumitg@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 566 bytes --]
On Wed, Jan 21, 2026 at 03:42:02PM +0530, Sumit Gupta wrote:
> Bug fixes for Tegra CBB 2.0 driver addressing resume handling,
> fabric lookup table sizing, and cross-fabric timeout lookup.
>
> Sumit Gupta (3):
> soc/tegra: cbb: set ERD on resume for err interrupt
> soc/tegra: cbb: fix incorrect ARRAY_SIZE in fabric lookup tables
> soc/tegra: cbb: fix cross-fabric target timeout lookup
>
> drivers/soc/tegra/cbb/tegra234-cbb.c | 35 +++++++++++++++++++++++++---
> 1 file changed, 32 insertions(+), 3 deletions(-)
Applied, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/2] soc/tegra: cbb: Add Tegra238 support
From: Thierry Reding @ 2026-03-27 14:27 UTC (permalink / raw)
To: Sumit Gupta
Cc: treding, jonathanh, robh, krzk+dt, conor+dt, devicetree,
linux-tegra, linux-kernel, bbasu
In-Reply-To: <20260325125726.2694144-1-sumitg@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 875 bytes --]
On Wed, Mar 25, 2026 at 06:27:24PM +0530, Sumit Gupta wrote:
> Add support for Control Backbone (CBB) 2.0 based fabrics in Tegra238 SoC.
>
> The series includes:
> - DT binding updates for Tegra238 CBB compatible strings
> - Driver support for Tegra238 AON, APE, BPMP, and CBB fabrics
>
> v1[1] -> v2:
> - Add DT maintainers for review. Forgot to add earlier.
>
> Sumit Gupta (2):
> dt-bindings: arm: tegra: Add Tegra238 CBB compatible strings
> soc/tegra: cbb: Add support for CBB fabrics in Tegra238
>
> .../arm/tegra/nvidia,tegra234-cbb.yaml | 4 +
> drivers/soc/tegra/cbb/tegra234-cbb.c | 134 ++++++++++++++++++
> 2 files changed, 138 insertions(+)
>
> [1] https://lore.kernel.org/lkml/20260303155927.1885297-1-sumitg@nvidia.com/
Applied after adjusting the commit message as suggested by Krzysztof.
Thanks,
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v10 RESEND 3/3] i2c: tegra: Add support for Tegra410
From: Thierry Reding @ 2026-03-27 14:16 UTC (permalink / raw)
To: Kartik Rajput
Cc: ldewangan, digetx, andi.shyti, jonathanh, akhilrajeev, smangipudi,
linux-i2c, linux-tegra, linux-kernel
In-Reply-To: <20260324055843.549808-4-kkartik@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]
On Tue, Mar 24, 2026 at 11:28:43AM +0530, Kartik Rajput wrote:
> Add support for the Tegra410 SoC, which has 4 I2C controllers. The
> controllers are feature-equivalent to Tegra264; only the register
> offsets differ.
>
> Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
> Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
> Tested-by: Jon Hunter <jonathanh@nvidia.com>
> ---
> Changes in v3:
> * Updated timing parameters for Tegra410.
> ---
> drivers/i2c/busses/i2c-tegra.c | 63 ++++++++++++++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
Acked-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v10 RESEND 2/3] i2c: tegra: Add logic to support different register offsets
From: Thierry Reding @ 2026-03-27 14:15 UTC (permalink / raw)
To: Kartik Rajput
Cc: ldewangan, digetx, andi.shyti, jonathanh, akhilrajeev, smangipudi,
linux-i2c, linux-tegra, linux-kernel
In-Reply-To: <20260324055843.549808-3-kkartik@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]
On Tue, Mar 24, 2026 at 11:28:42AM +0530, Kartik Rajput wrote:
> Tegra410 use different offsets for existing I2C registers, update
> the logic to use appropriate offsets per SoC.
>
> As the register offsets are now defined in the SoC-specific
> tegra_i2c_regs structures, the tegra_i2c_reg_addr() function is no
> longer needed to translate register offsets and has been removed.
>
> Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
> Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
> Tested-by: Jon Hunter <jonathanh@nvidia.com>
> ---
> Changes in v9:
> * Do not remove dvc_writel() and dvc_readl() calls.
> Changes in v8:
> * Replace usage of dvc_writel() with writel_relaxed().
> * Remove dvc_writel().
> Changes in v7:
> * Fix Tegra256 reg offsets, change it to tegra264_i2c_regs as it
> supports SW mutex.
> Changes in v6:
> * Do not remove dvc_writel().
> * Keep DVC registers defined as a macro.
> * Correct Tegra20 DVC register offsets.
> * Remove sl_cnfg, sl_addr1 and sl_addr2 registers for DVC and VI
> as they are not used.
> Changes in v2:
> * Replace individual is_dvc and is_vi flags with an I2C variant.
> * Add tegra20_dvc_i2c_hw and tegra210_vi_i2c_hw in a separate
> patch.
> * Use calculated offsets for tegra20_dvc_i2c_regs and
> tegra210_vi_i2c_regs.
> * Initialize registers only if they are used on the given SoC.
> ---
> drivers/i2c/busses/i2c-tegra.c | 359 ++++++++++++++++++++++-----------
> 1 file changed, 237 insertions(+), 122 deletions(-)
Acked-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v10 RESEND 1/3] i2c: tegra: Introduce tegra_i2c_variant to identify DVC and VI
From: Thierry Reding @ 2026-03-27 14:15 UTC (permalink / raw)
To: Kartik Rajput
Cc: ldewangan, digetx, andi.shyti, jonathanh, akhilrajeev, smangipudi,
linux-i2c, linux-tegra, linux-kernel
In-Reply-To: <20260324055843.549808-2-kkartik@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 924 bytes --]
On Tue, Mar 24, 2026 at 11:28:41AM +0530, Kartik Rajput wrote:
> Replace the per-instance DVC/VI boolean flags with a tegra_i2c_variant
> enum and move the variant field into tegra_i2c_hw_feature so it is
> populated via SoC match data.
>
> Add dedicated SoC data entries for the "nvidia,tegra20-i2c-dvc" and
> "nvidia,tegra210-i2c-vi" compatibles and drop compatible-string checks
> from tegra_i2c_parse_dt.
>
> Suggested-by: Jon Hunter <jonathanh@nvidia.com>
> Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
> Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
> Tested-by: Jon Hunter <jonathanh@nvidia.com>
> ---
> Changes in v10:
> * Suqashed "i2c: tegra: Move variant to tegra_i2c_hw_feature"
> with this patch.
> ---
> drivers/i2c/busses/i2c-tegra.c | 112 ++++++++++++++++++++++++++++-----
> 1 file changed, 95 insertions(+), 17 deletions(-)
Acked-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/6] usb: xhci: tegra: Remove redundant mutex when setting phy mode
From: Thierry Reding @ 2026-03-27 14:06 UTC (permalink / raw)
To: Diogo Ivo
Cc: Thierry Reding, Mathias Nyman, Greg Kroah-Hartman,
Jonathan Hunter, JC Kuo, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
linux-usb, linux-tegra, linux-kernel, linux-phy, devicetree
In-Reply-To: <00aeda7a-e5e5-4779-b212-6e56c2c5ec31@tecnico.ulisboa.pt>
[-- Attachment #1: Type: text/plain, Size: 2325 bytes --]
On Thu, Mar 26, 2026 at 02:17:33PM +0000, Diogo Ivo wrote:
> Hello,
>
> On 3/24/26 11:48, Thierry Reding wrote:
> > On Tue, Jan 27, 2026 at 03:11:48PM +0000, Diogo Ivo wrote:
> > > As the PHY subsystem already synchronizes concurrent accesses to a PHY
> > > instance with a core-internal mutex remove the driver specific mutex
> > > synchronization.
> > >
> > > Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
> > > ---
> > > v1->v2:
> > > - New patch
> > > ---
> > > drivers/usb/host/xhci-tegra.c | 4 ----
> > > 1 file changed, 4 deletions(-)
> > >
> > > diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
> > > index 8b492871d21d..927861ca14f2 100644
> > > --- a/drivers/usb/host/xhci-tegra.c
> > > +++ b/drivers/usb/host/xhci-tegra.c
> > > @@ -1357,15 +1357,11 @@ static void tegra_xhci_id_work(struct work_struct *work)
> > > dev_dbg(tegra->dev, "host mode %s\n", str_on_off(tegra->host_mode));
> > > - mutex_lock(&tegra->lock);
> > > -
> > > if (tegra->host_mode)
> > > phy_set_mode_ext(phy, PHY_MODE_USB_OTG, USB_ROLE_HOST);
> > > else
> > > phy_set_mode_ext(phy, PHY_MODE_USB_OTG, USB_ROLE_NONE);
> > > - mutex_unlock(&tegra->lock);
> > > -
> >
> > It looks to me like the mutex here is trying to protect against
> > tegra->host_mode changing while we're setting a different mode. That
> > doesn't seem to be taken care of by the PHY internal mutex.
>
> After taking another look at it I think I understand your point for the
> mutex, but in that case wouldn't it also need to be held in the writer
> of host_mode, tegra_xhci_id_notify()?
Yes, I think it probably would need to. I don't know how likely it is,
but I think the purpose of this is to protect against the ID notifier
firing quickly in succession. Although, given that this runs on a work
queue and work queue instances are non-reentrant to my knowledge, I
don't think we need the mutex here after all.
> This patch has been picked up as-is into usb-next so it would be nice to
> figure this out before it gets merged in the next merge window.
Given the above, I think it's fine. Maybe the commit message doesn't
give a correct reason for why we don't need the mutex, but the resulting
code looks like it should be fine regardless.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/2] PCI: dwc: Add multi-port controller support
From: Neil Armstrong @ 2026-03-27 14:04 UTC (permalink / raw)
To: Sumit Kumar, Bjorn Helgaas, Jingoo Han, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
Krzysztof Kozlowski, Alim Akhtar, Richard Zhu, Lucas Stach,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Yue Wang, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Paul Walmsley, Greentime Hu, Samuel Holland, Chuanhua Lei,
Marek Vasut, Yoshihiro Shimoda, Geert Uytterhoeven, Magnus Damm,
Pratyush Anand, Thierry Reding, Jonathan Hunter
Cc: linux-pci, linux-kernel, linux-arm-kernel, linux-samsung-soc, imx,
linux-amlogic, linux-arm-msm, linux-renesas-soc, linux-tegra,
linux-riscv
In-Reply-To: <20260305-dt-parser-v2-0-85836db8dc06@oss.qualcomm.com>
Le 05/03/2026 à 07:20, Sumit Kumar a écrit :
> This series adds support for multi-port PCIe controllers in the DesignWare
> driver. Currently, the driver only supports a single Root Port with
> controller-level properties, which doesn't work for multi-port controllers
> where each port may have different configurations.
>
> This series introduces a per-port structure and parsing API that allows
> each Root Port to be configured independently via pcie@N child nodes in
> device tree, while maintaining backward compatibility with existing
> single-port bindings.
>
> Signed-off-by: Sumit Kumar <sumit.kumar@oss.qualcomm.com>
> ---
> Changes in v2:
> - Fix error code preservation in dw_pcie_resume_noirq() to return actual
> error from dw_pcie_wait_for_link() instead of hardcoded -ETIMEDOUT (Mani).
> - Initialize ret variable to -ENOENT in dw_pcie_parse_root_ports() (Mani).
> - dw_pcie_host_init(): Remove -ENOENT error skipping to make parsing
> failures fatal for now, add TODO comment about making properties
> optional later (Mani).
> - Link to v1: https://lore.kernel.org/r/20260105-dt-parser-v1-0-b11c63cb5e2c@oss.qualcomm.com
>
> ---
> Sumit Kumar (2):
> PCI: API changes for multi-port controller support
> PCI: dwc: Add multi-port controller support
>
> drivers/pci/controller/dwc/pci-exynos.c | 4 +-
> drivers/pci/controller/dwc/pci-imx6.c | 15 +-
> drivers/pci/controller/dwc/pci-meson.c | 1 -
> drivers/pci/controller/dwc/pcie-designware-host.c | 175 ++++++++++++++++++----
> drivers/pci/controller/dwc/pcie-designware.c | 32 ++--
> drivers/pci/controller/dwc/pcie-designware.h | 17 ++-
> drivers/pci/controller/dwc/pcie-fu740.c | 6 +-
> drivers/pci/controller/dwc/pcie-intel-gw.c | 13 +-
> drivers/pci/controller/dwc/pcie-qcom-common.c | 5 +-
> drivers/pci/controller/dwc/pcie-qcom-ep.c | 4 +-
> drivers/pci/controller/dwc/pcie-qcom.c | 4 +-
> drivers/pci/controller/dwc/pcie-rcar-gen4.c | 13 +-
> drivers/pci/controller/dwc/pcie-spear13xx.c | 5 +-
> drivers/pci/controller/dwc/pcie-tegra194.c | 4 +-
> drivers/pci/of.c | 6 +-
> drivers/pci/pci.h | 2 +
> 16 files changed, 232 insertions(+), 74 deletions(-)
> ---
> base-commit: 097a6c336d0080725c626fda118ecfec448acd0f
> change-id: 20251010-dt-parser-98b50ce18fc1
>
> Best regards,
Tested on meson-pci (boot log https://gitlab.com/amlogic-foss/abcd-linux-test/-/jobs/13677061036)
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # On Bananapi M2S
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH] gpio: shared: call gpio_chip::of_xlate() if set
From: Konrad Dybcio @ 2026-03-27 13:05 UTC (permalink / raw)
To: Jon Hunter, Bartosz Golaszewski, Linus Walleij,
Bartosz Golaszewski, Abel Vesa, Sibi Sankar
Cc: linux-gpio, linux-kernel, linux-tegra@vger.kernel.org
In-Reply-To: <dff3c797-a619-42c0-9696-3e617e13356e@nvidia.com>
On 3/17/26 11:12 AM, Jon Hunter wrote:
> Hi Bartosz,
>
> On 16/03/2026 13:52, Bartosz Golaszewski wrote:
>> OF-based GPIO controller drivers may provide a translation function that
>> calculates the real chip offset from whatever devicetree sources
>> provide. We need to take this into account in the shared GPIO management
>> and call of_xlate() if it's provided and adjust the entry->offset we
>> initially set when scanning the tree.
>>
>> To that end: modify the shared GPIO API to take the GPIO chip as
>> argument on setup (to avoid having to rcu_dereference() it from the GPIO
>> device) and protect the access to entry->offset with the existing lock.
>>
>> Fixes: a060b8c511ab ("gpiolib: implement low-level, shared GPIO support")
>> Reported-by: Jon Hunter <jonathanh@nvidia.com>
>> Closes: https://lore.kernel.org/all/921ba8ce-b18e-4a99-966d-c763d22081e2@nvidia.com/
>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>> ---
[...]
> Thanks for sending this. However, I am seeing a different issue now ...
>
> ------------[ cut here ]------------
> WARNING: drivers/gpio/gpiolib-shared.c:499 at gpio_shared_add_proxy_lookup+0x118/0x1d8, CPU#8: swapper/0/1
Not only this, this breaks suspend on the Qualcomm X1E CRD (probably all
/most QC devices by extension)
+CC Abel, Sibi in case this is what you've been chasing
with the patch:
[rootfs ]# echo mem > /sys/power/state
[ 226.043580] PM: suspend entry (deep)
[ 226.047470] Filesystems sync: 0.000 seconds
[ 226.058513] Freezing user space processes
[ 226.066296] Freezing user space processes completed (elapsed 0.003 seconds)
[ 226.073489] OOM killer disabled.
[ 226.076843] Freezing remaining freezable tasks
[ 226.082353] Freezing remaining freezable tasks completed (elapsed 0.000 seconds)
(give it some time, it dies)
without the patch:
[rootfs ]# echo mem > /sys/power/state [ 38.047570] PM: suspend entry (deep)
[ 38.053506] Filesystems sync: 0.001 seconds
[ 38.082615] Freezing user space processes
[ 38.092528] Freezing user space processes completed (elapsed 0.005 seconds)
[ 38.099860] OOM killer disabled.
[ 38.103222] Freezing remaining freezable tasks
[ 38.110329] Freezing remaining freezable tasks completed (elapsed 0.002 seconds)
[ 38.469231] dwc3-qcom-legacy a0f8800.usb: port-1 HS-PHY not in L2
[ 38.652848] Disabling non-boot CPUs ...
[ 38.668957] IRQ205: set affinity failed(-22).
[ 38.669018] IRQ206: set affinity failed(-22).
[ 38.669029] IRQ207: set affinity failed(-22).
[ 38.670351] IRQ274: set affinity failed(-22).
[ 38.671257] psci: CPU11 killed (polled 0 ms)
[ 38.712308] IRQ205: set affinity failed(-22).
[ 38.712323] IRQ206: set affinity failed(-22).
[ 38.712333] IRQ207: set affinity failed(-22).
[ 38.713634] IRQ274: set affinity failed(-22).
[ 38.713821] psci: CPU10 killed (polled 0 ms)
[ 38.754187] IRQ205: set affinity failed(-22).
[ 38.754202] IRQ206: set affinity failed(-22).
[ 38.756479] psci: CPU9 killed (polled 0 ms)
[ 38.789962] psci: CPU8 killed (polled 0 ms)
[ 38.803178] psci: CPU7 killed (polled 0 ms)
[ 38.816286] psci: CPU6 killed (polled 0 ms)
[ 38.828479] psci: CPU5 killed (polled 0 ms)
[ 38.847479] psci: CPU4 killed (polled 0 ms)
[ 38.873528] psci: CPU3 killed (polled 0 ms)
[ 38.894399] psci: CPU2 killed (polled 0 ms)
[ 38.905818] psci: CPU1 killed (polled 0 ms)
[ 38.912658] Enabling non-boot CPUs ...
(resumes just fine)
Konrad
^ permalink raw reply
* Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
From: Akhil R @ 2026-03-27 11:42 UTC (permalink / raw)
To: alexandre.belloni
Cc: Frank.Li, acpica-devel, akhilrajeev, conor+dt, conor, devicetree,
ebiggers, fredrik.markstrom, jonathanh, krzk+dt, lenb, linux-acpi,
linux-hwmon, linux-i3c, linux-kernel, linux-tegra, linux,
miquel.raynal, p.zabel, rafael, robert.moore, robh, smangipudi,
thierry.reding
In-Reply-To: <20260327082721f7e69e6a@mail.local>
On Fri, 27 Mar 2026 09:27:21 +0100, Alexandre Belloni wrote:
> On 27/03/2026 13:48:58+0530, Akhil R wrote:
>> On Thu, 26 Mar 2026 16:44:31 +0100, Alexandre Belloni wrote:
>> > On 26/03/2026 10:05:03-0500, Rob Herring wrote:
>> >> On Wed, Mar 18, 2026 at 05:31:50PM +0000, Conor Dooley wrote:
>> >> > On Wed, Mar 18, 2026 at 10:57:14PM +0530, Akhil R wrote:
>> >> > > Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
>> >> > > Discovery and Configuration Specification [1] to specify which discovery
>> >> > > method an I3C device supports during bus initialization. The property is
>> >> > > a bitmap, where a bit value of 1 indicates support for that method, and 0
>> >> > > indicates lack of support.
>> >> > > Bit 0: SETDASA CCC (Direct)
>> >> > > Bit 1: SETAASA CCC (Broadcast)
>> >> > > Bit 2: Other CCC (vendor / standards extension)
>> >> > > All other bits are reserved.
>> >> > >
>> >> > > It is specifically needed when an I3C device requires SETAASA for the
>> >> > > address assignment. SETDASA will be supported by default if this property
>> >> > > is absent - which means for now the property just serves as a flag to
>> >> > > enable SETAASA, but keep the property as a bitmap to align with the
>> >> > > specifications.
>> >> > >
>> >> > > [1] https://www.mipi.org/specifications/disco
>> >> > >
>> >> > > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>> >> > > ---
>> >> > > .../devicetree/bindings/i3c/i3c.yaml | 30 ++++++++++++++++---
>> >> > > 1 file changed, 26 insertions(+), 4 deletions(-)
>> >> > >
>> >> > > diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
>> >> > > index e25fa72fd785..1705d90d4d79 100644
>> >> > > --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
>> >> > > +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
>> >> > > @@ -31,10 +31,12 @@ properties:
>> >> > > described in the device tree, which in turn means we have to describe
>> >> > > I3C devices.
>> >> > >
>> >> > > - Another use case for describing an I3C device in the device tree is when
>> >> > > - this I3C device has a static I2C address and we want to assign it a
>> >> > > - specific I3C dynamic address before the DAA takes place (so that other
>> >> > > - devices on the bus can't take this dynamic address).
>> >> > > + Other use-cases for describing an I3C device in the device tree are:
>> >> > > + - When the I3C device has a static I2C address and we want to assign
>> >> > > + it a specific I3C dynamic address before the DAA takes place (so
>> >> > > + that other devices on the bus can't take this dynamic address).
>> >> > > + - When the I3C device requires SETAASA for its discovery and uses a
>> >> > > + pre-defined static address.
>> >> > >
>> >> > > "#size-cells":
>> >> > > const: 0
>> >> > > @@ -147,6 +149,26 @@ patternProperties:
>> >> > > through SETDASA. If static address is not present, this address is assigned
>> >> > > through SETNEWDA after assigning a temporary address via ENTDAA.
>> >> > >
>> >> > > + mipi-i3c-static-method:
>> >> > > + $ref: /schemas/types.yaml#/definitions/uint32
>> >> > > + minimum: 0x1
>> >> > > + maximum: 0xff
>> >> > > + default: 1
>> >> > > + description: |
>> >> > > + Bitmap describing which methods of Dynamic Address Assignment from a
>> >> > > + static address are supported by this I3C Target. A bit value of 1
>> >> > > + indicates support for that method, and 0 indicates lack of support.
>> >> >
>> >> > I really am not keen on properties that are bitmaps, why can't we just
>> >> > use the strings "setdasa", "setaasa" etc?
>> >>
>> >> If this comes from a specification, then I'd tend to just copy it rather
>> >> than invent our own thing. Obviously if is something structured
>> >> fundamentally different from how DT is designed, then we wouldn't. But
>> >> this is just a simple property.
>> >>
>> >
>> > The issue being that the specification is not public so it is difficult
>> > to take any decision.
>>
>> There is a public version available in the same link, but you would still
>> have to provide them a name and an email ID. The document will be sent to
>> the mail ID.
>>
>
> The public version only contains one property:
> mipi-disco-interface-revision
Could you check once if the below link works?
https://www.mipi.org/mipi-disco-for-i3c-download
Best Regards,
Akhil
^ 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-27 11:28 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: <gq4sswslkjaoe5hhxe2mz6z57uiumotqknkryadvfsstj4srx4@qgenqekgrqv4>
[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]
On Fri, Mar 27, 2026 at 12:22:46PM +0530, Manivannan Sadhasivam wrote:
> I tested the patch. But it fails ufs_qcom_power_up_sequence() if PHY was already
> powered on:
>
> [ 31.513321] qcom-qmp-ufs-phy 1d87000.phy: phy initialization timed-out
> [ 31.513335] ufshcd-qcom 1d84000.ufshc: Failed to calibrate PHY: -110
> [ 31.565273] ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
>
> Funny thing is, it didn't affect the functionality since the UFS core retries
> ufshcd_hba_enable() and in the error path of ufs_qcom_power_up_sequence(),
> phy_power_off() gets called and that causes the next try to succeed. So it is
> evident that, if PHY was already powered ON, it should be powered off before
> ufs_qcom_phy_power_on(). And due to the UFS driver design,
> ufs_qcom_power_up_sequence() can get called multiple times. So we cannot just
> remove phy_power_off().
>
> Below diff on top of your patch fixes the issue:
>
> ```
> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
> index ed067247d72a..2c9fe03f349e 100644
> --- a/drivers/ufs/host/ufs-qcom.c
> +++ b/drivers/ufs/host/ufs-qcom.c
> @@ -567,6 +567,8 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
> if (ret)
> return ret;
>
> + ufs_qcom_phy_power_off(host);
> +
> ret = ufs_qcom_phy_set_gear(host, mode);
> if (ret) {
> dev_err(hba->dev, "%s: phy_set_mode_ext() failed, ret = %d\n",
> ```
>
> - Mani
Understood. Thanks for testing.
I'm still not satisfied with this level of complexity. If I get you
right, ufs_qcom_phy_power_off() is still needed because phy_calibrate()
expects a "fresh after power on" state, otherwise it fails? That would
be the second reason, apart from the first one I already identified
(undo a phy_power_on() done prior to phy_init()).
If so, could you please test the 3 patches attached (no relationship
with anything else we've exchanged thus far)?
[-- Attachment #2: 0001-phy-qcom-qmp-ufs-support-dynamic-gear-changing.patch --]
[-- Type: text/x-diff, Size: 2013 bytes --]
From 2d42c2d40e6ddfd0c73fc39601f93f7b81a42401 Mon Sep 17 00:00:00 2001
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Fri, 27 Mar 2026 12:41:00 +0200
Subject: [PATCH 1/3] phy: qcom-qmp-ufs: support dynamic gear changing
Currently, phy_set_mode_ext() on the QMP UFS PHY expects the PHY to be
powered down, and it makes no change to the hardware state, instead
phy_power_on() followed by phy_calibrate() must be run afterwards.
"Order of API calls" from Documentation/driver-api/phy/phy.rst has a
roundabout and not really clear way of saying that both calling
sequences should be supported. This was further discussed here,
documentation is pending an update:
https://lore.kernel.org/linux-phy/E1vo0mF-00000007kbg-1OeA@rmk-PC.armlinux.org.uk/
By absorbing the phy_power_off() -> ... -> phy_power_on() ->
phy_configure() surrounding sequence into phy_set_mode_ext(), consumer
drivers can be greatly simplified, and we also have a proper
self-standing phy_set_mode_ext() implementation which does not rely on
other calls to do its job.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
index df138a5442eb..e75b059bf246 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
@@ -2004,15 +2004,24 @@ static int qmp_ufs_set_mode(struct phy *phy, enum phy_mode mode, int submode)
{
struct qmp_ufs *qmp = phy_get_drvdata(phy);
const struct qmp_phy_cfg *cfg = qmp->cfg;
+ bool powered_on = phy->power_count;
if (submode > cfg->max_supported_gear || submode == 0) {
dev_err(qmp->dev, "Invalid PHY submode %d\n", submode);
return -EINVAL;
}
+ if (powered_on)
+ qmp_ufs_power_off(phy);
+
qmp->mode = mode;
qmp->submode = submode;
+ if (powered_on) {
+ qmp_ufs_power_on(phy);
+ return qmp_ufs_phy_calibrate(phy);
+ }
+
return 0;
}
--
2.34.1
[-- Attachment #3: 0002-scsi-ufs-qcom-call-phy_init-before-phy_power_on.patch --]
[-- Type: text/x-diff, Size: 3707 bytes --]
From 8d156781d38597865da37a86417f553143d74eaa Mon Sep 17 00:00:00 2001
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Fri, 27 Mar 2026 13:14:39 +0200
Subject: [PATCH 2/3] scsi: ufs: qcom: call phy_init() before phy_power_on()
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_off().
However, phy_power_off() is still needed, for a separate reason which
will be dealt with separately.
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 | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index 375fd24ba458..ffa70c6c7143 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -513,13 +513,6 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
/* phy initialization - calibrate the phy */
- ret = phy_init(phy);
- if (ret) {
- dev_err(hba->dev, "%s: phy init failed, ret = %d\n",
- __func__, ret);
- return ret;
- }
-
ret = phy_set_mode_ext(phy, mode, host->phy_gear);
if (ret)
goto out_disable_phy;
@@ -1441,6 +1434,13 @@ static int ufs_qcom_init(struct ufs_hba *hba)
if (err)
goto out_variant_clear;
+ err = phy_init(host->generic_phy);
+ 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);
--
2.34.1
[-- Attachment #4: 0003-scsi-ufs-qcom-make-use-of-QMP-PHY-dynamic-gear-switc.patch --]
[-- Type: text/x-diff, Size: 1696 bytes --]
From 88f4bdfee770cd433a940a14e318d8c8b5dfa516 Mon Sep 17 00:00:00 2001
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Fri, 27 Mar 2026 13:18:05 +0200
Subject: [PATCH 3/3] scsi: ufs: qcom: make use of QMP PHY dynamic gear
switching ability
The QMP UFS PHY can now tolerate having phy_set_mode_ext() being called
while the PHY is powered up. We no longer need to power it down, back up
and calibrate it.
Simplify ufs_qcom_power_up_sequence() by relying on just phy_set_mode_ext()
and let PHY power management be handled just by ufs_qcom_setup_clocks().
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
drivers/ufs/host/ufs-qcom.c | 25 +------------------------
1 file changed, 1 insertion(+), 24 deletions(-)
diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index ffa70c6c7143..cf7b67f2021e 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -508,37 +508,14 @@ 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_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);
- if (ret) {
- dev_err(hba->dev, "%s: phy power on failed, ret = %d\n",
- __func__, ret);
- goto out_disable_phy;
- }
-
- ret = phy_calibrate(phy);
- if (ret) {
- dev_err(hba->dev, "Failed to calibrate PHY: %d\n", ret);
- goto out_disable_phy;
- }
+ return ret;
ufs_qcom_select_unipro_mode(host);
return 0;
-
-out_disable_phy:
- phy_exit(phy);
-
- return ret;
}
/*
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
From: Alexandre Belloni @ 2026-03-27 8:27 UTC (permalink / raw)
To: Akhil R
Cc: Frank.Li, acpica-devel, conor+dt, conor, devicetree, ebiggers,
fredrik.markstrom, jonathanh, krzk+dt, lenb, linux-acpi,
linux-hwmon, linux-i3c, linux-kernel, linux-tegra, linux,
miquel.raynal, p.zabel, rafael, robert.moore, robh, smangipudi,
thierry.reding
In-Reply-To: <20260327081858.32354-1-akhilrajeev@nvidia.com>
On 27/03/2026 13:48:58+0530, Akhil R wrote:
> On Thu, 26 Mar 2026 16:44:31 +0100, Alexandre Belloni wrote:
> > On 26/03/2026 10:05:03-0500, Rob Herring wrote:
> >> On Wed, Mar 18, 2026 at 05:31:50PM +0000, Conor Dooley wrote:
> >> > On Wed, Mar 18, 2026 at 10:57:14PM +0530, Akhil R wrote:
> >> > > Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
> >> > > Discovery and Configuration Specification [1] to specify which discovery
> >> > > method an I3C device supports during bus initialization. The property is
> >> > > a bitmap, where a bit value of 1 indicates support for that method, and 0
> >> > > indicates lack of support.
> >> > > Bit 0: SETDASA CCC (Direct)
> >> > > Bit 1: SETAASA CCC (Broadcast)
> >> > > Bit 2: Other CCC (vendor / standards extension)
> >> > > All other bits are reserved.
> >> > >
> >> > > It is specifically needed when an I3C device requires SETAASA for the
> >> > > address assignment. SETDASA will be supported by default if this property
> >> > > is absent - which means for now the property just serves as a flag to
> >> > > enable SETAASA, but keep the property as a bitmap to align with the
> >> > > specifications.
> >> > >
> >> > > [1] https://www.mipi.org/specifications/disco
> >> > >
> >> > > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> >> > > ---
> >> > > .../devicetree/bindings/i3c/i3c.yaml | 30 ++++++++++++++++---
> >> > > 1 file changed, 26 insertions(+), 4 deletions(-)
> >> > >
> >> > > diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
> >> > > index e25fa72fd785..1705d90d4d79 100644
> >> > > --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
> >> > > +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
> >> > > @@ -31,10 +31,12 @@ properties:
> >> > > described in the device tree, which in turn means we have to describe
> >> > > I3C devices.
> >> > >
> >> > > - Another use case for describing an I3C device in the device tree is when
> >> > > - this I3C device has a static I2C address and we want to assign it a
> >> > > - specific I3C dynamic address before the DAA takes place (so that other
> >> > > - devices on the bus can't take this dynamic address).
> >> > > + Other use-cases for describing an I3C device in the device tree are:
> >> > > + - When the I3C device has a static I2C address and we want to assign
> >> > > + it a specific I3C dynamic address before the DAA takes place (so
> >> > > + that other devices on the bus can't take this dynamic address).
> >> > > + - When the I3C device requires SETAASA for its discovery and uses a
> >> > > + pre-defined static address.
> >> > >
> >> > > "#size-cells":
> >> > > const: 0
> >> > > @@ -147,6 +149,26 @@ patternProperties:
> >> > > through SETDASA. If static address is not present, this address is assigned
> >> > > through SETNEWDA after assigning a temporary address via ENTDAA.
> >> > >
> >> > > + mipi-i3c-static-method:
> >> > > + $ref: /schemas/types.yaml#/definitions/uint32
> >> > > + minimum: 0x1
> >> > > + maximum: 0xff
> >> > > + default: 1
> >> > > + description: |
> >> > > + Bitmap describing which methods of Dynamic Address Assignment from a
> >> > > + static address are supported by this I3C Target. A bit value of 1
> >> > > + indicates support for that method, and 0 indicates lack of support.
> >> >
> >> > I really am not keen on properties that are bitmaps, why can't we just
> >> > use the strings "setdasa", "setaasa" etc?
> >>
> >> If this comes from a specification, then I'd tend to just copy it rather
> >> than invent our own thing. Obviously if is something structured
> >> fundamentally different from how DT is designed, then we wouldn't. But
> >> this is just a simple property.
> >>
> >
> > The issue being that the specification is not public so it is difficult
> > to take any decision.
>
> There is a public version available in the same link, but you would still
> have to provide them a name and an email ID. The document will be sent to
> the mail ID.
>
The public version only contains one property:
mipi-disco-interface-revision
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
From: Akhil R @ 2026-03-27 8:18 UTC (permalink / raw)
To: alexandre.belloni
Cc: Frank.Li, acpica-devel, akhilrajeev, conor+dt, conor, devicetree,
ebiggers, fredrik.markstrom, jonathanh, krzk+dt, lenb, linux-acpi,
linux-hwmon, linux-i3c, linux-kernel, linux-tegra, linux,
miquel.raynal, p.zabel, rafael, robert.moore, robh, smangipudi,
thierry.reding
In-Reply-To: <202603261544313f63018c@mail.local>
On Thu, 26 Mar 2026 16:44:31 +0100, Alexandre Belloni wrote:
> On 26/03/2026 10:05:03-0500, Rob Herring wrote:
>> On Wed, Mar 18, 2026 at 05:31:50PM +0000, Conor Dooley wrote:
>> > On Wed, Mar 18, 2026 at 10:57:14PM +0530, Akhil R wrote:
>> > > Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
>> > > Discovery and Configuration Specification [1] to specify which discovery
>> > > method an I3C device supports during bus initialization. The property is
>> > > a bitmap, where a bit value of 1 indicates support for that method, and 0
>> > > indicates lack of support.
>> > > Bit 0: SETDASA CCC (Direct)
>> > > Bit 1: SETAASA CCC (Broadcast)
>> > > Bit 2: Other CCC (vendor / standards extension)
>> > > All other bits are reserved.
>> > >
>> > > It is specifically needed when an I3C device requires SETAASA for the
>> > > address assignment. SETDASA will be supported by default if this property
>> > > is absent - which means for now the property just serves as a flag to
>> > > enable SETAASA, but keep the property as a bitmap to align with the
>> > > specifications.
>> > >
>> > > [1] https://www.mipi.org/specifications/disco
>> > >
>> > > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>> > > ---
>> > > .../devicetree/bindings/i3c/i3c.yaml | 30 ++++++++++++++++---
>> > > 1 file changed, 26 insertions(+), 4 deletions(-)
>> > >
>> > > diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
>> > > index e25fa72fd785..1705d90d4d79 100644
>> > > --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
>> > > +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
>> > > @@ -31,10 +31,12 @@ properties:
>> > > described in the device tree, which in turn means we have to describe
>> > > I3C devices.
>> > >
>> > > - Another use case for describing an I3C device in the device tree is when
>> > > - this I3C device has a static I2C address and we want to assign it a
>> > > - specific I3C dynamic address before the DAA takes place (so that other
>> > > - devices on the bus can't take this dynamic address).
>> > > + Other use-cases for describing an I3C device in the device tree are:
>> > > + - When the I3C device has a static I2C address and we want to assign
>> > > + it a specific I3C dynamic address before the DAA takes place (so
>> > > + that other devices on the bus can't take this dynamic address).
>> > > + - When the I3C device requires SETAASA for its discovery and uses a
>> > > + pre-defined static address.
>> > >
>> > > "#size-cells":
>> > > const: 0
>> > > @@ -147,6 +149,26 @@ patternProperties:
>> > > through SETDASA. If static address is not present, this address is assigned
>> > > through SETNEWDA after assigning a temporary address via ENTDAA.
>> > >
>> > > + mipi-i3c-static-method:
>> > > + $ref: /schemas/types.yaml#/definitions/uint32
>> > > + minimum: 0x1
>> > > + maximum: 0xff
>> > > + default: 1
>> > > + description: |
>> > > + Bitmap describing which methods of Dynamic Address Assignment from a
>> > > + static address are supported by this I3C Target. A bit value of 1
>> > > + indicates support for that method, and 0 indicates lack of support.
>> >
>> > I really am not keen on properties that are bitmaps, why can't we just
>> > use the strings "setdasa", "setaasa" etc?
>>
>> If this comes from a specification, then I'd tend to just copy it rather
>> than invent our own thing. Obviously if is something structured
>> fundamentally different from how DT is designed, then we wouldn't. But
>> this is just a simple property.
>>
>
> The issue being that the specification is not public so it is difficult
> to take any decision.
There is a public version available in the same link, but you would still
have to provide them a name and an email ID. The document will be sent to
the mail ID.
Regards,
Akhil
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: arm: tegra: Add Tegra238 CBB compatible strings
From: Krzysztof Kozlowski @ 2026-03-27 7:26 UTC (permalink / raw)
To: Sumit Gupta
Cc: treding, jonathanh, robh, krzk+dt, conor+dt, devicetree,
linux-tegra, linux-kernel, bbasu
In-Reply-To: <20260325125726.2694144-2-sumitg@nvidia.com>
On Wed, Mar 25, 2026 at 06:27:25PM +0530, Sumit Gupta wrote:
> Add compatible strings for CBB v2.0 based fabrics in Tegra238:
> - nvidia,tegra238-ape-fabric
> - nvidia,tegra238-aon-fabric
> - nvidia,tegra238-bpmp-fabric
> - nvidia,tegra238-cbb-fabric
So you just pasted diff contents here. What's the point?
Comit msg is not a copy of the diff. We can read the diff.
Drop.
Acked-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: Manivannan Sadhasivam @ 2026-03-27 6:52 UTC (permalink / raw)
To: Vladimir Oltean
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: <20260326080444.gbesciaa5zwvcgoy@skbuf>
On Thu, Mar 26, 2026 at 10:04:44AM +0200, Vladimir Oltean wrote:
> 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/
>
Sure.
> 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?
>
I tested the patch. But it fails ufs_qcom_power_up_sequence() if PHY was already
powered on:
[ 31.513321] qcom-qmp-ufs-phy 1d87000.phy: phy initialization timed-out
[ 31.513335] ufshcd-qcom 1d84000.ufshc: Failed to calibrate PHY: -110
[ 31.565273] ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
Funny thing is, it didn't affect the functionality since the UFS core retries
ufshcd_hba_enable() and in the error path of ufs_qcom_power_up_sequence(),
phy_power_off() gets called and that causes the next try to succeed. So it is
evident that, if PHY was already powered ON, it should be powered off before
ufs_qcom_phy_power_on(). And due to the UFS driver design,
ufs_qcom_power_up_sequence() can get called multiple times. So we cannot just
remove phy_power_off().
Below diff on top of your patch fixes the issue:
```
diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index ed067247d72a..2c9fe03f349e 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -567,6 +567,8 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
if (ret)
return ret;
+ ufs_qcom_phy_power_off(host);
+
ret = ufs_qcom_phy_set_gear(host, mode);
if (ret) {
dev_err(hba->dev, "%s: phy_set_mode_ext() failed, ret = %d\n",
```
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply related
* Re: [PATCH v10 RESEND 0/3] Add I2C support for Tegra410
From: Andi Shyti @ 2026-03-26 22:46 UTC (permalink / raw)
To: Kartik Rajput
Cc: ldewangan, digetx, thierry.reding, jonathanh, akhilrajeev,
smangipudi, linux-i2c, linux-tegra, linux-kernel
In-Reply-To: <20260324055843.549808-1-kkartik@nvidia.com>
Hi Kartik,
> Kartik Rajput (3):
> i2c: tegra: Introduce tegra_i2c_variant to identify DVC and VI
> i2c: tegra: Add logic to support different register offsets
> i2c: tegra: Add support for Tegra410
merged to i2c/i2c-host.
Thanks,
Andi
^ permalink raw reply
* Re: [PATCHv2] firmware/tegra: add COMPILE_TEST
From: kernel test robot @ 2026-03-26 21:51 UTC (permalink / raw)
To: Rosen Penev, linux-tegra
Cc: oe-kbuild-all, Michael Turquette, Stephen Boyd, Thierry Reding,
Jonathan Hunter, linux-clk, linux-kernel
In-Reply-To: <20260324015722.12507-1-rosenp@gmail.com>
Hi Rosen,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20260325]
[cannot apply to tegra/for-next clk/clk-next drm-tegra/drm/tegra/for-next v7.0-rc5 v7.0-rc4 v7.0-rc3 linus/master v7.0-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Rosen-Penev/firmware-tegra-add-COMPILE_TEST/20260326-124230
base: next-20260325
patch link: https://lore.kernel.org/r/20260324015722.12507-1-rosenp%40gmail.com
patch subject: [PATCHv2] firmware/tegra: add COMPILE_TEST
config: s390-allnoconfig-bpf (https://download.01.org/0day-ci/archive/20260326/202603262233.dvRyEA8v-lkp@intel.com/config)
compiler: s390x-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260326/202603262233.dvRyEA8v-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603262233.dvRyEA8v-lkp@intel.com/
All errors (new ones prefixed by >>):
s390x-linux-gnu-ld: drivers/clk/tegra/clk.o: in function `tegra_register_devclks':
>> drivers/clk/tegra/clk.c:361:(.text+0x718): undefined reference to `clk_register_clkdev'
>> s390x-linux-gnu-ld: drivers/clk/tegra/clk.c:366:(.text+0x770): undefined reference to `__clk_get_name'
>> s390x-linux-gnu-ld: drivers/clk/tegra/clk.c:366:(.text+0x784): undefined reference to `clk_register_clkdev'
s390x-linux-gnu-ld: drivers/clk/tegra/clk.o: in function `tegra_clk_dev_register':
>> drivers/clk/tegra/clk.c:437:(.text+0x830): undefined reference to `clk_register'
s390x-linux-gnu-ld: drivers/clk/tegra/clk.o: in function `tegra_init_dup_clks':
>> drivers/clk/tegra/clk.c:263:(.init.text+0x17c): undefined reference to `clkdev_add'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-audio-sync.o: in function `tegra_clk_register_sync_source':
>> drivers/clk/tegra/clk-audio-sync.c:70:(.text+0x1f8): undefined reference to `clk_register'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-dfll.o: in function `dfll_unregister_clk':
>> drivers/clk/tegra/clk-dfll.c:1215:(.text+0x236): undefined reference to `clk_unregister'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-divider.o: in function `clk_divider_restore_context':
>> drivers/clk/tegra/clk-divider.c:127:(.text+0x262): undefined reference to `clk_hw_get_parent'
>> s390x-linux-gnu-ld: drivers/clk/tegra/clk-divider.c:128:(.text+0x268): undefined reference to `clk_hw_get_rate'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-divider.c:129:(.text+0x276): undefined reference to `clk_hw_get_rate'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-divider.o: in function `tegra_clk_register_divider':
>> drivers/clk/tegra/clk-divider.c:174:(.text+0x6e0): undefined reference to `clk_register'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-divider.o: in function `tegra_clk_register_mc':
>> drivers/clk/tegra/clk-divider.c:190:(.text+0x7da): undefined reference to `clk_register_divider_table'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-periph.o: in function `clk_periph_restore_context':
>> drivers/clk/tegra/clk-periph.c:119:(.text+0x676): undefined reference to `clk_hw_get_parent_index'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-periph.o: in function `_tegra_clk_register_periph':
>> drivers/clk/tegra/clk-periph.c:199:(.text+0x8ec): undefined reference to `clk_register'
>> s390x-linux-gnu-ld: drivers/clk/tegra/clk-periph.c:199:(.text+0x9b6): undefined reference to `clk_register'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-periph.c:199:(.text+0xb72): undefined reference to `clk_register'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-periph.c:199:(.text+0xdf2): undefined reference to `clk_register'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-periph.c:199:(.text+0xeb8): undefined reference to `clk_register'
>> s390x-linux-gnu-ld: drivers/clk/tegra/clk-periph.o:(.data.rel.ro+0x60): undefined reference to `clk_hw_determine_rate_no_reparent'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-periph-fixed.o: in function `tegra_clk_register_periph_fixed':
>> drivers/clk/tegra/clk-periph-fixed.c:105:(.text+0x558): undefined reference to `clk_register'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-periph-gate.o: in function `tegra_clk_register_periph_gate':
>> drivers/clk/tegra/clk-periph-gate.c:171:(.text+0x79e): undefined reference to `clk_register'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-pll.o: in function `clk_pll_determine_rate':
>> drivers/clk/tegra/clk-pll.c:852:(.text+0xbc4): undefined reference to `clk_hw_get_rate'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-pll.o: in function `clk_pll_wait_for_lock':
>> drivers/clk/tegra/clk-pll.c:319:(.text+0xdae): undefined reference to `clk_hw_get_name'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-pll.o: in function `clk_pllu_enable':
>> drivers/clk/tegra/clk-pll.c:1124:(.text+0x1eec): undefined reference to `clk_hw_get_parent'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-pll.c:1125:(.text+0x1ef2): undefined reference to `clk_hw_get_parent'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-pll.c:1137:(.text+0x1f08): undefined reference to `clk_hw_get_rate'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-pll.o: in function `clk_pll_recalc_rate':
drivers/clk/tegra/clk-pll.c:888:(.text+0x2b58): undefined reference to `clk_hw_get_name'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-pll.c:902:(.text+0x2c10): undefined reference to `clk_hw_get_name'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-pll.o: in function `clk_pll_set_rate':
drivers/clk/tegra/clk-pll.c:821:(.text+0x3a1a): undefined reference to `clk_hw_get_name'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-pll.c:811:(.text+0x3a4e): undefined reference to `clk_hw_get_name'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-pll.o: in function `tegra_clk_pll_restore_context':
drivers/clk/tegra/clk-pll.c:1042:(.text+0x3ae2): undefined reference to `clk_hw_get_parent'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-pll.c:1043:(.text+0x3ae8): undefined reference to `clk_hw_get_rate'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-pll.c:1044:(.text+0x3af6): undefined reference to `clk_hw_get_rate'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-pll.c:1054:(.text+0x3b5c): undefined reference to `__clk_get_enable_count'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-pll.o: in function `clk_plle_enable':
drivers/clk/tegra/clk-pll.c:971:(.text+0x3cc0): undefined reference to `clk_hw_get_parent'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-pll.c:971:(.text+0x3cc6): undefined reference to `clk_hw_get_rate'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-pll-out.o: in function `tegra_clk_pll_out_restore_context':
drivers/clk/tegra/clk-pll-out.c:74:(.text+0x432): undefined reference to `__clk_get_enable_count'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-pll-out.o: in function `tegra_clk_register_pll_out':
drivers/clk/tegra/clk-pll-out.c:115:(.text+0x5f8): undefined reference to `clk_register'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-sdmmc-mux.o: in function `clk_sdmmc_mux_get_parent':
drivers/clk/tegra/clk-sdmmc-mux.c:48:(.text+0x66c): undefined reference to `clk_hw_get_num_parents'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-sdmmc-mux.o: in function `clk_sdmmc_mux_restore_context':
drivers/clk/tegra/clk-sdmmc-mux.c:208:(.text+0x9e2): undefined reference to `clk_hw_get_parent'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-sdmmc-mux.c:209:(.text+0x9e8): undefined reference to `clk_hw_get_rate'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-sdmmc-mux.c:210:(.text+0x9f6): undefined reference to `clk_hw_get_rate'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-sdmmc-mux.c:213:(.text+0xa04): undefined reference to `clk_hw_get_parent_index'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-sdmmc-mux.o: in function `tegra_clk_register_sdmmc_mux_div':
drivers/clk/tegra/clk-sdmmc-mux.c:269:(.text+0xc06): undefined reference to `clk_register'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-super.o: in function `clk_super_restore_context':
drivers/clk/tegra/clk-super.c:184:(.text+0x726): undefined reference to `clk_hw_get_parent_index'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-super.o: in function `clk_super_mux_restore_context':
drivers/clk/tegra/clk-super.c:131:(.text+0x7a2): undefined reference to `clk_hw_get_parent_index'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-super.o: in function `tegra_clk_register_super_clk':
drivers/clk/tegra/clk-super.c:270:(.text+0xbba): undefined reference to `clk_register'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-super.o:(.data.rel.ro+0x60): undefined reference to `clk_hw_determine_rate_no_reparent'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-audio.o: in function `tegra_audio_sync_clk_init':
drivers/clk/tegra/clk-tegra-audio.c:145:(.init.text+0xda): undefined reference to `clk_register_mux_table'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-audio.c:156:(.init.text+0x172): undefined reference to `clk_register_gate'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-audio.o: in function `tegra_audio_clk_init':
drivers/clk/tegra/clk-tegra-audio.c:235:(.init.text+0x4a0): undefined reference to `clk_register_fixed_factor'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-periph.o: in function `init_pllp':
drivers/clk/tegra/clk-tegra-periph.c:952:(.init.text+0x7c): undefined reference to `clk_register_clkdev'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-periph.c:1004:(.init.text+0x326): undefined reference to `clk_register_gate'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-periph.c:1013:(.init.text+0x380): undefined reference to `clk_register_gate'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-periph.c:1017:(.init.text+0x394): undefined reference to `clk_register_clkdev'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-periph.o:(.data.rel+0xe8): undefined reference to `clk_mux_ops'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-periph.o:(.data.rel+0x208): undefined reference to `clk_mux_ops'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-periph.o:(.data.rel+0x328): undefined reference to `clk_mux_ops'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-periph.o:(.data.rel+0x448): undefined reference to `clk_mux_ops'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-periph.o:(.data.rel+0x568): undefined reference to `clk_mux_ops'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-periph.o:(.data.rel+0x688): more undefined references to `clk_mux_ops' follow
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-fixed.o: in function `tegra_osc_clk_init':
drivers/clk/tegra/clk-tegra-fixed.c:53:(.init.text+0xe0): undefined reference to `clk_register_fixed_rate'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-fixed.c:59:(.init.text+0x12e): undefined reference to `clk_register_fixed_factor'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-fixed.c:67:(.init.text+0x17c): undefined reference to `clk_register_fixed_factor'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-fixed.c:76:(.init.text+0x1ca): undefined reference to `clk_register_fixed_factor'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-fixed.c:87:(.init.text+0x226): undefined reference to `clk_register_fixed_factor'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-fixed.o: in function `tegra_fixed_clk_init':
drivers/clk/tegra/clk-tegra-fixed.c:105:(.init.text+0x2da): undefined reference to `clk_register_fixed_rate'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-super-cclk.o: in function `cclk_super_determine_rate':
drivers/clk/tegra/clk-tegra-super-cclk.c:71:(.text+0x200): undefined reference to `clk_hw_get_parent_by_index'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-super-cclk.c:72:(.text+0x212): undefined reference to `clk_hw_get_parent_by_index'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-super-cclk.c:84:(.text+0x246): undefined reference to `clk_hw_get_rate'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-super-cclk.c:95:(.text+0x304): undefined reference to `clk_hw_get_rate_range'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-super-cclk.c:106:(.text+0x34c): undefined reference to `clk_hw_round_rate'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-super-cclk.o: in function `tegra_clk_register_super_cclk':
drivers/clk/tegra/clk-tegra-super-cclk.c:200:(.text+0x6e2): undefined reference to `clk_register'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-super-gen4.o: in function `tegra_sclk_init':
drivers/clk/tegra/clk-tegra-super-gen4.c:117:(.init.text+0xf8): undefined reference to `clk_register_divider_table'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-super-gen4.c:141:(.init.text+0x1e8): undefined reference to `clk_register_divider_table'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-super-gen4.c:144:(.init.text+0x21a): undefined reference to `clk_register_gate'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-super-gen4.c:156:(.init.text+0x286): undefined reference to `clk_register_divider_table'
s390x-linux-gnu-ld: drivers/clk/tegra/clk-tegra-super-gen4.c:159:(.init.text+0x2b8): undefined reference to `clk_register_gate'
vim +361 drivers/clk/tegra/clk.c
d5ff89a82a6d27 Peter De Schrijver 2013-08-22 254
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 255 void __init tegra_init_dup_clks(struct tegra_clk_duplicate *dup_list,
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 256 struct clk *clks[], int clk_max)
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 257 {
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 258 struct clk *clk;
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 259
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 260 for (; dup_list->clk_id < clk_max; dup_list++) {
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 261 clk = clks[dup_list->clk_id];
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 262 dup_list->lookup.clk = clk;
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 @263 clkdev_add(&dup_list->lookup);
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 264 }
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 265 }
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 266
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 267 void tegra_init_from_table(struct tegra_clk_init_table *tbl,
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 268 struct clk *clks[], int clk_max)
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 269 {
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 270 struct clk *clk;
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 271
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 272 for (; tbl->clk_id < clk_max; tbl++) {
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 273 clk = clks[tbl->clk_id];
b9e742c3164344 Tomeu Vizoso 2014-09-17 274 if (IS_ERR_OR_NULL(clk)) {
b9e742c3164344 Tomeu Vizoso 2014-09-17 275 pr_err("%s: invalid entry %ld in clks array for id %d\n",
b9e742c3164344 Tomeu Vizoso 2014-09-17 276 __func__, PTR_ERR(clk), tbl->clk_id);
b9e742c3164344 Tomeu Vizoso 2014-09-17 277 WARN_ON(1);
b9e742c3164344 Tomeu Vizoso 2014-09-17 278
b9e742c3164344 Tomeu Vizoso 2014-09-17 279 continue;
b9e742c3164344 Tomeu Vizoso 2014-09-17 280 }
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 281
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 282 if (tbl->parent_id < clk_max) {
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 283 struct clk *parent = clks[tbl->parent_id];
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 284 if (clk_set_parent(clk, parent)) {
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 285 pr_err("%s: Failed to set parent %s of %s\n",
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 286 __func__, __clk_get_name(parent),
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 287 __clk_get_name(clk));
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 288 WARN_ON(1);
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 289 }
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 290 }
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 291
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 292 if (tbl->rate)
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 293 if (clk_set_rate(clk, tbl->rate)) {
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 294 pr_err("%s: Failed to set rate %lu of %s\n",
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 295 __func__, tbl->rate,
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 296 __clk_get_name(clk));
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 297 WARN_ON(1);
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 298 }
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 299
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 300 if (tbl->state)
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 301 if (clk_prepare_enable(clk)) {
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 302 pr_err("%s: Failed to enable %s\n", __func__,
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 303 __clk_get_name(clk));
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 304 WARN_ON(1);
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 305 }
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 306 }
8f8f484bf355e5 Prashant Gaikwad 2013-01-11 307 }
61fd290d213e25 Prashant Gaikwad 2013-01-11 308
7ba256d2aa2a18 Philipp Zabel 2016-02-25 309 static const struct reset_control_ops rst_ops = {
6d5b988e7dc56b Stephen Warren 2013-11-05 310 .assert = tegra_clk_rst_assert,
6d5b988e7dc56b Stephen Warren 2013-11-05 311 .deassert = tegra_clk_rst_deassert,
4236e752f19d4d Mikko Perttunen 2017-03-02 312 .reset = tegra_clk_rst_reset,
6d5b988e7dc56b Stephen Warren 2013-11-05 313 };
6d5b988e7dc56b Stephen Warren 2013-11-05 314
6d5b988e7dc56b Stephen Warren 2013-11-05 315 static struct reset_controller_dev rst_ctlr = {
6d5b988e7dc56b Stephen Warren 2013-11-05 316 .ops = &rst_ops,
6d5b988e7dc56b Stephen Warren 2013-11-05 317 .owner = THIS_MODULE,
6d5b988e7dc56b Stephen Warren 2013-11-05 318 .of_reset_n_cells = 1,
6d5b988e7dc56b Stephen Warren 2013-11-05 319 };
6d5b988e7dc56b Stephen Warren 2013-11-05 320
5d797111afe12e Dmitry Osipenko 2018-05-08 321 void __init tegra_add_of_provider(struct device_node *np,
5d797111afe12e Dmitry Osipenko 2018-05-08 322 void *clk_src_onecell_get)
343a607cb79259 Peter De Schrijver 2013-09-02 323 {
343a607cb79259 Peter De Schrijver 2013-09-02 324 int i;
343a607cb79259 Peter De Schrijver 2013-09-02 325
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 326 tegra_car_np = np;
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 327
343a607cb79259 Peter De Schrijver 2013-09-02 328 for (i = 0; i < clk_num; i++) {
343a607cb79259 Peter De Schrijver 2013-09-02 329 if (IS_ERR(clks[i])) {
343a607cb79259 Peter De Schrijver 2013-09-02 330 pr_err
343a607cb79259 Peter De Schrijver 2013-09-02 331 ("Tegra clk %d: register failed with %ld\n",
343a607cb79259 Peter De Schrijver 2013-09-02 332 i, PTR_ERR(clks[i]));
343a607cb79259 Peter De Schrijver 2013-09-02 333 }
343a607cb79259 Peter De Schrijver 2013-09-02 334 if (!clks[i])
343a607cb79259 Peter De Schrijver 2013-09-02 335 clks[i] = ERR_PTR(-EINVAL);
343a607cb79259 Peter De Schrijver 2013-09-02 336 }
343a607cb79259 Peter De Schrijver 2013-09-02 337
343a607cb79259 Peter De Schrijver 2013-09-02 338 clk_data.clks = clks;
343a607cb79259 Peter De Schrijver 2013-09-02 339 clk_data.clk_num = clk_num;
5d797111afe12e Dmitry Osipenko 2018-05-08 340 of_clk_add_provider(np, clk_src_onecell_get, &clk_data);
6d5b988e7dc56b Stephen Warren 2013-11-05 341
6d5b988e7dc56b Stephen Warren 2013-11-05 342 rst_ctlr.of_node = np;
66b6f3d07454a6 Mikko Perttunen 2015-05-20 343 rst_ctlr.nr_resets = periph_banks * 32 + num_special_reset;
6d5b988e7dc56b Stephen Warren 2013-11-05 344 reset_controller_register(&rst_ctlr);
343a607cb79259 Peter De Schrijver 2013-09-02 345 }
343a607cb79259 Peter De Schrijver 2013-09-02 346
66b6f3d07454a6 Mikko Perttunen 2015-05-20 347 void __init tegra_init_special_resets(unsigned int num,
66b6f3d07454a6 Mikko Perttunen 2015-05-20 348 int (*assert)(unsigned long),
66b6f3d07454a6 Mikko Perttunen 2015-05-20 349 int (*deassert)(unsigned long))
66b6f3d07454a6 Mikko Perttunen 2015-05-20 350 {
66b6f3d07454a6 Mikko Perttunen 2015-05-20 351 num_special_reset = num;
66b6f3d07454a6 Mikko Perttunen 2015-05-20 352 special_reset_assert = assert;
66b6f3d07454a6 Mikko Perttunen 2015-05-20 353 special_reset_deassert = deassert;
66b6f3d07454a6 Mikko Perttunen 2015-05-20 354 }
66b6f3d07454a6 Mikko Perttunen 2015-05-20 355
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 356 void tegra_register_devclks(struct tegra_devclk *dev_clks, int num)
73d37e4c7c4b9d Peter De Schrijver 2013-10-09 357 {
73d37e4c7c4b9d Peter De Schrijver 2013-10-09 358 int i;
73d37e4c7c4b9d Peter De Schrijver 2013-10-09 359
73d37e4c7c4b9d Peter De Schrijver 2013-10-09 360 for (i = 0; i < num; i++, dev_clks++)
73d37e4c7c4b9d Peter De Schrijver 2013-10-09 @361 clk_register_clkdev(clks[dev_clks->dt_id], dev_clks->con_id,
73d37e4c7c4b9d Peter De Schrijver 2013-10-09 362 dev_clks->dev_id);
9f0030c8ad0ce3 Peter De Schrijver 2014-06-26 363
9f0030c8ad0ce3 Peter De Schrijver 2014-06-26 364 for (i = 0; i < clk_num; i++) {
9f0030c8ad0ce3 Peter De Schrijver 2014-06-26 365 if (!IS_ERR_OR_NULL(clks[i]))
9f0030c8ad0ce3 Peter De Schrijver 2014-06-26 @366 clk_register_clkdev(clks[i], __clk_get_name(clks[i]),
9f0030c8ad0ce3 Peter De Schrijver 2014-06-26 367 "tegra-clk-debug");
9f0030c8ad0ce3 Peter De Schrijver 2014-06-26 368 }
73d37e4c7c4b9d Peter De Schrijver 2013-10-09 369 }
73d37e4c7c4b9d Peter De Schrijver 2013-10-09 370
b8700d506ac405 Peter De Schrijver 2013-10-14 371 struct clk ** __init tegra_lookup_dt_id(int clk_id,
b8700d506ac405 Peter De Schrijver 2013-10-14 372 struct tegra_clk *tegra_clk)
b8700d506ac405 Peter De Schrijver 2013-10-14 373 {
b8700d506ac405 Peter De Schrijver 2013-10-14 374 if (tegra_clk[clk_id].present)
b8700d506ac405 Peter De Schrijver 2013-10-14 375 return &clks[tegra_clk[clk_id].dt_id];
b8700d506ac405 Peter De Schrijver 2013-10-14 376 else
b8700d506ac405 Peter De Schrijver 2013-10-14 377 return NULL;
b8700d506ac405 Peter De Schrijver 2013-10-14 378 }
b8700d506ac405 Peter De Schrijver 2013-10-14 379
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 380 static struct device_node *tegra_clk_get_of_node(struct clk_hw *hw)
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 381 {
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 382 struct device_node *np;
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 383 char *node_name;
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 384
28df1500f53874 Andy Shevchenko 2023-08-04 385 node_name = kstrdup_and_replace(hw->init->name, '_', '-', GFP_KERNEL);
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 386 if (!node_name)
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 387 return NULL;
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 388
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 389 for_each_child_of_node(tegra_car_np, np) {
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 390 if (!strcmp(np->name, node_name))
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 391 break;
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 392 }
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 393
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 394 kfree(node_name);
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 395
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 396 return np;
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 397 }
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 398
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 399 struct clk *tegra_clk_dev_register(struct clk_hw *hw)
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 400 {
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 401 struct platform_device *pdev, *parent;
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 402 const char *dev_name = NULL;
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 403 struct device *dev = NULL;
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 404 struct device_node *np;
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 405
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 406 np = tegra_clk_get_of_node(hw);
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 407
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 408 if (!of_device_is_available(np))
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 409 goto put_node;
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 410
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 411 dev_name = kasprintf(GFP_KERNEL, "tegra_clk_%s", hw->init->name);
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 412 if (!dev_name)
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 413 goto put_node;
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 414
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 415 parent = of_find_device_by_node(tegra_car_np);
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 416 if (parent) {
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 417 pdev = of_platform_device_create(np, dev_name, &parent->dev);
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 418 put_device(&parent->dev);
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 419
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 420 if (!pdev) {
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 421 pr_err("%s: failed to create device for %pOF\n",
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 422 __func__, np);
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 423 goto free_name;
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 424 }
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 425
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 426 dev = &pdev->dev;
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 427 pm_runtime_enable(dev);
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 428 } else {
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 429 WARN(1, "failed to find device for %pOF\n", tegra_car_np);
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 430 }
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 431
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 432 free_name:
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 433 kfree(dev_name);
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 434 put_node:
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 435 of_node_put(np);
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 436
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 @437 return clk_register(dev, hw);
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 438 }
b1bc04a2ac5b15 Dmitry Osipenko 2021-12-01 439
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v4 08/10] dmaengine: tegra: Use iommu-map for stream ID
From: Frank Li @ 2026-03-26 20:26 UTC (permalink / raw)
To: Akhil R
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Laxman Dewangan,
Philipp Zabel, dmaengine, devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260326110948.68908-9-akhilrajeev@nvidia.com>
On Thu, Mar 26, 2026 at 04:39:45PM +0530, Akhil R wrote:
> Use 'iommu-map', when provided, to get the stream ID to be programmed
> for each channel. Iterate over the channels registered and configure
> each channel device separately using of_dma_configure_id() to allow
> it to use a separate IOMMU domain for the transfer. But do this
> in a second loop since the first loop populates the DMA device channels
> list and async_device_register() registers the channels. Both are
> prerequisites for using the channel device in the next loop.
>
> Channels will continue to use the same global stream ID if the
> 'iommu-map' property is not present in the device tree.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> ---
...
> @@ -1490,6 +1496,41 @@ static int tegra_dma_probe(struct platform_device *pdev)
> return ret;
> }
>
> + /*
> + * Configure stream ID for each channel from the channels registered
> + * above. This is done in a separate iteration to ensure that only
> + * the channels available and registered for the DMA device are used.
> + */
> + list_for_each_entry(chan, &tdma->dma_dev.channels, device_node) {
> + chdev = &chan->dev->device;
> + tdc = to_tegra_dma_chan(chan);
> +
> + if (use_iommu_map) {
> + chdev->bus = pdev->dev.bus;
> + dma_coerce_mask_and_coherent(chdev, DMA_BIT_MASK(cdata->addr_bits));
> +
> + ret = of_dma_configure_id(chdev, pdev->dev.of_node,
> + true, &tdc->id);
> + if (ret) {
> + dev_err(chdev, "Failed to configure IOMMU for channel %d: %d\n",
> + tdc->id, ret);
> + return ret;
This is in probe funciton
return dev_err_probe();
Frank
^ permalink raw reply
* Re: [PATCHv2] firmware/tegra: add COMPILE_TEST
From: kernel test robot @ 2026-03-26 19:35 UTC (permalink / raw)
To: Rosen Penev, linux-tegra
Cc: oe-kbuild-all, Michael Turquette, Stephen Boyd, Thierry Reding,
Jonathan Hunter, linux-clk, linux-kernel
In-Reply-To: <20260324015722.12507-1-rosenp@gmail.com>
Hi Rosen,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20260325]
[cannot apply to tegra/for-next clk/clk-next drm-tegra/drm/tegra/for-next v7.0-rc5 v7.0-rc4 v7.0-rc3 linus/master v7.0-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Rosen-Penev/firmware-tegra-add-COMPILE_TEST/20260326-124230
base: next-20260325
patch link: https://lore.kernel.org/r/20260324015722.12507-1-rosenp%40gmail.com
patch subject: [PATCHv2] firmware/tegra: add COMPILE_TEST
config: sparc-allnoconfig (https://download.01.org/0day-ci/archive/20260327/202603270305.aMVfb5Bs-lkp@intel.com/config)
compiler: sparc-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260327/202603270305.aMVfb5Bs-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603270305.aMVfb5Bs-lkp@intel.com/
All errors (new ones prefixed by >>):
sparc-linux-ld: drivers/clk/tegra/clk.o: in function `tegra_register_devclks':
clk.c:(.text+0x4b0): undefined reference to `clk_register_clkdev'
>> sparc-linux-ld: clk.c:(.text+0x520): undefined reference to `__clk_get_name'
>> sparc-linux-ld: clk.c:(.text+0x530): undefined reference to `clk_register_clkdev'
sparc-linux-ld: drivers/clk/tegra/clk.o: in function `tegra_clk_dev_register':
clk.c:(.text+0x5fc): undefined reference to `clk_register'
>> sparc-linux-ld: clk.c:(.text+0x664): undefined reference to `clk_register'
sparc-linux-ld: drivers/clk/tegra/clk.o: in function `tegra_init_dup_clks':
clk.c:(.init.text+0x10c): undefined reference to `clkdev_add'
sparc-linux-ld: drivers/clk/tegra/clk.o: in function `tegra_add_of_provider':
clk.c:(.init.text+0x1a0): undefined reference to `of_clk_add_provider'
sparc-linux-ld: drivers/clk/tegra/clk-audio-sync.o: in function `tegra_clk_register_sync_source':
clk-audio-sync.c:(.text+0x128): undefined reference to `clk_register'
sparc-linux-ld: drivers/clk/tegra/clk-dfll.o: in function `tegra_dfll_unregister':
clk-dfll.c:(.text+0x19c): undefined reference to `of_clk_del_provider'
>> sparc-linux-ld: clk-dfll.c:(.text+0x1a4): undefined reference to `clk_unregister'
sparc-linux-ld: drivers/clk/tegra/clk-divider.o: in function `clk_divider_restore_context':
clk-divider.c:(.text+0x2c4): undefined reference to `clk_hw_get_parent'
>> sparc-linux-ld: clk-divider.c:(.text+0x2cc): undefined reference to `clk_hw_get_rate'
sparc-linux-ld: clk-divider.c:(.text+0x2d8): undefined reference to `clk_hw_get_rate'
sparc-linux-ld: drivers/clk/tegra/clk-divider.o: in function `tegra_clk_register_divider':
clk-divider.c:(.text+0x3b4): undefined reference to `clk_register'
sparc-linux-ld: drivers/clk/tegra/clk-divider.o: in function `tegra_clk_register_mc':
clk-divider.c:(.text+0x438): undefined reference to `clk_register_divider_table'
sparc-linux-ld: drivers/clk/tegra/clk-periph.o: in function `clk_periph_restore_context':
clk-periph.c:(.text+0x248): undefined reference to `clk_hw_get_parent_index'
sparc-linux-ld: drivers/clk/tegra/clk-periph.o: in function `tegra_clk_register_periph':
clk-periph.c:(.text+0x350): undefined reference to `clk_register'
>> sparc-linux-ld: clk-periph.c:(.text+0x3d4): undefined reference to `clk_register'
sparc-linux-ld: drivers/clk/tegra/clk-periph.o: in function `tegra_clk_register_periph_nodiv':
clk-periph.c:(.text+0x484): undefined reference to `clk_register'
sparc-linux-ld: drivers/clk/tegra/clk-periph.o: in function `tegra_clk_register_periph_data':
clk-periph.c:(.text+0x560): undefined reference to `clk_register'
sparc-linux-ld: clk-periph.c:(.text+0x5e4): undefined reference to `clk_register'
>> sparc-linux-ld: drivers/clk/tegra/clk-periph.o:(.rodata+0x94): undefined reference to `clk_hw_determine_rate_no_reparent'
sparc-linux-ld: drivers/clk/tegra/clk-periph-fixed.o: in function `tegra_clk_register_periph_fixed':
clk-periph-fixed.c:(.text+0x2fc): undefined reference to `clk_register'
sparc-linux-ld: drivers/clk/tegra/clk-periph-gate.o: in function `tegra_clk_register_periph_gate':
clk-periph-gate.c:(.text+0x448): undefined reference to `clk_register'
sparc-linux-ld: drivers/clk/tegra/clk-pll.o: in function `clk_pll_determine_rate':
clk-pll.c:(.text+0x764): undefined reference to `clk_hw_get_rate'
sparc-linux-ld: drivers/clk/tegra/clk-pll.o: in function `clk_pll_wait_for_lock':
clk-pll.c:(.text+0x860): undefined reference to `clk_hw_get_name'
sparc-linux-ld: drivers/clk/tegra/clk-pll.o: in function `clk_pllu_enable':
clk-pll.c:(.text+0x1244): undefined reference to `clk_hw_get_parent'
>> sparc-linux-ld: clk-pll.c:(.text+0x124c): undefined reference to `clk_hw_get_parent'
>> sparc-linux-ld: clk-pll.c:(.text+0x1260): undefined reference to `clk_hw_get_rate'
sparc-linux-ld: drivers/clk/tegra/clk-pll.o: in function `clk_pll_set_rate':
clk-pll.c:(.text+0x20d8): undefined reference to `clk_hw_get_name'
>> sparc-linux-ld: clk-pll.c:(.text+0x2110): undefined reference to `clk_hw_get_name'
sparc-linux-ld: drivers/clk/tegra/clk-pll.o: in function `tegra_clk_pll_restore_context':
clk-pll.c:(.text+0x2184): undefined reference to `clk_hw_get_parent'
sparc-linux-ld: clk-pll.c:(.text+0x218c): undefined reference to `clk_hw_get_rate'
sparc-linux-ld: clk-pll.c:(.text+0x2198): undefined reference to `clk_hw_get_rate'
>> sparc-linux-ld: clk-pll.c:(.text+0x21e4): undefined reference to `__clk_get_enable_count'
sparc-linux-ld: drivers/clk/tegra/clk-pll.o: in function `clk_pll_recalc_rate':
clk-pll.c:(.text+0x243c): undefined reference to `clk_hw_get_name'
sparc-linux-ld: clk-pll.c:(.text+0x248c): undefined reference to `clk_hw_get_name'
sparc-linux-ld: drivers/clk/tegra/clk-pll.o: in function `clk_plle_enable':
clk-pll.c:(.text+0x24f4): undefined reference to `clk_hw_get_parent'
sparc-linux-ld: clk-pll.c:(.text+0x24fc): undefined reference to `clk_hw_get_rate'
sparc-linux-ld: drivers/clk/tegra/clk-pll-out.o: in function `tegra_clk_pll_out_restore_context':
clk-pll-out.c:(.text+0x284): undefined reference to `__clk_get_enable_count'
sparc-linux-ld: drivers/clk/tegra/clk-pll-out.o: in function `tegra_clk_register_pll_out':
clk-pll-out.c:(.text+0x364): undefined reference to `clk_register'
sparc-linux-ld: drivers/clk/tegra/clk-sdmmc-mux.o: in function `clk_sdmmc_mux_get_parent':
clk-sdmmc-mux.c:(.text+0x244): undefined reference to `clk_hw_get_num_parents'
sparc-linux-ld: drivers/clk/tegra/clk-sdmmc-mux.o: in function `clk_sdmmc_mux_restore_context':
clk-sdmmc-mux.c:(.text+0x4c4): undefined reference to `clk_hw_get_parent'
>> sparc-linux-ld: clk-sdmmc-mux.c:(.text+0x4cc): undefined reference to `clk_hw_get_rate'
sparc-linux-ld: clk-sdmmc-mux.c:(.text+0x4d8): undefined reference to `clk_hw_get_rate'
>> sparc-linux-ld: clk-sdmmc-mux.c:(.text+0x4e4): undefined reference to `clk_hw_get_parent_index'
sparc-linux-ld: drivers/clk/tegra/clk-sdmmc-mux.o: in function `tegra_clk_register_sdmmc_mux_div':
clk-sdmmc-mux.c:(.text+0x5f8): undefined reference to `clk_register'
sparc-linux-ld: drivers/clk/tegra/clk-super.o: in function `clk_super_restore_context':
clk-super.c:(.text+0x404): undefined reference to `clk_hw_get_parent_index'
sparc-linux-ld: drivers/clk/tegra/clk-super.o: in function `clk_super_mux_restore_context':
clk-super.c:(.text+0x484): undefined reference to `clk_hw_get_parent_index'
sparc-linux-ld: drivers/clk/tegra/clk-super.o: in function `tegra_clk_register_super_clk':
clk-super.c:(.text+0x620): undefined reference to `clk_register'
>> sparc-linux-ld: drivers/clk/tegra/clk-super.o:(.rodata+0x94): undefined reference to `clk_hw_determine_rate_no_reparent'
sparc-linux-ld: drivers/clk/tegra/clk-tegra-audio.o: in function `tegra_audio_sync_clk_init.constprop.0':
clk-tegra-audio.c:(.init.text+0x54): undefined reference to `clk_register_mux_table'
>> sparc-linux-ld: clk-tegra-audio.c:(.init.text+0x94): undefined reference to `clk_register_gate'
sparc-linux-ld: drivers/clk/tegra/clk-tegra-audio.o: in function `tegra_audio_clk_init':
clk-tegra-audio.c:(.init.text+0x29c): undefined reference to `clk_register_fixed_factor'
>> sparc-linux-ld: drivers/clk/tegra/clk-tegra-periph.o:(.data+0x10c): undefined reference to `clk_mux_ops'
sparc-linux-ld: drivers/clk/tegra/clk-tegra-periph.o:(.data+0x1a4): undefined reference to `clk_mux_ops'
sparc-linux-ld: drivers/clk/tegra/clk-tegra-periph.o:(.data+0x23c): undefined reference to `clk_mux_ops'
sparc-linux-ld: drivers/clk/tegra/clk-tegra-periph.o:(.data+0x2d4): undefined reference to `clk_mux_ops'
sparc-linux-ld: drivers/clk/tegra/clk-tegra-periph.o:(.data+0x36c): undefined reference to `clk_mux_ops'
sparc-linux-ld: drivers/clk/tegra/clk-tegra-periph.o:(.data+0x404): more undefined references to `clk_mux_ops' follow
sparc-linux-ld: drivers/clk/tegra/clk-tegra-periph.o: in function `init_pllp':
clk-tegra-periph.c:(.init.text+0x48): undefined reference to `clk_register_clkdev'
>> sparc-linux-ld: clk-tegra-periph.c:(.init.text+0x1c8): undefined reference to `clk_register_gate'
sparc-linux-ld: clk-tegra-periph.c:(.init.text+0x20c): undefined reference to `clk_register_gate'
>> sparc-linux-ld: clk-tegra-periph.c:(.init.text+0x21c): undefined reference to `clk_register_clkdev'
sparc-linux-ld: drivers/clk/tegra/clk-tegra-fixed.o: in function `tegra_osc_clk_init':
clk-tegra-fixed.c:(.init.text+0x98): undefined reference to `clk_register_fixed_rate'
>> sparc-linux-ld: clk-tegra-fixed.c:(.init.text+0xd0): undefined reference to `clk_register_fixed_factor'
sparc-linux-ld: clk-tegra-fixed.c:(.init.text+0x108): undefined reference to `clk_register_fixed_factor'
sparc-linux-ld: clk-tegra-fixed.c:(.init.text+0x140): undefined reference to `clk_register_fixed_factor'
sparc-linux-ld: clk-tegra-fixed.c:(.init.text+0x184): undefined reference to `clk_register_fixed_factor'
sparc-linux-ld: drivers/clk/tegra/clk-tegra-fixed.o: in function `tegra_fixed_clk_init':
clk-tegra-fixed.c:(.init.text+0x1d8): undefined reference to `clk_register_fixed_rate'
sparc-linux-ld: drivers/clk/tegra/clk-tegra-super-cclk.o: in function `cclk_super_determine_rate':
clk-tegra-super-cclk.c:(.text+0xc8): undefined reference to `clk_hw_get_parent_by_index'
>> sparc-linux-ld: clk-tegra-super-cclk.c:(.text+0xd8): undefined reference to `clk_hw_get_parent_by_index'
sparc-linux-ld: clk-tegra-super-cclk.c:(.text+0xfc): undefined reference to `clk_hw_get_rate'
sparc-linux-ld: clk-tegra-super-cclk.c:(.text+0x144): undefined reference to `clk_hw_round_rate'
sparc-linux-ld: clk-tegra-super-cclk.c:(.text+0x194): undefined reference to `clk_hw_get_rate_range'
sparc-linux-ld: drivers/clk/tegra/clk-tegra-super-cclk.o: in function `tegra_clk_register_super_cclk':
clk-tegra-super-cclk.c:(.text+0x420): undefined reference to `clk_register'
sparc-linux-ld: drivers/clk/tegra/clk-tegra-super-gen4.o: in function `tegra_sclk_init':
clk-tegra-super-gen4.c:(.init.text+0x98): undefined reference to `clk_register_divider_table'
sparc-linux-ld: clk-tegra-super-gen4.c:(.init.text+0x140): undefined reference to `clk_register_divider_table'
sparc-linux-ld: clk-tegra-super-gen4.c:(.init.text+0x16c): undefined reference to `clk_register_gate'
sparc-linux-ld: clk-tegra-super-gen4.c:(.init.text+0x1c4): undefined reference to `clk_register_divider_table'
sparc-linux-ld: clk-tegra-super-gen4.c:(.init.text+0x1f0): undefined reference to `clk_register_gate'
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCHv2] firmware/tegra: add COMPILE_TEST
From: kernel test robot @ 2026-03-26 19:35 UTC (permalink / raw)
To: Rosen Penev, linux-tegra
Cc: oe-kbuild-all, Michael Turquette, Stephen Boyd, Thierry Reding,
Jonathan Hunter, linux-clk, linux-kernel
In-Reply-To: <20260324015722.12507-1-rosenp@gmail.com>
Hi Rosen,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20260325]
[cannot apply to tegra/for-next clk/clk-next drm-tegra/drm/tegra/for-next v7.0-rc5 v7.0-rc4 v7.0-rc3 linus/master v7.0-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Rosen-Penev/firmware-tegra-add-COMPILE_TEST/20260326-124230
base: next-20260325
patch link: https://lore.kernel.org/r/20260324015722.12507-1-rosenp%40gmail.com
patch subject: [PATCHv2] firmware/tegra: add COMPILE_TEST
config: parisc-allnoconfig (https://download.01.org/0day-ci/archive/20260327/202603270355.rxjFONcV-lkp@intel.com/config)
compiler: hppa-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260327/202603270355.rxjFONcV-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603270355.rxjFONcV-lkp@intel.com/
All errors (new ones prefixed by >>):
hppa-linux-ld: drivers/clk/tegra/clk.o: in function `tegra_register_devclks':
>> (.text+0x348): undefined reference to `clk_register_clkdev'
>> hppa-linux-ld: (.text+0x398): undefined reference to `__clk_get_name'
>> hppa-linux-ld: (.text+0x3a8): undefined reference to `clk_register_clkdev'
hppa-linux-ld: drivers/clk/tegra/clk.o: in function `tegra_clk_dev_register':
>> (.text+0x438): undefined reference to `clk_register'
hppa-linux-ld: drivers/clk/tegra/clk.o: in function `tegra_init_dup_clks':
>> (.init.text+0x114): undefined reference to `clkdev_add'
hppa-linux-ld: drivers/clk/tegra/clk-tegra-audio.o: in function `tegra_audio_sync_clk_init.constprop.0':
>> (.init.text+0x90): undefined reference to `clk_register_mux_table'
>> hppa-linux-ld: (.init.text+0xd0): undefined reference to `clk_register_gate'
hppa-linux-ld: drivers/clk/tegra/clk-tegra-audio.o: in function `tegra_audio_clk_init':
>> (.init.text+0x348): undefined reference to `clk_register_fixed_factor'
>> hppa-linux-ld: drivers/clk/tegra/clk-tegra-periph.o:(.data+0x10c): undefined reference to `clk_mux_ops'
hppa-linux-ld: drivers/clk/tegra/clk-tegra-periph.o:(.data+0x1a4): undefined reference to `clk_mux_ops'
hppa-linux-ld: drivers/clk/tegra/clk-tegra-periph.o:(.data+0x23c): undefined reference to `clk_mux_ops'
hppa-linux-ld: drivers/clk/tegra/clk-tegra-periph.o:(.data+0x2d4): undefined reference to `clk_mux_ops'
hppa-linux-ld: drivers/clk/tegra/clk-tegra-periph.o:(.data+0x36c): undefined reference to `clk_mux_ops'
hppa-linux-ld: drivers/clk/tegra/clk-tegra-periph.o:(.data+0x404): more undefined references to `clk_mux_ops' follow
hppa-linux-ld: drivers/clk/tegra/clk-tegra-periph.o: in function `init_pllp':
>> (.init.text+0x7c): undefined reference to `clk_register_clkdev'
hppa-linux-ld: (.init.text+0x204): undefined reference to `clk_register_gate'
hppa-linux-ld: (.init.text+0x24c): undefined reference to `clk_register_gate'
>> hppa-linux-ld: (.init.text+0x260): undefined reference to `clk_register_clkdev'
hppa-linux-ld: drivers/clk/tegra/clk-tegra-fixed.o: in function `tegra_osc_clk_init':
>> (.init.text+0x9c): undefined reference to `clk_register_fixed_rate'
>> hppa-linux-ld: (.init.text+0xd8): undefined reference to `clk_register_fixed_factor'
hppa-linux-ld: (.init.text+0x114): undefined reference to `clk_register_fixed_factor'
hppa-linux-ld: (.init.text+0x150): undefined reference to `clk_register_fixed_factor'
hppa-linux-ld: (.init.text+0x194): undefined reference to `clk_register_fixed_factor'
hppa-linux-ld: drivers/clk/tegra/clk-tegra-fixed.o: in function `tegra_fixed_clk_init':
(.init.text+0x20c): undefined reference to `clk_register_fixed_rate'
hppa-linux-ld: drivers/clk/tegra/clk-tegra-super-gen4.o: in function `tegra_sclk_init':
>> (.init.text+0xb8): undefined reference to `clk_register_divider_table'
>> hppa-linux-ld: (.init.text+0x164): undefined reference to `clk_register_divider_table'
hppa-linux-ld: (.init.text+0x194): undefined reference to `clk_register_gate'
hppa-linux-ld: (.init.text+0x1ec): undefined reference to `clk_register_divider_table'
hppa-linux-ld: (.init.text+0x21c): undefined reference to `clk_register_gate'
hppa-linux-ld: drivers/clk/tegra/clk-audio-sync.o: in function `tegra_clk_register_sync_source':
(.text+0x13c): undefined reference to `clk_register'
hppa-linux-ld: drivers/clk/tegra/clk-dfll.o: in function `tegra_dfll_unregister':
>> (.text+0x1d8): undefined reference to `clk_unregister'
hppa-linux-ld: drivers/clk/tegra/clk-divider.o: in function `clk_divider_restore_context':
>> (.text+0x2c8): undefined reference to `clk_hw_get_parent'
>> hppa-linux-ld: (.text+0x2d0): undefined reference to `clk_hw_get_rate'
hppa-linux-ld: (.text+0x2dc): undefined reference to `clk_hw_get_rate'
hppa-linux-ld: drivers/clk/tegra/clk-divider.o: in function `tegra_clk_register_divider':
(.text+0x3d0): undefined reference to `clk_register'
hppa-linux-ld: drivers/clk/tegra/clk-divider.o: in function `tegra_clk_register_mc':
>> (.text+0x4c4): undefined reference to `clk_register_divider_table'
hppa-linux-ld: drivers/clk/tegra/clk-periph.o: in function `clk_periph_restore_context':
>> (.text+0x254): undefined reference to `clk_hw_get_parent_index'
hppa-linux-ld: drivers/clk/tegra/clk-periph.o: in function `tegra_clk_register_periph':
(.text+0x3bc): undefined reference to `clk_register'
hppa-linux-ld: (.text+0x420): undefined reference to `clk_register'
hppa-linux-ld: drivers/clk/tegra/clk-periph.o: in function `tegra_clk_register_periph_nodiv':
(.text+0x528): undefined reference to `clk_register'
hppa-linux-ld: drivers/clk/tegra/clk-periph.o: in function `tegra_clk_register_periph_data':
(.text+0x648): undefined reference to `clk_register'
hppa-linux-ld: (.text+0x6b0): undefined reference to `clk_register'
hppa-linux-ld: drivers/clk/tegra/clk-periph.o:(.rodata+0x94): undefined reference to `clk_hw_determine_rate_no_reparent'
hppa-linux-ld: drivers/clk/tegra/clk-periph-fixed.o: in function `tegra_clk_register_periph_fixed':
(.text+0x250): undefined reference to `clk_register'
hppa-linux-ld: drivers/clk/tegra/clk-periph-gate.o: in function `tegra_clk_register_periph_gate':
(.text+0x35c): undefined reference to `clk_register'
hppa-linux-ld: drivers/clk/tegra/clk-pll.o: in function `clk_pll_determine_rate':
(.text+0x6c4): undefined reference to `clk_hw_get_rate'
hppa-linux-ld: drivers/clk/tegra/clk-pll.o: in function `clk_pll_wait_for_lock':
(.text+0x7c0): undefined reference to `clk_hw_get_name'
hppa-linux-ld: drivers/clk/tegra/clk-pll.o: in function `clk_pllu_enable':
(.text+0xed0): undefined reference to `clk_hw_get_parent'
hppa-linux-ld: (.text+0xed8): undefined reference to `clk_hw_get_parent'
hppa-linux-ld: (.text+0xee8): undefined reference to `clk_hw_get_rate'
hppa-linux-ld: drivers/clk/tegra/clk-pll.o: in function `clk_pll_recalc_rate':
(.text+0x17c4): undefined reference to `clk_hw_get_name'
hppa-linux-ld: (.text+0x1818): undefined reference to `clk_hw_get_name'
hppa-linux-ld: drivers/clk/tegra/clk-pll.o: in function `clk_pll_set_rate':
(.text+0x1d54): undefined reference to `clk_hw_get_name'
hppa-linux-ld: (.text+0x1d84): undefined reference to `clk_hw_get_name'
hppa-linux-ld: drivers/clk/tegra/clk-pll.o: in function `tegra_clk_pll_restore_context':
(.text+0x1dcc): undefined reference to `clk_hw_get_parent'
hppa-linux-ld: (.text+0x1dd4): undefined reference to `clk_hw_get_rate'
hppa-linux-ld: (.text+0x1de0): undefined reference to `clk_hw_get_rate'
hppa-linux-ld: (.text+0x1e20): undefined reference to `__clk_get_enable_count'
hppa-linux-ld: drivers/clk/tegra/clk-pll.o: in function `clk_plle_enable':
(.text+0x1ed0): undefined reference to `clk_hw_get_parent'
hppa-linux-ld: (.text+0x1ed8): undefined reference to `clk_hw_get_rate'
hppa-linux-ld: drivers/clk/tegra/clk-pll-out.o: in function `tegra_clk_pll_out_restore_context':
(.text+0x1cc): undefined reference to `__clk_get_enable_count'
hppa-linux-ld: drivers/clk/tegra/clk-pll-out.o: in function `tegra_clk_register_pll_out':
(.text+0x2cc): undefined reference to `clk_register'
hppa-linux-ld: drivers/clk/tegra/clk-sdmmc-mux.o: in function `clk_sdmmc_mux_get_parent':
(.text+0x248): undefined reference to `clk_hw_get_num_parents'
hppa-linux-ld: drivers/clk/tegra/clk-sdmmc-mux.o: in function `clk_sdmmc_mux_restore_context':
(.text+0x48c): undefined reference to `clk_hw_get_parent'
hppa-linux-ld: (.text+0x494): undefined reference to `clk_hw_get_rate'
hppa-linux-ld: (.text+0x4a0): undefined reference to `clk_hw_get_rate'
hppa-linux-ld: (.text+0x4ac): undefined reference to `clk_hw_get_parent_index'
hppa-linux-ld: drivers/clk/tegra/clk-sdmmc-mux.o: in function `tegra_clk_register_sdmmc_mux_div':
(.text+0x5f4): undefined reference to `clk_register'
hppa-linux-ld: drivers/clk/tegra/clk-super.o: in function `clk_super_restore_context':
(.text+0x38c): undefined reference to `clk_hw_get_parent_index'
hppa-linux-ld: drivers/clk/tegra/clk-super.o: in function `clk_super_mux_restore_context':
(.text+0x408): undefined reference to `clk_hw_get_parent_index'
hppa-linux-ld: drivers/clk/tegra/clk-super.o: in function `tegra_clk_register_super_clk':
(.text+0x658): undefined reference to `clk_register'
hppa-linux-ld: drivers/clk/tegra/clk-super.o:(.rodata+0x94): undefined reference to `clk_hw_determine_rate_no_reparent'
hppa-linux-ld: drivers/clk/tegra/clk-tegra-super-cclk.o: in function `cclk_super_determine_rate':
(.text+0xe0): undefined reference to `clk_hw_get_parent_by_index'
hppa-linux-ld: (.text+0xf0): undefined reference to `clk_hw_get_parent_by_index'
hppa-linux-ld: (.text+0x10c): undefined reference to `clk_hw_get_rate'
hppa-linux-ld: (.text+0x184): undefined reference to `clk_hw_get_rate_range'
hppa-linux-ld: (.text+0x1b0): undefined reference to `clk_hw_round_rate'
hppa-linux-ld: drivers/clk/tegra/clk-tegra-super-cclk.o: in function `tegra_clk_register_super_cclk':
(.text+0x3c8): undefined reference to `clk_register'
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v9 1/5] PCI: Add pcie_get_link_speed() helper for safe array access
From: Manivannan Sadhasivam @ 2026-03-26 18:32 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Hans Zhang, lpieralisi, jingoohan1, kwilczynski, bhelgaas,
florian.fainelli, jim2101024, robh, ilpo.jarvinen, linux-arm-msm,
linux-arm-kernel, linux-renesas-soc, claudiu.beznea.uj,
linux-mediatek, linux-tegra, linux-omap, bcm-kernel-feedback-list,
linux-pci, linux-kernel, shawn.lin
In-Reply-To: <20260326181624.GA1331242@bhelgaas>
On Thu, Mar 26, 2026 at 01:16:24PM -0500, Bjorn Helgaas wrote:
> On Sat, Mar 14, 2026 at 12:55:18AM +0800, Hans Zhang wrote:
> > The pcie_link_speed[] array is indexed by PCIe generation numbers
> > (1 = 2.5 GT/s, 2 = 5 GT/s, ...). Several drivers use it directly,
> > which can lead to out-of-bounds accesses if an invalid generation
> > number is used.
> >
> > Introduce a helper function pcie_get_link_speed() that returns the
> > corresponding enum pci_bus_speed value for a given generation number,
> > or PCI_SPEED_UNKNOWN if the generation is out of range. This will
> > allow us to safely handle invalid values after the range check is
> > removed from of_pci_get_max_link_speed().
> >
> > Signed-off-by: Hans Zhang <18255117159@163.com>
> > ---
> > drivers/pci/pci.h | 2 ++
> > drivers/pci/probe.c | 16 ++++++++++++++++
> > 2 files changed, 18 insertions(+)
> >
> > diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> > index 13d998fbacce..409aca7d737a 100644
> > --- a/drivers/pci/pci.h
> > +++ b/drivers/pci/pci.h
> > @@ -108,6 +108,8 @@ struct pcie_tlp_log;
> > PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
> >
> > extern const unsigned char pcie_link_speed[];
> > +unsigned char pcie_get_link_speed(unsigned int speed);
> > +
> > extern bool pci_early_dump;
> >
> > extern struct mutex pci_rescan_remove_lock;
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index bccc7a4bdd79..d6592898330c 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -783,6 +783,22 @@ const unsigned char pcie_link_speed[] = {
> > };
> > EXPORT_SYMBOL_GPL(pcie_link_speed);
> >
> > +/**
> > + * pcie_link_speed_value - Get speed value from PCIe generation number
>
> Wrong name here (pcie_link_speed_value vs pcie_get_link_speed)
> (pointed out by Sashiko).
>
Noticed this one while applying.
> > + * @speed: PCIe speed (1-based: 1 = 2.5GT, 2 = 5GT, ...)
> > + *
> > + * Returns the speed value (e.g., PCIE_SPEED_2_5GT) if @speed is valid,
> > + * otherwise returns PCI_SPEED_UNKNOWN.
> > + */
> > +unsigned char pcie_get_link_speed(unsigned int speed)
>
> Sashiko also pointed out that the commit log says this returns "enum
> pci_bus_speed", while here we return unsigned char (which is also the
> type of pcie_link_speed[x]).
>
> https://sashiko.dev/#/patchset/20260313165522.123518-1-18255117159%40163.com
>
This one I didn't, but fixed now, thanks!
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v9 0/5] PCI: of: Remove max-link-speed generation validation
From: Manivannan Sadhasivam @ 2026-03-26 18:29 UTC (permalink / raw)
To: lpieralisi, jingoohan1, kwilczynski, bhelgaas, helgaas,
florian.fainelli, jim2101024, Hans Zhang
Cc: robh, ilpo.jarvinen, linux-arm-msm, linux-arm-kernel,
linux-renesas-soc, claudiu.beznea.uj, linux-mediatek, linux-tegra,
linux-omap, bcm-kernel-feedback-list, linux-pci, linux-kernel,
shawn.lin
In-Reply-To: <20260313165522.123518-1-18255117159@163.com>
On Sat, 14 Mar 2026 00:55:17 +0800, Hans Zhang wrote:
> This series moves the validation from the common OF function to the
> individual PCIe controller drivers. To protect against out-of-bounds
> accesses to the pcie_link_speed[] array, we first introduce a helper
> function pcie_get_link_speed() that safely returns the speed value
> (or PCI_SPEED_UNKNOWN) for a given generation number.
>
> Then all direct uses of pcie_link_speed[] as an array are converted to
> use the new helper, ensuring that even if an invalid generation number
> reaches those code paths, no out-of-bounds access occurs.
>
> [...]
Applied, thanks!
[1/5] PCI: Add pcie_get_link_speed() helper for safe array access
commit: df61f4732adf9de5ad1f5e71b7670710c1597d18
[2/5] PCI: dwc: Use pcie_get_link_speed() helper for safe array access
commit: d884b0e51459175f17ddc52759ea4533bb752130
[3/5] PCI: j721e: Validate max-link-speed from DT
commit: 1542ac6d83d0b5706f45e2937de7b4f7b8c4831d
[4/5] PCI: controller: Validate max-link-speed
commit: d0cc5918a1d539344190cbb19fa3ae0e7b0dca1e
[5/5] PCI: of: Remove max-link-speed generation validation
commit: 15217c7015c0e1804925693c55d721aad8987e32
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* Re: [PATCH v9 1/5] PCI: Add pcie_get_link_speed() helper for safe array access
From: Bjorn Helgaas @ 2026-03-26 18:16 UTC (permalink / raw)
To: Hans Zhang
Cc: lpieralisi, jingoohan1, mani, kwilczynski, bhelgaas,
florian.fainelli, jim2101024, robh, ilpo.jarvinen, linux-arm-msm,
linux-arm-kernel, linux-renesas-soc, claudiu.beznea.uj,
linux-mediatek, linux-tegra, linux-omap, bcm-kernel-feedback-list,
linux-pci, linux-kernel, shawn.lin
In-Reply-To: <20260313165522.123518-2-18255117159@163.com>
On Sat, Mar 14, 2026 at 12:55:18AM +0800, Hans Zhang wrote:
> The pcie_link_speed[] array is indexed by PCIe generation numbers
> (1 = 2.5 GT/s, 2 = 5 GT/s, ...). Several drivers use it directly,
> which can lead to out-of-bounds accesses if an invalid generation
> number is used.
>
> Introduce a helper function pcie_get_link_speed() that returns the
> corresponding enum pci_bus_speed value for a given generation number,
> or PCI_SPEED_UNKNOWN if the generation is out of range. This will
> allow us to safely handle invalid values after the range check is
> removed from of_pci_get_max_link_speed().
>
> Signed-off-by: Hans Zhang <18255117159@163.com>
> ---
> drivers/pci/pci.h | 2 ++
> drivers/pci/probe.c | 16 ++++++++++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 13d998fbacce..409aca7d737a 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -108,6 +108,8 @@ struct pcie_tlp_log;
> PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
>
> extern const unsigned char pcie_link_speed[];
> +unsigned char pcie_get_link_speed(unsigned int speed);
> +
> extern bool pci_early_dump;
>
> extern struct mutex pci_rescan_remove_lock;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index bccc7a4bdd79..d6592898330c 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -783,6 +783,22 @@ const unsigned char pcie_link_speed[] = {
> };
> EXPORT_SYMBOL_GPL(pcie_link_speed);
>
> +/**
> + * pcie_link_speed_value - Get speed value from PCIe generation number
Wrong name here (pcie_link_speed_value vs pcie_get_link_speed)
(pointed out by Sashiko).
> + * @speed: PCIe speed (1-based: 1 = 2.5GT, 2 = 5GT, ...)
> + *
> + * Returns the speed value (e.g., PCIE_SPEED_2_5GT) if @speed is valid,
> + * otherwise returns PCI_SPEED_UNKNOWN.
> + */
> +unsigned char pcie_get_link_speed(unsigned int speed)
Sashiko also pointed out that the commit log says this returns "enum
pci_bus_speed", while here we return unsigned char (which is also the
type of pcie_link_speed[x]).
https://sashiko.dev/#/patchset/20260313165522.123518-1-18255117159%40163.com
> +{
> + if (speed >= ARRAY_SIZE(pcie_link_speed))
> + return PCI_SPEED_UNKNOWN;
> +
> + return pcie_link_speed[speed];
> +}
> +EXPORT_SYMBOL_GPL(pcie_get_link_speed);
> +
> const char *pci_speed_string(enum pci_bus_speed speed)
> {
> /* Indexed by the pci_bus_speed enum */
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v9 1/5] PCI: Add pcie_get_link_speed() helper for safe array access
From: Bjorn Helgaas @ 2026-03-26 18:09 UTC (permalink / raw)
To: Hans Zhang
Cc: lpieralisi, jingoohan1, mani, kwilczynski, bhelgaas,
florian.fainelli, jim2101024, robh, ilpo.jarvinen, linux-arm-msm,
linux-arm-kernel, linux-renesas-soc, claudiu.beznea.uj,
linux-mediatek, linux-tegra, linux-omap, bcm-kernel-feedback-list,
linux-pci, linux-kernel, shawn.lin
In-Reply-To: <20260313165522.123518-2-18255117159@163.com>
On Sat, Mar 14, 2026 at 12:55:18AM +0800, Hans Zhang wrote:
> The pcie_link_speed[] array is indexed by PCIe generation numbers
> (1 = 2.5 GT/s, 2 = 5 GT/s, ...). Several drivers use it directly,
> which can lead to out-of-bounds accesses if an invalid generation
> number is used.
>
> Introduce a helper function pcie_get_link_speed() that returns the
> corresponding enum pci_bus_speed value for a given generation number,
> or PCI_SPEED_UNKNOWN if the generation is out of range. This will
> allow us to safely handle invalid values after the range check is
> removed from of_pci_get_max_link_speed().
>
> Signed-off-by: Hans Zhang <18255117159@163.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> drivers/pci/pci.h | 2 ++
> drivers/pci/probe.c | 16 ++++++++++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 13d998fbacce..409aca7d737a 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -108,6 +108,8 @@ struct pcie_tlp_log;
> PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
>
> extern const unsigned char pcie_link_speed[];
> +unsigned char pcie_get_link_speed(unsigned int speed);
> +
> extern bool pci_early_dump;
>
> extern struct mutex pci_rescan_remove_lock;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index bccc7a4bdd79..d6592898330c 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -783,6 +783,22 @@ const unsigned char pcie_link_speed[] = {
> };
> EXPORT_SYMBOL_GPL(pcie_link_speed);
>
> +/**
> + * pcie_link_speed_value - Get speed value from PCIe generation number
> + * @speed: PCIe speed (1-based: 1 = 2.5GT, 2 = 5GT, ...)
> + *
> + * Returns the speed value (e.g., PCIE_SPEED_2_5GT) if @speed is valid,
> + * otherwise returns PCI_SPEED_UNKNOWN.
> + */
> +unsigned char pcie_get_link_speed(unsigned int speed)
> +{
> + if (speed >= ARRAY_SIZE(pcie_link_speed))
> + return PCI_SPEED_UNKNOWN;
> +
> + return pcie_link_speed[speed];
> +}
> +EXPORT_SYMBOL_GPL(pcie_get_link_speed);
> +
> const char *pci_speed_string(enum pci_bus_speed speed)
> {
> /* Indexed by the pci_bus_speed enum */
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v9 1/5] PCI: Add pcie_get_link_speed() helper for safe array access
From: Manivannan Sadhasivam @ 2026-03-26 17:40 UTC (permalink / raw)
To: Hans Zhang, bhelgaas, helgaas
Cc: lpieralisi, jingoohan1, kwilczynski, florian.fainelli, jim2101024,
robh, ilpo.jarvinen, linux-arm-msm, linux-arm-kernel,
linux-renesas-soc, claudiu.beznea.uj, linux-mediatek, linux-tegra,
linux-omap, bcm-kernel-feedback-list, linux-pci, linux-kernel,
shawn.lin
In-Reply-To: <20260313165522.123518-2-18255117159@163.com>
On Sat, Mar 14, 2026 at 12:55:18AM +0800, Hans Zhang wrote:
> The pcie_link_speed[] array is indexed by PCIe generation numbers
> (1 = 2.5 GT/s, 2 = 5 GT/s, ...). Several drivers use it directly,
> which can lead to out-of-bounds accesses if an invalid generation
> number is used.
>
> Introduce a helper function pcie_get_link_speed() that returns the
> corresponding enum pci_bus_speed value for a given generation number,
> or PCI_SPEED_UNKNOWN if the generation is out of range. This will
> allow us to safely handle invalid values after the range check is
> removed from of_pci_get_max_link_speed().
>
Bjorn: Could you please take a look at this patch and ack if looks good? Rest of
the patches look good to me (I might squash patch 5 with 4 while applying).
- Mani
> Signed-off-by: Hans Zhang <18255117159@163.com>
> ---
> drivers/pci/pci.h | 2 ++
> drivers/pci/probe.c | 16 ++++++++++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 13d998fbacce..409aca7d737a 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -108,6 +108,8 @@ struct pcie_tlp_log;
> PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
>
> extern const unsigned char pcie_link_speed[];
> +unsigned char pcie_get_link_speed(unsigned int speed);
> +
> extern bool pci_early_dump;
>
> extern struct mutex pci_rescan_remove_lock;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index bccc7a4bdd79..d6592898330c 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -783,6 +783,22 @@ const unsigned char pcie_link_speed[] = {
> };
> EXPORT_SYMBOL_GPL(pcie_link_speed);
>
> +/**
> + * pcie_link_speed_value - Get speed value from PCIe generation number
> + * @speed: PCIe speed (1-based: 1 = 2.5GT, 2 = 5GT, ...)
> + *
> + * Returns the speed value (e.g., PCIE_SPEED_2_5GT) if @speed is valid,
> + * otherwise returns PCI_SPEED_UNKNOWN.
> + */
> +unsigned char pcie_get_link_speed(unsigned int speed)
> +{
> + if (speed >= ARRAY_SIZE(pcie_link_speed))
> + return PCI_SPEED_UNKNOWN;
> +
> + return pcie_link_speed[speed];
> +}
> +EXPORT_SYMBOL_GPL(pcie_get_link_speed);
> +
> const char *pci_speed_string(enum pci_bus_speed speed)
> {
> /* Indexed by the pci_bus_speed enum */
> --
> 2.34.1
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 0/2] PCI: dwc: Add multi-port controller support
From: Manivannan Sadhasivam @ 2026-03-26 16:56 UTC (permalink / raw)
To: Sumit Kumar
Cc: Bjorn Helgaas, Jingoo Han, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Krzysztof Kozlowski,
Alim Akhtar, Richard Zhu, Lucas Stach, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Yue Wang, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Paul Walmsley,
Greentime Hu, Samuel Holland, Chuanhua Lei, Marek Vasut,
Yoshihiro Shimoda, Geert Uytterhoeven, Magnus Damm,
Pratyush Anand, Thierry Reding, Jonathan Hunter, linux-pci,
linux-kernel, linux-arm-kernel, linux-samsung-soc, imx,
linux-amlogic, linux-arm-msm, linux-renesas-soc, linux-tegra,
linux-riscv
In-Reply-To: <20260305-dt-parser-v2-0-85836db8dc06@oss.qualcomm.com>
On Thu, Mar 05, 2026 at 11:50:35AM +0530, Sumit Kumar wrote:
> This series adds support for multi-port PCIe controllers in the DesignWare
> driver. Currently, the driver only supports a single Root Port with
> controller-level properties, which doesn't work for multi-port controllers
> where each port may have different configurations.
>
> This series introduces a per-port structure and parsing API that allows
> each Root Port to be configured independently via pcie@N child nodes in
> device tree, while maintaining backward compatibility with existing
> single-port bindings.
>
This patch touches multiple host controller drivers. I'd appreciate if the
platform maintainers could test this series and give their tested-by tag to make
sure we don't regress.
- Mani
> Signed-off-by: Sumit Kumar <sumit.kumar@oss.qualcomm.com>
> ---
> Changes in v2:
> - Fix error code preservation in dw_pcie_resume_noirq() to return actual
> error from dw_pcie_wait_for_link() instead of hardcoded -ETIMEDOUT (Mani).
> - Initialize ret variable to -ENOENT in dw_pcie_parse_root_ports() (Mani).
> - dw_pcie_host_init(): Remove -ENOENT error skipping to make parsing
> failures fatal for now, add TODO comment about making properties
> optional later (Mani).
> - Link to v1: https://lore.kernel.org/r/20260105-dt-parser-v1-0-b11c63cb5e2c@oss.qualcomm.com
>
> ---
> Sumit Kumar (2):
> PCI: API changes for multi-port controller support
> PCI: dwc: Add multi-port controller support
>
> drivers/pci/controller/dwc/pci-exynos.c | 4 +-
> drivers/pci/controller/dwc/pci-imx6.c | 15 +-
> drivers/pci/controller/dwc/pci-meson.c | 1 -
> drivers/pci/controller/dwc/pcie-designware-host.c | 175 ++++++++++++++++++----
> drivers/pci/controller/dwc/pcie-designware.c | 32 ++--
> drivers/pci/controller/dwc/pcie-designware.h | 17 ++-
> drivers/pci/controller/dwc/pcie-fu740.c | 6 +-
> drivers/pci/controller/dwc/pcie-intel-gw.c | 13 +-
> drivers/pci/controller/dwc/pcie-qcom-common.c | 5 +-
> drivers/pci/controller/dwc/pcie-qcom-ep.c | 4 +-
> drivers/pci/controller/dwc/pcie-qcom.c | 4 +-
> drivers/pci/controller/dwc/pcie-rcar-gen4.c | 13 +-
> drivers/pci/controller/dwc/pcie-spear13xx.c | 5 +-
> drivers/pci/controller/dwc/pcie-tegra194.c | 4 +-
> drivers/pci/of.c | 6 +-
> drivers/pci/pci.h | 2 +
> 16 files changed, 232 insertions(+), 74 deletions(-)
> ---
> base-commit: 097a6c336d0080725c626fda118ecfec448acd0f
> change-id: 20251010-dt-parser-98b50ce18fc1
>
> Best regards,
> --
> Sumit Kumar <sumit.kumar@oss.qualcomm.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