* Re: [PATCH phy-next 22/22] MAINTAINERS: add regex for linux-phy
From: Krzysztof Wilczyński @ 2026-03-05 13:01 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Vladimir Oltean, Joe Perches, Konrad Dybcio, 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: <aal6kWDx_3XRGB4K@shell.armlinux.org.uk>
Hello,
> > > For content match, it could also be:
> > >
> > > K: phy
> > >
> > > I believe this would match everything of interest?
> >
> > Yeah, and way more. Think USB PHY, network PHY, etc. Don't want to drown
> > the linux-phy mailing list in unrelated patches, either.
>
> Also phylink, any memory management / DMA stuff that happens to mention
> "physical", and probably numerous other examples.
Makes sense! Sorry for the commotion here, then. :)
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 22/22] MAINTAINERS: add regex for linux-phy
From: Krzysztof Wilczyński @ 2026-03-05 13:06 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Joe Perches, Konrad Dybcio, 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: <20260305123843.i47asdrjychwlgdt@skbuf>
Hello,
> > > K: \b(?:__)?(?:devm_)?(?:of_)?phy_(?:create|destroy|provider_(?:un)?register)\b
> > > K: \bphy_(?:create|remove)_lookup\b
> > > K: \bphy_(?:get|set)?_drvdata\b
> > > K: \b(?:devm_)?(?:of_)?phy_(?:optional_)?(?:get|put)(?:_by_index)?\b
> > > K: \bphy_pm_runtime_(?:get|put)(?:_sync)?\b
> > > K: \bphy_(?:init|exit|power_(?:on|off))\b
> > > K: \bphy_|(?:get|set)_(?:mode(?:_ext)?|media|speed|bus_width|max_link_rate)\b
> > > K: \bphy_(?:reset|configure|validate|calibrate)\b
> > > K: \bphy_notify_(?:connect|disconnect|state)\b
> > > K: (?:struct\s+)?phy(?:_ops|_attrs|_lookup|_provider)?\b
> > > K: (?:linux/phy/phy\.h|phy-props\.h|phy-provider\.h)
> >
> > What about
> >
> > F: drivers/*/*phy*
> >
> > or something along these lines.
> >
> > Krzysztof
>
> I don't understand your suggestion. Is it meant as a replacement for the
> keyword regexes? Your file pattern matches on:
I was thinking more along the lines of using wildcards, the F: was just an
example.
[...]
> There are a lot of false positives, and a lot of false negatives.
Yeah, the "catch-all", for lack of better word, will not work here.
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 22/22] MAINTAINERS: add regex for linux-phy
From: Vladimir Oltean @ 2026-03-05 13:11 UTC (permalink / raw)
To: Krzysztof Wilczyński
Cc: Joe Perches, Konrad Dybcio, 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: <20260305130609.GB1659133@rocinante>
On Thu, Mar 05, 2026 at 10:06:09PM +0900, Krzysztof Wilczyński wrote:
> > > What about
> > >
> > > F: drivers/*/*phy*
> > >
> > > or something along these lines.
> > >
> > > Krzysztof
> >
> > I don't understand your suggestion. Is it meant as a replacement for the
> > keyword regexes? Your file pattern matches on:
>
> I was thinking more along the lines of using wildcards, the F: was just an
> example.
>
> [...]
>
> > There are a lot of false positives, and a lot of false negatives.
>
> Yeah, the "catch-all", for lack of better word, will not work here.
But assume it did, for a second. The intention of the patch, stated in
the commit message, is to match on PHY consumers, to review their API
use.
$ grep -l -r '\bphy_power_on\b' drivers/ | sort | uniq
drivers/ata/ahci_ceva.c
drivers/ata/ahci_imx.c
drivers/ata/libahci_platform.c
drivers/ata/sata_dwc_460ex.c
drivers/ata/sata_mv.c
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
drivers/gpu/drm/bridge/imx/imx8qm-ldb.c
drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
drivers/gpu/drm/bridge/nwl-dsi.c
drivers/gpu/drm/bridge/samsung-dsim.c
drivers/gpu/drm/bridge/synopsys/dw-dp.c
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi2.c
drivers/gpu/drm/mediatek/mtk_dsi.c
drivers/gpu/drm/mediatek/mtk_hdmi.c
drivers/gpu/drm/mediatek/mtk_hdmi_v2.c
drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
drivers/gpu/drm/msm/dp/dp_ctrl.c
drivers/gpu/drm/rockchip/cdn-dp-core.c
drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
drivers/gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
drivers/gpu/drm/rockchip/rockchip_lvds.c
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
drivers/gpu/drm/xlnx/zynqmp_dp.c
drivers/media/platform/cadence/cdns-csi2rx.c
drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
drivers/media/platform/samsung/exynos4-is/mipi-csis.c
drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_mipi_csi2.c
drivers/media/platform/synopsys/dw-mipi-csi2rx.c
drivers/mmc/host/sdhci-of-arasan.c
drivers/net/can/at91_can.c
drivers/net/can/flexcan/flexcan-core.c
drivers/net/can/m_can/m_can.c
drivers/net/can/rcar/rcar_canfd.c
drivers/net/can/xilinx_can.c
drivers/net/ethernet/cadence/macb_main.c
drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
...
How can it find the above? I think you've severely oversimplified what I
am trying to do.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 00/10] SPMI: Implement sub-devices and migrate drivers
From: AngeloGioacchino Del Regno @ 2026-03-05 14:32 UTC (permalink / raw)
To: jic23, sboyd
Cc: dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
neil.armstrong, sre, krzk, dmitry.baryshkov, quic_wcheng,
melody.olvera, quic_nsekar, ivo.ivanov.ivanov1, abelvesa,
luca.weiss, konrad.dybcio, mitltlatltl, krishna.kurapati,
linux-arm-msm, linux-iio, linux-kernel, linux-phy, linux-pm,
kernel
In-Reply-To: <de08d697-4202-499c-9784-2bb8d3d614b6@collabora.com>
Il 21/01/26 12:00, AngeloGioacchino Del Regno ha scritto:
> Il 14/01/26 10:27, AngeloGioacchino Del Regno ha scritto:
>> Changes in v8:
>
> With this series being finally fully reviewed and having lots of acks, and
> since I think that the main part of this is in SPMI subsystem rather than
> others....
>
> ....Stephen or Jonathan, can you please pick at least the SPMI code so that
> it goes in for this merge window and doesn't get forgotten again?
>
> That also makes it easier for the other maintainers who didn't give an ack (and
> that don't want their subsystem patches to go through SPMI) to apply the patches
> in the next merge window, IMO.
>
This series was ready and fully reviewed since the last merge window.
This is a gentle ping to remind you to *please* finally pick it.
Cheers,
Angelo
> Thanks,
> Angelo
>
>
>> - Renamed *res to *sub_sdev in devm_spmi_subdevice_remove() (Andy)
>> - Changed kerneldoc wording to "error pointer" for function
>> spmi_subdevice_alloc_and_add() (Andy)
>> - Shuffled around some assignments in spmi_subdevice_alloc_and_add() (Andy)
>> - Used device_property_read_u32() instead of of_property_read_u32()
>> in all of the migrated drivers (Andy)
>> - Changed .max_register field in all of the migrated drivers from
>> 0x100 to 0xff (Andy)
>> - Kept `sta1` declaration in reversed xmas tree order in function
>> iadc_poll_wait_eoc() of qcom-spmi-iadc.c (Andy)
>>
>> Changes in v7:
>> - Added commit to cleanup redundant dev_name() in the pre-existing
>> spmi_device_add() function
>> - Added commit removing unneeded goto and improving spmi_device_add()
>> readability by returning error in error path, and explicitly zero
>> for success at the end.
>>
>> Changes in v6:
>> - Added commit to convert spmi.c to %pe error format and used
>> %pe error format in spmi_subdevice code as wanted by Uwe Kleine-Konig
>>
>> Changes in v5:
>> - Changed dev_err to dev_err_probe in qcom-spmi-sdam (and done
>> that even though I disagree - because I wanted this series to
>> *exclusively* introduce the minimum required changes to
>> migrate to the new API, but okay, whatever....!);
>> - Added missing REGMAP dependency in Kconfig for qcom-spmi-sdam,
>> phy-qcom-eusb2-repeater and qcom-coincell to resolve build
>> issues when the already allowed COMPILE_TEST is enabled
>> as pointed out by the test robot's randconfig builds.
>>
>> Changes in v4:
>> - Added selection of REGMAP_SPMI in Kconfig for qcom-coincell and
>> for phy-qcom-eusb2-repeater to resolve undefined references when
>> compiled with some randconfig
>>
>> Changes in v3:
>> - Fixed importing "SPMI" namespace in spmi-devres.c
>> - Removed all instances of defensive programming, as pointed out by
>> jic23 and Sebastian
>> - Removed explicit casting as pointed out by jic23
>> - Moved ida_free call to spmi_subdev_release() and simplified error
>> handling in spmi_subdevice_alloc_and_add() as pointed out by jic23
>>
>> Changes in v2:
>> - Fixed missing `sparent` initialization in phy-qcom-eusb2-repeater
>> - Changed val_bits to 8 in all Qualcomm drivers to ensure
>> compatibility as suggested by Casey
>> - Added struct device pointer in all conversion commits as suggested
>> by Andy
>> - Exported newly introduced functions with a new "SPMI" namespace
>> and imported the same in all converted drivers as suggested by Andy
>> - Added missing error checking for dev_set_name() call in spmi.c
>> as suggested by Andy
>> - Added comma to last entry of regmap_config as suggested by Andy
>>
>> While adding support for newer MediaTek platforms, featuring complex
>> SPMI PMICs, I've seen that those SPMI-connected chips are internally
>> divided in various IP blocks, reachable in specific contiguous address
>> ranges... more or less like a MMIO, but over a slow SPMI bus instead.
>>
>> I recalled that Qualcomm had something similar... and upon checking a
>> couple of devicetrees, yeah - indeed it's the same over there.
>>
>> What I've seen then is a common pattern of reading the "reg" property
>> from devicetree in a struct member and then either
>> A. Wrapping regmap_{read/write/etc}() calls in a function that adds
>> the register base with "base + ..register", like it's done with
>> writel()/readl() calls; or
>> B. Doing the same as A. but without wrapper functions.
>>
>> Even though that works just fine, in my opinion it's wrong.
>>
>> The regmap API is way more complex than MMIO-only readl()/writel()
>> functions for multiple reasons (including supporting multiple busses
>> like SPMI, of course) - but everyone seemed to forget that regmap
>> can manage register base offsets transparently and automatically in
>> its API functions by simply adding a `reg_base` to the regmap_config
>> structure, which is used for initializing a `struct regmap`.
>>
>> So, here we go: this series implements the software concept of an SPMI
>> Sub-Device (which, well, also reflects how Qualcomm and MediaTek's
>> actual hardware is laid out anyway).
>>
>> SPMI Controller
>> | ______
>> | / Sub-Device 1
>> V /
>> SPMI Device (PMIC) ----------- Sub-Device 2
>> \
>> \______ Sub-Device 3
>>
>> As per this implementation, an SPMI Sub-Device can be allocated/created
>> and added in any driver that implements a... well.. subdevice (!) with
>> an SPMI "main" device as its parent: this allows to create and finally
>> to correctly configure a regmap that is specific to the sub-device,
>> operating on its specific address range and reading, and writing, to
>> its registers with the regmap API taking care of adding the base address
>> of a sub-device's registers as per regmap API design.
>>
>> All of the SPMI Sub-Devices are therefore added as children of the SPMI
>> Device (usually a PMIC), as communication depends on the PMIC's SPMI bus
>> to be available (and the PMIC to be up and running, of course).
>>
>> Summarizing the dependency chain (which is obvious to whoever knows what
>> is going on with Qualcomm and/or MediaTek SPMI PMICs):
>> "SPMI Sub-Device x...N" are children "SPMI Device"
>> "SPMI Device" is a child of "SPMI Controller"
>>
>> (that was just another way to say the same thing as the graph above anyway).
>>
>> Along with the new SPMI Sub-Device registration functions, I have also
>> performed a conversion of some Qualcomm SPMI drivers and only where the
>> actual conversion was trivial.
>>
>> I haven't included any conversion of more complex Qualcomm SPMI drivers
>> because I don't have the required bandwidth to do so (and besides, I think,
>> but haven't exactly verified, that some of those require SoCs that I don't
>> have for testing anyway).
>>
>> AngeloGioacchino Del Regno (10):
>> spmi: Remove redundant dev_name() print in spmi_device_add()
>> spmi: Print error status with %pe format
>> spmi: Remove unneeded goto in spmi_device_add() error path
>> spmi: Implement spmi_subdevice_alloc_and_add() and devm variant
>> nvmem: qcom-spmi-sdam: Migrate to devm_spmi_subdevice_alloc_and_add()
>> power: reset: qcom-pon: Migrate to devm_spmi_subdevice_alloc_and_add()
>> phy: qualcomm: eusb2-repeater: Migrate to
>> devm_spmi_subdevice_alloc_and_add()
>> misc: qcom-coincell: Migrate to devm_spmi_subdevice_alloc_and_add()
>> iio: adc: qcom-spmi-iadc: Migrate to
>> devm_spmi_subdevice_alloc_and_add()
>> iio: adc: qcom-spmi-iadc: Remove regmap R/W wrapper functions
>>
>> drivers/iio/adc/qcom-spmi-iadc.c | 109 ++++++++----------
>> drivers/misc/Kconfig | 2 +
>> drivers/misc/qcom-coincell.c | 38 ++++--
>> drivers/nvmem/Kconfig | 1 +
>> drivers/nvmem/qcom-spmi-sdam.c | 38 ++++--
>> drivers/phy/qualcomm/Kconfig | 2 +
>> .../phy/qualcomm/phy-qcom-eusb2-repeater.c | 55 +++++----
>> drivers/power/reset/qcom-pon.c | 33 ++++--
>> drivers/spmi/spmi-devres.c | 24 ++++
>> drivers/spmi/spmi.c | 95 +++++++++++++--
>> include/linux/spmi.h | 16 +++
>> 11 files changed, 290 insertions(+), 123 deletions(-)
>>
>
--
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 15:35 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Konrad Dybcio, 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: <20260305114352.2f7btqixg4tu5bzl@skbuf>
On Thu, 2026-03-05 at 13:43 +0200, Vladimir Oltean wrote:
> K: (?:struct\s+)?phy(?:_ops|_attrs|_lookup|_provider)?\b
You have (?:...)?phy(?:...)?\b
I rather doubt you want anything that ends in phy
That matches words like cryptography and way too many dts/yaml files
--
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 15:39 UTC (permalink / raw)
To: Joe Perches
Cc: Konrad Dybcio, 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: <21e84301a7c37f9d5ce6f0ddcaed7846174d2a4d.camel@perches.com>
On Thu, Mar 05, 2026 at 07:35:54AM -0800, Joe Perches wrote:
> On Thu, 2026-03-05 at 13:43 +0200, Vladimir Oltean wrote:
>
> > K: (?:struct\s+)?phy(?:_ops|_attrs|_lookup|_provider)?\b
>
> You have (?:...)?phy(?:...)?\b
>
> I rather doubt you want anything that ends in phy
>
> That matches words like cryptography and way too many dts/yaml files
Yeah, the struct was meant to be non-optional, thanks for pointing it out.
K: \bstruct\s+phy(?:_ops|_attrs|_lookup|_provider)?\b
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: cadence: Sierra: Do not modify register when getting parent clock
From: Gregory CLEMENT @ 2026-03-05 15:57 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Aswath Govindraju, Swapnil Jakhade
Cc: Théo Lebrun, Thomas Petazzoni, linux-phy, linux-kernel,
Gregory CLEMENT
The get_parent() callback for the PLL_CMNLC1 clock was incorrectly
writing to the register while determining the parent clock index. This
unintended register access forces the PHY back into training mode. If
the PHY is already configured, this unexpected change prevents it from
exiting training mode.
Remove the register write operation to ensure the PHY remains stable
during the get_parent() callback.
Fixes: da08aab940092 ("phy: cadence: Sierra: Fix to get correct parent for mux clocks")
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
drivers/phy/cadence/phy-cadence-sierra.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/cadence/phy-cadence-sierra.c b/drivers/phy/cadence/phy-cadence-sierra.c
index 92ab1a31646ae..d4e8979c3abba 100644
--- a/drivers/phy/cadence/phy-cadence-sierra.c
+++ b/drivers/phy/cadence/phy-cadence-sierra.c
@@ -706,15 +706,10 @@ static u8 cdns_sierra_pll_mux_get_parent(struct clk_hw *hw)
regmap_field_read(field, &val);
- if (strstr(clk_hw_get_name(hw), clk_names[CDNS_SIERRA_PLL_CMNLC1])) {
+ if (strstr(clk_hw_get_name(hw), clk_names[CDNS_SIERRA_PLL_CMNLC1]))
index = clk_mux_val_to_index(hw, cdns_sierra_pll_mux_table[CMN_PLLLC1], 0, val);
- if (index == 1) {
- regmap_field_write(plllc1en_field, 1);
- regmap_field_write(termen_field, 1);
- }
- } else {
+ else
index = clk_mux_val_to_index(hw, cdns_sierra_pll_mux_table[CMN_PLLLC], 0, val);
- }
return index;
}
---
base-commit: 11439c4635edd669ae435eec308f4ab8a0804808
change-id: 20260305-fix_sierra_get_parent-9c8435cc65e7
Best regards,
--
Grégory CLEMENT, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v11 0/9] mmc: host: renesas_sdhi_core: support configuring an optional sdio mux
From: Ulf Hansson @ 2026-03-05 16:19 UTC (permalink / raw)
To: Josua Mayer, Peter Rosin
Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Janusz Krzysztofik, Vignesh R, Andi Shyti,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Wolfram Sang, Yoshihiro Shimoda,
Yazan Shhady, Jon Nettleton, Vladimir Oltean, Mikhail Anikin,
linux-can, linux-phy, linux-kernel, linux-omap, linux-i2c,
linux-mmc, devicetree, linux-renesas-soc
In-Reply-To: <20260226-rz-sdio-mux-v11-0-c2a350f9bbd3@solid-run.com>
On Thu, 26 Feb 2026 at 14:21, Josua Mayer <josua@solid-run.com> wrote:
>
> This series has evolved over time from adding generic mux support for
> renesas sdhi driver, to partial rewrite of the mux framework.
>
> Several drivers have started implementing driver-local managed and
> unmanaged helper functions for getting and selecting a mux-state object.
>
> mmc maintainers have requested that new code shall intreoduce and use
> generic helper functions that can be shared by all drivers, avoiding
> code duplication.
>
> This series is structured in 5 parts, each of which is self-sufficient
> depending only on the previous patches. This shall allow the first N
> patches to be applied even if the last ones need further discussion.
>
> 1. Rename driver-local helper functions to avoid name collision with
> global version to be introduced later.
>
> 2. Implement generic device-managed helper functions in mux core.
>
> 3. Convert driver local code from similar patterns to use the newly
> added global helpers.
>
> 4. Change mux-core Kconfig so that it can be enabled through menuconfig,
> without an explicit "select" dependency from other drivers.
>
> 5. add dt bindings and driver support for mux in renesas sdhi driver.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
> Changes in v11:
> - changed approach to Kconfig making MULTIPLEXER a bool, and adding a
> user-visible wrapper for menuconfig.
> (Reported-by: Ulf Hansson <ulf.hansson@linaro.org>)
> - dropped the "default m if COMPILE_TEST".
> (Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>)
> - improved kerneldoc line wrapping.
> - removed unnecessary changes to original devm_mux_control-get.
> - fix "reference preceded by free" in mux_state_get function
> - Link to v10: https://lore.kernel.org/r/20260225-rz-sdio-mux-v10-0-1ee44f2ea112@solid-run.com
>
[...]
To me, this looks ready for a new try. Unless I hear some objections,
I intend to apply this as material for v7.1 via my mmc tree on Monday.
The complete series will be available on an immutable branch, for
other subsystem maintainers to pull in if that turns out to be needed.
I let you know of more details on Monday.
Kind regards
Uffe
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next v2 2/7] net: stmmac: qcom-ethqos: convert to use phy_set_mode_ext()
From: Mohd Ayaan Anwar @ 2026-03-05 19:48 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
linux-phy, linux-stm32, Neil Armstrong, netdev, Paolo Abeni,
Vinod Koul
In-Reply-To: <E1vxS44-0000000BQXU-38lG@rmk-PC.armlinux.org.uk>
On Tue, Mar 03, 2026 at 03:53:40PM +0000, Russell King (Oracle) wrote:
> qcom-sgmii-eth now accepts the phy_set_mode*() calls to configure the
> SerDes, taking a PHY interface mode rather than a speed. This allows
> the elimination of the interface mode to speed conversion in
> ethqos_mac_finish_serdes().
>
> Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Ayaan
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: qualcomm: usb-hs-28nm: use flex array
From: Gustavo A. R. Silva @ 2026-03-05 4:52 UTC (permalink / raw)
To: Konrad Dybcio, Rosen Penev, linux-phy
Cc: Vinod Koul, Neil Armstrong, Kees Cook, Gustavo A. R. Silva,
open list:ARM/QUALCOMM MAILING LIST, open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <8d7a25e8-3af6-4adf-bcec-394895519bea@oss.qualcomm.com>
Hi!
On 3/5/26 19:06, Konrad Dybcio wrote:
> On 3/5/26 12:06 AM, Rosen Penev wrote:
>> Allows simplifying allocation to a single kzalloc call.
>>
>> Also allows using __counted_by for extra runtime analysis.
>>
>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
>> ---
>
> I don't see how this is an improvement - __counted_by() is useful for
> cases where we don't know how many entries there are, but in this
> case it's fully deterministic (as priv->num_clks is a compile-time
> constant)
Will this always be the case in the future (entries being a compile-time
constant)?
Thanks
-Gustavo
>
> Konrad
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: cadence: Sierra: Do not modify register when getting parent clock
From: kernel test robot @ 2026-03-06 2:45 UTC (permalink / raw)
To: Gregory CLEMENT, Vinod Koul, Neil Armstrong, Aswath Govindraju,
Swapnil Jakhade
Cc: oe-kbuild-all, Théo Lebrun, Thomas Petazzoni, linux-phy,
linux-kernel, Gregory CLEMENT
In-Reply-To: <20260305-fix_sierra_get_parent-v1-1-a7c18e9e6c58@bootlin.com>
Hi Gregory,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 11439c4635edd669ae435eec308f4ab8a0804808]
url: https://github.com/intel-lab-lkp/linux/commits/Gregory-CLEMENT/phy-cadence-Sierra-Do-not-modify-register-when-getting-parent-clock/20260306-000915
base: 11439c4635edd669ae435eec308f4ab8a0804808
patch link: https://lore.kernel.org/r/20260305-fix_sierra_get_parent-v1-1-a7c18e9e6c58%40bootlin.com
patch subject: [PATCH] phy: cadence: Sierra: Do not modify register when getting parent clock
config: xtensa-randconfig-001-20260306 (https://download.01.org/0day-ci/archive/20260306/202603061235.hrl27Jvj-lkp@intel.com/config)
compiler: xtensa-linux-gcc (GCC) 8.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260306/202603061235.hrl27Jvj-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/202603061235.hrl27Jvj-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/phy/cadence/phy-cadence-sierra.c: In function 'cdns_sierra_pll_mux_get_parent':
>> drivers/phy/cadence/phy-cadence-sierra.c:702:23: warning: unused variable 'termen_field' [-Wunused-variable]
struct regmap_field *termen_field = mux->termen_field;
^~~~~~~~~~~~
>> drivers/phy/cadence/phy-cadence-sierra.c:701:23: warning: unused variable 'plllc1en_field' [-Wunused-variable]
struct regmap_field *plllc1en_field = mux->plllc1en_field;
^~~~~~~~~~~~~~
vim +/termen_field +702 drivers/phy/cadence/phy-cadence-sierra.c
d88ca22d6f0c924 Aswath Govindraju 2022-01-28 697
28081b72859f0fa Kishon Vijay Abraham I 2021-03-19 698 static u8 cdns_sierra_pll_mux_get_parent(struct clk_hw *hw)
28081b72859f0fa Kishon Vijay Abraham I 2021-03-19 699 {
28081b72859f0fa Kishon Vijay Abraham I 2021-03-19 700 struct cdns_sierra_pll_mux *mux = to_cdns_sierra_pll_mux(hw);
da08aab940092a0 Swapnil Jakhade 2021-12-23 @701 struct regmap_field *plllc1en_field = mux->plllc1en_field;
da08aab940092a0 Swapnil Jakhade 2021-12-23 @702 struct regmap_field *termen_field = mux->termen_field;
28081b72859f0fa Kishon Vijay Abraham I 2021-03-19 703 struct regmap_field *field = mux->pfdclk_sel_preg;
28081b72859f0fa Kishon Vijay Abraham I 2021-03-19 704 unsigned int val;
da08aab940092a0 Swapnil Jakhade 2021-12-23 705 int index;
28081b72859f0fa Kishon Vijay Abraham I 2021-03-19 706
28081b72859f0fa Kishon Vijay Abraham I 2021-03-19 707 regmap_field_read(field, &val);
da08aab940092a0 Swapnil Jakhade 2021-12-23 708
4f20466dcc453ec Gregory CLEMENT 2026-03-05 709 if (strstr(clk_hw_get_name(hw), clk_names[CDNS_SIERRA_PLL_CMNLC1]))
da08aab940092a0 Swapnil Jakhade 2021-12-23 710 index = clk_mux_val_to_index(hw, cdns_sierra_pll_mux_table[CMN_PLLLC1], 0, val);
4f20466dcc453ec Gregory CLEMENT 2026-03-05 711 else
da08aab940092a0 Swapnil Jakhade 2021-12-23 712 index = clk_mux_val_to_index(hw, cdns_sierra_pll_mux_table[CMN_PLLLC], 0, val);
da08aab940092a0 Swapnil Jakhade 2021-12-23 713
da08aab940092a0 Swapnil Jakhade 2021-12-23 714 return index;
28081b72859f0fa Kishon Vijay Abraham I 2021-03-19 715 }
28081b72859f0fa Kishon Vijay Abraham I 2021-03-19 716
--
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 net-next v2 0/7] net: stmmac: qcom-ethqos: further serdes reorganisation
From: patchwork-bot+netdevbpf @ 2026-03-06 3:32 UTC (permalink / raw)
To: Russell King
Cc: andrew, alexandre.torgue, andrew+netdev, davem, edumazet, kuba,
linux-arm-kernel, linux-arm-msm, linux-phy, linux-stm32,
mohd.anwar, neil.armstrong, netdev, pabeni, vkoul
In-Reply-To: <aacD3osfaZkLsGxm@shell.armlinux.org.uk>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 3 Mar 2026 15:53:02 +0000 you wrote:
> This is part 2 of the qcom-ethqos series, part 1 and patch 2 of part 2
> has now been merged.
>
> This part of the series focuses on the generic PHY driver, but these
> changes have dependencies on the ethernet driver, hence why
> it will need to go via net-next. Furthermore, subsequent changes
> depend on these patches.
>
> [...]
Here is the summary with links:
- [net-next,v2,1/7] net: stmmac: qcom-ethqos: move ethqos_set_serdes_speed()
https://git.kernel.org/netdev/net-next/c/fc8ca5da896e
- [net-next,v2,2/7] net: stmmac: qcom-ethqos: convert to use phy_set_mode_ext()
https://git.kernel.org/netdev/net-next/c/4999e0a2ab34
- [net-next,v2,3/7] phy: qcom-sgmii-eth: remove .set_speed() implementation
https://git.kernel.org/netdev/net-next/c/b7721597547d
- [net-next,v2,4/7] phy: qcom-sgmii-eth: use PHY interface mode for SerDes settings
https://git.kernel.org/netdev/net-next/c/d2b20acdaed8
- [net-next,v2,5/7] phy: qcom-sgmii-eth: remove qcom_dwmac_sgmii_phy_interface()
https://git.kernel.org/netdev/net-next/c/f82210ce8cb8
- [net-next,v2,6/7] phy: qcom-sgmii-eth: relax order of .power_on() vs .set_mode*()
https://git.kernel.org/netdev/net-next/c/ebe8b48b88ad
- [net-next,v2,7/7] net: stmmac: qcom-ethqos: remove phy_set_mode_ext() after phy_power_on()
https://git.kernel.org/netdev/net-next/c/038a8e8eb90d
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
--
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-06 5: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,
Chaotian Jing (井朝天), conor+dt@kernel.org,
lgirdwood@gmail.com, nicolas.frattaroli@collabora.com,
vkoul@kernel.org, krzk+dt@kernel.org, p.zabel@pengutronix.de,
alim.akhtar@samsung.com, neil.armstrong@linaro.org,
matthias.bgg@gmail.com, avri.altman@wdc.com, broonie@kernel.org,
martin.petersen@oracle.com
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: <3472277.mvXUDI8C0e@workhorse>
On Thu, 2026-03-05 at 10:57 +0100, Nicolas Frattaroli wrote:
>
> 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.
>
I thought ensuring that every patch builds successfully
was a basic requirement.
--
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: Qiang Yu @ 2026-03-06 9:26 UTC (permalink / raw)
To: Konrad Dybcio
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: <42a9dd4d-eb96-42c0-b836-dcd7cb9405ff@oss.qualcomm.com>
On Thu, Mar 05, 2026 at 10:14:05AM +0100, Konrad Dybcio wrote:
> 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
>
I understand your suggestion would look like below. I agree that the
unified PHY approach being more elegant from a device tree perspective,
provide better DT flexibility and eliminate the need for different
compatibles and dupicated resources between 1x8 and 2x4 modes.
However, this will include implementation complexity to phy driver.
The driver would need conditional logic to selectively enable different
clocks/resets based on the PHY parameter and maintain mode-specific
resource arrays. There's also the issue that assigned-clocks
GCC_PCIE_3A_PHY_RCHNG_CLK and GCC_PCIE_3B_PHY_RCHNG_CLK will be set before
probe no matter which mode is used, even though in 1x8 mode or only one of
them is actually needed. For pipe clock outputs, only pcie3a_pipe_clk would
be needed in 1x8 mode while pcie3b_pipe_clk would be unused. For
powerdomain, we also need to add additional logic to attach and turn
on/off them.
While these challenges could be resolved, I'm not sure the benefits
justify the added complexity.
pcie3_unified_phy {
compatible = "qcom,glymur-qmp-gen5-pcie-phy";
reg = <0 0x00f00000 0 0x10000>, <0 0x00f10000 0 0x10000>; /* Both PHY ranges */
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>,
<&gcc GCC_PCIE_3B_CFG_AHB_CLK>,
<&gcc GCC_PCIE_3B_PHY_RCHNG_CLK>,
<&gcc GCC_PCIE_3B_PIPE_CLK>,
<&gcc GCC_PCIE_3B_PIPE_DIV2_CLK>;
power-domains = <&gcc GCC_PCIE_3A_PHY_GDSC>,
<&gcc GCC_PCIE_3B_PHY_GDSC>;
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>;
#clock-cells = <1>;
clock-output-names = "pcie3a_pipe_clk", "pcie3b_pipe_clk";
assigned-clocks = <&gcc GCC_PCIE_3A_PHY_RCHNG_CLK>,
<&gcc GCC_PCIE_3B_PHY_RCHNG_CLK>;
assigned-clock-rates = <100000000>, <100000000>;
#phy-cells = <1>; /* Parameter: 0=PHY_A, 1=PHY_B, 2=UNIFIED_8LANE */
};
For 2x4 mode (independent 4-lane PHYs):
&pcie3a {
phys = <&pcie3_unified_phy PHY_A>; /* PHY A only */
status = "okay";
};
&pcie3b {
phys = <&pcie3_unified_phy PHY_B>; /* PHY B only */
status = "okay";
};
For 1x8 mode (unified 8-lane PHY):
&pcie3a {
phys = <&pcie3_unified_phy PHY_AB>;
num-lanes = <8>;
status = "okay";
};
&pcie3b {
status = "disabled";
};
- Qiang Yu
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 2/2] phy: Add driver for EyeQ5 Ethernet PHY wrapper
From: Théo Lebrun @ 2026-03-06 9:53 UTC (permalink / raw)
To: Vladimir Oltean, Théo Lebrun
Cc: Vinod Koul, Neil Armstrong, linux-phy, linux-kernel, linux-mips,
Vladimir Kondratiev, Gregory CLEMENT, Benoît Monin,
Tawfik Bayouk, Thomas Petazzoni, Luca Ceresoli
In-Reply-To: <20260227171446.mqygrv35s5jdae46@skbuf>
Hello Vladimir,
On Fri Feb 27, 2026 at 6:14 PM CET, Vladimir Oltean wrote:
> On Wed, Feb 25, 2026 at 05:54:41PM +0100, Théo Lebrun wrote:
>> +static int eq5_phy_set_mode(struct phy *phy, enum phy_mode mode, int submode)
>> +{
>> + struct eq5_phy_inst *inst = phy_get_drvdata(phy);
>> +
>> + if (eq5_phy_validate(phy, mode, submode, NULL))
>> + return -EOPNOTSUPP;
>
> Propagate the phy_validate() return code, don't generate your own.
> -EINVAL should be preferable to -EOPNOTSUPP, so that callers can
> distinguish between "phy_set_mode() not implemented" and "phy_set_mode()
> failed".
ACK. I had made the decision to explicitely override the return value
but indeed EOPNOTSUPP isn't the cleverest option. Will fix.
> (yeah, phy_set_mode() was made optional a while ago, IMO incorrectly,
> but that's another story)
>
>> +
>> + if (submode == inst->phy_interface)
>> + return 0;
>
> I think this simple comparison fails to serve its intended purpose
> (avoid PHY reset when not changing modes) for RGMII modes, of which
> there exist 4 variants.
Yes!
> Maybe:
> if ((phy_interface_mode_is_rgmii(submode) &&
> phy_interface_mode_is_rgmii(inst->phy_interface)) ||
> submode == inst->phy_interface)
> return 0;
>
> Does the EyeQ5 platform support internal RGMII delays? If yes, which
> layer enables them? The Generic PHY?
You are on point. We shouldn't care about the RGMII delays inside the
generic PHY driver. What we deal with here is a wrapper to the actual
net PHY behind the scenes. The net PHY is dealing with delays, we can
ignore them in the generic PHY driver.
Will fix, either with your solution or with a custom two state enum that
can do SGMII or RGMII (will represent all RGMII delay variants). I'll
experiment with both and send what looks better.
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.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 07/22] net: lan969x: include missing <linux/of.h>
From: Daniel Machon @ 2026-03-06 9:56 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,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Steen Hegelund
In-Reply-To: <20260304175735.2660419-8-vladimir.oltean@nxp.com>
> This file is calling of_property_read_u32() without including the proper
> header for it. It is provided by <linux/phy/phy.h>, which wants to get
> rid of it.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> Cc: Daniel Machon <daniel.machon@microchip.com>
> Cc: Andrew Lunn <andrew+netdev@lunn.ch>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Steen Hegelund <Steen.Hegelund@microchip.com>
> ---
> drivers/net/ethernet/microchip/sparx5/lan969x/lan969x_rgmii.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ethernet/microchip/sparx5/lan969x/lan969x_rgmii.c b/drivers/net/ethernet/microchip/sparx5/lan969x/lan969x_rgmii.c
> index 4e422ca50828..249114b40c42 100644
> --- a/drivers/net/ethernet/microchip/sparx5/lan969x/lan969x_rgmii.c
> +++ b/drivers/net/ethernet/microchip/sparx5/lan969x/lan969x_rgmii.c
> @@ -4,6 +4,7 @@
> * Copyright (c) 2024 Microchip Technology Inc. and its subsidiaries.
> */
>
> +#include <linux/of.h>
> #include "lan969x.h"
>
> /* Tx clock selectors */
> --
> 2.43.0
>
Acked-by: Daniel Machon <daniel.machon@microchip.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2] phy: cadence: Sierra: Do not modify register when getting parent clock
From: Gregory CLEMENT @ 2026-03-06 10:23 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Aswath Govindraju, Swapnil Jakhade
Cc: Théo Lebrun, Thomas Petazzoni, Vladimir Kondratiev,
linux-phy, linux-kernel, Gregory CLEMENT
The get_parent() callback for the PLL_CMNLC1 clock was incorrectly
writing to the register while determining the parent clock index. This
unintended register access forces the PHY back into training mode. If
the PHY is already configured, this unexpected change prevents it from
exiting training mode.
Remove the register write operation to ensure the PHY remains stable
during the get_parent() callback.
Fixes: da08aab940092 ("phy: cadence: Sierra: Fix to get correct parent for mux clocks")
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
Changes in v2:
- Removed unused variable spotted by the 0-DAY CI Kernel Test Service:
https://lore.kernel.org/oe-kbuild-all/202603061235.hrl27Jvj-lkp@intel.com/
- Link to v1: https://lore.kernel.org/r/20260305-fix_sierra_get_parent-v1-1-a7c18e9e6c58@bootlin.com
---
drivers/phy/cadence/phy-cadence-sierra.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/phy/cadence/phy-cadence-sierra.c b/drivers/phy/cadence/phy-cadence-sierra.c
index 92ab1a31646ae..dbeda7f01cbb2 100644
--- a/drivers/phy/cadence/phy-cadence-sierra.c
+++ b/drivers/phy/cadence/phy-cadence-sierra.c
@@ -698,23 +698,16 @@ static const struct phy_ops noop_ops = {
static u8 cdns_sierra_pll_mux_get_parent(struct clk_hw *hw)
{
struct cdns_sierra_pll_mux *mux = to_cdns_sierra_pll_mux(hw);
- struct regmap_field *plllc1en_field = mux->plllc1en_field;
- struct regmap_field *termen_field = mux->termen_field;
struct regmap_field *field = mux->pfdclk_sel_preg;
unsigned int val;
int index;
regmap_field_read(field, &val);
- if (strstr(clk_hw_get_name(hw), clk_names[CDNS_SIERRA_PLL_CMNLC1])) {
+ if (strstr(clk_hw_get_name(hw), clk_names[CDNS_SIERRA_PLL_CMNLC1]))
index = clk_mux_val_to_index(hw, cdns_sierra_pll_mux_table[CMN_PLLLC1], 0, val);
- if (index == 1) {
- regmap_field_write(plllc1en_field, 1);
- regmap_field_write(termen_field, 1);
- }
- } else {
+ else
index = clk_mux_val_to_index(hw, cdns_sierra_pll_mux_table[CMN_PLLLC], 0, val);
- }
return index;
}
---
base-commit: 11439c4635edd669ae435eec308f4ab8a0804808
change-id: 20260305-fix_sierra_get_parent-9c8435cc65e7
Best regards,
--
Grégory CLEMENT, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v2] phy: cadence: Sierra: Do not modify register when getting parent clock
From: Neil Armstrong @ 2026-03-06 10:29 UTC (permalink / raw)
To: Gregory CLEMENT, Vinod Koul, Aswath Govindraju, Swapnil Jakhade
Cc: Théo Lebrun, Thomas Petazzoni, Vladimir Kondratiev,
linux-phy, linux-kernel
In-Reply-To: <20260306-fix_sierra_get_parent-v2-1-cafe89ee5382@bootlin.com>
On 3/6/26 11:23, Gregory CLEMENT wrote:
> The get_parent() callback for the PLL_CMNLC1 clock was incorrectly
> writing to the register while determining the parent clock index. This
> unintended register access forces the PHY back into training mode. If
> the PHY is already configured, this unexpected change prevents it from
> exiting training mode.
>
> Remove the register write operation to ensure the PHY remains stable
> during the get_parent() callback.
>
> Fixes: da08aab940092 ("phy: cadence: Sierra: Fix to get correct parent for mux clocks")
> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
> ---
> Changes in v2:
>
> - Removed unused variable spotted by the 0-DAY CI Kernel Test Service:
> https://lore.kernel.org/oe-kbuild-all/202603061235.hrl27Jvj-lkp@intel.com/
> - Link to v1: https://lore.kernel.org/r/20260305-fix_sierra_get_parent-v1-1-a7c18e9e6c58@bootlin.com
> ---
> drivers/phy/cadence/phy-cadence-sierra.c | 11 ++---------
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/phy/cadence/phy-cadence-sierra.c b/drivers/phy/cadence/phy-cadence-sierra.c
> index 92ab1a31646ae..dbeda7f01cbb2 100644
> --- a/drivers/phy/cadence/phy-cadence-sierra.c
> +++ b/drivers/phy/cadence/phy-cadence-sierra.c
> @@ -698,23 +698,16 @@ static const struct phy_ops noop_ops = {
> static u8 cdns_sierra_pll_mux_get_parent(struct clk_hw *hw)
> {
> struct cdns_sierra_pll_mux *mux = to_cdns_sierra_pll_mux(hw);
> - struct regmap_field *plllc1en_field = mux->plllc1en_field;
> - struct regmap_field *termen_field = mux->termen_field;
> struct regmap_field *field = mux->pfdclk_sel_preg;
> unsigned int val;
> int index;
>
> regmap_field_read(field, &val);
>
> - if (strstr(clk_hw_get_name(hw), clk_names[CDNS_SIERRA_PLL_CMNLC1])) {
> + if (strstr(clk_hw_get_name(hw), clk_names[CDNS_SIERRA_PLL_CMNLC1]))
> index = clk_mux_val_to_index(hw, cdns_sierra_pll_mux_table[CMN_PLLLC1], 0, val);
> - if (index == 1) {
> - regmap_field_write(plllc1en_field, 1);
> - regmap_field_write(termen_field, 1);
> - }
> - } else {
> + else
> index = clk_mux_val_to_index(hw, cdns_sierra_pll_mux_table[CMN_PLLLC], 0, val);
> - }
>
> return index;
> }
>
> ---
> base-commit: 11439c4635edd669ae435eec308f4ab8a0804808
> change-id: 20260305-fix_sierra_get_parent-9c8435cc65e7
>
> Best regards,
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
--
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: Neil Armstrong @ 2026-03-06 10:34 UTC (permalink / raw)
To: Qiang Yu, Konrad Dybcio
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-phy, devicetree, linux-kernel
In-Reply-To: <aaqdv7Zx5AODzg6P@hu-qianyu-lv.qualcomm.com>
On 3/6/26 10:26, Qiang Yu wrote:
> On Thu, Mar 05, 2026 at 10:14:05AM +0100, Konrad Dybcio wrote:
>> 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
DT requires strict hardware description, no abstraction for HW, so if there's
2 PHYs, then add 2 separate phys and reference them from the PCie controller.
On platforms where you want 2x4, then add 2 pcie_ports using 2 phys, on platforms
with 1x8 a single pcie_port with 2 phys.
Neil
>>
> I understand your suggestion would look like below. I agree that the
> unified PHY approach being more elegant from a device tree perspective,
> provide better DT flexibility and eliminate the need for different
> compatibles and dupicated resources between 1x8 and 2x4 modes.
>
> However, this will include implementation complexity to phy driver.
> The driver would need conditional logic to selectively enable different
> clocks/resets based on the PHY parameter and maintain mode-specific
> resource arrays. There's also the issue that assigned-clocks
> GCC_PCIE_3A_PHY_RCHNG_CLK and GCC_PCIE_3B_PHY_RCHNG_CLK will be set before
> probe no matter which mode is used, even though in 1x8 mode or only one of
> them is actually needed. For pipe clock outputs, only pcie3a_pipe_clk would
> be needed in 1x8 mode while pcie3b_pipe_clk would be unused. For
> powerdomain, we also need to add additional logic to attach and turn
> on/off them.
>
> While these challenges could be resolved, I'm not sure the benefits
> justify the added complexity.
>
> pcie3_unified_phy {
> compatible = "qcom,glymur-qmp-gen5-pcie-phy";
> reg = <0 0x00f00000 0 0x10000>, <0 0x00f10000 0 0x10000>; /* Both PHY ranges */
>
> 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>,
> <&gcc GCC_PCIE_3B_CFG_AHB_CLK>,
> <&gcc GCC_PCIE_3B_PHY_RCHNG_CLK>,
> <&gcc GCC_PCIE_3B_PIPE_CLK>,
> <&gcc GCC_PCIE_3B_PIPE_DIV2_CLK>;
>
> power-domains = <&gcc GCC_PCIE_3A_PHY_GDSC>,
> <&gcc GCC_PCIE_3B_PHY_GDSC>;
>
> 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>;
>
> #clock-cells = <1>;
> clock-output-names = "pcie3a_pipe_clk", "pcie3b_pipe_clk";
> assigned-clocks = <&gcc GCC_PCIE_3A_PHY_RCHNG_CLK>,
> <&gcc GCC_PCIE_3B_PHY_RCHNG_CLK>;
> assigned-clock-rates = <100000000>, <100000000>;
>
> #phy-cells = <1>; /* Parameter: 0=PHY_A, 1=PHY_B, 2=UNIFIED_8LANE */
> };
>
> For 2x4 mode (independent 4-lane PHYs):
> &pcie3a {
> phys = <&pcie3_unified_phy PHY_A>; /* PHY A only */
> status = "okay";
> };
>
> &pcie3b {
> phys = <&pcie3_unified_phy PHY_B>; /* PHY B only */
> status = "okay";
> };
>
> For 1x8 mode (unified 8-lane PHY):
>
> &pcie3a {
> phys = <&pcie3_unified_phy PHY_AB>;
> num-lanes = <8>;
> status = "okay";
> };
>
> &pcie3b {
> status = "disabled";
> };
>
> - Qiang Yu
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: renesas: rzg3e-usb3: Convert to FIELD_MODIFY()
From: Neil Armstrong @ 2026-03-06 10:35 UTC (permalink / raw)
To: Geert Uytterhoeven, Vinod Koul, Biju Das; +Cc: linux-phy, linux-renesas-soc
In-Reply-To: <a52020ba597e2e213b161eee21239f10e6057d9d.1772705690.git.geert+renesas@glider.be>
On 3/5/26 11:15, Geert Uytterhoeven wrote:
> Use the FIELD_MODIFY() helper instead of open-coding the same operation.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> No changes in generated code.
> ---
> drivers/phy/renesas/phy-rzg3e-usb3.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/phy/renesas/phy-rzg3e-usb3.c b/drivers/phy/renesas/phy-rzg3e-usb3.c
> index 6b3453ea0004cf59..7f809ef1bb5135ec 100644
> --- a/drivers/phy/renesas/phy-rzg3e-usb3.c
> +++ b/drivers/phy/renesas/phy-rzg3e-usb3.c
> @@ -78,13 +78,11 @@ static void rzg3e_phy_usb2test_phy_init(void __iomem *base)
> writel(val, base + USB3_TEST_UTMICTRL2);
>
> val = readl(base + USB3_TEST_PRMCTRL5_R);
> - val &= ~USB3_TEST_PRMCTRL5_R_TXPREEMPAMPTUNE0_MASK;
> - val |= FIELD_PREP(USB3_TEST_PRMCTRL5_R_TXPREEMPAMPTUNE0_MASK, 2);
> + FIELD_MODIFY(USB3_TEST_PRMCTRL5_R_TXPREEMPAMPTUNE0_MASK, &val, 2);
> writel(val, base + USB3_TEST_PRMCTRL5_R);
>
> val = readl(base + USB3_TEST_PRMCTRL6_R);
> - val &= ~USB3_TEST_PRMCTRL6_R_OTGTUNE0_MASK;
> - val |= FIELD_PREP(USB3_TEST_PRMCTRL6_R_OTGTUNE0_MASK, 7);
> + FIELD_MODIFY(USB3_TEST_PRMCTRL6_R_OTGTUNE0_MASK, &val, 7);
> writel(val, base + USB3_TEST_PRMCTRL6_R);
>
> val = readl(base + USB3_TEST_RESET);
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
--
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: Neil Armstrong @ 2026-03-06 10:36 UTC (permalink / raw)
To: Dmitry Baryshkov, 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, Krishna Manikandan, Jonathan Marek
Cc: 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 3/5/26 00:47, 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.
> ---
> .../{display/msm/dsi-phy-10nm.yaml => phy/qcom,dsi-phy-10nm.yaml} | 4 ++--
> .../{display/msm/dsi-phy-14nm.yaml => phy/qcom,dsi-phy-14nm.yaml} | 4 ++--
> .../{display/msm/dsi-phy-20nm.yaml => phy/qcom,dsi-phy-20nm.yaml} | 4 ++--
> .../{display/msm/dsi-phy-28nm.yaml => phy/qcom,dsi-phy-28nm.yaml} | 4 ++--
> .../{display/msm/dsi-phy-7nm.yaml => phy/qcom,dsi-phy-7nm.yaml} | 4 ++--
> .../{display/msm/dsi-phy-common.yaml => phy/qcom,dsi-phy-common.yaml} | 2 +-
> 6 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-10nm.yaml
> similarity index 96%
> rename from Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
> rename to Documentation/devicetree/bindings/phy/qcom,dsi-phy-10nm.yaml
> index fc9abf090f0d..d98217747ad1 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-10nm.yaml
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> %YAML 1.2
> ---
> -$id: http://devicetree.org/schemas/display/msm/dsi-phy-10nm.yaml#
> +$id: http://devicetree.org/schemas/phy/qcom,dsi-phy-10nm.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> title: Qualcomm Display DSI 10nm PHY
> @@ -10,7 +10,7 @@ maintainers:
> - Krishna Manikandan <quic_mkrishn@quicinc.com>
>
> allOf:
> - - $ref: dsi-phy-common.yaml#
> + - $ref: qcom,dsi-phy-common.yaml#
>
> properties:
> compatible:
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-14nm.yaml
> similarity index 94%
> rename from Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
> rename to Documentation/devicetree/bindings/phy/qcom,dsi-phy-14nm.yaml
> index 206a9a4b3845..be31b9bac9d5 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-14nm.yaml
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> %YAML 1.2
> ---
> -$id: http://devicetree.org/schemas/display/msm/dsi-phy-14nm.yaml#
> +$id: http://devicetree.org/schemas/phy/qcom,dsi-phy-14nm.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> title: Qualcomm Display DSI 14nm PHY
> @@ -10,7 +10,7 @@ maintainers:
> - Krishna Manikandan <quic_mkrishn@quicinc.com>
>
> allOf:
> - - $ref: dsi-phy-common.yaml#
> + - $ref: qcom,dsi-phy-common.yaml#
>
> properties:
> compatible:
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-20nm.yaml
> similarity index 93%
> rename from Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml
> rename to Documentation/devicetree/bindings/phy/qcom,dsi-phy-20nm.yaml
> index 93570052992a..1d135419d015 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-20nm.yaml
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> %YAML 1.2
> ---
> -$id: http://devicetree.org/schemas/display/msm/dsi-phy-20nm.yaml#
> +$id: http://devicetree.org/schemas/phy/qcom,dsi-phy-20nm.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> title: Qualcomm Display DSI 20nm PHY
> @@ -10,7 +10,7 @@ maintainers:
> - Krishna Manikandan <quic_mkrishn@quicinc.com>
>
> allOf:
> - - $ref: dsi-phy-common.yaml#
> + - $ref: qcom,dsi-phy-common.yaml#
>
> properties:
> compatible:
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-28nm.yaml
> similarity index 94%
> rename from Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
> rename to Documentation/devicetree/bindings/phy/qcom,dsi-phy-28nm.yaml
> index 371befa9f9d2..f8fe75fa29d7 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-28nm.yaml
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> %YAML 1.2
> ---
> -$id: http://devicetree.org/schemas/display/msm/dsi-phy-28nm.yaml#
> +$id: http://devicetree.org/schemas/phy/qcom,dsi-phy-28nm.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> title: Qualcomm Display DSI 28nm PHY
> @@ -10,7 +10,7 @@ maintainers:
> - Krishna Manikandan <quic_mkrishn@quicinc.com>
>
> allOf:
> - - $ref: dsi-phy-common.yaml#
> + - $ref: qcom,dsi-phy-common.yaml#
>
> properties:
> compatible:
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-7nm.yaml
> similarity index 95%
> rename from Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml
> rename to Documentation/devicetree/bindings/phy/qcom,dsi-phy-7nm.yaml
> index 9a9a6c4abf43..d45015e24639 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-7nm.yaml
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> %YAML 1.2
> ---
> -$id: http://devicetree.org/schemas/display/msm/dsi-phy-7nm.yaml#
> +$id: http://devicetree.org/schemas/phy/qcom,dsi-phy-7nm.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> title: Qualcomm Display DSI 7nm PHY
> @@ -10,7 +10,7 @@ maintainers:
> - Jonathan Marek <jonathan@marek.ca>
>
> allOf:
> - - $ref: dsi-phy-common.yaml#
> + - $ref: qcom,dsi-phy-common.yaml#
>
> properties:
> compatible:
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-common.yaml
> similarity index 91%
> rename from Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml
> rename to Documentation/devicetree/bindings/phy/qcom,dsi-phy-common.yaml
> index d0ce85a08b6d..849321e56b2f 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,dsi-phy-common.yaml
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> %YAML 1.2
> ---
> -$id: http://devicetree.org/schemas/display/msm/dsi-phy-common.yaml#
> +$id: http://devicetree.org/schemas/phy/qcom,dsi-phy-common.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> title: Qualcomm Display DSI PHY Common Properties
>
> ---
> base-commit: ac47870fd795549f03d57e0879fc730c79119f4b
> change-id: 20260305-msm-dsi-phy-96b063cce7b5
>
> Best regards,
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] phy: rockchip: naneng-combphy: Consolidate SSC configuration
From: Neil Armstrong @ 2026-03-06 10:38 UTC (permalink / raw)
To: Shawn Lin, Vinod Koul
Cc: linux-rockchip, linux-phy, Heiko Stuebner, linux-kernel
In-Reply-To: <1772696450-139583-1-git-send-email-shawn.lin@rock-chips.com>
On 3/5/26 08:40, Shawn Lin wrote:
> The PCIe SSC configuration for the RK3588 and RK3576 SoCs required
> additional tuning which is missing. When adding these same SSC
> configurations for both of these two SoCs, as well as upcoming
> platforms, it's obvious the SSC setup code was largely duplicated
> across the platform-specific configuration functions. This becomes
> harder to maintain as more platforms are added.
>
> So extract the common SSC logic into a shared helper function,
> rk_combphy_common_cfg_ssc(). This cleans up the per-platform drivers
> and centralizes the standard configuration as possible.
>
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>
> ---
>
> Changes in v2:
> - rework to consolidate more configuration
> - reword the commit message
>
> drivers/phy/rockchip/phy-rockchip-naneng-combphy.c | 173 +++++++++------------
> 1 file changed, 73 insertions(+), 100 deletions(-)
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c b/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
> index b60d6bf..2b0f152 100644
> --- a/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
> +++ b/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
> @@ -121,6 +121,7 @@
> #define RK3568_PHYREG32_SSC_OFFSET_500PPM 1
>
> #define RK3568_PHYREG33 0x80
> +#define RK3568_PHYREG33_PLL_SSC_CTRL BIT(5)
> #define RK3568_PHYREG33_PLL_KVCO_MASK GENMASK(4, 2)
> #define RK3568_PHYREG33_PLL_KVCO_SHIFT 2
> #define RK3568_PHYREG33_PLL_KVCO_VALUE 2
> @@ -446,6 +447,74 @@ static int rockchip_combphy_probe(struct platform_device *pdev)
> return PTR_ERR_OR_ZERO(phy_provider);
> }
>
> +static void rk_combphy_common_cfg_ssc(struct rockchip_combphy_priv *priv, unsigned long rate)
> +{
> + struct device_node *np = priv->dev->of_node;
> + u32 val;
> +
> + if (!priv->enable_ssc)
> + return;
> +
> + /* Set SSC downward spread spectrum for PCIe and USB3 */
> + if (priv->type == PHY_TYPE_PCIE || priv->type == PHY_TYPE_USB3) {
> + val = FIELD_PREP(RK3568_PHYREG32_SSC_MASK, RK3568_PHYREG32_SSC_DOWNWARD);
> + rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> + }
> +
> + /* Set SSC downward spread spectrum +500ppm for SATA in 100MHz */
> + if (priv->type == PHY_TYPE_SATA && rate == REF_CLOCK_100MHz) {
> + val = FIELD_PREP(RK3568_PHYREG32_SSC_DIR_MASK,
> + RK3568_PHYREG32_SSC_DOWNWARD);
> + val |= FIELD_PREP(RK3568_PHYREG32_SSC_OFFSET_MASK,
> + RK3568_PHYREG32_SSC_OFFSET_500PPM);
> + rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val,
> + RK3568_PHYREG32);
> + }
> +
> + /* Enable SSC */
> + val = readl(priv->mmio + RK3568_PHYREG8);
> + val |= RK3568_PHYREG8_SSC_EN;
> + writel(val, priv->mmio + RK3568_PHYREG8);
> +
> + /* Some SoCs need tuning PCIe SSC instead of default configuration in 24MHz */
> + if (!of_device_is_compatible(np, "rockchip,rk3588-naneng-combphy") &&
> + !of_device_is_compatible(np, "rockchip,rk3576-naneng-combphy"))
> + return;
> +
> + /* PLL control SSC module period should be set if need tuning */
> + val = readl(priv->mmio + RK3568_PHYREG33);
> + val |= RK3568_PHYREG33_PLL_SSC_CTRL;
> + writel(val, priv->mmio + RK3568_PHYREG33);
> +
> + if (priv->type == PHY_TYPE_PCIE && rate == REF_CLOCK_24MHz) {
> + /* Set PLL loop divider */
> + writel(0x00, priv->mmio + RK3576_PHYREG17);
> + writel(RK3568_PHYREG18_PLL_LOOP, priv->mmio + RK3568_PHYREG18);
> +
> + /* Set up rx_pck invert and rx msb to disable */
> + writel(0x00, priv->mmio + RK3588_PHYREG27);
> +
> + /*
> + * Set up SU adjust signal:
> + * su_trim[7:0], PLL KVCO adjust bits[2:0] to min
> + * su_trim[15:8], PLL LPF R1 adujst bits[9:7]=3'b101
> + * su_trim[23:16], CKRCV adjust
> + * su_trim[31:24], CKDRV adjust
> + */
> + writel(0x90, priv->mmio + RK3568_PHYREG11);
> + writel(0x02, priv->mmio + RK3568_PHYREG12);
> + writel(0x08, priv->mmio + RK3568_PHYREG13);
> + writel(0x57, priv->mmio + RK3568_PHYREG14);
> + writel(0x40, priv->mmio + RK3568_PHYREG15);
> +
> + writel(RK3568_PHYREG16_SSC_CNT_VALUE, priv->mmio + RK3568_PHYREG16);
> +
> + val = FIELD_PREP(RK3568_PHYREG33_PLL_KVCO_MASK,
> + RK3576_PHYREG33_PLL_KVCO_VALUE);
> + writel(val, priv->mmio + RK3568_PHYREG33);
> + }
> +}
> +
> static int rk3528_combphy_cfg(struct rockchip_combphy_priv *priv)
> {
> const struct rockchip_combphy_grfcfg *cfg = priv->cfg->grfcfg;
> @@ -600,21 +669,12 @@ static int rk3562_combphy_cfg(struct rockchip_combphy_priv *priv)
>
> switch (priv->type) {
> case PHY_TYPE_PCIE:
> - /* Set SSC downward spread spectrum */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT;
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> -
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con0_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con1_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con2_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con3_for_pcie, true);
> break;
> case PHY_TYPE_USB3:
> - /* Set SSC downward spread spectrum */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT;
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val,
> - RK3568_PHYREG32);
> -
> /* Enable adaptive CTLE for USB3.0 Rx */
> rockchip_combphy_updatel(priv, RK3568_PHYREG15_CTLE_EN,
> RK3568_PHYREG15_CTLE_EN, RK3568_PHYREG15);
> @@ -706,11 +766,7 @@ static int rk3562_combphy_cfg(struct rockchip_combphy_priv *priv)
> }
> }
>
> - if (priv->enable_ssc) {
> - val = readl(priv->mmio + RK3568_PHYREG8);
> - val |= RK3568_PHYREG8_SSC_EN;
> - writel(val, priv->mmio + RK3568_PHYREG8);
> - }
> + rk_combphy_common_cfg_ssc(priv, rate);
>
> return 0;
> }
> @@ -755,11 +811,6 @@ static int rk3568_combphy_cfg(struct rockchip_combphy_priv *priv)
>
> switch (priv->type) {
> case PHY_TYPE_PCIE:
> - /* Set SSC downward spread spectrum. */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT;
> -
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> -
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con0_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con1_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con2_for_pcie, true);
> @@ -767,10 +818,6 @@ static int rk3568_combphy_cfg(struct rockchip_combphy_priv *priv)
> break;
>
> case PHY_TYPE_USB3:
> - /* Set SSC downward spread spectrum. */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT,
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> -
> /* Enable adaptive CTLE for USB3.0 Rx. */
> val = readl(priv->mmio + RK3568_PHYREG15);
> val |= RK3568_PHYREG15_CTLE_EN;
> @@ -880,13 +927,6 @@ static int rk3568_combphy_cfg(struct rockchip_combphy_priv *priv)
>
> writel(RK3568_PHYREG18_PLL_LOOP, priv->mmio + RK3568_PHYREG18);
> writel(RK3568_PHYREG11_SU_TRIM_0_7, priv->mmio + RK3568_PHYREG11);
> - } else if (priv->type == PHY_TYPE_SATA) {
> - /* downward spread spectrum +500ppm */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT;
> - val |= RK3568_PHYREG32_SSC_OFFSET_500PPM <<
> - RK3568_PHYREG32_SSC_OFFSET_SHIFT;
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val,
> - RK3568_PHYREG32);
> }
> break;
>
> @@ -909,11 +949,7 @@ static int rk3568_combphy_cfg(struct rockchip_combphy_priv *priv)
> }
> }
>
> - if (priv->enable_ssc) {
> - val = readl(priv->mmio + RK3568_PHYREG8);
> - val |= RK3568_PHYREG8_SSC_EN;
> - writel(val, priv->mmio + RK3568_PHYREG8);
> - }
> + rk_combphy_common_cfg_ssc(priv, rate);
>
> return 0;
> }
> @@ -972,10 +1008,6 @@ static int rk3576_combphy_cfg(struct rockchip_combphy_priv *priv)
>
> switch (priv->type) {
> case PHY_TYPE_PCIE:
> - /* Set SSC downward spread spectrum */
> - val = FIELD_PREP(RK3568_PHYREG32_SSC_MASK, RK3568_PHYREG32_SSC_DOWNWARD);
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> -
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con0_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con1_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con2_for_pcie, true);
> @@ -983,10 +1015,6 @@ static int rk3576_combphy_cfg(struct rockchip_combphy_priv *priv)
> break;
>
> case PHY_TYPE_USB3:
> - /* Set SSC downward spread spectrum */
> - val = FIELD_PREP(RK3568_PHYREG32_SSC_MASK, RK3568_PHYREG32_SSC_DOWNWARD);
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> -
> /* Enable adaptive CTLE for USB3.0 Rx */
> val = readl(priv->mmio + RK3568_PHYREG15);
> val |= RK3568_PHYREG15_CTLE_EN;
> @@ -1110,14 +1138,6 @@ static int rk3576_combphy_cfg(struct rockchip_combphy_priv *priv)
> writel(0x88, priv->mmio + RK3568_PHYREG13);
> writel(0x56, priv->mmio + RK3568_PHYREG14);
> } else if (priv->type == PHY_TYPE_SATA) {
> - /* downward spread spectrum +500ppm */
> - val = FIELD_PREP(RK3568_PHYREG32_SSC_DIR_MASK,
> - RK3568_PHYREG32_SSC_DOWNWARD);
> - val |= FIELD_PREP(RK3568_PHYREG32_SSC_OFFSET_MASK,
> - RK3568_PHYREG32_SSC_OFFSET_500PPM);
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val,
> - RK3568_PHYREG32);
> -
> /* ssc ppm adjust to 3500ppm */
> rockchip_combphy_updatel(priv, RK3576_PHYREG10_SSC_PCM_MASK,
> RK3576_PHYREG10_SSC_PCM_3500PPM,
> @@ -1156,39 +1176,7 @@ static int rk3576_combphy_cfg(struct rockchip_combphy_priv *priv)
> }
> }
>
> - if (priv->enable_ssc) {
> - val = readl(priv->mmio + RK3568_PHYREG8);
> - val |= RK3568_PHYREG8_SSC_EN;
> - writel(val, priv->mmio + RK3568_PHYREG8);
> -
> - if (priv->type == PHY_TYPE_PCIE && rate == REF_CLOCK_24MHz) {
> - /* Set PLL loop divider */
> - writel(0x00, priv->mmio + RK3576_PHYREG17);
> - writel(RK3568_PHYREG18_PLL_LOOP, priv->mmio + RK3568_PHYREG18);
> -
> - /* Set up rx_pck invert and rx msb to disable */
> - writel(0x00, priv->mmio + RK3588_PHYREG27);
> -
> - /*
> - * Set up SU adjust signal:
> - * su_trim[7:0], PLL KVCO adjust bits[2:0] to min
> - * su_trim[15:8], PLL LPF R1 adujst bits[9:7]=3'b101
> - * su_trim[23:16], CKRCV adjust
> - * su_trim[31:24], CKDRV adjust
> - */
> - writel(0x90, priv->mmio + RK3568_PHYREG11);
> - writel(0x02, priv->mmio + RK3568_PHYREG12);
> - writel(0x08, priv->mmio + RK3568_PHYREG13);
> - writel(0x57, priv->mmio + RK3568_PHYREG14);
> - writel(0x40, priv->mmio + RK3568_PHYREG15);
> -
> - writel(RK3568_PHYREG16_SSC_CNT_VALUE, priv->mmio + RK3568_PHYREG16);
> -
> - val = FIELD_PREP(RK3568_PHYREG33_PLL_KVCO_MASK,
> - RK3576_PHYREG33_PLL_KVCO_VALUE);
> - writel(val, priv->mmio + RK3568_PHYREG33);
> - }
> - }
> + rk_combphy_common_cfg_ssc(priv, rate);
>
> return 0;
> }
> @@ -1255,10 +1243,6 @@ static int rk3588_combphy_cfg(struct rockchip_combphy_priv *priv)
> }
> break;
> case PHY_TYPE_USB3:
> - /* Set SSC downward spread spectrum */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT;
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> -
> /* Enable adaptive CTLE for USB3.0 Rx. */
> val = readl(priv->mmio + RK3568_PHYREG15);
> val |= RK3568_PHYREG15_CTLE_EN;
> @@ -1343,13 +1327,6 @@ static int rk3588_combphy_cfg(struct rockchip_combphy_priv *priv)
>
> /* Set up su_trim: */
> writel(RK3568_PHYREG11_SU_TRIM_0_7, priv->mmio + RK3568_PHYREG11);
> - } else if (priv->type == PHY_TYPE_SATA) {
> - /* downward spread spectrum +500ppm */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT;
> - val |= RK3568_PHYREG32_SSC_OFFSET_500PPM <<
> - RK3568_PHYREG32_SSC_OFFSET_SHIFT;
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val,
> - RK3568_PHYREG32);
> }
> break;
> default:
> @@ -1371,11 +1348,7 @@ static int rk3588_combphy_cfg(struct rockchip_combphy_priv *priv)
> }
> }
>
> - if (priv->enable_ssc) {
> - val = readl(priv->mmio + RK3568_PHYREG8);
> - val |= RK3568_PHYREG8_SSC_EN;
> - writel(val, priv->mmio + RK3568_PHYREG8);
> - }
> + rk_combphy_common_cfg_ssc(priv, rate);
>
> return 0;
> }
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [RESEND 1/1] phy: freescale: imx8qm-hsio: provide regmap names
From: Neil Armstrong @ 2026-03-06 10:39 UTC (permalink / raw)
To: Alexander Stein, Vinod Koul, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260211144949.1128122-1-alexander.stein@ew.tq-group.com>
On 2/11/26 15:49, Alexander Stein wrote:
> This driver uses multiple regmaps, which will causes name conflicts
> in debugfs like:
> debugfs: '5f1a0000.phy' already exists in 'regmap'
> Fix this by using a dedicated regmap config for each resource, each
> having a dedicated regmap name.
>
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> ---
> Same as the one sent in December but with an updated CC list.
>
> drivers/phy/freescale/phy-fsl-imx8qm-hsio.c | 23 +++++++++++++++++----
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c b/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c
> index 279b8ac7822df..4ab45c9f53dff 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c
> @@ -107,7 +107,22 @@ static const char * const lan2_pcieb_clks[] = {"apb_pclk2", "pclk2", "ctl1_crr",
> static const char * const lan2_sata_clks[] = {"pclk2", "epcs_tx", "epcs_rx",
> "phy1_crr", "misc_crr"};
>
> -static const struct regmap_config regmap_config = {
> +static const struct regmap_config regmap_phy_config = {
> + .name = "phy",
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> +static const struct regmap_config regmap_ctrl_config = {
> + .name = "ctrl",
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> +static const struct regmap_config regmap_misc_config = {
> + .name = "misc",
> .reg_bits = 32,
> .val_bits = 32,
> .reg_stride = 4,
> @@ -562,19 +577,19 @@ static int imx_hsio_probe(struct platform_device *pdev)
> return PTR_ERR(priv->base);
>
> off = devm_platform_ioremap_resource_byname(pdev, "phy");
> - priv->phy = devm_regmap_init_mmio(dev, off, ®map_config);
> + priv->phy = devm_regmap_init_mmio(dev, off, ®map_phy_config);
> if (IS_ERR(priv->phy))
> return dev_err_probe(dev, PTR_ERR(priv->phy),
> "unable to find phy csr registers\n");
>
> off = devm_platform_ioremap_resource_byname(pdev, "ctrl");
> - priv->ctrl = devm_regmap_init_mmio(dev, off, ®map_config);
> + priv->ctrl = devm_regmap_init_mmio(dev, off, ®map_ctrl_config);
> if (IS_ERR(priv->ctrl))
> return dev_err_probe(dev, PTR_ERR(priv->ctrl),
> "unable to find ctrl csr registers\n");
>
> off = devm_platform_ioremap_resource_byname(pdev, "misc");
> - priv->misc = devm_regmap_init_mmio(dev, off, ®map_config);
> + priv->misc = devm_regmap_init_mmio(dev, off, ®map_misc_config);
> if (IS_ERR(priv->misc))
> return dev_err_probe(dev, PTR_ERR(priv->misc),
> "unable to find misc csr registers\n");
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
--
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: Vladimir Oltean @ 2026-03-06 12:50 UTC (permalink / raw)
To: Geert Uytterhoeven
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,
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,
Magnus Damm
In-Reply-To: <CAMuHMdUNtqsui3ek1RYCTyiuDLRajpSBMnrdzED6wu6i7-QcuA@mail.gmail.com>
On Thu, Mar 05, 2026 at 08:47:47AM +0100, Geert Uytterhoeven wrote:
> > --- 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)
> > +{
> > + return phy->attrs.max_link_rate;
> > +}
> > +EXPORT_SYMBOL_GPL(phy_get_max_link_rate);
>
> Any specific reason you are not making this a simple static inline
> function, like phy_get_bus_width()?
For a consumer function to be static inline and to dereference struct
phy fields, it would mean that the struct phy contents need to be
visible to the consumer directly. Against my stated purpose.
phy_get_bus_width() was also changed to be non-inline.
--
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: Vladimir Oltean @ 2026-03-06 12:51 UTC (permalink / raw)
To: Geert Uytterhoeven
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: <CAMuHMdV+7n==crPmitH-JCwtJiH+7LaPKZQYU4ZqX_duo3_7Eg@mail.gmail.com>
On Thu, Mar 05, 2026 at 09:28:50AM +0100, Geert Uytterhoeven wrote:
> > +#include "../../drivers/phy/phy-provider.h"
>
> Shouldn't there be one more "../"?
> Interestingly, it compiles with/without.
Thanks for the observation. Indeed, it compiles both ways, I have no
idea why.
--
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