* Re: [PATCH v8 11/23] scsi: ufs: mediatek: Remove undocumented downstream reset cruft
From: Nicolas Frattaroli @ 2026-03-05 9:57 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, vkoul@kernel.org, krzk+dt@kernel.org,
p.zabel@pengutronix.de, alim.akhtar@samsung.com,
matthias.bgg@gmail.com, avri.altman@wdc.com,
martin.petersen@oracle.com, broonie@kernel.org,
Peter Wang (王信友)
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <3aeee75e78fed2be92038c776463a231b94462f3.camel@mediatek.com>
On Thursday, 5 March 2026 10:14:47 Central European Standard Time Peter Wang (王信友) wrote:
> On Wed, 2026-03-04 at 15:53 +0100, Nicolas Frattaroli wrote:
> > @@ -2383,38 +2383,12 @@ MODULE_DEVICE_TABLE(of, ufs_mtk_of_match);
> > static int ufs_mtk_probe(struct platform_device *pdev)
> > {
> > int err;
> > - struct device *dev = &pdev->dev, *phy_dev = NULL;
> >
>
> Will there be a build error if phy_dev is removed?
> Please make sure that each patch can build successfully, one by one.
>
> Thanks
> Peter
>
>
>
>
Yes, these are the kinds of mistakes that happen when you ask someone
to pick apart patches for your downstream convenience.
I'll hand dealing with any further fixups and variable naming concerns
you have over to Angelo, as I can't be bothered to deal with you
anymore.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy-next 19/22] power: supply: cpcap-charger: include missing <linux/property.h>
From: Sebastian Reichel @ 2026-03-05 9:52 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-sunxi,
linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver
In-Reply-To: <20260304175735.2660419-20-vladimir.oltean@nxp.com>
[-- Attachment #1.1: Type: text/plain, Size: 1408 bytes --]
Hi,
On Wed, Mar 04, 2026 at 07:57:32PM +0200, Vladimir Oltean wrote:
> This file uses dev_fwnode() without including the proper header for it,
> relying on transitive header inclusion from:
>
> drivers/power/supply/cpcap-charger.c
> - include/linux/phy/omap_usb.h
> - include/linux/usb/phy_companion.h
> - include/linux/usb/otg.h
> - include/linux/phy/phy.h
> - drivers/phy/phy-provider.h
> - include/linux/of.h
> - include/linux/property.h
>
> With the future removal of drivers/phy/phy-provider.h from
> include/linux/phy/phy.h, this transitive inclusion would break.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> Cc: Sebastian Reichel <sre@kernel.org>
> ---
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
-- Sebastian
> drivers/power/supply/cpcap-charger.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/power/supply/cpcap-charger.c b/drivers/power/supply/cpcap-charger.c
> index d0c3008db534..24221244b45b 100644
> --- a/drivers/power/supply/cpcap-charger.c
> +++ b/drivers/power/supply/cpcap-charger.c
> @@ -21,6 +21,7 @@
> #include <linux/mod_devicetable.h>
> #include <linux/platform_device.h>
> #include <linux/power_supply.h>
> +#include <linux/property.h>
> #include <linux/regmap.h>
>
> #include <linux/gpio/consumer.h>
> --
> 2.43.0
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 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 v8 20/23] scsi: ufs: mediatek: Back up idle timer in per-instance struct
From: Peter Wang (王信友) @ 2026-03-05 9:39 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260304-mt8196-ufs-v8-20-5b0eac23314f@collabora.com>
On Wed, 2026-03-04 at 15:53 +0100, Nicolas Frattaroli wrote:
> @@ -187,6 +187,7 @@ struct ufs_mtk_host {
> u16 ref_clk_gating_wait_us;
> u32 ip_ver;
> bool legacy_ip_ver;
> + u32 hibernate_idle_timer;
>
Same as in patch V7, this variable is not clear to me.
Please do not omit "auto" or consider using "ahit" as
is customary in the UFS community.
Thanks
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 18/23] scsi: ufs: mediatek: Don't acquire dvfsrc-vcore twice
From: Peter Wang (王信友) @ 2026-03-05 9:38 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260304-mt8196-ufs-v8-18-5b0eac23314f@collabora.com>
On Wed, 2026-03-04 at 15:53 +0100, Nicolas Frattaroli wrote:
> As part of its featureset, the ufs-mediatek driver needs to play with
> an
> optional dvfsrc-vcore regulator for some of them.
>
> However, it currently does this by acquiring two different references
> to
> it in two different places, needlessly duplicating logic.
>
> Move reg_vcore to the host struct, acquire it in the same function as
> avdd09 is acquired, and rework the users of reg_vcore.
>
> Reviewed-by: AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 17/23] scsi: ufs: mediatek: Rework ufs_mtk_wait_idle_state
From: Peter Wang (王信友) @ 2026-03-05 9:37 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260304-mt8196-ufs-v8-17-5b0eac23314f@collabora.com>
On Wed, 2026-03-04 at 15:53 +0100, Nicolas Frattaroli wrote:
> While ufs_mtk_wait_idle state has some code smells for me (the
> VS_HCE_BASE early exit seems racey at best), it can still benefit
> from
> some general cleanup to make the code flow less convoluted.
>
> Use the iopoll helpers, for one, and specifically the one that sleeps
> and does not busy delay, as it's being done for up to 5ms.
>
> The register read is split out to a helper function that branches
> between new and old style flow.
>
> Every called uses the same 5ms timeout value, so there is no point in
> making this a parameter. Just assume a 5ms timeout in the function.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy-next 13/22] phy: introduce phy_get_max_link_rate() helper for consumers
From: Markus Schneider-Pargmann @ 2026-03-05 9:36 UTC (permalink / raw)
To: Vladimir Oltean, linux-phy
Cc: 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-sunxi,
linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver,
Andrzej Hajda, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Andy Yan,
Marc Kleine-Budde, Vincent Mailhol, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Markus Schneider-Pargmann,
Geert Uytterhoeven, Magnus Damm
In-Reply-To: <20260304175735.2660419-14-vladimir.oltean@nxp.com>
[-- Attachment #1.1: Type: text/plain, Size: 7905 bytes --]
Hi,
On Wed Mar 4, 2026 at 6:57 PM CET, Vladimir Oltean wrote:
> Consumer drivers shouldn't dereference struct phy, not even to get to
> its attributes.
>
> We have phy_get_bus_width() as a precedent for getting the bus_width
> attribute, so let's add phy_get_max_link_rate() and use it in DRM and
> CAN drivers.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> Cc: Andrzej Hajda <andrzej.hajda@intel.com>
> Cc: Neil Armstrong <neil.armstrong@linaro.org>
> Cc: Robert Foss <rfoss@kernel.org>
> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
> Cc: Jonas Karlman <jonas@kwiboo.se>
> Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Simona Vetter <simona@ffwll.ch>
> Cc: Andy Yan <andy.yan@rock-chips.com>
> Cc: Marc Kleine-Budde <mkl@pengutronix.de>
> Cc: Vincent Mailhol <mailhol@kernel.org>
> Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev>
> Cc: Markus Schneider-Pargmann <msp@baylibre.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> ---
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 4 ++--
> drivers/gpu/drm/bridge/synopsys/dw-dp.c | 2 +-
> drivers/net/can/at91_can.c | 2 +-
> drivers/net/can/flexcan/flexcan-core.c | 2 +-
> drivers/net/can/m_can/m_can_platform.c | 2 +-
> drivers/net/can/rcar/rcar_canfd.c | 2 +-
> drivers/phy/phy-core.c | 6 ++++++
> include/linux/phy/phy.h | 6 ++++++
> 8 files changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> index a8b6ae58cb0a..ed7ed82ddb64 100644
> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> @@ -1300,7 +1300,7 @@ static u32 cdns_mhdp_get_training_interval_us(struct cdns_mhdp_device *mhdp,
>
> static void cdns_mhdp_fill_host_caps(struct cdns_mhdp_device *mhdp)
> {
> - unsigned int link_rate;
> + u32 link_rate;
>
> /* Get source capabilities based on PHY attributes */
>
> @@ -1308,7 +1308,7 @@ static void cdns_mhdp_fill_host_caps(struct cdns_mhdp_device *mhdp)
> if (!mhdp->host.lanes_cnt)
> mhdp->host.lanes_cnt = 4;
>
> - link_rate = mhdp->phy->attrs.max_link_rate;
> + link_rate = phy_get_max_link_rate(mhdp->phy);
> if (!link_rate)
> link_rate = drm_dp_bw_code_to_link_rate(DP_LINK_BW_8_1);
> else
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> index 4ab6922dd79c..79c72ee8e263 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> @@ -536,7 +536,7 @@ static int dw_dp_link_parse(struct dw_dp *dp, struct drm_connector *connector)
>
> link->revision = link->dpcd[DP_DPCD_REV];
> link->rate = min_t(u32, min(dp->plat_data.max_link_rate,
> - dp->phy->attrs.max_link_rate * 100),
> + phy_get_max_link_rate(dp->phy) * 100),
> drm_dp_max_link_rate(link->dpcd));
> link->lanes = min_t(u8, phy_get_bus_width(dp->phy),
> drm_dp_max_lane_count(link->dpcd));
> diff --git a/drivers/net/can/at91_can.c b/drivers/net/can/at91_can.c
> index 58da323f14d7..b56db253f02d 100644
> --- a/drivers/net/can/at91_can.c
> +++ b/drivers/net/can/at91_can.c
> @@ -1126,7 +1126,7 @@ static int at91_can_probe(struct platform_device *pdev)
> can_rx_offload_add_timestamp(dev, &priv->offload);
>
> if (transceiver)
> - priv->can.bitrate_max = transceiver->attrs.max_link_rate;
> + priv->can.bitrate_max = phy_get_max_link_rate(transceiver);
>
> if (at91_is_sam9263(priv))
> dev->sysfs_groups[0] = &at91_sysfs_attr_group;
> diff --git a/drivers/net/can/flexcan/flexcan-core.c b/drivers/net/can/flexcan/flexcan-core.c
> index f5d22c61503f..3a4307bc1d61 100644
> --- a/drivers/net/can/flexcan/flexcan-core.c
> +++ b/drivers/net/can/flexcan/flexcan-core.c
> @@ -2211,7 +2211,7 @@ static int flexcan_probe(struct platform_device *pdev)
> priv->transceiver = transceiver;
>
> if (transceiver)
> - priv->can.bitrate_max = transceiver->attrs.max_link_rate;
> + priv->can.bitrate_max = phy_get_max_link_rate(transceiver);
>
> if (priv->devtype_data.quirks & FLEXCAN_QUIRK_NR_IRQ_3) {
> priv->irq_boff = platform_get_irq(pdev, 1);
> diff --git a/drivers/net/can/m_can/m_can_platform.c b/drivers/net/can/m_can/m_can_platform.c
> index 56da411878af..73525be6566b 100644
> --- a/drivers/net/can/m_can/m_can_platform.c
> +++ b/drivers/net/can/m_can/m_can_platform.c
> @@ -132,7 +132,7 @@ static int m_can_plat_probe(struct platform_device *pdev)
> }
>
> if (transceiver)
> - mcan_class->can.bitrate_max = transceiver->attrs.max_link_rate;
> + mcan_class->can.bitrate_max = phy_get_max_link_rate(transceiver);
>
> priv->base = addr;
> priv->mram_base = mram_addr;
> diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
> index eaf8cac78038..645d5671705d 100644
> --- a/drivers/net/can/rcar/rcar_canfd.c
> +++ b/drivers/net/can/rcar/rcar_canfd.c
> @@ -1885,7 +1885,7 @@ static int rcar_canfd_channel_probe(struct rcar_canfd_global *gpriv, u32 ch,
> priv->channel = ch;
> priv->gpriv = gpriv;
> if (transceiver)
> - priv->can.bitrate_max = transceiver->attrs.max_link_rate;
> + priv->can.bitrate_max = phy_get_max_link_rate(transceiver);
> priv->can.clock.freq = fcan_freq;
> dev_info(dev, "can_clk rate is %u\n", priv->can.clock.freq);
>
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index a1aff00fba7c..89f7410241aa 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -640,6 +640,12 @@ void phy_set_bus_width(struct phy *phy, int bus_width)
> }
> EXPORT_SYMBOL_GPL(phy_set_bus_width);
>
> +u32 phy_get_max_link_rate(struct phy *phy)
> +{
All of the can drivers that would use this function are checking phy
before assigning the max_link_rate:
if (transceiver)
priv->can.bitrate_max = transceiver->attrs.max_link_rate;
Would it be reasonable to have
if (!phy)
return 0;
in this function to be able to drop these individual checks of the
drivers? This would be similar to clk_get_rate() which does the same
check and return 0 for convenience.
Best
Markus
> + return phy->attrs.max_link_rate;
> +}
> +EXPORT_SYMBOL_GPL(phy_get_max_link_rate);
> +
> /**
> * _of_phy_get() - lookup and obtain a reference to a phy by phandle
> * @np: device_node for which to get the phy
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index 36307e47760d..af9c3e795786 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -57,6 +57,7 @@ int phy_notify_disconnect(struct phy *phy, int port);
> int phy_notify_state(struct phy *phy, union phy_notify state);
> int phy_get_bus_width(struct phy *phy);
> void phy_set_bus_width(struct phy *phy, int bus_width);
> +u32 phy_get_max_link_rate(struct phy *phy);
> #else
> static inline struct phy *phy_get(struct device *dev, const char *string)
> {
> @@ -256,6 +257,11 @@ static inline int phy_get_bus_width(struct phy *phy)
> static inline void phy_set_bus_width(struct phy *phy, int bus_width)
> {
> }
> +
> +static inline u32 phy_get_max_link_rate(struct phy *phy)
> +{
> + return 0;
> +}
> #endif /* IS_ENABLED(CONFIG_GENERIC_PHY) */
>
> #endif /* __PHY_CONSUMER_H */
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 289 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 v8 16/23] scsi: ufs: mediatek: Clean up logging prints
From: Peter Wang (王信友) @ 2026-03-05 9:34 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260304-mt8196-ufs-v8-16-5b0eac23314f@collabora.com>
On Wed, 2026-03-04 at 15:53 +0100, Nicolas Frattaroli wrote:
> The Linux kernel's log buffer provides many levels of verbosity,
> associated with different semantic meanings. Care should be taken to
> only log useful information to the info level, and log errors to the
> error level.
>
> The MediaTek UFS driver does not do this. It freely logs verbose
> debug
> information to the info level, errors to the info level, and
> sometimes
> errors to the warning level.
>
> Adjust all the wrapped kprintf invocations to rectify this situation.
> Use user-friendly %pe format codes for printing errors where
> possible.
>
> Reviewed-by: AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 14/23] scsi: ufs: mediatek: Remove mediatek,ufs-broken-rtc property
From: Peter Wang (王信友) @ 2026-03-05 9:33 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260304-mt8196-ufs-v8-14-5b0eac23314f@collabora.com>
On Wed, 2026-03-04 at 15:53 +0100, Nicolas Frattaroli wrote:
> This flag property was never described in the binding, and its
> capability wrapper seems pointless.
>
> If one of the MediaTek SoCs needs the ufshcd quirk applied, then this
> can be done per-compatible, without needing to give the device tree
> author the option to forget to set it.
>
> Remove it and the associated capability flag wrapping code.
>
> Reviewed-by: AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy-next 22/22] MAINTAINERS: add regex for linux-phy
From: Joe Perches @ 2026-03-05 9:30 UTC (permalink / raw)
To: Vladimir Oltean, Konrad Dybcio
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-sunxi,
linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver
In-Reply-To: <20260305085148.7cwo3yflp7vcfldf@skbuf>
On Thu, 2026-03-05 at 10:51 +0200, Vladimir Oltean wrote:
> On Thu, Mar 05, 2026 at 09:39:35AM +0100, Konrad Dybcio wrote:
> diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 55af015174a5..bdfa47d9c774 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -10713,6 +10713,7 @@ F: Documentation/devicetree/bindings/phy/
> > > F: drivers/phy/
> > > F: include/dt-bindings/phy/
> > > F: include/linux/phy/
> > > +K: \b(devm_)?(of_)?phy_(create|destroy|init|exit|reset|power_(on|off)|configure|validate|calibrate|(get|set)_(mode|media|speed|bus_width|drvdata)|get_max_link_rate|pm_runtime_(get|put)|notify_(connect|disconnect|state)|get|put|optional_get|provider_(un)?register|simple_xlate|(create|remove)_lookup)\b|(struct\s+)?phy(_ops|_attrs|_lookup|_provider)?\b|linux/phy/phy\.h|phy-props\.h|phy-provider\.h
You could use multiple K: entries instead of this monster.
And please use (?:<foo>) to avoid capture groups too.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 4/4] phy: airoha: Add support for Airoha AN7581 USB PHY
From: kernel test robot @ 2026-03-05 9:18 UTC (permalink / raw)
To: Christian Marangi, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lorenzo Bianconi,
linux-arm-kernel, linux-phy, devicetree, linux-kernel
Cc: oe-kbuild-all
In-Reply-To: <20260304005843.2680-5-ansuelsmth@gmail.com>
Hi Christian,
kernel test robot noticed the following build warnings:
[auto build test WARNING on next-20260303]
[cannot apply to robh/for-next linus/master v7.0-rc2 v7.0-rc1 v6.19 v7.0-rc2]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Christian-Marangi/dt-bindings-soc-Add-bindings-for-Airoha-SCU-Serdes-lines/20260304-090107
base: next-20260303
patch link: https://lore.kernel.org/r/20260304005843.2680-5-ansuelsmth%40gmail.com
patch subject: [PATCH v5 4/4] phy: airoha: Add support for Airoha AN7581 USB PHY
config: powerpc64-randconfig-r131-20260305 (https://download.01.org/0day-ci/archive/20260305/202603051725.x2cR2ynI-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 9a109fbb6e184ec9bcce10615949f598f4c974a9)
sparse: v0.6.5-rc1
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260305/202603051725.x2cR2ynI-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603051725.x2cR2ynI-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
>> drivers/phy/airoha/phy-an7581-usb.c:569:14: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *base @@ got void [noderef] __iomem * @@
drivers/phy/airoha/phy-an7581-usb.c:569:14: sparse: expected void *base
drivers/phy/airoha/phy-an7581-usb.c:569:14: sparse: got void [noderef] __iomem *
>> drivers/phy/airoha/phy-an7581-usb.c:573:24: sparse: sparse: incorrect type in argument 3 (different address spaces) @@ expected void [noderef] __iomem *regs @@ got void *base @@
drivers/phy/airoha/phy-an7581-usb.c:573:24: sparse: expected void [noderef] __iomem *regs
drivers/phy/airoha/phy-an7581-usb.c:573:24: sparse: got void *base
vim +569 drivers/phy/airoha/phy-an7581-usb.c
545
546 static int an7581_usb_phy_probe(struct platform_device *pdev)
547 {
548 struct phy_provider *phy_provider;
549 struct an7581_usb_phy_priv *priv;
550 struct device *dev = &pdev->dev;
551 unsigned int index;
552 void *base;
553 int ret;
554
555 priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
556 if (!priv)
557 return -ENOMEM;
558
559 priv->dev = dev;
560
561 ret = of_property_read_u32(dev->of_node, "airoha,usb2-monitor-clk-sel",
562 &priv->monclk_sel);
563 if (ret)
564 return dev_err_probe(dev, ret, "Monitor clock selection is mandatory for USB PHY calibration\n");
565
566 if (priv->monclk_sel > 3)
567 return dev_err_probe(dev, -EINVAL, "only 4 Monitor clock are selectable on the SoC\n");
568
> 569 base = devm_platform_ioremap_resource(pdev, 0);
570 if (IS_ERR(base))
571 return PTR_ERR(base);
572
> 573 priv->regmap = devm_regmap_init_mmio(dev, base, &an7581_usb_phy_regmap_config);
574 if (IS_ERR(priv->regmap))
575 return PTR_ERR(priv->regmap);
576
577 platform_set_drvdata(pdev, priv);
578
579 for (index = 0; index < AIROHA_PHY_USB_MAX; index++) {
580 enum an7581_usb_phy_instance_type phy_type;
581 struct an7581_usb_phy_instance *instance;
582
583 switch (index) {
584 case AIROHA_PHY_USB2:
585 phy_type = PHY_TYPE_USB2;
586 break;
587 case AIROHA_PHY_USB3:
588 phy_type = PHY_TYPE_USB3;
589 break;
590 }
591
592 if (phy_type == PHY_TYPE_USB3) {
593 ret = of_property_read_u32(dev->of_node, "airoha,usb3-serdes",
594 &priv->serdes_port);
595 if (ret)
596 return dev_err_probe(dev, ret, "missing serdes line for USB 3.0\n");
597
598 priv->scu = syscon_regmap_lookup_by_compatible("airoha,en7581-scu");
599 if (IS_ERR(priv->scu))
600 return dev_err_probe(dev, PTR_ERR(priv->scu), "failed to get SCU syscon\n");
601 }
602
603 instance = devm_kzalloc(dev, sizeof(*instance), GFP_KERNEL);
604 if (!instance)
605 return -ENOMEM;
606
607 instance->type = phy_type;
608 priv->phys[index] = instance;
609
610 instance->phy = devm_phy_create(dev, NULL, &airoha_phy);
611 if (IS_ERR(instance->phy))
612 return dev_err_probe(dev, PTR_ERR(instance->phy), "failed to create phy\n");
613
614 phy_set_drvdata(instance->phy, instance);
615 }
616
617 phy_provider = devm_of_phy_provider_register(&pdev->dev, an7581_usb_phy_xlate);
618
619 return PTR_ERR_OR_ZERO(phy_provider);
620 }
621
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 11/23] scsi: ufs: mediatek: Remove undocumented downstream reset cruft
From: Peter Wang (王信友) @ 2026-03-05 9:14 UTC (permalink / raw)
To: chu.stanley@gmail.com, robh@kernel.org,
Chunfeng Yun (云春峰), kishon@kernel.org,
James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
conor+dt@kernel.org, Chaotian Jing (井朝天),
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, matthias.bgg@gmail.com,
avri.altman@wdc.com, martin.petersen@oracle.com,
broonie@kernel.org
Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <20260304-mt8196-ufs-v8-11-5b0eac23314f@collabora.com>
On Wed, 2026-03-04 at 15:53 +0100, Nicolas Frattaroli wrote:
> @@ -2383,38 +2383,12 @@ MODULE_DEVICE_TABLE(of, ufs_mtk_of_match);
> static int ufs_mtk_probe(struct platform_device *pdev)
> {
> int err;
> - struct device *dev = &pdev->dev, *phy_dev = NULL;
>
Will there be a build error if phy_dev is removed?
Please make sure that each patch can build successfully, one by one.
Thanks
Peter
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy-next 22/22] MAINTAINERS: add regex for linux-phy
From: Konrad Dybcio @ 2026-03-05 9:15 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-sunxi,
linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver
In-Reply-To: <20260305091336.ls3k24ieehntxf4f@skbuf>
On 3/5/26 10:13 AM, Vladimir Oltean wrote:
> On Thu, Mar 05, 2026 at 10:11:32AM +0100, Konrad Dybcio wrote:
>> On 3/5/26 9:51 AM, Vladimir Oltean wrote:
>>> Hello Konrad,
>>>
>>> On Thu, Mar 05, 2026 at 09:39:35AM +0100, Konrad Dybcio wrote:
>>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>>> index 55af015174a5..bdfa47d9c774 100644
>>>>> --- a/MAINTAINERS
>>>>> +++ b/MAINTAINERS
>>>>> @@ -10713,6 +10713,7 @@ F: Documentation/devicetree/bindings/phy/
>>>>> F: drivers/phy/
>>>>> F: include/dt-bindings/phy/
>>>>> F: include/linux/phy/
>>>>> +K: \b(devm_)?(of_)?phy_(create|destroy|init|exit|reset|power_(on|off)|configure|validate|calibrate|(get|set)_(mode|media|speed|bus_width|drvdata)|get_max_link_rate|pm_runtime_(get|put)|notify_(connect|disconnect|state)|get|put|optional_get|provider_(un)?register|simple_xlate|(create|remove)_lookup)\b|(struct\s+)?phy(_ops|_attrs|_lookup|_provider)?\b|linux/phy/phy\.h|phy-props\.h|phy-provider\.h
>>>>
>>>> Would looking for the devm/of_phy_ prefix followed by an open parentheses
>>>> not suffice for the 'has function call' case, instead of listing all
>>>> currently present exported functions?
>>>
>>> This would maybe work when you run ./scripts/get_maintainer.pl on a file.
>>> But I would like it to have good coverage on individual patches too. And
>>> since the devm/of_phy prefix only matches when you "get" the PHY, not
>>> "use" it, my fear is we would still be missing out on the most important
>>> part of the patches.
>>
>> But that's just '(devm_)?(of_)?phy_[a-z]+\(|includes.h'?
>
> Yeah, but what about the networking PHY API, phy_start(), phy_connect(),
> phy_inband_caps() etc?
OK I wasn't aware of that poor namespacing..
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 0/5] phy: qcom: qmp-pcie: Add PCIe Gen5 8-lane bifurcation support for Glymur
From: Konrad Dybcio @ 2026-03-05 9:14 UTC (permalink / raw)
To: Qiang Yu, 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
In-Reply-To: <20260304-glymur_gen5x8_phy-v1-0-849e9a72e125@oss.qualcomm.com>
On 3/4/26 9:21 AM, Qiang Yu wrote:
> This patch series adds support for PCIe Gen5 8-lane bifurcation mode on
> the Glymur SoC's third PCIe controller. In this configuration, pcie3a PHY
> acts as leader and pcie3b PHY as follower to form a single 8-lane PCIe
> Gen5 interface.
>
> To support 8-lanes mode, this patch series add multiple power domain and
> multi nocsr reset infrastructure as the hardware programming guide
> specifies a strict initialization sequence for bifurcation mode that
> requires coordinated multi-PHY resource management:
>
> 1. Turn on both pcie3a_phy_gdsc and pcie3b_phy_gdsc power domains
> 2. Assert both pcie3a and pcie3b nocsr resets, then deassert them together
> 3. Enable all pcie3a PHY clocks and pcie3b PHY aux clock (bifur_aux)
> 4. Poll for PHY ready status
I think we never concluded the discussion where I suggested the
bifurcated PHY may be better expressed as a single node with
#phy-cells = <1>, removing the need for duplicated resource references
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy-next 22/22] MAINTAINERS: add regex for linux-phy
From: Vladimir Oltean @ 2026-03-05 9:13 UTC (permalink / raw)
To: Konrad Dybcio
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-sunxi,
linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver
In-Reply-To: <ebee2fcf-9069-4a9f-ae72-86f4471cd4f3@oss.qualcomm.com>
On Thu, Mar 05, 2026 at 10:11:32AM +0100, Konrad Dybcio wrote:
> On 3/5/26 9:51 AM, Vladimir Oltean wrote:
> > Hello Konrad,
> >
> > On Thu, Mar 05, 2026 at 09:39:35AM +0100, Konrad Dybcio wrote:
> >>> diff --git a/MAINTAINERS b/MAINTAINERS
> >>> index 55af015174a5..bdfa47d9c774 100644
> >>> --- a/MAINTAINERS
> >>> +++ b/MAINTAINERS
> >>> @@ -10713,6 +10713,7 @@ F: Documentation/devicetree/bindings/phy/
> >>> F: drivers/phy/
> >>> F: include/dt-bindings/phy/
> >>> F: include/linux/phy/
> >>> +K: \b(devm_)?(of_)?phy_(create|destroy|init|exit|reset|power_(on|off)|configure|validate|calibrate|(get|set)_(mode|media|speed|bus_width|drvdata)|get_max_link_rate|pm_runtime_(get|put)|notify_(connect|disconnect|state)|get|put|optional_get|provider_(un)?register|simple_xlate|(create|remove)_lookup)\b|(struct\s+)?phy(_ops|_attrs|_lookup|_provider)?\b|linux/phy/phy\.h|phy-props\.h|phy-provider\.h
> >>
> >> Would looking for the devm/of_phy_ prefix followed by an open parentheses
> >> not suffice for the 'has function call' case, instead of listing all
> >> currently present exported functions?
> >
> > This would maybe work when you run ./scripts/get_maintainer.pl on a file.
> > But I would like it to have good coverage on individual patches too. And
> > since the devm/of_phy prefix only matches when you "get" the PHY, not
> > "use" it, my fear is we would still be missing out on the most important
> > part of the patches.
>
> But that's just '(devm_)?(of_)?phy_[a-z]+\(|includes.h'?
Yeah, but what about the networking PHY API, phy_start(), phy_connect(),
phy_inband_caps() etc?
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy-next 22/22] MAINTAINERS: add regex for linux-phy
From: Konrad Dybcio @ 2026-03-05 9:11 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-sunxi,
linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver
In-Reply-To: <20260305085148.7cwo3yflp7vcfldf@skbuf>
On 3/5/26 9:51 AM, Vladimir Oltean wrote:
> Hello Konrad,
>
> On Thu, Mar 05, 2026 at 09:39:35AM +0100, Konrad Dybcio wrote:
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 55af015174a5..bdfa47d9c774 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -10713,6 +10713,7 @@ F: Documentation/devicetree/bindings/phy/
>>> F: drivers/phy/
>>> F: include/dt-bindings/phy/
>>> F: include/linux/phy/
>>> +K: \b(devm_)?(of_)?phy_(create|destroy|init|exit|reset|power_(on|off)|configure|validate|calibrate|(get|set)_(mode|media|speed|bus_width|drvdata)|get_max_link_rate|pm_runtime_(get|put)|notify_(connect|disconnect|state)|get|put|optional_get|provider_(un)?register|simple_xlate|(create|remove)_lookup)\b|(struct\s+)?phy(_ops|_attrs|_lookup|_provider)?\b|linux/phy/phy\.h|phy-props\.h|phy-provider\.h
>>
>> Would looking for the devm/of_phy_ prefix followed by an open parentheses
>> not suffice for the 'has function call' case, instead of listing all
>> currently present exported functions?
>
> This would maybe work when you run ./scripts/get_maintainer.pl on a file.
> But I would like it to have good coverage on individual patches too. And
> since the devm/of_phy prefix only matches when you "get" the PHY, not
> "use" it, my fear is we would still be missing out on the most important
> part of the patches.
But that's just '(devm_)?(of_)?phy_[a-z]+\(|includes.h'?
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add vdda-refgen supply for Glymur
From: Qiang Yu @ 2026-03-05 8:57 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Dmitry Baryshkov, Krzysztof Kozlowski, Vinod Koul, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm,
linux-phy, devicetree, linux-kernel
In-Reply-To: <578c485e-b7d3-4468-bece-efeb6db2b1e1@oss.qualcomm.com>
On Tue, Mar 03, 2026 at 12:14:29PM +0100, Konrad Dybcio wrote:
> On 3/2/26 11:21 AM, Qiang Yu wrote:
> > On Fri, Feb 13, 2026 at 07:47:36PM +0200, Dmitry Baryshkov wrote:
> >> On Wed, Feb 11, 2026 at 07:32:23PM -0800, Qiang Yu wrote:
> >>> On Mon, Feb 09, 2026 at 09:06:23AM +0100, Krzysztof Kozlowski wrote:
> >>>> On Sun, Feb 08, 2026 at 08:49:39PM -0800, Qiang Yu wrote:
> >>>>> The PCIe QMP PHYs on Glymur require stable reference voltage provided by
> >>>>> refgen. The refgen itself requires two separate power supplies:
> >>>>> vdda-refgen0p9 and vdda-refgen1p2.
> >>>>>
> >>>>> Since there is no dedicated driver for REFGEN, add vdda-refgen0p9-supply
> >>>>
> >>>> How does the driver matter for the bindings? If I add dedicated driver
> >>>> for refgen, then I change the bindings?
> >>>
> >>> Yeah, I know that dt-bindings should describe hardware, not software. But
> >>> what I meant to say is that the refgen is different from qref which is
> >>> controlled via TCSR registers and its LDOs are requested to vote in
> >>> tcsrcc driver. The refgen doesn't required register setting and it doesn't
> >>> have dedicated driver, so we vote its LDOs in phy driver. I will avoid
> >>> this statement in next version.
> >>
> >> I must admit, I could not find references to the refgen in any of Glymur
> >> PCIe-related HPGs.
> >>
> >>>
> >>>>
> >>>> There is qcom,sc8280xp-refgen-regulator so why there cannot be
> >>>> qcom,x1e-refgen-regulator?
> >>>
> >>> I think we can and it seems better because the refgen for pcie phy also
> >>> supplies reference voltage to other modules like usb. But I checked the
> >>> qcom-refgen-regulator.c, it contains some register settings and there is
> >>> no LDOs voting. I'm not sure what does those register do, maybe Konrad
> >>> can provide some backgroud.
> >>
> >> Those regs provide voting for refgen, because on those platforms DSI
> >> block doesn't have a hardware vote for refgen.
> >
> > Hi Konrad, Dmitry
> >
> > I tried to model the reference voltage as a fixed regulator but the fixed
> > regulator driver only supports a single vin-supply. However, the refgen
> > block requires two separate power supplies (1.2V and 0.9V LDOs).
> >
> > Would it be appropriate to modify the qcom-refgen-regulator.c driver to
> > handle LDO voting for both the 1.2V and 0.9V supplies? In the regulator's
> > enable/disable callbacks, we could vote for and unvote these two LDOs
> > instead of performing register operations.
>
> Wait, so you want to associate the MMIO-controlled refgen's driver with
> a dummy regulator that takes 2 supplies? I didn't catch that part earlier,
> that's not great..
>
> Or do we actually have access to the MMIO of *this* refgen and can control
I can't find related info in any documentation.
> it (except we don't do that today because X Y Z)?
>
But even if we could find registers to enable/disable the refgen block,
the two LDOs (1.2V and 0.9V) would still need to be voted/unvoted manually
since they're separate power rails that feed the refgen.
I searched through the drivers/regulator/ directory and couldn't find any
existing examples where a regulator driver enables/disables other
regulators in its own enable/disable callbacks. This pattern doesn't seem
to be commonly used in the kernel.
So seems like we have to vote this two LDOs in phy driver.
- Qiang Yu
> Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy-next 22/22] MAINTAINERS: add regex for linux-phy
From: Vladimir Oltean @ 2026-03-05 8:51 UTC (permalink / raw)
To: Konrad Dybcio
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-sunxi,
linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver
In-Reply-To: <a8fee1cd-1e69-4a9e-8533-c0988c480fb9@oss.qualcomm.com>
Hello Konrad,
On Thu, Mar 05, 2026 at 09:39:35AM +0100, Konrad Dybcio wrote:
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 55af015174a5..bdfa47d9c774 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -10713,6 +10713,7 @@ F: Documentation/devicetree/bindings/phy/
> > F: drivers/phy/
> > F: include/dt-bindings/phy/
> > F: include/linux/phy/
> > +K: \b(devm_)?(of_)?phy_(create|destroy|init|exit|reset|power_(on|off)|configure|validate|calibrate|(get|set)_(mode|media|speed|bus_width|drvdata)|get_max_link_rate|pm_runtime_(get|put)|notify_(connect|disconnect|state)|get|put|optional_get|provider_(un)?register|simple_xlate|(create|remove)_lookup)\b|(struct\s+)?phy(_ops|_attrs|_lookup|_provider)?\b|linux/phy/phy\.h|phy-props\.h|phy-provider\.h
>
> Would looking for the devm/of_phy_ prefix followed by an open parentheses
> not suffice for the 'has function call' case, instead of listing all
> currently present exported functions?
This would maybe work when you run ./scripts/get_maintainer.pl on a file.
But I would like it to have good coverage on individual patches too. And
since the devm/of_phy prefix only matches when you "get" the PHY, not
"use" it, my fear is we would still be missing out on the most important
part of the patches.
>
> My worry is that this approach is overbuilt and absolutely no one will
> remember to update it
I think I can add a test in the patch build automation that correlates
function and struct names from <linux/phy/phy.h> with their presence in
MAINTAINERS.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 5/5] arch: arm64: dts: qcom: Add support for PCIe3a
From: Qiang Yu @ 2026-03-05 8:40 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <u4abdgzrlfijwymnoneb6xa34l3y6fpenlbidvej5cgfz2dzkd@dk37ihalaast>
On Thu, Mar 05, 2026 at 02:02:18AM +0200, Dmitry Baryshkov wrote:
> On Wed, Mar 04, 2026 at 12:21:59AM -0800, Qiang Yu wrote:
> > 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(-)
> >
> > + 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",
>
> Please align on "
Okay, will align on " in next version.
>
> > + "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";
>
> Should we be supplying _b components by default? What about the
> platforms which might use separate 3a and 3b?
We can override compatible, resets, and clks in board.dts.
- Qiang Yu
>
> > +
> > + 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
> >
>
> --
> 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 phy-next 22/22] MAINTAINERS: add regex for linux-phy
From: Konrad Dybcio @ 2026-03-05 8:39 UTC (permalink / raw)
To: Vladimir Oltean, linux-phy
Cc: 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-sunxi,
linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver
In-Reply-To: <20260304175735.2660419-23-vladimir.oltean@nxp.com>
On 3/4/26 6:57 PM, Vladimir Oltean wrote:
> Some pragmatic shortcuts are being taken by PHY consumer driver authors,
> which put a burden on the framework. A lot of these can be caught during
> review.
>
> Make sure the linux-phy list is copied on as many keywords that a regex
> can reasonably catch.
>
> For simplicity sake this is not perfect (devm_ and of_ are not valid
> prefixes for all function names), but I tried to pay attention on
> avoiding false matches on things like:
> - drivers/net/vendor/device/phy.h
> - include/linux/phy.h - network PHY, not generic PHY
>
> So I used \b to try to match on actual word boundaries and be explicit
> about what is matched on.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 55af015174a5..bdfa47d9c774 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10713,6 +10713,7 @@ F: Documentation/devicetree/bindings/phy/
> F: drivers/phy/
> F: include/dt-bindings/phy/
> F: include/linux/phy/
> +K: \b(devm_)?(of_)?phy_(create|destroy|init|exit|reset|power_(on|off)|configure|validate|calibrate|(get|set)_(mode|media|speed|bus_width|drvdata)|get_max_link_rate|pm_runtime_(get|put)|notify_(connect|disconnect|state)|get|put|optional_get|provider_(un)?register|simple_xlate|(create|remove)_lookup)\b|(struct\s+)?phy(_ops|_attrs|_lookup|_provider)?\b|linux/phy/phy\.h|phy-props\.h|phy-provider\.h
Would looking for the devm/of_phy_ prefix followed by an open parentheses
not suffice for the 'has function call' case, instead of listing all
currently present exported functions?
My worry is that this approach is overbuilt and absolutely no one will
remember to update it
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy-next 17/22] net: renesas: rswitch: include PHY provider header
From: Geert Uytterhoeven @ 2026-03-05 8:29 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-sunxi,
linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver,
Yoshihiro Shimoda, Michael Dege, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Russell King (Oracle)
In-Reply-To: <20260304175735.2660419-18-vladimir.oltean@nxp.com>
On Wed, 4 Mar 2026 at 19:00, Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
> As a PHY consumer driver, the Renesas rswitch dereferences internal
> fields of struct phy, something which shouldn't be done, as that is
> going to be made an opaque pointer.
>
> It is quite clearly visible that the driver is tightly coupled with the
> drivers/phy/renesas/r8a779f0-ether-serdes.c, which puts heavy pressure
> on the Generic PHY subsystem.
>
> This was discussed before here:
> https://lore.kernel.org/linux-phy/20260211194541.cdmibrpfn6ej6e74@skbuf/
>
> but to summarize, it is generally expected that when a Generic PHY
> function is called, it takes effect immediately. When this doesn't
> happen, the PHY provider driver must change its implementation rather
> than the consumer be made to work around it. PHY providers which rely on
> a hardcoded call sequence in the consumer are just lazy and wrong.
>
> The most obvious example is commit 5cb630925b49 ("net: renesas: rswitch:
> Add phy_power_{on,off}() calling"). Problem description:
> - Ethernet PHYs may change phydev->interface. When this happens, the
> SerDes must learn of the new phydev->interface using phy_set_mode_ext().
> - drivers/phy/renesas/r8a779f0-ether-serdes.c implements phy_set_mode_ext(),
> but this only caches the mode and submode into channel->phy_interface
> and applies this to hardware during phy_power_on().
>
> The commit author decided to work around this at the consumer site, by
> power cycling the PHY for the configuration to take effect.
>
> This had a worse implication from an API perspective in subsequent
> commit 053f13f67be6 ("rswitch: Fix imbalance phy_power_off() calling").
> It was observed that phy_power_on() and phy_power_off() calls need to be
> balanced, and so, the consumer decided to start looking at the struct
> phy :: power_count (the technical reason why I'm making this change).
>
> This is also wrong from an API perspective because
> - a consumer should only care about its own vote on the PHY power state.
> If this is a multi-port submode like QSGMII, a single phy_power_off()
> call will not actually turn the PHY off (nor should it).
> - the power_count is written under the &phy->mutex, but read unlocked
> here.
>
> The rswitch and r8a779f0-ether-serdes drivers both need to be completely
> rethought in terms of Generic PHY API call sequence. There is no quick
> fix to apply. Just include the PHY provider API along with the consumer
> one, to keep working as before when struct phy will be made an opaque
> pointer to normal PHY consumers. But this is a bad offender (and it's
> not even a provider) so add a FIXME.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] dt-bindings: display/msm: move DSI PHY bindings to phy/ subdir
From: Krzysztof Kozlowski @ 2026-03-05 8:36 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
Krishna Manikandan, Jonathan Marek, linux-arm-msm, dri-devel,
freedreno, devicetree, linux-kernel, linux-phy
In-Reply-To: <20260305-msm-dsi-phy-v1-1-0a99ac665995@oss.qualcomm.com>
On Thu, Mar 05, 2026 at 01:47:12AM +0200, Dmitry Baryshkov wrote:
> Historically DSI PHY bindings landed to the display/msm subdir, however
> they describe PHYs and as such they should be in the phy/ subdir.
> Follow the example of other Qualcomm display-related PHYs (HDMI, eDP)
> and move bindings for the Qualcomm DSI PHYs to the correct subdir.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> Merge strategy: I'd ask to merge bindings through the msm tree, reducing
> the conflicts for the current kernel development cycle. Starting from
> the cycle after this patch is merged, DSI PHY bindings should go through
> the PHY tree.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy-next 12/22] phy: move provider API out of public <linux/phy/phy.h>
From: Geert Uytterhoeven @ 2026-03-05 8:28 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-sunxi,
linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver
In-Reply-To: <20260304175735.2660419-13-vladimir.oltean@nxp.com>
Hi Vladimir,
On Wed, 4 Mar 2026 at 19:03, Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
> The major goal is to hide the contents of struct phy from consumer
> drivers.
>
> The idea with "phy-props.h" is that both consumers and providers make
> use of some data types. So both headers include "phy-props.h".
>
> Two slight points of contention.
>
> 1. phy_set_bus_width(): Vinod explains that despite the current caller
> situation (9 providers, 1 consumer), it is a consumer API function.
>
> The use case is that the controller (for example UFS) may have
> limitations and should set the expected lanes to be used and width on
> those lanes. A number of Generic PHYs can support multiple lanes and
> multiple width so this is way for controller telling I am using this
> configuration.
>
> 2. phy-provider.h should go to include/linux/phy/ or to drivers/phy/?
> We do have 3 PHY providers outside of drivers/phy/:
>
> drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c
> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> drivers/pinctrl/tegra/pinctrl-tegra-xusb.c
>
> but the practice is not encouraged, and with time, these should be
> moved to the subsystem. This is not something that I can do now.
>
> For temporary compatibility, keep including the provider header. This
> will be removed when abuses are all gotten rid of.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Thanks for your patch!
> --- /dev/null
> +++ b/drivers/phy/phy-provider.h
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -1,246 +1,38 @@
> /* SPDX-License-Identifier: GPL-2.0-or-later */
> /*
> - * phy.h -- generic phy header file
> + * phy.h -- Generic PHY consumer API
> *
> * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
> *
> * Author: Kishon Vijay Abraham I <kishon@ti.com>
> */
>
> -#ifndef __DRIVERS_PHY_H
> -#define __DRIVERS_PHY_H
> +#ifndef __PHY_CONSUMER_H
> +#define __PHY_CONSUMER_H
>
> -#include <linux/err.h>
> -#include <linux/of.h>
> -#include <linux/device.h>
> -#include <linux/pm_runtime.h>
> -#include <linux/regulator/consumer.h>
> +#include <linux/phy/phy-props.h>
>
> -#include <linux/phy/phy-dp.h>
> -#include <linux/phy/phy-hdmi.h>
> -#include <linux/phy/phy-lvds.h>
> -#include <linux/phy/phy-mipi-dphy.h>
> +#include "../../drivers/phy/phy-provider.h"
Shouldn't there be one more "../"?
Interestingly, it compiles with/without.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/5] phy: qcom: qmp-pcie: Add multiple power-domains support
From: Qiang Yu @ 2026-03-05 8:34 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <duny3mu3vx75m5ik7xkqotdajomkpj5udg7x2gcyj6pho2ybv7@w3q3pru35p45>
On Thu, Mar 05, 2026 at 01:58:34AM +0200, Dmitry Baryshkov wrote:
> On Wed, Mar 04, 2026 at 12:21:56AM -0800, Qiang Yu wrote:
> > 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 | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> > index fed2fc9bb31108d51f88d34f3379c7744681f485..7369c291be51aa1ad7a330459dcb857f5a1988f6 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>
> > @@ -3334,6 +3335,8 @@ struct qmp_pcie {
> >
> > struct clk_fixed_rate pipe_clk_fixed;
> > struct clk_fixed_rate aux_clk_fixed;
> > +
> > + struct dev_pm_domain_list *pd_list;
> > };
> >
> > static bool qphy_checkbits(const void __iomem *base, u32 offset, u32 val)
> > @@ -5348,6 +5351,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, &qmp->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;
>
> These two should be separate commits.
IIUC, dev_pm_domain_attach_list doesn't turn on power domian during
attaching, which is different to dev_pm_domain_attach called in
platform_probe for single power domain.
- Qiang Yu
>
> > +
> > ret = qmp_pcie_clk_init(qmp);
> > if (ret)
> > return ret;
> >
> > --
> > 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 2/5] phy: qcom: qmp-pcie: Add multiple power-domains support
From: Qiang Yu @ 2026-03-05 8:17 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Konrad Dybcio, linux-arm-msm,
linux-phy, devicetree, linux-kernel
In-Reply-To: <qmtl3j7czisocywmkwgaxxuzhc6e6zzvaqmqjs5p2phcpk2q3x@rocbjxeguv4g>
On Wed, Mar 04, 2026 at 02:46:22PM -0600, Bjorn Andersson wrote:
> On Wed, Mar 04, 2026 at 12:21:56AM -0800, Qiang Yu wrote:
> > 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:
> >
>
> Enabling runtime PM seems like a separate change that impacts all
> existing targets, while adding multiple power domains should only affect
> the specific ones.
>
> I'm not sure if it's too picky, but it would be nice to separate this -
> so that any issues that might arise can be bisected down to one or the
> other of these two changes?
The devm_pm_domain_attach_list() function calls genpd_dev_pm_attach_by_id,
which in turn calls __genpd_dev_pm_attach() with power_on=false. This
means the attached power domains are not powered on during attachment.
>
> > - 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 | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> > index fed2fc9bb31108d51f88d34f3379c7744681f485..7369c291be51aa1ad7a330459dcb857f5a1988f6 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>
> > @@ -3334,6 +3335,8 @@ struct qmp_pcie {
> >
> > struct clk_fixed_rate pipe_clk_fixed;
> > struct clk_fixed_rate aux_clk_fixed;
> > +
> > + struct dev_pm_domain_list *pd_list;
>
> This is just an pointer to the list allocated inside
> devm_pm_domain_attach_list(), as far as I can tell you don't need to
> keep this in the qmp_pcie struct - as you're not using it anyways.
Okay, will remove this part in next version.
- Qiang Yu
>
> Regards,
> Bjorn
>
> > };
> >
> > static bool qphy_checkbits(const void __iomem *base, u32 offset, u32 val)
> > @@ -5348,6 +5351,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, &qmp->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
* Re: [PATCH phy-next 05/22] phy: add <linux/pm_runtime.h> where missing
From: Geert Uytterhoeven @ 2026-03-05 7:45 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-sunxi,
linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver,
Peter Griffin, André Draszik, Tudor Ambarus,
Geert Uytterhoeven, Magnus Damm, Heiko Stuebner
In-Reply-To: <20260304175735.2660419-6-vladimir.oltean@nxp.com>
On Wed, 4 Mar 2026 at 19:00, Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
> It appears that the phy-mapphone-mdm6600, phy-qcom-snps-femto-v2,
> phy-rcar-gen3-pcie, r8a779f0-ether-serdes and phy-rockchip-typec drivers
> call runtime PM operations without including the proper header.
>
> This was provided by <linux/phy/phy.h> but no function exported by this
> header directly needs it. So we need to drop it from there, and fix up
> drivers that used to depend on that.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> drivers/phy/renesas/phy-rcar-gen3-pcie.c | 1 +
> drivers/phy/renesas/r8a779f0-ether-serdes.c | 1 +
For the Renesas parts:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox