* Re: [net-next,05/14] net: stmmac: add stmmac core serdes support
From: Jakub Kicinski @ 2026-01-20 23:32 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: 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: <aW8M9ZiiftGBQIRM@shell.armlinux.org.uk>
On Tue, 20 Jan 2026 05:04:53 +0000 Russell King (Oracle) wrote:
> By the time phylink_pcs_enable() has been called, the PCS is already
> plumbed in to phylink. It _will_ have phylink_pcs_disable() called on
> it at some point in the future, either by having the PCS displaced
> by another in a subsequent phylink_major_config(), or by a driver
> calling phylink_stop().
>
> If we clean up here, then we will call dwmac_serdes_power_off() twice.
>
> Yes, it's not "nice" but that's the way phylink is right now, and
> without reworking phylink to record that pcs_enable() has failed
> to avoid a subsequent pcs_disable(), and to stop the major config
> (which then potentially causes a whole bunch of other issues). I
> don't even want to think about that horrid scenario at the moment.
Would you mind adding a note to this effect to the commit message
to shut up the bot?
Unless the comment on patch 12 is also incorrect in which case I'll
restore the v1 into patchwork.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 2/7] mux: Add helper functions for getting optional and selected mux-state
From: Geert Uytterhoeven @ 2026-01-20 15:57 UTC (permalink / raw)
To: Josua Mayer
Cc: 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,
Yazan Shhady, Jon Nettleton, Mikhail Anikin, linux-can, linux-phy,
linux-kernel, linux-omap, linux-i2c, linux-mmc, devicetree,
linux-renesas-soc
In-Reply-To: <20260118-rz-sdio-mux-v5-2-3c37e8872683@solid-run.com>
Hi Josua,
On Sun, 18 Jan 2026 at 11:29, Josua Mayer <josua@solid-run.com> wrote:
> In-tree phy-can-transceiver driver has already implemented a local
> version of devm_mux_state_get_optional.
>
> The omap-i2c driver gets and selects an optional mux in its probe
> function without using any helper.
>
> Add new helper functions covering both aforementioned use-cases:
>
> - mux_control_get_optional:
> Get a mux-control if specified in dt, return NULL otherwise.
> - devm_mux_state_get_optional:
> Get a mux-state if specified in dt, return NULL otherwise.
> - devm_mux_state_get_selected:
> Get and select a mux-state specified in dt, return error otherwise.
> - devm_mux_state_get_optional_selected:
> Get and select a mux-state if specified in dt, return error or NULL.
>
> Existing mux_get helper function is changed to take an extra argument
> indicating whether the mux is optional.
> In this case no error is printed, and NULL returned in case of ENOENT.
>
> Calling code is adapted to handle NULL return case, and to pass optional
> argument as required.
>
> To support automatic deselect for _selected helper, a new structure is
> created storing an exit pointer similar to clock core which is called on
> release.
>
> To facilitate code sharing between optional/mandatory/selected helpers,
> a new internal helper function is added to handle quiet (optional) and
> verbose (mandatory) errors, as well as storing the correct callback for
> devm release: __devm_mux_state_get
>
> Due to this structure devm_mux_state_get_*_selected can no longer print
> a useful error message when select fails. Instead callers should print
> errors where needed.
>
> Commit e153fdea9db04 ("phy: can-transceiver: Re-instate "mux-states"
> property presence check") noted that "mux_get() always prints an error
> message in case of an error, including when the property is not present,
> confusing the user."
>
> The first error message covers the case that a mux name is not matched
> in dt. The second error message is based on of_parse_phandle_with_args
> return value.
>
> In optional case no error is printed and NULL is returned.
> This ensures that the new helper functions will not confuse the user
> either.
>
> With the addition of optional helper functions it became clear that
> drivers should compile and link even if CONFIG_MULTIPLEXER was not enabled.
> Add stubs for all symbols exported by mux core.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
Thanks for your patch!
> --- a/drivers/mux/core.c
> +++ b/drivers/mux/core.c
> @@ -46,6 +46,16 @@ static const struct class mux_class = {
> .name = "mux",
> };
>
> +/*
> + * struct devm_mux_state_state - Tracks managed resources for mux-state objects.
Please run scripts/checkpatch.pl:
WARNING: please, no space before tabs
#80: FILE: drivers/mux/core.c:50:
+ * struct devm_mux_state_state - ^ITracks managed resources for
mux-state objects.$
> + * @mux: Pointer to a mux state.
> + * @exit: An optional callback to execte before free.
> + */
> +struct devm_mux_state_state {
> + struct mux_state *mstate;
> + int (*exit)(struct mux_state *mstate);
> +};
> +
> static DEFINE_IDA(mux_ida);
>
> static int __init mux_init(void)
> --- a/include/linux/mux/consumer.h
> +++ b/include/linux/mux/consumer.h
> +static inline void mux_control_put(struct mux_control *mux)
> +{
> + return;
> +}
WARNING: void function return statements are not generally useful
#441: FILE: include/linux/mux/consumer.h:139:
+ return;
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] phy: fsl-imx8mq-usb: disable bind/unbind platform driver feature
From: Frank Li @ 2026-01-20 16:28 UTC (permalink / raw)
To: Xu Yang
Cc: vkoul, neil.armstrong, shawnguo, kernel, festevam, jun.li,
linux-phy, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260120111712.3159782-1-xu.yang_2@nxp.com>
On Tue, Jan 20, 2026 at 07:17:12PM +0800, Xu Yang wrote:
> Disabling PHYs in runtime usually causes the client with external abort
> exception or similar issue due to lack of API to notify clients about PHY
> removal. This patch removes the possibility to unbind i.MX PHY drivers in
> runtime.
>
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index 028c4c9dea40..abfa6ac3ae3f 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> @@ -837,6 +837,7 @@ static struct platform_driver imx8mq_usb_phy_driver = {
> .driver = {
> .name = "imx8mq-usb-phy",
> .of_match_table = imx8mq_usb_phy_of_match,
> + .suppress_bind_attrs = true,
> }
> };
> module_platform_driver(imx8mq_usb_phy_driver);
> --
> 2.34.1
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: fsl-imx8mq-usb: set platform driver data
From: Frank Li @ 2026-01-20 16:27 UTC (permalink / raw)
To: Xu Yang
Cc: vkoul, neil.armstrong, shawnguo, kernel, festevam, jun.li,
linux-phy, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260120111646.3159766-1-xu.yang_2@nxp.com>
On Tue, Jan 20, 2026 at 07:16:46PM +0800, Xu Yang wrote:
> Add missing platform_set_drvdata() as the data will be used in remove().
>
> Fixes: b58f0f86fd61 ("phy: fsl-imx8mq-usb: add tca function driver for imx95")
> Cc: stable@vger.kernel.org
> Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index e9c113edd470..028c4c9dea40 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> @@ -778,6 +778,8 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> if (!imx_phy)
> return -ENOMEM;
>
> + platform_set_drvdata(pdev, imx_phy);
> +
> imx_phy->clk = devm_clk_get(dev, "phy");
> if (IS_ERR(imx_phy->clk)) {
> dev_err(dev, "failed to get imx8mq usb phy clock\n");
> --
> 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 v2 2/2] dt-bindings: phy: ti,control-phy-otghs: convert to DT schema
From: Charan Pedumuru @ 2026-01-20 15:15 UTC (permalink / raw)
To: Rob Herring
Cc: Vinod Koul, Neil Armstrong, Krzysztof Kozlowski, Conor Dooley,
Kishon Vijay Abraham I, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260115145137.GB3319937-robh@kernel.org>
On 15-01-2026 20:21, Rob Herring wrote:
> On Wed, Jan 07, 2026 at 04:11:16PM +0000, Charan Pedumuru wrote:
>> Convert TI OMAP Control PHY binding to DT schema.
>> Changes during conversion:
>> - Define a new pattern 'control-phy' to match nodes defined in DT.
>>
>> Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
>> ---
>> .../bindings/phy/ti,control-phy-otghs.yaml | 94 +++++++++++++++++++++
>> Documentation/devicetree/bindings/phy/ti-phy.txt | 98 ----------------------
>> 2 files changed, 94 insertions(+), 98 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/ti,control-phy-otghs.yaml b/Documentation/devicetree/bindings/phy/ti,control-phy-otghs.yaml
>> new file mode 100644
>> index 000000000000..2c91609cac35
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/ti,control-phy-otghs.yaml
>> @@ -0,0 +1,94 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/phy/ti,control-phy-otghs.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: TI OMAP Control PHY Module
>> +
>> +maintainers:
>> + - Kishon Vijay Abraham I <kishon@ti.com>
>> +
>> +description:
>> + The TI OMAP Control PHY module is a hardware block within the system
>> + control module (SCM) of Texas Instruments OMAP SoCs. It provides
>> + centralized control over power, configuration, and auxiliary features
>> + for multiple on-chip PHYs. This module is essential for proper PHY
>> + operation in power-constrained embedded systems.
>> +
>> +properties:
>> + $nodename:
>> + pattern: "^control-phy(@[0-9a-f]+)?$"
>
> Drop. Non-standard.
Sure, I will change it to phy and will modify in dts too.
>
>> +
>> + compatible:
>> + enum:
>> + - ti,control-phy-otghs
>> + - ti,control-phy-usb2
>> + - ti,control-phy-pipe3
>> + - ti,control-phy-pcie
>> + - ti,control-phy-usb2-dra7
>> + - ti,control-phy-usb2-am437
>
> Alphabetical order
Okay.
>
>> +
>> + reg:
>> + minItems: 1
>> + maxItems: 4
>
> With the constraints below, there is no case that allows 4 entries.
Yeah, I will make it 3.
>
>> +
>> + reg-names:
>> + minItems: 1
>> + maxItems: 4
I will make it 3 here too
>> + items:
>> + enum: [otghs_control, power, pcie_pcs, control_sma]
>> +
>> +allOf:
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - ti,control-phy-otghs
>> + then:
>> + properties:
>> + reg-names:
>> + const: otghs_control
>> +
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - ti,control-phy-pcie
>
> There's no .dts with this compatible. Do you really need this
> compatible or can drop it?
Yeah, currently there is no such compatible, I was following the old binding, I could remove if it's necessary.
>
>> + then:
>> + properties:
>> + reg-names:
>> + items:
>> + - enum: [power, pcie_pcs, control_sma]
>
> It's really 1 entry of 3 possible names?
I think it should be direct 3 entries as per the binding, shouldn't be an enum, I will change it.
>
>> +
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - ti,control-phy-usb2
>> + - ti,control-phy-usb2-dra7
>> + - ti,control-phy-usb2-am437
>> + - ti,control-phy-pipe3
>> + then:
>> + properties:
>> + reg-names:
>> + const: power
>> +
>> +required:
>> + - reg
>> + - compatible
>> + - reg-names
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + control-phy@4a00233c {
>
> phy@...
>
>> + compatible = "ti,control-phy-otghs";
>> + reg = <0x4a00233c 0x4>;
>> + reg-names = "otghs_control";
>> + };
>> +...
>> diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt
>> deleted file mode 100644
>> index 7c7936b89f2c..000000000000
>> --- a/Documentation/devicetree/bindings/phy/ti-phy.txt
>> +++ /dev/null
>> @@ -1,98 +0,0 @@
>> -TI PHY: DT DOCUMENTATION FOR PHYs in TI PLATFORMs
>> -
>> -OMAP CONTROL PHY
>> -
>> -Required properties:
>> - - compatible: Should be one of
>> - "ti,control-phy-otghs" - if it has otghs_control mailbox register as on OMAP4.
>> - "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf register
>> - e.g. USB2_PHY on OMAP5.
>> - "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control
>> - e.g. USB3 PHY and SATA PHY on OMAP5.
>> - "ti,control-phy-pcie" - for pcie to support external clock for pcie and to
>> - set PCS delay value.
>> - e.g. PCIE PHY in DRA7x
>> - "ti,control-phy-usb2-dra7" - if it has power down register like USB2 PHY on
>> - DRA7 platform.
>> - "ti,control-phy-usb2-am437" - if it has power down register like USB2 PHY on
>> - AM437 platform.
>> - - reg : register ranges as listed in the reg-names property
>> - - reg-names: "otghs_control" for control-phy-otghs
>> - "power", "pcie_pcs" and "control_sma" for control-phy-pcie
>> - "power" for all other types
>> -
>> -omap_control_usb: omap-control-usb@4a002300 {
>> - compatible = "ti,control-phy-otghs";
>> - reg = <0x4a00233c 0x4>;
>> - reg-names = "otghs_control";
>> -};
>> -
>> -TI PIPE3 PHY
>> -
>> -Required properties:
>> - - compatible: Should be "ti,phy-usb3", "ti,phy-pipe3-sata" or
>> - "ti,phy-pipe3-pcie. "ti,omap-usb3" is deprecated.
>> - - reg : Address and length of the register set for the device.
>> - - reg-names: The names of the register addresses corresponding to the registers
>> - filled in "reg".
>> - - #phy-cells: determine the number of cells that should be given in the
>> - phandle while referencing this phy.
>> - - clocks: a list of phandles and clock-specifier pairs, one for each entry in
>> - clock-names.
>> - - clock-names: should include:
>> - * "wkupclk" - wakeup clock.
>> - * "sysclk" - system clock.
>> - * "refclk" - reference clock.
>> - * "dpll_ref" - external dpll ref clk
>> - * "dpll_ref_m2" - external dpll ref clk
>> - * "phy-div" - divider for apll
>> - * "div-clk" - apll clock
>> -
>> -Optional properties:
>> - - id: If there are multiple instance of the same type, in order to
>> - differentiate between each instance "id" can be used (e.g., multi-lane PCIe
>> - PHY). If "id" is not provided, it is set to default value of '1'.
>> - - syscon-pllreset: Handle to system control region that contains the
>> - CTRL_CORE_SMA_SW_0 register and register offset to the CTRL_CORE_SMA_SW_0
>> - register that contains the SATA_PLL_SOFT_RESET bit. Only valid for sata_phy.
>> - - syscon-pcs : phandle/offset pair. Phandle to the system control module and the
>> - register offset to write the PCS delay value.
>> -
>> -Deprecated properties:
>> - - ctrl-module : phandle of the control module used by PHY driver to power on
>> - the PHY.
>> -
>> -Recommended properties:
>> - - syscon-phy-power : phandle/offset pair. Phandle to the system control
>> - module and the register offset to power on/off the PHY.
>> -
>> -This is usually a subnode of ocp2scp to which it is connected.
>> -
>> -usb3phy@4a084400 {
>> - compatible = "ti,phy-usb3";
>> - reg = <0x4a084400 0x80>,
>> - <0x4a084800 0x64>,
>> - <0x4a084c00 0x40>;
>> - reg-names = "phy_rx", "phy_tx", "pll_ctrl";
>> - ctrl-module = <&omap_control_usb>;
>> - #phy-cells = <0>;
>> - clocks = <&usb_phy_cm_clk32k>,
>> - <&sys_clkin>,
>> - <&usb_otg_ss_refclk960m>;
>> - clock-names = "wkupclk",
>> - "sysclk",
>> - "refclk";
>> -};
>> -
>> -sata_phy: phy@4a096000 {
>> - compatible = "ti,phy-pipe3-sata";
>> - reg = <0x4A096000 0x80>, /* phy_rx */
>> - <0x4A096400 0x64>, /* phy_tx */
>> - <0x4A096800 0x40>; /* pll_ctrl */
>> - reg-names = "phy_rx", "phy_tx", "pll_ctrl";
>> - ctrl-module = <&omap_control_sata>;
>> - clocks = <&sys_clkin1>, <&sata_ref_clk>;
>> - clock-names = "sysclk", "refclk";
>> - syscon-pllreset = <&scm_conf 0x3fc>;
>> - #phy-cells = <0>;
>> -};
>>
>> --
>> 2.52.0
>>
--
Best Regards,
Charan.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 5/6] arm64: dts: qcom: milos: Add UFS nodes
From: Abel Vesa @ 2026-01-20 14:52 UTC (permalink / raw)
To: Luca Weiss
Cc: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Alim Akhtar, Avri Altman,
Bart Van Assche, Vinod Koul, Neil Armstrong, Konrad Dybcio,
~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, linux-scsi, linux-phy,
Konrad Dybcio, Dmitry Baryshkov
In-Reply-To: <zvagnaxqgrpm6bagw6zuov4oi6o4b7vmy673oh5st22tec2swl@abvblxgray2s>
On 26-01-20 16:49:26, Abel Vesa wrote:
> On 26-01-12 14:53:18, Luca Weiss wrote:
> > Add the nodes for the UFS PHY and UFS host controller, along with the
> > ICE used for UFS.
> >
> > Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> > ---
> > arch/arm64/boot/dts/qcom/milos.dtsi | 129 +++++++++++++++++++++++++++++++++++-
> > 1 file changed, 126 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
> > index e1a51d43943f..7c8a84bfaee1 100644
> > --- a/arch/arm64/boot/dts/qcom/milos.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/milos.dtsi
> > @@ -1151,6 +1151,129 @@ aggre2_noc: interconnect@1700000 {
> > qcom,bcm-voters = <&apps_bcm_voter>;
> > };
> >
> > + ufs_mem_phy: phy@1d80000 {
> > + compatible = "qcom,milos-qmp-ufs-phy";
> > + reg = <0x0 0x01d80000 0x0 0x2000>;
> > +
> > + clocks = <&rpmhcc RPMH_CXO_CLK>,
> > + <&gcc GCC_UFS_PHY_PHY_AUX_CLK>,
> > + <&tcsr TCSR_UFS_CLKREF_EN>;
> > + clock-names = "ref",
> > + "ref_aux",
> > + "qref";
> > +
> > + resets = <&ufs_mem_hc 0>;
> > + reset-names = "ufsphy";
> > +
> > + power-domains = <&gcc UFS_MEM_PHY_GDSC>;
> > +
> > + #clock-cells = <1>;
> > + #phy-cells = <0>;
> > +
> > + status = "disabled";
> > + };
> > +
> > + ufs_mem_hc: ufshc@1d84000 {
> > + compatible = "qcom,milos-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
> > + reg = <0x0 0x01d84000 0x0 0x3000>;
> > +
> > + interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH 0>;
> > +
> > + clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
> > + <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
> > + <&gcc GCC_UFS_PHY_AHB_CLK>,
> > + <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
> > + <&tcsr TCSR_UFS_PAD_CLKREF_EN>,
>
> Maybe I'm looking at the wrong documentation, but it doesn't seem to exist
> such clock on Milos. It does exist on SM8650 though. So maybe the TCSR CC
> driver is not really that much compatible between these two platforms.
>
> I take it that the UFS works. Maybe because the actual TCSR UFS clkref
> is left enabled at boot?
Oh, nevemind. I think I was looking at the wrong SoC.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: phy: ti,phy-usb3: convert to DT schema
From: Charan Pedumuru @ 2026-01-20 14:50 UTC (permalink / raw)
To: Rob Herring
Cc: Vinod Koul, Neil Armstrong, Krzysztof Kozlowski, Conor Dooley,
Kishon Vijay Abraham I, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260115144541.GA3319937-robh@kernel.org>
On 15-01-2026 20:15, Rob Herring wrote:
> On Wed, Jan 07, 2026 at 04:11:15PM +0000, Charan Pedumuru wrote:
>> Convert TI PIPE3 PHY binding to DT schema.
>> Changes during conversion:
>> - Define a new pattern 'pciephy' to match nodes defined in DT.
>> - Drop obsolete "id" property from the schema.
>>
>> Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
>> ---
>> .../devicetree/bindings/phy/ti,phy-usb3.yaml | 127 +++++++++++++++++++++
>> 1 file changed, 127 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml b/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml
>> new file mode 100644
>> index 000000000000..41b3828723ae
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/ti,phy-usb3.yaml
>> @@ -0,0 +1,127 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/phy/ti,phy-usb3.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: TI PIPE3 PHY Module
>> +
>> +maintainers:
>> + - Kishon Vijay Abraham I <kishon@ti.com>
>> +
>> +description:
>> + The TI PIPE3 PHY is a high-speed SerDes (Serializer/Deserializer)
>> + transceiver integrated in OMAP5, DRA7xx/AM57xx, and similar SoCs.
>> + It supports multiple protocols (USB3, SATA, PCIe) using the PIPE3
>> + interface standard, which defines a common physical layer for
>> + high-speed serial interfaces.
>> +
>> +properties:
>> + $nodename:
>> + pattern: "^(pciephy|usb3phy|phy)(@[0-9a-f]+)?$"
>
> Again, don't define your own patterns. Either update the .dts files to
> use the established patterns (pcie-phy, usb3-phy, phy) or leave it
> undefined here.
Sure, I will try to update them in dts.
>
> Plus the unit-address is not optional as 'reg' is not optional...
Okay.
>
>> +
>> + compatible:
>> + enum:
>> + - ti,phy-usb3
>> + - ti,phy-pipe3-sata
>> + - ti,phy-pipe3-pcie
>> + - ti,omap-usb3
>
> Alphabetical order please.
Sure.
>
>> +
>> + reg:
>> + minItems: 2
>> + maxItems: 3
>> +
>> + reg-names:
>> + minItems: 2
>> + maxItems: 3
>> + items:
>> + enum:
>> + - phy_rx
>> + - phy_tx
>> + - pll_ctrl
>
> Do this really need to be any order? Looks to me like this works for all
> users in tree:
>
> minItems: 2
> items:
> - const: phy_rx
> - const: phy_tx
> - const: pll_ctrl
This will work, I tested it now.
>
>> +
>> + "#phy-cells":
>> + const: 0
>> +
>> + clocks:
>> + minItems: 2
>> + maxItems: 7
>> +
>> + clock-names:
>> + minItems: 2
>> + maxItems: 7
>> + items:
>> + enum: [wkupclk, sysclk, refclk, dpll_ref,
>> + dpll_ref_m2, phy-div, div-clk]
>> +
>> + syscon-phy-power:
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + description:
>> + Phandle/offset pair to system control module register for PHY
>> + power on/off.
>
> Needs constrants on the size:
>
> items:
> - items:
> - description: phandle to ...
> - description: offset of ...
Sure, I will change for the other properties too.
>
>> +
>> + syscon-pllreset:
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + description:
>> + Phandle/offset pair to CTRL_CORE_SMA_SW_0 register containing
>> + SATA_PLL_SOFT_RESET bit (SATA PHY only).
>
> Same here.
>
>> +
>> + syscon-pcs:
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + description:
>> + Phandle/offset pair to system control module for writing PCS delay value.
>
> Same here.
>
>> +
>> + ctrl-module:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description:
>> + Phandle of control module for PHY power on.
>> + deprecated: true
>> +
>> +dependencies:
>> + syscon-pllreset:
>> + properties:
>> + compatible:
>> + contains:
>> + const: ti,phy-pipe3-sata
>
> Usually we express this the other way around:
>
> if:
> properties:
> compatible:
> contains:
> const: ti,phy-pipe3-sata
> then:
> required:
> - syscon-pllreset
> else:
> properties:
> syscon-pllreset: false
>
> But that's slightly different as syscon-pllreset is optional for
> ti,phy-pipe3-sata in your case. Seems like it should be required if
> ti,phy-pipe3-sata?
I checked the DTS, it is not a required property. So, I will not change the format.
>
>
>> +
>> +required:
>> + - reg
>> + - compatible
>> + - reg-names
>> + - "#phy-cells"
>> + - clocks
>> + - clock-names
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + /* TI PIPE3 USB3 PHY */
>> + usb3phy@4a084400 {
>> + compatible = "ti,phy-usb3";
>> + reg = <0x4a084400 0x80>,
>> + <0x4a084800 0x64>,
>> + <0x4a084c00 0x40>;
>> + reg-names = "phy_rx", "phy_tx", "pll_ctrl";
>> + #phy-cells = <0>;
>> + clocks = <&usb_phy_cm_clk32k>,
>> + <&sys_clkin>,
>> + <&usb_otg_ss_refclk960m>;
>> + clock-names = "wkupclk", "sysclk", "refclk";
>> + ctrl-module = <&omap_control_usb>;
>> + };
>> +
>> + - |
>> + /* TI PIPE3 SATA PHY */
>> + phy@4a096000 {
>> + compatible = "ti,phy-pipe3-sata";
>> + reg = <0x4A096000 0x80>, /* phy_rx */
>> + <0x4A096400 0x64>, /* phy_tx */
>> + <0x4A096800 0x40>; /* pll_ctrl */
>> + reg-names = "phy_rx", "phy_tx", "pll_ctrl";
>> + clocks = <&sys_clkin1>, <&sata_ref_clk>;
>> + clock-names = "sysclk", "refclk";
>> + syscon-pllreset = <&scm_conf 0x3fc>;
>> + #phy-cells = <0>;
>> + };
>> +...
>>
>> --
>> 2.52.0
>>
--
Best Regards,
Charan.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 5/6] arm64: dts: qcom: milos: Add UFS nodes
From: Abel Vesa @ 2026-01-20 14:49 UTC (permalink / raw)
To: Luca Weiss
Cc: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Alim Akhtar, Avri Altman,
Bart Van Assche, Vinod Koul, Neil Armstrong, Konrad Dybcio,
~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, linux-scsi, linux-phy,
Konrad Dybcio, Dmitry Baryshkov
In-Reply-To: <20260112-milos-ufs-v2-5-d3ce4f61f030@fairphone.com>
On 26-01-12 14:53:18, Luca Weiss wrote:
> Add the nodes for the UFS PHY and UFS host controller, along with the
> ICE used for UFS.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> arch/arm64/boot/dts/qcom/milos.dtsi | 129 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 126 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
> index e1a51d43943f..7c8a84bfaee1 100644
> --- a/arch/arm64/boot/dts/qcom/milos.dtsi
> +++ b/arch/arm64/boot/dts/qcom/milos.dtsi
> @@ -1151,6 +1151,129 @@ aggre2_noc: interconnect@1700000 {
> qcom,bcm-voters = <&apps_bcm_voter>;
> };
>
> + ufs_mem_phy: phy@1d80000 {
> + compatible = "qcom,milos-qmp-ufs-phy";
> + reg = <0x0 0x01d80000 0x0 0x2000>;
> +
> + clocks = <&rpmhcc RPMH_CXO_CLK>,
> + <&gcc GCC_UFS_PHY_PHY_AUX_CLK>,
> + <&tcsr TCSR_UFS_CLKREF_EN>;
> + clock-names = "ref",
> + "ref_aux",
> + "qref";
> +
> + resets = <&ufs_mem_hc 0>;
> + reset-names = "ufsphy";
> +
> + power-domains = <&gcc UFS_MEM_PHY_GDSC>;
> +
> + #clock-cells = <1>;
> + #phy-cells = <0>;
> +
> + status = "disabled";
> + };
> +
> + ufs_mem_hc: ufshc@1d84000 {
> + compatible = "qcom,milos-ufshc", "qcom,ufshc", "jedec,ufs-2.0";
> + reg = <0x0 0x01d84000 0x0 0x3000>;
> +
> + interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH 0>;
> +
> + clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
> + <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
> + <&gcc GCC_UFS_PHY_AHB_CLK>,
> + <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
> + <&tcsr TCSR_UFS_PAD_CLKREF_EN>,
Maybe I'm looking at the wrong documentation, but it doesn't seem to exist
such clock on Milos. It does exist on SM8650 though. So maybe the TCSR CC
driver is not really that much compatible between these two platforms.
I take it that the UFS works. Maybe because the actual TCSR UFS clkref
is left enabled at boot?
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 0/4] Add USB support for Canaan K230
From: Jiayu Du @ 2026-01-20 14:38 UTC (permalink / raw)
To: Greg KH
Cc: vkoul, conor, neil.armstrong, robh, krzk+dt, pjw, palmer, aou,
alex, linux-phy, linux-usb, devicetree, linux-riscv, linux-kernel
In-Reply-To: <2026012036-refuse-reply-a363@gregkh>
On Tue, Jan 20, 2026 at 07:06:54AM +0100, Greg KH wrote:
> On Tue, Jan 20, 2026 at 12:07:38AM +0800, Jiayu Du wrote:
> > On Mon, Jan 19, 2026 at 05:38:31PM +0800, Jiayu Du wrote:
> >
> > This is series is the RESEND of the series here[1]. I resend it
> > because I mistakenly sent the wrong USBPHY driver code.
> >
> > Link: https://lore.kernel.org/all/20260119093836.316007-1-jiayu.riscv@isrc.iscas.ac.cn/ [1]
> > ]
> >
>
> I have no idea which is which anymore, sorry. Please send out a v4 so
> we know which to look at.
>
> confused,
>
> greg k-h
So sorry for that, I have sent the v4[1]. Please ignore the v3.
Link: https://lore.kernel.org/all/20260120143243.71937-1-jiayu.riscv@isrc.iscas.ac.cn/ [1]
Sincerely,
Jiayu Du
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v4 3/4] phy: usb: Add driver for Canaan K230 USB 2.0 PHY
From: Jiayu Du @ 2026-01-20 14:32 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: <20260120143243.71937-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 | 283 ++++++++++++++++++++++++++++++
5 files changed, 301 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..350950563f60
--- /dev/null
+++ b/drivers/phy/canaan/phy-k230-usb.c
@@ -0,0 +1,283 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Canaan usb PHY driver
+ *
+ * Copyright (C) 2025 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 v4 0/4] Add USB support for Canaan K230
From: Jiayu Du @ 2026-01-20 14:32 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 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 | 283 ++++++++++++++++++
9 files changed, 391 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
* [PATCH v4 4/4] riscv: dts: canaan: Add syscon and USB nodes for K230
From: Jiayu Du @ 2026-01-20 14:32 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: <20260120143243.71937-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 v4 1/4] dt-bindings: phy: Add Canaan K230 USB PHY
From: Jiayu Du @ 2026-01-20 14:32 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: <20260120143243.71937-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.
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 v4 2/4] dt-bindings: usb: dwc2: Add support for Canaan K230 SoC
From: Jiayu Du @ 2026-01-20 14:32 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: <20260120143243.71937-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
* Re: [PATCH v3] phy: fsl-imx8mq-usb: add debugfs to access control register
From: Andrew Lunn @ 2026-01-20 13:32 UTC (permalink / raw)
To: Xu Yang
Cc: Frank Li, vkoul, neil.armstrong, shawnguo, kernel, festevam,
jun.li, linux-phy, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <fmdje7ftwna5vv5xrzt5e7hpv4juzwjurhvdzzrfeifaeyyblj@givopw2u7vmn>
> > Rather than reinvent the wheel, could you use regmap?
> >
> > https://elixir.bootlin.com/linux/v6.12.1/source/drivers/base/regmap/regmap-debugfs.c#L546
> >
> > Regmap should be able to provide a debugfs interface for you, no
> > driver code needed.
> >
> > This will also help you with the abstraction between the core generic
> > part of the PHY driver and the SoC integration glue. You pass the
> > regmap to the core driver, and the funny muxing through two registers
> > is hidden away from the core. If the next SoC integrated uses plan
> > MMIO, that SoC glue driver can instantiate an MMIO regmap.
> >
> > Using regmap is a good idea for core generic drivers which can be
> > integrated into SoCs in different ways. It hides the SoC details
> > behind a well known API.
>
> Thanks for your suggestion.
>
> Using regmap is generally a good fit for reusable driver and I aggre it
> helps abstract Soc-specific details.
>
> However, the regmap defbugfs has its own limitations:
> 1. By default the register is read-only, add write operation require rebuild
> the kernel which make it inconvenient to debug the issue on the spot.
That is somewhat deliberate. We don't want a nice API which can be
used for user space binary blob drivers. In networking, which is my
more normal area, we pretty much reject any sort of write interface,
other than official kernel APIs.
> Refer to: "09c6ecd39410 regmap: Add support for writing to regmap registers
> via debugfs"
>
> # ls /sys/kernel/debug/regmap/2-0050/ -l
> total 0
> -r-------- 1 root root 0 Jan 20 07:45 access
> -r-------- 1 root root 0 Jan 20 07:45 name
> -r-------- 1 root root 0 Jan 20 07:45 range
> -r-------- 1 root root 0 Jan 20 07:45 registers
>
> 2. It can't randomly read specific one register with common linux commands. Besides,
> the read operation is inefficient especially when the range is a bit large because
> when you cat the register it always read and output all the registers.
You are debugging. Do you need efficient output?
If you have a specific debug tasks in mind, maybe you should be
thinking of an official kernel API? In the past, there has been
interest in getting SERDES eye information out of PHYs, and being able
to change the configuration parameters of the eye. Could a generic API
be added for that? Some of these PHYs also support pseudo random bit
sequence generators, and there has been interest in adding APIs for
configuring them.
Andrew
--
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-20 12:11 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: <aW9VHt6meEJFxV0I@shell.armlinux.org.uk>
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.
Similarly, the fact we don't have to whom to report an error code
doesn't make it pointless to offer the guarantee that pcs_disable() will
be called only when pcs_enable() has succeeded. It is only the latter
that seems necessary in order to develop reliable complexity on top of
these.
If SerDes PHY integration in phylink_pcs drivers is a model to follow
for other drivers, I think the way in which balanced calls can be made
from pcs_enable()/pcs_disable() needs to be given more attention.
And I think it's a bit worse than "doesn't matter, the port is dead
anyway". For example, we can have QSGMII where 4 PCSes share a single
SerDes lane, so one single malfunctioning PCS instance can affect all
the others through the lane's phy->power_count.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: fsl-imx8mq-usb: disable bind/unbind platform driver feature
From: Xu Yang @ 2026-01-20 11:17 UTC (permalink / raw)
To: vkoul, neil.armstrong, shawnguo, kernel, festevam, jun.li,
Frank.Li
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel
Disabling PHYs in runtime usually causes the client with external abort
exception or similar issue due to lack of API to notify clients about PHY
removal. This patch removes the possibility to unbind i.MX PHY drivers in
runtime.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index 028c4c9dea40..abfa6ac3ae3f 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -837,6 +837,7 @@ static struct platform_driver imx8mq_usb_phy_driver = {
.driver = {
.name = "imx8mq-usb-phy",
.of_match_table = imx8mq_usb_phy_of_match,
+ .suppress_bind_attrs = true,
}
};
module_platform_driver(imx8mq_usb_phy_driver);
--
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] phy: fsl-imx8mq-usb: set platform driver data
From: Xu Yang @ 2026-01-20 11:16 UTC (permalink / raw)
To: vkoul, neil.armstrong, shawnguo, kernel, festevam, jun.li,
Frank.Li
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel
Add missing platform_set_drvdata() as the data will be used in remove().
Fixes: b58f0f86fd61 ("phy: fsl-imx8mq-usb: add tca function driver for imx95")
Cc: stable@vger.kernel.org
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index e9c113edd470..028c4c9dea40 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -778,6 +778,8 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
if (!imx_phy)
return -ENOMEM;
+ platform_set_drvdata(pdev, imx_phy);
+
imx_phy->clk = devm_clk_get(dev, "phy");
if (IS_ERR(imx_phy->clk)) {
dev_err(dev, "failed to get imx8mq usb phy clock\n");
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v3] phy: fsl-imx8mq-usb: add debugfs to access control register
From: Xu Yang @ 2026-01-20 11:06 UTC (permalink / raw)
To: Andrew Lunn
Cc: Frank Li, vkoul, neil.armstrong, shawnguo, kernel, festevam,
jun.li, linux-phy, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <6d27a8b1-1407-40ff-945b-927ef0a39eb1@lunn.ch>
On Fri, Jan 16, 2026 at 04:19:01PM +0100, Andrew Lunn wrote:
> On Fri, Jan 16, 2026 at 07:29:39PM +0800, Xu Yang wrote:
> > On Thu, Jan 08, 2026 at 10:43:01AM -0500, Frank Li wrote:
> > > On Thu, Jan 08, 2026 at 04:36:41PM +0800, Xu Yang wrote:
> > > > The CR port is a simple 16-bit data/address parallel port that is
> > > > provided for on-chip access to the control registers inside the
> > > > USB 3.0 femtoPHY[1].
> > >
> > >
> > > > While access to these registers is not required
> > > > for normal PHY operation, this interface enables you to access
> > > > some of the PHY’s diagnostic features during normal operation or
> > > > to override some basic PHY control signals.
> > >
> > > Simple said "Export these registers by debugfs to help PHY’s diagnostic."
> > > should be enough
> >
> > OK.
> >
> > >
> > > >
> > > > 3 debugfs files are created to read and write control registers,
> > > > all use hexadecimal format:
> > > > ctrl_reg_base: the register offset to write, or the start offset
> > > > to read.
> > > > ctrl_reg_count: how many continuous registers to be read.
> > > > ctrl_reg_value: read to show the continuous registers value from
> > > > the offset in ctrl_reg_base, to ctrl_reg_base
> > > > + ctrl_reg_count - 1, one line for one register.
> > > > when write, override the register at ctrl_reg_base,
> > > > one time can only change one 16bits register.
> > >
> > > how many regs? how about create file regNNN,
> >
> > >From 0x0 to 0x201F.
>
> Rather than reinvent the wheel, could you use regmap?
>
> https://elixir.bootlin.com/linux/v6.12.1/source/drivers/base/regmap/regmap-debugfs.c#L546
>
> Regmap should be able to provide a debugfs interface for you, no
> driver code needed.
>
> This will also help you with the abstraction between the core generic
> part of the PHY driver and the SoC integration glue. You pass the
> regmap to the core driver, and the funny muxing through two registers
> is hidden away from the core. If the next SoC integrated uses plan
> MMIO, that SoC glue driver can instantiate an MMIO regmap.
>
> Using regmap is a good idea for core generic drivers which can be
> integrated into SoCs in different ways. It hides the SoC details
> behind a well known API.
Thanks for your suggestion.
Using regmap is generally a good fit for reusable driver and I aggre it
helps abstract Soc-specific details.
However, the regmap defbugfs has its own limitations:
1. By default the register is read-only, add write operation require rebuild
the kernel which make it inconvenient to debug the issue on the spot.
Refer to: "09c6ecd39410 regmap: Add support for writing to regmap registers
via debugfs"
# ls /sys/kernel/debug/regmap/2-0050/ -l
total 0
-r-------- 1 root root 0 Jan 20 07:45 access
-r-------- 1 root root 0 Jan 20 07:45 name
-r-------- 1 root root 0 Jan 20 07:45 range
-r-------- 1 root root 0 Jan 20 07:45 registers
2. It can't randomly read specific one register with common linux commands. Besides,
the read operation is inefficient especially when the range is a bit large because
when you cat the register it always read and output all the registers.
Thanks,
Xu Yang
>
> Andrew
>
--
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-20 10:14 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: <20260120084227.j2wgbmjsrpmycpgn@skbuf>
On Tue, Jan 20, 2026 at 10:42:27AM +0200, Vladimir Oltean wrote:
> More to the point, if dwmac_integrated_pcs_enable() fails at
> dwmac_serdes_power_on() (thus, the SerDes is _not_ powered on), by your
> own admission of this PCS calling convention, sooner or later
> dwmac_integrated_pcs_disable() -> dwmac_serdes_power_off() will still be
> called, leading to a negative phy->power_count.
>
> That is to say, if the model is "irrespective of whether pcs_enable()
> succeeds or fails mid way, pcs_disable is called anyway()", then these
> methods are not prepared to handle that reliably.
That's the way it currently is, and it's been this way in the
major_config path for a very long time. If anything fails in that
path, we can't report the error back up to anyone, and the netdev
is effectively dead.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [net-next,05/14] net: stmmac: add stmmac core serdes support
From: Russell King (Oracle) @ 2026-01-20 10:12 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: <20260120081844.7e6aq2urhxrylywi@skbuf>
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.
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.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 7/7] mmc: host: renesas_sdhi_core: support selecting an optional mux
From: Geert Uytterhoeven @ 2026-01-20 9:49 UTC (permalink / raw)
To: Josua Mayer
Cc: 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, Magnus Damm, Wolfram Sang, Yazan Shhady,
Jon Nettleton, Mikhail Anikin, linux-can, linux-phy, linux-kernel,
linux-omap, linux-i2c, linux-mmc, devicetree, linux-renesas-soc
In-Reply-To: <20260118-rz-sdio-mux-v5-7-3c37e8872683@solid-run.com>
On Sun, 18 Jan 2026 at 11:29, Josua Mayer <josua@solid-run.com> wrote:
> Some hardware designs route data or control signals through a mux to
> support multiple devices on a single sdhi controller.
>
> In particular SolidRun RZ/G2L/G2LC/V2L System on Module use a mux for
> switching between soldered eMMC and an optional microSD on a carrier
> board, e.g. for development or provisioning.
>
> SD/SDIO/eMMC are not well suited for runtime switching between different
> cards, however boot-time selection is possible and useful - in
> particular considering dt overlays.
>
> Add support for an optional SD/SDIO/eMMC mux defined in dt, and select
> it during probe.
>
> Similar functionality already exists in other places, e.g. i2c-omap.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
LGTM, so
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 2/7] mux: Add helper functions for getting optional and selected mux-state
From: Geert Uytterhoeven @ 2026-01-20 9:45 UTC (permalink / raw)
To: Josua Mayer
Cc: 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,
Yazan Shhady, Jon Nettleton, Mikhail Anikin, linux-can, linux-phy,
linux-kernel, linux-omap, linux-i2c, linux-mmc, devicetree,
linux-renesas-soc
In-Reply-To: <20260118-rz-sdio-mux-v5-2-3c37e8872683@solid-run.com>
Hi Josua,
On Sun, 18 Jan 2026 at 11:29, Josua Mayer <josua@solid-run.com> wrote:
> In-tree phy-can-transceiver driver has already implemented a local
> version of devm_mux_state_get_optional.
>
> The omap-i2c driver gets and selects an optional mux in its probe
> function without using any helper.
>
> Add new helper functions covering both aforementioned use-cases:
>
> - mux_control_get_optional:
> Get a mux-control if specified in dt, return NULL otherwise.
> - devm_mux_state_get_optional:
> Get a mux-state if specified in dt, return NULL otherwise.
> - devm_mux_state_get_selected:
> Get and select a mux-state specified in dt, return error otherwise.
> - devm_mux_state_get_optional_selected:
> Get and select a mux-state if specified in dt, return error or NULL.
>
> Existing mux_get helper function is changed to take an extra argument
> indicating whether the mux is optional.
> In this case no error is printed, and NULL returned in case of ENOENT.
>
> Calling code is adapted to handle NULL return case, and to pass optional
> argument as required.
>
> To support automatic deselect for _selected helper, a new structure is
> created storing an exit pointer similar to clock core which is called on
> release.
>
> To facilitate code sharing between optional/mandatory/selected helpers,
> a new internal helper function is added to handle quiet (optional) and
> verbose (mandatory) errors, as well as storing the correct callback for
> devm release: __devm_mux_state_get
>
> Due to this structure devm_mux_state_get_*_selected can no longer print
> a useful error message when select fails. Instead callers should print
> errors where needed.
>
> Commit e153fdea9db04 ("phy: can-transceiver: Re-instate "mux-states"
> property presence check") noted that "mux_get() always prints an error
> message in case of an error, including when the property is not present,
> confusing the user."
>
> The first error message covers the case that a mux name is not matched
> in dt. The second error message is based on of_parse_phandle_with_args
> return value.
>
> In optional case no error is printed and NULL is returned.
> This ensures that the new helper functions will not confuse the user
> either.
>
> With the addition of optional helper functions it became clear that
> drivers should compile and link even if CONFIG_MULTIPLEXER was not enabled.
> Add stubs for all symbols exported by mux core.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
Thanks for your patch!
> --- a/drivers/mux/core.c
> +++ b/drivers/mux/core.c
> @@ -677,7 +707,7 @@ EXPORT_SYMBOL_GPL(devm_mux_control_get);
> *
> * Return: A pointer to the mux-state, or an ERR_PTR with a negative errno.
> */
> -static struct mux_state *mux_state_get(struct device *dev, const char *mux_name)
> +static struct mux_state *mux_state_get(struct device *dev, const char *mux_name, bool optional)
> {
> struct mux_state *mstate;
>
> @@ -685,12 +715,10 @@ static struct mux_state *mux_state_get(struct device *dev, const char *mux_name)
> if (!mstate)
> return ERR_PTR(-ENOMEM);
>
> - mstate->mux = mux_get(dev, mux_name, &mstate->state);
> - if (IS_ERR(mstate->mux)) {
> - int err = PTR_ERR(mstate->mux);
> -
> + mstate->mux = mux_get(dev, mux_name, &mstate->state, optional);
> + if (IS_ERR_OR_NULL(mstate->mux)) {
> kfree(mstate);
mstate is freed here...
> - return ERR_PTR(err);
> + return ERR_CAST(mstate->mux);
... and dereferenced here, leading to a use after free.
> }
>
> return mstate;
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 v5 11/24] scsi: ufs: mediatek: Rework probe function
From: AngeloGioacchino Del Regno @ 2026-01-20 9:43 UTC (permalink / raw)
To: Peter Wang (王信友), chu.stanley@gmail.com,
robh@kernel.org, Chunfeng Yun (云春峰),
kishon@kernel.org, James.Bottomley@HansenPartnership.com,
bvanassche@acm.org, 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, krzk@kernel.org,
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: <74944c55418976375955430d27ac568149d555f1.camel@mediatek.com>
Il 13/01/26 08:26, Peter Wang (王信友) ha scritto:
> On Mon, 2026-01-12 at 16:02 +0100, AngeloGioacchino Del Regno wrote:
>> No, MediaTek's reset hardware implementation is not the same as Texas
>> Instruments.
>> It was *very similar* to TI in the past (years ago, around the MT6795
>> Helio
>> generation times).
>>
>> MediaTek's reset controller - by hardware - is definitely different
>> from the one
>> found in TI SoCs.
>>
>> Regards,
>> Angelo
>
> I did not notice this change.
> Will you be helping to upstream MediaTek's reset controller instead of
> TI's?
>
The main reset controllers are already integrated in clock drivers since
... well, years ago.
If there's any additional reset controller that is missing, and special to
UFS, and that's not in the UFS clock driver, yes we can upstream that.
Cheers,
Angelo
> Thanks
> Peter
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 1/7] phy: can-transceiver: rename temporary helper function to avoid conflict
From: Geert Uytterhoeven @ 2026-01-20 9:35 UTC (permalink / raw)
To: Josua Mayer
Cc: 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,
Yazan Shhady, Jon Nettleton, Mikhail Anikin, linux-can, linux-phy,
linux-kernel, linux-omap, linux-i2c, linux-mmc, devicetree,
linux-renesas-soc
In-Reply-To: <20260118-rz-sdio-mux-v5-1-3c37e8872683@solid-run.com>
Hi Josua,
On Sun, 18 Jan 2026 at 11:29, Josua Mayer <josua@solid-run.com> wrote:
> Rename the temporary devm_mux_state_get_optional function to avoid
> conflict with upcoming implementation in multiplexer subsystem.
>
> Acked-by: Vinod Koul <vkoul@kernel.org>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
My
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
on v3 is still valid.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox