* Re: [PATCH v2 01/12] dt-bindings: phy: mediatek,hdmi-phy: Fix clock output names for MT8195
From: Chun-Kuang Hu @ 2026-01-17 0:24 UTC (permalink / raw)
To: Louis-Alexis Eyraud
Cc: Chunfeng Yun, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Chun-Kuang Hu, Philipp Zabel,
Guillaume Ranquet, kernel, Krzysztof Kozlowski, linux-arm-kernel,
linux-mediatek, linux-phy, devicetree, linux-kernel
In-Reply-To: <20251217-mtk-genio-evk-hdmi-support-v2-1-a994976bb39a@collabora.com>
Hi, Louis:
Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> 於 2025年12月17日週三
上午10:19寫道：
>
> From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>
> For all of the HDMI PHYs compatible with the one found on MT8195
> the output clock has a different datasheet name and specifically
> it is called "hdmi_txpll", differently from the older HDMI PHYs
> which output block is called "hdmitx_dig_cts".
>
> Replace clock output name string check by max item number one to allow
> the new name on all of the HDMI PHY IPs that are perfectly compatible
> with MT8195.
>
> [Louis-Alexis Eyraud: split patch, addressed previous feedback from
> mailing list, and reworded description]
Applied the binding patches of this series to mediatek-drm-next [1], thanks.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Fixes: c78fe548b062 ("dt-bindings: phy: mediatek: hdmi-phy: Add mt8195 compatible")
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
> ---
> Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
> index f3a8b0b745d13ffc55d391570bff20830d925ed3..10f1d9326f18dba85b92b4c88f4c0f6cdddc4c25 100644
> --- a/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml
> @@ -42,8 +42,7 @@ properties:
> - const: pll_ref
>
> clock-output-names:
> - items:
> - - const: hdmitx_dig_cts
> + maxItems: 1
>
> "#phy-cells":
> const: 0
>
> --
> 2.52.0
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: (subset) [PATCH v7 0/3] arm64: qcom: x1e78100-lenovo-thinkpad-t14s: add support for HDMI output
From: Bjorn Andersson @ 2026-01-16 21:39 UTC (permalink / raw)
To: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Neil Armstrong
Cc: Xilin Wu, linux-arm-msm, linux-phy, devicetree, linux-kernel,
Dmitry Baryshkov, Konrad Dybcio, Abel Vesa
In-Reply-To: <20251119-topic-x1e80100-hdmi-v7-0-2bee0e66cc1b@linaro.org>
On Wed, 19 Nov 2025 09:45:39 +0100, Neil Armstrong wrote:
> The Thinkpad T14s embeds a transparent 4lanes DP->HDMI transceiver
> connected to the third QMP Combo PHY 4 lanes.
>
> The QMP USB3/DP Combo PHY hosts an USB3 phy and a DP PHY on top
> of a combo glue to route either lanes to the 4 shared physical lanes.
>
> The routing of the lanes can be:
> - 1/2 DP + 2 USB3
> - 1/2/4 DP
> - 2 USB3
>
> [...]
Applied, thanks!
[3/3] arm64: dts: qcom: x1e78100-lenovo-thinkpad-t14s: add HDMI nodes
commit: a1338b39c14ddf50b841e891833786037dec6de4
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 2/8] arm64: dts: mediatek: mt7981b: Add PCIe and USB support
From: Rob Herring @ 2026-01-16 16:02 UTC (permalink / raw)
To: Sjoerd Simons
Cc: Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Ryder Lee, Jianjun Wang,
Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Chunfeng Yun, Vinod Koul,
Kishon Vijay Abraham I, Lee Jones, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lorenzo Bianconi,
Felix Fietkau, kernel, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-pci, linux-phy, netdev, Daniel Golle,
Bryan Hinton
In-Reply-To: <20251223-openwrt-one-network-v5-2-7d1864ea3ad5@collabora.com>
On Tue, Dec 23, 2025 at 6:38 AM Sjoerd Simons <sjoerd@collabora.com> wrote:
>
> Add device tree nodes for PCIe controller and USB3 XHCI host
> controller on MT7981B SoC. Both controllers share the USB3 PHY
> which can be configured for either USB3 or PCIe operation.
>
> The USB3 XHCI controller supports USB 2.0 and USB 3.0 SuperSpeed
> operation. The PCIe controller is compatible with PCIe Gen2
> specifications.
>
> Also add the topmisc syscon node required for USB/PCIe PHY
> multiplexing.
>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
> ---
> V1 -> V2: Keep xhci reg and phys properties in single lines
> ---
> arch/arm64/boot/dts/mediatek/mt7981b.dtsi | 80 +++++++++++++++++++++++++++++++
> 1 file changed, 80 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> index 416096b80770..d3f37413413e 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt7981b.dtsi
> @@ -2,6 +2,7 @@
>
> #include <dt-bindings/clock/mediatek,mt7981-clk.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/phy/phy.h>
> #include <dt-bindings/reset/mt7986-resets.h>
>
> / {
> @@ -223,6 +224,55 @@ auxadc: adc@1100d000 {
> status = "disabled";
> };
>
> + xhci: usb@11200000 {
> + compatible = "mediatek,mt7986-xhci", "mediatek,mtk-xhci";
> + reg = <0 0x11200000 0 0x2e00>, <0 0x11203e00 0 0x0100>;
> + reg-names = "mac", "ippc";
> + clocks = <&infracfg CLK_INFRA_IUSB_SYS_CK>,
> + <&infracfg CLK_INFRA_IUSB_CK>,
> + <&infracfg CLK_INFRA_IUSB_133_CK>,
> + <&infracfg CLK_INFRA_IUSB_66M_CK>,
> + <&topckgen CLK_TOP_U2U3_XHCI_SEL>;
> + clock-names = "sys_ck", "ref_ck", "mcu_ck", "dma_ck", "xhci_ck";
> + interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
> + phys = <&u2port0 PHY_TYPE_USB2>, <&u3port0 PHY_TYPE_USB3>;
> + status = "disabled";
> + };
> +
> + pcie: pcie@11280000 {
> + compatible = "mediatek,mt7981-pcie",
> + "mediatek,mt8192-pcie";
> + reg = <0 0x11280000 0 0x4000>;
> + reg-names = "pcie-mac";
> + ranges = <0x82000000 0 0x20000000
> + 0x0 0x20000000 0 0x10000000>;
> + bus-range = <0x00 0xff>;
> + clocks = <&infracfg CLK_INFRA_IPCIE_CK>,
> + <&infracfg CLK_INFRA_IPCIE_PIPE_CK>,
> + <&infracfg CLK_INFRA_IPCIER_CK>,
> + <&infracfg CLK_INFRA_IPCIEB_CK>;
> + clock-names = "pl_250m", "tl_26m", "peri_26m", "top_133m";
> + device_type = "pci";
> + phys = <&u3port0 PHY_TYPE_PCIE>;
> + phy-names = "pcie-phy";
> + interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 &pcie_intc 0>,
> + <0 0 0 2 &pcie_intc 1>,
> + <0 0 0 3 &pcie_intc 2>,
> + <0 0 0 4 &pcie_intc 3>;
> + #address-cells = <3>;
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + status = "disabled";
> +
> + pcie_intc: interrupt-controller {
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + };
> + };
> +
> pio: pinctrl@11d00000 {
> compatible = "mediatek,mt7981-pinctrl";
> reg = <0 0x11d00000 0 0x1000>,
> @@ -252,6 +302,36 @@ mux {
> };
> };
>
> + topmisc: topmisc@11d10000 {
> + compatible = "mediatek,mt7981-topmisc", "syscon";
> + reg = <0 0x11d10000 0 0x10000>;
> + #clock-cells = <1>;
This is now a warning as the syscon.yaml binding this compatible is
defined in doesn't allow #clock-cells.
Rob
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3] phy: fsl-imx8mq-usb: add debugfs to access control register
From: Andrew Lunn @ 2026-01-16 15:19 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: <das6ud7gep5hrcdn4bnmoyl2pb7okbxslpnawch2osaezd6xm5@psbizlufjec4>
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.
Andrew
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: (subset) [PATCH v3 0/4] PCI: qcom: Add support for Glymur PCIe Gen5x4
From: Manivannan Sadhasivam @ 2026-01-16 13:25 UTC (permalink / raw)
To: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Helgaas,
Lorenzo Pieralisi, Krzysztof Wilczyński, Bjorn Andersson,
Wenbin Yao
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-pci,
konrad.dybcio, qiang.yu, Prudhvi Yarlagadda, Dmitry Baryshkov
In-Reply-To: <20250825-glymur_pcie5-v3-0-5c1d1730c16f@oss.qualcomm.com>
On Mon, 25 Aug 2025 23:01:46 -0700, Wenbin Yao wrote:
> Glymur is the next generation compute SoC of Qualcomm. This patch series
> aims to add support for the fifth PCIe instance on it. The fifth PCIe
> instance on Glymur has a Gen5 4-lane PHY. Patch [1/4] documents PHY as a
> separate compatible and Patch [2/4] documents controller as a separate
> compatible. Patch [3/4] describles the new PCS offsets in a dedicated
> header file. Patch [4/4] adds configuration and compatible for PHY.
>
> [...]
Applied, thanks!
[2/4] dt-bindings: PCI: qcom: Document the Glymur PCIe Controller
commit: e74887035fba99ead63235740908debeb1326dad
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3] phy: fsl-imx8mq-usb: add debugfs to access control register
From: Xu Yang @ 2026-01-16 11:30 UTC (permalink / raw)
To: Vinod Koul
Cc: Andrew Lunn, neil.armstrong, shawnguo, kernel, festevam, jun.li,
Frank.Li, linux-phy, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <aWdkapV39bOArR-d@vaman>
On Wed, Jan 14, 2026 at 03:09:54PM +0530, Vinod Koul wrote:
> On 08-01-26, 19:24, Andrew Lunn 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.
> > >
> > > 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.
> > >
> > > Link[1]: https://www.synopsys.com/dw/doc.php/phy/usb3.0/femto/phy/x652_usb3_ss14lpp_18_ns/4.07a/dwc_usb3.0_femtophy_ss14lpp_08V18V_x1_databook.pdf
> >
> > Please don't ignore my comments to V2. Think about the code split
> > between the generic IP licensed from Synopsys and the vendor specific
> > code used for integration into the SoC. You want to avoid making a
> > mess you later need to cleanup because somebody else licensed the same
> > IP core from Synopsys, and need to put their own vendor specific
> > integration code around the generic code.
>
> Agree with Andrew here, please do mix, splitting would be better
OK, will try.
Thanks,
Xu Yang
>
> >
> > Andrew
>
> --
> ~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3] phy: fsl-imx8mq-usb: add debugfs to access control register
From: Xu Yang @ 2026-01-16 11:30 UTC (permalink / raw)
To: Andrew Lunn
Cc: vkoul, neil.armstrong, shawnguo, kernel, festevam, jun.li,
Frank.Li, linux-phy, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <c1425564-9dca-45dc-ac5e-093150a3ff01@lunn.ch>
On Thu, Jan 08, 2026 at 07:24:31PM +0100, Andrew Lunn 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.
> >
> > 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.
> >
> > Link[1]: https://www.synopsys.com/dw/doc.php/phy/usb3.0/femto/phy/x652_usb3_ss14lpp_18_ns/4.07a/dwc_usb3.0_femtophy_ss14lpp_08V18V_x1_databook.pdf
>
> Please don't ignore my comments to V2. Think about the code split
> between the generic IP licensed from Synopsys and the vendor specific
> code used for integration into the SoC. You want to avoid making a
> mess you later need to cleanup because somebody else licensed the same
> IP core from Synopsys, and need to put their own vendor specific
> integration code around the generic code.
OK.
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: [PATCH v3] phy: fsl-imx8mq-usb: add debugfs to access control register
From: Xu Yang @ 2026-01-16 11:29 UTC (permalink / raw)
To: Frank Li
Cc: vkoul, neil.armstrong, shawnguo, kernel, festevam, jun.li,
linux-phy, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <aV/Qha0CQ+LJHo76@lizhi-Precision-Tower-5810>
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.
>
> cat/echo to regNNN?
Only regNNN seems not convenient to dump non-fixed number of registers.
>
> or create export file
>
> echo 100 > export, then create REG100, so can use cat/echo modify it.
If use export, it seems need a place to doc these information. It's not
straightforward to use.
>
>
> >
> > Link[1]: https://www.synopsys.com/dw/doc.php/phy/usb3.0/femto/phy/x652_usb3_ss14lpp_18_ns/4.07a/dwc_usb3.0_femtophy_ss14lpp_08V18V_x1_databook.pdf
> > Signed-off-by: Li Jun <jun.li@nxp.com>
> > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> >
> > ---
> > Changes in v3:
> > - add documentation link of registers
> > Changes in v2:
> > - correct copyright
> > - add imx8mq_phy_wait_for_cr_ack() helper and use it
> > - use DEFINE_SHOW_STORE_ATTRIBUTE()
> > - directly create debugfs file under imx phy debugfs
> > - remove debug_remove_files() since the phy core will handle it
> > ---
> > drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 180 ++++++++++++++++++++-
> > 1 file changed, 178 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> > index 95f9264bd0f7..e11054f6673c 100644
> > --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> > +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> > @@ -1,10 +1,11 @@
> > // SPDX-License-Identifier: GPL-2.0+
> > -/* Copyright (c) 2017 NXP. */
> > +/* Copyright 2017-2025 NXP. */
> >
> > #include <linux/bitfield.h>
> > #include <linux/clk.h>
> > +#include <linux/debugfs.h>
> > #include <linux/delay.h>
> > -#include <linux/io.h>
> > +#include <linux/iopoll.h>
> > #include <linux/module.h>
> > #include <linux/of.h>
> > #include <linux/phy/phy.h>
> > @@ -57,6 +58,20 @@
> >
> > #define PHY_TUNE_DEFAULT 0xffffffff
> >
> > +/* PHY control register access */
> > +#define PHY_CTRL_REG_OFFSET_MAX 0x201f
> > +
> > +#define PHY_CRCTL 0x30
> > +#define PHY_CRCTL_DATA_IN_MASK GENMASK(15, 0)
> > +#define PHY_CRCTL_CAP_ADDR BIT(16)
> > +#define PHY_CRCTL_CAP_DATA BIT(17)
> > +#define PHY_CRCTL_CR_WRITE BIT(18)
> > +#define PHY_CRCTL_CR_READ BIT(19)
> > +
> > +#define PHY_CRSR 0x34
> > +#define PHY_CRSR_DATA_OUT_MASK GENMASK(15, 0)
> > +#define PHY_CRSR_CR_ACK BIT(16)
> > +
> > #define TCA_CLK_RST 0x00
> > #define TCA_CLK_RST_SW BIT(9)
> > #define TCA_CLK_RST_REF_CLK_EN BIT(1)
> > @@ -118,6 +133,9 @@ struct imx8mq_usb_phy {
> > void __iomem *base;
> > struct regulator *vbus;
> > struct tca_blk *tca;
> > + struct dentry *debugfs;
> > + u16 cr_access_base;
> > + u16 cr_read_count;
> > u32 pcs_tx_swing_full;
> > u32 pcs_tx_deemph_3p5db;
> > u32 tx_vref_tune;
> > @@ -411,6 +429,163 @@ static u32 phy_pcs_tx_swing_full_from_property(u32 percent)
> > percent = min(percent, 100U);
> >
> > return (percent * 127) / 100;
> > +};
> > +
> > +static int imx8mq_phy_wait_for_cr_ack(struct imx8mq_usb_phy *imx_phy,
> > + u32 stage, u32 *data)
> > +{
> > + void __iomem *cr_ctrl = imx_phy->base + PHY_CRCTL;
> > + void __iomem *cr_sr = imx_phy->base + PHY_CRSR;
> > + u32 val;
> > + int ret;
> > +
> > + writel(readl(cr_ctrl) | stage, cr_ctrl);
> > + /* Wait CRSR[16] == 1 */
> > + ret = readl_poll_timeout(cr_sr, val,
> > + (val & PHY_CRSR_CR_ACK) == PHY_CRSR_CR_ACK,
> > + 1, 100);
> > + if (ret)
> > + return ret;
> > +
> > + if (stage == PHY_CRCTL_CR_READ)
> > + *data = readl(cr_sr) & 0xffff;
> > +
> > + writel(readl(cr_ctrl) & (~stage), cr_ctrl);
> > + /* Wait CRSR[16] == 0 */
> > + return readl_poll_timeout(cr_sr, val, (val & PHY_CRSR_CR_ACK) == 0, 1, 100);
> > +}
> > +
> > +static int imx8mq_phy_ctrl_reg_addr(struct imx8mq_usb_phy *imx_phy, u16 offset)
> > +{
> > + void __iomem *cr_ctrl = imx_phy->base + PHY_CRCTL;
> > + struct device *dev = &imx_phy->phy->dev;
> > + int ret;
> > +
> > + writel(offset, cr_ctrl);
> > + ret = imx8mq_phy_wait_for_cr_ack(imx_phy, PHY_CRCTL_CAP_ADDR, NULL);
> > + if (ret < 0) {
> > + dev_err(dev, "Failed to address reg 0x%04x\n", offset);
> > + return -EIO;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int imx8mq_phy_ctrl_reg_read(struct imx8mq_usb_phy *imx_phy,
> > + u16 offset, u32 *val)
> > +{
> > + struct device *dev = &imx_phy->phy->dev;
> > + int ret;
> > +
> > + if (offset > PHY_CTRL_REG_OFFSET_MAX) {
> > + dev_err(dev, "Invalid reg address 0x%04x\n", offset);
> > + return -EINVAL;
> > + }
> > +
> > + /* Address stage */
> > + ret = imx8mq_phy_ctrl_reg_addr(imx_phy, offset);
> > + if (ret)
> > + return ret;
> > +
> > + /* Read data stage */
> > + ret = imx8mq_phy_wait_for_cr_ack(imx_phy, PHY_CRCTL_CR_READ, val);
> > + if (ret < 0) {
> > + dev_err(dev, "Failed to read reg 0x%04x\n", offset);
> > + return -EIO;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static int imx8mq_phy_ctrl_reg_write(struct imx8mq_usb_phy *imx_phy,
> > + u16 offset, u16 val)
> > +{
> > + struct device *dev = &imx_phy->phy->dev;
> > + void __iomem *cr_ctrl = imx_phy->base + PHY_CRCTL;
> > + int ret;
> > +
> > + if (offset > PHY_CTRL_REG_OFFSET_MAX) {
> > + dev_err(dev, "Invalid reg address 0x%04x\n", offset);
> > + return -EINVAL;
> > + }
> > +
> > + /* Address stage */
> > + ret = imx8mq_phy_ctrl_reg_addr(imx_phy, offset);
> > + if (ret)
> > + return ret;
> > +
> > + /* Capture data stage */
> > + writel(val, cr_ctrl);
> > + ret = imx8mq_phy_wait_for_cr_ack(imx_phy, PHY_CRCTL_CAP_DATA, NULL);
> > + if (ret < 0)
> > + goto cr_write_err;
> > +
> > + /* Write data stage */
> > + ret = imx8mq_phy_wait_for_cr_ack(imx_phy, PHY_CRCTL_CR_WRITE, NULL);
> > + if (ret < 0)
> > + goto cr_write_err;
> > +
> > + return 0;
> > +
> > +cr_write_err:
> > + dev_err(dev, "Failed to write reg 0x%04x\n", offset);
> > + return -EIO;
> > +}
> > +
> > +static int ctrl_reg_value_show(struct seq_file *s, void *unused)
> > +{
> > + struct imx8mq_usb_phy *imx_phy = s->private;
> > + u16 base = imx_phy->cr_access_base;
> > + u32 val;
> > + int i, ret;
> > +
> > + for (i = 0; i < imx_phy->cr_read_count; i++) {
> > + ret = imx8mq_phy_ctrl_reg_read(imx_phy, base + i, &val);
> > + if (ret < 0)
> > + return ret;
> > +
> > + seq_printf(s, "Control Register 0x%04x value is 0x%04x\n",
> > + base + i, val);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static ssize_t ctrl_reg_value_write(struct file *file, const char __user *ubuf,
> > + size_t count, loff_t *ppos)
> > +
> > +{
> > + struct seq_file *s = file->private_data;
> > + struct imx8mq_usb_phy *imx_phy = s->private;
> > + u16 cr_value;
> > + int ret;
> > +
> > + ret = kstrtou16_from_user(ubuf, count, 16, &cr_value);
> > + if (ret)
> > + return ret;
> > +
> > + ret = imx8mq_phy_ctrl_reg_write(imx_phy, imx_phy->cr_access_base, cr_value);
> > + if (ret)
> > + return ret;
> > +
> > + return count;
> > +}
> > +
> > +DEFINE_SHOW_STORE_ATTRIBUTE(ctrl_reg_value);
> > +
> > +static void imx8m_create_debug_files(struct imx8mq_usb_phy *imx_phy)
> > +{
> > + struct dentry *debugfs = imx_phy->phy->debugfs;
> > +
> > + debugfs_create_x16("ctrl_reg_base", 0600, debugfs,
> > + &imx_phy->cr_access_base);
> > + debugfs_create_x16("ctrl_reg_count", 0600, debugfs,
> > + &imx_phy->cr_read_count);
> > + debugfs_create_file("ctrl_reg_value", 0600, debugfs,
> > + imx_phy, &ctrl_reg_value_fops);
> > +
> > + imx_phy->cr_access_base = 0;
> > + imx_phy->cr_read_count = 1;
> > }
> >
> > static void imx8m_get_phy_tuning_data(struct imx8mq_usb_phy *imx_phy)
> > @@ -731,6 +906,7 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> > "failed to get tca\n");
> >
> > imx8m_get_phy_tuning_data(imx_phy);
> > + imx8m_create_debug_files(imx_phy);
>
> where remove debug fs?
phy core will remove debug fs when call phy_release().
Thanks,
Xu Yang
>
> Frank
> >
> > phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> >
> > --
> > 2.34.1
> >
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v3] phy: fsl-imx8mq-usb: enable RX Termination override
From: Xu Yang @ 2026-01-16 10:18 UTC (permalink / raw)
To: vkoul, neil.armstrong, shawnguo, kernel, festevam, jun.li,
Frank.Li
Cc: linux-phy, imx, linux-arm-kernel, linux-kernel
This is to resolve the problem of wakeup system by USB3 device insertion
if HSIOMIX on, in that case, the USB3 device detects RX term on so the
USB3 device doesn't downgrade to high-speed, we can't expect CONN wakeup
(for USB3) happen because the 24MHz OSC is required ON to trigger it.
Because the device works at Super-speed so DP/DM wakeup can't happen
either. Then the entire systen can't be waken up by such device attach
event.
With this override bit we can force the RX term off when enters system
suspend, and disable the override after system resume. Therefore, the
USB3 device will always downgrade to High-speed, then DP/DM wakeup can
always happen. It will correctly switch to Super-speed later when the
host reset it after the system resume back.
Signed-off-by: Li Jun <jun.li@nxp.com>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v3:
- remove CamelCase style in title
Changes in v2:
- rephase the message
---
drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
index f33eef218db1..e9c113edd470 100644
--- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
+++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
@@ -54,6 +54,7 @@
#define PHY_CTRL5_PCS_TX_SWING_FULL_MASK GENMASK(6, 0)
#define PHY_CTRL6 0x18
+#define PHY_CTRL6_RXTERM_OVERRIDE_SEL BIT(29)
#define PHY_CTRL6_ALT_CLK_EN BIT(1)
#define PHY_CTRL6_ALT_CLK_SEL BIT(0)
@@ -699,6 +700,7 @@ static int imx8mp_usb_phy_init(struct phy *phy)
static int imx8mq_phy_power_on(struct phy *phy)
{
struct imx8mq_usb_phy *imx_phy = phy_get_drvdata(phy);
+ u32 value;
int ret;
ret = regulator_enable(imx_phy->vbus);
@@ -715,12 +717,23 @@ static int imx8mq_phy_power_on(struct phy *phy)
return ret;
}
- return ret;
+ /* Disable rx term override */
+ value = readl(imx_phy->base + PHY_CTRL6);
+ value &= ~PHY_CTRL6_RXTERM_OVERRIDE_SEL;
+ writel(value, imx_phy->base + PHY_CTRL6);
+
+ return 0;
}
static int imx8mq_phy_power_off(struct phy *phy)
{
struct imx8mq_usb_phy *imx_phy = phy_get_drvdata(phy);
+ u32 value;
+
+ /* Override rx term to be 0 */
+ value = readl(imx_phy->base + PHY_CTRL6);
+ value |= PHY_CTRL6_RXTERM_OVERRIDE_SEL;
+ writel(value, imx_phy->base + PHY_CTRL6);
clk_disable_unprepare(imx_phy->alt_clk);
clk_disable_unprepare(imx_phy->clk);
--
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 v2] phy: fsl-imx8mq-usb: enable RxTermination_override_sel
From: Xu Yang @ 2026-01-16 10:07 UTC (permalink / raw)
To: Vinod Koul
Cc: neil.armstrong, shawnguo, kernel, festevam, jun.li, Frank.Li,
linux-phy, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <aWe_oNDOqHnQo0X2@vaman>
On Wed, Jan 14, 2026 at 09:39:04PM +0530, Vinod Koul wrote:
> On 24-12-25, 19:18, Xu Yang wrote:
>
> What is the with the CamelCase on the patch title! We dont do that
> please
Not on purpose. It's a bit field name. Will fix the title.
Thanks,
Xu Yang
>
> > This is to resolve the problem of wakeup system by USB3 device insertion
> > if HSIOMIX on, in that case, the USB3 device detects RX term on so the
> > USB3 device doesn't downgrade to high-speed, we can't expect CONN wakeup
> > (for USB3) happen because the 24MHz OSC is required ON to trigger it.
> > Because the device works at Super-speed so DP/DM wakeup can't happen
> > either. Then the entire systen can't be waken up by such device attach
> > event.
> >
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: Re: [PATCH v7 2/2] phy: eswin: Create eswin directory and add EIC7700 SATA PHY driver
From: Yulin Lu @ 2026-01-16 8:50 UTC (permalink / raw)
To: Vinod Koul
Cc: neil.armstrong, robh, krzk+dt, conor+dt, p.zabel, linux-phy,
devicetree, linux-kernel, ningyu, zhengyu, linmin, huangyifeng,
fenglin, lianghujun
In-Reply-To: <aWeH5fn8nGOzjDpP@vaman>
> > +static int eic7700_sata_phy_init(struct phy *phy)
> > +{
> > + struct eic7700_sata_phy *sata_phy = phy_get_drvdata(phy);
> > + u32 val;
> > + int ret;
> > +
> > + ret = clk_prepare_enable(sata_phy->clk);
> > + if (ret)
> > + return ret;
> > +
> > + regmap_write(sata_phy->regmap, SATA_REF_CTRL1, SATA_CLK_RST_SOURCE_PHY);
> > +
> > + val = FIELD_PREP(SATA_P0_PHY_TX_AMPLITUDE_GEN1_MASK, 0x42) |
> > + FIELD_PREP(SATA_P0_PHY_TX_AMPLITUDE_GEN2_MASK, 0x46) |
> > + FIELD_PREP(SATA_P0_PHY_TX_AMPLITUDE_GEN3_MASK, 0x73);
> > + regmap_write(sata_phy->regmap, SATA_PHY_CTRL0, val);
> > +
> > + val = FIELD_PREP(SATA_P0_PHY_TX_PREEMPH_GEN1_MASK, 0x5) |
> > + FIELD_PREP(SATA_P0_PHY_TX_PREEMPH_GEN2_MASK, 0x5) |
> > + FIELD_PREP(SATA_P0_PHY_TX_PREEMPH_GEN3_MASK, 0x8);
>
> Where are the magic values you are writing coming from..?
>
Hi Vinod,
These values set the TX preemphasis and amplitude parameters for the SATA PHY.
The actual numbers come from eye‑diagram tuning results on different hardware
development boards.
The current code reflects the settings for the Sifive HiFive Premier P550 board.
In the next patch I plan to move these into the devicetree (DTS).
Would that be acceptable?
> > + regmap_write(sata_phy->regmap, SATA_PHY_CTRL1, val);
> > +
> > + val = FIELD_PREP(SATA_LOS_LEVEL_MASK, 0x9) |
> > + FIELD_PREP(SATA_LOS_BIAS_MASK, 0x2);
> > + regmap_write(sata_phy->regmap, SATA_LOS_IDEN, val);
> > +
> > + val = SATA_M_CSYSREQ | SATA_S_CSYSREQ;
> > + regmap_write(sata_phy->regmap, SATA_AXI_LP_CTRL, val);
> > +
> > + val = SATA_REF_REPEATCLK_EN | SATA_REF_USE_PAD;
> > + regmap_write(sata_phy->regmap, SATA_REF_CTRL, val);
> > +
> > + val = FIELD_PREP(SATA_MPLL_MULTIPLIER_MASK, 0x3c);
> > + regmap_write(sata_phy->regmap, SATA_MPLL_CTRL, val);
> > +
> > + usleep_range(15, 20);
> > +
> > + ret = reset_control_deassert(sata_phy->rst);
> > + if (ret)
> > + goto disable_clk;
> > +
> > + ret = wait_for_phy_ready(sata_phy->regmap, SATA_P0_PHY_STAT,
> > + SATA_P0_PHY_READY, 1);
> > + if (ret < 0) {
> > + dev_err(&sata_phy->phy->dev, "PHY READY check failed\n");
> > + goto disable_clk;
> > + }
> > +
> > + return 0;
> > +
> > +disable_clk:
> > + clk_disable_unprepare(sata_phy->clk);
> > + return ret;
> > +}
> > +
> > +static int eic7700_sata_phy_exit(struct phy *phy)
> > +{
> > + struct eic7700_sata_phy *sata_phy = phy_get_drvdata(phy);
> > + int ret;
> > +
> > + ret = reset_control_assert(sata_phy->rst);
> > + if (ret)
> > + return ret;
> > +
> > + clk_disable_unprepare(sata_phy->clk);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct phy_ops eic7700_sata_phy_ops = {
> > + .init = eic7700_sata_phy_init,
> > + .exit = eic7700_sata_phy_exit,
> > + .owner = THIS_MODULE,
> > +};
> > +
> > +static int eic7700_sata_phy_probe(struct platform_device *pdev)
> > +{
> > + struct eic7700_sata_phy *sata_phy;
> > + struct phy_provider *phy_provider;
> > + struct device *dev = &pdev->dev;
> > + struct resource *res;
> > + void __iomem *regs;
> > +
> > + sata_phy = devm_kzalloc(dev, sizeof(*sata_phy), GFP_KERNEL);
> > + if (!sata_phy)
> > + return -ENOMEM;
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + if (!res)
> > + return -ENOENT;
> > +
> > + regs = devm_ioremap(dev, res->start, resource_size(res));
> > + if (IS_ERR(regs))
> > + return PTR_ERR(regs);
>
> devm_platform_get_and_ioremap_resource() please
>
As explained in my “v6 → v5” changes in the cover‑letter:
“Map the I/O resource with platform_get_resource and devm_ioremap
instead of the devm_platform_ioremap_resource API,
because the address region of the SATA‑PHY falls into the region of
the HSP clock & reset that has already been obtained by the HSP
clock‑and‑reset driver.”
The HSP clock-and-reset driver uses devm_platform_get_and_ioremap_resource(),
meaning this region has already been requested.
The HSP clock-and-reset driver is also currently being upstreamed.
Best regards,
Yulin Lu
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] drm/msm/dp: Correct LeMans/Monaco DP phy Swing/Emphasis setting
From: Dmitry Baryshkov @ 2026-01-16 8:41 UTC (permalink / raw)
To: Yongxing Mou
Cc: Konrad Dybcio, Vinod Koul, Neil Armstrong, linux-arm-msm,
linux-phy, linux-kernel
In-Reply-To: <80411ac4-6143-4c2e-bc9e-20a734f15987@oss.qualcomm.com>
On Fri, Jan 16, 2026 at 04:18:43PM +0800, Yongxing Mou wrote:
>
>
> On 1/14/2026 2:55 AM, Dmitry Baryshkov wrote:
> > On Tue, Jan 13, 2026 at 08:04:06PM +0800, Yongxing Mou wrote:
> > >
> > >
> > > On 1/9/2026 5:58 PM, Konrad Dybcio wrote:
> > > > On 1/9/26 9:30 AM, Yongxing Mou wrote:
> > > > > Currently, the LeMans/Monaco DP PHY operates in DP mode rather than eDP
> > > > > mode. Per the PHY HPG, the Swing and Emphasis settings have been corrected
> > > > > to the appropriate DP-mode values.
> > > > >
> > > > > Additionally, the HPG specifies that the LDO value should be set to 0 when
> > > > > in DP mode. These misconfigurations can lead to link training failures on
> > > > > certain dongles.
> > > > >
> > > > > Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> > > > > ---
> > > > > drivers/phy/qualcomm/phy-qcom-edp.c | 27 ++++++++++++++++++++++++---
> > > > > 1 file changed, 24 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
> > > > > index 13feab99feec..5b0d774bd715 100644
> > > > > --- a/drivers/phy/qualcomm/phy-qcom-edp.c
> > > > > +++ b/drivers/phy/qualcomm/phy-qcom-edp.c
> > > > > @@ -122,6 +122,13 @@ static const u8 dp_swing_hbr_rbr[4][4] = {
> > > > > { 0x1f, 0xff, 0xff, 0xff }
> > > > > };
> > > > > +static const u8 dp_swing_hbr_rbr_v1[4][4] = {
> > > > > + { 0x07, 0x0f, 0x16, 0x1f },
> > > > > + { 0x11, 0x1e, 0x1f, 0xff },
> > > > > + { 0x16, 0x1f, 0xff, 0xff },
> > > > > + { 0x1f, 0xff, 0xff, 0xff }
> > > > > +};
> > > >
> > > > For these platforms, I see 4 tables of settings:
> > > >
> > > > (Low/High) Swing/Pre-em for (Low/High) HBR
> > > >
> > > > None of them exactly match your change
> > > >
> > > Emm, this table is in LeMans eDP HPG, here are 6 tables. 4 of them use for
> > > eDP mode and reset 2 tables used for DP mode. If my understanding is
> > > incorrect, please correct me. Thanks ~~~ > [...]
> > > >
> > > > > - ldo_config = edp->is_edp ? 0x0 : 0x1;
> > > > > + ldo_config = !edp->is_edp ? 0x0 : 0x1;
> > > >
> > > > You'll notice that this is further wrong, because for eDP, it should be
> > > > 0x81 at low-swing-high-HBR and 0xc1 at low-swing-low-HBR, and 0 at both
> > > > cases of high-swing
> > > >
> > > > Please split the LDO change into a separate commit because it touches
> > > > more platforms
> > > >
> > > > Konrad
> > > >
> > >
> > > Yes, you are right, here seems something not correct. i will separate this
> > > change into single one.Here are some parts I don't fully understand here.
> > > Could you please point it? How do we know whether it is in low‑swing or
> > > high‑swing. I didn’t see any logic in the current code that determines this.
> > > Also, the value in Hamoa seems not same with LeMans,it is 0x51 and 0x91.
> > >
> > > While going through the Hamoa HPG, I noticed a potential issue.
> > >
> > > static struct qcom_edp_phy_cfg x1e80100_phy_cfg = {
> > > .aux_cfg = edp_phy_aux_cfg_v4,
> > > .vco_div_cfg = edp_phy_vco_div_cfg_v4,
> > > .swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,...It use
> > > dp_phy_swing_pre_emph_cfg not edp_phy_swing_pre_emph_cfg, but Hamoa really
> > > use edp-panel here.. so does this phy cfg correct here?
> >
> > All PHYs should support eDP and DP modes, so most of the configuration
> > tables need to be updated/fixed. I tried going through all the tables,
> > but I never had time to do it in a sane and complete way. As you started
> > looking into it, would you please review programming for all chipsets
> > starting from SC8180X?
> >
> I don't got the SC8180X PHY HPG permission now. once i got it, will check
> it's configuration and see what i can do. But first i want to correct the
> LeMans and Hamoa configuration and post the LDO change. Do you mean
> switching between the eDP and DP mode tables based on is_edp, instead of
> using a fixed table?
Based on the PHY being used in the eDP or DP modes (it is related but
not equivalent to the is_edp).
--
With best wishes
Dmitry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] drm/msm/dp: Correct LeMans/Monaco DP phy Swing/Emphasis setting
From: Yongxing Mou @ 2026-01-16 8:18 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Konrad Dybcio, Vinod Koul, Neil Armstrong, linux-arm-msm,
linux-phy, linux-kernel
In-Reply-To: <ldl7floy6bi5d6svs45xsdgbgkgwxpvj4kuazzg3e6dxzm654l@l5pjud7mvcgu>
On 1/14/2026 2:55 AM, Dmitry Baryshkov wrote:
> On Tue, Jan 13, 2026 at 08:04:06PM +0800, Yongxing Mou wrote:
>>
>>
>> On 1/9/2026 5:58 PM, Konrad Dybcio wrote:
>>> On 1/9/26 9:30 AM, Yongxing Mou wrote:
>>>> Currently, the LeMans/Monaco DP PHY operates in DP mode rather than eDP
>>>> mode. Per the PHY HPG, the Swing and Emphasis settings have been corrected
>>>> to the appropriate DP-mode values.
>>>>
>>>> Additionally, the HPG specifies that the LDO value should be set to 0 when
>>>> in DP mode. These misconfigurations can lead to link training failures on
>>>> certain dongles.
>>>>
>>>> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
>>>> ---
>>>> drivers/phy/qualcomm/phy-qcom-edp.c | 27 ++++++++++++++++++++++++---
>>>> 1 file changed, 24 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c b/drivers/phy/qualcomm/phy-qcom-edp.c
>>>> index 13feab99feec..5b0d774bd715 100644
>>>> --- a/drivers/phy/qualcomm/phy-qcom-edp.c
>>>> +++ b/drivers/phy/qualcomm/phy-qcom-edp.c
>>>> @@ -122,6 +122,13 @@ static const u8 dp_swing_hbr_rbr[4][4] = {
>>>> { 0x1f, 0xff, 0xff, 0xff }
>>>> };
>>>> +static const u8 dp_swing_hbr_rbr_v1[4][4] = {
>>>> + { 0x07, 0x0f, 0x16, 0x1f },
>>>> + { 0x11, 0x1e, 0x1f, 0xff },
>>>> + { 0x16, 0x1f, 0xff, 0xff },
>>>> + { 0x1f, 0xff, 0xff, 0xff }
>>>> +};
>>>
>>> For these platforms, I see 4 tables of settings:
>>>
>>> (Low/High) Swing/Pre-em for (Low/High) HBR
>>>
>>> None of them exactly match your change
>>>
>> Emm, this table is in LeMans eDP HPG, here are 6 tables. 4 of them use for
>> eDP mode and reset 2 tables used for DP mode. If my understanding is
>> incorrect, please correct me. Thanks ~~~ > [...]
>>>
>>>> - ldo_config = edp->is_edp ? 0x0 : 0x1;
>>>> + ldo_config = !edp->is_edp ? 0x0 : 0x1;
>>>
>>> You'll notice that this is further wrong, because for eDP, it should be
>>> 0x81 at low-swing-high-HBR and 0xc1 at low-swing-low-HBR, and 0 at both
>>> cases of high-swing
>>>
>>> Please split the LDO change into a separate commit because it touches
>>> more platforms
>>>
>>> Konrad
>>>
>>
>> Yes, you are right, here seems something not correct. i will separate this
>> change into single one.Here are some parts I don't fully understand here.
>> Could you please point it? How do we know whether it is in low‑swing or
>> high‑swing. I didn’t see any logic in the current code that determines this.
>> Also, the value in Hamoa seems not same with LeMans,it is 0x51 and 0x91.
>>
>> While going through the Hamoa HPG, I noticed a potential issue.
>>
>> static struct qcom_edp_phy_cfg x1e80100_phy_cfg = {
>> .aux_cfg = edp_phy_aux_cfg_v4,
>> .vco_div_cfg = edp_phy_vco_div_cfg_v4,
>> .swing_pre_emph_cfg = &dp_phy_swing_pre_emph_cfg,...It use
>> dp_phy_swing_pre_emph_cfg not edp_phy_swing_pre_emph_cfg, but Hamoa really
>> use edp-panel here.. so does this phy cfg correct here?
>
> All PHYs should support eDP and DP modes, so most of the configuration
> tables need to be updated/fixed. I tried going through all the tables,
> but I never had time to do it in a sane and complete way. As you started
> looking into it, would you please review programming for all chipsets
> starting from SC8180X?
>
I don't got the SC8180X PHY HPG permission now. once i got it, will
check it's configuration and see what i can do. But first i want to
correct the LeMans and Hamoa configuration and post the LDO change. Do
you mean switching between the eDP and DP mode tables based on is_edp,
instead of using a fixed table?
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 net-next 05/10] phy: add phy_get_rx_polarity() and phy_get_tx_polarity()
From: Jakub Kicinski @ 2026-01-16 3:19 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Paolo Abeni, Bjørn Mork, netdev, devicetree, linux-phy,
linux-kernel, linux-arm-kernel, linux-mediatek, Daniel Golle,
Horatiu Vultur, Andrew Lunn, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Matthias Brugger,
AngeloGioacchino Del Regno, Eric Woudstra, Marek Behún,
Lee Jones, Patrice Chotard, Vinod Koul
In-Reply-To: <20260115093928.hdqlxkt6bd5w4xud@skbuf>
On Thu, 15 Jan 2026 11:39:28 +0200 Vladimir Oltean wrote:
> > > Could you please share a stable branch/tag, so that we can pull patches
> > > 1-5 into the net-next tree from there?
> >
> > Vladimir, could you please re-post patches 1-5 after that Vinod shares
> > the above? So that we don't keep in PW the dangling (current) series.
> >
> Vinod did share the PR:
> https://lore.kernel.org/netdev/aWeXvFcGNK5T6As9@vaman/
IIUC Paolo did not pull Vinod's PR, so pulled now, you can repost.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 net-next 00/10] PHY polarity inversion via generic device tree properties
From: Jakub Kicinski @ 2026-01-16 3:16 UTC (permalink / raw)
To: Vinod Koul
Cc: Vladimir Oltean, netdev, devicetree, linux-phy, linux-kernel,
linux-arm-kernel, linux-mediatek, Daniel Golle, Horatiu Vultur,
Bjørn Mork, Andrew Lunn, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Matthias Brugger, AngeloGioacchino Del Regno, Eric Woudstra,
Marek Behún, Lee Jones, Patrice Chotard
In-Reply-To: <aWeXvFcGNK5T6As9@vaman>
On Wed, 14 Jan 2026 18:48:52 +0530 Vinod Koul wrote:
> Subject: Re: [PATCH v3 net-next 00/10] PHY polarity inversion via generic device tree properties
You can submit the PR in reply to the series, but please rewrite the
subject to a typical PR format. Patchwork does not register this reply
as a submission.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [net-next,12/14] net: stmmac: add support for reading inband SGMII status
From: Jakub Kicinski @ 2026-01-16 2:58 UTC (permalink / raw)
To: rmk+kernel
Cc: Jakub Kicinski, andrew+netdev, alexandre.torgue, hkallweit1,
vkoul, mohd.anwar, konrad.dybcio, andrew, edumazet, netdev,
linux-phy, davem, linux-arm-msm, neil.armstrong, linux-arm-kernel,
pabeni, mcoquelin.stm32, linux-stm32
In-Reply-To: <E1vg4wc-00000003SGl-1dZi@rmk-PC.armlinux.org.uk>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: stmmac: add support for reading inband SGMII status
This commit adds support for reading link status, speed, and duplex for
SGMII links from the RGSMII status register.
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> index 73fc56ce5e55..12fc5038d913 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
[ ... ]
> @@ -97,7 +107,7 @@ static void dwmac_integrated_pcs_get_state(struct phylink_pcs *pcs,
> struct phylink_link_state *state)
> {
> struct stmmac_pcs *spcs = phylink_pcs_to_stmmac_pcs(pcs);
> - u32 status, lpa;
> + u32 status, lpa, rgsmii;
>
> status = readl(spcs->base + GMAC_AN_STATUS);
>
> @@ -111,7 +121,35 @@ static void dwmac_integrated_pcs_get_state(struct phylink_pcs *pcs,
>
> phylink_mii_c22_pcs_decode_state(state, neg_mode, status, lpa);
> } else {
> - state->link = false;
> + rgsmii = field_get(spcs->rgsmii_status_mask,
> + readl(spcs->rgsmii));
> + state->link = !!(status & GMAC_RGSMIII_LNKSTS);
^^^^^^
Should this be checking rgsmii instead of status here? The status
variable contains the GMAC_AN_STATUS register which is equivalent to
MII_BMSR according to the comment at line 7. In BMSR, the link status
bit is BMSR_LSTATUS (bit 2), not bit 3.
GMAC_RGSMIII_LNKSTS is defined as BIT(3), which is the correct bit
position for the RGSMII status register (matching GMAC_RGSMIIIS_LNKSTS
in dwmac1000.h), but it appears to be applied to the wrong register
variable.
The code later uses rgsmii correctly for speed and duplex extraction.
Was the intent to use rgsmii for the link status check as well?
> +
> + if (state->link && neg_mode == PHYLINK_PCS_NEG_INBAND_ENABLED) {
[ ... ]
--
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: Jakub Kicinski @ 2026-01-16 2:57 UTC (permalink / raw)
To: rmk+kernel
Cc: Jakub Kicinski, andrew+netdev, alexandre.torgue, hkallweit1,
vkoul, mohd.anwar, konrad.dybcio, andrew, edumazet, netdev,
linux-phy, davem, linux-arm-msm, neil.armstrong, linux-arm-kernel,
pabeni, mcoquelin.stm32, linux-stm32
In-Reply-To: <E1vg4w2-00000003SG5-2FH5@rmk-PC.armlinux.org.uk>
I haven't investigated too closely if this is legit or too defensive
TBH but since I'm sending the second one I'll include this as well..
This is an AI-generated review of your patch.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: stmmac: add stmmac core serdes support
This commit adds SerDes PHY support to the stmmac core driver, moving it
from platform glue into the integrated PCS driver. The serdes field in
platform data is optional and NULL when not provided by platforms.
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 24a2555ca329..6c515f9efbe7 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
[ ... ]
> @@ -3549,12 +3550,16 @@ static void stmmac_safety_feat_configuration(struct stmmac_priv *priv)
>
> static void stmmac_clk_rx_i_require(struct stmmac_priv *priv)
> {
> + dwmac_serdes_power_on(priv);
> + /* Only sets the SerDes mode if it wasn't already configured. */
> + dwmac_serdes_init_mode(priv, priv->plat->phy_interface);
When priv->plat->serdes is NULL, dwmac_serdes_init_mode() will call
phy_get_mode(NULL). Unlike other phy_* functions (phy_power_on,
phy_power_off, phy_set_mode_ext, phy_init, phy_exit) which handle NULL
by returning early, phy_get_mode() is an inline that directly
dereferences the pointer:
static inline enum phy_mode phy_get_mode(struct phy *phy)
{
return phy->attrs.mode;
}
Can this NULL pointer dereference occur when a platform does not
populate plat->serdes? The call path stmmac_open() -> dwmac_serdes_init()
returns 0 (success) when serdes is NULL, allowing __stmmac_open() ->
stmmac_hw_setup() -> stmmac_clk_rx_i_require() to proceed.
> + phylink_rx_clk_stop_block(priv->phylink);
> }
[ ... ]
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_serdes.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_serdes.c
> new file mode 100644
> index 000000000000..3003e1ae38d2
> --- /dev/null
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_serdes.c
[ ... ]
> +int dwmac_serdes_init(struct stmmac_priv *priv)
> +{
> + size_t i;
> + int ret;
> +
> + if (!priv->plat->serdes)
> + return 0;
This returns success when serdes is NULL...
[ ... ]
> +int dwmac_serdes_init_mode(struct stmmac_priv *priv, phy_interface_t interface)
> +{
> + struct phy *serdes = priv->plat->serdes;
> +
> + if (phy_get_mode(serdes) == PHY_MODE_ETHERNET)
^^^^^^
...but dwmac_serdes_init_mode() has no NULL check before calling
phy_get_mode(), which will crash when serdes is NULL. Should this
function also check for NULL serdes before calling phy_get_mode()?
> + return 0;
> +
> + return dwmac_serdes_set_mode(priv, interface);
> +}
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 3/3] MAINTAINERS: Add ASPEED USB3 PHY driver
From: Ryan Chen @ 2026-01-16 2:53 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, Andrew Jeffery, Philipp Zabel
Cc: linux-phy, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen
In-Reply-To: <20260116-upstream_usb3phy-v2-0-0b0c9f3eb6f4@aspeedtech.com>
Add maintainer entry for ASPEED USB3 PHY driver.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5b11839cba9d..ad1d12f346f2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3894,6 +3894,14 @@ S: Maintained
F: Documentation/devicetree/bindings/usb/aspeed,ast2600-udc.yaml
F: drivers/usb/gadget/udc/aspeed_udc.c
+ASPEED USB3 PHY DRIVER
+M: Ryan Chen <ryan_chen@aspeedtech.com>
+L: linux-aspeed@lists.ozlabs.org (moderated for non-subscribers)
+L: linux-phy@lists.infradead.org
+S: Maintained
+F: Documentation/devicetree/bindings/phy/aspeed,ast2700-usb3-phy.yaml
+F: drivers/phy/aspeed/phy-aspeed-usb3.c
+
ASPEED VIDEO ENGINE DRIVER
M: Eddie James <eajames@linux.ibm.com>
L: linux-media@vger.kernel.org
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 2/3] phy: add AST2700 usb3.2 phy driver
From: Ryan Chen @ 2026-01-16 2:53 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, Andrew Jeffery, Philipp Zabel
Cc: linux-phy, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen
In-Reply-To: <20260116-upstream_usb3phy-v2-0-0b0c9f3eb6f4@aspeedtech.com>
Add AST2700 USB3.2 PHY driver support.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
drivers/phy/aspeed/Kconfig | 12 ++
drivers/phy/aspeed/Makefile | 2 +
drivers/phy/aspeed/phy-aspeed-usb3.c | 236 +++++++++++++++++++++++++++++++++++
3 files changed, 250 insertions(+)
diff --git a/drivers/phy/aspeed/Kconfig b/drivers/phy/aspeed/Kconfig
new file mode 100644
index 000000000000..72b4fc17a85e
--- /dev/null
+++ b/drivers/phy/aspeed/Kconfig
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+#
+# PHY drivers for ASPEED
+#
+
+config PHY_ASPEED_USB3
+ tristate "ASPEED USB3 PHY driver"
+ select GENERIC_PHY
+ depends on (ARCH_ASPEED || COMPILE_TEST)
+ help
+ Enable driver support for Aspeed AST2700 USB3 PHY.
diff --git a/drivers/phy/aspeed/Makefile b/drivers/phy/aspeed/Makefile
new file mode 100644
index 000000000000..20b5ac7b7e64
--- /dev/null
+++ b/drivers/phy/aspeed/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_ASPEED_USB3_PHY) += phy-aspeed-usb3.o
diff --git a/drivers/phy/aspeed/phy-aspeed-usb3.c b/drivers/phy/aspeed/phy-aspeed-usb3.c
new file mode 100644
index 000000000000..872d2163fcf5
--- /dev/null
+++ b/drivers/phy/aspeed/phy-aspeed-usb3.c
@@ -0,0 +1,236 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2026 Aspeed Technology Inc.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/reset.h>
+
+#define PHY3S00 0x00
+#define PHY3S00_INIT_DONE BIT(15)
+#define PHY3S00_SRAM_BYPASS BIT(7)
+#define PHY3S00_SRAM_EXT_LOAD BIT(6)
+#define PHY3S04 0x04
+#define PHY3C00 0x08
+#define PHY3C04 0x0C
+#define PHY3P00 0x10
+#define PHY3P00_RX_ADAPT_AFE_EN_G1 BIT(0)
+#define PHY3P00_RX_ADAPT_AFE_EN_G2 BIT(1)
+#define PHY3P00_RX_ADAPT_DFE_EN_G1 BIT(2)
+#define PHY3P00_RX_ADAPT_DFE_EN_G2 BIT(3)
+#define PHY3P00_RX_CDR_VCO_LOWFREQ_G1 BIT(4)
+#define PHY3P00_RX_CDR_VCO_LOWFREQ_G2 BIT(5)
+#define PHY3P00_RX_EQ_AFE_GAIN_G1 GENMASK(9, 6)
+#define PHY3P00_RX_EQ_AFE_GAIN_G2 GENMASK(13, 10)
+#define PHY3P00_RX_EQ_ATT_LVL_G1 GENMASK(16, 14)
+#define PHY3P00_RX_EQ_ATT_LVL_G2 GENMASK(19, 17)
+#define PHY3P00_RX_EQ_CTLE_BOOST_G1 GENMASK(24, 20)
+#define PHY3P00_RX_EQ_CTLE_BOOST_G2 GENMASK(29, 25)
+#define PHY3P00_RX_EQ_DELTA_IQ_G1_LO GENMASK(31, 30)
+
+#define PHY3P04 0x14
+#define PHY3P04_RX_EQ_DELTA_IQ_G1_HI GENMASK(1, 0)
+#define PHY3P04_RX_EQ_DELTA_IQ_G2 GENMASK(5, 2)
+#define PHY3P04_RX_EQ_DFE_TAP1_G1 GENMASK(13, 6)
+#define PHY3P04_RX_EQ_DFE_TAP1_G2 GENMASK(21, 14)
+#define PHY3P04_RX_LOS_LFPS_EN BIT(22)
+#define PHY3P04_RX_LOS_THRESHOLD GENMASK(25, 23)
+#define PHY3P04_RX_TERM_CTRL GENMASK(28, 26)
+#define PHY3P04_TX_EQ_MAIN_G1_LO GENMASK(31, 29)
+
+#define PHY3P08 0x18
+#define PHY3P08_TX_EQ_MAIN_G1_HI GENMASK(1, 0)
+#define PHY3P08_TX_EQ_MAIN_G2 GENMASK(6, 2)
+#define PHY3P08_TX_EQ_OVRD BIT(7)
+#define PHY3P08_TX_EQ_POST_G1 GENMASK(12, 9)
+#define PHY3P08_TX_EQ_POST_G2 GENMASK(16, 13)
+#define PHY3P08_TX_EQ_PRE_G1 GENMASK(20, 17)
+#define PHY3P08_TX_EQ_PRE_G2 GENMASK(24, 21)
+#define PHY3P08_TX_IBOOST_LVL GENMASK(28, 25)
+#define PHY3P08_TX_TERM_CTRL GENMASK(31, 29)
+
+#define PHY3P0C 0x1C
+#define PHY3P0C_TX_VBOOST_EN BIT(0)
+
+#define PHY3CMD 0x40
+
+#define PHY3P_RX_EQ_CTLE_BOOST_G1_DEFAULT 0x7
+#define PHY3P_RX_EQ_CTLE_BOOST_G2_DEFAULT 0x7
+#define PHY3P_RX_EQ_DELTA_IQ_G1_DEFAULT 0x3
+#define PHY3P_RX_EQ_DELTA_IQ_G2_DEFAULT 0x5
+#define PHY3P_RX_LOS_THRESHOLD_DEFAULT 0x3
+#define PHY3P_RX_TERM_CTRL_DEFAULT 0x2
+#define PHY3P_TX_EQ_MAIN_G1_DEFAULT 0xa
+#define PHY3P_TX_EQ_MAIN_G2_DEFAULT 0x9
+#define PHY3P_TX_EQ_POST_G1_DEFAULT 0x4
+#define PHY3P_TX_EQ_POST_G2_DEFAULT 0x3
+#define PHY3P_TX_EQ_PRE_G2_DEFAULT 0x2
+#define PHY3P_TX_IBOOST_LVL_DEFAULT 0xf
+#define PHY3P_TX_TERM_CTRL_DEFAULT 0x2
+
+#define PHY3P00_DEFAULT ( \
+ PHY3P00_RX_ADAPT_AFE_EN_G1 | \
+ PHY3P00_RX_ADAPT_AFE_EN_G2 | \
+ PHY3P00_RX_ADAPT_DFE_EN_G1 | \
+ PHY3P00_RX_ADAPT_DFE_EN_G2 | \
+ FIELD_PREP(PHY3P00_RX_EQ_CTLE_BOOST_G1, PHY3P_RX_EQ_CTLE_BOOST_G1_DEFAULT) | \
+ FIELD_PREP(PHY3P00_RX_EQ_CTLE_BOOST_G2, PHY3P_RX_EQ_CTLE_BOOST_G2_DEFAULT) | \
+ FIELD_PREP(PHY3P00_RX_EQ_DELTA_IQ_G1_LO, \
+ PHY3P_RX_EQ_DELTA_IQ_G1_DEFAULT & 0x3) \
+)
+
+#define PHY3P04_DEFAULT ( \
+ FIELD_PREP(PHY3P04_RX_EQ_DELTA_IQ_G1_HI, \
+ PHY3P_RX_EQ_DELTA_IQ_G1_DEFAULT >> 2) | \
+ FIELD_PREP(PHY3P04_RX_EQ_DELTA_IQ_G2, PHY3P_RX_EQ_DELTA_IQ_G2_DEFAULT) | \
+ PHY3P04_RX_LOS_LFPS_EN | \
+ FIELD_PREP(PHY3P04_RX_LOS_THRESHOLD, PHY3P_RX_LOS_THRESHOLD_DEFAULT) | \
+ FIELD_PREP(PHY3P04_RX_TERM_CTRL, PHY3P_RX_TERM_CTRL_DEFAULT) | \
+ FIELD_PREP(PHY3P04_TX_EQ_MAIN_G1_LO, \
+ PHY3P_TX_EQ_MAIN_G1_DEFAULT & 0x7) \
+)
+
+#define PHY3P08_DEFAULT ( \
+ FIELD_PREP(PHY3P08_TX_EQ_MAIN_G1_HI, PHY3P_TX_EQ_MAIN_G1_DEFAULT >> 3) | \
+ FIELD_PREP(PHY3P08_TX_EQ_MAIN_G2, PHY3P_TX_EQ_MAIN_G2_DEFAULT) | \
+ FIELD_PREP(PHY3P08_TX_EQ_POST_G1, PHY3P_TX_EQ_POST_G1_DEFAULT) | \
+ FIELD_PREP(PHY3P08_TX_EQ_POST_G2, PHY3P_TX_EQ_POST_G2_DEFAULT) | \
+ FIELD_PREP(PHY3P08_TX_EQ_PRE_G2, PHY3P_TX_EQ_PRE_G2_DEFAULT) | \
+ FIELD_PREP(PHY3P08_TX_IBOOST_LVL, PHY3P_TX_IBOOST_LVL_DEFAULT) | \
+ FIELD_PREP(PHY3P08_TX_TERM_CTRL, PHY3P_TX_TERM_CTRL_DEFAULT) \
+)
+
+#define PHY3P0C_DEFAULT \
+ PHY3P0C_TX_VBOOST_EN
+
+struct aspeed_usb3_phy {
+ void __iomem *regs;
+ struct reset_control *rst;
+ struct device *dev;
+ struct clk *clk;
+};
+
+static int aspeed_usb3_phy_init(struct phy *phy)
+{
+ struct aspeed_usb3_phy *aspeed_phy = phy_get_drvdata(phy);
+ u32 val;
+ int ret;
+
+ ret = clk_prepare_enable(aspeed_phy->clk);
+ if (ret) {
+ dev_err(aspeed_phy->dev, "Failed to enable clock %d\n", ret);
+ return ret;
+ }
+
+ ret = reset_control_deassert(aspeed_phy->rst);
+ if (ret) {
+ clk_disable_unprepare(aspeed_phy->clk);
+ return ret;
+ }
+
+ /* Wait for USB3 PHY internal SRAM initialization done */
+ ret = readl_poll_timeout(aspeed_phy->regs + PHY3S00, val,
+ val & PHY3S00_INIT_DONE,
+ USEC_PER_MSEC, 10 * USEC_PER_MSEC);
+ if (ret) {
+ dev_err(aspeed_phy->dev, "SRAM init timeout\n");
+ goto err_assert_reset;
+ }
+
+ val = readl(aspeed_phy->regs + PHY3S00);
+ val |= PHY3S00_SRAM_BYPASS;
+ writel(val, aspeed_phy->regs + PHY3S00);
+
+ /* Set protocol1_ext signals as default PHY3 settings based on SNPS documents.
+ * Including PCFGI[54]: protocol1_ext_rx_los_lfps_en for better compatibility
+ */
+ writel(PHY3P00_DEFAULT, aspeed_phy->regs + PHY3P00);
+ writel(PHY3P04_DEFAULT, aspeed_phy->regs + PHY3P04);
+ writel(PHY3P08_DEFAULT, aspeed_phy->regs + PHY3P08);
+ writel(PHY3P0C_DEFAULT, aspeed_phy->regs + PHY3P0C);
+
+ return 0;
+
+err_assert_reset:
+ reset_control_assert(aspeed_phy->rst);
+ clk_disable_unprepare(aspeed_phy->clk);
+ return ret;
+}
+
+static int aspeed_usb3_phy_exit(struct phy *phy)
+{
+ struct aspeed_usb3_phy *aspeed_phy = phy_get_drvdata(phy);
+
+ reset_control_assert(aspeed_phy->rst);
+ clk_disable_unprepare(aspeed_phy->clk);
+
+ return 0;
+}
+
+static const struct phy_ops aspeed_usb3_phy_ops = {
+ .init = aspeed_usb3_phy_init,
+ .exit = aspeed_usb3_phy_exit,
+ .owner = THIS_MODULE,
+};
+
+static int aspeed_usb3_phy_probe(struct platform_device *pdev)
+{
+ struct aspeed_usb3_phy *aspeed_phy;
+ struct phy_provider *phy_provider;
+ struct device *dev = &pdev->dev;
+ struct phy *phy;
+
+ aspeed_phy = devm_kzalloc(dev, sizeof(*aspeed_phy), GFP_KERNEL);
+ if (!aspeed_phy)
+ return -ENOMEM;
+
+ aspeed_phy->dev = dev;
+
+ aspeed_phy->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(aspeed_phy->clk))
+ return PTR_ERR(aspeed_phy->clk);
+
+ aspeed_phy->rst = devm_reset_control_get_exclusive(dev, NULL);
+ if (IS_ERR(aspeed_phy->rst))
+ return PTR_ERR(aspeed_phy->rst);
+
+ aspeed_phy->regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(aspeed_phy->regs))
+ return PTR_ERR(aspeed_phy->regs);
+
+ phy = devm_phy_create(dev, NULL, &aspeed_usb3_phy_ops);
+ if (IS_ERR(phy))
+ return PTR_ERR(phy);
+
+ phy_set_drvdata(phy, aspeed_phy);
+
+ phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+ return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct of_device_id aspeed_usb3_phy_match_table[] = {
+ {
+ .compatible = "aspeed,ast2700-usb3-phy",
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, aspeed_usb3_phy_match_table);
+
+static struct platform_driver aspeed_usb3_phy_driver = {
+ .probe = aspeed_usb3_phy_probe,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .of_match_table = aspeed_usb3_phy_match_table,
+ },
+};
+module_platform_driver(aspeed_usb3_phy_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("ASPEED USB3.0 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 v2 1/3] dt-bindings: phy: aspeed: Document AST2700 USB3.0 PHY
From: Ryan Chen @ 2026-01-16 2:53 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, Andrew Jeffery, Philipp Zabel
Cc: linux-phy, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen, Krzysztof Kozlowski
In-Reply-To: <20260116-upstream_usb3phy-v2-0-0b0c9f3eb6f4@aspeedtech.com>
Document AST2700 USB3.2 PHY. This IP is connected between
USB3 controller and PHY module.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
.../bindings/phy/aspeed,ast2700-usb3-phy.yaml | 48 ++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/aspeed,ast2700-usb3-phy.yaml b/Documentation/devicetree/bindings/phy/aspeed,ast2700-usb3-phy.yaml
new file mode 100644
index 000000000000..b83037aa0438
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/aspeed,ast2700-usb3-phy.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/aspeed,ast2700-usb3-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED AST2700 USB 3.2 PHY
+
+maintainers:
+ - Ryan Chen <ryan_chen@aspeedtech.com>
+
+properties:
+ compatible:
+ const: aspeed,ast2700-usb3-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ '#phy-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/aspeed,ast2700-scu.h>
+ #include <dt-bindings/reset/aspeed,ast2700-scu.h>
+
+ usb-phy@12010000 {
+ compatible = "aspeed,ast2700-usb3-phy";
+ reg = <0x12010000 0xc0>;
+ clocks = <&syscon0 SCU0_CLK_GATE_PORTAUSB2CLK>;
+ resets = <&syscon0 SCU0_RESET_PORTA_PHY3>;
+ #phy-cells = <0>;
+ };
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 0/3] Add AST2700 USB3.2 PHY driver
From: Ryan Chen @ 2026-01-16 2:53 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, Andrew Jeffery, Philipp Zabel
Cc: linux-phy, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen, Krzysztof Kozlowski
Add AST2700 USB3.2 PHY support.
- Supports Super Speed Plus Gen2x1 (10 Gbps), Super Speed (5 Gbps),
High Speed (480 Mbps), Full Speed (12Mbps), and Low Speed (1.5 Mbps).
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
Changes in v2:
- aspeed,ast2700-usb3-phy.yaml
- Drop clocks, resets descripton.
- Kconfig
- add COMPILE_TEST, remove default n
- Link to v1: https://lore.kernel.org/r/20260114-upstream_usb3phy-v1-0-2e59590be2d7@aspeedtech.com
---
Ryan Chen (3):
dt-bindings: phy: aspeed: Document AST2700 USB3.0 PHY
phy: add AST2700 usb3.2 phy driver
MAINTAINERS: Add ASPEED USB3 PHY driver
.../bindings/phy/aspeed,ast2700-usb3-phy.yaml | 48 +++++
MAINTAINERS | 8 +
drivers/phy/aspeed/Kconfig | 12 ++
drivers/phy/aspeed/Makefile | 2 +
drivers/phy/aspeed/phy-aspeed-usb3.c | 236 +++++++++++++++++++++
5 files changed, 306 insertions(+)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20260112-upstream_usb3phy-7116f8dfe779
Best regards,
--
Ryan Chen <ryan_chen@aspeedtech.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 04/10] spmi: Implement spmi_subdevice_alloc_and_add() and devm variant
From: Stephen Boyd @ 2026-01-16 2:08 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, jic23
Cc: dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
neil.armstrong, sre, angelogioacchino.delregno, 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, Jonathan Cameron
In-Reply-To: <20260114092742.13231-5-angelogioacchino.delregno@collabora.com>
Quoting AngeloGioacchino Del Regno (2026-01-14 03:27:36)
> Some devices connected over the SPMI bus may be big, in the sense
> that those may be a complex of devices managed by a single chip
> over the SPMI bus, reachable through a single SID.
>
> Add new functions aimed at managing sub-devices of a SPMI device
> spmi_subdevice_alloc_and_add() and a spmi_subdevice_put_and_remove()
> for adding a new subdevice and removing it respectively, and also
> add their devm_* variants.
>
> The need for such functions comes from the existence of those
> complex Power Management ICs (PMICs), which feature one or many
> sub-devices, in some cases with these being even addressable on
> the chip in form of SPMI register ranges.
>
> Examples of those devices can be found in both Qualcomm platforms
> with their PMICs having PON, RTC, SDAM, GPIO controller, and other
> sub-devices, and in newer MediaTek platforms showing similar HW
> features and a similar layout with those also having many subdevs.
>
> Also, instead of generally exporting symbols, export them with a
> new "SPMI" namespace: all users will have to import this namespace
> to make use of the newly introduced exports.
>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
Acked-by: Stephen Boyd <sboyd@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 03/10] spmi: Remove unneeded goto in spmi_device_add() error path
From: Stephen Boyd @ 2026-01-16 2:03 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, jic23
Cc: dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
neil.armstrong, sre, angelogioacchino.delregno, 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: <20260114092742.13231-4-angelogioacchino.delregno@collabora.com>
Quoting AngeloGioacchino Del Regno (2026-01-14 03:27:35)
> If any error happens during device_add() just return inside of the
> conditional, as the goto path doesn't do anything else if not just
> returning.
>
> While at it, to improve readability, also change this function to
> explicitly return 0 (for success) at the end.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
Acked-by: Stephen Boyd <sboyd@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 02/10] spmi: Print error status with %pe format
From: Stephen Boyd @ 2026-01-16 2:03 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, jic23
Cc: dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
neil.armstrong, sre, angelogioacchino.delregno, 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: <20260114092742.13231-3-angelogioacchino.delregno@collabora.com>
Quoting AngeloGioacchino Del Regno (2026-01-14 03:27:34)
> Instead of printing just a number, use the %pe format for error
> status, increasing readability of error prints.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
Acked-by: Stephen Boyd <sboyd@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 01/10] spmi: Remove redundant dev_name() print in spmi_device_add()
From: Stephen Boyd @ 2026-01-16 2:03 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, jic23
Cc: dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
neil.armstrong, sre, angelogioacchino.delregno, 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: <20260114092742.13231-2-angelogioacchino.delregno@collabora.com>
Quoting AngeloGioacchino Del Regno (2026-01-14 03:27:33)
> Function spmi_device_add() uses dev_{dbg,err}() for respectively
> debug and error prints, and passes the same device pointer as both
> the dev_{dbg,err}() parameters and to a dev_name() that is part of
> the actual message.
> This means that the device name gets printed twice!
>
> Remove the redundant dev_name() from the messages.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
Acked-by: Stephen Boyd <sboyd@kernel.org>
--
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