* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Mark Brown @ 2026-03-23 19:58 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vinod Koul, Neil Armstrong, Liam Girdwood, Lee Jones,
Pavel Machek, Peter Rosin, Andrew Lunn, Heiner Kallweit,
Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <acGWJf1AGXT1xduM@google.com>
[-- Attachment #1.1: Type: text/plain, Size: 1545 bytes --]
On Mon, Mar 23, 2026 at 12:41:59PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 23, 2026 at 07:05:13PM +0000, Mark Brown wrote:
> > I think this is a worrying idea for core code like this, we have
> > specific firmware bindings for specific firmware interfaces with the
> > different interfaces having very different ideas of how things should be
> > modelled. The chances that firmware agnostic code is going to do the
> > right thing seem low, and encouraging the use of generic APIs that might
> > happen to run OK raises the risk that we'll get firmware vendors relying
> > on them and leaving us with a conceptual mishmash to sort through.
> Firmware vendors can introduce incompatible DT bindings and have them in
> their devices too and we have to deal with that...
The case that's worrying me is mixing the ACPI and DT design models in
one system, and especially having that happen to actually work without
modification purely by luck rather than by design.
> I think if this pushes closer ACPI and OF schemas for at least some
> subsystems closer to each other it would not be a bad thing.
I think we shouldn't be encouraging people to just throw random stuff at
the wall and see if it happens to run OK with whatever OS they tried
booting. The differences between ACPI and DT in areas like the
regulator bindings are fundamental conceptual ones. There's some areas
where things are closer and it winds up being fine actually, especially
for leaf devices, but there's others where that's less likely.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23 19:41 UTC (permalink / raw)
To: Mark Brown
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vinod Koul, Neil Armstrong, Liam Girdwood, Lee Jones,
Pavel Machek, Peter Rosin, Andrew Lunn, Heiner Kallweit,
Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <7d46803e-b285-4e9c-8856-10100fa0ea85@sirena.org.uk>
On Mon, Mar 23, 2026 at 07:05:13PM +0000, Mark Brown wrote:
> On Mon, Mar 23, 2026 at 11:28:27AM -0700, Dmitry Torokhov wrote:
> > On Mon, Mar 23, 2026 at 02:00:43PM +0000, Mark Brown wrote:
>
> > > The regulator API is very deliberately specifically using the OF APIs,
> > > not the ACPI APIs, since ACPI really doesn't want to model regulators.
>
> > For now? We also have software nodes and maybe we come up with something
> > else in the future...
>
> > I think we should use firmware-agnostic APIs as much as possible, and
> > only use OF- or ACPI-specific ones when there is no generic equivalent.
> > This makes the code most flexible.
>
> I think this is a worrying idea for core code like this, we have
> specific firmware bindings for specific firmware interfaces with the
> different interfaces having very different ideas of how things should be
> modelled. The chances that firmware agnostic code is going to do the
> right thing seem low, and encouraging the use of generic APIs that might
> happen to run OK raises the risk that we'll get firmware vendors relying
> on them and leaving us with a conceptual mishmash to sort through.
>
> Software nodes are already a bit of a concern here TBH.
Firmware vendors can introduce incompatible DT bindings and have them in
their devices too and we have to deal with that...
I think if this pushes closer ACPI and OF schemas for at least some
subsystems closer to each other it would not be a bad thing.
Thanks.
--
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23 19:35 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Mark Brown, Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <acGI4PI3MHML9Pce@shell.armlinux.org.uk>
On Mon, Mar 23, 2026 at 06:39:28PM +0000, Russell King (Oracle) wrote:
> On Mon, Mar 23, 2026 at 11:33:36AM -0700, Dmitry Torokhov wrote:
> > On Mon, Mar 23, 2026 at 08:59:52AM +0000, Russell King (Oracle) wrote:
> > > On Sun, Mar 22, 2026 at 10:17:15PM -0700, Dmitry Torokhov wrote:
> > > > On Mon, Mar 23, 2026 at 03:54:09AM +0100, Andrew Lunn wrote:
> > > > > > - d = class_find_device_by_of_node(&mdio_bus_class, mdio_bus_np);
> > > > > > + d = class_find_device_by_fwnode(&mdio_bus_class,
> > > > > > + of_fwnode_handle(mdio_bus_np));
> > > > >
> > > > > When you look at this, why is it better?
> > > >
> > > > I think we should move as much as possible towards firmware-agnostic
> > > > APIs and use fwnode_handle instead of device_node or software_node or
> > > > ACPI companion. To discourage this I think we better remove
> > > > firmware-specific APIs where we have firmware-agnostic ones and
> > > > eventually clean up drivers that use OF- or ACPI-specific APIs.
> > >
> > > Basically, no. This is wrong.
> > >
> > > It may sound like a good goal, but there's an underlying issue. This
> > > goal assumes that the firmware description in OF and ACPI are
> > > indentical.
> >
> > If they are different then drivers will make allowance for this, like
> > I2C core or SPI core does. But most of the modern drivers use
> > firmware-agnostic APIs (device_property_*()).
>
> What is appropriate is up to the standards bodies responsible for
> the firmware. ACPI has a separate body, and we can't just dump
> the structure we use for networking into ACPI. So no, you can't
> just switch to firmware-agnostic APIs for networking.
So I believe there is a difference between deciding:
1. What schema is being used on a particular system - it may be
OF-compatible, or ACPI compatible one, and ACPI may support
OF-compatible schemes for certain subsystems or individual devices, and
2. What is the API to access the properties.
There is no harm to use device_property_read_*() universally as well as
not having OF-specific APIs at the driver core level. What matters is
schema matches the system type.
>
> For infrastructure where we lookup stuff by some kind of firmware
> node, I have no problem with converting that to fwnode APIs,
> because that doesn't transfer the DT description into other
> firmwares without prior agreement of the appropriate firmware
> standards bodies.
>
> This is not "foreign territory" - ACPI in general doesn't want to
> describe e.g. the individual components of a network card, unlike
> DT.
I think we actually broadly agree? What you are arguing against is
saying that OF schema is guaranteed to work on ACPI systems and vice
versa, but I am not saying that (although for some things it may). But
still most OF schema can be handled by generic APIs (either
device_property_read_*() or fwnode ones).
Thanks.
--
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Mark Brown @ 2026-03-23 19:05 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vinod Koul, Neil Armstrong, Liam Girdwood, Lee Jones,
Pavel Machek, Peter Rosin, Andrew Lunn, Heiner Kallweit,
Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <acGFksyx3SA0kJ5b@google.com>
[-- Attachment #1.1: Type: text/plain, Size: 1110 bytes --]
On Mon, Mar 23, 2026 at 11:28:27AM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 23, 2026 at 02:00:43PM +0000, Mark Brown wrote:
> > The regulator API is very deliberately specifically using the OF APIs,
> > not the ACPI APIs, since ACPI really doesn't want to model regulators.
> For now? We also have software nodes and maybe we come up with something
> else in the future...
> I think we should use firmware-agnostic APIs as much as possible, and
> only use OF- or ACPI-specific ones when there is no generic equivalent.
> This makes the code most flexible.
I think this is a worrying idea for core code like this, we have
specific firmware bindings for specific firmware interfaces with the
different interfaces having very different ideas of how things should be
modelled. The chances that firmware agnostic code is going to do the
right thing seem low, and encouraging the use of generic APIs that might
happen to run OK raises the risk that we'll get firmware vendors relying
on them and leaving us with a conceptual mishmash to sort through.
Software nodes are already a bit of a concern here TBH.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()
From: Russell King (Oracle) @ 2026-03-23 18:39 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andrew Lunn, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Mark Brown, Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <acGGWTmSMuc5h3Od@google.com>
On Mon, Mar 23, 2026 at 11:33:36AM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 23, 2026 at 08:59:52AM +0000, Russell King (Oracle) wrote:
> > On Sun, Mar 22, 2026 at 10:17:15PM -0700, Dmitry Torokhov wrote:
> > > On Mon, Mar 23, 2026 at 03:54:09AM +0100, Andrew Lunn wrote:
> > > > > - d = class_find_device_by_of_node(&mdio_bus_class, mdio_bus_np);
> > > > > + d = class_find_device_by_fwnode(&mdio_bus_class,
> > > > > + of_fwnode_handle(mdio_bus_np));
> > > >
> > > > When you look at this, why is it better?
> > >
> > > I think we should move as much as possible towards firmware-agnostic
> > > APIs and use fwnode_handle instead of device_node or software_node or
> > > ACPI companion. To discourage this I think we better remove
> > > firmware-specific APIs where we have firmware-agnostic ones and
> > > eventually clean up drivers that use OF- or ACPI-specific APIs.
> >
> > Basically, no. This is wrong.
> >
> > It may sound like a good goal, but there's an underlying issue. This
> > goal assumes that the firmware description in OF and ACPI are
> > indentical.
>
> If they are different then drivers will make allowance for this, like
> I2C core or SPI core does. But most of the modern drivers use
> firmware-agnostic APIs (device_property_*()).
What is appropriate is up to the standards bodies responsible for
the firmware. ACPI has a separate body, and we can't just dump
the structure we use for networking into ACPI. So no, you can't
just switch to firmware-agnostic APIs for networking.
For infrastructure where we lookup stuff by some kind of firmware
node, I have no problem with converting that to fwnode APIs,
because that doesn't transfer the DT description into other
firmwares without prior agreement of the appropriate firmware
standards bodies.
This is not "foreign territory" - ACPI in general doesn't want to
describe e.g. the individual components of a network card, unlike
DT.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23 18:33 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Mark Brown, Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <acEBCBgMV3RrGKiU@shell.armlinux.org.uk>
On Mon, Mar 23, 2026 at 08:59:52AM +0000, Russell King (Oracle) wrote:
> On Sun, Mar 22, 2026 at 10:17:15PM -0700, Dmitry Torokhov wrote:
> > On Mon, Mar 23, 2026 at 03:54:09AM +0100, Andrew Lunn wrote:
> > > > - d = class_find_device_by_of_node(&mdio_bus_class, mdio_bus_np);
> > > > + d = class_find_device_by_fwnode(&mdio_bus_class,
> > > > + of_fwnode_handle(mdio_bus_np));
> > >
> > > When you look at this, why is it better?
> >
> > I think we should move as much as possible towards firmware-agnostic
> > APIs and use fwnode_handle instead of device_node or software_node or
> > ACPI companion. To discourage this I think we better remove
> > firmware-specific APIs where we have firmware-agnostic ones and
> > eventually clean up drivers that use OF- or ACPI-specific APIs.
>
> Basically, no. This is wrong.
>
> It may sound like a good goal, but there's an underlying issue. This
> goal assumes that the firmware description in OF and ACPI are
> indentical.
If they are different then drivers will make allowance for this, like
I2C core or SPI core does. But most of the modern drivers use
firmware-agnostic APIs (device_property_*()).
ACPI has allowance for device tree properties (via PRP0001 HID
entries), and drivers should work with them.
>
> Sure, looking up devices by fwnode handle makes sense, but looking up
> anything that is described in firmware is not suitable for this kind
> of conversion, because in doing so, you effectively "port" the DT
> bindings to ACPI, and it may not be suitable for ACPI.
>
> So, please don't make wholesale changes that transfer the DT bindings
> into ACPI.
>
I am not "transferring" anything, but I want to make sure the code works
even if we augment OF with software nodes or if DT properties are used
in ACPI.
Thanks.
--
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23 18:28 UTC (permalink / raw)
To: Mark Brown
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vinod Koul, Neil Armstrong, Liam Girdwood, Lee Jones,
Pavel Machek, Peter Rosin, Andrew Lunn, Heiner Kallweit,
Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <360a8b4a-6507-417a-9fc1-c53b14868657@sirena.org.uk>
On Mon, Mar 23, 2026 at 02:00:43PM +0000, Mark Brown wrote:
> On Sun, Mar 22, 2026 at 06:54:22PM -0700, Dmitry Torokhov wrote:
> > In preparation to class_find_device_by_of_node() going away switch to
> > using class_find_device_by_fwnode().
>
> > struct device *dev;
> >
> > - dev = class_find_device_by_of_node(®ulator_class, np);
> > + dev = class_find_device_by_fwnode(®ulator_class, of_fwnode_handle(np));
>
> The regulator API is very deliberately specifically using the OF APIs,
> not the ACPI APIs, since ACPI really doesn't want to model regulators.
For now? We also have software nodes and maybe we come up with something
else in the future...
I think we should use firmware-agnostic APIs as much as possible, and
only use OF- or ACPI-specific ones when there is no generic equivalent.
This makes the code most flexible.
Anyway, I am not proposing to change all of the regulator code, just
clean up driver core APIs.
Thanks.
--
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 03/10] spi: switch to using class_find_device_by_fwnode()
From: Dmitry Torokhov @ 2026-03-23 18:25 UTC (permalink / raw)
To: Mark Brown
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vinod Koul, Neil Armstrong, Liam Girdwood, Lee Jones,
Pavel Machek, Peter Rosin, Andrew Lunn, Heiner Kallweit,
Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <098e1856-feee-4f4b-8059-85a53967f6b3@sirena.org.uk>
On Mon, Mar 23, 2026 at 05:16:04PM +0000, Mark Brown wrote:
> On Sun, Mar 22, 2026 at 06:54:21PM -0700, Dmitry Torokhov wrote:
> > In preparation to class_find_device_by_of_node() going away switch to
> > using class_find_device_by_fwnode().
>
> > struct spi_controller *of_find_spi_controller_by_node(struct device_node *node)
> > {
> > + struct fwnode_handle *fwnode = of_fwnode_handle(node);
> > struct device *dev;
> >
> > - dev = class_find_device_by_of_node(&spi_controller_class, node);
> > + dev = class_find_device_by_fwnode(&spi_controller_class, fwnode);
> > if (!dev && IS_ENABLED(CONFIG_SPI_SLAVE))
> > - dev = class_find_device_by_of_node(&spi_target_class, node);
> > + dev = class_find_device_by_fwnode(&spi_target_class, fwnode);
> > if (!dev)
> > return NULL;
>
> Actually, no - this just looks weird. We're in the middle of an OF
> specific function but we're having to jump up to fwnode for no apparent
> reason. If we actually decide to get rid of the OF specific function
> then I guess but I'm really not convinced this is an improvement in
> isolation.
Yes, I want to remove OF-specific APIs from the driver core. I also have
drafts for bus_find_device_by_fwnode and others.
I can make a followup series introducing spi_find_controller_by_fwnode()
and removing this OF-specific variant.
Thanks.
--
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 03/10] spi: switch to using class_find_device_by_fwnode()
From: Mark Brown @ 2026-03-23 17:16 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vinod Koul, Neil Armstrong, Liam Girdwood, Lee Jones,
Pavel Machek, Peter Rosin, Andrew Lunn, Heiner Kallweit,
Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <20260322-remove-device-find-by-of-node-v1-3-b72eb22a1215@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1014 bytes --]
On Sun, Mar 22, 2026 at 06:54:21PM -0700, Dmitry Torokhov wrote:
> In preparation to class_find_device_by_of_node() going away switch to
> using class_find_device_by_fwnode().
> struct spi_controller *of_find_spi_controller_by_node(struct device_node *node)
> {
> + struct fwnode_handle *fwnode = of_fwnode_handle(node);
> struct device *dev;
>
> - dev = class_find_device_by_of_node(&spi_controller_class, node);
> + dev = class_find_device_by_fwnode(&spi_controller_class, fwnode);
> if (!dev && IS_ENABLED(CONFIG_SPI_SLAVE))
> - dev = class_find_device_by_of_node(&spi_target_class, node);
> + dev = class_find_device_by_fwnode(&spi_target_class, fwnode);
> if (!dev)
> return NULL;
Actually, no - this just looks weird. We're in the middle of an OF
specific function but we're having to jump up to fwnode for no apparent
reason. If we actually decide to get rid of the OF specific function
then I guess but I'm really not convinced this is an improvement in
isolation.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 0/6] Fixes to Tegra USB role switching and phy handling
From: Diogo Ivo @ 2026-03-23 16:15 UTC (permalink / raw)
To: Mathias Nyman, Greg Kroah-Hartman, Thierry Reding,
Jonathan Hunter, JC Kuo, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: linux-usb, linux-tegra, linux-kernel, linux-phy, devicetree,
stable
In-Reply-To: <20260127-diogo-tegra_phy-v2-0-787b9eed3ed5@tecnico.ulisboa.pt>
Hello,
Ping on this series as it has been quite a while since this was sent out
originally.
Best regards,
Diogo
On 1/27/26 15:11, Diogo Ivo wrote:
> Hello,
>
> This patch series contains fixes/improvements for USB role switching on the
> Tegra210 and Tegra186 SoCs.
>
> The first patch addresses a wrong check on the logic that disables the
> VBUS regulator.
>
> The second patch removes a redundant mutex lock when setting the PHY
> mode.
>
> The third patch guarantees proper ordering of events when switching PHY
> roles.
>
> The remaining patches are included to standardize the PHY .set_mode()
> callback between Tegra186 and Tegra210.
>
> With this patch series this feature can only be controlled from userspace,
> by writing the desired role to sysfs as
>
> echo "role" > /sys/class/usb_role/usb2-0-role-switch/role
>
> with role being one of {device, host, none}.
>
> Further patches will enable automatic role switching via the 'cros_ec_typec'
> driver which is currently broken on Smaug.
>
> Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
> ---
> Changes in v2:
> - Remove DT patches already taken to be upstreamed
> - Add standardization between Tegra210 and Tegra186
> - Address review comments from v1, detailed descriptions in each patch
> - Link to v1: https://lore.kernel.org/r/20251204-diogo-tegra_phy-v1-0-51a2016d0be8@tecnico.ulisboa.pt
>
> ---
> Diogo Ivo (6):
> phy: tegra: xusb: Fix USB2 port regulator disable logic
> usb: xhci: tegra: Remove redundant mutex when setting phy mode
> phy: tegra: xusb: Fix ordering issue when switching roles on USB2 ports
> phy: tegra: xusb: Add ID override support to padctl
> phy: tegra: xusb: Move .set_mode() to a shared location
> phy: tegra: xusb: Move T186 .set_mode() to common implementation
>
> drivers/phy/tegra/xusb-tegra186.c | 73 +++++----------------------------
> drivers/phy/tegra/xusb-tegra210.c | 42 +------------------
> drivers/phy/tegra/xusb.c | 80 +++++++++++++++++++++++++++++++++++++
> drivers/phy/tegra/xusb.h | 4 ++
> drivers/usb/gadget/udc/tegra-xudc.c | 4 ++
> drivers/usb/host/xhci-tegra.c | 14 ++++---
> include/linux/phy/tegra/xusb.h | 3 ++
> 7 files changed, 111 insertions(+), 109 deletions(-)
> ---
> base-commit: b02a5530af8abe0d3cd4852ba48990716e962934
> change-id: 20251201-diogo-tegra_phy-86c89cab7377
>
> Best regards,
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* RE: [PATCH v5 phy-next 09/27] scsi: ufs: exynos: stop poking into struct phy guts
From: Alim Akhtar @ 2026-03-23 12:35 UTC (permalink / raw)
To: 'Vladimir Oltean', 'Martin K. Petersen'
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, 'Bart Van Assche',
'Peter Griffin', 'James E.J. Bottomley',
'Krzysztof Kozlowski', 'Chanho Park'
In-Reply-To: <20260323115848.ghdu4sbk75tvggfb@skbuf>
Hi Vladimir
> -----Original Message-----
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
> Sent: Monday, March 23, 2026 5:29 PM
> To: Martin K. Petersen <martin.petersen@oracle.com>
> Cc: linux-phy@lists.infradead.org; Vinod Koul <vkoul@kernel.org>; Neil
> Armstrong <neil.armstrong@linaro.org>; dri-devel@lists.freedesktop.org;
> freedreno@lists.freedesktop.org; linux-arm-kernel@lists.infradead.org;
> linux-arm-msm@vger.kernel.org; linux-can@vger.kernel.org; linux-
> gpio@vger.kernel.org; linux-ide@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-media@vger.kernel.org; linux-
> pci@vger.kernel.org; linux-renesas-soc@vger.kernel.org; linux-
> riscv@lists.infradead.org; linux-rockchip@lists.infradead.org;
linux-samsung-
> soc@vger.kernel.org; linux-scsi@vger.kernel.org;
linux-sunxi@lists.linux.dev;
> linux-tegra@vger.kernel.org; linux-usb@vger.kernel.org;
> netdev@vger.kernel.org; spacemit@lists.linux.dev;
> UNGLinuxDriver@microchip.com; Bart Van Assche <bvanassche@acm.org>;
> Alim Akhtar <alim.akhtar@samsung.com>; Peter Griffin
> <peter.griffin@linaro.org>; James E.J. Bottomley
> <James.Bottomley@HansenPartnership.com>; Krzysztof Kozlowski
> <krzk@kernel.org>; Chanho Park <chanho61.park@samsung.com>
> Subject: Re: [PATCH v5 phy-next 09/27] scsi: ufs: exynos: stop poking into
> struct phy guts
>
> On Thu, Mar 19, 2026 at 10:15:17PM -0400, Martin K. Petersen wrote:
> > Vladimir,
> >
> > > The Exynos host controller driver is clearly a PHY consumer (gets
> > > the
> > > ufs->phy using devm_phy_get()), but pokes into the guts of struct
> > > ufs->phy
> > > to get the generic_phy->power_count.
> >
> > Ah, newer version. Would still like an ack from Samsung.
> >
> > And I hit the wrong key, I did not actually apply this...
>
> I will have to resend v6 because of an armv7 build error I've caused for
ufs-
> qcom.c (which doesn't #include <linux/interrupt.h>, and relies on a
transitive
> inclusion from <linux/phy/phy.h>). It would be nice to get the ack from
> Samsung, but I'll send the next version in the upcoming hours regardless.
Will review and possibly test on one of the board later tonight
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: (subset) [PATCH V5 0/3] Add UFS support for x1e80100 SoC
From: Bjorn Andersson @ 2026-03-23 14:38 UTC (permalink / raw)
To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, martin.petersen,
konradybcio, taniya.das, dmitry.baryshkov, manivannan.sadhasivam,
Pradeep P V K
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
nitin.rawat
In-Reply-To: <20260211132926.3716716-1-pradeep.pragallapati@oss.qualcomm.com>
On Wed, 11 Feb 2026 18:59:23 +0530, Pradeep P V K wrote:
> Add UFSPHY, UFSHC compatible binding names and UFS devicetree
> enablement changes for Qualcomm x1e80100 SoC.
>
> Changes in V5:
> - Rebased on linux-next (next-20260210) to resolve merge conflicts.
> - Add RB-by for UFSHC dt-binding [Krzysztof]
> - Add AB-by for UFSHC dt-binding [Mani]
> - Add RB-by for SoC dtsi [Konrad, Abel, Taniya, Mani]
> - Add RB-by for board dts [Konrad, Mani]
> - Link to V4:
> https://lore.kernel.org/all/20260106154207.1871487-1-pradeep.pragallapati@oss.qualcomm.com
>
> [...]
Applied, thanks!
[2/3] arm64: dts: qcom: hamoa: Add UFS nodes for x1e80100 SoC
commit: 23c6e96c5b60c2725db955b7ba6bf80609a7256d
[3/3] arm64: dts: qcom: hamoa-iot-evk: Enable UFS
commit: 5b1a4acc08e57712e85f9c8927b96a2843645f08
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue @ 2026-03-23 14:29 UTC (permalink / raw)
To: Konrad Dybcio, Vijay Kumar Tumati, Bryan O'Donoghue,
Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: Vladimir Zapolskiy, linux-arm-msm, linux-phy, linux-media,
devicetree, linux-kernel
In-Reply-To: <4b1b5b79-df37-499e-99c4-1a965a9b2455@oss.qualcomm.com>
On 23/03/2026 14:22, Konrad Dybcio wrote:
>> Sure, FYI: Dmitry, Konrad.
> I'll admit I haven't yet read up on all of the background discussions that you
> guys had on LKML, but*if* we're going to put the PHY under camss, the GDSC and
> CPAS_AHB/CAMNOC_AXI_RT references should be unnecessary, given they're not
> related strictly to this PHY itself, rather it sitting in a specific corner of
> the subsystem that needs them to be active (see related:
> https://lore.kernel.org/linux-arm-msm/cb2430f2-8601-4c72-
> af6b-10f1ff16c188@oss.qualcomm.com/
> )
That's fair comment with the PHYs inside of the CAMSS block. Obviously
if its outside of the block we need the full gamut of clocks defined.
..
Yeah I think I'm happy enough to drop these predicated on sub-nodes.
> For the other names, I*think* we won't need to rely on them (i.e. only operate
> the resources through PHY APIs from the V4L2 driver) and can come up with new
> ones. And hence I think we can turn "csiphy" to "core" and "csiphy_timer" to
> "timer" (because we really don't need to repeat the csiphy_ prefix)
Works for me.
---
bod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Konrad Dybcio @ 2026-03-23 14:22 UTC (permalink / raw)
To: Vijay Kumar Tumati, Bryan O'Donoghue, Bryan O'Donoghue,
Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: Vladimir Zapolskiy, linux-arm-msm, linux-phy, linux-media,
devicetree, linux-kernel
In-Reply-To: <4afceefe-8053-4c10-8595-39dab9379aab@oss.qualcomm.com>
On 3/17/26 9:25 PM, Vijay Kumar Tumati wrote:
>
>
> On 3/16/2026 10:26 PM, Bryan O'Donoghue wrote:
>> On 16/03/2026 21:31, Vijay Kumar Tumati wrote:
>>> Hi Bryan,
>>>
>>> On 3/15/2026 4:52 PM, Bryan O'Donoghue wrote:
>>>> Add a base schema initially compatible with x1e80100 to describe MIPI CSI2
>>>> PHY devices.
>>>>
>>>> The hardware can support both C-PHY and D-PHY modes. The CSIPHY devices
>>>> have their own pinouts on the SoC as well as their own individual voltage
>>>> rails.
>>>>
>>>> The need to model voltage rails on a per-PHY basis leads us to define
>>>> CSIPHY devices as individual nodes.
>>>>
>>>> Two nice outcomes in terms of schema and DT arise from this change.
>>>>
>>>> 1. The ability to define on a per-PHY basis voltage rails.
>>>> 2. The ability to require those voltage.
>>>>
>>>> We have had a complete bodge upstream for this where a single set of
>>>> voltage rail for all CSIPHYs has been buried inside of CAMSS.
>>>>
>>>> Much like the I2C bus which is dedicated to Camera sensors - the CCI bus in
>>>> CAMSS parlance, the CSIPHY devices should be individually modelled.
>>>>
>>>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>>>> ---
>>>> .../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 133 +++++++++ ++++++++++++
>>>> 1 file changed, 133 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/phy/qcom,x1e80100- csi2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,x1e80100- csi2-phy.yaml
>>>> new file mode 100644
>>>> index 0000000000000..b83c2d65ebc6e
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
>>>> @@ -0,0 +1,133 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/phy/qcom,x1e80100-csi2-phy.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Qualcomm CSI2 PHY
>>>> +
>>>> +maintainers:
>>>> + - Bryan O'Donoghue <bod@kernel.org>
>>>> +
>>>> +description:
>>>> + Qualcomm MIPI CSI2 C-PHY/D-PHY combination PHY. Connects MIPI CSI2 sensors
>>>> + to Qualcomm's Camera CSI Decoder. The PHY supports both C-PHY and D-PHY
>>>> + modes.
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + const: qcom,x1e80100-csi2-phy
>>>> +
>>>> + reg:
>>>> + maxItems: 1
>>>> +
>>>> + "#phy-cells":
>>>> + const: 1
>>>> +
>>>> + clocks:
>>>> + maxItems: 4
>>>> +
>>>> + clock-names:
>>>> + items:
>>>> + - const: csiphy
>>>> + - const: csiphy_timer
>>>> + - const: camnoc_axi
>>>> + - const: cpas_ahb
>>>> +
>>>> + interrupts:
>>>> + maxItems: 1
>>>> +
>>>> + operating-points-v2:
>>>> + maxItems: 1
>>>> +
>>>> + power-domains:
>>>> + items:
>>>> + - description: TITAN TOP GDSC
>>>> + - description: MXC or MXA voltage rail
>>> Would it be better to provision MXA or MXC as an additional optional
>>> power domain? I see 'cam_cc_cphy_rx_clk_src', the parent of all CSIPHYx
>>> clocks, need all three power domains on this chipset.
>>
>> I don't think this should be optional. Have the dts point to an "mx" power-domain and then select which one is right for a PHY MX/MXA or MXC.
>>
>> Your worst case here is some future PHY which has more or fewer PDs which is then either a special case in this file or a whole new file for that compat.
>>
> I think it is the case on x1e* as well, Bryan.
>>>> + - description: MMCX voltage rail
>>>> +
>>>> + power-domain-names:
>>>> + items:
>>>> + - const: top
>>>> + - const: mx
>>>> + - const: mmcx
>>>> +
>>>> + vdda-0p8-supply:
>>>> + description: Phandle to a 0.8V regulator supply to a PHY.
>>>> +
>>>> + vdda-1p2-supply:
>>>> + description: Phandle to 1.2V regulator supply to a PHY.
>>>> +
>>>> +required:
>>>> + - compatible
>>>> + - reg
>>>> + - "#phy-cells"
>>>> + - clocks
>>>> + - clock-names
>>>> + - interrupts
>>>> + - operating-points-v2
>>>> + - power-domains
>>>> + - power-domain-names
>>>> + - vdda-0p8-supply
>>>> + - vdda-1p2-supply
>>>> +
>>>> +additionalProperties: false
>>>> +
>>>> +examples:
>>>> + - |
>>>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>> + #include <dt-bindings/clock/qcom,x1e80100-camcc.h>
>>>> + #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
>>>> + #include <dt-bindings/phy/phy.h>
>>>> + #include <dt-bindings/power/qcom,rpmhpd.h>
>>>> +
>>>> + csiphy@ace4000 {
>>>> + compatible = "qcom,x1e80100-csi2-phy";
>>>> + reg = <0x0ace4000 0x2000>;
>>>> + #phy-cells = <1>;
>>>> +
>>>> + clocks = <&camcc CAM_CC_CSIPHY0_CLK>,
>>>> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
>>>> + <&camcc CAM_CC_CAMNOC_AXI_RT_CLK>,
>>>> + <&camcc CAM_CC_CPAS_AHB_CLK>;
>>>> + clock-names = "csiphy",
>>>> + "csiphy_timer",
>>>> + "camnoc_axi",
>>>> + "cpas_ahb";
>>> Although it's not a concern from my side, just want to be explicitly
>>> sure that everyone is happy with the clock names, just to avoid any
>>> changes later on when other modules are separated out.
>>
>> These are the names we already use in CAMSS so ... they're good enough to start from.
>>
> Sure, FYI: Dmitry, Konrad.
I'll admit I haven't yet read up on all of the background discussions that you
guys had on LKML, but *if* we're going to put the PHY under camss, the GDSC and
CPAS_AHB/CAMNOC_AXI_RT references should be unnecessary, given they're not
related strictly to this PHY itself, rather it sitting in a specific corner of
the subsystem that needs them to be active (see related:
https://lore.kernel.org/linux-arm-msm/cb2430f2-8601-4c72-af6b-10f1ff16c188@oss.qualcomm.com/
)
For the other names, I *think* we won't need to rely on them (i.e. only operate
the resources through PHY APIs from the V4L2 driver) and can come up with new
ones. And hence I think we can turn "csiphy" to "core" and "csiphy_timer" to
"timer" (because we really don't need to repeat the csiphy_ prefix)
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Mark Brown @ 2026-03-23 14:00 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vinod Koul, Neil Armstrong, Liam Girdwood, Lee Jones,
Pavel Machek, Peter Rosin, Andrew Lunn, Heiner Kallweit,
Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <20260322-remove-device-find-by-of-node-v1-4-b72eb22a1215@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 500 bytes --]
On Sun, Mar 22, 2026 at 06:54:22PM -0700, Dmitry Torokhov wrote:
> In preparation to class_find_device_by_of_node() going away switch to
> using class_find_device_by_fwnode().
> struct device *dev;
>
> - dev = class_find_device_by_of_node(®ulator_class, np);
> + dev = class_find_device_by_fwnode(®ulator_class, of_fwnode_handle(np));
The regulator API is very deliberately specifically using the OF APIs,
not the ACPI APIs, since ACPI really doesn't want to model regulators.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 03/10] spi: switch to using class_find_device_by_fwnode()
From: Mark Brown @ 2026-03-23 13:58 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vinod Koul, Neil Armstrong, Liam Girdwood, Lee Jones,
Pavel Machek, Peter Rosin, Andrew Lunn, Heiner Kallweit,
Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <20260322-remove-device-find-by-of-node-v1-3-b72eb22a1215@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 219 bytes --]
On Sun, Mar 22, 2026 at 06:54:21PM -0700, Dmitry Torokhov wrote:
> In preparation to class_find_device_by_of_node() going away switch to
> using class_find_device_by_fwnode().
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 4/4] phy: qualcomm: add MSM8974 HDMI PHY support
From: Konrad Dybcio @ 2026-03-23 12:07 UTC (permalink / raw)
To: Dmitry Baryshkov, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Vinod Koul, Neil Armstrong
Cc: linux-kernel, linux-arm-msm, dri-devel, freedreno, linux-phy,
Dmitry Baryshkov
In-Reply-To: <20260319-fd-hdmi-phy-v6-4-cefc08a55470@oss.qualcomm.com>
On 3/19/26 4:48 AM, Dmitry Baryshkov wrote:
> From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>
> Add support for HDMI PHY on Qualcomm MSM8974 / APQ8074 platforms.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
I don't have much insight, but the code looks alright..
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 phy-next 09/27] scsi: ufs: exynos: stop poking into struct phy guts
From: Vladimir Oltean @ 2026-03-23 11:58 UTC (permalink / raw)
To: Martin K. Petersen
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, Bart Van Assche, Alim Akhtar, Peter Griffin,
James E.J. Bottomley, Krzysztof Kozlowski, Chanho Park
In-Reply-To: <yq1a4w3l04g.fsf@ca-mkp.ca.oracle.com>
On Thu, Mar 19, 2026 at 10:15:17PM -0400, Martin K. Petersen wrote:
> Vladimir,
>
> > The Exynos host controller driver is clearly a PHY consumer (gets the
> > ufs->phy using devm_phy_get()), but pokes into the guts of struct phy
> > to get the generic_phy->power_count.
>
> Ah, newer version. Would still like an ack from Samsung.
>
> And I hit the wrong key, I did not actually apply this...
I will have to resend v6 because of an armv7 build error I've caused for
ufs-qcom.c (which doesn't #include <linux/interrupt.h>, and relies on a
transitive inclusion from <linux/phy/phy.h>). It would be nice to get
the ack from Samsung, but I'll send the next version in the upcoming
hours regardless.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next 07/10] net: phy: switch to using class_find_device_by_fwnode()
From: Russell King (Oracle) @ 2026-03-23 8:59 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andrew Lunn, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vinod Koul, Neil Armstrong,
Mark Brown, Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin,
Heiner Kallweit, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <acDLzK8vpptTUMf1@google.com>
On Sun, Mar 22, 2026 at 10:17:15PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 23, 2026 at 03:54:09AM +0100, Andrew Lunn wrote:
> > > - d = class_find_device_by_of_node(&mdio_bus_class, mdio_bus_np);
> > > + d = class_find_device_by_fwnode(&mdio_bus_class,
> > > + of_fwnode_handle(mdio_bus_np));
> >
> > When you look at this, why is it better?
>
> I think we should move as much as possible towards firmware-agnostic
> APIs and use fwnode_handle instead of device_node or software_node or
> ACPI companion. To discourage this I think we better remove
> firmware-specific APIs where we have firmware-agnostic ones and
> eventually clean up drivers that use OF- or ACPI-specific APIs.
Basically, no. This is wrong.
It may sound like a good goal, but there's an underlying issue. This
goal assumes that the firmware description in OF and ACPI are
indentical.
Sure, looking up devices by fwnode handle makes sense, but looking up
anything that is described in firmware is not suitable for this kind
of conversion, because in doing so, you effectively "port" the DT
bindings to ACPI, and it may not be suitable for ACPI.
So, please don't make wholesale changes that transfer the DT bindings
into ACPI.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 10/10] driver core: class: remove class_find_device_by_of_node()
From: Greg Kroah-Hartman @ 2026-03-23 7:43 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vinod Koul, Neil Armstrong, Mark Brown,
Liam Girdwood, Lee Jones, Pavel Machek, Peter Rosin, Andrew Lunn,
Heiner Kallweit, Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Rafael J. Wysocki, Danilo Krummrich, netdev, linux-kernel,
linux-phy, linux-spi, linux-leds, linux-fpga, driver-core
In-Reply-To: <20260322-remove-device-find-by-of-node-v1-10-b72eb22a1215@gmail.com>
On Sun, Mar 22, 2026 at 06:54:28PM -0700, Dmitry Torokhov wrote:
> All users of class_find_device_by_of_node() have been converted to
> using class_find_device_by_fwnode(). Remove the former.
>
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> include/linux/device/class.h | 12 ------------
> 1 file changed, 12 deletions(-)
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 5/5] arch: arm64: dts: qcom: Add support for PCIe3a
From: Qiang Yu @ 2026-03-23 7:15 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Qiang Yu
In-Reply-To: <20260323-glymur_gen5x8_phy_0323-v2-0-ce0fc07f0e52@oss.qualcomm.com>
Describe PCIe3a controller and PHY. Also add required system resources
like regulators, clocks, interrupts and registers configuration for PCIe3a.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 314 ++++++++++++++++++++++++++++++++++-
1 file changed, 313 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index bde287f645ee94116a489c55be3b7b80db3815e9..52104607a1713323fdfe2e7de710e38c1e22d06e 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -736,7 +736,7 @@ gcc: clock-controller@100000 {
<0>, /* USB 2 Phy PCIE PIPEGMUX */
<0>, /* USB 2 Phy PIPEGMUX */
<0>, /* USB 2 Phy SYS PCIE PIPEGMUX */
- <0>, /* PCIe 3a */
+ <&pcie3a_phy>, /* PCIe 3a */
<&pcie3b_phy>, /* PCIe 3b */
<&pcie4_phy>, /* PCIe 4 */
<&pcie5_phy>, /* PCIe 5 */
@@ -2360,6 +2360,318 @@ pcie_west_slv_noc: interconnect@1920000 {
#interconnect-cells = <2>;
};
+ pcie3a: pci@1c10000 {
+ device_type = "pci";
+ compatible = "qcom,glymur-pcie", "qcom,pcie-x1e80100";
+ reg = <0x0 0x01c10000 0x0 0x3000>,
+ <0x0 0x70000000 0x0 0xf20>,
+ <0x0 0x70000f40 0x0 0xa8>,
+ <0x0 0x70001000 0x0 0x4000>,
+ <0x0 0x70100000 0x0 0x100000>,
+ <0x0 0x01c13000 0x0 0x1000>;
+ reg-names = "parf",
+ "dbi",
+ "elbi",
+ "atu",
+ "config",
+ "mhi";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x01000000 0x0 0x00000000 0x0 0x70200000 0x0 0x100000>,
+ <0x02000000 0x0 0x70000000 0x0 0x70300000 0x0 0x3d00000>,
+ <0x03000000 0x7 0x00000000 0x7 0x00000000 0x0 0x40000000>;
+ bus-range = <0 0xff>;
+
+ dma-coherent;
+
+ linux,pci-domain = <3>;
+ num-lanes = <8>;
+
+ operating-points-v2 = <&pcie3a_opp_table>;
+
+ msi-map = <0x0 &gic_its 0xb0000 0x10000>;
+ iommu-map = <0x0 &pcie_smmu 0x30000 0x10000>;
+
+ interrupts = <GIC_SPI 948 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 949 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 844 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 845 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 846 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 847 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 942 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi0",
+ "msi1",
+ "msi2",
+ "msi3",
+ "msi4",
+ "msi5",
+ "msi6",
+ "msi7",
+ "global";
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc 0 0 0 848 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc 0 0 0 849 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc 0 0 0 850 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc 0 0 0 851 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&gcc GCC_PCIE_3A_AUX_CLK>,
+ <&gcc GCC_PCIE_3A_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_3A_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_3A_SLV_AXI_CLK>,
+ <&gcc GCC_PCIE_3A_SLV_Q2A_AXI_CLK>,
+ <&gcc GCC_AGGRE_NOC_PCIE_3A_WEST_SF_AXI_CLK>;
+ clock-names = "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave",
+ "slave_q2a",
+ "noc_aggr";
+
+ assigned-clocks = <&gcc GCC_PCIE_3A_AUX_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ interconnects = <&pcie_west_anoc MASTER_PCIE_3A QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&hsc_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS
+ &pcie_west_slv_noc SLAVE_PCIE_3A QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "pcie-mem",
+ "cpu-pcie";
+
+ resets = <&gcc GCC_PCIE_3A_BCR>,
+ <&gcc GCC_PCIE_3A_LINK_DOWN_BCR>;
+ reset-names = "pci",
+ "link_down";
+
+ power-domains = <&gcc GCC_PCIE_3A_GDSC>;
+
+ eq-presets-8gts = /bits/ 16 <0x5555 0x5555 0x5555 0x5555
+ 0x5555 0x5555 0x5555 0x5555>;
+ eq-presets-16gts = /bits/ 8 <0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55>;
+ eq-presets-32gts = /bits/ 8 <0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55>;
+
+ status = "disabled";
+
+ pcie3a_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ /* GEN 1 x1 */
+ opp-2500000-1 {
+ opp-hz = /bits/ 64 <2500000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <250000 1>;
+ opp-level = <1>;
+ };
+
+ /* GEN 1 x2 */
+ opp-5000000-1 {
+ opp-hz = /bits/ 64 <5000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <500000 1>;
+ opp-level = <1>;
+ };
+
+ /* GEN 1 x4 */
+ opp-10000000-1 {
+ opp-hz = /bits/ 64 <10000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <1000000 1>;
+ opp-level = <1>;
+ };
+
+ /* GEN 1 x8 */
+ opp-20000000-1 {
+ opp-hz = /bits/ 64 <20000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <2000000 1>;
+ opp-level = <1>;
+ };
+
+ /* GEN 2 x1 */
+ opp-5000000-2 {
+ opp-hz = /bits/ 64 <5000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <500000 1>;
+ opp-level = <2>;
+ };
+
+ /* GEN 2 x2 */
+ opp-10000000-2 {
+ opp-hz = /bits/ 64 <10000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <1000000 1>;
+ opp-level = <2>;
+ };
+
+ /* GEN 2 x4 */
+ opp-20000000-2 {
+ opp-hz = /bits/ 64 <20000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <2000000 1>;
+ opp-level = <2>;
+ };
+
+ /* GEN 2 x8 */
+ opp-40000000-2 {
+ opp-hz = /bits/ 64 <40000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <4000000 1>;
+ opp-level = <2>;
+ };
+
+ /* GEN 3 x1 */
+ opp-8000000-3 {
+ opp-hz = /bits/ 64 <8000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <984500 1>;
+ opp-level = <3>;
+ };
+
+ /* GEN 3 x2 */
+ opp-16000000-3 {
+ opp-hz = /bits/ 64 <16000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <1969000 1>;
+ opp-level = <3>;
+ };
+
+ /* GEN 3 x4 */
+ opp-32000000-3 {
+ opp-hz = /bits/ 64 <32000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <3938000 1>;
+ opp-level = <3>;
+ };
+
+ /* GEN 3 x8 */
+ opp-64000000-3 {
+ opp-hz = /bits/ 64 <64000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <7876000 1>;
+ opp-level = <3>;
+ };
+
+ /* GEN 4 x1 */
+ opp-16000000-4 {
+ opp-hz = /bits/ 64 <16000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ opp-peak-kBps = <1969000 1>;
+ opp-level = <4>;
+ };
+
+ /* GEN 4 x2 */
+ opp-32000000-4 {
+ opp-hz = /bits/ 64 <32000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ opp-peak-kBps = <3938000 1>;
+ opp-level = <4>;
+ };
+
+ /* GEN 4 x4 */
+ opp-64000000-4 {
+ opp-hz = /bits/ 64 <64000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ opp-peak-kBps = <7876000 1>;
+ opp-level = <4>;
+ };
+
+ /* GEN 4 x8 */
+ opp-128000000-4 {
+ opp-hz = /bits/ 64 <128000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ opp-peak-kBps = <15753000 1>;
+ opp-level = <4>;
+ };
+
+ /* GEN 5 x1 */
+ opp-32000000-5 {
+ opp-hz = /bits/ 64 <32000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ opp-peak-kBps = <3938000 1>;
+ opp-level = <5>;
+ };
+
+ /* GEN 5 x2 */
+ opp-64000000-5 {
+ opp-hz = /bits/ 64 <64000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ opp-peak-kBps = <7876000 1>;
+ opp-level = <5>;
+ };
+
+ /* GEN 5 x4 */
+ opp-128000000-5 {
+ opp-hz = /bits/ 64 <128000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ opp-peak-kBps = <15753000 1>;
+ opp-level = <5>;
+ };
+
+ /* GEN 5 x8 */
+ opp-256000000-5 {
+ opp-hz = /bits/ 64 <256000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ opp-peak-kBps = <31506000 1>;
+ opp-level = <5>;
+ };
+ };
+
+ pcie3a_port0: pcie@0 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ phys = <&pcie3a_phy>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
+ };
+
+ pcie3a_phy: phy@f00000 {
+ compatible = "qcom,glymur-qmp-gen5x8-pcie-phy";
+ reg = <0 0x00f00000 0 0x10000>;
+
+ clocks = <&gcc GCC_PCIE_PHY_3A_AUX_CLK>,
+ <&gcc GCC_PCIE_3A_CFG_AHB_CLK>,
+ <&tcsr TCSR_PCIE_3_CLKREF_EN>,
+ <&gcc GCC_PCIE_3A_PHY_RCHNG_CLK>,
+ <&gcc GCC_PCIE_3A_PIPE_CLK>,
+ <&gcc GCC_PCIE_PHY_3B_AUX_CLK>;
+ clock-names = "aux",
+ "cfg_ahb",
+ "ref",
+ "rchng",
+ "pipe",
+ "phy_b_aux";
+
+ resets = <&gcc GCC_PCIE_3A_PHY_BCR>,
+ <&gcc GCC_PCIE_3A_NOCSR_COM_PHY_BCR>,
+ <&gcc GCC_PCIE_3B_PHY_BCR>,
+ <&gcc GCC_PCIE_3B_NOCSR_COM_PHY_BCR>;
+ reset-names = "phy",
+ "phy_nocsr",
+ "phy_b",
+ "phy_b_nocsr";
+
+ assigned-clocks = <&gcc GCC_PCIE_3A_PHY_RCHNG_CLK>;
+ assigned-clock-rates = <100000000>;
+
+ power-domains = <&gcc GCC_PCIE_3A_PHY_GDSC>,
+ <&gcc GCC_PCIE_3B_PHY_GDSC>;
+
+ #clock-cells = <0>;
+ clock-output-names = "pcie3a_pipe_clk";
+
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+
pcie4: pci@1bf0000 {
device_type = "pci";
compatible = "qcom,glymur-pcie", "qcom,pcie-x1e80100";
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 4/5] phy: qcom: qmp-pcie: Add Gen5 8-lanes mode for Glymur
From: Qiang Yu @ 2026-03-23 7:15 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Qiang Yu
In-Reply-To: <20260323-glymur_gen5x8_phy_0323-v2-0-ce0fc07f0e52@oss.qualcomm.com>
The third PCIe controller on Glymur SoC supports 8-lane operation via
bifurcation of two PHYs (each requires separate power domian, resets and
aux clk).
Add dedicated reset/no_csr reset list ("phy_b", "phy_b_nocsr") and
clock ("phy_b_aux") required for 8-lane operation. Introduce new
glymur_qmp_gen5x8_pciephy_cfg configuration to enable PCIe Gen5 x8 mode.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index 51db9eea41255bad0034bbcfbfdc36894c2bc95f..e872b50b11da50e6317ce7e1acf6385925f92cdb 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -3376,7 +3376,7 @@ static inline void qphy_clrbits(void __iomem *base, u32 offset, u32 val)
/* list of clocks required by phy */
static const char * const qmp_pciephy_clk_l[] = {
- "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux",
+ "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", "phy_b_aux",
};
/* list of regulators */
@@ -3401,6 +3401,14 @@ static const char * const sm8550_pciephy_nocsr_reset_l[] = {
"phy_nocsr",
};
+static const char * const glymur_pciephy_reset_l[] = {
+ "phy", "phy_b"
+};
+
+static const char * const glymur_pciephy_nocsr_reset_l[] = {
+ "phy_nocsr", "phy_b_nocsr",
+};
+
static const struct qmp_pcie_offsets qmp_pcie_offsets_qhp = {
.serdes = 0,
.pcs = 0x1800,
@@ -4705,6 +4713,23 @@ static const struct qmp_phy_cfg glymur_qmp_gen4x2_pciephy_cfg = {
.phy_status = PHYSTATUS_4_20,
};
+static const struct qmp_phy_cfg glymur_qmp_gen5x8_pciephy_cfg = {
+ .lanes = 8,
+
+ .offsets = &qmp_pcie_offsets_v8_50,
+
+ .reset_list = glymur_pciephy_reset_l,
+ .num_resets = ARRAY_SIZE(glymur_pciephy_reset_l),
+ .nocsr_reset_list = glymur_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(glymur_pciephy_nocsr_reset_l),
+ .vreg_list = qmp_phy_vreg_l,
+ .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
+
+ .regs = pciephy_v8_50_regs_layout,
+
+ .phy_status = PHYSTATUS_4_20,
+};
+
static void qmp_pcie_init_port_b(struct qmp_pcie *qmp, const struct qmp_phy_cfg_tbls *tbls)
{
const struct qmp_phy_cfg *cfg = qmp->cfg;
@@ -5483,6 +5508,9 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
}, {
.compatible = "qcom,glymur-qmp-gen5x4-pcie-phy",
.data = &glymur_qmp_gen5x4_pciephy_cfg,
+ }, {
+ .compatible = "qcom,glymur-qmp-gen5x8-pcie-phy",
+ .data = &glymur_qmp_gen5x8_pciephy_cfg,
}, {
.compatible = "qcom,ipq6018-qmp-pcie-phy",
.data = &ipq6018_pciephy_cfg,
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 3/5] phy: qcom: qmp-pcie: Support multiple nocsr resets
From: Qiang Yu @ 2026-03-23 7:15 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Qiang Yu
In-Reply-To: <20260323-glymur_gen5x8_phy_0323-v2-0-ce0fc07f0e52@oss.qualcomm.com>
Refactor nocsr reset handling to support multiple nocsr resets required
for PHY configurations with bifurcated operation modes.
The Glymur SoC's 3rd PCIe instance supports 8-lane mode using two PHYs
in bifurcation, where each PHY requires its own nocsr reset to be
controlled simultaneously. The current implementation only supports a
single nocsr reset per PHY configuration.
Add num_nocsr and nocsr_list fields to struct qmp_phy_cfg to represent the
number and names of a group of nocsr reset names. Initialize these fields
for all PHYs that have nocsr resets, allowing the driver to correctly
acquire multiple nocsr resets during probe and control them as an array
by using reset_control_bulk APIs.
The refactoring maintains backward compatibility for existing single
nocsr reset configurations while enabling support for multi-PHY
scenarios like Glymur's 8-lane bifurcation mode.
Additionally, introduces x1e80100_qmp_gen3x2_pciephy_cfg as a separate
configuration from sm8550_qmp_gen3x2_pciephy_cfg since the x1e80100 Gen3x2
PHY requires nocsr reset support while the sm8550 Gen3x2 PHY does not.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 87 ++++++++++++++++++++++++++++----
1 file changed, 77 insertions(+), 10 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index 424c935e27a8766e1e26762bd3d7df527c1520e3..51db9eea41255bad0034bbcfbfdc36894c2bc95f 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -3281,6 +3281,11 @@ struct qmp_phy_cfg {
/* resets to be requested */
const char * const *reset_list;
int num_resets;
+
+ /* nocsr resets to be requested */
+ const char * const *nocsr_reset_list;
+ int num_nocsr_resets;
+
/* regulators to be requested */
const char * const *vreg_list;
int num_vregs;
@@ -3327,7 +3332,7 @@ struct qmp_pcie {
int num_pipe_clks;
struct reset_control_bulk_data *resets;
- struct reset_control *nocsr_reset;
+ struct reset_control_bulk_data *nocsr_reset;
struct regulator_bulk_data *vregs;
struct phy *phy;
@@ -3392,6 +3397,10 @@ static const char * const sdm845_pciephy_reset_l[] = {
"phy",
};
+static const char * const sm8550_pciephy_nocsr_reset_l[] = {
+ "phy_nocsr",
+};
+
static const struct qmp_pcie_offsets qmp_pcie_offsets_qhp = {
.serdes = 0,
.pcs = 0x1800,
@@ -4348,6 +4357,8 @@ static const struct qmp_phy_cfg sm8550_qmp_gen4x2_pciephy_cfg = {
},
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
.vreg_list = sm8550_qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(sm8550_qmp_phy_vreg_l),
.regs = pciephy_v6_regs_layout,
@@ -4380,6 +4391,8 @@ static const struct qmp_phy_cfg sm8650_qmp_gen4x2_pciephy_cfg = {
},
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
.vreg_list = sm8550_qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(sm8550_qmp_phy_vreg_l),
.regs = pciephy_v6_regs_layout,
@@ -4480,6 +4493,35 @@ static const struct qmp_phy_cfg sa8775p_qmp_gen4x4_pciephy_cfg = {
.phy_status = PHYSTATUS_4_20,
};
+static const struct qmp_phy_cfg x1e80100_qmp_gen3x2_pciephy_cfg = {
+ .lanes = 2,
+
+ .offsets = &qmp_pcie_offsets_v5,
+
+ .tbls = {
+ .serdes = sm8550_qmp_gen3x2_pcie_serdes_tbl,
+ .serdes_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_serdes_tbl),
+ .tx = sm8550_qmp_gen3x2_pcie_tx_tbl,
+ .tx_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_tx_tbl),
+ .rx = sm8550_qmp_gen3x2_pcie_rx_tbl,
+ .rx_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_rx_tbl),
+ .pcs = sm8550_qmp_gen3x2_pcie_pcs_tbl,
+ .pcs_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_pcs_tbl),
+ .pcs_misc = sm8550_qmp_gen3x2_pcie_pcs_misc_tbl,
+ .pcs_misc_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_pcs_misc_tbl),
+ },
+ .reset_list = sdm845_pciephy_reset_l,
+ .num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
+ .vreg_list = qmp_phy_vreg_l,
+ .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
+ .regs = pciephy_v5_regs_layout,
+
+ .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
+ .phy_status = PHYSTATUS,
+};
+
static const struct qmp_phy_cfg x1e80100_qmp_gen4x2_pciephy_cfg = {
.lanes = 2,
@@ -4502,6 +4544,8 @@ static const struct qmp_phy_cfg x1e80100_qmp_gen4x2_pciephy_cfg = {
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
.vreg_list = qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = pciephy_v6_regs_layout,
@@ -4535,6 +4579,8 @@ static const struct qmp_phy_cfg x1e80100_qmp_gen4x4_pciephy_cfg = {
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
.vreg_list = qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = pciephy_v6_regs_layout,
@@ -4566,6 +4612,8 @@ static const struct qmp_phy_cfg x1e80100_qmp_gen4x8_pciephy_cfg = {
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
.vreg_list = qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = pciephy_v6_regs_layout,
@@ -4581,6 +4629,8 @@ static const struct qmp_phy_cfg qmp_v6_gen4x4_pciephy_cfg = {
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
.vreg_list = qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = pciephy_v6_regs_layout,
@@ -4609,6 +4659,8 @@ static const struct qmp_phy_cfg qmp_v8_gen3x2_pciephy_cfg = {
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
.vreg_list = qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = pciephy_v8_regs_layout,
@@ -4624,6 +4676,8 @@ static const struct qmp_phy_cfg glymur_qmp_gen5x4_pciephy_cfg = {
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
.vreg_list = qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
@@ -4640,6 +4694,8 @@ static const struct qmp_phy_cfg glymur_qmp_gen4x2_pciephy_cfg = {
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
.vreg_list = qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
@@ -4768,7 +4824,7 @@ static int qmp_pcie_init(struct phy *phy)
}
}
- ret = reset_control_assert(qmp->nocsr_reset);
+ ret = reset_control_bulk_assert(cfg->num_nocsr_resets, qmp->nocsr_reset);
if (ret) {
dev_err(qmp->dev, "no-csr reset assert failed\n");
goto err_assert_reset;
@@ -4805,7 +4861,7 @@ static int qmp_pcie_exit(struct phy *phy)
const struct qmp_phy_cfg *cfg = qmp->cfg;
if (qmp->nocsr_reset)
- reset_control_assert(qmp->nocsr_reset);
+ reset_control_bulk_assert(cfg->num_nocsr_resets, qmp->nocsr_reset);
else
reset_control_bulk_assert(cfg->num_resets, qmp->resets);
@@ -4849,7 +4905,7 @@ static int qmp_pcie_power_on(struct phy *phy)
if (ret)
return ret;
- ret = reset_control_deassert(qmp->nocsr_reset);
+ ret = reset_control_bulk_deassert(cfg->num_nocsr_resets, qmp->nocsr_reset);
if (ret) {
dev_err(qmp->dev, "no-csr reset deassert failed\n");
goto err_disable_pipe_clk;
@@ -4998,14 +5054,25 @@ static int qmp_pcie_reset_init(struct qmp_pcie *qmp)
for (i = 0; i < cfg->num_resets; i++)
qmp->resets[i].id = cfg->reset_list[i];
- ret = devm_reset_control_bulk_get_exclusive(dev, cfg->num_resets, qmp->resets);
+ ret = devm_reset_control_bulk_get_exclusive(dev, cfg->num_resets,
+ qmp->resets);
if (ret)
return dev_err_probe(dev, ret, "failed to get resets\n");
- qmp->nocsr_reset = devm_reset_control_get_optional_exclusive(dev, "phy_nocsr");
- if (IS_ERR(qmp->nocsr_reset))
- return dev_err_probe(dev, PTR_ERR(qmp->nocsr_reset),
- "failed to get no-csr reset\n");
+ if (!cfg->num_nocsr_resets)
+ return 0;
+ qmp->nocsr_reset = devm_kcalloc(dev, cfg->num_nocsr_resets,
+ sizeof(*qmp->nocsr_reset), GFP_KERNEL);
+ if (!qmp->nocsr_reset)
+ return -ENOMEM;
+
+ for (i = 0; i < cfg->num_nocsr_resets; i++)
+ qmp->nocsr_reset[i].id = cfg->nocsr_reset_list[i];
+
+ ret = devm_reset_control_bulk_get_exclusive(dev, cfg->num_nocsr_resets,
+ qmp->nocsr_reset);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to get no-csr reset\n");
return 0;
}
@@ -5520,7 +5587,7 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
.data = &sm8750_qmp_gen3x2_pciephy_cfg,
}, {
.compatible = "qcom,x1e80100-qmp-gen3x2-pcie-phy",
- .data = &sm8550_qmp_gen3x2_pciephy_cfg,
+ .data = &x1e80100_qmp_gen3x2_pciephy_cfg,
}, {
.compatible = "qcom,x1e80100-qmp-gen4x2-pcie-phy",
.data = &x1e80100_qmp_gen4x2_pciephy_cfg,
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 2/5] phy: qcom: qmp-pcie: Add multiple power-domains support
From: Qiang Yu @ 2026-03-23 7:15 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Qiang Yu
In-Reply-To: <20260323-glymur_gen5x8_phy_0323-v2-0-ce0fc07f0e52@oss.qualcomm.com>
The Glymur SoC's 3rd PCIe instance supports 8-lane mode using two PHYs in
a bifurcated configuration. Each PHY has its own power domain (phy_gdsc)
that must be powered on before initialization per hardware requirements.
Current PHY power management assumes a single power domain per PHY,
preventing proper setup for this dual-PHY scenario. Add support for
multiple power domains by using devm_pm_domain_attach_list() to attach
power domains manually, while maintaining compatibility with single
power domain PHYs.
Enable runtime PM to allow power domain control when the PCIe driver
calls phy_power_on/phy_power_off:
- Single power domain: QMP PHY platform device directly attaches to
power domain and controls it during runtime resume/suspend
- Multiple power domains: devm_pm_domain_attach_list() creates virtual
devices as power domain suppliers, linked to the QMP PHY platform
device as consumer
This ensures power domains are properly attached and turned on/off
for both single and multiple power domain configurations.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index fed2fc9bb31108d51f88d34f3379c7744681f485..424c935e27a8766e1e26762bd3d7df527c1520e3 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -17,6 +17,7 @@
#include <linux/phy/pcie.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
#include <linux/reset.h>
@@ -5329,6 +5330,7 @@ static int qmp_pcie_parse_dt(struct qmp_pcie *qmp)
static int qmp_pcie_probe(struct platform_device *pdev)
{
+ struct dev_pm_domain_list *pd_list;
struct device *dev = &pdev->dev;
struct phy_provider *phy_provider;
struct device_node *np;
@@ -5348,6 +5350,16 @@ static int qmp_pcie_probe(struct platform_device *pdev)
WARN_ON_ONCE(!qmp->cfg->pwrdn_ctrl);
WARN_ON_ONCE(!qmp->cfg->phy_status);
+ ret = devm_pm_domain_attach_list(dev, NULL, &pd_list);
+ if (ret < 0 && ret != -EEXIST) {
+ dev_err(dev, "Failed to attach power domain\n");
+ return ret;
+ }
+
+ ret = devm_pm_runtime_enable(dev);
+ if (ret)
+ return ret;
+
ret = qmp_pcie_clk_init(qmp);
if (ret)
return ret;
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 1/5] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add support for glymur Gen5 x8 bifurcation mode
From: Qiang Yu @ 2026-03-23 7:15 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Qiang Yu
In-Reply-To: <20260323-glymur_gen5x8_phy_0323-v2-0-ce0fc07f0e52@oss.qualcomm.com>
The Glymur SoC has pcie3a and pcie3b PHYs that can operate in two modes:
1. Independent 4-lane mode: Each PHY operates as a separate PCIe Gen5
4-lane interface, compatible with qcom,glymur-qmp-gen5x4-pcie-phy
2. Bifurcation mode (8-lane): pcie3a phy acts as leader and pcie3b phy as
follower to form a single 8-lane PCIe Gen5 interface
In bifurcation mode, the hardware design requires controlling additional
resources beyond the standard pcie3a PHY configuration:
- pcie3b's aux_clk (phy_b_aux)
- pcie3b's phy_gdsc power domain
- pcie3b's bcr/nocsr reset
Add qcom,glymur-qmp-gen5x8-pcie-phy compatible string to document this
8-lane bifurcation configuration.
The phy_b_aux clock is used as the 6th clock instead of pipediv2,
requiring the clock-names enum to be extended to support both
[phy_b_aux, pipediv2] options at index 5. This follows the existing
pattern used for [rchng, refgen] clocks at index 3.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
.../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 45 ++++++++++++++++++----
1 file changed, 37 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
index 3a35120a77ec0ceb814a1cdcacff32fef32b4f7b..25717bc9be98824e38f3c27c3299fbd1f2e7e299 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
@@ -18,6 +18,7 @@ properties:
enum:
- qcom,glymur-qmp-gen4x2-pcie-phy
- qcom,glymur-qmp-gen5x4-pcie-phy
+ - qcom,glymur-qmp-gen5x8-pcie-phy
- qcom,kaanapali-qmp-gen3x2-pcie-phy
- qcom,qcs615-qmp-gen3x1-pcie-phy
- qcom,qcs8300-qmp-gen4x2-pcie-phy
@@ -68,20 +69,23 @@ properties:
- const: ref
- enum: [rchng, refgen]
- const: pipe
- - const: pipediv2
+ - enum: [phy_b_aux, pipediv2]
power-domains:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
resets:
minItems: 1
- maxItems: 2
+ maxItems: 4
reset-names:
minItems: 1
items:
- const: phy
- const: phy_nocsr
+ - const: phy_b
+ - const: phy_b_nocsr
vdda-phy-supply: true
@@ -183,6 +187,7 @@ allOf:
enum:
- qcom,glymur-qmp-gen4x2-pcie-phy
- qcom,glymur-qmp-gen5x4-pcie-phy
+ - qcom,glymur-qmp-gen5x8-pcie-phy
- qcom,qcs8300-qmp-gen4x2-pcie-phy
- qcom,sa8775p-qmp-gen4x2-pcie-phy
- qcom,sa8775p-qmp-gen4x4-pcie-phy
@@ -201,6 +206,17 @@ allOf:
clock-names:
minItems: 6
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,glymur-qmp-gen5x8-pcie-phy
+ then:
+ properties:
+ power-domains:
+ minItems: 2
+
- if:
properties:
compatible:
@@ -223,11 +239,24 @@ allOf:
reset-names:
minItems: 2
else:
- properties:
- resets:
- maxItems: 1
- reset-names:
- maxItems: 1
+ if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,glymur-qmp-gen5x8-pcie-phy
+ then:
+ properties:
+ resets:
+ minItems: 4
+ reset-names:
+ minItems: 4
+ else:
+ properties:
+ resets:
+ maxItems: 1
+ reset-names:
+ maxItems: 1
- if:
properties:
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
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