* Re: [PATCH 09/10] phy: qcom-qmp: pcs-pcie: Add v10.60 register offsets
From: sashiko-bot @ 2026-05-08 23:38 UTC (permalink / raw)
To: Matthew Leung
Cc: conor+dt, robh, krzk+dt, neil.armstrong, olteanv, linux-phy,
devicetree, vkoul
In-Reply-To: <20260508-hawi-phy-pcie-v1-9-237b894353fc@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The macro `QPHY_PCIE_V10_60_PCS_PCS_TX_RX_CONFIG` contains a redundant `PCS_` substring.
--
commit fa9d92bd2f41dd643566d490312c4a18a8a68214
Author: Matthew Leung <matthew.leung@oss.qualcomm.com>
phy: qcom-qmp: pcs-pcie: Add v10.60 register offsets
This commit adds a new header file containing the specific PCS PCIe register
offsets for the QMP phy version v10.60 used in Hawi SoCs.
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v10_60.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v10_60.h
> new file mode 100644
> index 0000000000000..e4a2bdc7c3f03
> --- /dev/null
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-pcie-v10_60.h
> @@ -0,0 +1,26 @@
[ ... ]
> +#ifndef QCOM_PHY_QMP_PCS_PCIE_V10_60_H_
> +#define QCOM_PHY_QMP_PCS_PCIE_V10_60_H_
> +
> +/* Only for QMP V10_60 PHY - PCIE PCS registers */
> +#define QPHY_PCIE_V10_60_PCS_POWER_STATE_CONFIG2 0x00c
> +#define QPHY_PCIE_V10_60_PCS_PCS_TX_RX_CONFIG 0x018
This isn't a bug, but there is a redundant "PCS_" substring in
QPHY_PCIE_V10_60_PCS_PCS_TX_RX_CONFIG.
Should this be named QPHY_PCIE_V10_60_PCS_TX_RX_CONFIG to remain consistent
with older PHY version headers like QPHY_PCIE_V8_PCS_TX_RX_CONFIG?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260508-hawi-phy-pcie-v1-0-237b894353fc@oss.qualcomm.com?part=9
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 00/16] phy: rockchip: usbdp: Fixes, DP 1-lane support and cleanups
From: Vinod Koul @ 2026-05-10 7:32 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Sebastian Reichel, Neil Armstrong, Frank Wang, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Andy Yan, Dmitry Baryshkov,
Yubing Zhang, Alexey Charkov, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel, kernel, devicetree, William Wu
In-Reply-To: <6960660.0VBMTVartN@phil>
Hi Heiko,
On 03-05-26, 21:12, Heiko Stuebner wrote:
> Hi Vinod,
>
> Am Sonntag, 3. Mai 2026, 18:50:12 Mitteleuropäische Sommerzeit schrieb Vinod Koul:
> > Hi Sebastian,
> >
> > On 28-04-26, 18:13, Sebastian Reichel wrote:
> > > This series overhauls the Rockchip USBDP driver; apart from a
> > > a bunch of cleanups and small improvements the main goal is to
> > > get the driver ready for proper USB-C DP AltMode support.
> > >
> > > Once this series has landed, it unblocks enabling proper USB-C
> > > DP AltMode on the RK3588 and RK3576 platforms incl. runtime PM
> > > for the Synopsys DesignWare DisplayPort controller.
> > >
> > > Apart from this series, further changes are required on the
> > > DRM side. There are no compile-time dependencies between the
> > > DRM side and the PHY side, but the PHY side must be applied
> > > to avoid SErrors once runtime PM is added to the DisplayPort
> > > controller driver. Thus it would be really good to land this
> > > series in the next merge window.
> >
> > Looks like sasiko has flagged 8 high warning, can you please check them
>
> (1) as mentioned in a different patch thread, review should be happening
> on the lists. Tools regularly dump old results, so anyone looking at the
> mailinglist thread might now be able to follow along with what happened
> in 2 months or so.
>
> Also other robot tools can reply on the lists just fine.
It was not available in past, have enabled email reply as that is best
way for us. It should happen going forward
> (2) if 1. is so hugely impossible, please at least provide some reference
> to what you mean. Not everybody knows all the hype-tools-of-the-week and
> simply searching for that mysterious "sasiko" [0] did not provide any
> meaningful results for me, despite some amazon or youtube links for some
> non-kernel uses of that term ;-)
I am surprised that the hype of the week seems to missing for you or
Sebastian as Sashiko has been, IMO covered quite well. Instead of a random
web search I would have looked at lwn [1], [2].
> So a link should be present at least please.
Agree, I have sent to people who I thought might not be aware. I guess
better to not assume. In any case here are the comments, which maybe
valid or maybe not. As usual with tools we should use our discretion
https://sashiko.dev/#/patchset/20260428-rockchip-usbdp-cleanup-v4-0-7775671ece22%40collabora.com
[1]: https://lwn.net/Articles/1063292/
[2]: https://lwn.net/Articles/1063303/
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 0/6] phy: rockchip: samsung-hdptx: Clock fixes and API transition cleanups
From: Vinod Koul @ 2026-05-10 7:36 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Neil Armstrong, Heiko Stuebner, Algea Cao, Dmitry Baryshkov,
kernel, linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260227-hdptx-clk-fixes-v1-0-f998f2762d0f@collabora.com>
On 27-02-26, 22:48, Cristian Ciocaltea wrote:
> This series provides a set of bug fixes and cleanups for the Rockchip
> Samsung HDPTX PHY driver.
>
> The first part of the series (i.e. PATCH 1 & 2) addresses clock rate
> calculation and synchronization issues. Specifically, it fixes edge
> cases where the PHY PLL is pre-programmed by an external component (like
> a bootloader) or when changing the color depth (bpc) while keeping the
> modeline constant. Because the Common Clock Framework .set_rate()
> callback might not be invoked if the pixel clock remains unchanged, this
> previously led to out-of-sync states between CCF and the actual HDMI PHY
> configuration.
>
> The second part focuses on code cleanups and modernizing the register
> access. Now that dw_hdmi_qp driver has fully switched to using
> phy_configure(), we can drop the deprecated TMDS rate setup workarounds
> and the restrict_rate_change flag logic. Finally, it refactors the
> driver to consistently use standard bitfield macros.
Sorry looks like I have missed to review this one.
Can you please rebase on phy/fixes and send...
Thanks
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 05/12] phy: add a driver for T-Head TH1520 USB PHY
From: Vinod Koul @ 2026-05-10 7:44 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Drew Fustini, Guo Ren, Fu Wei, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Greg Kroah-Hartman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Jisheng Zhang, Philipp Zabel, linux-riscv,
linux-clk, devicetree, linux-kernel, linux-gpio, linux-phy,
linux-usb, Icenowy Zheng, Han Gao, Yao Zi
In-Reply-To: <20260507081710.4090814-6-zhengxingda@iscas.ac.cn>
On 07-05-26, 16:17, Icenowy Zheng wrote:
> The USB PHY on T-Head TH1520 SoC is a Synopsys USB 3.0 FemtoPHY, with
> some PHY parameters exported as another system controller along with it.
>
> As a few PHY parameters' default value isn't ready to work, add a driver
> configuring them before letting the PHY run, in addition to
> clock/reset/regulator management.
Is there any dependency on the rest of series, if not please split up!
Some warnings flagged by sashiko, please check
https://sashiko.dev/#/patchset/20260507081710.4090814-1-zhengxingda%40iscas.ac.cn
>
> Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> ---
> drivers/phy/Kconfig | 1 +
> drivers/phy/Makefile | 1 +
> drivers/phy/thead/Kconfig | 12 ++
> drivers/phy/thead/Makefile | 2 +
> drivers/phy/thead/phy-th1520-usb.c | 197 +++++++++++++++++++++++++++++
> 5 files changed, 213 insertions(+)
> create mode 100644 drivers/phy/thead/Kconfig
> create mode 100644 drivers/phy/thead/Makefile
> create mode 100644 drivers/phy/thead/phy-th1520-usb.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 227b9a4c612e8..ea1a52e14b839 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -164,6 +164,7 @@ source "drivers/phy/st/Kconfig"
> source "drivers/phy/starfive/Kconfig"
> source "drivers/phy/sunplus/Kconfig"
> source "drivers/phy/tegra/Kconfig"
> +source "drivers/phy/thead/Kconfig"
> source "drivers/phy/ti/Kconfig"
> source "drivers/phy/xilinx/Kconfig"
>
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index f49d83f00a3d8..4604522548c91 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -48,5 +48,6 @@ obj-$(CONFIG_GENERIC_PHY) += allwinner/ \
> starfive/ \
> sunplus/ \
> tegra/ \
> + thead/ \
> ti/ \
> xilinx/
> diff --git a/drivers/phy/thead/Kconfig b/drivers/phy/thead/Kconfig
> new file mode 100644
> index 0000000000000..14012db5973c4
> --- /dev/null
> +++ b/drivers/phy/thead/Kconfig
> @@ -0,0 +1,12 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config PHY_TH1520_USB
> + tristate "USB PHY driver for T-Head TH1520 SoC"
> + depends on ARCH_THEAD || COMPILE_TEST
> + depends on COMMON_CLK
> + depends on HAS_IOMEM
> + depends on OF
> + depends on RESET_CONTROLLER
> + select GENERIC_PHY
> + default ARCH_THEAD
Why should this be default?
> + help
> + Enable support for the USB PHY on the T-Head TH1520 SoC.
> diff --git a/drivers/phy/thead/Makefile b/drivers/phy/thead/Makefile
> new file mode 100644
> index 0000000000000..5b459bc7004bd
> --- /dev/null
> +++ b/drivers/phy/thead/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +obj-$(CONFIG_PHY_TH1520_USB) += phy-th1520-usb.o
> diff --git a/drivers/phy/thead/phy-th1520-usb.c b/drivers/phy/thead/phy-th1520-usb.c
> new file mode 100644
> index 0000000000000..c87bd779bbb74
> --- /dev/null
> +++ b/drivers/phy/thead/phy-th1520-usb.c
> @@ -0,0 +1,197 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2026 Institute of Software, Chinese Academy of Sciences (ISCAS)
> + *
> + * Authors:
> + * Icenowy Zheng <zhengxingda@iscas.ac.cn>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/reset.h>
> +
> +#define USB_SYSCON_OFFSET 0xf000
> +
> +/* All the below registers are in the USB syscon region */
> +#define USB_CLK_GATE_STS 0x0
> +#define USB_LOGIC_ANALYZER_TRACE_STS0 0x4
> +#define USB_LOGIC_ANALYZER_TRACE_STS1 0x8
> +#define USB_GPIO 0xc
> +#define USB_DEBUG_STS0 0x10
> +#define USB_DEBUG_STS1 0x14
> +#define USB_DEBUG_STS2 0x18
> +#define USBCTL_CLK_CTRL0 0x1c
> +#define USBPHY_CLK_CTRL1 0x20
> +#define USBPHY_TEST_CTRL0 0x24
> +#define USBPHY_TEST_CTRL1 0x28
> +#define USBPHY_TEST_CTRL2 0x2c
> +#define USBPHY_TEST_CTRL3 0x30
> +#define USB_SSP_EN 0x34
> +#define USB_HADDR_SEL 0x38
> +#define USB_SYS 0x3c
> +#define USB_HOST_STATUS 0x40
> +#define USB_HOST_CTRL 0x44
> +#define USBPHY_HOST_CTRL 0x48
> +#define USBPHY_HOST_STATUS 0x4c
> +#define USB_TEST_REG0 0x50
> +#define USB_TEST_REG1 0x54
> +#define USB_TEST_REG2 0x58
> +#define USB_TEST_REG3 0x5c
Why do need these test registers, they seem unused?
> +
> +#define USB_SYS_COMMONONN BIT(0)
> +
> +#define USB_SSP_EN_REF_SSP_EN BIT(0)
> +
> +struct th1520_usb_phy {
> + struct platform_device *pdev;
> + struct phy *phy;
> + struct regmap *regmap;
> + struct clk *ref_clk;
> + struct reset_control *phy_reset;
> +};
> +
> +static int th1520_usb_phy_init(struct phy *phy)
> +{
> + struct th1520_usb_phy *th1520_phy = phy_get_drvdata(phy);
> + int ret;
> +
> + ret = clk_prepare_enable(th1520_phy->ref_clk);
> + if (ret)
> + return ret;
> +
> + ret = reset_control_assert(th1520_phy->phy_reset);
> + if (ret)
> + goto err_disable_clk;
> +
> + /*
> + * Do some initial PHY setup:
> + * - Set COMMONONN to allow the PHY to automatically power down.
> + * - Set REF_SSP_EN to enable feeding reference clock to SuperSpeed
> + * PHY clock PLL.
> + */
> + regmap_set_bits(th1520_phy->regmap, USB_SYS, USB_SYS_COMMONONN);
> + regmap_set_bits(th1520_phy->regmap, USB_SSP_EN, USB_SSP_EN_REF_SSP_EN);
> +
> + ret = reset_control_deassert(th1520_phy->phy_reset);
> + if (ret)
> + goto err_disable_clk;
> +
> + udelay(10);
> +
> + return 0;
> +
> +err_disable_clk:
> + clk_disable_unprepare(th1520_phy->ref_clk);
> + return ret;
> +}
> +
> +static int th1520_usb_phy_exit(struct phy *phy)
> +{
> + struct th1520_usb_phy *th1520_phy = phy_get_drvdata(phy);
> + int ret;
> +
> + ret = reset_control_assert(th1520_phy->phy_reset);
> + if (ret)
> + return ret;
> +
> + clk_disable_unprepare(th1520_phy->ref_clk);
> +
> + return 0;
> +}
> +
> +static const struct phy_ops th1520_usb_phy_ops = {
> + .init = th1520_usb_phy_init,
> + .exit = th1520_usb_phy_exit,
> + .owner = THIS_MODULE,
> +};
> +
> +static const struct regmap_config phy_regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .max_register = USB_TEST_REG3,
> +};
> +
> +static int th1520_usb_phy_probe(struct platform_device *pdev)
> +{
> + struct phy_provider *phy_provider;
> + struct device *dev = &pdev->dev;
> + struct th1520_usb_phy *th1520_phy;
> + struct reset_control *bus_reset;
> + void __iomem *base;
> + int ret;
> +
> + th1520_phy = devm_kzalloc(dev, sizeof(*th1520_phy), GFP_KERNEL);
> + if (!th1520_phy)
> + return -ENOMEM;
> +
> + th1520_phy->pdev = pdev;
> +
> + base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + th1520_phy->ref_clk = devm_clk_get(dev, "ref");
> + if (IS_ERR(th1520_phy->ref_clk))
> + return PTR_ERR(th1520_phy->ref_clk);
> +
> + /* De-assert the bus reset and leave it that way */
> + bus_reset = devm_reset_control_get_exclusive_deasserted(dev, "bus");
> + if (IS_ERR(bus_reset))
> + return PTR_ERR(bus_reset);
> +
> + th1520_phy->phy_reset = devm_reset_control_get_exclusive(dev, "phy");
> + if (IS_ERR(th1520_phy->phy_reset))
> + return PTR_ERR(th1520_phy->phy_reset);
> +
> + /*
> + * Schematics of several boards (Lichee Module 4A/Milk-V Meles)
> + * describe this power rail as always-on.
> + */
> + ret = devm_regulator_get_enable(dev, "avdd33-usb3");
> + if (ret)
> + return ret;
> +
> + th1520_phy->regmap = devm_regmap_init_mmio_clk(dev, "bus",
> + base + USB_SYSCON_OFFSET,
> + &phy_regmap_config);
> + if (IS_ERR(th1520_phy->regmap))
> + return dev_err_probe(dev, PTR_ERR(th1520_phy->regmap),
> + "Failed to init regmap\n");
> +
> + th1520_phy->phy = devm_phy_create(dev, dev->of_node, &th1520_usb_phy_ops);
> + if (IS_ERR(th1520_phy->phy)) {
> + dev_err(dev, "failed to create PHY\n");
> + return PTR_ERR(th1520_phy->phy);
> + }
> +
> + phy_set_drvdata(th1520_phy->phy, th1520_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 th1520_usb_phy_of_table[] = {
> + { .compatible = "thead,th1520-usb-phy" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, th1520_usb_phy_of_table);
> +
> +static struct platform_driver th1520_usb_phy_driver = {
> + .driver = {
> + .name = "th1520-usb-phy",
> + .of_match_table = th1520_usb_phy_of_table,
> + },
> + .probe = th1520_usb_phy_probe,
> +};
> +
> +module_platform_driver(th1520_usb_phy_driver);
> +
> +MODULE_DESCRIPTION("T-Head TH1520 USB PHY driver");
> +MODULE_LICENSE("GPL");
> --
> 2.52.0
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 0/6] phy: rockchip: samsung-hdptx: Clock fixes and API transition cleanups
From: Cristian Ciocaltea @ 2026-05-10 8:55 UTC (permalink / raw)
To: Vinod Koul
Cc: Neil Armstrong, Heiko Stuebner, Algea Cao, Dmitry Baryshkov,
kernel, linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <agA1dFpheTaBfyUt@vaman>
Hi Vinod,
On 5/10/26 10:36 AM, Vinod Koul wrote:
> On 27-02-26, 22:48, Cristian Ciocaltea wrote:
>> This series provides a set of bug fixes and cleanups for the Rockchip
>> Samsung HDPTX PHY driver.
>>
>> The first part of the series (i.e. PATCH 1 & 2) addresses clock rate
>> calculation and synchronization issues. Specifically, it fixes edge
>> cases where the PHY PLL is pre-programmed by an external component (like
>> a bootloader) or when changing the color depth (bpc) while keeping the
>> modeline constant. Because the Common Clock Framework .set_rate()
>> callback might not be invoked if the pixel clock remains unchanged, this
>> previously led to out-of-sync states between CCF and the actual HDMI PHY
>> configuration.
>>
>> The second part focuses on code cleanups and modernizing the register
>> access. Now that dw_hdmi_qp driver has fully switched to using
>> phy_configure(), we can drop the deprecated TMDS rate setup workarounds
>> and the restrict_rate_change flag logic. Finally, it refactors the
>> driver to consistently use standard bitfield macros.
>
> Sorry looks like I have missed to review this one.
> Can you please rebase on phy/fixes and send...
I've just verified and it applies cleanly on top of phy/fixes.
Do you still need a resend?
Regards,
Cristian
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 05/12] phy: add a driver for T-Head TH1520 USB PHY
From: Icenowy Zheng @ 2026-05-10 9:17 UTC (permalink / raw)
To: Vinod Koul
Cc: Drew Fustini, Guo Ren, Fu Wei, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Greg Kroah-Hartman, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Jisheng Zhang, Philipp Zabel, linux-riscv,
linux-clk, devicetree, linux-kernel, linux-gpio, linux-phy,
linux-usb, Han Gao, Yao Zi
In-Reply-To: <agA3URhGA1u6R7LD@vaman>
在 2026-05-10日的 13:14 +0530，Vinod Koul写道：
> On 07-05-26, 16:17, Icenowy Zheng wrote:
> > The USB PHY on T-Head TH1520 SoC is a Synopsys USB 3.0 FemtoPHY,
> > with
> > some PHY parameters exported as another system controller along
> > with it.
> >
> > As a few PHY parameters' default value isn't ready to work, add a
> > driver
> > configuring them before letting the PHY run, in addition to
> > clock/reset/regulator management.
>
> Is there any dependency on the rest of series, if not please split
> up!
I want to give reviewers a whole view of the implementation, although
the phy driver doesn't depends on other patches.
I am okay to split it out in the next revision.
>
> Some warnings flagged by sashiko, please check
> https://sashiko.dev/#/patchset/20260507081710.4090814-1-zhengxingda%40iscas.ac.cn
>
>
> >
> > Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> > ---
> > drivers/phy/Kconfig | 1 +
> > drivers/phy/Makefile | 1 +
> > drivers/phy/thead/Kconfig | 12 ++
> > drivers/phy/thead/Makefile | 2 +
> > drivers/phy/thead/phy-th1520-usb.c | 197
> > +++++++++++++++++++++++++++++
> > 5 files changed, 213 insertions(+)
> > create mode 100644 drivers/phy/thead/Kconfig
> > create mode 100644 drivers/phy/thead/Makefile
> > create mode 100644 drivers/phy/thead/phy-th1520-usb.c
> >
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> > index 227b9a4c612e8..ea1a52e14b839 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -164,6 +164,7 @@ source "drivers/phy/st/Kconfig"
> > source "drivers/phy/starfive/Kconfig"
> > source "drivers/phy/sunplus/Kconfig"
> > source "drivers/phy/tegra/Kconfig"
> > +source "drivers/phy/thead/Kconfig"
> > source "drivers/phy/ti/Kconfig"
> > source "drivers/phy/xilinx/Kconfig"
> >
> > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> > index f49d83f00a3d8..4604522548c91 100644
> > --- a/drivers/phy/Makefile
> > +++ b/drivers/phy/Makefile
> > @@ -48,5 +48,6 @@ obj-$(CONFIG_GENERIC_PHY) +=
> > allwinner/ \
> > starfive/ \
> > sunplus/ \
> > tegra/ \
> > + thead/ \
> > ti/ \
> > xilinx/
> > diff --git a/drivers/phy/thead/Kconfig b/drivers/phy/thead/Kconfig
> > new file mode 100644
> > index 0000000000000..14012db5973c4
> > --- /dev/null
> > +++ b/drivers/phy/thead/Kconfig
> > @@ -0,0 +1,12 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +config PHY_TH1520_USB
> > + tristate "USB PHY driver for T-Head TH1520 SoC"
> > + depends on ARCH_THEAD || COMPILE_TEST
> > + depends on COMMON_CLK
> > + depends on HAS_IOMEM
> > + depends on OF
> > + depends on RESET_CONTROLLER
> > + select GENERIC_PHY
> > + default ARCH_THEAD
>
> Why should this be default?
Okay, I will drop the default clause.
>
> > + help
> > + Enable support for the USB PHY on the T-Head TH1520 SoC.
> > diff --git a/drivers/phy/thead/Makefile
> > b/drivers/phy/thead/Makefile
> > new file mode 100644
> > index 0000000000000..5b459bc7004bd
> > --- /dev/null
> > +++ b/drivers/phy/thead/Makefile
> > @@ -0,0 +1,2 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +obj-$(CONFIG_PHY_TH1520_USB) += phy-th1520-usb.o
> > diff --git a/drivers/phy/thead/phy-th1520-usb.c
> > b/drivers/phy/thead/phy-th1520-usb.c
> > new file mode 100644
> > index 0000000000000..c87bd779bbb74
> > --- /dev/null
> > +++ b/drivers/phy/thead/phy-th1520-usb.c
> > @@ -0,0 +1,197 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2026 Institute of Software, Chinese Academy of
> > Sciences (ISCAS)
> > + *
> > + * Authors:
> > + * Icenowy Zheng <zhengxingda@iscas.ac.cn>
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/phy/phy.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +#include <linux/regulator/consumer.h>
> > +#include <linux/reset.h>
> > +
> > +#define USB_SYSCON_OFFSET 0xf000
> > +
> > +/* All the below registers are in the USB syscon region */
> > +#define USB_CLK_GATE_STS 0x0
> > +#define USB_LOGIC_ANALYZER_TRACE_STS0 0x4
> > +#define USB_LOGIC_ANALYZER_TRACE_STS1 0x8
> > +#define USB_GPIO 0xc
> > +#define USB_DEBUG_STS0 0x10
> > +#define USB_DEBUG_STS1 0x14
> > +#define USB_DEBUG_STS2 0x18
> > +#define USBCTL_CLK_CTRL0 0x1c
> > +#define USBPHY_CLK_CTRL1 0x20
> > +#define USBPHY_TEST_CTRL0 0x24
> > +#define USBPHY_TEST_CTRL1 0x28
> > +#define USBPHY_TEST_CTRL2 0x2c
> > +#define USBPHY_TEST_CTRL3 0x30
> > +#define USB_SSP_EN 0x34
> > +#define USB_HADDR_SEL 0x38
> > +#define USB_SYS 0x3c
> > +#define USB_HOST_STATUS 0x40
> > +#define USB_HOST_CTRL 0x44
> > +#define USBPHY_HOST_CTRL 0x48
> > +#define USBPHY_HOST_STATUS 0x4c
> > +#define USB_TEST_REG0 0x50
> > +#define USB_TEST_REG1 0x54
> > +#define USB_TEST_REG2 0x58
> > +#define USB_TEST_REG3 0x5c
>
> Why do need these test registers, they seem unused?
The register list is copied from the SoC manual, although most of them
are unused.
Should I remove all unused registers, as the manual is publicly
available?
Thanks,
Icenowy
>
> > +
> > +#define USB_SYS_COMMONONN BIT(0)
> > +
> > +#define USB_SSP_EN_REF_SSP_EN BIT(0)
> > +
> > +struct th1520_usb_phy {
> > + struct platform_device *pdev;
> > + struct phy *phy;
> > + struct regmap *regmap;
> > + struct clk *ref_clk;
> > + struct reset_control *phy_reset;
> > +};
> > +
> > +static int th1520_usb_phy_init(struct phy *phy)
> > +{
> > + struct th1520_usb_phy *th1520_phy = phy_get_drvdata(phy);
> > + int ret;
> > +
> > + ret = clk_prepare_enable(th1520_phy->ref_clk);
> > + if (ret)
> > + return ret;
> > +
> > + ret = reset_control_assert(th1520_phy->phy_reset);
> > + if (ret)
> > + goto err_disable_clk;
> > +
> > + /*
> > + * Do some initial PHY setup:
> > + * - Set COMMONONN to allow the PHY to automatically power
> > down.
> > + * - Set REF_SSP_EN to enable feeding reference clock to
> > SuperSpeed
> > + * PHY clock PLL.
> > + */
> > + regmap_set_bits(th1520_phy->regmap, USB_SYS,
> > USB_SYS_COMMONONN);
> > + regmap_set_bits(th1520_phy->regmap, USB_SSP_EN,
> > USB_SSP_EN_REF_SSP_EN);
> > +
> > + ret = reset_control_deassert(th1520_phy->phy_reset);
> > + if (ret)
> > + goto err_disable_clk;
> > +
> > + udelay(10);
> > +
> > + return 0;
> > +
> > +err_disable_clk:
> > + clk_disable_unprepare(th1520_phy->ref_clk);
> > + return ret;
> > +}
> > +
> > +static int th1520_usb_phy_exit(struct phy *phy)
> > +{
> > + struct th1520_usb_phy *th1520_phy = phy_get_drvdata(phy);
> > + int ret;
> > +
> > + ret = reset_control_assert(th1520_phy->phy_reset);
> > + if (ret)
> > + return ret;
> > +
> > + clk_disable_unprepare(th1520_phy->ref_clk);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct phy_ops th1520_usb_phy_ops = {
> > + .init = th1520_usb_phy_init,
> > + .exit = th1520_usb_phy_exit,
> > + .owner = THIS_MODULE,
> > +};
> > +
> > +static const struct regmap_config phy_regmap_config = {
> > + .reg_bits = 32,
> > + .val_bits = 32,
> > + .reg_stride = 4,
> > + .max_register = USB_TEST_REG3,
> > +};
> > +
> > +static int th1520_usb_phy_probe(struct platform_device *pdev)
> > +{
> > + struct phy_provider *phy_provider;
> > + struct device *dev = &pdev->dev;
> > + struct th1520_usb_phy *th1520_phy;
> > + struct reset_control *bus_reset;
> > + void __iomem *base;
> > + int ret;
> > +
> > + th1520_phy = devm_kzalloc(dev, sizeof(*th1520_phy),
> > GFP_KERNEL);
> > + if (!th1520_phy)
> > + return -ENOMEM;
> > +
> > + th1520_phy->pdev = pdev;
> > +
> > + base = devm_platform_ioremap_resource(pdev, 0);
> > + if (IS_ERR(base))
> > + return PTR_ERR(base);
> > +
> > + th1520_phy->ref_clk = devm_clk_get(dev, "ref");
> > + if (IS_ERR(th1520_phy->ref_clk))
> > + return PTR_ERR(th1520_phy->ref_clk);
> > +
> > + /* De-assert the bus reset and leave it that way */
> > + bus_reset =
> > devm_reset_control_get_exclusive_deasserted(dev, "bus");
> > + if (IS_ERR(bus_reset))
> > + return PTR_ERR(bus_reset);
> > +
> > + th1520_phy->phy_reset =
> > devm_reset_control_get_exclusive(dev, "phy");
> > + if (IS_ERR(th1520_phy->phy_reset))
> > + return PTR_ERR(th1520_phy->phy_reset);
> > +
> > + /*
> > + * Schematics of several boards (Lichee Module 4A/Milk-V
> > Meles)
> > + * describe this power rail as always-on.
> > + */
> > + ret = devm_regulator_get_enable(dev, "avdd33-usb3");
> > + if (ret)
> > + return ret;
> > +
> > + th1520_phy->regmap = devm_regmap_init_mmio_clk(dev, "bus",
> > + base +
> > USB_SYSCON_OFFSET,
> > +
> > &phy_regmap_config);
> > + if (IS_ERR(th1520_phy->regmap))
> > + return dev_err_probe(dev, PTR_ERR(th1520_phy-
> > >regmap),
> > + "Failed to init regmap\n");
> > +
> > + th1520_phy->phy = devm_phy_create(dev, dev->of_node,
> > &th1520_usb_phy_ops);
> > + if (IS_ERR(th1520_phy->phy)) {
> > + dev_err(dev, "failed to create PHY\n");
> > + return PTR_ERR(th1520_phy->phy);
> > + }
> > +
> > + phy_set_drvdata(th1520_phy->phy, th1520_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 th1520_usb_phy_of_table[] = {
> > + { .compatible = "thead,th1520-usb-phy" },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(of, th1520_usb_phy_of_table);
> > +
> > +static struct platform_driver th1520_usb_phy_driver = {
> > + .driver = {
> > + .name = "th1520-usb-phy",
> > + .of_match_table = th1520_usb_phy_of_table,
> > + },
> > + .probe = th1520_usb_phy_probe,
> > +};
> > +
> > +module_platform_driver(th1520_usb_phy_driver);
> > +
> > +MODULE_DESCRIPTION("T-Head TH1520 USB PHY driver");
> > +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
* Re: [PATCH v2 0/4] Add USB Phy driver and binding changes for Qualcomm Shikra SoC
From: Vinod Koul @ 2026-05-10 9:29 UTC (permalink / raw)
To: Krishna Kurapati
Cc: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Xiangxu Yin, Johan Hovold,
Loic Poulain, Kathiravan Thirumoorthy, Dmitry Baryshkov,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260504170659.282532-1-krishna.kurapati@oss.qualcomm.com>
On 04-05-26, 22:36, Krishna Kurapati wrote:
> This series adds Driver and binding changes for USB Phys on Shikra. There
> are two USB controllers - One of them is SS capable and other is highspeed
> only capable. The ss Phy init sequence is same as that of Talos.
Please check https://sashiko.dev/#/patchset/20260504170659.282532-1-krishna.kurapati%40oss.qualcomm.com
>
> Changes in v2:
> - Separated the usb controller binding changes
> - Updated commit texts.
>
> Krishna Kurapati (4):
> dt-bindings: phy: qcom,qusb2: Document QUSB2 Phy for Shikra
> dt-bindings: phy: qcom,msm8998-qmp-usb3-phy: Add support for Shikra
> phy: qcom-qusb2: Add support for Shikra
> phy: qcom: qmp-usbc: Add qmp configuration for Shikra
>
> .../bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml | 2 ++
> .../devicetree/bindings/phy/qcom,qusb2-phy.yaml | 1 +
> drivers/phy/qualcomm/phy-qcom-qmp-usbc.c | 3 +++
> drivers/phy/qualcomm/phy-qcom-qusb2.c | 16 ++++++++++++++++
> 4 files changed, 22 insertions(+)
>
> --
> 2.34.1
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 1/2] phy: rockchip: inno-hdmi: Add configure() and validate() ops
From: Jonas Karlman @ 2026-05-10 9:57 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner
Cc: linux-phy, linux-rockchip, linux-arm-kernel, linux-kernel,
Jonas Karlman
In-Reply-To: <20260510095731.1222705-1-jonas@kwiboo.se>
The commit 10ed34d6eaaf ("phy: Add HDMI configuration options")
introduced a way for HDMI PHYs to be configured through the generic
phy_configure() function.
This driver derives the TMDS character rate from the pixel clock and the
PHY bus width setting. However, no in-tree consumer of this PHY has ever
called phy_set_bus_width() to change the TMDS character rate as only
8-bit RGB output is supported by the HDMI display driver.
Add configure() and validate() ops to allow consumers to configure the
TMDS character rate using phy_configure(). Fallback to the deprecated
way of using the PHY bus width to configure the TMDS character rate.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
---
Changes in v2:
- Add validate() ops to validate that the TMDS rate is supported
- Split out parts that remove the old workaround into a separate patch
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 47 ++++++++++++++++++-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 1483907413fa..9cfe956fefe7 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -245,6 +245,7 @@ struct inno_hdmi_phy {
struct clk *phyclk;
unsigned long pixclock;
unsigned long tmdsclock;
+ struct phy_configure_opts_hdmi hdmi_cfg;
};
struct pre_pll_config {
@@ -554,7 +555,12 @@ static inline void inno_update_bits(struct inno_hdmi_phy *inno, u8 reg,
static unsigned long inno_hdmi_phy_get_tmdsclk(struct inno_hdmi_phy *inno,
unsigned long rate)
{
- int bus_width = phy_get_bus_width(inno->phy);
+ int bus_width;
+
+ if (inno->hdmi_cfg.tmds_char_rate)
+ return inno->hdmi_cfg.tmds_char_rate;
+
+ bus_width = phy_get_bus_width(inno->phy);
switch (bus_width) {
case 4:
@@ -602,6 +608,42 @@ static irqreturn_t inno_hdmi_phy_rk3328_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static int inno_hdmi_phy_validate(struct phy *phy, enum phy_mode mode,
+ int submode, union phy_configure_opts *opts)
+{
+ const struct pre_pll_config *cfg = pre_pll_cfg_table;
+ unsigned long tmdsclock;
+
+ if (!(mode == PHY_MODE_HDMI && submode == PHY_HDMI_MODE_TMDS))
+ return -EINVAL;
+
+ if (!opts->hdmi.tmds_char_rate || opts->hdmi.tmds_char_rate > 594000000)
+ return -EINVAL;
+
+ tmdsclock = opts->hdmi.tmds_char_rate;
+ for (; cfg->pixclock != 0; cfg++)
+ if (cfg->pixclock == tmdsclock && cfg->tmdsclock == tmdsclock)
+ return 0;
+
+ return -EINVAL;
+}
+
+static int inno_hdmi_phy_configure(struct phy *phy,
+ union phy_configure_opts *opts)
+{
+ struct inno_hdmi_phy *inno = phy_get_drvdata(phy);
+ int ret;
+
+ ret = inno_hdmi_phy_validate(phy, phy_get_mode(phy),
+ PHY_HDMI_MODE_TMDS, opts);
+ if (ret)
+ return ret;
+
+ inno->hdmi_cfg = opts->hdmi;
+
+ return 0;
+}
+
static int inno_hdmi_phy_power_on(struct phy *phy)
{
struct inno_hdmi_phy *inno = phy_get_drvdata(phy);
@@ -670,6 +712,8 @@ static const struct phy_ops inno_hdmi_phy_ops = {
.owner = THIS_MODULE,
.power_on = inno_hdmi_phy_power_on,
.power_off = inno_hdmi_phy_power_off,
+ .configure = inno_hdmi_phy_configure,
+ .validate = inno_hdmi_phy_validate,
};
static const
@@ -1392,6 +1436,7 @@ static int inno_hdmi_phy_probe(struct platform_device *pdev)
}
phy_set_drvdata(inno->phy, inno);
+ phy_set_mode_ext(inno->phy, PHY_MODE_HDMI, PHY_HDMI_MODE_TMDS);
phy_set_bus_width(inno->phy, 8);
if (inno->plat_data->ops->init) {
--
2.54.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 0/2] phy: rockchip: inno-hdmi: Change TMDS rate handling to configure() ops
From: Jonas Karlman @ 2026-05-10 9:57 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner
Cc: linux-phy, linux-rockchip, linux-arm-kernel, linux-kernel,
Jonas Karlman
This series adds support for using phy_validate() and phy_configure()
with this HDMI PHY as an alternative to current in-tree unused way of
using PHY bus width to configure the TMDS character rate.
The only known users that calls phy_set_bus_width() on this PHY are my
out-of-tree HDMI 2.0 patches for Rockchip RK3228/RK3328, i.e. those
originating from LibreELEC (also carried by other distros), the
downstream vendor kernel uses a different implementation that also calls
phy_set_bus_width() on this PHY.
Patches that calls phy_validate() and phy_configure() on this PHY should
land on mailing lists any day now.
This series is part of a larger multi series effort to:
- phy: rockchip: inno-hdmi: Change TMDS rate handling to configure() ops
- drm/rockchip: dw_hdmi: Misc cleanup and propagate bus format
- drm: bridge: dw_hdmi: Misc enable/disable, CEC and EDID cleanup
- drm/bridge: dw-hdmi: Improve input/output bus format handling
- drm/bridge: dw-hdmi: Convert to a HDMI bridge and use of bridge connector
- drm/bridge: dw-hdmi: Add and use tmds_char_rate_valid() plat data ops
- drm/meson: hdmi: Misc cleanup and use CEC notifier helpers
- drm/rockchip: dw_hdmi: Enable YCbCr and Deep Color modes
Link to snapshot: https://github.com/Kwiboo/linux-rockchip/commits/next-20260508-rk-hdmi-v3/
Changes in v2:
- Split into two patches, one that adds new ops and a second that remove
the old and unused workaround
- Add validate() ops to validate that the TMDS rate is supported
Link to v1: https://lore.kernel.org/linux-phy/20260503172936.194003-1-jonas@kwiboo.se/
Jonas Karlman (2):
phy: rockchip: inno-hdmi: Add configure() and validate() ops
phy: rockchip: inno-hdmi: Remove deprecated way to configure TMDS rate
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 58 ++++++++++++++-----
1 file changed, 44 insertions(+), 14 deletions(-)
--
2.54.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 2/2] phy: rockchip: inno-hdmi: Remove deprecated way to configure TMDS rate
From: Jonas Karlman @ 2026-05-10 9:57 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner
Cc: linux-phy, linux-rockchip, linux-arm-kernel, linux-kernel,
Jonas Karlman
In-Reply-To: <20260510095731.1222705-1-jonas@kwiboo.se>
The TMDS character rate of this PHY is configured using PHY bus width
in downstream vendor kernel and out-of-tree patches, however no in-tree
consumer of this PHY has ever called phy_set_bus_width() to change the
TMDS character rate as currently only 8-bit RGB output is supported by
the HDMI display driver.
The series "Split Generic PHY consumer and provider" clarifies that
phy_set_bus_width() is intended as a provider-only function.
Remove the deprecated unused fallback way to configure TMDS character
rate now that this HDMI PHY support using phy_configure() to configure
the TMDS character rate.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
---
v2: New patch, split from original patch
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 17 +----------------
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 9cfe956fefe7..5e76a1ea9d9f 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -555,24 +555,10 @@ static inline void inno_update_bits(struct inno_hdmi_phy *inno, u8 reg,
static unsigned long inno_hdmi_phy_get_tmdsclk(struct inno_hdmi_phy *inno,
unsigned long rate)
{
- int bus_width;
-
if (inno->hdmi_cfg.tmds_char_rate)
return inno->hdmi_cfg.tmds_char_rate;
- bus_width = phy_get_bus_width(inno->phy);
-
- switch (bus_width) {
- case 4:
- case 5:
- case 6:
- case 10:
- case 12:
- case 16:
- return (u64)rate * bus_width / 8;
- default:
- return rate;
- }
+ return rate;
}
static irqreturn_t inno_hdmi_phy_rk3328_hardirq(int irq, void *dev_id)
@@ -1437,7 +1423,6 @@ static int inno_hdmi_phy_probe(struct platform_device *pdev)
phy_set_drvdata(inno->phy, inno);
phy_set_mode_ext(inno->phy, PHY_MODE_HDMI, PHY_HDMI_MODE_TMDS);
- phy_set_bus_width(inno->phy, 8);
if (inno->plat_data->ops->init) {
ret = inno->plat_data->ops->init(inno);
--
2.54.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 13/15] phy: mediatek: phy-mtk-hdmi-mt2701: use clk_determine_rate_noop()
From: Vinod Koul @ 2026-05-10 10:17 UTC (permalink / raw)
To: Brian Masney
Cc: Michael Turquette, Stephen Boyd, linux-clk, linux-kernel,
Chun-Kuang Hu, Philipp Zabel, Chunfeng Yun, Matthias Brugger,
AngeloGioacchino Del Regno, Neil Armstrong, dri-devel,
linux-mediatek, linux-arm-kernel, linux-phy
In-Reply-To: <20260505-clk-determine-rate-noop-v3-13-f3f829fbacdf@redhat.com>
On 05-05-26, 20:49, Brian Masney wrote:
> Drop the driver-specific empty determine_rate() function and use the new
> shared clk_determine_rate_noop() helper.
Acked-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 0/2] riscv: spacemit: Add K3 PCIe/USB comb phy support
From: Vinod Koul @ 2026-05-10 10:44 UTC (permalink / raw)
To: Inochi Amaoto
Cc: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Kees Cook, Gustavo A. R. Silva, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Ze Huang, Alex Elder,
linux-phy, devicetree, linux-riscv, spacemit, linux-kernel,
linux-hardening, Yixun Lan, Longbin Li
In-Reply-To: <20260430022843.1090138-1-inochiama@gmail.com>
On 30-04-26, 10:28, Inochi Amaoto wrote:
> The PCIe/USB comb phy on K3 is a big phy that contains multiple
> standalone phys for each PCIe and USB controllers. This phy is
> required to configure a syscon device for mux configuration and
> calibration.
Please check https://sashiko.dev/#/patchset/20260430022843.1090138-1-inochiama%40gmail.com
>
> Inochi Amaoto (2):
> dt-bindings: phy: Add Spacemit K3 USB3/PCIe comb phy support
> phy: spacemit: Add USB3/PCIe comb PHY driver for Spacemit K3
>
> .../bindings/phy/spacemit,k3-comb-phy.yaml | 63 +++
> drivers/phy/spacemit/Kconfig | 16 +
> drivers/phy/spacemit/Makefile | 2 +
> drivers/phy/spacemit/phy-k3-combphy.c | 250 +++++++++++
> drivers/phy/spacemit/phy-k3-common.c | 398 ++++++++++++++++++
> drivers/phy/spacemit/phy-k3-common.h | 27 ++
> 6 files changed, 756 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/spacemit,k3-comb-phy.yaml
> create mode 100644 drivers/phy/spacemit/phy-k3-combphy.c
> create mode 100644 drivers/phy/spacemit/phy-k3-common.c
> create mode 100644 drivers/phy/spacemit/phy-k3-common.h
>
> --
> 2.54.0
--
~Vinod
--
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] phy: phy-can-transceiver: Ad-hoc cleanups and refactoring
From: Vinod Koul @ 2026-05-10 10:51 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Peng Fan, linux-can, linux-phy, linux-kernel, Marc Kleine-Budde,
Vincent Mailhol, Neil Armstrong, Josua Mayer, Ulf Hansson
In-Reply-To: <20260504070054.29508-1-andriy.shevchenko@linux.intel.com>
On 04-05-26, 08:58, Andy Shevchenko wrote:
> The driver does two things that need to be addressed:
> - includes subject to remove gpio.h
> - checks for error code from device property APIs when it can be done in
> a robust way
>
> This series addresses the above and adds a couple of additional refactoring.
Sashiko flagged some issues, some of them not introduced by this, can
you please check this:
https://sashiko.dev/#/patchset/20260504070054.29508-1-andriy.shevchenko%40linux.intel.com
--
~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: rockchip: naneng-combphy: Consolidate SSC configuration
From: Vinod Koul @ 2026-05-10 11:01 UTC (permalink / raw)
To: Shawn Lin; +Cc: linux-rockchip, linux-phy, Heiko Stuebner, Neil Armstrong
In-Reply-To: <1777251433-110466-1-git-send-email-shawn.lin@rock-chips.com>
On 27-04-26, 08:57, Shawn Lin wrote:
> The PCIe SSC configuration for the RK3588 and RK3576 SoCs required
> additional tuning which is missing. When adding these same SSC
> configurations for both of these two SoCs, as well as upcoming
> platforms, it's obvious the SSC setup code was largely duplicated
> across the platform-specific configuration functions. This becomes
> harder to maintain as more platforms are added.
>
> So extract the common SSC logic into a shared helper function,
> rk_combphy_common_cfg_ssc(). This cleans up the per-platform drivers
> and centralizes the standard configuration as possible.
Please check
https://sashiko.dev/#/patchset/1777251433-110466-1-git-send-email-shawn.lin%40rock-chips.com
>
> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
> Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
> ---
> .../rockchip/phy-rockchip-naneng-combphy.c | 173 ++++++++----------
> 1 file changed, 73 insertions(+), 100 deletions(-)
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c b/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
> index b60d6bf3f33c..2b0f152f5470 100644
> --- a/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
> +++ b/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
> @@ -121,6 +121,7 @@
> #define RK3568_PHYREG32_SSC_OFFSET_500PPM 1
>
> #define RK3568_PHYREG33 0x80
> +#define RK3568_PHYREG33_PLL_SSC_CTRL BIT(5)
> #define RK3568_PHYREG33_PLL_KVCO_MASK GENMASK(4, 2)
> #define RK3568_PHYREG33_PLL_KVCO_SHIFT 2
> #define RK3568_PHYREG33_PLL_KVCO_VALUE 2
> @@ -446,6 +447,74 @@ static int rockchip_combphy_probe(struct platform_device *pdev)
> return PTR_ERR_OR_ZERO(phy_provider);
> }
>
> +static void rk_combphy_common_cfg_ssc(struct rockchip_combphy_priv *priv, unsigned long rate)
> +{
> + struct device_node *np = priv->dev->of_node;
> + u32 val;
> +
> + if (!priv->enable_ssc)
> + return;
> +
> + /* Set SSC downward spread spectrum for PCIe and USB3 */
> + if (priv->type == PHY_TYPE_PCIE || priv->type == PHY_TYPE_USB3) {
> + val = FIELD_PREP(RK3568_PHYREG32_SSC_MASK, RK3568_PHYREG32_SSC_DOWNWARD);
> + rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> + }
> +
> + /* Set SSC downward spread spectrum +500ppm for SATA in 100MHz */
> + if (priv->type == PHY_TYPE_SATA && rate == REF_CLOCK_100MHz) {
> + val = FIELD_PREP(RK3568_PHYREG32_SSC_DIR_MASK,
> + RK3568_PHYREG32_SSC_DOWNWARD);
> + val |= FIELD_PREP(RK3568_PHYREG32_SSC_OFFSET_MASK,
> + RK3568_PHYREG32_SSC_OFFSET_500PPM);
> + rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val,
> + RK3568_PHYREG32);
> + }
> +
> + /* Enable SSC */
> + val = readl(priv->mmio + RK3568_PHYREG8);
> + val |= RK3568_PHYREG8_SSC_EN;
> + writel(val, priv->mmio + RK3568_PHYREG8);
> +
> + /* Some SoCs need tuning PCIe SSC instead of default configuration in 24MHz */
> + if (!of_device_is_compatible(np, "rockchip,rk3588-naneng-combphy") &&
> + !of_device_is_compatible(np, "rockchip,rk3576-naneng-combphy"))
> + return;
> +
> + /* PLL control SSC module period should be set if need tuning */
> + val = readl(priv->mmio + RK3568_PHYREG33);
> + val |= RK3568_PHYREG33_PLL_SSC_CTRL;
> + writel(val, priv->mmio + RK3568_PHYREG33);
> +
> + if (priv->type == PHY_TYPE_PCIE && rate == REF_CLOCK_24MHz) {
> + /* Set PLL loop divider */
> + writel(0x00, priv->mmio + RK3576_PHYREG17);
> + writel(RK3568_PHYREG18_PLL_LOOP, priv->mmio + RK3568_PHYREG18);
> +
> + /* Set up rx_pck invert and rx msb to disable */
> + writel(0x00, priv->mmio + RK3588_PHYREG27);
> +
> + /*
> + * Set up SU adjust signal:
> + * su_trim[7:0], PLL KVCO adjust bits[2:0] to min
> + * su_trim[15:8], PLL LPF R1 adujst bits[9:7]=3'b101
> + * su_trim[23:16], CKRCV adjust
> + * su_trim[31:24], CKDRV adjust
> + */
> + writel(0x90, priv->mmio + RK3568_PHYREG11);
> + writel(0x02, priv->mmio + RK3568_PHYREG12);
> + writel(0x08, priv->mmio + RK3568_PHYREG13);
> + writel(0x57, priv->mmio + RK3568_PHYREG14);
> + writel(0x40, priv->mmio + RK3568_PHYREG15);
> +
> + writel(RK3568_PHYREG16_SSC_CNT_VALUE, priv->mmio + RK3568_PHYREG16);
> +
> + val = FIELD_PREP(RK3568_PHYREG33_PLL_KVCO_MASK,
> + RK3576_PHYREG33_PLL_KVCO_VALUE);
> + writel(val, priv->mmio + RK3568_PHYREG33);
> + }
> +}
> +
> static int rk3528_combphy_cfg(struct rockchip_combphy_priv *priv)
> {
> const struct rockchip_combphy_grfcfg *cfg = priv->cfg->grfcfg;
> @@ -600,21 +669,12 @@ static int rk3562_combphy_cfg(struct rockchip_combphy_priv *priv)
>
> switch (priv->type) {
> case PHY_TYPE_PCIE:
> - /* Set SSC downward spread spectrum */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT;
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> -
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con0_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con1_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con2_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con3_for_pcie, true);
> break;
> case PHY_TYPE_USB3:
> - /* Set SSC downward spread spectrum */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT;
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val,
> - RK3568_PHYREG32);
> -
> /* Enable adaptive CTLE for USB3.0 Rx */
> rockchip_combphy_updatel(priv, RK3568_PHYREG15_CTLE_EN,
> RK3568_PHYREG15_CTLE_EN, RK3568_PHYREG15);
> @@ -706,11 +766,7 @@ static int rk3562_combphy_cfg(struct rockchip_combphy_priv *priv)
> }
> }
>
> - if (priv->enable_ssc) {
> - val = readl(priv->mmio + RK3568_PHYREG8);
> - val |= RK3568_PHYREG8_SSC_EN;
> - writel(val, priv->mmio + RK3568_PHYREG8);
> - }
> + rk_combphy_common_cfg_ssc(priv, rate);
>
> return 0;
> }
> @@ -755,11 +811,6 @@ static int rk3568_combphy_cfg(struct rockchip_combphy_priv *priv)
>
> switch (priv->type) {
> case PHY_TYPE_PCIE:
> - /* Set SSC downward spread spectrum. */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT;
> -
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> -
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con0_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con1_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con2_for_pcie, true);
> @@ -767,10 +818,6 @@ static int rk3568_combphy_cfg(struct rockchip_combphy_priv *priv)
> break;
>
> case PHY_TYPE_USB3:
> - /* Set SSC downward spread spectrum. */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT,
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> -
> /* Enable adaptive CTLE for USB3.0 Rx. */
> val = readl(priv->mmio + RK3568_PHYREG15);
> val |= RK3568_PHYREG15_CTLE_EN;
> @@ -880,13 +927,6 @@ static int rk3568_combphy_cfg(struct rockchip_combphy_priv *priv)
>
> writel(RK3568_PHYREG18_PLL_LOOP, priv->mmio + RK3568_PHYREG18);
> writel(RK3568_PHYREG11_SU_TRIM_0_7, priv->mmio + RK3568_PHYREG11);
> - } else if (priv->type == PHY_TYPE_SATA) {
> - /* downward spread spectrum +500ppm */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT;
> - val |= RK3568_PHYREG32_SSC_OFFSET_500PPM <<
> - RK3568_PHYREG32_SSC_OFFSET_SHIFT;
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val,
> - RK3568_PHYREG32);
> }
> break;
>
> @@ -909,11 +949,7 @@ static int rk3568_combphy_cfg(struct rockchip_combphy_priv *priv)
> }
> }
>
> - if (priv->enable_ssc) {
> - val = readl(priv->mmio + RK3568_PHYREG8);
> - val |= RK3568_PHYREG8_SSC_EN;
> - writel(val, priv->mmio + RK3568_PHYREG8);
> - }
> + rk_combphy_common_cfg_ssc(priv, rate);
>
> return 0;
> }
> @@ -972,10 +1008,6 @@ static int rk3576_combphy_cfg(struct rockchip_combphy_priv *priv)
>
> switch (priv->type) {
> case PHY_TYPE_PCIE:
> - /* Set SSC downward spread spectrum */
> - val = FIELD_PREP(RK3568_PHYREG32_SSC_MASK, RK3568_PHYREG32_SSC_DOWNWARD);
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> -
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con0_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con1_for_pcie, true);
> rockchip_combphy_param_write(priv->phy_grf, &cfg->con2_for_pcie, true);
> @@ -983,10 +1015,6 @@ static int rk3576_combphy_cfg(struct rockchip_combphy_priv *priv)
> break;
>
> case PHY_TYPE_USB3:
> - /* Set SSC downward spread spectrum */
> - val = FIELD_PREP(RK3568_PHYREG32_SSC_MASK, RK3568_PHYREG32_SSC_DOWNWARD);
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> -
> /* Enable adaptive CTLE for USB3.0 Rx */
> val = readl(priv->mmio + RK3568_PHYREG15);
> val |= RK3568_PHYREG15_CTLE_EN;
> @@ -1110,14 +1138,6 @@ static int rk3576_combphy_cfg(struct rockchip_combphy_priv *priv)
> writel(0x88, priv->mmio + RK3568_PHYREG13);
> writel(0x56, priv->mmio + RK3568_PHYREG14);
> } else if (priv->type == PHY_TYPE_SATA) {
> - /* downward spread spectrum +500ppm */
> - val = FIELD_PREP(RK3568_PHYREG32_SSC_DIR_MASK,
> - RK3568_PHYREG32_SSC_DOWNWARD);
> - val |= FIELD_PREP(RK3568_PHYREG32_SSC_OFFSET_MASK,
> - RK3568_PHYREG32_SSC_OFFSET_500PPM);
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val,
> - RK3568_PHYREG32);
> -
> /* ssc ppm adjust to 3500ppm */
> rockchip_combphy_updatel(priv, RK3576_PHYREG10_SSC_PCM_MASK,
> RK3576_PHYREG10_SSC_PCM_3500PPM,
> @@ -1156,39 +1176,7 @@ static int rk3576_combphy_cfg(struct rockchip_combphy_priv *priv)
> }
> }
>
> - if (priv->enable_ssc) {
> - val = readl(priv->mmio + RK3568_PHYREG8);
> - val |= RK3568_PHYREG8_SSC_EN;
> - writel(val, priv->mmio + RK3568_PHYREG8);
> -
> - if (priv->type == PHY_TYPE_PCIE && rate == REF_CLOCK_24MHz) {
> - /* Set PLL loop divider */
> - writel(0x00, priv->mmio + RK3576_PHYREG17);
> - writel(RK3568_PHYREG18_PLL_LOOP, priv->mmio + RK3568_PHYREG18);
> -
> - /* Set up rx_pck invert and rx msb to disable */
> - writel(0x00, priv->mmio + RK3588_PHYREG27);
> -
> - /*
> - * Set up SU adjust signal:
> - * su_trim[7:0], PLL KVCO adjust bits[2:0] to min
> - * su_trim[15:8], PLL LPF R1 adujst bits[9:7]=3'b101
> - * su_trim[23:16], CKRCV adjust
> - * su_trim[31:24], CKDRV adjust
> - */
> - writel(0x90, priv->mmio + RK3568_PHYREG11);
> - writel(0x02, priv->mmio + RK3568_PHYREG12);
> - writel(0x08, priv->mmio + RK3568_PHYREG13);
> - writel(0x57, priv->mmio + RK3568_PHYREG14);
> - writel(0x40, priv->mmio + RK3568_PHYREG15);
> -
> - writel(RK3568_PHYREG16_SSC_CNT_VALUE, priv->mmio + RK3568_PHYREG16);
> -
> - val = FIELD_PREP(RK3568_PHYREG33_PLL_KVCO_MASK,
> - RK3576_PHYREG33_PLL_KVCO_VALUE);
> - writel(val, priv->mmio + RK3568_PHYREG33);
> - }
> - }
> + rk_combphy_common_cfg_ssc(priv, rate);
>
> return 0;
> }
> @@ -1255,10 +1243,6 @@ static int rk3588_combphy_cfg(struct rockchip_combphy_priv *priv)
> }
> break;
> case PHY_TYPE_USB3:
> - /* Set SSC downward spread spectrum */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT;
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val, RK3568_PHYREG32);
> -
> /* Enable adaptive CTLE for USB3.0 Rx. */
> val = readl(priv->mmio + RK3568_PHYREG15);
> val |= RK3568_PHYREG15_CTLE_EN;
> @@ -1343,13 +1327,6 @@ static int rk3588_combphy_cfg(struct rockchip_combphy_priv *priv)
>
> /* Set up su_trim: */
> writel(RK3568_PHYREG11_SU_TRIM_0_7, priv->mmio + RK3568_PHYREG11);
> - } else if (priv->type == PHY_TYPE_SATA) {
> - /* downward spread spectrum +500ppm */
> - val = RK3568_PHYREG32_SSC_DOWNWARD << RK3568_PHYREG32_SSC_DIR_SHIFT;
> - val |= RK3568_PHYREG32_SSC_OFFSET_500PPM <<
> - RK3568_PHYREG32_SSC_OFFSET_SHIFT;
> - rockchip_combphy_updatel(priv, RK3568_PHYREG32_SSC_MASK, val,
> - RK3568_PHYREG32);
> }
> break;
> default:
> @@ -1371,11 +1348,7 @@ static int rk3588_combphy_cfg(struct rockchip_combphy_priv *priv)
> }
> }
>
> - if (priv->enable_ssc) {
> - val = readl(priv->mmio + RK3568_PHYREG8);
> - val |= RK3568_PHYREG8_SSC_EN;
> - writel(val, priv->mmio + RK3568_PHYREG8);
> - }
> + rk_combphy_common_cfg_ssc(priv, rate);
>
> return 0;
> }
> --
> 2.43.0
>
>
> --
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: rockchip: naneng-combphy: Fix TX detect RX termination errata
From: Vinod Koul @ 2026-05-10 11:08 UTC (permalink / raw)
To: Shawn Lin
Cc: linux-rockchip, linux-phy, Heiko Stuebner, Neil Armstrong,
linux-kernel
In-Reply-To: <1774423383-36599-1-git-send-email-shawn.lin@rock-chips.com>
On 25-03-26, 15:23, Shawn Lin wrote:
> Some PHY revisions may fail to detect the peer RX's termination
> resistor (RTERM) under certain critical temperature conditions.
> This causes TX detection failures on PCIe links.
>
> Add a workaround to force the RTERM detection ready signal for
> affected PHY revisions. This ensures reliable TX-to-RX termination
> detection across all operating temperature ranges.
>
> The fix applies to RK3562, RK3568, RK3576 and RK3588 SoCs which share
> the same PHY IP with this hardware errata.
Missing Fixes tag?
>
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
> ---
>
> drivers/phy/rockchip/phy-rockchip-naneng-combphy.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c b/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
> index b60d6bf..76d4994 100644
> --- a/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
> +++ b/drivers/phy/rockchip/phy-rockchip-naneng-combphy.c
> @@ -106,6 +106,9 @@
> #define RK3568_PHYREG18 0x44
> #define RK3568_PHYREG18_PLL_LOOP 0x32
>
> +#define RK3568_PHYREG26 0x64
> +#define RK3568_PHYREG26_FORCE_RTERM_DET_RDY BIT(5)
> +
> #define RK3568_PHYREG30 0x74
> #define RK3568_PHYREG30_GATE_TX_PCK_SEL BIT(7)
> #define RK3568_PHYREG30_GATE_TX_PCK_DLY_PLL_OFF BIT(7)
> @@ -193,6 +196,7 @@ struct rockchip_combphy_cfg {
> unsigned int num_phys;
> unsigned int phy_ids[3];
> const struct rockchip_combphy_grfcfg *grfcfg;
> + bool force_rxterm_det_rdy;
> int (*combphy_cfg)(struct rockchip_combphy_priv *priv);
> };
>
> @@ -264,6 +268,17 @@ static int rockchip_combphy_init(struct phy *phy)
>
> switch (priv->type) {
> case PHY_TYPE_PCIE:
> + /*
> + * Hardware Errata: TX fails to detect peer RX termination.
Is there an errata number or links which people can refer to?
> + * Some PHY revisions may fail to detect remote RX's RTERM
> + * (receiver termination resistor) under certain critical
> + * temperature conditions. Set force rterm detect ready to
> + * fix it.
> + */
> + if (priv->cfg->force_rxterm_det_rdy)
> + rockchip_combphy_updatel(priv, RK3568_PHYREG26_FORCE_RTERM_DET_RDY,
> + RK3568_PHYREG26_FORCE_RTERM_DET_RDY, RK3568_PHYREG26);
> + fallthrough;
> case PHY_TYPE_USB3:
> case PHY_TYPE_SATA:
> case PHY_TYPE_SGMII:
> @@ -745,6 +760,7 @@ static const struct rockchip_combphy_cfg rk3562_combphy_cfgs = {
> },
> .grfcfg = &rk3562_combphy_grfcfgs,
> .combphy_cfg = rk3562_combphy_cfg,
> + .force_rxterm_det_rdy = true,
> };
>
> static int rk3568_combphy_cfg(struct rockchip_combphy_priv *priv)
> @@ -962,6 +978,7 @@ static const struct rockchip_combphy_cfg rk3568_combphy_cfgs = {
> },
> .grfcfg = &rk3568_combphy_grfcfgs,
> .combphy_cfg = rk3568_combphy_cfg,
> + .force_rxterm_det_rdy = true,
> };
>
> static int rk3576_combphy_cfg(struct rockchip_combphy_priv *priv)
> @@ -1231,6 +1248,7 @@ static const struct rockchip_combphy_cfg rk3576_combphy_cfgs = {
> },
> .grfcfg = &rk3576_combphy_grfcfgs,
> .combphy_cfg = rk3576_combphy_cfg,
> + .force_rxterm_det_rdy = true,
> };
>
> static int rk3588_combphy_cfg(struct rockchip_combphy_priv *priv)
> @@ -1418,6 +1436,7 @@ static const struct rockchip_combphy_cfg rk3588_combphy_cfgs = {
> },
> .grfcfg = &rk3588_combphy_grfcfgs,
> .combphy_cfg = rk3588_combphy_cfg,
> + .force_rxterm_det_rdy = true,
> };
>
> static const struct of_device_id rockchip_combphy_of_match[] = {
> --
> 2.7.4
>
>
> --
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy
--
~Vinod
--
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] phy: econet: Add PCIe PHY driver for EcoNet EN751221 and EN7528 SoCs.
From: Vinod Koul @ 2026-05-10 11:16 UTC (permalink / raw)
To: Caleb James DeLisle
Cc: linux-phy, naseefkm, neil.armstrong, robh, krzk+dt, conor+dt,
linux-mips, devicetree, linux-kernel
In-Reply-To: <20260404184918.2184070-3-cjd@cjdns.fr>
On 04-04-26, 18:49, Caleb James DeLisle wrote:
> Introduce support for EcoNet PCIe PHY controllers found in EN751221
> and EN7528 SoCs, these SoCs are not identical but are similar, each
> having one Gen1 port, and one Gen1/Gen2 port.
>
> Co-developed-by: Ahmed Naseef <naseefkm@gmail.com>
> Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
> [cjd@cjdns.fr: add EN751221 support and refactor for clarity]
> Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
> ---
> MAINTAINERS | 1 +
> drivers/phy/Kconfig | 12 +++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-econet-pcie.c | 180 ++++++++++++++++++++++++++++++++++
> 4 files changed, 194 insertions(+)
> create mode 100644 drivers/phy/phy-econet-pcie.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1b016212e4cb..b2d37c7c80af 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9177,6 +9177,7 @@ M: Caleb James DeLisle <cjd@cjdns.fr>
> L: linux-mips@vger.kernel.org
> S: Maintained
> F: Documentation/devicetree/bindings/phy/econet,en751221-pcie-phy.yaml
> +F: drivers/phy/phy-econet-pcie.c
>
> ECRYPT FILE SYSTEM
> M: Tyler Hicks <code@tyhicks.com>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 227b9a4c612e..9aad68829d72 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -66,6 +66,18 @@ config PHY_CAN_TRANSCEIVER
> functional modes using gpios and sets the attribute max link
> rate, for CAN drivers.
>
> +config PHY_ECONET_PCIE
> + tristate "EcoNet PCIe-PHY Driver"
> + depends on ECONET || COMPILE_TEST
> + depends on OF
> + select GENERIC_PHY
> + select REGMAP_MMIO
> + help
> + Say Y here to add support for EcoNet PCIe PHY driver.
> + This driver create the basic PHY instance and provides initialize
> + callback for PCIe GEN1 and GEN2 ports. This PHY is found on
> + EcoNet SoCs including EN751221 and EN7528.
> +
> config PHY_GOOGLE_USB
> tristate "Google Tensor SoC USB PHY driver"
> select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index f49d83f00a3d..42959ed383fd 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_GENERIC_PHY) += phy-core.o
> obj-$(CONFIG_GENERIC_PHY_MIPI_DPHY) += phy-core-mipi-dphy.o
> obj-$(CONFIG_PHY_AIROHA_PCIE) += phy-airoha-pcie.o
> obj-$(CONFIG_PHY_CAN_TRANSCEIVER) += phy-can-transceiver.o
> +obj-$(CONFIG_PHY_ECONET_PCIE) += phy-econet-pcie.o
> obj-$(CONFIG_PHY_GOOGLE_USB) += phy-google-usb.o
> obj-$(CONFIG_USB_LGM_PHY) += phy-lgm-usb.o
> obj-$(CONFIG_PHY_LPC18XX_USB_OTG) += phy-lpc18xx-usb-otg.o
> diff --git a/drivers/phy/phy-econet-pcie.c b/drivers/phy/phy-econet-pcie.c
> new file mode 100644
> index 000000000000..d2c6e0c1f331
> --- /dev/null
> +++ b/drivers/phy/phy-econet-pcie.c
> @@ -0,0 +1,180 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Author: Caleb James DeLisle <cjd@cjdns.fr>
> + * Ahmed Naseef <naseefkm@gmail.com>
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +
> +/* Rx detection timing for EN751221: 16*8 clock cycles */
> +#define EN751221_RXDET_VAL 16
> +
> +/* Rx detection timing when in power mode 3 */
> +#define EN75_RXDET_P3_REG 0xa28
> +#define EN75_RXDET_P3_MASK GENMASK(17, 9)
> +
> +/* Rx detection timing when in power mode 2 */
> +#define EN75_RXDET_P2_REG 0xa2c
> +#define EN75_RXDET_P2_MASK GENMASK(8, 0)
> +
> +/* Rx impedance */
> +#define EN75_RX_IMPEDANCE_REG 0xb2c
> +#define EN75_RX_IMPEDANCE_MASK GENMASK(13, 12)
> +enum en75_rx_impedance {
> + EN75_RX_IMPEDANCE_100_OHM = 0,
> + EN75_RX_IMPEDANCE_95_OHM = 1,
> + EN75_RX_IMPEDANCE_90_OHM = 2,
> +};
> +
> +/* PLL Invert clock */
> +#define EN75_PLL_PH_INV_REG 0x4a0
> +#define EN75_PLL_PH_INV_MASK BIT(5)
> +
> +struct en75_phy_op {
> + u32 reg;
> + u32 mask;
> + u32 val;
> +};
> +
> +struct en7528_pcie_phy {
> + struct regmap *regmap;
> + const struct en75_phy_op *data;
> +};
> +
> +/* Port 0 PHY: set LCDDS_CLK_PH_INV for PLL operation */
> +static const struct en75_phy_op en7528_phy_gen1[] = {
> + {
> + .reg = EN75_PLL_PH_INV_REG,
> + .mask = EN75_PLL_PH_INV_MASK,
> + .val = 1,
> + },
> + { /* sentinel */ }
> +};
> +
> +/* EN7528 Port 1 PHY: Rx impedance tuning, target R -5 Ohm */
> +static const struct en75_phy_op en7528_phy_gen2[] = {
> + {
> + .reg = EN75_RX_IMPEDANCE_REG,
> + .mask = EN75_RX_IMPEDANCE_MASK,
> + .val = EN75_RX_IMPEDANCE_95_OHM,
> + },
> + { /* sentinel */ }
> +};
> +
> +/* EN751221 Port 1 PHY, set RX detect to 16*8 clock cycles */
> +static const struct en75_phy_op en751221_phy_gen2[] = {
> + {
> + .reg = EN75_RXDET_P3_REG,
> + .mask = EN75_RXDET_P3_MASK,
> + .val = EN751221_RXDET_VAL,
> + },
> + {
> + .reg = EN75_RXDET_P2_REG,
> + .mask = EN75_RXDET_P2_MASK,
> + .val = EN751221_RXDET_VAL,
> + },
> + { /* sentinel */ }
> +};
> +
> +static int en75_pcie_phy_init(struct phy *phy)
> +{
> + struct en7528_pcie_phy *ephy = phy_get_drvdata(phy);
> + const struct en75_phy_op *data = ephy->data;
> + int i, ret;
> + u32 val;
> +
> + for (i = 0; data[i].mask || data[i].val; i++) {
> + if (i)
> + usleep_range(1000, 2000);
> +
> + val = field_prep(data[i].mask, data[i].val);
Please see:
https://sashiko.dev/#/patchset/20260425173642.406089-1-cjd%40cjdns.fr
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 0/4] drm/msm/hdmi & phy: use generic PHY framework
From: Vinod Koul @ 2026-05-10 11:23 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Neil Armstrong, linux-kernel, linux-arm-msm, dri-devel, freedreno,
linux-phy, Dmitry Baryshkov, Konrad Dybcio, Konrad Dybcio
In-Reply-To: <20260401-fd-hdmi-phy-v8-0-51b0e98edf6c@oss.qualcomm.com>
On 01-04-26, 06:38, Dmitry Baryshkov wrote:
> The MSM HDMI PHYs have been using the ad-hoc approach / API instead of
> using the generic API framework. Move MSM HDMI PHY drivers to
> drivers/phy/qualcomm and rework them to use generic PHY framework. This
> way all the QMP-related code is kept at the same place.
> Also MSM8974 HDMI PHY, 28nm DSI PHY and apq8964 SATA PHY now can use
> common helpers for the UNI PLL.
>
> This also causes some design changes. Currently on MSM8996 the HDMI PLL
> implements clock's set_rate(), while other HDMI PHY drivers used the
> ad-hoc PHY API for setting the PLL rate (this includes in-tree MSM8960
> driver and posted, but not merged, MSM8974 driver). This might result in
> the PLL being set to one rate, while the rest of the PHY being tuned to
> work at another rate. Adopt the latter idea and always use
> phy_configure() to tune the PHY and set the PLL rate.
Hi Dimitry,
Can you please check
https://sashiko.dev/#/patchset/20260401-fd-hdmi-phy-v8-0-51b0e98edf6c%40oss.qualcomm.com
>
> Merge strategy: Merge the first patch (either through drm/msm or through
> the PHY tree), merge the rest of the patches in the next cycle.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> Changes in v8:
> - Rebased on linux-next, fixing conflicts
> - Added missing ids for APQ8084 and MSM8998 (Sashiko)
> - Switched to pm_runtime_put() (Sashiko)
> - Fixed several missed *1000 after pixclk -> tmds_char_rate conversion
> (Sashiko)
> - Fixed several math overflows (Sashiko)
> - Link to v7: https://patch.msgid.link/20260324-fd-hdmi-phy-v7-0-b41dde8d83b8@oss.qualcomm.com
>
> Changes in v7:
> - Fixed the build issue between msm8974 patches.
> - Dropped even more writel / readl wrappers (now from QMP PHYs)
> - Link to v6: https://lore.kernel.org/r/20260319-fd-hdmi-phy-v6-0-cefc08a55470@oss.qualcomm.com
>
> Changes in v6:
> - Changed MSM8974 HDMI PHY driver to use FIELD_PREP / FIELD_GET (Konrad)
> - Fixed rate recalculation for MSM8974 HDMI PHY (Konrad)
> - Dropped register read/write wrappers
> - Link to v5: https://lore.kernel.org/r/20260314-fd-hdmi-phy-v5-0-58122ae96d3b@oss.qualcomm.com
>
> Changes in v5:
> - Kept only a single place which handles extp clk (after PHY power on,
> before PHY power off) (Neil)
> - Inlined pm_runtime calls in the HDMI TX driver, replaced
> pm_runtime_resume_and_get() with pm_runtime_get_sync(), since
> atomic_pre_enable() can not fail.
> - Renamed registers defines to drop the REG_ prefix.
> - Link to v4: https://lore.kernel.org/r/20250520-fd-hdmi-phy-v4-0-fcbaa652ad75@oss.qualcomm.com
>
> Changes in v3-v4:
> - Rebased on top of linux-next, solving conflicts
> - Squashed add-and-remove patches into a single git mv patch
> - Dropped HDMI PHY header patch (merged upstream)
>
> Changes in v2:
> - Changed msm8960 / apq8064 to calculate register data instead of using
> fixed tables. This extends the list of supported modes.
> (Implementation is based on mdss-hdmi-pll-28lpm.c from msm-4.14).
>
> - Fixed the reprogramming of PLL rate on apq8064.
>
> - Merged all non-QMP HDMI PHY drivers into a common PHY_QCOM_HDMI
> driver (suggested by Rob Clark)
>
> ---
> Dmitry Baryshkov (4):
> drm/msm/hdmi: switch to generic PHY subsystem
> phy: qcom: apq8064-sata: extract UNI PLL register defines
> phy: qcom-uniphy: add more registers from display PHYs
> phy: qualcomm: add MSM8974 HDMI PHY support
>
> drivers/gpu/drm/msm/Makefile | 7 -
> drivers/gpu/drm/msm/hdmi/hdmi.c | 59 +-
> drivers/gpu/drm/msm/hdmi/hdmi.h | 80 +--
> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 80 ++-
> drivers/gpu/drm/msm/hdmi/hdmi_phy.c | 226 -------
> drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c | 51 --
> drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c | 761 ----------------------
> drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c | 765 -----------------------
> drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c | 141 -----
> drivers/gpu/drm/msm/hdmi/hdmi_phy_8x74.c | 44 --
> drivers/gpu/drm/msm/hdmi/hdmi_pll_8960.c | 460 --------------
> drivers/gpu/drm/msm/registers/display/hdmi.xml | 537 ----------------
> drivers/phy/qualcomm/Kconfig | 24 +
> drivers/phy/qualcomm/Makefile | 14 +
> drivers/phy/qualcomm/phy-qcom-apq8064-sata.c | 23 +-
> drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c | 353 +++++++++++
> drivers/phy/qualcomm/phy-qcom-hdmi-28lpm.c | 478 ++++++++++++++
> drivers/phy/qualcomm/phy-qcom-hdmi-45nm.c | 186 ++++++
> drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.c | 213 +++++++
> drivers/phy/qualcomm/phy-qcom-hdmi-preqmp.h | 59 ++
> drivers/phy/qualcomm/phy-qcom-qmp-hdmi-base.c | 187 ++++++
> drivers/phy/qualcomm/phy-qcom-qmp-hdmi-msm8996.c | 440 +++++++++++++
> drivers/phy/qualcomm/phy-qcom-qmp-hdmi-msm8998.c | 489 +++++++++++++++
> drivers/phy/qualcomm/phy-qcom-qmp-hdmi.h | 49 ++
> drivers/phy/qualcomm/phy-qcom-uniphy.h | 74 +++
> 25 files changed, 2611 insertions(+), 3189 deletions(-)
> ---
> base-commit: d894dddf2a144f0e1d1cd7a8225c744dc906cdd5
> change-id: 20240109-fd-hdmi-phy-44b8319fbcc7
>
> Best regards,
> --
> With best wishes
> Dmitry
--
~Vinod
--
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] phy: econet: Add PCIe PHY driver for EcoNet EN751221 and EN7528 SoCs.
From: Caleb James DeLisle @ 2026-05-10 11:25 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-phy, naseefkm, neil.armstrong, robh, krzk+dt, conor+dt,
linux-mips, devicetree, linux-kernel
In-Reply-To: <agBpBxofP00bAt7V@vaman>
On 10/05/2026 13:16, Vinod Koul wrote:
> On 04-04-26, 18:49, Caleb James DeLisle wrote:
>> Introduce support for EcoNet PCIe PHY controllers found in EN751221
>> and EN7528 SoCs, these SoCs are not identical but are similar, each
>> having one Gen1 port, and one Gen1/Gen2 port.
>>
>> Co-developed-by: Ahmed Naseef <naseefkm@gmail.com>
>> Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
>> [cjd@cjdns.fr: add EN751221 support and refactor for clarity]
>> Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
>> ---
>> MAINTAINERS | 1 +
>> drivers/phy/Kconfig | 12 +++
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-econet-pcie.c | 180 ++++++++++++++++++++++++++++++++++
>> 4 files changed, 194 insertions(+)
>> create mode 100644 drivers/phy/phy-econet-pcie.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 1b016212e4cb..b2d37c7c80af 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -9177,6 +9177,7 @@ M: Caleb James DeLisle <cjd@cjdns.fr>
>> L: linux-mips@vger.kernel.org
>> S: Maintained
>> F: Documentation/devicetree/bindings/phy/econet,en751221-pcie-phy.yaml
>> +F: drivers/phy/phy-econet-pcie.c
>>
>> ECRYPT FILE SYSTEM
>> M: Tyler Hicks <code@tyhicks.com>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 227b9a4c612e..9aad68829d72 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -66,6 +66,18 @@ config PHY_CAN_TRANSCEIVER
>> functional modes using gpios and sets the attribute max link
>> rate, for CAN drivers.
>>
>> +config PHY_ECONET_PCIE
>> + tristate "EcoNet PCIe-PHY Driver"
>> + depends on ECONET || COMPILE_TEST
>> + depends on OF
>> + select GENERIC_PHY
>> + select REGMAP_MMIO
>> + help
>> + Say Y here to add support for EcoNet PCIe PHY driver.
>> + This driver create the basic PHY instance and provides initialize
>> + callback for PCIe GEN1 and GEN2 ports. This PHY is found on
>> + EcoNet SoCs including EN751221 and EN7528.
>> +
>> config PHY_GOOGLE_USB
>> tristate "Google Tensor SoC USB PHY driver"
>> select GENERIC_PHY
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index f49d83f00a3d..42959ed383fd 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -9,6 +9,7 @@ obj-$(CONFIG_GENERIC_PHY) += phy-core.o
>> obj-$(CONFIG_GENERIC_PHY_MIPI_DPHY) += phy-core-mipi-dphy.o
>> obj-$(CONFIG_PHY_AIROHA_PCIE) += phy-airoha-pcie.o
>> obj-$(CONFIG_PHY_CAN_TRANSCEIVER) += phy-can-transceiver.o
>> +obj-$(CONFIG_PHY_ECONET_PCIE) += phy-econet-pcie.o
>> obj-$(CONFIG_PHY_GOOGLE_USB) += phy-google-usb.o
>> obj-$(CONFIG_USB_LGM_PHY) += phy-lgm-usb.o
>> obj-$(CONFIG_PHY_LPC18XX_USB_OTG) += phy-lpc18xx-usb-otg.o
>> diff --git a/drivers/phy/phy-econet-pcie.c b/drivers/phy/phy-econet-pcie.c
>> new file mode 100644
>> index 000000000000..d2c6e0c1f331
>> --- /dev/null
>> +++ b/drivers/phy/phy-econet-pcie.c
>> @@ -0,0 +1,180 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Author: Caleb James DeLisle <cjd@cjdns.fr>
>> + * Ahmed Naseef <naseefkm@gmail.com>
>> + */
>> +
>> +#include <linux/bitfield.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/phy/phy.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/regmap.h>
>> +
>> +/* Rx detection timing for EN751221: 16*8 clock cycles */
>> +#define EN751221_RXDET_VAL 16
>> +
>> +/* Rx detection timing when in power mode 3 */
>> +#define EN75_RXDET_P3_REG 0xa28
>> +#define EN75_RXDET_P3_MASK GENMASK(17, 9)
>> +
>> +/* Rx detection timing when in power mode 2 */
>> +#define EN75_RXDET_P2_REG 0xa2c
>> +#define EN75_RXDET_P2_MASK GENMASK(8, 0)
>> +
>> +/* Rx impedance */
>> +#define EN75_RX_IMPEDANCE_REG 0xb2c
>> +#define EN75_RX_IMPEDANCE_MASK GENMASK(13, 12)
>> +enum en75_rx_impedance {
>> + EN75_RX_IMPEDANCE_100_OHM = 0,
>> + EN75_RX_IMPEDANCE_95_OHM = 1,
>> + EN75_RX_IMPEDANCE_90_OHM = 2,
>> +};
>> +
>> +/* PLL Invert clock */
>> +#define EN75_PLL_PH_INV_REG 0x4a0
>> +#define EN75_PLL_PH_INV_MASK BIT(5)
>> +
>> +struct en75_phy_op {
>> + u32 reg;
>> + u32 mask;
>> + u32 val;
>> +};
>> +
>> +struct en7528_pcie_phy {
>> + struct regmap *regmap;
>> + const struct en75_phy_op *data;
>> +};
>> +
>> +/* Port 0 PHY: set LCDDS_CLK_PH_INV for PLL operation */
>> +static const struct en75_phy_op en7528_phy_gen1[] = {
>> + {
>> + .reg = EN75_PLL_PH_INV_REG,
>> + .mask = EN75_PLL_PH_INV_MASK,
>> + .val = 1,
>> + },
>> + { /* sentinel */ }
>> +};
>> +
>> +/* EN7528 Port 1 PHY: Rx impedance tuning, target R -5 Ohm */
>> +static const struct en75_phy_op en7528_phy_gen2[] = {
>> + {
>> + .reg = EN75_RX_IMPEDANCE_REG,
>> + .mask = EN75_RX_IMPEDANCE_MASK,
>> + .val = EN75_RX_IMPEDANCE_95_OHM,
>> + },
>> + { /* sentinel */ }
>> +};
>> +
>> +/* EN751221 Port 1 PHY, set RX detect to 16*8 clock cycles */
>> +static const struct en75_phy_op en751221_phy_gen2[] = {
>> + {
>> + .reg = EN75_RXDET_P3_REG,
>> + .mask = EN75_RXDET_P3_MASK,
>> + .val = EN751221_RXDET_VAL,
>> + },
>> + {
>> + .reg = EN75_RXDET_P2_REG,
>> + .mask = EN75_RXDET_P2_MASK,
>> + .val = EN751221_RXDET_VAL,
>> + },
>> + { /* sentinel */ }
>> +};
>> +
>> +static int en75_pcie_phy_init(struct phy *phy)
>> +{
>> + struct en7528_pcie_phy *ephy = phy_get_drvdata(phy);
>> + const struct en75_phy_op *data = ephy->data;
>> + int i, ret;
>> + u32 val;
>> +
>> + for (i = 0; data[i].mask || data[i].val; i++) {
>> + if (i)
>> + usleep_range(1000, 2000);
>> +
>> + val = field_prep(data[i].mask, data[i].val);
> Please see:
>
> https://sashiko.dev/#/patchset/20260425173642.406089-1-cjd%40cjdns.fr
I think this is an error in that the AI is not correctly differentiating
between field_prep() which accepts a non-constant mask, and FIELD_PREP()
which does not. In any case I can confirm that it does compile and work
correctly on the device.
On another note, I think you may be the creator of Sashiko, if so, thank
you for your work - it helped me with another patch already.
Thanks,
Caleb
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 02/10] phy: core: switch to using class_find_device_by_fwnode()
From: Vinod Koul @ 2026-05-10 11:26 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Neil Armstrong, Mark Brown, Liam Girdwood, Lee Jones,
Pavel Machek, Peter Rosin, Andrew Lunn, Heiner Kallweit,
Russell King, Moritz Fischer, Xu Yilun, Tom Rix,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich, netdev,
linux-kernel, linux-phy, linux-spi, linux-leds, linux-fpga,
driver-core
In-Reply-To: <20260322-remove-device-find-by-of-node-v1-2-b72eb22a1215@gmail.com>
On 22-03-26, 18:54, Dmitry Torokhov wrote:
> In preparation to class_find_device_by_of_node() going away switch to
> using class_find_device_by_fwnode().
Acked-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH V2 RESEND 2/2] phy: mediatek: xsphy: add support to set disconnect threshold
From: Vinod Koul @ 2026-05-10 11:50 UTC (permalink / raw)
To: Chunfeng Yun
Cc: AngeloGioacchino Del Regno, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
linux-arm-kernel, linux-mediatek, linux-phy, devicetree,
linux-kernel
In-Reply-To: <20260413122836.4848-2-chunfeng.yun@mediatek.com>
On 13-04-26, 20:28, Chunfeng Yun wrote:
> Add a property to tune usb2 phy's disconnect threshold.
>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> v2: change property name
> ---
> drivers/phy/mediatek/phy-mtk-xsphy.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/phy/mediatek/phy-mtk-xsphy.c b/drivers/phy/mediatek/phy-mtk-xsphy.c
> index c0ddb9273cc3..46345e4f4189 100644
> --- a/drivers/phy/mediatek/phy-mtk-xsphy.c
> +++ b/drivers/phy/mediatek/phy-mtk-xsphy.c
> @@ -61,6 +61,7 @@
> #define XSP_USBPHYACR6 ((SSUSB_SIFSLV_U2PHY_COM) + 0x018)
> #define P2A6_RG_BC11_SW_EN BIT(23)
> #define P2A6_RG_OTG_VBUSCMP_EN BIT(20)
> +#define PA6_RG_U2_DISCTH GENMASK(7, 4)
>
> #define XSP_U2PHYDTM1 ((SSUSB_SIFSLV_U2PHY_COM) + 0x06C)
> #define P2D_FORCE_IDDIG BIT(9)
> @@ -107,6 +108,7 @@ struct xsphy_instance {
> int eye_src;
> int eye_vrt;
> int eye_term;
> + int discth;
Please see
https://sashiko.dev/#/patchset/20260413122836.4848-1-chunfeng.yun%40mediatek.com
> };
>
> struct mtk_xsphy {
> @@ -256,9 +258,12 @@ static void phy_parse_property(struct mtk_xsphy *xsphy,
> &inst->eye_vrt);
> device_property_read_u32(dev, "mediatek,eye-term",
> &inst->eye_term);
> - dev_dbg(dev, "intr:%d, src:%d, vrt:%d, term:%d\n",
> + device_property_read_u32(dev, "mediatek,discth",
> + &inst->discth);
> + dev_dbg(dev, "intr:%d, src:%d, vrt:%d, term:%d, discth:%d\n",
> inst->efuse_intr, inst->eye_src,
> - inst->eye_vrt, inst->eye_term);
> + inst->eye_vrt, inst->eye_term,
> + inst->discth);
> break;
> case PHY_TYPE_USB3:
> device_property_read_u32(dev, "mediatek,efuse-intr",
> @@ -301,6 +306,9 @@ static void u2_phy_props_set(struct mtk_xsphy *xsphy,
> if (inst->eye_term)
> mtk_phy_update_field(pbase + XSP_USBPHYACR1, P2A1_RG_TERM_SEL,
> inst->eye_term);
> + if (inst->discth)
> + mtk_phy_update_field(pbase + XSP_USBPHYACR6, PA6_RG_U2_DISCTH,
> + inst->discth);
> }
>
> static void u3_phy_props_set(struct mtk_xsphy *xsphy,
> --
> 2.45.2
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy: Add Eliza QMP PHY
From: Vinod Koul @ 2026-05-10 12:06 UTC (permalink / raw)
To: Abel Vesa
Cc: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260318-eliza-bindings-qmp-phy-v1-1-96a0d529ad2d@oss.qualcomm.com>
On 18-03-26, 11:54, Abel Vesa wrote:
> Document the compatible for the USB QMP PHY found on the Qualcomm Eliza
> SoC.
>
> It is fully compatible with the one found on Qualcomm SM8650, so add it
> with the SM8650 as fallback.
Can you please rebase this on phy/next
>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
> .../devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> index 3d537b7f9985..4eff92343ce4 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> @@ -16,6 +16,10 @@ description:
> properties:
> compatible:
> oneOf:
> + - items:
> + - enum:
> + - qcom,eliza-qmp-usb3-dp-phy
> + - const: qcom,sm8650-qmp-usb3-dp-phy
> - items:
> - enum:
> - qcom,kaanapali-qmp-usb3-dp-phy
>
> ---
> base-commit: 8e5a478b6d6a5bb0a3d52147862b15e4d826af19
> change-id: 20260318-eliza-bindings-qmp-phy-c53be4b0b131
>
> Best regards,
> --
> Abel Vesa <abel.vesa@oss.qualcomm.com>
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy-fixes] phy: marvell: mvebu-a3700-utmi: fix incorrect USB2_PHY_CTRL register access
From: Vinod Koul @ 2026-05-10 12:23 UTC (permalink / raw)
To: Miquel Raynal, Neil Armstrong, Igal Liberman,
Kishon Vijay Abraham I, Gabor Juhos
Cc: linux-phy, linux-kernel
In-Reply-To: <20260321-a3700-utmi-fix-usb2_phy_ctrl-access-v1-1-6005ff4b5058@gmail.com>
On Sat, 21 Mar 2026 15:42:32 +0100, Gabor Juhos wrote:
> The mvebu_a3700_utmi_phy_power_off() function tries to modify the
> USB2_PHY_CTRL register by using the IO address of the PHY IP block along
> with the readl/writel IO accessors. However, the register exist in the
> USB miscellaneous register space, and as such it must be accessed via
> regmap like it is done in the mvebu_a3700_utmi_phy_power_on() function.
>
> Change the code to use regmap_update_bits() for modífying the register
> to fix this.
>
> [...]
Applied, thanks!
[1/1] phy: marvell: mvebu-a3700-utmi: fix incorrect USB2_PHY_CTRL register access
commit: 91ddf6f722084383fb05be731c0107814b055c0c
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] phy: tegra: xusb: Fix per-pad high-speed termination calibration
From: Vinod Koul @ 2026-05-10 12:23 UTC (permalink / raw)
To: Jonathan Hunter, JC Kuo, Neil Armstrong, Thierry Reding,
Wei-Cheng Chen
Cc: Wayne Chang, WK Tsai, linux-phy, linux-tegra, linux-kernel
In-Reply-To: <20260504033305.2283145-1-weichengc@nvidia.com>
On Mon, 04 May 2026 11:33:05 +0800, Wei-Cheng Chen wrote:
> The existing code reads a single hs_term_range_adj value from bit field
> [10:7] of FUSE_SKU_CALIB_0 and applies it to all USB2 pads uniformly.
> However, on SoCs that support per-pad termination, each pad has its own
> hs_term_range_adj field: pad 0 in FUSE_SKU_CALIB_0[10:7], and pads 1-3
> in FUSE_USB_CALIB_EXT_0 at bit offsets [8:5], [12:9], and [16:13]
> respectively.
>
> [...]
Applied, thanks!
[1/1] phy: tegra: xusb: Fix per-pad high-speed termination calibration
commit: da110228b54f2e2143d97ea7151e0dc22e539d67
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] phy: exynos5-usbdrd: fix USB 2.0 HS PHY tuning values for Exynos7870
From: Vinod Koul @ 2026-05-10 12:23 UTC (permalink / raw)
To: Łukasz Lebiedziński
Cc: neil.armstrong, krzk, alim.akhtar, andre.draszik, pritam.sutar,
kauschluss, johan, ivo.ivanov.ivanov1, linux-phy,
linux-arm-kernel, linux-samsung-soc, linux-kernel, stable,
Krzysztof Kozlowski
In-Reply-To: <20260406135627.234835-1-kernel@lvkasz.us>
On Mon, 06 Apr 2026 15:56:27 +0200, Łukasz Lebiedziński wrote:
> The existing PHYPARAM0 tuning values for Exynos7870 are incorrect,
> causing the USB 2.0 PHY to fail high-speed negotiation and fall back
> to full-speed (12Mbps) operation.
>
> Fix TXVREFTUNE (transmitter voltage reference) from 14 to 3,
> TXRESTUNE (transmitter impedance) from 3 to 2, and SQRXTUNE
> (squelch threshold) from 6 to 5. Also explicitly set
> TXPREEMPPULSETUNE to 0, which was previously missing from the
> tuning table despite being included in the register mask.
>
> [...]
Applied, thanks!
[1/1] phy: exynos5-usbdrd: fix USB 2.0 HS PHY tuning values for Exynos7870
commit: 5a759b120e31aa3ed914d98b51eb1755235250f2
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: qcom-qmp-ufs: Fix kaanapali PHY PLL lock failure after SM8650 G4 fix
From: Vinod Koul @ 2026-05-10 12:23 UTC (permalink / raw)
To: neil.armstrong, konrad.dybcio, dmitry.baryshkov, mani, abel.vesa,
Nitin Rawat
Cc: linux-arm-msm, linux-phy, linux-kernel, stable
In-Reply-To: <20260415104851.2763238-1-nitin.rawat@oss.qualcomm.com>
On Wed, 15 Apr 2026 16:18:51 +0530, Nitin Rawat wrote:
> Commit 81af9e40e2e4 ("phy: qcom: qmp-ufs: Fix SM8650 PCS table for Gear 4")
> moved QPHY_V6_PCS_UFS_PLL_CNTL register configuration from the shared
> sm8650_ufsphy_g5_pcs table to the SM8650-specific sm8650_ufsphy_pcs base
> table to fix Gear 4 operation on SM8650.
>
> However, this change inadvertently broke kaanapali and SM8750 SoCs
> which also rely on the shared sm8650_ufsphy_g5_pcs table for Gear 5
> configuration but use their own sm8750_ufsphy_pcs base table. After the
> change, kaanapali PHYs are left without the required PLL_CNTL = 0x33
> setting, causing the PHY PLL to remain at its hardware reset default
> value, preventing PLL lock and resulting in DME_LINKSTARTUP timeouts.
>
> [...]
Applied, thanks!
[1/1] phy: qcom-qmp-ufs: Fix kaanapali PHY PLL lock failure after SM8650 G4 fix
commit: 80305760d7a55b884fb9023c490b75568d1ea0b1
Best regards,
--
~Vinod
--
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