* Re: [PATCH v2 9/9] arm64: dts: renesas: ebisu: Describe PCIe/USB3.0 clock generator
From: Marek Vasut @ 2026-01-22 10:56 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Brown, linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski,
Magnus Damm, Neil Armstrong, Rob Herring, Vinod Koul,
Yoshihiro Shimoda, devicetree, linux-phy, linux-renesas-soc
In-Reply-To: <CAMuHMdX0iuyUhGRPFf4x==e_ZEMjaB_dP6mrM81F+yxqwam0FA@mail.gmail.com>
On 1/22/26 11:24 AM, Geert Uytterhoeven wrote:
Hello Geert,
>> This piece of code in drivers/usb/phy/phy-generic.c [1] shouldn't fail
>> the probe if "vbus-supply" property is not present in DT. If
>> "vbus-supply" property is not present in DT, then
>> PTR_ERR(nop->vbus_draw) == -ENODEV is true, nop->vbus_draw will be set
>> to NULL, but won't encode error, so the dev_err_probe() won't trigger.
>>
>> "
>> 259 nop->vbus_draw = devm_regulator_get_exclusive(dev, "vbus");
>> 260 if (PTR_ERR(nop->vbus_draw) == -ENODEV)
>> 261 nop->vbus_draw = NULL;
>> 262 if (IS_ERR(nop->vbus_draw))
>> 263 return dev_err_probe(dev, PTR_ERR(nop->vbus_draw),
>> 264 "could not get vbus regulator\n");
>> "
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/phy/phy-generic.c#n259
>
> Sorry, you are right. I missed the PHY driver ignores the error and
> probes successfully, and thus didn't bother doing "echo ee000000.usb >
> /sys/bus/platform/drivers/xhci-renesas-hcd/bind" after /lib/firmware
> became available.
Is any change needed to this series then ?
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [net-next,05/14] net: stmmac: add stmmac core serdes support
From: Vladimir Oltean @ 2026-01-22 11:29 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Jakub Kicinski, linux-phy, davem, maxime.chevallier,
alexandre.torgue, mohd.anwar, neil.armstrong, hkallweit1,
mcoquelin.stm32, netdev, edumazet, linux-arm-msm,
linux-arm-kernel, vkoul, andrew, pabeni, andrew+netdev,
linux-stm32
In-Reply-To: <aXEN6B5_T9uFzVvu@shell.armlinux.org.uk>
On Wed, Jan 21, 2026 at 05:33:28PM +0000, Russell King (Oracle) wrote:
> On Wed, Jan 21, 2026 at 06:23:45PM +0200, Vladimir Oltean wrote:
> > On Wed, Jan 21, 2026 at 02:46:42PM +0000, Russell King (Oracle) wrote:
> > > On Tue, Jan 20, 2026 at 02:11:14PM +0200, Vladimir Oltean wrote:
> > > > On Tue, Jan 20, 2026 at 10:12:46AM +0000, Russell King (Oracle) wrote:
> > > > > First, I'll say I'm on a very short fuse today; no dinner last night,
> > > > > at the hospital up until 5:30am, and a fucking cold caller rang the door
> > > > > bell at 10am this morning. Just fucking our luck.
> > > >
> > > > Sorry to hear that.
> > > >
> > > > > On Tue, Jan 20, 2026 at 10:18:44AM +0200, Vladimir Oltean wrote:
> > > > > > Isn't it sufficient to set pl->pcs to NULL when pcs_enable() fails and
> > > > > > after calling pcs_disable(), though?
> > > > >
> > > > > No. We've already called mac_prepare(), pcs_pre_config(),
> > > > > pcs_post_config() by this time, we're past the point of being able to
> > > > > unwind.
> > > >
> > > > I'm set out to resolve a much smaller problem.
> > > >
> > > > Calling it a full "unwind" is perhaps a bit much, because pcs_pre_config()
> > > > and pcs_post_config() don't have unwinding equivalents, unlike how
> > > > pcs_enable() has pcs_disable(). I don't see what API convention would be
> > > > violated if phylink decided to drop a PCS whose enable() returned an error.
> > >
> > > While pcs_pre_config() and pcs_post_config() do not have unwinding
> > > equivalents (what would they be?) the issue here is that these could
> > > have changed any state that isn't simply undone by calling
> > > pcs_disable().
> > >
> > > For example, pcs_pre_config() could have reprogrammed signal routing,
> > > clocking, or power supplies to blocks.
> > >
> > > This already applies to Marvell DSA pcs-639x.c, where the pre/post
> > > config hooks change the power state of the PCS block (for errata
> > > handling), and the only way that gets undone is via a call to
> > > pcs_disable() which explicitly disables IRQs and power for the PCS. Its
> > > pcs_disable() isn't a strict reversal of pcs_enable(), it does more.
> > >
> > > We already declare the interface to be dead on pcs_post_config()
> > > failure, but we don't do that for pcs_enable() failure.
> > >
> > > Maybe I need to explicitly state that pcs_disable() does not directly
> > > balance pcs_enable(), but that _and_ the effects of pcs_pre_config()
> > > and pcs_post_config(). However, that itself will add to the problems.
> > > What if pcs_pre_config() and pcs_post_config() succeed but not
> > > pcs_enable()? pcs-639x needs pcs_disable() to be called, but if we
> > > require pcs_disable() to be balanced with a successful call to
> > > pcs_enable(), that messes up that driver, and pretty much makes it
> > > impossible to work around the errata.
> >
> > What if we reordered phylink_major_config() such that phylink_pcs_enable()
> > comes first, followed by phylink_pcs_pre_config() -> phylink_mac_config() ->
> > phylink_pcs_post_config()? Superficially looking at pcs-639x, I don't
> > think it would break.
>
> I'm sorry, but I don't have time to continue this discussion today. I
> woke late, we're trying to cram in the meals (in the middle of delayed
> lunch-time dinner right now), work wants a quick call to discuss a
> project that I missed the meeting for yesterday (which I haven't yet
> had time for...)
>
> Sorry, but while you may wish to get this sorted, for me this is a very
> low priority issue that can be addressed later. Don't think I will have
> time to review anything you send - and that's not a personal attack,
> it's because I'm barely managing to hold everything together at my
> end, and I don't have the time.
Thanks, this was a good talk, I understood a bit more about the
challenges that need to be overcome. I'll do some testing on the
Turris MOX with a 6390 switch. From my side this shouldn't block the
stmmac integrated PCS from being integrated with the SerDes, but I do
agree that leaving a comment explaining the current phylink_pcs calling
convention, as Jakub requested, would be very useful.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH next] phy: google: fix build dependency for Google Tensor USB PHY
From: André Draszik @ 2026-01-22 10:39 UTC (permalink / raw)
To: Roy Luo, Vinod Koul, Neil Armstrong, Peter Griffin, Tudor Ambarus,
Joy Chakraborty, Naveen Kumar
Cc: linux-phy, linux-kernel, linux-arm-kernel, linux-samsung-soc,
kernel test robot
In-Reply-To: <20260121-next-v1-1-c18068b091b9@google.com>
Hi Roy,
On Wed, 2026-01-21 at 22:21 +0000, Roy Luo wrote:
> The Google Tensor USB PHY driver uses the Type-C switch framework to
> handle orientation changes. However, the Kconfig did not specify a
> dependency on the TYPEC framework, leading to undefined reference
> errors when building for architectures or configurations where
> CONFIG_TYPEC is disabled or configured as a module.
>
> Add 'depends on TYPEC' to the PHY_GOOGLE_USB entry to ensure all
> required symbols are available during linking.
>
> Fixes: cbce66669c82 ("phy: Add Google Tensor SoC USB PHY driver")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202601210825.ELrpQeED-lkp@intel.com/
> Signed-off-by: Roy Luo <royluo@google.com>
> ---
> drivers/phy/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 142e7b0ef2efb9209781800ee47b820a91b115ae..5531ff31d8156cb164c32e3e52d4a57b26a62d8d 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -49,6 +49,7 @@ config GENERIC_PHY_MIPI_DPHY
>
> config PHY_GOOGLE_USB
> tristate "Google Tensor SoC USB PHY driver"
> + depends on TYPEC
Can you make this
depends on TYPEC || COMPILE_TEST
to allow some better test coverage?
Cheers,
Andre
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 9/9] arm64: dts: renesas: ebisu: Describe PCIe/USB3.0 clock generator
From: Geert Uytterhoeven @ 2026-01-22 10:24 UTC (permalink / raw)
To: Marek Vasut
Cc: Mark Brown, linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski,
Magnus Damm, Neil Armstrong, Rob Herring, Vinod Koul,
Yoshihiro Shimoda, devicetree, linux-phy, linux-renesas-soc
In-Reply-To: <6f817993-1b4a-4600-a771-d6c25efc668b@mailbox.org>
Hi Marek,
On Wed, 21 Jan 2026 at 23:44, Marek Vasut <marek.vasut@mailbox.org> wrote:
> On 1/21/26 2:48 PM, Geert Uytterhoeven wrote:
> >> @@ -871,7 +902,19 @@ &usb2_phy0 {
> >> status = "okay";
> >> };
> >>
> >> +&usb3_phy0 {
> >> + clocks = <&pcie_usb_clk 6>;
> >> + status = "okay";
> >> +};
> >
> > This does not work, probing fails with:
> >
> > usb_phy_generic usb-phy: dummy supplies not allowed for exclusive
> > requests (id=vbus)
> >
> > Adding a fixed regulator that serves as vbus-supply like in commit
> > fec2d8fcdedaeeb0 ("arm64: dts: freescale: imx93-phyboard-nash: Add USB
> > vbus regulators") fixes that issue (and my USB3.0 FLASH driver is
> > detected, yeah!), but a more accurate description would be better.
>
> This piece of code in drivers/usb/phy/phy-generic.c [1] shouldn't fail
> the probe if "vbus-supply" property is not present in DT. If
> "vbus-supply" property is not present in DT, then
> PTR_ERR(nop->vbus_draw) == -ENODEV is true, nop->vbus_draw will be set
> to NULL, but won't encode error, so the dev_err_probe() won't trigger.
>
> "
> 259 nop->vbus_draw = devm_regulator_get_exclusive(dev, "vbus");
> 260 if (PTR_ERR(nop->vbus_draw) == -ENODEV)
> 261 nop->vbus_draw = NULL;
> 262 if (IS_ERR(nop->vbus_draw))
> 263 return dev_err_probe(dev, PTR_ERR(nop->vbus_draw),
> 264 "could not get vbus regulator\n");
> "
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/phy/phy-generic.c#n259
Sorry, you are right. I missed the PHY driver ignores the error and
probes successfully, and thus didn't bother doing "echo ee000000.usb >
/sys/bus/platform/drivers/xhci-renesas-hcd/bind" after /lib/firmware
became available.
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 v3 3/6] drm/sun4i: Enable LVDS output on sun20i D1s/T113
From: Parthiban @ 2026-01-22 10:22 UTC (permalink / raw)
To: Kuba Szczodrzyński, Maxime Ripard, Samuel Holland,
Chen-Yu Tsai, Jernej Skrabec, Maarten Lankhorst,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: parthiban, David Airlie, Simona Vetter, linux-arm-kernel,
linux-sunxi, linux-kernel, linux-riscv, linux-phy, devicetree,
dri-devel, paulk
In-Reply-To: <20251116134835.447357-1-kuba@szczodrzynski.pl>
Dear Kuba,
On 11/16/25 2:48 PM, Kuba Szczodrzyński wrote:
> +static void sun20i_tcon_setup_lvds_dphy(struct sun4i_tcon *tcon,
> + const struct drm_encoder *encoder)
> +{
> + union phy_configure_opts opts = { };
> +
> + if (!tcon->quirks->has_combo_dphy || !tcon->dphy)
> + return;
> +
> + if (phy_init(tcon->dphy))
> + return;
> +
> + if (phy_set_mode(tcon->dphy, PHY_MODE_LVDS))
From Documentation/driver-api/phy/phy.rst, set_mode shall be after power_on. But re-order
will fail to work for our case. Not sure if this is fine.
Thanks,
Parthiban
> + return;
> +
> + if (phy_configure(tcon->dphy, &opts))
> + return;
> +
> + if (phy_power_on(tcon->dphy))
> + return;
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 1/6] phy: allwinner: phy-sun6i-mipi-dphy: Support LVDS in combo D-PHY
From: Parthiban @ 2026-01-22 10:15 UTC (permalink / raw)
To: Kuba Szczodrzyński, Maxime Ripard, Samuel Holland,
Chen-Yu Tsai, Jernej Skrabec, Maarten Lankhorst,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: parthiban, David Airlie, Simona Vetter, linux-arm-kernel,
linux-sunxi, linux-kernel, linux-riscv, linux-phy, devicetree,
dri-devel, paulk
In-Reply-To: <20251116134724.447131-1-kuba@szczodrzynski.pl>
Dear Kuba,
On 11/16/25 2:47 PM, Kuba Szczodrzyński wrote:
> Some Allwinner chips (notably the D1s/T113 and the A100) have a "combo
> MIPI DSI D-PHY" which is required when using single-link LVDS0.
>
> In this mode, the DSI peripheral is not used and the PHY is not
> configured for DSI. Instead, the COMBO_PHY_REGx registers are set to
> enable LVDS operation.
>
> Enable the PHY driver to work in LVDS mode on chips with a combo D-PHY.
>
> Also change the SUN50I_COMBO_PHY_REG1 macro names to reflect the correct
> register name.
>
> Signed-off-by: Kuba Szczodrzyński <kuba@szczodrzynski.pl>
> ---
> drivers/phy/allwinner/phy-sun6i-mipi-dphy.c | 70 ++++++++++++++++++++-
> 1 file changed, 68 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c b/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
> index 36eab9527..57035b3a4 100644
> --- a/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
> +++ b/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
> @@ -166,8 +166,8 @@
> #define SUN50I_COMBO_PHY_REG0_EN_CP BIT(0)
>
> #define SUN50I_COMBO_PHY_REG1 0x114
> -#define SUN50I_COMBO_PHY_REG2_REG_VREF1P6(n) (((n) & 0x7) << 4)
> -#define SUN50I_COMBO_PHY_REG2_REG_VREF0P8(n) ((n) & 0x7)
> +#define SUN50I_COMBO_PHY_REG1_REG_VREF1P6(n) (((n) & 0x7) << 4)
> +#define SUN50I_COMBO_PHY_REG1_REG_VREF0P8(n) ((n) & 0x7)
>
> #define SUN50I_COMBO_PHY_REG2 0x118
> #define SUN50I_COMBO_PHY_REG2_HS_STOP_DLY(n) ((n) & 0xff)
> @@ -181,7 +181,9 @@ struct sun6i_dphy;
>
> struct sun6i_dphy_variant {
> void (*tx_power_on)(struct sun6i_dphy *dphy);
> + void (*lvds_power_on)(struct sun6i_dphy *dphy);
> bool rx_supported;
> + bool is_combo_dphy;
> };
>
> struct sun6i_dphy {
> @@ -222,6 +224,18 @@ static int sun6i_dphy_configure(struct phy *phy, union phy_configure_opts *opts)
> return 0;
> }
>
> +static int sun6i_dphy_set_mode(struct phy *phy, enum phy_mode mode, int submode)
> +{
> + struct sun6i_dphy *dphy = phy_get_drvdata(phy);
> +
> + if (mode == PHY_MODE_LVDS && !dphy->variant->is_combo_dphy) {
At this stage mode will be PHY_MODE_INVALID by default. So the consumer fails with set_mode by
default.
IMO set_mode shall set
+ dphy->mode = mode;
+ dphy->submode = submode;
in the sun6i_dphy and retain for the next calls like power on.
> + /* Not a combo D-PHY: LVDS is not supported. */
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> static void sun6i_a31_mipi_dphy_tx_power_on(struct sun6i_dphy *dphy)
> {
> u8 lanes_mask = GENMASK(dphy->config.lanes - 1, 0);
> @@ -329,6 +343,43 @@ static void sun50i_a100_mipi_dphy_tx_power_on(struct sun6i_dphy *dphy)
> udelay(1);
> }
>
> +static void sun50i_a100_mipi_dphy_lvds_power_on(struct sun6i_dphy *dphy)
> +{
> + regmap_write(dphy->regs, SUN50I_COMBO_PHY_REG1,
> + SUN50I_COMBO_PHY_REG1_REG_VREF1P6(4) |
> + SUN50I_COMBO_PHY_REG1_REG_VREF0P8(3));
> +
> + regmap_write(dphy->regs, SUN50I_COMBO_PHY_REG0,
> + SUN50I_COMBO_PHY_REG0_EN_CP);
> + udelay(5);
> +
> + regmap_update_bits(dphy->regs, SUN50I_COMBO_PHY_REG0,
> + SUN50I_COMBO_PHY_REG0_EN_LVDS,
> + SUN50I_COMBO_PHY_REG0_EN_LVDS);
> + udelay(5);
> +
> + regmap_update_bits(dphy->regs, SUN50I_COMBO_PHY_REG0,
> + SUN50I_COMBO_PHY_REG0_EN_COMBOLDO,
> + SUN50I_COMBO_PHY_REG0_EN_COMBOLDO);
> + udelay(5);
> +
> + regmap_update_bits(dphy->regs, SUN50I_COMBO_PHY_REG0,
> + SUN50I_COMBO_PHY_REG0_EN_MIPI,
> + SUN50I_COMBO_PHY_REG0_EN_MIPI);
> +
> + regmap_write(dphy->regs, SUN6I_DPHY_ANA4_REG,
> + SUN6I_DPHY_ANA4_REG_EN_MIPI |
> + SUN6I_DPHY_ANA4_REG_IB(2));
> +
> + regmap_write(dphy->regs, SUN6I_DPHY_ANA3_REG,
> + SUN6I_DPHY_ANA3_EN_LDOR |
> + SUN6I_DPHY_ANA3_EN_LDOD);
> +
> + regmap_write(dphy->regs, SUN6I_DPHY_ANA2_REG, 0);
> +
> + regmap_write(dphy->regs, SUN6I_DPHY_ANA1_REG, 0);
> +}
> +
> static int sun6i_dphy_tx_power_on(struct sun6i_dphy *dphy)
> {
> u8 lanes_mask = GENMASK(dphy->config.lanes - 1, 0);
> @@ -492,6 +543,13 @@ static int sun6i_dphy_power_on(struct phy *phy)
> {
> struct sun6i_dphy *dphy = phy_get_drvdata(phy);
>
> + if (phy->attrs.mode == PHY_MODE_LVDS && dphy->variant->is_combo_dphy) {
+ if (dphy->mode == PHY_MODE_LVDS && dphy->variant->is_combo_dphy) {
compared like this.
Thanks,
Parthiban
> + if (!dphy->variant->lvds_power_on)
> + return -EINVAL;
> + dphy->variant->lvds_power_on(dphy);
> + return 0;
> + }
> +
> switch (dphy->direction) {
> case SUN6I_DPHY_DIRECTION_TX:
> return sun6i_dphy_tx_power_on(dphy);
> @@ -514,6 +572,11 @@ static int sun6i_dphy_power_off(struct phy *phy)
> regmap_write(dphy->regs, SUN6I_DPHY_ANA3_REG, 0);
> regmap_write(dphy->regs, SUN6I_DPHY_ANA4_REG, 0);
>
> + if (phy->attrs.mode == PHY_MODE_LVDS && dphy->variant->is_combo_dphy) {
> + regmap_write(dphy->regs, SUN50I_COMBO_PHY_REG1, 0);
> + regmap_write(dphy->regs, SUN50I_COMBO_PHY_REG0, 0);
> + }
> +
> return 0;
> }
>
> @@ -533,6 +596,7 @@ static const struct phy_ops sun6i_dphy_ops = {
> .configure = sun6i_dphy_configure,
> .power_on = sun6i_dphy_power_on,
> .power_off = sun6i_dphy_power_off,
> + .set_mode = sun6i_dphy_set_mode,
> .init = sun6i_dphy_init,
> .exit = sun6i_dphy_exit,
> };
> @@ -619,6 +683,8 @@ static const struct sun6i_dphy_variant sun6i_a31_mipi_dphy_variant = {
>
> static const struct sun6i_dphy_variant sun50i_a100_mipi_dphy_variant = {
> .tx_power_on = sun50i_a100_mipi_dphy_tx_power_on,
> + .lvds_power_on = sun50i_a100_mipi_dphy_lvds_power_on,
> + .is_combo_dphy = true,
> };
>
> static const struct of_device_id sun6i_dphy_of_table[] = {
--
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: Krishna Chaitanya Chundru @ 2026-01-22 8:59 UTC (permalink / raw)
To: Dmitry Baryshkov
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: <woztsrvxwkgi34z3yop7nja6ojbxdboyzz5xpz4xlym75dtyja@iopi7hvw42v7>
On 1/9/2026 6:39 PM, Dmitry Baryshkov wrote:
> 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?
As mentioned in the cover letter we are not trusting every platform boot
loaders,
which have initialized the controller to max speed. That is we are
restricting them to
only for this platform.
- Krishna Chaitanya.
>> 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
>>
--
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: Krishna Chaitanya Chundru @ 2026-01-22 8:55 UTC (permalink / raw)
To: Bjorn Helgaas
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: <20260109155350.GA546142@bhelgaas>
On 1/9/2026 9:23 PM, Bjorn Helgaas wrote:
> 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().
Yes the bootloader is expected to do everything what dw_pcie_setup_r()
does.
> 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.
As the devicetree changes already pointing to different address from the
boatloader,
I was trying use this method. As changing device tree properties now
might not
be good, but no harm in doing so. I can skip this and make device tree
changes.
> Is there something in dw_pcie_setup_rc() that takes a lot of time or
> forces a link retrain?
I don't think it might not take much time as it is few register writes,
Just doesn't
want to do redundant register writes which are costly in general.
> 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.
The clock and GENPD issues have no direct relation ship with
dw_pcie_setup_r(). we are skipping them as they are redundant. I will
add a comment in next series on this. - Krishna Chaitanya.
>> 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
* Re: [PATCH v6 2/7] mux: Add helper functions for getting optional and selected mux-state
From: Dan Carpenter @ 2026-01-22 6:17 UTC (permalink / raw)
To: oe-kbuild, Josua Mayer, Marc Kleine-Budde, Vincent Mailhol,
Vinod Koul, Neil Armstrong, Peter Rosin, Aaro Koskinen,
Andreas Kemnade, Kevin Hilman, Roger Quadros, Tony Lindgren,
Janusz Krzysztofik, Vignesh R, Andi Shyti, Ulf Hansson,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Wolfram Sang
Cc: lkp, oe-kbuild-all, Yazan Shhady, Jon Nettleton, Mikhail Anikin,
linux-can, linux-phy, linux-kernel, linux-omap, linux-i2c,
linux-mmc, devicetree
In-Reply-To: <20260121-rz-sdio-mux-v6-2-38aa39527928@solid-run.com>
Hi Josua,
kernel test robot noticed the following build warnings:
url: https://github.com/intel-lab-lkp/linux/commits/Josua-Mayer/phy-can-transceiver-rename-temporary-helper-function-to-avoid-conflict/20260121-173607
base: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
patch link: https://lore.kernel.org/r/20260121-rz-sdio-mux-v6-2-38aa39527928%40solid-run.com
patch subject: [PATCH v6 2/7] mux: Add helper functions for getting optional and selected mux-state
config: arm64-randconfig-r073-20260121 (https://download.01.org/0day-ci/archive/20260122/202601221036.J0kR78Uw-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 8.5.0
smatch version: v0.5.0-8985-g2614ff1a
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>
| Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
| Closes: https://lore.kernel.org/r/202601221036.J0kR78Uw-lkp@intel.com/
New smatch warnings:
drivers/mux/core.c:776 __devm_mux_state_get() warn: passing zero to 'PTR_ERR'
drivers/mux/core.c:796 __devm_mux_state_get() warn: passing zero to 'ERR_PTR'
Old smatch warnings:
drivers/mux/core.c:722 mux_state_get() warn: passing zero to 'ERR_CAST'
vim +/PTR_ERR +776 drivers/mux/core.c
0610cc3159b786 Josua Mayer 2026-01-21 761 static struct mux_state *__devm_mux_state_get(struct device *dev, const char *mux_name,
0610cc3159b786 Josua Mayer 2026-01-21 762 bool optional,
0610cc3159b786 Josua Mayer 2026-01-21 763 int (*init)(struct mux_state *mstate),
0610cc3159b786 Josua Mayer 2026-01-21 764 int (*exit)(struct mux_state *mstate))
0610cc3159b786 Josua Mayer 2026-01-21 765 {
0610cc3159b786 Josua Mayer 2026-01-21 766 struct devm_mux_state_state *devm_state;
0610cc3159b786 Josua Mayer 2026-01-21 767 struct mux_state *mstate;
0610cc3159b786 Josua Mayer 2026-01-21 768 int ret;
84564481bc4520 Aswath Govindraju 2022-01-07 769
0610cc3159b786 Josua Mayer 2026-01-21 770 devm_state = devres_alloc(devm_mux_state_release, sizeof(*devm_state), GFP_KERNEL);
0610cc3159b786 Josua Mayer 2026-01-21 771 if (!devm_state)
0610cc3159b786 Josua Mayer 2026-01-21 772 return ERR_PTR(-ENOMEM);
0610cc3159b786 Josua Mayer 2026-01-21 773
0610cc3159b786 Josua Mayer 2026-01-21 774 mstate = mux_state_get(dev, mux_name, optional);
0610cc3159b786 Josua Mayer 2026-01-21 775 if (IS_ERR_OR_NULL(mstate)) {
Please, change this to if (IS_ERR(mstate)) {. The mux_state_get() never
returns NULL. I have written a blog about functions which return both
error pointers and NULL.
https://staticthinking.wordpress.com/2022/08/01/mixing-error-pointers-and-null/
0610cc3159b786 Josua Mayer 2026-01-21 @776 ret = PTR_ERR(mstate);
0610cc3159b786 Josua Mayer 2026-01-21 777 goto err_mux_state_get;
0610cc3159b786 Josua Mayer 2026-01-21 778 }
0610cc3159b786 Josua Mayer 2026-01-21 779
0610cc3159b786 Josua Mayer 2026-01-21 780 if (init) {
0610cc3159b786 Josua Mayer 2026-01-21 781 ret = init(mstate);
0610cc3159b786 Josua Mayer 2026-01-21 782 if (ret)
0610cc3159b786 Josua Mayer 2026-01-21 783 goto err_mux_state_init;
0610cc3159b786 Josua Mayer 2026-01-21 784 }
0610cc3159b786 Josua Mayer 2026-01-21 785
0610cc3159b786 Josua Mayer 2026-01-21 786 devm_state->mstate = mstate;
0610cc3159b786 Josua Mayer 2026-01-21 787 devm_state->exit = exit;
0610cc3159b786 Josua Mayer 2026-01-21 788 devres_add(dev, devm_state);
0610cc3159b786 Josua Mayer 2026-01-21 789
0610cc3159b786 Josua Mayer 2026-01-21 790 return mstate;
0610cc3159b786 Josua Mayer 2026-01-21 791
0610cc3159b786 Josua Mayer 2026-01-21 792 err_mux_state_init:
84564481bc4520 Aswath Govindraju 2022-01-07 793 mux_state_put(mstate);
0610cc3159b786 Josua Mayer 2026-01-21 794 err_mux_state_get:
0610cc3159b786 Josua Mayer 2026-01-21 795 devres_free(devm_state);
0610cc3159b786 Josua Mayer 2026-01-21 @796 return ERR_PTR(ret);
84564481bc4520 Aswath Govindraju 2022-01-07 797 }
--
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 next] phy: google: fix build dependency for Google Tensor USB PHY
From: Peter Griffin @ 2026-01-21 23:06 UTC (permalink / raw)
To: Roy Luo
Cc: Vinod Koul, Neil Armstrong, André Draszik, Tudor Ambarus,
Joy Chakraborty, Naveen Kumar, linux-phy, linux-kernel,
linux-arm-kernel, linux-samsung-soc, kernel test robot
In-Reply-To: <20260121-next-v1-1-c18068b091b9@google.com>
On Wed, 21 Jan 2026 at 22:21, Roy Luo <royluo@google.com> wrote:
>
> The Google Tensor USB PHY driver uses the Type-C switch framework to
> handle orientation changes. However, the Kconfig did not specify a
> dependency on the TYPEC framework, leading to undefined reference
> errors when building for architectures or configurations where
> CONFIG_TYPEC is disabled or configured as a module.
>
> Add 'depends on TYPEC' to the PHY_GOOGLE_USB entry to ensure all
> required symbols are available during linking.
>
> Fixes: cbce66669c82 ("phy: Add Google Tensor SoC USB PHY driver")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202601210825.ELrpQeED-lkp@intel.com/
> Signed-off-by: Roy Luo <royluo@google.com>
> ---
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
> drivers/phy/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 142e7b0ef2efb9209781800ee47b820a91b115ae..5531ff31d8156cb164c32e3e52d4a57b26a62d8d 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -49,6 +49,7 @@ config GENERIC_PHY_MIPI_DPHY
>
> config PHY_GOOGLE_USB
> tristate "Google Tensor SoC USB PHY driver"
> + depends on TYPEC
> select GENERIC_PHY
> help
> Enable support for the USB PHY on Google Tensor SoCs, starting with
>
> ---
> base-commit: 8bb92fd7a04077925c8330f46a6ab44c80ca59f4
> change-id: 20260121-next-b949189cacf4
>
> Best regards,
> --
> Roy Luo <royluo@google.com>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 00/27] clk: remove deprecated API divider_round_rate() and friends
From: Brian Masney @ 2026-01-21 22:53 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
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, Bjorn Andersson, 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>
Hi Stephen,
On Thu, Jan 08, 2026 at 04:16:18PM -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.
I sent you a GIT PULL for what can go to Linus for the upcoming merge
window from this series:
https://lore.kernel.org/linux-clk/aXFYU324yQ6uBmk0@redhat.com/T/#u
Thanks,
Brian
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 9/9] arm64: dts: renesas: ebisu: Describe PCIe/USB3.0 clock generator
From: Marek Vasut @ 2026-01-21 17:38 UTC (permalink / raw)
To: Geert Uytterhoeven, Mark Brown
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Neil Armstrong, Rob Herring,
Vinod Koul, Yoshihiro Shimoda, devicetree, linux-phy,
linux-renesas-soc
In-Reply-To: <CAMuHMdWfkHMQFvUzaHpso-fMFAS5u8ABHpEA9ZXq1fxcR-oN6Q@mail.gmail.com>
On 1/21/26 2:48 PM, Geert Uytterhoeven wrote:
Hello Geert,
>> @@ -439,6 +445,13 @@ adv7511_out: endpoint {
>> };
>> };
>>
>> + pcie_usb_clk: clk@68 {
>> + compatible = "renesas,9fgv0841";
>> + reg = <0x68>;
>> + clocks = <&pcie_usb_refclk>;
>> + #clock-cells = <1>;
>> + };
>
> During boot, the rs9 prints a warning:
>
> clk-renesas-pcie-9series 0-0068: No cache defaults, reading back from HW
>
> which probably shouldn't be printed at the warning level?
+CC Mark . Reading the (default) register values from hardware on first
boot is the valid/right thing to do, so this could be demoted to
dev_dbg() . Or is there some specific usecase where this should be a
warning ?
>> +
>> video-receiver@70 {
>> compatible = "adi,adv7482";
>> reg = <0x70>;
>
>> @@ -871,7 +902,19 @@ &usb2_phy0 {
>> status = "okay";
>> };
>>
>> +&usb3_phy0 {
>> + clocks = <&pcie_usb_clk 6>;
>> + status = "okay";
>> +};
>
> This does not work, probing fails with:
>
> usb_phy_generic usb-phy: dummy supplies not allowed for exclusive
> requests (id=vbus)
>
> Adding a fixed regulator that serves as vbus-supply like in commit
> fec2d8fcdedaeeb0 ("arm64: dts: freescale: imx93-phyboard-nash: Add USB
> vbus regulators") fixes that issue (and my USB3.0 FLASH driver is
> detected, yeah!), but a more accurate description would be better.
This piece of code in drivers/usb/phy/phy-generic.c [1] shouldn't fail
the probe if "vbus-supply" property is not present in DT. If
"vbus-supply" property is not present in DT, then
PTR_ERR(nop->vbus_draw) == -ENODEV is true, nop->vbus_draw will be set
to NULL, but won't encode error, so the dev_err_probe() won't trigger.
"
259 nop->vbus_draw = devm_regulator_get_exclusive(dev, "vbus");
260 if (PTR_ERR(nop->vbus_draw) == -ENODEV)
261 nop->vbus_draw = NULL;
262 if (IS_ERR(nop->vbus_draw))
263 return dev_err_probe(dev, PTR_ERR(nop->vbus_draw),
264 "could not get vbus regulator\n");
"
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/phy/phy-generic.c#n259
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH next] phy: google: fix build dependency for Google Tensor USB PHY
From: Roy Luo @ 2026-01-21 22:21 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Peter Griffin, André Draszik,
Tudor Ambarus, Joy Chakraborty, Naveen Kumar
Cc: linux-phy, linux-kernel, linux-arm-kernel, linux-samsung-soc,
kernel test robot, Roy Luo
The Google Tensor USB PHY driver uses the Type-C switch framework to
handle orientation changes. However, the Kconfig did not specify a
dependency on the TYPEC framework, leading to undefined reference
errors when building for architectures or configurations where
CONFIG_TYPEC is disabled or configured as a module.
Add 'depends on TYPEC' to the PHY_GOOGLE_USB entry to ensure all
required symbols are available during linking.
Fixes: cbce66669c82 ("phy: Add Google Tensor SoC USB PHY driver")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202601210825.ELrpQeED-lkp@intel.com/
Signed-off-by: Roy Luo <royluo@google.com>
---
drivers/phy/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 142e7b0ef2efb9209781800ee47b820a91b115ae..5531ff31d8156cb164c32e3e52d4a57b26a62d8d 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -49,6 +49,7 @@ config GENERIC_PHY_MIPI_DPHY
config PHY_GOOGLE_USB
tristate "Google Tensor SoC USB PHY driver"
+ depends on TYPEC
select GENERIC_PHY
help
Enable support for the USB PHY on Google Tensor SoCs, starting with
---
base-commit: 8bb92fd7a04077925c8330f46a6ab44c80ca59f4
change-id: 20260121-next-b949189cacf4
Best regards,
--
Roy Luo <royluo@google.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [net-next,05/14] net: stmmac: add stmmac core serdes support
From: Russell King (Oracle) @ 2026-01-21 17:33 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Jakub Kicinski, linux-phy, davem, maxime.chevallier,
alexandre.torgue, mohd.anwar, neil.armstrong, hkallweit1,
mcoquelin.stm32, netdev, edumazet, linux-arm-msm,
linux-arm-kernel, vkoul, andrew, pabeni, andrew+netdev,
linux-stm32
In-Reply-To: <20260121162345.4jpzvwqhfqxd7tl7@skbuf>
On Wed, Jan 21, 2026 at 06:23:45PM +0200, Vladimir Oltean wrote:
> On Wed, Jan 21, 2026 at 02:46:42PM +0000, Russell King (Oracle) wrote:
> > On Tue, Jan 20, 2026 at 02:11:14PM +0200, Vladimir Oltean wrote:
> > > On Tue, Jan 20, 2026 at 10:12:46AM +0000, Russell King (Oracle) wrote:
> > > > First, I'll say I'm on a very short fuse today; no dinner last night,
> > > > at the hospital up until 5:30am, and a fucking cold caller rang the door
> > > > bell at 10am this morning. Just fucking our luck.
> > >
> > > Sorry to hear that.
> > >
> > > > On Tue, Jan 20, 2026 at 10:18:44AM +0200, Vladimir Oltean wrote:
> > > > > Isn't it sufficient to set pl->pcs to NULL when pcs_enable() fails and
> > > > > after calling pcs_disable(), though?
> > > >
> > > > No. We've already called mac_prepare(), pcs_pre_config(),
> > > > pcs_post_config() by this time, we're past the point of being able to
> > > > unwind.
> > >
> > > I'm set out to resolve a much smaller problem.
> > >
> > > Calling it a full "unwind" is perhaps a bit much, because pcs_pre_config()
> > > and pcs_post_config() don't have unwinding equivalents, unlike how
> > > pcs_enable() has pcs_disable(). I don't see what API convention would be
> > > violated if phylink decided to drop a PCS whose enable() returned an error.
> >
> > While pcs_pre_config() and pcs_post_config() do not have unwinding
> > equivalents (what would they be?) the issue here is that these could
> > have changed any state that isn't simply undone by calling
> > pcs_disable().
> >
> > For example, pcs_pre_config() could have reprogrammed signal routing,
> > clocking, or power supplies to blocks.
> >
> > This already applies to Marvell DSA pcs-639x.c, where the pre/post
> > config hooks change the power state of the PCS block (for errata
> > handling), and the only way that gets undone is via a call to
> > pcs_disable() which explicitly disables IRQs and power for the PCS. Its
> > pcs_disable() isn't a strict reversal of pcs_enable(), it does more.
> >
> > We already declare the interface to be dead on pcs_post_config()
> > failure, but we don't do that for pcs_enable() failure.
> >
> > Maybe I need to explicitly state that pcs_disable() does not directly
> > balance pcs_enable(), but that _and_ the effects of pcs_pre_config()
> > and pcs_post_config(). However, that itself will add to the problems.
> > What if pcs_pre_config() and pcs_post_config() succeed but not
> > pcs_enable()? pcs-639x needs pcs_disable() to be called, but if we
> > require pcs_disable() to be balanced with a successful call to
> > pcs_enable(), that messes up that driver, and pretty much makes it
> > impossible to work around the errata.
>
> What if we reordered phylink_major_config() such that phylink_pcs_enable()
> comes first, followed by phylink_pcs_pre_config() -> phylink_mac_config() ->
> phylink_pcs_post_config()? Superficially looking at pcs-639x, I don't
> think it would break.
I'm sorry, but I don't have time to continue this discussion today. I
woke late, we're trying to cram in the meals (in the middle of delayed
lunch-time dinner right now), work wants a quick call to discuss a
project that I missed the meeting for yesterday (which I haven't yet
had time for...)
Sorry, but while you may wish to get this sorted, for me this is a very
low priority issue that can be addressed later. Don't think I will have
time to review anything you send - and that's not a personal attack,
it's because I'm barely managing to hold everything together at my
end, and I don't have the time.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: ti: phy-omap-usb2: Fix a reference leak in omap_usb2_probe()
From: Felix Gu @ 2026-01-21 17:18 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Greg Kroah-Hartman, Roger Quadros
Cc: linux-phy, linux-kernel, Felix Gu
In omap_usb2_probe(), control_node is obtained via of_parse_phandle(),
which increments the refcount.
Add a missing of_node_put() after of_find_device_by_node() to prevent
a reference leak.
Fixes: 478b6c7436c2 ("usb: phy: omap-usb2: Don't use omap_get_control_dev()")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/phy/ti/phy-omap-usb2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/ti/phy-omap-usb2.c b/drivers/phy/ti/phy-omap-usb2.c
index 1eb252604441..660df3181e4f 100644
--- a/drivers/phy/ti/phy-omap-usb2.c
+++ b/drivers/phy/ti/phy-omap-usb2.c
@@ -426,6 +426,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
}
control_pdev = of_find_device_by_node(control_node);
+ of_node_put(control_node);
if (!control_pdev) {
dev_err(&pdev->dev, "Failed to get control device\n");
return -EINVAL;
---
base-commit: 053966c344dbd346e71305f530e91ea77916189f
change-id: 20260122-phy-omap-usb2-0dff7b055d41
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [net-next,05/14] net: stmmac: add stmmac core serdes support
From: Vladimir Oltean @ 2026-01-21 16:23 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Jakub Kicinski, linux-phy, davem, maxime.chevallier,
alexandre.torgue, mohd.anwar, neil.armstrong, hkallweit1,
mcoquelin.stm32, netdev, edumazet, linux-arm-msm,
linux-arm-kernel, vkoul, andrew, pabeni, andrew+netdev,
linux-stm32
In-Reply-To: <aXDm0jVOYOZ9l6Wu@shell.armlinux.org.uk>
On Wed, Jan 21, 2026 at 02:46:42PM +0000, Russell King (Oracle) wrote:
> On Tue, Jan 20, 2026 at 02:11:14PM +0200, Vladimir Oltean wrote:
> > On Tue, Jan 20, 2026 at 10:12:46AM +0000, Russell King (Oracle) wrote:
> > > First, I'll say I'm on a very short fuse today; no dinner last night,
> > > at the hospital up until 5:30am, and a fucking cold caller rang the door
> > > bell at 10am this morning. Just fucking our luck.
> >
> > Sorry to hear that.
> >
> > > On Tue, Jan 20, 2026 at 10:18:44AM +0200, Vladimir Oltean wrote:
> > > > Isn't it sufficient to set pl->pcs to NULL when pcs_enable() fails and
> > > > after calling pcs_disable(), though?
> > >
> > > No. We've already called mac_prepare(), pcs_pre_config(),
> > > pcs_post_config() by this time, we're past the point of being able to
> > > unwind.
> >
> > I'm set out to resolve a much smaller problem.
> >
> > Calling it a full "unwind" is perhaps a bit much, because pcs_pre_config()
> > and pcs_post_config() don't have unwinding equivalents, unlike how
> > pcs_enable() has pcs_disable(). I don't see what API convention would be
> > violated if phylink decided to drop a PCS whose enable() returned an error.
>
> While pcs_pre_config() and pcs_post_config() do not have unwinding
> equivalents (what would they be?) the issue here is that these could
> have changed any state that isn't simply undone by calling
> pcs_disable().
>
> For example, pcs_pre_config() could have reprogrammed signal routing,
> clocking, or power supplies to blocks.
>
> This already applies to Marvell DSA pcs-639x.c, where the pre/post
> config hooks change the power state of the PCS block (for errata
> handling), and the only way that gets undone is via a call to
> pcs_disable() which explicitly disables IRQs and power for the PCS. Its
> pcs_disable() isn't a strict reversal of pcs_enable(), it does more.
>
> We already declare the interface to be dead on pcs_post_config()
> failure, but we don't do that for pcs_enable() failure.
>
> Maybe I need to explicitly state that pcs_disable() does not directly
> balance pcs_enable(), but that _and_ the effects of pcs_pre_config()
> and pcs_post_config(). However, that itself will add to the problems.
> What if pcs_pre_config() and pcs_post_config() succeed but not
> pcs_enable()? pcs-639x needs pcs_disable() to be called, but if we
> require pcs_disable() to be balanced with a successful call to
> pcs_enable(), that messes up that driver, and pretty much makes it
> impossible to work around the errata.
What if we reordered phylink_major_config() such that phylink_pcs_enable()
comes first, followed by phylink_pcs_pre_config() -> phylink_mac_config() ->
phylink_pcs_post_config()? Superficially looking at pcs-639x, I don't
think it would break.
If we did that, we'd effectively have to also call pcs_disable() when
pcs_post_config() fails, and that is semantically compatible with saying
that pcs_disable() is balanced with pcs_enable(). It also gives the
ability for drivers such as pcs-639x to unwind in pcs_disable() any
actions done in pcs_enable(), pcs_pre_config() or pcs_post_config().
Plus, it's more natural/useful from an API perspective to say
"the PCS has to be enabled in order for anything to be done with it",
rather than the current "first mac_config cycle runs with the PCS not
enabled; subsequent mac_config cycles run with the PCS enabled".
> If you feel strongly about this, then the only thing I can think of
> doing is to move this SerDes support out of stmmac and into phylink
> (which is a point I already raised in the cover message) so that
> its failure can be dealt with at the higher level, where we can
> ensure that phy_power_off() is balaced with phy_power_on(). However,
> that means pushing even more of the stmmac specific "we need the
> clocks running to access registers XYZ or reset" weirdness into
> phylink.
I think core phylink support for generic PHYs eventually makes sense,
but at this stage it's perhaps too early, there's too much we don't yet
know. I would wait at least until it's clear, with an upstream example,
that multiple generic PHYs per phylink instance are needed: 1 SerDes PHY
per lane (for 40GBase-R etc), plus 1 retimer PHY per lane direction.
Also how do those retimers differ from SerDes PHYs. At the very least,
the phy_validate() of SerDes PHYs should be additive w.r.t.
supported_interfaces, whereas the phy_validate() of retimers should be
subtractive.
Also, moving SerDes PHY into phylink only avoids the problem, but if the
PCS driver needs to allocate memory, it will return. I have downstream
patches for a software backplane AN/LT state machine in phylink_pcs,
which is allocated in pcs_enable() and freed in pcs_disable().
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v5 4/4] riscv: dts: canaan: Add syscon and USB nodes for K230
From: Jiayu Du @ 2026-01-21 14:55 UTC (permalink / raw)
To: vkoul, gregkh, conor
Cc: neil.armstrong, robh, krzk+dt, pjw, palmer, aou, alex,
jiayu.riscv, linux-phy, linux-usb, devicetree, linux-riscv,
linux-kernel
In-Reply-To: <20260121145526.14672-1-jiayu.riscv@isrc.iscas.ac.cn>
Add top syscon and USB PHY subdevice nodes, USB0/USB1 dwc2 controller
to K230 DTSI, and enable UART0 and USB0/USB1 in DshanPI DT.
Signed-off-by: Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
---
.../boot/dts/canaan/k230-canmv-dshanpi.dts | 17 +++++++++
arch/riscv/boot/dts/canaan/k230.dtsi | 35 +++++++++++++++++++
2 files changed, 52 insertions(+)
diff --git a/arch/riscv/boot/dts/canaan/k230-canmv-dshanpi.dts b/arch/riscv/boot/dts/canaan/k230-canmv-dshanpi.dts
index 4f95b534ee87..55197cfc25b4 100644
--- a/arch/riscv/boot/dts/canaan/k230-canmv-dshanpi.dts
+++ b/arch/riscv/boot/dts/canaan/k230-canmv-dshanpi.dts
@@ -80,3 +80,20 @@ &uart0 {
pinctrl-0 = <&uart0_pins>;
status = "okay";
};
+
+&usb0 {
+ vusb_d-supply = <&vdd_3v3>;
+ vusb_a-supply = <&vdd_1v8>;
+ status = "okay";
+};
+
+&usb1 {
+ dr_mode = "host";
+ vusb_d-supply = <&vdd_3v3>;
+ vusb_a-supply = <&vdd_1v8>;
+ status = "okay";
+};
+
+&usbphy {
+ status = "okay";
+};
diff --git a/arch/riscv/boot/dts/canaan/k230.dtsi b/arch/riscv/boot/dts/canaan/k230.dtsi
index 8ca5c7dee427..b369b7d8dc83 100644
--- a/arch/riscv/boot/dts/canaan/k230.dtsi
+++ b/arch/riscv/boot/dts/canaan/k230.dtsi
@@ -148,5 +148,40 @@ uart4: serial@91404000 {
reg-shift = <2>;
status = "disabled";
};
+
+ usb0: usb@91500000 {
+ compatible = "canaan,k230-usb", "snps,dwc2";
+ reg = <0x0 0x91500000 0x0 0x40000>;
+ interrupts = <173 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysclk K230_HS_USB0_AHB_GATE>;
+ clock-names = "otg";
+ g-rx-fifo-size = <512>;
+ g-np-tx-fifo-size = <64>;
+ g-tx-fifo-size = <512 1024 64 64 64 64>;
+ phys = <&usbphy 0>;
+ phy-names = "usb2-phy";
+ status = "disabled";
+ };
+
+ usb1: usb@91540000 {
+ compatible = "canaan,k230-usb", "snps,dwc2";
+ reg = <0x0 0x91540000 0x0 0x40000>;
+ interrupts = <174 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sysclk K230_HS_USB1_AHB_GATE>;
+ clock-names = "otg";
+ g-rx-fifo-size = <512>;
+ g-np-tx-fifo-size = <64>;
+ g-tx-fifo-size = <512 1024 64 64 64 64>;
+ phys = <&usbphy 1>;
+ phy-names = "usb2-phy";
+ status = "disabled";
+ };
+
+ usbphy: usb-phy@91585000 {
+ compatible = "canaan,k230-usb-phy";
+ reg = <0x0 0x91585000 0x0 0x400>;
+ #phy-cells = <1>;
+ status = "disabled";
+ };
};
};
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v5 2/4] dt-bindings: usb: dwc2: Add support for Canaan K230 SoC
From: Jiayu Du @ 2026-01-21 14:55 UTC (permalink / raw)
To: vkoul, gregkh, conor
Cc: neil.armstrong, robh, krzk+dt, pjw, palmer, aou, alex,
jiayu.riscv, linux-phy, linux-usb, devicetree, linux-riscv,
linux-kernel
In-Reply-To: <20260121145526.14672-1-jiayu.riscv@isrc.iscas.ac.cn>
Add 'canaan,k230-usb' compatible string with 'snps,dwc2' as fallback
for the DWC2 IP which is used by Canaan K230.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
---
Documentation/devicetree/bindings/usb/dwc2.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml
index 6c3a10991b8b..352487c6392a 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.yaml
+++ b/Documentation/devicetree/bindings/usb/dwc2.yaml
@@ -17,6 +17,9 @@ properties:
compatible:
oneOf:
- const: brcm,bcm2835-usb
+ - items:
+ - const: canaan,k230-usb
+ - const: snps,dwc2
- const: hisilicon,hi6220-usb
- const: ingenic,jz4775-otg
- const: ingenic,jz4780-otg
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v5 3/4] phy: usb: Add driver for Canaan K230 USB 2.0 PHY
From: Jiayu Du @ 2026-01-21 14:55 UTC (permalink / raw)
To: vkoul, gregkh, conor
Cc: neil.armstrong, robh, krzk+dt, pjw, palmer, aou, alex,
jiayu.riscv, linux-phy, linux-usb, devicetree, linux-riscv,
linux-kernel
In-Reply-To: <20260121145526.14672-1-jiayu.riscv@isrc.iscas.ac.cn>
Add driver for the USB 2.0 PHY in Canaan K230 SoC, which supports PHY
initialization and power management.
Add Kconfig/Makefile under drivers/phy/canaan/.
Signed-off-by: Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
---
drivers/phy/Kconfig | 1 +
drivers/phy/Makefile | 1 +
drivers/phy/canaan/Kconfig | 14 ++
drivers/phy/canaan/Makefile | 2 +
drivers/phy/canaan/phy-k230-usb.c | 284 ++++++++++++++++++++++++++++++
5 files changed, 302 insertions(+)
create mode 100644 drivers/phy/canaan/Kconfig
create mode 100644 drivers/phy/canaan/Makefile
create mode 100644 drivers/phy/canaan/phy-k230-usb.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 142e7b0ef2ef..e37bcceef65a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -150,6 +150,7 @@ source "drivers/phy/amlogic/Kconfig"
source "drivers/phy/apple/Kconfig"
source "drivers/phy/broadcom/Kconfig"
source "drivers/phy/cadence/Kconfig"
+source "drivers/phy/canaan/Kconfig"
source "drivers/phy/freescale/Kconfig"
source "drivers/phy/hisilicon/Kconfig"
source "drivers/phy/ingenic/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index dcbb060c8207..8cef0a447986 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -22,6 +22,7 @@ obj-y += allwinner/ \
apple/ \
broadcom/ \
cadence/ \
+ canaan/ \
freescale/ \
hisilicon/ \
ingenic/ \
diff --git a/drivers/phy/canaan/Kconfig b/drivers/phy/canaan/Kconfig
new file mode 100644
index 000000000000..1ff8831846d5
--- /dev/null
+++ b/drivers/phy/canaan/Kconfig
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Phy drivers for Canaan platforms
+#
+config PHY_CANAAN_USB
+ tristate "Canaan USB2 PHY Driver"
+ depends on (ARCH_CANAAN || COMPILE_TEST) && OF
+ select GENERIC_PHY
+ help
+ Enable this driver to support the USB 2.0 PHY controller
+ on Canaan K230 RISC-V SoCs. This PHY controller
+ provides physical layer functionality for USB 2.0 devices.
+ If you have a Canaan K230 board and need USB 2.0 support,
+ say Y or M here.
diff --git a/drivers/phy/canaan/Makefile b/drivers/phy/canaan/Makefile
new file mode 100644
index 000000000000..d73857ba284e
--- /dev/null
+++ b/drivers/phy/canaan/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_PHY_CANAAN_USB) += phy-k230-usb.o
diff --git a/drivers/phy/canaan/phy-k230-usb.c b/drivers/phy/canaan/phy-k230-usb.c
new file mode 100644
index 000000000000..52dad35fc6cf
--- /dev/null
+++ b/drivers/phy/canaan/phy-k230-usb.c
@@ -0,0 +1,284 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Canaan usb PHY driver
+ *
+ * Copyright (C) 2026 Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+
+#define MAX_PHYS 2
+
+/* Register offsets within the HiSysConfig system controller */
+#define K230_USB0_TEST_REG_BASE 0x70
+#define K230_USB0_CTL_REG_BASE 0xb0
+#define K230_USB1_TEST_REG_BASE 0x90
+#define K230_USB1_CTL_REG_BASE 0xb8
+
+/* Relative offsets within each PHY's control/test block */
+#define CTL0_OFFSET 0x00
+#define CTL1_OFFSET 0x04
+#define TEST_CTL3_OFFSET 0x0c
+
+/* Bit definitions for TEST_CTL3 */
+#define USB_IDPULLUP0 BIT(4)
+#define USB_DMPULLDOWN0 BIT(8)
+#define USB_DPPULLDOWN0 BIT(9)
+
+/* USB control register 0 in HiSysConfig system controller */
+/* PLL Integral Path Tune */
+#define USB_CTL0_PLLITUNE_MASK GENMASK(23, 22)
+
+/* PLL Proportional Path Tune */
+#define USB_CTL0_PLLPTUNE_MASK GENMASK(21, 18)
+
+/* PLL Bandwidth Adjustment */
+#define USB_CTL0_PLLBTUNE_MASK GENMASK(17, 17)
+
+/* VReg18 Bypass Control */
+#define USB_CTL0_VREGBYPASS_MASK GENMASK(16, 16)
+
+/* Retention Mode Enable */
+#define USB_CTL0_RETENABLEN_MASK GENMASK(15, 15)
+
+/* Reserved Request Input */
+#define USB_CTL0_RESREQIN_MASK GENMASK(14, 14)
+
+/* External VBUS Valid Select */
+#define USB_CTL0_VBUSVLDEXTSEL0_MASK GENMASK(13, 13)
+
+/* OTG Block Disable Control */
+#define USB_CTL0_OTGDISABLE0_MASK GENMASK(12, 12)
+
+/* Drive VBUS Enable */
+#define USB_CTL0_DRVVBUS0_MASK GENMASK(11, 11)
+
+/* Autoresume Mode Enable */
+#define USB_CTL0_AUTORSMENB0_MASK GENMASK(10, 10)
+
+/* HS Transceiver Asynchronous Control */
+#define USB_CTL0_HSXCVREXTCTL0_MASK GENMASK(9, 9)
+
+/* USB 1.1 Transmit Data */
+#define USB_CTL0_FSDATAEXT0_MASK GENMASK(8, 8)
+
+/* USB 1.1 SE0 Generation */
+#define USB_CTL0_FSSE0EXT0_MASK GENMASK(7, 7)
+
+/* USB 1.1 Data Enable */
+#define USB_CTL0_TXENABLEN0_MASK GENMASK(6, 6)
+
+/* Disconnect Threshold */
+#define USB_CTL0_COMPDISTUNE0_MASK GENMASK(5, 3)
+
+/* Squelch Threshold */
+#define USB_CTL0_SQRXTUNE0_MASK GENMASK(2, 0)
+
+/* USB control register 1 in HiSysConfig system controller */
+/* Data Detect Voltage */
+#define USB_CTL1_VDATREFTUNE0_MASK GENMASK(23, 22)
+
+/* VBUS Valid Threshold */
+#define USB_CTL1_OTGTUNE0_MASK GENMASK(21, 19)
+
+/* Transmitter High-Speed Crossover */
+#define USB_CTL1_TXHSXVTUNE0_MASK GENMASK(18, 17)
+
+/* FS/LS Source Impedance */
+#define USB_CTL1_TXFSLSTUNE0_MASK GENMASK(16, 13)
+
+/* HS DC Voltage Level */
+#define USB_CTL1_TXVREFTUNE0_MASK GENMASK(12, 9)
+
+/* HS Transmitter Rise/Fall Time */
+#define USB_CTL1_TXRISETUNE0_MASK GENMASK(8, 7)
+
+/* USB Source Impedance */
+#define USB_CTL1_TXRESTUNE0_MASK GENMASK(6, 5)
+
+/* HS Transmitter Pre-Emphasis Current Control */
+#define USB_CTL1_TXPREEMPAMPTUNE0_MASK GENMASK(4, 3)
+
+/* HS Transmitter Pre-Emphasis Duration Control */
+#define USB_CTL1_TXPREEMPPULSETUNE0_MASK GENMASK(2, 2)
+
+/* charging detection */
+#define USB_CTL1_CHRGSRCPUENB0_MASK GENMASK(1, 0)
+
+#define K230_PHY_CTL0_VAL \
+( \
+ FIELD_PREP(USB_CTL0_PLLITUNE_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL0_PLLPTUNE_MASK, 0xc) | \
+ FIELD_PREP(USB_CTL0_PLLBTUNE_MASK, 0x1) | \
+ FIELD_PREP(USB_CTL0_VREGBYPASS_MASK, 0x1) | \
+ FIELD_PREP(USB_CTL0_RETENABLEN_MASK, 0x1) | \
+ FIELD_PREP(USB_CTL0_RESREQIN_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL0_VBUSVLDEXTSEL0_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL0_OTGDISABLE0_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL0_DRVVBUS0_MASK, 0x1) | \
+ FIELD_PREP(USB_CTL0_AUTORSMENB0_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL0_HSXCVREXTCTL0_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL0_FSDATAEXT0_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL0_FSSE0EXT0_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL0_TXENABLEN0_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL0_COMPDISTUNE0_MASK, 0x3) | \
+ FIELD_PREP(USB_CTL0_SQRXTUNE0_MASK, 0x3) \
+)
+
+#define K230_PHY_CTL1_VAL \
+( \
+ FIELD_PREP(USB_CTL1_VDATREFTUNE0_MASK, 0x1) | \
+ FIELD_PREP(USB_CTL1_OTGTUNE0_MASK, 0x3) | \
+ FIELD_PREP(USB_CTL1_TXHSXVTUNE0_MASK, 0x3) | \
+ FIELD_PREP(USB_CTL1_TXFSLSTUNE0_MASK, 0x3) | \
+ FIELD_PREP(USB_CTL1_TXVREFTUNE0_MASK, 0x3) | \
+ FIELD_PREP(USB_CTL1_TXRISETUNE0_MASK, 0x1) | \
+ FIELD_PREP(USB_CTL1_TXRESTUNE0_MASK, 0x1) | \
+ FIELD_PREP(USB_CTL1_TXPREEMPAMPTUNE0_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL1_TXPREEMPPULSETUNE0_MASK, 0x0) | \
+ FIELD_PREP(USB_CTL1_CHRGSRCPUENB0_MASK, 0x0) \
+)
+
+struct k230_usb_phy_instance {
+ struct k230_usb_phy_global *global;
+ struct phy *phy;
+ u32 test_offset;
+ u32 ctl_offset;
+ int index;
+};
+
+struct k230_usb_phy_global {
+ struct k230_usb_phy_instance phys[MAX_PHYS];
+ void __iomem *base;
+};
+
+static int k230_usb_phy_power_on(struct phy *phy)
+{
+ struct k230_usb_phy_instance *inst = phy_get_drvdata(phy);
+ struct k230_usb_phy_global *global = inst->global;
+ void __iomem *base = global->base;
+ u32 val;
+
+ /* Apply recommended settings */
+ writel(K230_PHY_CTL0_VAL, base + inst->ctl_offset + CTL0_OFFSET);
+ writel(K230_PHY_CTL1_VAL, base + inst->ctl_offset + CTL1_OFFSET);
+
+ /* Configure test register (pull-ups/pull-downs) */
+ val = readl(base + inst->test_offset + TEST_CTL3_OFFSET);
+ val |= USB_IDPULLUP0;
+
+ if (inst->index == 1)
+ val |= (USB_DMPULLDOWN0 | USB_DPPULLDOWN0);
+ else
+ val &= ~(USB_DMPULLDOWN0 | USB_DPPULLDOWN0);
+
+ writel(val, base + inst->test_offset + TEST_CTL3_OFFSET);
+
+ return 0;
+}
+
+static int k230_usb_phy_power_off(struct phy *phy)
+{
+ struct k230_usb_phy_instance *inst = phy_get_drvdata(phy);
+ struct k230_usb_phy_global *global = inst->global;
+ void __iomem *base = global->base;
+ u32 val;
+
+ val = readl(base + inst->test_offset + TEST_CTL3_OFFSET);
+ val &= ~(USB_DMPULLDOWN0 | USB_DPPULLDOWN0);
+ writel(val, base + inst->test_offset + TEST_CTL3_OFFSET);
+
+ return 0;
+}
+
+static const struct phy_ops k230_usb_phy_ops = {
+ .power_on = k230_usb_phy_power_on,
+ .power_off = k230_usb_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static struct phy *k230_usb_phy_xlate(struct device *dev,
+ const struct of_phandle_args *args)
+{
+ struct k230_usb_phy_global *global = dev_get_drvdata(dev);
+ unsigned int idx = args->args[0];
+
+ if (idx >= MAX_PHYS)
+ return ERR_PTR(-EINVAL);
+
+ return global->phys[idx].phy;
+}
+
+static int k230_usb_phy_probe(struct platform_device *pdev)
+{
+ struct k230_usb_phy_global *global;
+ struct device *dev = &pdev->dev;
+ struct phy_provider *provider;
+ int i;
+
+ global = devm_kzalloc(dev, sizeof(*global), GFP_KERNEL);
+ if (!global)
+ return -ENOMEM;
+ dev_set_drvdata(dev, global);
+
+ global->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(global->base))
+ return dev_err_probe(dev, PTR_ERR(global->base),
+ "failed to map registers\n");
+
+ static const struct {
+ u32 test_offset;
+ u32 ctl_offset;
+ } phy_reg_info[MAX_PHYS] = {
+ [0] = { K230_USB0_TEST_REG_BASE, K230_USB0_CTL_REG_BASE },
+ [1] = { K230_USB1_TEST_REG_BASE, K230_USB1_CTL_REG_BASE },
+ };
+
+ for (i = 0; i < MAX_PHYS; i++) {
+ struct k230_usb_phy_instance *inst = &global->phys[i];
+ struct phy *phy;
+
+ inst->global = global;
+ inst->index = i;
+ inst->test_offset = phy_reg_info[i].test_offset;
+ inst->ctl_offset = phy_reg_info[i].ctl_offset;
+
+ phy = devm_phy_create(dev, NULL, &k230_usb_phy_ops);
+ if (IS_ERR(phy)) {
+ dev_err(dev, "failed to create phy%d\n", i);
+ return PTR_ERR(phy);
+ }
+
+ phy_set_drvdata(phy, inst);
+ inst->phy = phy;
+ }
+
+ provider = devm_of_phy_provider_register(dev, k230_usb_phy_xlate);
+ if (IS_ERR(provider))
+ return PTR_ERR(provider);
+
+ return 0;
+}
+
+static const struct of_device_id k230_usb_phy_of_match[] = {
+ { .compatible = "canaan,k230-usb-phy" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, k230_usb_phy_of_match);
+
+static struct platform_driver k230_usb_phy_driver = {
+ .probe = k230_usb_phy_probe,
+ .driver = {
+ .name = "k230-usb-phy",
+ .of_match_table = k230_usb_phy_of_match,
+ },
+};
+module_platform_driver(k230_usb_phy_driver);
+
+MODULE_DESCRIPTION("Canaan Kendryte K230 USB 2.0 PHY driver");
+MODULE_AUTHOR("Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>");
+MODULE_LICENSE("GPL");
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v5 1/4] dt-bindings: phy: Add Canaan K230 USB PHY
From: Jiayu Du @ 2026-01-21 14:55 UTC (permalink / raw)
To: vkoul, gregkh, conor
Cc: neil.armstrong, robh, krzk+dt, pjw, palmer, aou, alex,
jiayu.riscv, linux-phy, linux-usb, devicetree, linux-riscv,
linux-kernel
In-Reply-To: <20260121145526.14672-1-jiayu.riscv@isrc.iscas.ac.cn>
K230 SoC USB PHY requires configuring registers for control and
configuration. Add USB phy bindings for K230 SoC.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
---
.../bindings/phy/canaan,k230-usb-phy.yaml | 35 +++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/canaan,k230-usb-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/canaan,k230-usb-phy.yaml b/Documentation/devicetree/bindings/phy/canaan,k230-usb-phy.yaml
new file mode 100644
index 000000000000..b959b381c44c
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/canaan,k230-usb-phy.yaml
@@ -0,0 +1,35 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/canaan,k230-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Canaan K230 USB2.0 PHY
+
+maintainers:
+ - Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
+
+properties:
+ compatible:
+ const: canaan,k230-usb-phy
+
+ reg:
+ maxItems: 1
+
+ "#phy-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ usbphy: usb-phy@91585000 {
+ compatible = "canaan,k230-usb-phy";
+ reg = <0x91585000 0x400>;
+ #phy-cells = <1>;
+ };
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v5 0/4] Add USB support for Canaan K230
From: Jiayu Du @ 2026-01-21 14:55 UTC (permalink / raw)
To: vkoul, gregkh, conor
Cc: neil.armstrong, robh, krzk+dt, pjw, palmer, aou, alex,
jiayu.riscv, linux-phy, linux-usb, devicetree, linux-riscv,
linux-kernel
Add support for the USB PHY and DWC2 IP which is used by Canaan K230,
and made relevant changes to the DTS.
This series is based on the initial 100ask K230 DshanPi series [1] which
is based on the clock and pinctrl series. Check the details in the link.
Link: https://lore.kernel.org/all/20260115060801.16819-1-jiayu.riscv@isrc.iscas.ac.cn/ [1]
Changes in v5:
- Changed the year of Copyright to 2026.
- Add blank line after the declaration of variables
- Fix wrong alignment.
- Link to v4: https://lore.kernel.org/all/20260120143243.71937-1-jiayu.riscv@isrc.iscas.ac.cn/
Changes in v4:
- Shrink reg length to match the address/size-cells in k230-usb-phy yaml.
- Move all PHY instance creation and initialization from xlate to probe.
- Modify xlate function to only perform index lookup for PHY instances.
- Define all register base offsets macros at the top of file instead of
hard-coding magic numbers directly in probe.
- Link to v2: https://lore.kernel.org/all/20260115064223.21926-1-jiayu.riscv@isrc.iscas.ac.cn/
Changes in v3:
- Please ignore v3.
Changes in v2:
- Fold the child into the parent in dtsi.
- Define one usbphy with phy-cells=1.
- Delete the clock of the usbphy as it is not needed.
- Link to v1: https://lore.kernel.org/all/20251230023725.15966-1-jiayu.riscv@isrc.iscas.ac.cn/
Jiayu Du (4):
dt-bindings: phy: Add Canaan K230 USB PHY
dt-bindings: usb: dwc2: Add support for Canaan K230 SoC
phy: usb: Add driver for Canaan K230 USB 2.0 PHY
riscv: dts: canaan: Add syscon and USB nodes for K230
.../bindings/phy/canaan,k230-usb-phy.yaml | 35 +++
.../devicetree/bindings/usb/dwc2.yaml | 3 +
.../boot/dts/canaan/k230-canmv-dshanpi.dts | 17 ++
arch/riscv/boot/dts/canaan/k230.dtsi | 35 +++
drivers/phy/Kconfig | 1 +
drivers/phy/Makefile | 1 +
drivers/phy/canaan/Kconfig | 14 +
drivers/phy/canaan/Makefile | 2 +
drivers/phy/canaan/phy-k230-usb.c | 284 ++++++++++++++++++
9 files changed, 392 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/canaan,k230-usb-phy.yaml
create mode 100644 drivers/phy/canaan/Kconfig
create mode 100644 drivers/phy/canaan/Makefile
create mode 100644 drivers/phy/canaan/phy-k230-usb.c
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 2/7] mux: Add helper functions for getting optional and selected mux-state
From: kernel test robot @ 2026-01-21 14:49 UTC (permalink / raw)
To: Josua Mayer, Marc Kleine-Budde, Vincent Mailhol, Vinod Koul,
Neil Armstrong, Peter Rosin, Aaro Koskinen, Andreas Kemnade,
Kevin Hilman, Roger Quadros, Tony Lindgren, Janusz Krzysztofik,
Vignesh R, Andi Shyti, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: oe-kbuild-all, Yazan Shhady, Jon Nettleton, Mikhail Anikin,
linux-can, linux-phy, linux-kernel, linux-omap, linux-i2c,
linux-mmc, devicetree
In-Reply-To: <20260121-rz-sdio-mux-v6-2-38aa39527928@solid-run.com>
Hi Josua,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 8f0b4cce4481fb22653697cced8d0d04027cb1e8]
url: https://github.com/intel-lab-lkp/linux/commits/Josua-Mayer/phy-can-transceiver-rename-temporary-helper-function-to-avoid-conflict/20260121-173607
base: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
patch link: https://lore.kernel.org/r/20260121-rz-sdio-mux-v6-2-38aa39527928%40solid-run.com
patch subject: [PATCH v6 2/7] mux: Add helper functions for getting optional and selected mux-state
config: i386-randconfig-001-20260121 (https://download.01.org/0day-ci/archive/20260121/202601212215.qNGA0wVh-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260121/202601212215.qNGA0wVh-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/202601212215.qNGA0wVh-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> Warning: drivers/mux/core.c:56 struct member 'mstate' not described in 'devm_mux_state_state'
>> Warning: drivers/mux/core.c:56 struct member 'mstate' not described in 'devm_mux_state_state'
--
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: [net-next,05/14] net: stmmac: add stmmac core serdes support
From: Russell King (Oracle) @ 2026-01-21 14:46 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Jakub Kicinski, linux-phy, davem, maxime.chevallier,
alexandre.torgue, mohd.anwar, neil.armstrong, hkallweit1,
mcoquelin.stm32, netdev, edumazet, linux-arm-msm,
linux-arm-kernel, vkoul, andrew, pabeni, andrew+netdev,
linux-stm32
In-Reply-To: <20260120121114.2aedgu42i2wax3yp@skbuf>
On Tue, Jan 20, 2026 at 02:11:14PM +0200, Vladimir Oltean wrote:
> On Tue, Jan 20, 2026 at 10:12:46AM +0000, Russell King (Oracle) wrote:
> > First, I'll say I'm on a very short fuse today; no dinner last night,
> > at the hospital up until 5:30am, and a fucking cold caller rang the door
> > bell at 10am this morning. Just fucking our luck.
>
> Sorry to hear that.
>
> > On Tue, Jan 20, 2026 at 10:18:44AM +0200, Vladimir Oltean wrote:
> > > Isn't it sufficient to set pl->pcs to NULL when pcs_enable() fails and
> > > after calling pcs_disable(), though?
> >
> > No. We've already called mac_prepare(), pcs_pre_config(),
> > pcs_post_config() by this time, we're past the point of being able to
> > unwind.
>
> I'm set out to resolve a much smaller problem.
>
> Calling it a full "unwind" is perhaps a bit much, because pcs_pre_config()
> and pcs_post_config() don't have unwinding equivalents, unlike how
> pcs_enable() has pcs_disable(). I don't see what API convention would be
> violated if phylink decided to drop a PCS whose enable() returned an error.
While pcs_pre_config() and pcs_post_config() do not have unwinding
equivalents (what would they be?) the issue here is that these could
have changed any state that isn't simply undone by calling
pcs_disable().
For example, pcs_pre_config() could have reprogrammed signal routing,
clocking, or power supplies to blocks.
This already applies to Marvell DSA pcs-639x.c, where the pre/post
config hooks change the power state of the PCS block (for errata
handling), and the only way that gets undone is via a call to
pcs_disable() which explicitly disables IRQs and power for the PCS. Its
pcs_disable() isn't a strict reversal of pcs_enable(), it does more.
We already declare the interface to be dead on pcs_post_config()
failure, but we don't do that for pcs_enable() failure.
Maybe I need to explicitly state that pcs_disable() does not directly
balance pcs_enable(), but that _and_ the effects of pcs_pre_config()
and pcs_post_config(). However, that itself will add to the problems.
What if pcs_pre_config() and pcs_post_config() succeed but not
pcs_enable()? pcs-639x needs pcs_disable() to be called, but if we
require pcs_disable() to be balanced with a successful call to
pcs_enable(), that messes up that driver, and pretty much makes it
impossible to work around the errata.
If you feel strongly about this, then the only thing I can think of
doing is to move this SerDes support out of stmmac and into phylink
(which is a point I already raised in the cover message) so that
its failure can be dealt with at the higher level, where we can
ensure that phy_power_off() is balaced with phy_power_on(). However,
that means pushing even more of the stmmac specific "we need the
clocks running to access registers XYZ or reset" weirdness into
phylink.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 6/6] phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend
From: Loic Poulain @ 2026-01-21 14:28 UTC (permalink / raw)
To: vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong,
konrad.dybcio, Loic Poulain
In-Reply-To: <20260121142827.2583-1-loic.poulain@oss.qualcomm.com>
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>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
index eb0b0f61d98e..d1288a6c202e 100644
--- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
+++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
@@ -599,13 +599,17 @@ static int qcom_snps_hsphy_probe(struct platform_device *pdev)
return dev_err_probe(dev, ret,
"failed to get regulator supplies\n");
- pm_runtime_set_active(dev);
- pm_runtime_enable(dev);
+ dev_set_drvdata(dev, hsphy);
+
/*
- * Prevent runtime pm from being ON by default. Users can enable
- * it using power/control in sysfs.
+ * Enable runtime PM support, but forbid it by default.
+ * Users can allow it again via the power/control attribute in sysfs.
*/
+ pm_runtime_set_active(dev);
pm_runtime_forbid(dev);
+ ret = devm_pm_runtime_enable(dev);
+ if (ret)
+ return ret;
generic_phy = devm_phy_create(dev, NULL, &qcom_snps_hsphy_gen_ops);
if (IS_ERR(generic_phy)) {
@@ -615,15 +619,12 @@ static int qcom_snps_hsphy_probe(struct platform_device *pdev)
}
hsphy->phy = generic_phy;
- dev_set_drvdata(dev, hsphy);
phy_set_drvdata(generic_phy, hsphy);
qcom_snps_hsphy_read_override_param_seq(dev);
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
if (!IS_ERR(phy_provider))
dev_dbg(dev, "Registered Qcom-SNPS HS phy\n");
- else
- pm_runtime_disable(dev);
return PTR_ERR_OR_ZERO(phy_provider);
}
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 5/6] phy: qcom: qmp-usb-legacy: Prevent unnecessary PM runtime suspend at boot
From: Loic Poulain @ 2026-01-21 14:28 UTC (permalink / raw)
To: vkoul, kishon
Cc: linux-arm-msm, linux-phy, dmitry.baryshkov, neil.armstrong,
konrad.dybcio, Loic Poulain
In-Reply-To: <20260121142827.2583-1-loic.poulain@oss.qualcomm.com>
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-usb-legacy.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-usb-legacy.c b/drivers/phy/qualcomm/phy-qcom-qmp-usb-legacy.c
index 258e0e966a02..73439d223f1d 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-usb-legacy.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-usb-legacy.c
@@ -1284,15 +1284,15 @@ static int qmp_usb_legacy_probe(struct platform_device *pdev)
if (ret)
goto err_node_put;
+ /*
+ * Enable runtime PM support, but forbid it by default.
+ * Users can allow it again via the power/control attribute in sysfs.
+ */
pm_runtime_set_active(dev);
+ pm_runtime_forbid(dev);
ret = devm_pm_runtime_enable(dev);
if (ret)
goto err_node_put;
- /*
- * Prevent runtime pm from being ON by default. Users can enable
- * it using power/control in sysfs.
- */
- pm_runtime_forbid(dev);
ret = phy_pipe_clk_register(qmp, np);
if (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
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