* Re: (subset) [PATCH 00/27] clk: remove deprecated API divider_round_rate() and friends
From: Bjorn Andersson @ 2026-01-10 19:11 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney
Cc: linux-clk, linux-kernel, Chen Wang, Inochi Amaoto, sophgo,
Chen-Yu Tsai, Maxime Ripard, Jernej Skrabec, Samuel Holland,
linux-arm-kernel, linux-sunxi, Alexandre Belloni, linux-rtc,
Andreas Färber, Manivannan Sadhasivam, linux-actions,
Keguang Zhang, linux-mips, Taichi Sugaya, Takao Orito,
Jacky Huang, Shan-Chun Hung, Vladimir Zapolskiy,
Piotr Wojtaszczyk, linux-arm-msm, Orson Zhai, Baolin Wang,
Chunyan Zhang, Maxime Coquelin, Alexandre Torgue, linux-stm32,
Michal Simek, Rob Clark, Dmitry Baryshkov, David Airlie,
Simona Vetter, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, dri-devel, freedreno, Vinod Koul, Neil Armstrong,
linux-phy
In-Reply-To: <20260108-clk-divider-round-rate-v1-0-535a3ed73bf3@redhat.com>
On Thu, 08 Jan 2026 16:16:18 -0500, Brian Masney wrote:
> Here's a series that gets rid of the deprecated APIs
> divider_round_rate(), divider_round_rate_parent(), and
> divider_ro_round_rate_parent() since these functions are just wrappers
> for the determine_rate variant.
>
> Note that when I converted some of these drivers from round_rate to
> determine_rate, this was mistakenly converted to the following in some
> cases:
>
> [...]
Applied, thanks!
[14/27] clk: qcom: alpha-pll: convert from divider_round_rate() to divider_determine_rate()
commit: e1f08613e113f02a3ec18c9a7964de97f940acbf
[15/27] clk: qcom: regmap-divider: convert from divider_ro_round_rate() to divider_ro_determine_rate()
commit: 35a48f41b63f67c490f3a2a89b042536be67cf0f
[16/27] clk: qcom: regmap-divider: convert from divider_round_rate() to divider_determine_rate()
commit: b2f36d675e09299d9aee395c6f83d8a95d4c9441
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 v2 net-next 07/10] net: phy: air_en8811h: deprecate "airoha,pnswap-rx" and "airoha,pnswap-tx"
From: Vladimir Oltean @ 2026-01-10 18:41 UTC (permalink / raw)
To: Bjørn Mork
Cc: netdev, devicetree, linux-phy, linux-kernel, linux-arm-kernel,
linux-mediatek, Daniel Golle, Horatiu Vultur, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, Matthias Brugger,
AngeloGioacchino Del Regno, Eric Woudstra, Marek Behún,
Lee Jones, Patrice Chotard
In-Reply-To: <87qzs2a7hl.fsf@miraculix.mork.no>
On Tue, Jan 06, 2026 at 08:03:50PM +0100, Bjørn Mork wrote:
> Vladimir Oltean <vladimir.oltean@nxp.com> writes:
>
> > diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> > index a7ade7b95a2e..7b73332a13d9 100644
> > --- a/drivers/net/phy/Kconfig
> > +++ b/drivers/net/phy/Kconfig
> > @@ -98,6 +98,7 @@ config AS21XXX_PHY
> >
> > config AIR_EN8811H_PHY
> > tristate "Airoha EN8811H 2.5 Gigabit PHY"
> > + select PHY_COMMON_PROPS
>
> GENERIC_PHY_COMMON_PROPS maybe?
FWIW, I'm renaming this to PHY_COMMON_PROPS across the board. The
properties are common between generic PHY and Ethernet PHY/PCS, hence
calling them "generic PHY common properties" is a bit incorrect.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 net-next 05/10] phy: add phy_get_rx_polarity() and phy_get_tx_polarity()
From: Vladimir Oltean @ 2026-01-10 18:19 UTC (permalink / raw)
To: Bjørn Mork
Cc: netdev, devicetree, linux-phy, linux-kernel, linux-arm-kernel,
linux-mediatek, Daniel Golle, Horatiu Vultur, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, Matthias Brugger,
AngeloGioacchino Del Regno, Eric Woudstra, Marek Behún,
Lee Jones, Patrice Chotard
In-Reply-To: <87zf6l49y9.fsf@miraculix.mork.no>
On Sat, Jan 10, 2026 at 07:08:30PM +0100, Bjørn Mork wrote:
> Vladimir Oltean <vladimir.oltean@nxp.com> writes:
>
> > I've integrated your test and added one more for RX. Do you have any
> > further comments, or shall I send an updated v3?
>
> That was everything I've found.
>
>
> Bjørn
Ok. I'll add your Co-developed-by and Signed-off-by tags for the tests,
if you don't mind. I'll also do some build testing, so I'm not sure if
I'll manage to send v3 today.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 net-next 05/10] phy: add phy_get_rx_polarity() and phy_get_tx_polarity()
From: Bjørn Mork @ 2026-01-10 18:08 UTC (permalink / raw)
To: Vladimir Oltean
Cc: netdev, devicetree, linux-phy, linux-kernel, linux-arm-kernel,
linux-mediatek, Daniel Golle, Horatiu Vultur, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, Matthias Brugger,
AngeloGioacchino Del Regno, Eric Woudstra, Marek Behún,
Lee Jones, Patrice Chotard
In-Reply-To: <20260110180433.bfg2hxbdjkfllkiq@skbuf>
Vladimir Oltean <vladimir.oltean@nxp.com> writes:
> I've integrated your test and added one more for RX. Do you have any
> further comments, or shall I send an updated v3?
That was everything I've found.
Bjørn
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 net-next 05/10] phy: add phy_get_rx_polarity() and phy_get_tx_polarity()
From: Vladimir Oltean @ 2026-01-10 18:04 UTC (permalink / raw)
To: Bjørn Mork
Cc: netdev, devicetree, linux-phy, linux-kernel, linux-arm-kernel,
linux-mediatek, Daniel Golle, Horatiu Vultur, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, Matthias Brugger,
AngeloGioacchino Del Regno, Eric Woudstra, Marek Behún,
Lee Jones, Patrice Chotard
In-Reply-To: <87jyxtaljn.fsf@miraculix.mork.no>
Hi Bjørn,
On Wed, Jan 07, 2026 at 09:12:28AM +0100, Bjørn Mork wrote:
> Vladimir Oltean <vladimir.oltean@nxp.com> writes:
>
> > +static int fwnode_get_u32_prop_for_name(struct fwnode_handle *fwnode,
> > + const char *name,
> > + const char *props_title,
> > + const char *names_title,
> > + unsigned int default_val,
> > + unsigned int *val)
> > +{
> > + int err, n_props, n_names, idx = -1;
> > + u32 *props;
> > +
> > + if (!name) {
> > + pr_err("Lookup key inside \"%s\" is mandatory\n", names_title);
> > + return -EINVAL;
> > + }
> > +
> > + if (!fwnode) {
> > + *val = default_val;
> > + return 0;
> > + }
> > +
> > + err = fwnode_property_count_u32(fwnode, props_title);
> > + if (err < 0)
> > + return err;
> > + if (err == 0) {
> > + *val = default_val;
> > + return 0;
> > + }
> > + n_props = err;
>
> I tried using this in the air_en8811h driver and started wondering if I
> have misunderstood something.
>
> The problem I have is that fwnode_property_count_u32() returns -EINVAL
> if props_title is missing. So if you have a node with the legacy
> "airoha,pnswap-rx" property instead of "rx-polarity", or more common: no
> polariy property at all, then we see -EINVAL returned from
> phy_get_rx_polarity(). Which is propagated back to config_init() and
> the phy fails to attach. That can't be the intention?
>
> The behaviour I expected is described by this test:
>
>
> /* Test: tx-polarity property is missing */
> static void phy_test_tx_polarity_is_missing(struct kunit *test)
> {
> static const struct property_entry entries[] = {
> {}
> };
> struct fwnode_handle *node;
> unsigned int val;
> int ret;
>
> node = fwnode_create_software_node(entries, NULL);
> KUNIT_ASSERT_NOT_ERR_OR_NULL(test, node);
>
> ret = phy_get_manual_tx_polarity(node, "sgmi", &val);
> KUNIT_EXPECT_EQ(test, ret, 0);
> KUNIT_EXPECT_EQ(test, val, PHY_POL_NORMAL);
>
> fwnode_remove_software_node(node);
> }
Thanks for debugging and for the test! This is a regression from v1,
where I just checked the fwnode_property_count_u32() return code for
being <= 0.
I've integrated your test and added one more for RX. Do you have any
further comments, or shall I send an updated v3?
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/5] PCI: dwc: Add support for retaining link during host init
From: Bjorn Helgaas @ 2026-01-09 15:53 UTC (permalink / raw)
To: Krishna Chaitanya Chundru
Cc: Vinod Koul, Neil Armstrong, Philipp Zabel, Jingoo Han,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
linux-arm-msm, linux-phy, linux-kernel, linux-pci
In-Reply-To: <20260109-link_retain-v1-2-7e6782230f4b@oss.qualcomm.com>
On Fri, Jan 09, 2026 at 12:51:07PM +0530, Krishna Chaitanya Chundru wrote:
> Some platforms keep the PCIe link up across bootloader and kernel
> handoff. In such cases, reinitializing the root complex is unnecessary
> if the DWC glue drivers wants to retain the PCIe link.
>
> Introduce a link_retain flag in struct dw_pcie_rp to indicate that
> the link should be preserved. When this flag is set by DWC glue drivers,
> skip dw_pcie_setup_rc() and only initialize MSI, avoiding redundant
> configuration steps.
It sounds like this adds an assumption that the bootloader
initialization is the same as what dw_pcie_setup_rc() would do. This
assumption also applies to future changes in dw_pcie_setup_rc().
It looks like you mention an issue like this in [PATCH 4/5]; DBI & ATU
base being different than "HLOS" (whatever that is). This sounds like
a maintenance issue keeping bootloader and kernel driver assumptions
synchronized.
Is there something in dw_pcie_setup_rc() that takes a lot of time or
forces a link retrain? You mentioned some clock and GENPD issues in
the cover letter, but I don't see the connection between those and
dw_pcie_setup_rc(). If there is a connection, please include it in
this commit log and include a code comment about why
dw_pcie_setup_rc() is being skipped.
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> ---
> drivers/pci/controller/dwc/pcie-designware-host.c | 11 ++++++++---
> drivers/pci/controller/dwc/pcie-designware.h | 1 +
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 372207c33a857b4c98572bb1e9b61fa0080bc871..d050df3f22e9507749a8f2fedd4c24fca43fb410 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -655,9 +655,14 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
> if (ret)
> goto err_free_msi;
>
> - ret = dw_pcie_setup_rc(pp);
> - if (ret)
> - goto err_remove_edma;
> + if (!pp->link_retain) {
Use positive logic if possible (test "pp->link_retain" instead of
"!pp->link_retain").
I suspect this would be more maintainable if you identified specific
things *inside* dw_pcie_setup_rc() that need to be skipped, and you
added tests there.
> + ret = dw_pcie_setup_rc(pp);
> + if (ret)
> + goto err_remove_edma;
> + } else {
> + dw_pcie_msi_init(pp);
> + }
> +
>
> if (!dw_pcie_link_up(pci)) {
> ret = dw_pcie_start_link(pci);
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
> index 31685951a080456b8834aab2bf79a36c78f46639..8acab751b66a06e8322e027ab55dc0ecfdcf634c 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -439,6 +439,7 @@ struct dw_pcie_rp {
> struct pci_config_window *cfg;
> bool ecam_enabled;
> bool native_ecam;
> + bool link_retain;
> };
>
> struct dw_pcie_ep_ops {
>
> --
> 2.34.1
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2] phy: rockchip: inno-usb2: Fix a double free bug in rockchip_usb2phy_probe()
From: Wentao Liang @ 2026-01-09 15:46 UTC (permalink / raw)
To: vkoul, kishon, heiko
Cc: linux-phy, linux-rockchip, linux-kernel, linux-arm-kernel,
Wentao Liang, stable
The for_each_available_child_of_node() calls of_node_put() to
release child_np in each success loop. After breaking from the
loop with the child_np has been released, the code will jump to
the put_child label and will call the of_node_put() again if the
devm_request_threaded_irq() fails. These cause a double free bug.
Fix by returning directly to avoid the duplicate of_node_put().
Fixes: ed2b5a8e6b98 ("phy: phy-rockchip-inno-usb2: support muxed interrupts")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
Changes in v2:
- Drop error jumping label.
---
drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index b0f23690ec30..fe97a26297af 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -1491,7 +1491,7 @@ static int rockchip_usb2phy_probe(struct platform_device *pdev)
rphy);
if (ret) {
dev_err_probe(rphy->dev, ret, "failed to request usb2phy irq handle\n");
- goto put_child;
+ 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
* Re: [PATCH v6 00/14] Add USB2.0 support for RZ/G3E
From: Tommaso Merciai @ 2026-01-09 15:32 UTC (permalink / raw)
To: tomm.merciai
Cc: linux-renesas-soc, biju.das.jz, Peter Rosin, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
Fabrizio Castro, Lad Prabhakar, Philipp Zabel, Geert Uytterhoeven,
Magnus Damm, Uwe Kleine-König, Sebastian Reichel,
Georgi Djakov, Greg Kroah-Hartman, Arnd Bergmann,
Yoshihiro Shimoda, devicetree, linux-kernel, linux-phy
In-Reply-To: <cover.1766405010.git.tommaso.merciai.xr@bp.renesas.com>
Dear All,
A gentle ping on this patch series.
Thanks & Regards,
Tommaso
On Mon, Dec 22, 2025 at 02:43:34PM +0100, Tommaso Merciai wrote:
> Dear All,
>
> This patch series adds USB2.0 support for the Renesas
> RZ/G3E (a.k.a R9A09G047) R9A09G047 SoC.
>
> RZ/G3E has USB2.0 IP that is identical to the one's found into
> the RZ/V2H SoC (R9A09G057).
>
> Merge strategy, if any:
>
> - patches 1-2/14 can go through the MUX tree
> - patches 3-6/14 can go through the Reset tree
> - patches 7-13/14 can go through the PHY tree
> - patches 14-14/14 can go through the USB tree
>
> Note:
> - Reset driver (reset-rzv2h-usb2phy.c)
> has build dependency on Mux header file
> (reset_rzv2h_usb2phy.h).
>
> Thanks & Regards,
> Tommaso
>
> v5->v6:
> - Rebased on top of next-20251219
> - Re-arranged series order per subsystem patches.
> - Patch: 3/14: Collected tag.
> - Patch: 4/14: Fixed commit message.
> - Split from dts patches will send separate series.
> - Added merge strategy in cover letter.
>
> v4->v5:
> - Rebased on top of next-20251127
> - Patch 01/22: Added Reviewed-by tag from Conor Dooley.
> - Patch 06/22: Changed file name to rzv2h-usb-vbenctl.c and Fixed
> Makefile, Kconfig, function names accordingly.
> Changed driver .name to "vbenctl" and fix auxiliary_device_id name.
> Updated commit msg.
> - Patch 07/22: Update mux_name to "vbenctl" to match the driver name.
> Updated commit message.
> - Patch 11/22: Fixed if statement for mux_state error check.
>
> v3->v4:
> - Rebased on top of next-20251121
> - Added patch 01/22 to remove nodename pattern from mux-controller schema.
> - Switch back to v2 implementation for mux controller in patches
> 5/22, 15/22, 16/22, 21/22.
> - Improved commit bodies for patches 5/22, 15/22, 16/22, 21/22.
> - Removed mux_chip->dev.of_node not needed in patch 06/22.
> - Collected CDooley tag in patch 09/22.
> - Added missing select MULTIPLEXER into Kconfig in patch 11/22.
>
> v2->v3:
> - Rebased on top of next-20251110 + [1] + [2]
> - Add missing Cc: stable@vger.kernel.org in patch 03/21
> - Patch 03/21: Added missing Cc: stable@vger.kernel.org.
> Improved commit body describing the removal of rzv2h_usbphy_assert_helper()
> from rzv2h_usb2phy_reset_probe().
> - Patch 04/21: Manipulate mux-controller as an internal node.
> Improved commit body.
> - Patch 05/21: The main driver is using now __devm_auxiliary_device_create()
> then update the aux driver accordingly.
> - Patch 06/21: Use __devm_auxiliary_device_create() to create the aux device.
> - Patch 08/21: Improved commit body and mux-states description.
> - Patch 14/21: Manipulate the mux controller as an internal node,
> and update commit body accordingly.
> - Patch 15/21: Manipulate the mux controller as an internal node,
> and update commit body accordingly.
> - Patch 20/21: Manipulate the mux controller as an internal node.
>
> v1->v2:
> - Rebased on top of next-20251103 + [1] + [2]
> - Reworked series to use mux-state for controlling VBUS_SEL
> as suggested by PZabel added also mux bindings documentation
> on phy and rst side.
> - Collected Conor Dooley tags
> - Dropped unnecessary rzv2h_usbphy_assert_helper() function from
> rzv2h_usb2phy_reset_probe()
>
> Tommaso Merciai (14):
> dt-bindings: mux: Remove nodename pattern constraints
> mux: Add driver for Renesas RZ/V2H USB VBENCTL VBUS_SEL mux
> dt-bindings: reset: renesas,rzv2h-usb2phy: Add '#mux-state-cells'
> property
> dt-bindings: reset: renesas,rzv2h-usb2phy: Document RZ/G3E USB2PHY
> reset
> reset: rzv2h-usb2phy: Keep PHY clock enabled for entire device
> lifetime
> reset: rzv2h-usb2phy: Add support for VBUS mux controller registration
> dt-bindings: phy: renesas,usb2-phy: Document USB VBUS regulator
> dt-bindings: phy: renesas,usb2-phy: Document mux-states property
> dt-bindings: phy: renesas,usb2-phy: Document RZ/G3E SoC
> phy: renesas: rcar-gen3-usb2: Factor out VBUS control logic
> phy: renesas: rcar-gen3-usb2: Use devm_pm_runtime_enable()
> phy: renesas: rcar-gen3-usb2: Add regulator for OTG VBUS control
> phy: renesas: rcar-gen3-usb2: Use mux-state for phyrst management
> dt-bindings: usb: renesas,usbhs: Add RZ/G3E SoC support
>
> .../bindings/mux/mux-controller.yaml | 6 -
> .../bindings/phy/renesas,usb2-phy.yaml | 15 +-
> .../reset/renesas,rzv2h-usb2phy-reset.yaml | 9 +-
> .../bindings/usb/renesas,usbhs.yaml | 1 +
> drivers/mux/Kconfig | 11 +
> drivers/mux/Makefile | 2 +
> drivers/mux/rzv2h-usb-vbenctl.c | 97 +++++++
> drivers/phy/renesas/Kconfig | 1 +
> drivers/phy/renesas/phy-rcar-gen3-usb2.c | 261 ++++++++++++++----
> drivers/reset/Kconfig | 1 +
> drivers/reset/reset-rzv2h-usb2phy.c | 108 +++++---
> include/linux/reset/reset_rzv2h_usb2phy.h | 11 +
> 12 files changed, 420 insertions(+), 103 deletions(-)
> create mode 100644 drivers/mux/rzv2h-usb-vbenctl.c
> create mode 100644 include/linux/reset/reset_rzv2h_usb2phy.h
>
> --
> 2.43.0
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] drm/msm/dp: Correct LeMans/Monaco DP phy Swing/Emphasis setting
From: Dmitry Baryshkov @ 2026-01-09 15:27 UTC (permalink / raw)
To: Yongxing Mou
Cc: Vinod Koul, Neil Armstrong, linux-arm-msm, linux-phy,
linux-kernel
In-Reply-To: <20260109-klm_dpphy-v1-1-a6b6abe382de@oss.qualcomm.com>
On Fri, Jan 09, 2026 at 04:30:21PM +0800, Yongxing Mou wrote:
> Currently, the LeMans/Monaco DP PHY operates in DP mode rather than eDP
> mode. Per the PHY HPG, the Swing and Emphasis settings have been corrected
have been corrected... when?
> to the appropriate DP-mode values.
>
> Additionally, the HPG specifies that the LDO value should be set to 0 when
> in DP mode. These misconfigurations can lead to link training failures on
> certain dongles.
Separate commit
>
> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
Missing Fixes, cc:stable
> ---
> drivers/phy/qualcomm/phy-qcom-edp.c | 27 ++++++++++++++++++++++++---
> 1 file changed, 24 insertions(+), 3 deletions(-)
>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/5] phy: qcom: qmp-pcie: Skip PHY reset if already up
From: Dmitry Baryshkov @ 2026-01-09 14:03 UTC (permalink / raw)
To: Neil Armstrong
Cc: Krishna Chaitanya Chundru, Vinod Koul, Philipp Zabel, Jingoo Han,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
linux-arm-msm, linux-phy, linux-kernel, linux-pci
In-Reply-To: <53f0c45f-7f5c-4abd-af84-cbb82d509872@linaro.org>
On Fri, Jan 09, 2026 at 02:10:49PM +0100, Neil Armstrong wrote:
> On 1/9/26 14:08, Dmitry Baryshkov wrote:
> > On Fri, Jan 09, 2026 at 12:51:06PM +0530, Krishna Chaitanya Chundru wrote:
> > > If the bootloader has already powered up the PCIe PHY, doing a full
> > > reset and waiting for it to come up again slows down boot time.
> >
> > How big is the delay caused by it?
> >
> > >
> > > Add a check for PHY status and skip the reset steps when the PHY is
> > > already active. In this case, only enable the required resources during
> > > power-on. This works alongside the existing logic that skips the init
> > > sequence.
> >
> > Can we end up in a state where the bootloader has mis-setup the link? Or
> > the link going bad because of any glitch during the bootup?
>
> Good question, can we add a module parameter to force a full reset of the PHY in case
> the bootloader is buggy ?
I'd suggest a simpler thing: if the reset was skipped, reset the PHY in
case of an error and retry. That's also one of the reasons why I asked
for skip_reset not to be the persistent value.
>
> >
> > >
> > > Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> > > ---
> > > drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 28 ++++++++++++++++++----------
> > > 1 file changed, 18 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> > > index 86b1b7e2da86a8675e3e48e90b782afb21cafd77..c93e613cf80b2612f0f225fa2125f78dbec1a33f 100644
> > > --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> > > +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> > > @@ -3153,6 +3153,7 @@ struct qmp_pcie {
> > > const struct qmp_phy_cfg *cfg;
> > > bool tcsr_4ln_config;
> > > bool skip_init;
> > > + bool skip_reset;
> > > void __iomem *serdes;
> > > void __iomem *pcs;
> > > @@ -4537,6 +4538,9 @@ static int qmp_pcie_init(struct phy *phy)
> > > qphy_checkbits(pcs, cfg->regs[QPHY_START_CTRL], SERDES_START | PCS_START) &&
> > > qphy_checkbits(pcs, cfg->regs[QPHY_PCS_POWER_DOWN_CONTROL], cfg->pwrdn_ctrl);
> > > + qmp->skip_reset = qmp->skip_init && !qphy_checkbits(pcs, cfg->regs[QPHY_PCS_STATUS],
> >
> > It is definitely not a long-term state, there is no need to store it in
> > qmp_pcie struct.
> >
> > > + cfg->phy_status);
> > > +
> > > if (!qmp->skip_init && !cfg->tbls.serdes_num) {
> > > dev_err(qmp->dev, "Init sequence not available\n");
> > > return -ENODATA;
> > > @@ -4560,13 +4564,15 @@ static int qmp_pcie_init(struct phy *phy)
> > > }
> > > }
> > > - ret = reset_control_assert(qmp->nocsr_reset);
> > > - if (ret) {
> > > - dev_err(qmp->dev, "no-csr reset assert failed\n");
> > > - goto err_assert_reset;
> > > - }
> > > + if (!qmp->skip_reset) {
> > > + ret = reset_control_assert(qmp->nocsr_reset);
> > > + if (ret) {
> > > + dev_err(qmp->dev, "no-csr reset assert failed\n");
> > > + goto err_assert_reset;
> > > + }
> > > - usleep_range(200, 300);
> > > + usleep_range(200, 300);
> > > + }
> > > if (!qmp->skip_init) {
> > > ret = reset_control_bulk_deassert(cfg->num_resets, qmp->resets);
> > > @@ -4641,10 +4647,12 @@ static int qmp_pcie_power_on(struct phy *phy)
> > > if (ret)
> > > return ret;
> > > - ret = reset_control_deassert(qmp->nocsr_reset);
> > > - if (ret) {
> > > - dev_err(qmp->dev, "no-csr reset deassert failed\n");
> > > - goto err_disable_pipe_clk;
> > > + if (!qmp->skip_reset) {
> > > + ret = reset_control_deassert(qmp->nocsr_reset);
> > > + if (ret) {
> > > + dev_err(qmp->dev, "no-csr reset deassert failed\n");
> > > + goto err_disable_pipe_clk;
> > > + }
> > > }
> > > if (qmp->skip_init)
> > >
> > > --
> > > 2.34.1
> > >
> >
>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 1/3] arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports
From: Dmitry Baryshkov @ 2026-01-09 13:13 UTC (permalink / raw)
To: Ziyue Zhang
Cc: andersson, konradybcio, robh, krzk+dt, conor+dt, jingoohan1, mani,
lpieralisi, kwilczynski, bhelgaas, johan+linaro, vkoul, kishon,
neil.armstrong, abel.vesa, kw, linux-arm-msm, devicetree,
linux-kernel, linux-pci, linux-phy, qiang.yu, quic_krichai,
quic_vbadigan
In-Reply-To: <20260109104504.3147745-2-ziyue.zhang@oss.qualcomm.com>
On Fri, Jan 09, 2026 at 06:45:02PM +0800, Ziyue Zhang wrote:
> Since describing the PCIe PHY directly under the RC node is now
> deprecated, move the references to the respective PCIe port nodes,
> creating them where necessary.Also add port nodes for PCIe5 and PCIe6a
> with proper PHY references.
>
> And also move the PCIe PERST and wake GPIOs from the controller nodes to
> the corresponding PCIe port nodes on Hamoa-based platforms:
>
> - x1e001de-devkit
> - x1e78100-lenovo-thinkpad-t14s
> - x1e80100-asus-vivobook-s15
> - x1e80100-asus-zenbook-a14
> - x1e80100-dell-xps13-9345
> - x1e80100-lenovo-yoga-slim7x
> - x1e80100-microsoft-romulus
> - x1e80100-qcp
>
> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/hamoa.dtsi | 42 +++++++++++++------
> arch/arm64/boot/dts/qcom/x1e001de-devkit.dts | 24 +++++++----
> .../qcom/x1e78100-lenovo-thinkpad-t14s.dtsi | 24 +++++++----
> .../dts/qcom/x1e80100-asus-vivobook-s15.dts | 14 ++++---
> .../dts/qcom/x1e80100-asus-zenbook-a14.dts | 3 ++
> .../dts/qcom/x1e80100-dell-xps13-9345.dts | 14 ++++---
> .../dts/qcom/x1e80100-lenovo-yoga-slim7x.dts | 8 ++--
> .../dts/qcom/x1e80100-microsoft-romulus.dtsi | 19 ++++++---
> arch/arm64/boot/dts/qcom/x1e80100-qcp.dts | 21 ++++++----
> 9 files changed, 108 insertions(+), 61 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/5] phy: qcom: qmp-pcie: Skip PHY reset if already up
From: Neil Armstrong @ 2026-01-09 13:10 UTC (permalink / raw)
To: Dmitry Baryshkov, Krishna Chaitanya Chundru
Cc: Vinod Koul, Philipp Zabel, Jingoo Han, Manivannan Sadhasivam,
Lorenzo Pieralisi, Krzysztof Wilczyński, Rob Herring,
Bjorn Helgaas, linux-arm-msm, linux-phy, linux-kernel, linux-pci
In-Reply-To: <nmle3y6nb4kjcwstzqxkqzaokeyjoegg6lxtmji57kxwh5snxa@p76v6dr7rgsg>
On 1/9/26 14:08, Dmitry Baryshkov wrote:
> On Fri, Jan 09, 2026 at 12:51:06PM +0530, Krishna Chaitanya Chundru wrote:
>> If the bootloader has already powered up the PCIe PHY, doing a full
>> reset and waiting for it to come up again slows down boot time.
>
> How big is the delay caused by it?
>
>>
>> Add a check for PHY status and skip the reset steps when the PHY is
>> already active. In this case, only enable the required resources during
>> power-on. This works alongside the existing logic that skips the init
>> sequence.
>
> Can we end up in a state where the bootloader has mis-setup the link? Or
> the link going bad because of any glitch during the bootup?
Good question, can we add a module parameter to force a full reset of the PHY in case
the bootloader is buggy ?
>
>>
>> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
>> ---
>> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 28 ++++++++++++++++++----------
>> 1 file changed, 18 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
>> index 86b1b7e2da86a8675e3e48e90b782afb21cafd77..c93e613cf80b2612f0f225fa2125f78dbec1a33f 100644
>> --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
>> @@ -3153,6 +3153,7 @@ struct qmp_pcie {
>> const struct qmp_phy_cfg *cfg;
>> bool tcsr_4ln_config;
>> bool skip_init;
>> + bool skip_reset;
>>
>> void __iomem *serdes;
>> void __iomem *pcs;
>> @@ -4537,6 +4538,9 @@ static int qmp_pcie_init(struct phy *phy)
>> qphy_checkbits(pcs, cfg->regs[QPHY_START_CTRL], SERDES_START | PCS_START) &&
>> qphy_checkbits(pcs, cfg->regs[QPHY_PCS_POWER_DOWN_CONTROL], cfg->pwrdn_ctrl);
>>
>> + qmp->skip_reset = qmp->skip_init && !qphy_checkbits(pcs, cfg->regs[QPHY_PCS_STATUS],
>
> It is definitely not a long-term state, there is no need to store it in
> qmp_pcie struct.
>
>> + cfg->phy_status);
>> +
>> if (!qmp->skip_init && !cfg->tbls.serdes_num) {
>> dev_err(qmp->dev, "Init sequence not available\n");
>> return -ENODATA;
>> @@ -4560,13 +4564,15 @@ static int qmp_pcie_init(struct phy *phy)
>> }
>> }
>>
>> - ret = reset_control_assert(qmp->nocsr_reset);
>> - if (ret) {
>> - dev_err(qmp->dev, "no-csr reset assert failed\n");
>> - goto err_assert_reset;
>> - }
>> + if (!qmp->skip_reset) {
>> + ret = reset_control_assert(qmp->nocsr_reset);
>> + if (ret) {
>> + dev_err(qmp->dev, "no-csr reset assert failed\n");
>> + goto err_assert_reset;
>> + }
>>
>> - usleep_range(200, 300);
>> + usleep_range(200, 300);
>> + }
>>
>> if (!qmp->skip_init) {
>> ret = reset_control_bulk_deassert(cfg->num_resets, qmp->resets);
>> @@ -4641,10 +4647,12 @@ static int qmp_pcie_power_on(struct phy *phy)
>> if (ret)
>> return ret;
>>
>> - ret = reset_control_deassert(qmp->nocsr_reset);
>> - if (ret) {
>> - dev_err(qmp->dev, "no-csr reset deassert failed\n");
>> - goto err_disable_pipe_clk;
>> + if (!qmp->skip_reset) {
>> + ret = reset_control_deassert(qmp->nocsr_reset);
>> + if (ret) {
>> + dev_err(qmp->dev, "no-csr reset deassert failed\n");
>> + goto err_disable_pipe_clk;
>> + }
>> }
>>
>> if (qmp->skip_init)
>>
>> --
>> 2.34.1
>>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 5/5] PCI: qcom: enable Link retain logic for Hamoa
From: Dmitry Baryshkov @ 2026-01-09 13:09 UTC (permalink / raw)
To: Krishna Chaitanya Chundru
Cc: Vinod Koul, Neil Armstrong, Philipp Zabel, Jingoo Han,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
linux-arm-msm, linux-phy, linux-kernel, linux-pci
In-Reply-To: <20260109-link_retain-v1-5-7e6782230f4b@oss.qualcomm.com>
On Fri, Jan 09, 2026 at 12:51:10PM +0530, Krishna Chaitanya Chundru wrote:
> The Hamoa platform supports keeping the PCIe link active across
> bootloader and kernel handoff. To take advantage of this, introduce a
> specific configuration (cfg_x1e80100) with link_retain = true and
> update the device match table to use it.
Why are we enabling it only for this platform?
>
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index bdd5bdb462c5f6814c8311be96411173456b6b14..975671a0dd4757074600d5a0966e94220bb18d8c 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -1531,6 +1531,12 @@ static const struct qcom_pcie_cfg cfg_sc8280xp = {
> .no_l0s = true,
> };
>
> +static const struct qcom_pcie_cfg cfg_x1e80100 = {
> + .ops = &ops_1_21_0,
> + .no_l0s = true,
> + .link_retain = true,
> +};
> +
> static const struct qcom_pcie_cfg cfg_fw_managed = {
> .firmware_managed = true,
> };
> @@ -2168,7 +2174,7 @@ static const struct of_device_id qcom_pcie_match[] = {
> { .compatible = "qcom,pcie-sm8450-pcie0", .data = &cfg_1_9_0 },
> { .compatible = "qcom,pcie-sm8450-pcie1", .data = &cfg_1_9_0 },
> { .compatible = "qcom,pcie-sm8550", .data = &cfg_1_9_0 },
> - { .compatible = "qcom,pcie-x1e80100", .data = &cfg_sc8280xp },
> + { .compatible = "qcom,pcie-x1e80100", .data = &cfg_x1e80100 },
> { }
> };
>
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/5] phy: qcom: qmp-pcie: Skip PHY reset if already up
From: Dmitry Baryshkov @ 2026-01-09 13:08 UTC (permalink / raw)
To: Krishna Chaitanya Chundru
Cc: Vinod Koul, Neil Armstrong, Philipp Zabel, Jingoo Han,
Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
linux-arm-msm, linux-phy, linux-kernel, linux-pci
In-Reply-To: <20260109-link_retain-v1-1-7e6782230f4b@oss.qualcomm.com>
On Fri, Jan 09, 2026 at 12:51:06PM +0530, Krishna Chaitanya Chundru wrote:
> If the bootloader has already powered up the PCIe PHY, doing a full
> reset and waiting for it to come up again slows down boot time.
How big is the delay caused by it?
>
> Add a check for PHY status and skip the reset steps when the PHY is
> already active. In this case, only enable the required resources during
> power-on. This works alongside the existing logic that skips the init
> sequence.
Can we end up in a state where the bootloader has mis-setup the link? Or
the link going bad because of any glitch during the bootup?
>
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 28 ++++++++++++++++++----------
> 1 file changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> index 86b1b7e2da86a8675e3e48e90b782afb21cafd77..c93e613cf80b2612f0f225fa2125f78dbec1a33f 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> @@ -3153,6 +3153,7 @@ struct qmp_pcie {
> const struct qmp_phy_cfg *cfg;
> bool tcsr_4ln_config;
> bool skip_init;
> + bool skip_reset;
>
> void __iomem *serdes;
> void __iomem *pcs;
> @@ -4537,6 +4538,9 @@ static int qmp_pcie_init(struct phy *phy)
> qphy_checkbits(pcs, cfg->regs[QPHY_START_CTRL], SERDES_START | PCS_START) &&
> qphy_checkbits(pcs, cfg->regs[QPHY_PCS_POWER_DOWN_CONTROL], cfg->pwrdn_ctrl);
>
> + qmp->skip_reset = qmp->skip_init && !qphy_checkbits(pcs, cfg->regs[QPHY_PCS_STATUS],
It is definitely not a long-term state, there is no need to store it in
qmp_pcie struct.
> + cfg->phy_status);
> +
> if (!qmp->skip_init && !cfg->tbls.serdes_num) {
> dev_err(qmp->dev, "Init sequence not available\n");
> return -ENODATA;
> @@ -4560,13 +4564,15 @@ static int qmp_pcie_init(struct phy *phy)
> }
> }
>
> - ret = reset_control_assert(qmp->nocsr_reset);
> - if (ret) {
> - dev_err(qmp->dev, "no-csr reset assert failed\n");
> - goto err_assert_reset;
> - }
> + if (!qmp->skip_reset) {
> + ret = reset_control_assert(qmp->nocsr_reset);
> + if (ret) {
> + dev_err(qmp->dev, "no-csr reset assert failed\n");
> + goto err_assert_reset;
> + }
>
> - usleep_range(200, 300);
> + usleep_range(200, 300);
> + }
>
> if (!qmp->skip_init) {
> ret = reset_control_bulk_deassert(cfg->num_resets, qmp->resets);
> @@ -4641,10 +4647,12 @@ static int qmp_pcie_power_on(struct phy *phy)
> if (ret)
> return ret;
>
> - ret = reset_control_deassert(qmp->nocsr_reset);
> - if (ret) {
> - dev_err(qmp->dev, "no-csr reset deassert failed\n");
> - goto err_disable_pipe_clk;
> + if (!qmp->skip_reset) {
> + ret = reset_control_deassert(qmp->nocsr_reset);
> + if (ret) {
> + dev_err(qmp->dev, "no-csr reset deassert failed\n");
> + goto err_disable_pipe_clk;
> + }
> }
>
> if (qmp->skip_init)
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 4/4] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
From: Dmitry Baryshkov @ 2026-01-09 12:55 UTC (permalink / raw)
To: Loic Poulain; +Cc: vkoul, kishon, linux-arm-msm, linux-phy, neil.armstrong
In-Reply-To: <20260108154944.211886-5-loic.poulain@oss.qualcomm.com>
On Thu, Jan 08, 2026 at 04:49:44PM +0100, Loic Poulain wrote:
> Enabling runtime PM before attaching the hsphy instance as driver data
> can lead to a NULL pointer dereference in runtime PM callbacks that
> expect valid driver data. There is a small window where the suspend
> callback may run after PM runtime enabling and before runtime forbid.
>
> Attach the hsphy instance as driver data before enabling runtime PM to
> prevent NULL pointer dereference in runtime PM callbacks.
>
> Reorder pm_runtime_enable() and pm_runtime_forbid() to prevent a
> short window where an unnecessary runtime suspend can occur.
>
> Use the devres-managed version to ensure PM runtime is symmetrically
> disabled during driver removal for proper cleanup.
>
> Fixes: 0d75f508a9d5 ("phy: qcom-snps: Add runtime suspend and resume handlers")
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 3/4] phy: qcom: qmp-usb-legacy: Fix possible NULL-deref on early runtime suspend
From: Dmitry Baryshkov @ 2026-01-09 12:55 UTC (permalink / raw)
To: Loic Poulain; +Cc: vkoul, kishon, linux-arm-msm, linux-phy, neil.armstrong
In-Reply-To: <20260108154944.211886-4-loic.poulain@oss.qualcomm.com>
On Thu, Jan 08, 2026 at 04:49:43PM +0100, Loic Poulain wrote:
> There is a small window where the runtime suspend callback may run
> after pm_runtime_enable() and before pm_runtime_forbid(). In this
> case, a crash occurs because runtime suspend/resume dereferences
> qmp->phy pointer, which is not yet initialized:
> `if (!qmp->phy->init_count) {`
>
> Similarly to other qcom phy drivers, introduce a qmp->phy_initialized
> variable that can be used to avoid relying on the possibly uninitialized
> phy pointer.
I think these two sets of changes should be split into two different
commits.
>
> Reorder pm_runtime_enable() and pm_runtime_forbid() to prevent the window
> where an unnecessary runtime suspend can occur.
>
> Fixes: e464a3180a43 ("phy: qcom-qmp-usb: split off the legacy USB+dp_com support")
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> .../phy/qualcomm/phy-qcom-qmp-usb-legacy.c | 21 ++++++++++++-------
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/4] phy: qcom: qmp-usbc: Fix possible NULL-deref on early runtime suspend
From: Dmitry Baryshkov @ 2026-01-09 12:50 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Loic Poulain, vkoul, kishon, linux-arm-msm, linux-phy,
neil.armstrong
In-Reply-To: <c6017022-c96e-4095-b85d-88784a44c13a@oss.qualcomm.com>
On Fri, Jan 09, 2026 at 12:26:58PM +0100, Konrad Dybcio wrote:
> On 1/8/26 4:49 PM, Loic Poulain wrote:
> > There is a small window where the runtime suspend callback may run
> > after pm_runtime_enable() and before pm_runtime_forbid(). In this
> > case, a crash occurs because runtime suspend/resume dereferences
> > qmp->phy pointer, which is not yet initialized:
> > `if (!qmp->phy->init_count) {`
> >
> > Use qmp->usb_init_count instead of qmp->phy->init_count to avoid
> > depending on the possibly uninitialized phy pointer.
> >
> > Also reorder pm_runtime_enable() and pm_runtime_forbid() to prevent
> > the window where an unnecessary runtime suspend can occur.
> >
> > Fixes: 19281571a4d5 ("phy: qcom: qmp-usb: split USB-C PHY driver")
> > Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> > ---
> > drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 14 +++++++-------
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
> > index 5e7fcb26744a..05717ca85c5b 100644
> > --- a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
> > +++ b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
> > @@ -690,7 +690,7 @@ static int __maybe_unused qmp_usbc_runtime_suspend(struct device *dev)
> >
> > dev_vdbg(dev, "Suspending QMP phy, mode:%d\n", qmp->mode);
> >
> > - if (!qmp->phy->init_count) {
> > + if (!qmp->usb_init_count) {
> > dev_vdbg(dev, "PHY not initialized, bailing out\n");
>
> FWIW this effectively says "if in DP mode, the PHY can't runtime suspend"
> which I'm not sure is what should happen.
>
> In USB3 mode, there's definitely a register in PCS_USB to put it into
> "autonomous mode", where I believe all the hw does it listen for link
> sleep (U3 in USB3 spec) exit requests
>
> In DP, I suppose we can't just yank the power until the controller
> decides to suspend the link, at which point we just power off the PHY..
> would that be right, Dmitry?
I think so.
>
> Konrad
>
> --
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/4] phy: qcom: qmp-combo: Prevent unnecessary PM runtime suspend at boot
From: Dmitry Baryshkov @ 2026-01-09 12:49 UTC (permalink / raw)
To: Loic Poulain; +Cc: vkoul, kishon, linux-arm-msm, linux-phy, neil.armstrong
In-Reply-To: <20260108154944.211886-2-loic.poulain@oss.qualcomm.com>
On Thu, Jan 08, 2026 at 04:49:41PM +0100, Loic Poulain wrote:
> There is a small window where the device can suspend after
> pm_runtime_enable() and before pm_runtime_forbid(), causing an
> unnecessary suspend/resume cycle while the PHY is not yet registered.
>
> Move pm_runtime_forbid() before pm_runtime_enable() to eliminate
> this race.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: mmc: arasan,sdhci: Add Axiado AX3000 SoC
From: Rob Herring (Arm) @ 2026-01-09 11:29 UTC (permalink / raw)
To: Tzu-Hao Wei
Cc: SriNavmani A, Vinod Koul, Adrian Hunter, openbmc, Neil Armstrong,
devicetree, Ulf Hansson, Krzysztof Kozlowski, Prasad Bolisetty,
Conor Dooley, linux-arm-kernel, linux-phy, linux-kernel,
Michal Simek, linux-mmc
In-Reply-To: <20260109-axiado-ax3000-add-emmc-host-driver-support-v2-1-934f1a61f7c0@axiado.com>
On Fri, 09 Jan 2026 17:46:25 +0800, Tzu-Hao Wei wrote:
> From: SriNavmani A <srinavmani@axiado.com>
>
> Add compatible strings for Axiado AX3000 SoC eMMC controller which
> is based on Arasan eMMC controller.
>
> Signed-off-by: SriNavmani A <srinavmani@axiado.com>
> Signed-off-by: Tzu-Hao Wei <twei@axiado.com>
> ---
> Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/axiado,ax3000-emmc-phy.yaml: properties:compatible:const: ['axiado,ax3000-emmc-phy'] is not of type 'integer', 'string'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/axiado,ax3000-emmc-phy.yaml: properties:compatible:const: ['axiado,ax3000-emmc-phy'] is not of type 'string'
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml
Documentation/devicetree/bindings/phy/axiado,ax3000-emmc-phy.example.dtb: /example-0/phy@80801c00: failed to match any schema with compatible: ['axiado,ax3000-emmc-phy']
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260109-axiado-ax3000-add-emmc-host-driver-support-v2-1-934f1a61f7c0@axiado.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/4] phy: qcom: qmp-usbc: Fix possible NULL-deref on early runtime suspend
From: Konrad Dybcio @ 2026-01-09 11:26 UTC (permalink / raw)
To: Loic Poulain, vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong
In-Reply-To: <20260108154944.211886-3-loic.poulain@oss.qualcomm.com>
On 1/8/26 4:49 PM, Loic Poulain wrote:
> There is a small window where the runtime suspend callback may run
> after pm_runtime_enable() and before pm_runtime_forbid(). In this
> case, a crash occurs because runtime suspend/resume dereferences
> qmp->phy pointer, which is not yet initialized:
> `if (!qmp->phy->init_count) {`
>
> Use qmp->usb_init_count instead of qmp->phy->init_count to avoid
> depending on the possibly uninitialized phy pointer.
>
> Also reorder pm_runtime_enable() and pm_runtime_forbid() to prevent
> the window where an unnecessary runtime suspend can occur.
>
> Fixes: 19281571a4d5 ("phy: qcom: qmp-usb: split USB-C PHY driver")
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
> index 5e7fcb26744a..05717ca85c5b 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-usbc.c
> @@ -690,7 +690,7 @@ static int __maybe_unused qmp_usbc_runtime_suspend(struct device *dev)
>
> dev_vdbg(dev, "Suspending QMP phy, mode:%d\n", qmp->mode);
>
> - if (!qmp->phy->init_count) {
> + if (!qmp->usb_init_count) {
> dev_vdbg(dev, "PHY not initialized, bailing out\n");
FWIW this effectively says "if in DP mode, the PHY can't runtime suspend"
which I'm not sure is what should happen.
In USB3 mode, there's definitely a register in PCS_USB to put it into
"autonomous mode", where I believe all the hw does it listen for link
sleep (U3 in USB3 spec) exit requests
In DP, I suppose we can't just yank the power until the controller
decides to suspend the link, at which point we just power off the PHY..
would that be right, Dmitry?
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 3/5] PCI: qcom: Keep PERST# GPIO state as-is during probe
From: Konrad Dybcio @ 2026-01-09 11:14 UTC (permalink / raw)
To: Krishna Chaitanya Chundru, Vinod Koul, Neil Armstrong,
Philipp Zabel, Jingoo Han, Manivannan Sadhasivam,
Lorenzo Pieralisi, Krzysztof Wilczyński, Rob Herring,
Bjorn Helgaas
Cc: linux-arm-msm, linux-phy, linux-kernel, linux-pci
In-Reply-To: <20260109-link_retain-v1-3-7e6782230f4b@oss.qualcomm.com>
On 1/9/26 8:21 AM, Krishna Chaitanya Chundru wrote:
> The PERST# signal is used to reset PCIe devices. Currently, the driver
> requests the GPIO with GPIOD_OUT_HIGH, which forces the line high
> during probe. This can unintentionally assert reset early, breaking
^ de-assert, probably?
Konrad
> link retention or causing unexpected device behavior.
>
> Change the request to use GPIOD_ASIS so the driver preserves the
> existing state configured by the bootloader or firmware. This allows
> platforms that manage PERST# externally to maintain proper reset
> sequencing.
>
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index 7b92e7a1c0d9364a9cefe1450818f9cbfc7fd3ac..9342f9c75f1c3017b55614069a7aa821a6fb8da7 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -1711,7 +1711,7 @@ static int qcom_pcie_parse_port(struct qcom_pcie *pcie, struct device_node *node
> int ret;
>
> reset = devm_fwnode_gpiod_get(dev, of_fwnode_handle(node),
> - "reset", GPIOD_OUT_HIGH, "PERST#");
> + "reset", GPIOD_ASIS, "PERST#");
> if (IS_ERR(reset))
> return PTR_ERR(reset);
>
> @@ -1772,7 +1772,7 @@ static int qcom_pcie_parse_legacy_binding(struct qcom_pcie *pcie)
> if (IS_ERR(phy))
> return PTR_ERR(phy);
>
> - reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_HIGH);
> + reset = devm_gpiod_get_optional(dev, "perst", GPIOD_ASIS);
> if (IS_ERR(reset))
> return PTR_ERR(reset);
>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 8/9] drm/rockchip: Drop ROCKCHIP_IOMMU depend for DRM_ROCKCHIP
From: Heiko Stübner @ 2026-01-09 10:51 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sandy Huang, Andy Yan,
Vinod Koul, Kishon Vijay Abraham I, Chaoyi Chen, Chaoyi Chen
Cc: dri-devel, devicetree, linux-kernel, linux-arm-kernel,
linux-rockchip, linux-phy
In-Reply-To: <4e01f121-1912-4897-98e8-cb543a501707@rock-chips.com>
Hi,
Am Freitag, 9. Januar 2026, 02:26:00 Mitteleuropäische Normalzeit schrieb Chaoyi Chen:
> On 1/9/2026 3:03 AM, Heiko Stuebner wrote:
> > Am Donnerstag, 6. November 2025, 03:06:31 Mitteleuropäische Normalzeit schrieb Chaoyi Chen:
> >> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> >>
> >> On the RK3506 platform, there is no iommu hardware. And even on
> >> platform that have iommu hardware, it should be possible to use
> >> VOP without enabling iommu. In this case, a contiguous memory
> >> space like CMA should be used.
> >>
> >> So this patch removes the dependency on ROCKCHIP_IOMMU.
> >>
> >> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> >> ---
> >> drivers/gpu/drm/rockchip/Kconfig | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
> >> index b7b025814e72..a056d419190c 100644
> >> --- a/drivers/gpu/drm/rockchip/Kconfig
> >> +++ b/drivers/gpu/drm/rockchip/Kconfig
> >> @@ -1,7 +1,8 @@
> >> # SPDX-License-Identifier: GPL-2.0-only
> >> config DRM_ROCKCHIP
> >> tristate "DRM Support for Rockchip"
> >> - depends on DRM && ROCKCHIP_IOMMU
> >> + depends on DRM
> >> + depends on ROCKCHIP_IOMMU || !ROCKCHIP_IOMMU
> >
> > I don't really understand this yes+no line :-)
> >
> > Can't you just
> > - drop the dependency altogether
> > or
> > - do a depends on ROCKCHIP_IOMMU if ARM64
> >
> >
>
> This trick is called optional-dependencies [0]. In addition to the
> familiar depends on ROCKCHIP_IOMMU part, the newly added !ROCKCHIP_IOMMU
> ensures that DRM_ROCKCHIP can still be built even when ROCKCHIP_IOMMU
> is not build.
>
> [0]: https://docs.kernel.org/kbuild/kconfig-language.html#optional-dependencies
thanks a lot for pointing me to this nifty feature :-)
Heiko
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: (subset) [PATCH 0/9] drm/rockchip: Introduce Rockchip RK3506 VOP
From: Heiko Stuebner @ 2026-01-09 10:51 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sandy Huang, Andy Yan,
Vinod Koul, Kishon Vijay Abraham I, Chaoyi Chen
Cc: Heiko Stuebner, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip, linux-phy, Chaoyi Chen
In-Reply-To: <20251106020632.92-1-kernel@airkyi.com>
On Thu, 06 Nov 2025 10:06:23 +0800, Chaoyi Chen wrote:
> The VOP on rk3506:
> - Support 2 lane MIPI DSI interface, 1.5Gbps/lane.
> - Support RGB interface.
> - Max output resolution is 1280x1280@60fps.
> - WIN1 layer support RGB888/ARGB8888/RGB565.
> - Support Gamma LUT.
>
> [...]
Applied, thanks!
[8/9] drm/rockchip: Drop ROCKCHIP_IOMMU depend for DRM_ROCKCHIP
commit: 0244539f9a4f3b564604dfe4d639f61cecec381a
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: qcom: edp: Fix NULL pointer dereference for phy v6 (x1e80100)
From: Konrad Dybcio @ 2026-01-09 10:49 UTC (permalink / raw)
To: Val Packett, Vinod Koul, Neil Armstrong, Abel Vesa,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <20260109045214.5983-1-val@packett.cool>
On 1/9/26 5:50 AM, Val Packett wrote:
> For Glymur SoC support, the com_clk_fwd_cfg callback was added, and a
> stub implementation was added for the v4 of the hardware. However it
> was omitted for the v6, causing a NULL pointer dereference oops on
> Hamoa/Purwa (X1E/X1P) SoC devices. Fix by adding the appropriate stub.
>
> Fixes: add66a6673bc ("phy: qcom: edp: Add Glymur platform support")
> Signed-off-by: Val Packett <val@packett.cool>
> ---
> drivers/phy/qualcomm/phy-qcom-edp.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
> index 13feab99feec..a17492db21d8 100644
> --- a/drivers/phy/qualcomm/phy-qcom-edp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-edp.c
> @@ -613,6 +613,11 @@ static int qcom_edp_phy_com_resetsm_cntrl_v6(const struct qcom_edp *edp)
> val, val & BIT(0), 500, 10000);
> }
>
> +static int qcom_edp_com_clk_fwd_cfg_v6(const struct qcom_edp *edp)
> +{
> + return 0;
> +}
> +
> static int qcom_edp_com_bias_en_clkbuflr_v6(const struct qcom_edp *edp)
> {
> /* Turn on BIAS current for PHY/PLL */
> @@ -758,6 +763,7 @@ static const struct phy_ver_ops qcom_edp_phy_ops_v6 = {
> .com_power_on = qcom_edp_phy_power_on_v6,
> .com_resetsm_cntrl = qcom_edp_phy_com_resetsm_cntrl_v6,
> .com_bias_en_clkbuflr = qcom_edp_com_bias_en_clkbuflr_v6,
> + .com_clk_fwd_cfg = qcom_edp_com_clk_fwd_cfg_v6,
Let's just point it to the existing qcom_edp_com_clk_fwd_cfg_v4
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v4 1/3] arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports
From: Ziyue Zhang @ 2026-01-09 10:45 UTC (permalink / raw)
To: andersson, konradybcio, robh, krzk+dt, conor+dt, ziyue.zhang,
jingoohan1, mani, lpieralisi, kwilczynski, bhelgaas, johan+linaro,
vkoul, kishon, neil.armstrong, abel.vesa, kw
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pci, linux-phy,
qiang.yu, quic_krichai, quic_vbadigan
In-Reply-To: <20260109104504.3147745-1-ziyue.zhang@oss.qualcomm.com>
Since describing the PCIe PHY directly under the RC node is now
deprecated, move the references to the respective PCIe port nodes,
creating them where necessary.Also add port nodes for PCIe5 and PCIe6a
with proper PHY references.
And also move the PCIe PERST and wake GPIOs from the controller nodes to
the corresponding PCIe port nodes on Hamoa-based platforms:
- x1e001de-devkit
- x1e78100-lenovo-thinkpad-t14s
- x1e80100-asus-vivobook-s15
- x1e80100-asus-zenbook-a14
- x1e80100-dell-xps13-9345
- x1e80100-lenovo-yoga-slim7x
- x1e80100-microsoft-romulus
- x1e80100-qcp
Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/hamoa.dtsi | 42 +++++++++++++------
arch/arm64/boot/dts/qcom/x1e001de-devkit.dts | 24 +++++++----
.../qcom/x1e78100-lenovo-thinkpad-t14s.dtsi | 24 +++++++----
.../dts/qcom/x1e80100-asus-vivobook-s15.dts | 14 ++++---
.../dts/qcom/x1e80100-asus-zenbook-a14.dts | 3 ++
.../dts/qcom/x1e80100-dell-xps13-9345.dts | 14 ++++---
.../dts/qcom/x1e80100-lenovo-yoga-slim7x.dts | 8 ++--
.../dts/qcom/x1e80100-microsoft-romulus.dtsi | 19 ++++++---
arch/arm64/boot/dts/qcom/x1e80100-qcp.dts | 21 ++++++----
9 files changed, 108 insertions(+), 61 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index a559f6340af9..f464ff3b89cb 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -3261,9 +3261,6 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
power-domains = <&gcc GCC_PCIE_3_GDSC>;
- phys = <&pcie3_phy>;
- phy-names = "pciephy";
-
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>;
@@ -3404,12 +3401,14 @@ opp-128000000-4 {
};
};
- pcie3_port: pcie@0 {
+ pcie3_port0: pcie@0 {
device_type = "pci";
compatible = "pciclass,0604";
reg = <0x0 0x0 0x0 0x0 0x0>;
bus-range = <0x01 0xff>;
+ phys = <&pcie3_phy>;
+
#address-cells = <3>;
#size-cells = <2>;
ranges;
@@ -3538,13 +3537,22 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
power-domains = <&gcc GCC_PCIE_6A_GDSC>;
required-opps = <&rpmhpd_opp_nom>;
- phys = <&pcie6a_phy>;
- phy-names = "pciephy";
-
eq-presets-8gts = /bits/ 16 <0x5555 0x5555 0x5555 0x5555>;
eq-presets-16gts = /bits/ 8 <0x55 0x55 0x55 0x55>;
status = "disabled";
+
+ pcie6a_port0: pcie@0 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ phys = <&pcie6a_phy>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcie6a_phy: phy@1bfc000 {
@@ -3670,12 +3678,21 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
power-domains = <&gcc GCC_PCIE_5_GDSC>;
required-opps = <&rpmhpd_opp_nom>;
- phys = <&pcie5_phy>;
- phy-names = "pciephy";
-
eq-presets-8gts = /bits/ 16 <0x5555 0x5555>;
status = "disabled";
+
+ pcie5_port0: pcie@0 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ phys = <&pcie5_phy>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcie5_phy: phy@1c06000 {
@@ -3800,9 +3817,6 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
power-domains = <&gcc GCC_PCIE_4_GDSC>;
required-opps = <&rpmhpd_opp_nom>;
- phys = <&pcie4_phy>;
- phy-names = "pciephy";
-
eq-presets-8gts = /bits/ 16 <0x5555 0x5555>;
status = "disabled";
@@ -3812,6 +3826,8 @@ pcie4_port0: pcie@0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
bus-range = <0x01 0xff>;
+ phys = <&pcie4_phy>;
+
#address-cells = <3>;
#size-cells = <2>;
ranges;
diff --git a/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
index a9643cd746d5..d5a60671a383 100644
--- a/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
+++ b/arch/arm64/boot/dts/qcom/x1e001de-devkit.dts
@@ -1003,9 +1003,6 @@ &mdss_dp2_out {
};
&pcie4 {
- perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
pinctrl-0 = <&pcie4_default>;
pinctrl-names = "default";
@@ -1019,10 +1016,12 @@ &pcie4_phy {
status = "okay";
};
-&pcie5 {
- perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
+&pcie4_port0 {
+ reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+};
+&pcie5 {
vddpe-3v3-supply = <&vreg_wwan>;
pinctrl-0 = <&pcie5_default>;
@@ -1038,10 +1037,12 @@ &pcie5_phy {
status = "okay";
};
-&pcie6a {
- perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+&pcie5_port0 {
+ reset-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
+};
+&pcie6a {
vddpe-3v3-supply = <&vreg_nvme>;
pinctrl-names = "default";
@@ -1057,6 +1058,11 @@ &pcie6a_phy {
status = "okay";
};
+&pcie6a_port0 {
+ reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
&pm8550_gpios {
rtmr0_default: rtmr0-reset-n-active-state {
pins = "gpio10";
diff --git a/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi b/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi
index 7aee9a20c6df..b45e377a22c6 100644
--- a/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e78100-lenovo-thinkpad-t14s.dtsi
@@ -1113,9 +1113,6 @@ &mdss_dp3_phy {
};
&pcie4 {
- perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
pinctrl-0 = <&pcie4_default>;
pinctrl-names = "default";
@@ -1129,10 +1126,12 @@ &pcie4_phy {
status = "okay";
};
-&pcie5 {
- perst-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
+&pcie4_port0 {
+ reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+};
+&pcie5 {
vddpe-3v3-supply = <&vreg_wwan>;
pinctrl-0 = <&pcie5_default>;
@@ -1148,10 +1147,12 @@ &pcie5_phy {
status = "okay";
};
-&pcie6a {
- perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+&pcie5_port0 {
+ reset-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
+};
+&pcie6a {
vddpe-3v3-supply = <&vreg_nvme>;
pinctrl-0 = <&pcie6a_default>;
@@ -1167,6 +1168,11 @@ &pcie6a_phy {
status = "okay";
};
+&pcie6a_port0 {
+ reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
&pm8550_gpios {
rtmr0_default: rtmr0-reset-n-active-state {
pins = "gpio10";
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-asus-vivobook-s15.dts b/arch/arm64/boot/dts/qcom/x1e80100-asus-vivobook-s15.dts
index 34467b84a2fa..17269eb0638a 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-asus-vivobook-s15.dts
+++ b/arch/arm64/boot/dts/qcom/x1e80100-asus-vivobook-s15.dts
@@ -907,9 +907,6 @@ &mdss_dp3_phy {
};
&pcie4 {
- perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
pinctrl-0 = <&pcie4_default>;
pinctrl-names = "default";
@@ -924,6 +921,9 @@ &pcie4_phy {
};
&pcie4_port0 {
+ reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+
wifi@0 {
compatible = "pci17cb,1107";
reg = <0x10000 0x0 0x0 0x0 0x0>;
@@ -941,9 +941,6 @@ wifi@0 {
};
&pcie6a {
- perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
-
vddpe-3v3-supply = <&vreg_nvme>;
pinctrl-0 = <&pcie6a_default>;
@@ -959,6 +956,11 @@ &pcie6a_phy {
status = "okay";
};
+&pcie6a_port0 {
+ reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
&pm8550_gpios {
rtmr0_default: rtmr0-reset-n-active-state {
pins = "gpio10";
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-asus-zenbook-a14.dts b/arch/arm64/boot/dts/qcom/x1e80100-asus-zenbook-a14.dts
index 0408ade7150f..b42318c75ed2 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-asus-zenbook-a14.dts
+++ b/arch/arm64/boot/dts/qcom/x1e80100-asus-zenbook-a14.dts
@@ -82,6 +82,9 @@ &gpu_zap_shader {
};
&pcie4_port0 {
+ reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+
wifi@0 {
compatible = "pci17cb,1107";
reg = <0x10000 0x0 0x0 0x0 0x0>;
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts b/arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts
index 2f533e56c8c8..4c95b1af2c64 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts
+++ b/arch/arm64/boot/dts/qcom/x1e80100-dell-xps13-9345.dts
@@ -941,9 +941,6 @@ &mdss_dp3_phy {
};
&pcie4 {
- perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
pinctrl-0 = <&pcie4_default>;
pinctrl-names = "default";
@@ -958,6 +955,9 @@ &pcie4_phy {
};
&pcie4_port0 {
+ reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+
wifi@0 {
compatible = "pci17cb,1107";
reg = <0x10000 0x0 0x0 0x0 0x0>;
@@ -975,9 +975,6 @@ wifi@0 {
};
&pcie6a {
- perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
-
vddpe-3v3-supply = <&vreg_nvme>;
pinctrl-0 = <&pcie6a_default>;
@@ -993,6 +990,11 @@ &pcie6a_phy {
status = "okay";
};
+&pcie6a_port0 {
+ reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
&pm8550_gpios {
rtmr0_default: rtmr0-reset-n-active-state {
pins = "gpio10";
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts b/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
index 4c31d14a07bc..d6472e5a3f9f 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
+++ b/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts
@@ -1160,9 +1160,6 @@ wifi@0 {
};
&pcie6a {
- perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
-
vddpe-3v3-supply = <&vreg_nvme>;
pinctrl-0 = <&pcie6a_default>;
@@ -1178,6 +1175,11 @@ &pcie6a_phy {
status = "okay";
};
+&pcie6a_port0 {
+ reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
&pm8550_gpios {
rtmr0_default: rtmr0-reset-n-active-state {
pins = "gpio10";
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi b/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
index 7e1e808ea983..37539a09b76e 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
@@ -1094,9 +1094,6 @@ &mdss_dp3_phy {
};
&pcie3 {
- perst-gpios = <&tlmm 143 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 145 GPIO_ACTIVE_HIGH>;
-
pinctrl-0 = <&pcie3_default>;
pinctrl-names = "default";
@@ -1112,6 +1109,11 @@ &pcie3_phy {
status = "okay";
};
+&pcie3_port0 {
+ reset-gpios = <&tlmm 143 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 145 GPIO_ACTIVE_LOW>;
+};
+
&pcie4 {
status = "okay";
};
@@ -1124,6 +1126,9 @@ &pcie4_phy {
};
&pcie4_port0 {
+ reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+
wifi@0 {
compatible = "pci17cb,1107";
reg = <0x10000 0x0 0x0 0x0 0x0>;
@@ -1141,9 +1146,6 @@ wifi@0 {
};
&pcie6a {
- perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
-
vddpe-3v3-supply = <&vreg_nvme>;
pinctrl-0 = <&pcie6a_default>;
@@ -1159,6 +1161,11 @@ &pcie6a_phy {
status = "okay";
};
+&pcie6a_port0 {
+ reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
&pm8550_gpios {
rtmr0_default: rtmr0-reset-n-active-state {
pins = "gpio10";
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts b/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts
index b742aabd9c04..1d402ef86512 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts
+++ b/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts
@@ -979,8 +979,6 @@ pm_sde7_main_3p3_en: pcie-main-3p3-default-state {
&pcie3 {
pinctrl-names = "default";
pinctrl-0 = <&pcie3_default>;
- perst-gpios = <&tlmm 143 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 145 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -992,16 +990,16 @@ &pcie3_phy {
status = "okay";
};
-&pcie3_port {
+&pcie3_port0 {
vpcie12v-supply = <&vreg_pcie_12v>;
vpcie3v3-supply = <&vreg_pcie_3v3>;
vpcie3v3aux-supply = <&vreg_pcie_3v3_aux>;
+
+ reset-gpios = <&tlmm 143 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 145 GPIO_ACTIVE_LOW>;
};
&pcie4 {
- perst-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
-
pinctrl-0 = <&pcie4_default>;
pinctrl-names = "default";
@@ -1016,6 +1014,9 @@ &pcie4_phy {
};
&pcie4_port0 {
+ reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+
wifi@0 {
compatible = "pci17cb,1107";
reg = <0x10000 0x0 0x0 0x0 0x0>;
@@ -1033,9 +1034,6 @@ wifi@0 {
};
&pcie6a {
- perst-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
- wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
-
vddpe-3v3-supply = <&vreg_nvme>;
pinctrl-names = "default";
@@ -1051,6 +1049,11 @@ &pcie6a_phy {
status = "okay";
};
+&pcie6a_port0 {
+ reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
&qupv3_0 {
status = "okay";
};
--
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