* [PATCH v7 3/4] phy: qcom-uniphy: add more registers from display PHYs
From: Dmitry Baryshkov @ 2026-03-23 22:56 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Vinod Koul, Neil Armstrong
Cc: linux-kernel, linux-arm-msm, dri-devel, freedreno, linux-phy,
Dmitry Baryshkov
In-Reply-To: <20260324-fd-hdmi-phy-v7-0-b41dde8d83b8@oss.qualcomm.com>
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Import register definitions from 28nm DSI and HDMI PHYs, adding more UNI
PHY registers.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-uniphy.h | 42 ++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-uniphy.h b/drivers/phy/qualcomm/phy-qcom-uniphy.h
index e5b79a4dc270..ba9d14aae682 100644
--- a/drivers/phy/qualcomm/phy-qcom-uniphy.h
+++ b/drivers/phy/qualcomm/phy-qcom-uniphy.h
@@ -8,10 +8,30 @@
/* PHY registers */
#define UNIPHY_PLL_REFCLK_CFG 0x000
+#define UNIPHY_PLL_REFCLK_DBLR BIT(0)
+#define UNIPHY_PLL_REFCLK_DIV GENMASK(3, 2)
+
+#define UNIPHY_PLL_POSTDIV1_CFG 0x004
+#define UNIPHY_PLL_CHGPUMP_CFG 0x008
+#define UNIPHY_PLL_VCOLPF_CFG 0x00c
+#define UNIPHY_PLL_VREG_CFG 0x010
#define UNIPHY_PLL_PWRGEN_CFG 0x014
+#define UNIPHY_PLL_DMUX_CFG 0x018
+#define UNIPHY_PLL_AMUX_CFG 0x01c
#define UNIPHY_PLL_GLB_CFG 0x020
+#define UNIPHY_PLL_POSTDIV2_CFG 0x024
+#define UNIPHY_PLL_POSTDIV3_CFG 0x028
+#define UNIPHY_PLL_LPFR_CFG 0x02c
+#define UNIPHY_PLL_LPFC1_CFG 0x030
+#define UNIPHY_PLL_LPFC2_CFG 0x034
#define UNIPHY_PLL_SDM_CFG0 0x038
+#define UNIPHY_PLL_SDM_BYP BIT(6)
+#define UNIPHY_PLL_SDM_BYP_DIV GENMASK(5, 0)
+
#define UNIPHY_PLL_SDM_CFG1 0x03c
+#define UNIPHY_PLL_SDM_DITHER_EN BIT(6)
+#define UNIPHY_PLL_SDM_DC_OFFSET GENMASK(5, 0)
+
#define UNIPHY_PLL_SDM_CFG2 0x040
#define UNIPHY_PLL_SDM_CFG3 0x044
#define UNIPHY_PLL_SDM_CFG4 0x048
@@ -22,11 +42,33 @@
#define UNIPHY_PLL_LKDET_CFG0 0x05c
#define UNIPHY_PLL_LKDET_CFG1 0x060
#define UNIPHY_PLL_LKDET_CFG2 0x064
+#define UNIPHY_PLL_TEST_CFG 0x068
#define UNIPHY_PLL_CAL_CFG0 0x06c
+#define UNIPHY_PLL_CAL_CFG1 0x070
+#define UNIPHY_PLL_CAL_CFG2 0x074
+#define UNIPHY_PLL_CAL_CFG3 0x078
+#define UNIPHY_PLL_CAL_CFG4 0x07c
+#define UNIPHY_PLL_CAL_CFG5 0x080
+#define UNIPHY_PLL_CAL_CFG6 0x084
+#define UNIPHY_PLL_CAL_CFG7 0x088
#define UNIPHY_PLL_CAL_CFG8 0x08c
#define UNIPHY_PLL_CAL_CFG9 0x090
#define UNIPHY_PLL_CAL_CFG10 0x094
#define UNIPHY_PLL_CAL_CFG11 0x098
+#define UNIPHY_PLL_EFUSE_CFG 0x09c
+#define UNIPHY_PLL_DEBUG_BUS_SEL 0x0a0
+#define UNIPHY_PLL_CTRL_42 0x0a4
+#define UNIPHY_PLL_CTRL_43 0x0a8
+#define UNIPHY_PLL_CTRL_44 0x0ac
+#define UNIPHY_PLL_CTRL_45 0x0b0
+#define UNIPHY_PLL_CTRL_46 0x0b4
+#define UNIPHY_PLL_CTRL_47 0x0b8
+#define UNIPHY_PLL_CTRL_48 0x0bc
#define UNIPHY_PLL_STATUS 0x0c0
+#define UNIPHY_PLL_DEBUG_BUS0 0x0c4
+#define UNIPHY_PLL_DEBUG_BUS1 0x0c8
+#define UNIPHY_PLL_DEBUG_BUS2 0x0cc
+#define UNIPHY_PLL_DEBUG_BUS3 0x0d0
+#define UNIPHY_PLL_CTRL_54 0x0d4
#endif
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v7 4/4] phy: qualcomm: add MSM8974 HDMI PHY support
From: Dmitry Baryshkov @ 2026-03-23 22:56 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Vinod Koul, Neil Armstrong
Cc: linux-kernel, linux-arm-msm, dri-devel, freedreno, linux-phy,
Dmitry Baryshkov, Konrad Dybcio
In-Reply-To: <20260324-fd-hdmi-phy-v7-0-b41dde8d83b8@oss.qualcomm.com>
Add support for HDMI PHY on Qualcomm MSM8974 / APQ8074 platforms.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c | 281 +++++++++++++++++++++++++++++
1 file changed, 281 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c b/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c
index 720757f8f393..a1a73586be53 100644
--- a/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c
+++ b/drivers/phy/qualcomm/phy-qcom-hdmi-28hpm.c
@@ -6,10 +6,12 @@
* Author: Rob Clark <robdclark@gmail.com>
*/
+#include <linux/bitfield.h>
#include <linux/delay.h>
#include <linux/iopoll.h>
#include "phy-qcom-hdmi-preqmp.h"
+#include "phy-qcom-uniphy.h"
#define REG_HDMI_8x74_ANA_CFG0 0x00000000
#define REG_HDMI_8x74_ANA_CFG1 0x00000004
@@ -31,8 +33,282 @@
#define REG_HDMI_8x74_BIST_PATN3 0x00000048
#define REG_HDMI_8x74_STATUS 0x0000005c
+#define HDMI_8974_VCO_MAX_FREQ 1800000000UL
+#define HDMI_8974_VCO_MIN_FREQ 600000000UL
+
+#define HDMI_8974_COMMON_DIV 5
+
+static inline void write16(u16 val, void __iomem *reg)
+{
+ writel(val & 0xff, reg);
+ writel(val >> 8, reg + 4);
+}
+
+static inline void write24(u32 val, void __iomem *reg)
+{
+ writel(val & 0xff, reg);
+ writel((val >> 8) & 0xff, reg + 4);
+ writel(val >> 16, reg + 8);
+}
+
+static inline u32 read24(void __iomem *reg)
+{
+ u32 val = readl(reg);
+
+ val |= readl(reg + 4) << 8;
+ val |= readl(reg + 8) << 16;
+
+ return val;
+}
+
+static void qcom_uniphy_setup(void __iomem *base, unsigned int ref_freq,
+ bool sdm_mode,
+ bool ref_freq_mult_2,
+ bool dither,
+ unsigned int refclk_div,
+ unsigned int vco_freq)
+{
+ unsigned int int_ref_freq = ref_freq * (ref_freq_mult_2 ? 2 : 1);
+ unsigned int div_in_freq = vco_freq / refclk_div;
+ unsigned int dc_offset = div_in_freq / int_ref_freq - 1;
+ unsigned int sdm_freq_seed;
+ unsigned int val;
+ unsigned int remain = div_in_freq - (dc_offset + 1) * int_ref_freq;
+
+ sdm_freq_seed = mult_frac(remain, 0x10000, int_ref_freq);
+
+ val = FIELD_PREP(UNIPHY_PLL_REFCLK_DBLR, ref_freq_mult_2) |
+ FIELD_PREP(UNIPHY_PLL_REFCLK_DIV, refclk_div - 1);
+ writel(val, base + UNIPHY_PLL_REFCLK_CFG);
+
+ if (sdm_mode) {
+ writel(0, base + UNIPHY_PLL_SDM_CFG0);
+ writel(FIELD_PREP(UNIPHY_PLL_SDM_DITHER_EN, dither) | dc_offset,
+ base + UNIPHY_PLL_SDM_CFG1);
+ write24(sdm_freq_seed, base + UNIPHY_PLL_SDM_CFG2);
+ } else {
+ writel(UNIPHY_PLL_SDM_BYP | dc_offset, base + UNIPHY_PLL_SDM_CFG0);
+ writel(0, base + UNIPHY_PLL_SDM_CFG1);
+ write24(0, base + UNIPHY_PLL_SDM_CFG2);
+ }
+
+ write16(mult_frac(ref_freq, 5, 1000), base + UNIPHY_PLL_CAL_CFG8);
+ write16(vco_freq / 16, base + UNIPHY_PLL_CAL_CFG10);
+}
+
+static unsigned long qcom_uniphy_recalc(void __iomem *base, unsigned long parent_rate)
+{
+ unsigned long rate;
+ u32 refclk_cfg;
+ u32 dc_offset;
+ u64 fraq_n;
+ u32 val;
+
+ refclk_cfg = readl(base + UNIPHY_PLL_REFCLK_CFG);
+ if (refclk_cfg & UNIPHY_PLL_REFCLK_DBLR)
+ parent_rate *= 2;
+
+ val = readl(base + UNIPHY_PLL_SDM_CFG0);
+ if (FIELD_GET(UNIPHY_PLL_SDM_BYP, val)) {
+ dc_offset = FIELD_GET(UNIPHY_PLL_SDM_BYP_DIV, val);
+ fraq_n = 0;
+ } else {
+ dc_offset = FIELD_GET(UNIPHY_PLL_SDM_DC_OFFSET,
+ readl(base + UNIPHY_PLL_SDM_CFG1));
+ fraq_n = read24(base + UNIPHY_PLL_SDM_CFG2);
+ }
+
+ rate = (dc_offset + 1) * parent_rate;
+ rate += mult_frac(fraq_n, parent_rate, 0x10000);
+
+ rate *= FIELD_GET(UNIPHY_PLL_REFCLK_DIV, refclk_cfg) + 1;
+
+ return rate;
+}
+
+static const unsigned int qcom_hdmi_8974_divs[] = {1, 2, 4, 6};
+
+static unsigned long qcom_hdmi_8974_pll_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct qcom_hdmi_preqmp_phy *hdmi_phy = hw_clk_to_phy(hw);
+ u32 div_idx = readl(hdmi_phy->pll_reg + UNIPHY_PLL_POSTDIV1_CFG);
+ unsigned long rate = qcom_uniphy_recalc(hdmi_phy->pll_reg, parent_rate);
+
+ return rate / HDMI_8974_COMMON_DIV / qcom_hdmi_8974_divs[div_idx & 0x3];
+}
+
+static int qcom_hdmi_8974_pll_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
+{
+ unsigned long min_freq = HDMI_8974_VCO_MIN_FREQ / HDMI_8974_COMMON_DIV;
+ unsigned long max_freq = HDMI_8974_VCO_MAX_FREQ / HDMI_8974_COMMON_DIV;
+
+ req->rate = clamp(req->rate, min_freq / 6, max_freq);
+
+ return 0;
+}
+
+static const struct clk_ops qcom_hdmi_8974_pll_ops = {
+ .recalc_rate = qcom_hdmi_8974_pll_recalc_rate,
+ .determine_rate = qcom_hdmi_8974_pll_determine_rate,
+};
+
+static int qcom_hdmi_msm8974_phy_find_div(unsigned long long pixclk)
+{
+ unsigned long long min_freq = HDMI_8974_VCO_MIN_FREQ / HDMI_8974_COMMON_DIV;
+ int i;
+
+ if (pixclk > HDMI_8974_VCO_MAX_FREQ / HDMI_8974_COMMON_DIV)
+ return -EINVAL;
+
+ for (i = 0; i < ARRAY_SIZE(qcom_hdmi_8974_divs); i++) {
+ if (pixclk >= min_freq / qcom_hdmi_8974_divs[i])
+ return i;
+ }
+
+ return -EINVAL;
+}
+
+static int qcom_hdmi_msm8974_phy_pll_set_rate(struct qcom_hdmi_preqmp_phy *hdmi_phy)
+{
+ unsigned long long pixclk = hdmi_phy->hdmi_opts.tmds_char_rate;
+ unsigned long vco_rate;
+ unsigned int div;
+ int div_idx = 0;
+
+ div_idx = qcom_hdmi_msm8974_phy_find_div(pixclk);
+ if (WARN_ON(div_idx < 0))
+ return div_idx;
+
+ div = qcom_hdmi_8974_divs[div_idx];
+ vco_rate = pixclk * HDMI_8974_COMMON_DIV * div;
+
+ writel(0x81, hdmi_phy->phy_reg + REG_HDMI_8x74_GLB_CFG);
+
+ writel(0x01, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ writel(0x19, hdmi_phy->pll_reg + UNIPHY_PLL_VCOLPF_CFG);
+ writel(0x0e, hdmi_phy->pll_reg + UNIPHY_PLL_LPFR_CFG);
+ writel(0x20, hdmi_phy->pll_reg + UNIPHY_PLL_LPFC1_CFG);
+ writel(0x0d, hdmi_phy->pll_reg + UNIPHY_PLL_LPFC2_CFG);
+
+ qcom_uniphy_setup(hdmi_phy->pll_reg, 19200000, true, true, true, 1, vco_rate);
+
+ writel(0x10, hdmi_phy->pll_reg + UNIPHY_PLL_LKDET_CFG0);
+ writel(0x1a, hdmi_phy->pll_reg + UNIPHY_PLL_LKDET_CFG1);
+ writel(0x05, hdmi_phy->pll_reg + UNIPHY_PLL_LKDET_CFG2);
+
+ writel(div_idx,
+ hdmi_phy->pll_reg + UNIPHY_PLL_POSTDIV1_CFG);
+
+ writel(0x00, hdmi_phy->pll_reg + UNIPHY_PLL_POSTDIV2_CFG);
+ writel(0x00, hdmi_phy->pll_reg + UNIPHY_PLL_POSTDIV3_CFG);
+ writel(0x01, hdmi_phy->pll_reg + UNIPHY_PLL_CAL_CFG2);
+
+ writel(0x1f, hdmi_phy->phy_reg + REG_HDMI_8x74_PD_CTRL0);
+ udelay(50);
+
+ writel(0x0f, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_PD_CTRL1);
+ writel(0x10, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG2);
+ writel(0xdb, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG0);
+ writel(0x43, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG1);
+ if (pixclk == 297000) {
+ writel(0x06, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG2);
+ writel(0x03, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG3);
+ } else if (pixclk == 268500) {
+ writel(0x05, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG2);
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG3);
+ } else {
+ writel(0x02, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG2);
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG3);
+ }
+
+ writel(0x04, hdmi_phy->pll_reg + UNIPHY_PLL_VREG_CFG);
+
+ writel(0xd0, hdmi_phy->phy_reg + REG_HDMI_8x74_DCC_CFG0);
+ writel(0x1a, hdmi_phy->phy_reg + REG_HDMI_8x74_DCC_CFG1);
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG0);
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG1);
+
+ if (pixclk == 268500)
+ writel(0x11, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG2);
+ else
+ writel(0x02, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG2);
+
+ writel(0x05, hdmi_phy->phy_reg + REG_HDMI_8x74_TXCAL_CFG3);
+ udelay(200);
+
+ return 0;
+}
+
+static int qcom_hdmi_msm8974_phy_pll_enable(struct qcom_hdmi_preqmp_phy *hdmi_phy)
+{
+ int ret;
+ unsigned long status;
+
+ /* Global enable */
+ writel(0x81, hdmi_phy->phy_reg + REG_HDMI_8x74_GLB_CFG);
+
+ /* Power up power gen */
+ writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_PD_CTRL0);
+ udelay(350);
+
+ /* PLL power up */
+ writel(0x01, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(5);
+
+ /* Power up PLL LDO */
+ writel(0x03, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(350);
+
+ /* PLL power up */
+ writel(0x0f, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(350);
+
+ /* Poll for PLL ready status */
+ ret = readl_poll_timeout(hdmi_phy->pll_reg + UNIPHY_PLL_STATUS,
+ status, status & BIT(0),
+ 100, 2000);
+ if (ret) {
+ dev_warn(hdmi_phy->dev, "HDMI PLL not ready\n");
+ goto err;
+ }
+
+ udelay(350);
+
+ /* Poll for PHY ready status */
+ ret = readl_poll_timeout(hdmi_phy->phy_reg + REG_HDMI_8x74_STATUS,
+ status, status & BIT(0),
+ 100, 2000);
+ if (ret) {
+ dev_warn(hdmi_phy->dev, "HDMI PHY not ready\n");
+ goto err;
+ }
+
+ return 0;
+
+err:
+ writel(0, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(5);
+ writel(0, hdmi_phy->phy_reg + REG_HDMI_8x74_GLB_CFG);
+
+ return ret;
+}
+
static int qcom_hdmi_msm8974_phy_power_on(struct qcom_hdmi_preqmp_phy *hdmi_phy)
{
+ int ret;
+
+ ret = qcom_hdmi_msm8974_phy_pll_set_rate(hdmi_phy);
+ if (ret)
+ return ret;
+
+ ret = qcom_hdmi_msm8974_phy_pll_enable(hdmi_phy);
+ if (ret)
+ return ret;
+
writel(0x1b, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG0);
writel(0xf2, hdmi_phy->phy_reg + REG_HDMI_8x74_ANA_CFG1);
writel(0x00, hdmi_phy->phy_reg + REG_HDMI_8x74_BIST_CFG0);
@@ -49,6 +325,10 @@ static int qcom_hdmi_msm8974_phy_power_off(struct qcom_hdmi_preqmp_phy *hdmi_phy
{
writel(0x7f, hdmi_phy->phy_reg + REG_HDMI_8x74_PD_CTRL0);
+ writel(0, hdmi_phy->pll_reg + UNIPHY_PLL_GLB_CFG);
+ udelay(5);
+ writel(0, hdmi_phy->phy_reg + REG_HDMI_8x74_GLB_CFG);
+
return 0;
}
@@ -67,5 +347,6 @@ const struct qcom_hdmi_preqmp_cfg msm8974_hdmi_phy_cfg = {
.power_on = qcom_hdmi_msm8974_phy_power_on,
.power_off = qcom_hdmi_msm8974_phy_power_off,
+ .pll_ops = &qcom_hdmi_8974_pll_ops,
.pll_parent = &msm8974_hdmi_pll_parent,
};
--
2.47.3
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH 04/10] regulator: of: switch to using class_find_device_by_fwnode()
From: Russell King (Oracle) @ 2026-03-24 0:17 UTC (permalink / raw)
To: Andrew Lunn
Cc: Mark Brown, Dmitry Torokhov, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Vinod Koul,
Neil Armstrong, Liam Girdwood, Lee Jones, Pavel Machek,
Peter Rosin, Heiner Kallweit, 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: <cf92122d-6b15-458a-bf89-189a0a6874f7@lunn.ch>
On Mon, Mar 23, 2026 at 09:01:47PM +0100, Andrew Lunn wrote:
> On Mon, Mar 23, 2026 at 07:05:13PM +0000, Mark Brown wrote:
> > On Mon, Mar 23, 2026 at 11:28:27AM -0700, Dmitry Torokhov wrote:
> > > On Mon, Mar 23, 2026 at 02:00:43PM +0000, Mark Brown wrote:
> >
> > > > The regulator API is very deliberately specifically using the OF APIs,
> > > > not the ACPI APIs, since ACPI really doesn't want to model regulators.
> >
> > > For now? We also have software nodes and maybe we come up with something
> > > else in the future...
> >
> > > I think we should use firmware-agnostic APIs as much as possible, and
> > > only use OF- or ACPI-specific ones when there is no generic equivalent.
> > > This makes the code most flexible.
> >
> > I think this is a worrying idea for core code like this, we have
> > specific firmware bindings for specific firmware interfaces with the
> > different interfaces having very different ideas of how things should be
> > modelled. The chances that firmware agnostic code is going to do the
> > right thing seem low, and encouraging the use of generic APIs that might
> > happen to run OK raises the risk that we'll get firmware vendors relying
> > on them and leaving us with a conceptual mishmash to sort through.
>
> How do you handle deprecated OF properties? This is a problem i've run
> into before. A developer needs an ACPI binding, so they blindly
> convert from of_ to device_ without engaging brain. As a result, they
> bring all the deprecated OF properties we want to die into the brand
> new ACPI bindings.
>
> A agree with Mark here. OF != ACPI, and anything which makes it appear
> they are the same is just going to lead developers down the wrong path
> and increase Maintainers work pointing out all the problems.
That's three who agree.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* RE: [PATCH v5 phy-next 09/27] scsi: ufs: exynos: stop poking into struct phy guts
From: Alim Akhtar @ 2026-03-23 17:26 UTC (permalink / raw)
To: 'Vladimir Oltean', linux-phy
Cc: 'Vinod Koul', 'Neil Armstrong', dri-devel,
freedreno, linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio,
linux-ide, linux-kernel, linux-media, linux-pci,
linux-renesas-soc, linux-riscv, linux-rockchip, linux-samsung-soc,
linux-scsi, linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, 'Bart Van Assche',
'Peter Griffin', 'James E.J. Bottomley',
'Martin K. Petersen', 'Krzysztof Kozlowski',
'Chanho Park'
In-Reply-To: <20260319223241.1351137-10-vladimir.oltean@nxp.com>
HI Vladimir,
> -----Original Message-----
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
> Sent: Friday, March 20, 2026 4:02 AM
> To: linux-phy@lists.infradead.org
> Cc: Vinod Koul <vkoul@kernel.org>; Neil Armstrong
> <neil.armstrong@linaro.org>; dri-devel@lists.freedesktop.org;
> freedreno@lists.freedesktop.org; linux-arm-kernel@lists.infradead.org;
> linux-arm-msm@vger.kernel.org; linux-can@vger.kernel.org; linux-
> gpio@vger.kernel.org; linux-ide@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-media@vger.kernel.org; linux-
> pci@vger.kernel.org; linux-renesas-soc@vger.kernel.org; linux-
> riscv@lists.infradead.org; linux-rockchip@lists.infradead.org;
linux-samsung-
> soc@vger.kernel.org; linux-scsi@vger.kernel.org;
linux-sunxi@lists.linux.dev;
> linux-tegra@vger.kernel.org; linux-usb@vger.kernel.org;
> netdev@vger.kernel.org; spacemit@lists.linux.dev;
> UNGLinuxDriver@microchip.com; Bart Van Assche <bvanassche@acm.org>;
> Alim Akhtar <alim.akhtar@samsung.com>; Peter Griffin
> <peter.griffin@linaro.org>; James E.J. Bottomley
> <James.Bottomley@HansenPartnership.com>; Martin K. Petersen
> <martin.petersen@oracle.com>; Krzysztof Kozlowski <krzk@kernel.org>;
> Chanho Park <chanho61.park@samsung.com>
> Subject: [PATCH v5 phy-next 09/27] scsi: ufs: exynos: stop poking into
struct
> phy guts
>
> The Exynos host controller driver is clearly a PHY consumer (gets the
> ufs->phy using devm_phy_get()), but pokes into the guts of struct phy
> to get the generic_phy->power_count.
>
> The UFS core (specifically ufshcd_link_startup()) may call the variant
> operation exynos_ufs_pre_link() -> exynos_ufs_phy_init() multiple times if
> the link startup fails and needs to be retried.
>
> However ufs-exynos shouldn't be doing what it's doing, i.e. looking at the
> generic_phy->power_count, because in the general sense of the API, a
> single Generic PHY may have multiple consumers. If ufs-exynos looks at
> generic_phy->power_count, there's no guarantee that this ufs-exynos
> instance is the one who previously bumped that power count. So it may be
> powering down the PHY on behalf of another consumer.
>
> The correct way in which this should be handled is ufs-exynos should
> *remember* whether it has initialized and powered up the PHY before, and
> power it down during link retries. Not rely on the power_count (which,
btw,
> on the writer side is modified under &phy->mutex, but on the reader side
is
> accessed unlocked). This is a discouraged pattern even if here it doesn't
> cause functional problems.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> Reviewed-by: Bart Van Assche <bvanassche@acm.org>
> ---
Thanks for the patch
Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
Tested this patch for basic UFS functionality, UFS still works.
Feel free to add
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 phy-next 10/27] scsi: ufs: qcom: keep parallel track of PHY power state
From: Manivannan Sadhasivam @ 2026-03-24 5:30 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, James E.J. Bottomley, Martin K. Petersen,
Nitin Rawat
In-Reply-To: <20260319223241.1351137-11-vladimir.oltean@nxp.com>
On Fri, Mar 20, 2026 at 12:32:24AM +0200, Vladimir Oltean wrote:
> As explained in the similar ufs-exynos.c change, PHY consumer drivers
> should not look at the phy->power_count, because in the general case
> there might also be other consumers who have called phy_power_on() too,
> so the fact that the power_count is non-zero does not mean that we did.
>
> Moreover, struct phy will become opaque soon, so the qcom UFS driver
> will not be able to apply this pattern. Keep parallel track of the PHY
> power state, instead of looking at a field which will become unavailable
> (phy->power_count).
>
> About treating the phy_power_off() return code: from an API perspective,
> this should have probably returned void, otherwise consumers would be
> stuck in a state they can't escape. The provider, phy-qcom-qmp-ufs.c,
> does return 0 in its power_off() implementation. I consider it safe to
> discard potential errors from phy_power_off() instead of complicating
> the phy_powered_on logic.
>
You could even simplify the code by getting rid of the 'phy_powered_on' check
altogether. There is no real need to track the PHY power state in this driver.
It is safe to call phy_power_off() without any checks.
- Mani
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
> Cc: Manivannan Sadhasivam <mani@kernel.org>
> Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
> Cc: Nitin Rawat <quic_nitirawa@quicinc.com>
>
> v4->v5: patch is new
> ---
> drivers/ufs/host/ufs-qcom.c | 9 +++++++--
> drivers/ufs/host/ufs-qcom.h | 1 +
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
> index 375fd24ba458..3b8bd9968235 100644
> --- a/drivers/ufs/host/ufs-qcom.c
> +++ b/drivers/ufs/host/ufs-qcom.c
> @@ -508,9 +508,10 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
> if (ret)
> return ret;
>
> - if (phy->power_count)
> + if (host->phy_powered_on) {
> phy_power_off(phy);
> -
> + host->phy_powered_on = false;
> + }
>
> /* phy initialization - calibrate the phy */
> ret = phy_init(phy);
> @@ -531,6 +532,7 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
> __func__, ret);
> goto out_disable_phy;
> }
> + host->phy_powered_on = true;
>
> ret = phy_calibrate(phy);
> if (ret) {
> @@ -1268,6 +1270,7 @@ static int ufs_qcom_setup_clocks(struct ufs_hba *hba, bool on,
> dev_err(hba->dev, "phy power off failed, ret=%d\n", err);
> return err;
> }
> + host->phy_powered_on = false;
> }
> break;
> case POST_CHANGE:
> @@ -1277,6 +1280,7 @@ static int ufs_qcom_setup_clocks(struct ufs_hba *hba, bool on,
> dev_err(hba->dev, "phy power on failed, ret = %d\n", err);
> return err;
> }
> + host->phy_powered_on = true;
>
> /* enable the device ref clock for HS mode*/
> if (ufshcd_is_hs_mode(&hba->pwr_info))
> @@ -1467,6 +1471,7 @@ static void ufs_qcom_exit(struct ufs_hba *hba)
>
> ufs_qcom_disable_lane_clks(host);
> phy_power_off(host->generic_phy);
> + host->phy_powered_on = false;
> phy_exit(host->generic_phy);
> }
>
> diff --git a/drivers/ufs/host/ufs-qcom.h b/drivers/ufs/host/ufs-qcom.h
> index 1111ab34da01..72ce0687fa42 100644
> --- a/drivers/ufs/host/ufs-qcom.h
> +++ b/drivers/ufs/host/ufs-qcom.h
> @@ -282,6 +282,7 @@ struct ufs_qcom_host {
> struct clk_bulk_data *clks;
> u32 num_clks;
> bool is_lane_clks_enabled;
> + bool phy_powered_on;
>
> struct icc_path *icc_ddr;
> struct icc_path *icc_cpu;
> --
> 2.43.0
>
--
மணிவண்ணன் சதாசிவம்
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v5 phy-next 08/27] PCI: Remove device links to PHY
From: Manivannan Sadhasivam @ 2026-03-24 5:35 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, Bjorn Helgaas, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Vignesh Raghavendra,
Siddharth Vadapalli
In-Reply-To: <20260319223241.1351137-9-vladimir.oltean@nxp.com>
On Fri, Mar 20, 2026 at 12:32:22AM +0200, Vladimir Oltean wrote:
> This is practically a full revert of commit
> 7a4db656a635 ("PCI: dra7xx: Create functional dependency between PCIe and PHY")
> and a partial revert of the device link pieces from commits
> dfb80534692d ("PCI: cadence: Add generic PHY support to host and EP drivers")
> 49229238ab47 ("PCI: keystone: Cleanup PHY handling")
>
> The trouble with these commits is that they dereference fields inside
> struct phy from a consumer driver, which will become no longer possible.
>
> Since commit 987351e1ea77 ("phy: core: Add consumer device link
> support") from 2019, the PHY core also adds a device link to order PHY
> provider and consumer suspend/resume operations. All reverted commits
> are from 2017-2018, and what they do should actually be redundant now.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
> Cc: Manivannan Sadhasivam <mani@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Vignesh Raghavendra <vigneshr@ti.com>
> Cc: Siddharth Vadapalli <s-vadapalli@ti.com>
>
> v3->v5: none
> v2->v3:
> - remove dangling set but unused phy_count local variable in
> cdns_plat_pcie_probe()
> v1->v2:
> - fully remove struct device link **link from struct cdns_pcie and from
> cdns_plat_pcie_probe() error path
> - collect tag
> - adjust commit title
> ---
> .../controller/cadence/pcie-cadence-plat.c | 4 ---
> drivers/pci/controller/cadence/pcie-cadence.c | 16 +---------
> drivers/pci/controller/cadence/pcie-cadence.h | 2 --
> drivers/pci/controller/dwc/pci-dra7xx.c | 16 ----------
> drivers/pci/controller/dwc/pci-keystone.c | 31 +++----------------
> 5 files changed, 5 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/pci/controller/cadence/pcie-cadence-plat.c b/drivers/pci/controller/cadence/pcie-cadence-plat.c
> index b067a3296dd3..fc39c01b7964 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-plat.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-plat.c
> @@ -41,7 +41,6 @@ static int cdns_plat_pcie_probe(struct platform_device *pdev)
> struct pci_host_bridge *bridge;
> struct cdns_pcie_ep *ep;
> struct cdns_pcie_rc *rc;
> - int phy_count;
> bool is_rc;
> int ret;
>
> @@ -122,9 +121,6 @@ static int cdns_plat_pcie_probe(struct platform_device *pdev)
> pm_runtime_put_sync(dev);
> pm_runtime_disable(dev);
> cdns_pcie_disable_phy(cdns_plat_pcie->pcie);
> - phy_count = cdns_plat_pcie->pcie->phy_count;
> - while (phy_count--)
> - device_link_del(cdns_plat_pcie->pcie->link[phy_count]);
>
> return 0;
> }
> diff --git a/drivers/pci/controller/cadence/pcie-cadence.c b/drivers/pci/controller/cadence/pcie-cadence.c
> index a1eada56edba..0ac980249941 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence.c
> @@ -222,7 +222,6 @@ int cdns_pcie_init_phy(struct device *dev, struct cdns_pcie *pcie)
> struct device_node *np = dev->of_node;
> int phy_count;
> struct phy **phy;
> - struct device_link **link;
> int i;
> int ret;
> const char *name;
> @@ -238,10 +237,6 @@ int cdns_pcie_init_phy(struct device *dev, struct cdns_pcie *pcie)
> if (!phy)
> return -ENOMEM;
>
> - link = devm_kcalloc(dev, phy_count, sizeof(*link), GFP_KERNEL);
> - if (!link)
> - return -ENOMEM;
> -
> for (i = 0; i < phy_count; i++) {
> of_property_read_string_index(np, "phy-names", i, &name);
> phy[i] = devm_phy_get(dev, name);
> @@ -249,17 +244,10 @@ int cdns_pcie_init_phy(struct device *dev, struct cdns_pcie *pcie)
> ret = PTR_ERR(phy[i]);
> goto err_phy;
> }
> - link[i] = device_link_add(dev, &phy[i]->dev, DL_FLAG_STATELESS);
> - if (!link[i]) {
> - devm_phy_put(dev, phy[i]);
> - ret = -EINVAL;
> - goto err_phy;
> - }
> }
>
> pcie->phy_count = phy_count;
> pcie->phy = phy;
> - pcie->link = link;
>
> ret = cdns_pcie_enable_phy(pcie);
> if (ret)
> @@ -268,10 +256,8 @@ int cdns_pcie_init_phy(struct device *dev, struct cdns_pcie *pcie)
> return 0;
>
> err_phy:
> - while (--i >= 0) {
> - device_link_del(link[i]);
> + while (--i >= 0)
> devm_phy_put(dev, phy[i]);
> - }
>
> return ret;
> }
> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h b/drivers/pci/controller/cadence/pcie-cadence.h
> index 443033c607d7..35b0b33bc6fb 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence.h
> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
> @@ -82,7 +82,6 @@ struct cdns_plat_pcie_of_data {
> * @is_rc: tell whether the PCIe controller mode is Root Complex or Endpoint.
> * @phy_count: number of supported PHY devices
> * @phy: list of pointers to specific PHY control blocks
> - * @link: list of pointers to corresponding device link representations
> * @ops: Platform-specific ops to control various inputs from Cadence PCIe
> * wrapper
> * @cdns_pcie_reg_offsets: Register bank offsets for different SoC
> @@ -95,7 +94,6 @@ struct cdns_pcie {
> bool is_rc;
> int phy_count;
> struct phy **phy;
> - struct device_link **link;
> const struct cdns_pcie_ops *ops;
> const struct cdns_plat_pcie_of_data *cdns_pcie_reg_offsets;
> };
> diff --git a/drivers/pci/controller/dwc/pci-dra7xx.c b/drivers/pci/controller/dwc/pci-dra7xx.c
> index d5d26229063f..b91ab37845c9 100644
> --- a/drivers/pci/controller/dwc/pci-dra7xx.c
> +++ b/drivers/pci/controller/dwc/pci-dra7xx.c
> @@ -9,7 +9,6 @@
>
> #include <linux/clk.h>
> #include <linux/delay.h>
> -#include <linux/device.h>
> #include <linux/err.h>
> #include <linux/interrupt.h>
> #include <linux/irq.h>
> @@ -683,7 +682,6 @@ static int dra7xx_pcie_probe(struct platform_device *pdev)
> int i;
> int phy_count;
> struct phy **phy;
> - struct device_link **link;
> void __iomem *base;
> struct dw_pcie *pci;
> struct dra7xx_pcie *dra7xx;
> @@ -731,10 +729,6 @@ static int dra7xx_pcie_probe(struct platform_device *pdev)
> if (!phy)
> return -ENOMEM;
>
> - link = devm_kcalloc(dev, phy_count, sizeof(*link), GFP_KERNEL);
> - if (!link)
> - return -ENOMEM;
> -
> dra7xx->clk = devm_clk_get_optional(dev, NULL);
> if (IS_ERR(dra7xx->clk))
> return dev_err_probe(dev, PTR_ERR(dra7xx->clk),
> @@ -749,12 +743,6 @@ static int dra7xx_pcie_probe(struct platform_device *pdev)
> phy[i] = devm_phy_get(dev, name);
> if (IS_ERR(phy[i]))
> return PTR_ERR(phy[i]);
> -
> - link[i] = device_link_add(dev, &phy[i]->dev, DL_FLAG_STATELESS);
> - if (!link[i]) {
> - ret = -EINVAL;
> - goto err_link;
> - }
> }
>
> dra7xx->base = base;
> @@ -856,10 +844,6 @@ static int dra7xx_pcie_probe(struct platform_device *pdev)
> pm_runtime_disable(dev);
> dra7xx_pcie_disable_phy(dra7xx);
>
> -err_link:
> - while (--i >= 0)
> - device_link_del(link[i]);
> -
> return ret;
> }
>
> diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
> index 642e4c45eefc..07698c645e02 100644
> --- a/drivers/pci/controller/dwc/pci-keystone.c
> +++ b/drivers/pci/controller/dwc/pci-keystone.c
> @@ -130,7 +130,6 @@ struct keystone_pcie {
> int num_lanes;
> u32 num_viewport;
> struct phy **phy;
> - struct device_link **link;
> struct device_node *msi_intc_np;
> struct irq_domain *intx_irq_domain;
> struct device_node *np;
> @@ -1118,7 +1117,6 @@ static int ks_pcie_probe(struct platform_device *pdev)
> enum dw_pcie_device_mode mode;
> struct dw_pcie *pci;
> struct keystone_pcie *ks_pcie;
> - struct device_link **link;
> struct gpio_desc *gpiod;
> struct resource *res;
> void __iomem *base;
> @@ -1189,31 +1187,17 @@ static int ks_pcie_probe(struct platform_device *pdev)
> if (!phy)
> return -ENOMEM;
>
> - link = devm_kcalloc(dev, num_lanes, sizeof(*link), GFP_KERNEL);
> - if (!link)
> - return -ENOMEM;
> -
> for (i = 0; i < num_lanes; i++) {
> snprintf(name, sizeof(name), "pcie-phy%d", i);
> phy[i] = devm_phy_optional_get(dev, name);
> if (IS_ERR(phy[i])) {
> ret = PTR_ERR(phy[i]);
> - goto err_link;
> - }
> -
> - if (!phy[i])
> - continue;
> -
> - link[i] = device_link_add(dev, &phy[i]->dev, DL_FLAG_STATELESS);
> - if (!link[i]) {
> - ret = -EINVAL;
> - goto err_link;
> + goto err;
> }
> }
>
> ks_pcie->np = np;
> ks_pcie->pci = pci;
> - ks_pcie->link = link;
> ks_pcie->num_lanes = num_lanes;
> ks_pcie->phy = phy;
>
> @@ -1223,7 +1207,7 @@ static int ks_pcie_probe(struct platform_device *pdev)
> ret = PTR_ERR(gpiod);
> if (ret != -EPROBE_DEFER)
> dev_err(dev, "Failed to get reset GPIO\n");
> - goto err_link;
> + goto err;
> }
>
> /* Obtain references to the PHYs */
> @@ -1238,7 +1222,7 @@ static int ks_pcie_probe(struct platform_device *pdev)
>
> if (ret) {
> dev_err(dev, "failed to enable phy\n");
> - goto err_link;
> + goto err;
> }
>
> platform_set_drvdata(pdev, ks_pcie);
> @@ -1325,25 +1309,18 @@ static int ks_pcie_probe(struct platform_device *pdev)
> pm_runtime_disable(dev);
> ks_pcie_disable_phy(ks_pcie);
>
> -err_link:
> - while (--i >= 0 && link[i])
> - device_link_del(link[i]);
> -
> +err:
> return ret;
> }
>
> static void ks_pcie_remove(struct platform_device *pdev)
> {
> struct keystone_pcie *ks_pcie = platform_get_drvdata(pdev);
> - struct device_link **link = ks_pcie->link;
> - int num_lanes = ks_pcie->num_lanes;
> struct device *dev = &pdev->dev;
>
> pm_runtime_put(dev);
> pm_runtime_disable(dev);
> ks_pcie_disable_phy(ks_pcie);
> - while (num_lanes--)
> - device_link_del(link[num_lanes]);
> }
>
> static struct platform_driver ks_pcie_driver = {
> --
> 2.43.0
>
--
மணிவண்ணன் சதாசிவம்
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes
From: Manivannan Sadhasivam @ 2026-03-24 5:59 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Ziyue Zhang, andersson, konradybcio, robh, krzk+dt, conor+dt,
jingoohan1, lpieralisi, kwilczynski, bhelgaas, johan+linaro,
vkoul, kishon, neil.armstrong, abel.vesa, kw, linux-arm-msm,
devicetree, linux-kernel, linux-pci, linux-phy, qiang.yu,
quic_krichai, quic_vbadigan
In-Reply-To: <20260319171728.GA505341@bhelgaas>
On Thu, Mar 19, 2026 at 12:17:28PM -0500, Bjorn Helgaas wrote:
> On Thu, Mar 19, 2026 at 10:58:36AM +0530, Manivannan Sadhasivam wrote:
> > On Tue, Mar 17, 2026 at 12:13:19PM -0500, Bjorn Helgaas wrote:
> > > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > >
> > > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > > to the port nodes.
> > > > > >
> > > > > > This fixes probe failures seen on the following platforms:
> > > > > > - x1-hp-omnibook-x14
> > > > > > - x1-microsoft-denali
> > > > > > - x1e80100-lenovo-yoga-slim7x
> > > > > > - x1e80100-medion-sprchrgd-14-s1
> > > > > > - x1p42100-lenovo-thinkbook-16
> > > > > > - x1-asus-zenbook-a14
> > > > > > - x1-crd
> > > > > > - x1-dell-thena
> > > > > >
> > > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > >
> > > > > Are you saying that DTs in the field broke because of some kernel
> > > > > change? That's not supposed to happen. Even though PHY, PERST, and
> > > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > > the old style with them described in the Root Complex node.
> > > >
> > > > This is not related to the driver change. The driver correctly
> > > > parses all Root Port properties either in the Root Complex node (old
> > > > binding) or Root Port node (new binding). But commit 960609b22be5,
> > > > left converting mentioned board DTS to the new binding, leaving
> > > > those affected platforms in a half baked state i.e., some properties
> > > > in RC node and some in Root Port node. Driver cannot parse such
> > > > combinations, so it fails correctly so.
> > >
> > > The commit log mentions probe failures on some machines. I'd like it
> > > to be more clear about who is affected and what they need to do to fix
> > > their machines.
> >
> > There is already a list of affected machines mentioned in the commit
> > message.
> >
> > And for fix, they just need to apply this patch. Or once this patch
> > gets merged into v7.0-rcS, v7.0 will have no issue.
> >
> > > If it only affects developers who generated DTs based on
> > > 960609b22be5 for internal testing, we should say that so it's
> > > clear that no end users will see any regressions or boot
> > > failures.
> >
> > Whoever have included commit 960609b22be5 in their kernel and using
> > the above mentioned machines will see the failure. But looks like no
> > one really tested v7.0-rcS on these machines as we haven't gotten
> > any reports so far.
>
> Two points:
>
> - a2fbecdbbb9d ("PCI: qcom: Add support for parsing the new Root
> Port binding") is intended for hardware with multiple Root Ports
> with independent PHY/reset controls.
>
Not really. The commit was a prerequisite for adding multi-Root Port
controllers, but the intention is also to move the Root Port resources to Root
Port node and not stuff everything in the Host Bridge node.
> The driver will always fall back to PHY/reset info in the host
> bridge, so I think the only reason to do 960609b22be5 and this fix
> is if hamoa.dtsi will also be used for hardware with multiple Root
> Ports. If there's no plan for multiple RPs with hamoa.dtsi,
> reverting 960609b22be5 is another, less risky, option.
>
That will leave things in a messy state. Our intention is to move Root Port
resources to Root Port nodes for all SoCs irrespective of whether they support
multi-RPs or not.
> - 960609b22be5 only touches .dtsi and .dts files; it doesn't change
> the kernel itself.
>
> So I assume this issue only affects somebody who used v7.0-rc1 to
> rebuild the DTB for one of those machines and then installed that
> new DTB on their system. That sounds like developers to me, not
> end users.
>
Unfortunately, DTB is still not treated as a firmware like ACPI. And the fact
that we build the DTBs with the kernel, causes the DTBs to be updated whenever
an end user or a developer builds the kernel .deb package using 'make deb-pkg'
and installs then package using 'dpkg -i'.
And most of the users of these affected machines are pretty much both end users
and developers who know how to build the kernel themselves, so they won't be
updating the kernel through their distro update.
> The commit log already mentions the affected machines. I'm
> suggesting that it should also say something about the fact that
> only DTBs built with 960609b22be5 are affected, i.e., DTBs built
> with 960609b22be5 but without this fix are incompatible with the
> kernel driver.
Sure.
- Mani
--
மணிவண்ணன் சதாசிவம்
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes
From: Manivannan Sadhasivam @ 2026-03-24 6:07 UTC (permalink / raw)
To: Tobias Heider
Cc: Bjorn Andersson, Bjorn Helgaas, Ziyue Zhang, konradybcio, robh,
krzk+dt, conor+dt, jingoohan1, lpieralisi, kwilczynski, bhelgaas,
johan+linaro, vkoul, kishon, neil.armstrong, abel.vesa, kw,
linux-arm-msm, devicetree, linux-kernel, linux-pci, linux-phy,
qiang.yu, quic_krichai, quic_vbadigan
In-Reply-To: <CAARv3RSag8n0=ut9KGm0yALRPVTiyQ+bBBbT+3Vf1sNOCBLbGA@mail.gmail.com>
On Thu, Mar 19, 2026 at 02:50:37PM +0100, Tobias Heider wrote:
> Resending because the previous mail ended up being HTML (sorry)
>
> On Thu, Mar 19, 2026 at 6:39 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> >
> > On Wed, Mar 18, 2026 at 09:42:56PM -0500, Bjorn Andersson wrote:
> > > On Mon, Mar 16, 2026 at 08:50:12AM +0530, Manivannan Sadhasivam wrote:
> > > > On Sun, Mar 15, 2026 at 09:53:33PM -0500, Bjorn Andersson wrote:
> > > > > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > > > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > > > >
> > > > > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > > > > to the port nodes.
> > > > > > > >
> > > > > > > > This fixes probe failures seen on the following platforms:
> > > > > > > > - x1-hp-omnibook-x14
> > > > > > > > - x1-microsoft-denali
> > > > > > > > - x1e80100-lenovo-yoga-slim7x
> > > > > > > > - x1e80100-medion-sprchrgd-14-s1
> > > > > > > > - x1p42100-lenovo-thinkbook-16
> > > > > > > > - x1-asus-zenbook-a14
> > > > > > > > - x1-crd
> > > > > > > > - x1-dell-thena
> > > > > > > >
> > > > > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > > > >
> > > > > > > Are you saying that DTs in the field broke because of some kernel
> > > > > > > change? That's not supposed to happen. Even though PHY, PERST, and
> > > > > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > > > > the old style with them described in the Root Complex node.
> > > > > > >
> > > > > >
> > > > > > This is not related to the driver change. The driver correctly parses all Root
> > > > > > Port properties either in the Root Complex node (old binding) or Root Port node
> > > > > > (new binding). But commit 960609b22be5, left converting mentioned board DTS to
> > > > > > the new binding, leaving those affected platforms in a half baked state i.e.,
> > > > > > some properties in RC node and some in Root Port node. Driver cannot parse such
> > > > > > combinations, so it fails correctly so.
> > > > > >
> > > > >
> > > > > Are you saying that above listed machines has broken PCIe support in
> > > > > v7.0-rc?
> > > > >
> > > >
> > > > I haven't verified it, but I'm pretty sure PCIe is broken on these platforms.
> > > >
> > >
> > > In line with Bjorn's request, we shouldn't have to guess.
> > >
> > > > > It seems this is a (partial) revert of 960609b22be5, is this actually
> > > > > fixing that change, or is it only applicable once some other changes are
> > > > > applied?
> > > > >
> > > >
> > > > This change is fixing the issue in the respective board DTS and is a standalone
> > > > fix on top of v7.0-rc1.
> > > >
> > >
> > > So 960609b22be5 was broken when I merged it?
> > >
> >
> > Broken on the machines mentioned in the commit message, not for all Hamoa
> > platforms.
> >
> > > The commit message says that the commit was incomplete, in that it
> > > didn't fully convert from the old to the new style, so it sounds like
> > > the offending commit was incomplete - but I believe the offending commit
> > > was a workaround for the new solution not being in place and this commit
> > > mostly reverts the changes in the offending commit.
> > >
> >
> > So 960609b22be5 was supposed to move all the platforms from old PCIe binding to
> > new for greater good, but it apparently decided to do so only for a subset of
> > the platforms for some reason which don't know. But the problem arises due to
> > 960609b22be5 changing the hamoa.dtsi to the new binding which also warrants the
> > platform DTS to also be changed to the new binding. If we only have either dtsi
> > or dts converted and not both to the new binding, the driver will get confused
> > and fail. And this is what exactly happended for below machines:
> >
> > - x1-hp-omnibook-x14
> > - x1-microsoft-denali
> > - x1e80100-lenovo-yoga-slim7x
> > - x1e80100-medion-sprchrgd-14-s1
> > - x1p42100-lenovo-thinkbook-16
> > - x1-asus-zenbook-a14
> > - x1-crd
> > - x1-dell-thena
>
> I can confirm the breakage for (some of) the listed devices on Ubuntu.
> We are experimenting with 7.0-rcs ahead of our 26.04 release.
>
> I'll try to collect some test feedback for the fix.
> I'd certainly appreciate this being included as an rc fix since
> currently half of
> the x1 laptop devices are broken.
>
Thanks for the report. We will try to get this patch into v7.0-rcS.
It'd be appreciated if you can test this patch and give your tested-by tag.
- Mani
--
மணிவண்ணன் சதாசிவம்
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: tegra: xusb: Fix per-pad high-speed termination calibration
From: Jon Hunter @ 2026-03-24 9:11 UTC (permalink / raw)
To: Wei-Cheng Chen, jckuo, vkoul, neil.armstrong, thierry.reding
Cc: linux-phy, linux-tegra, linux-kernel, waynec, wtsai
In-Reply-To: <20260304102649.3670783-1-weichengc@nvidia.com>
On 04/03/2026 10:26, Wei-Cheng Chen wrote:
> From: Wayne Chang <waynec@nvidia.com>
>
> 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.
>
> Fix the calibration by reading per-pad values from the appropriate fuse
> registers. For SoCs that do not support per-pad termination, replicate
> pad 0's value to all pads to maintain existing behavior.
>
> Add a has_per_pad_term flag to the SoC data to indicate whether per-pad
> termination values are available in FUSE_USB_CALIB_EXT_0.
>
> Fixes: 1ef535c6ba8e ("phy: tegra: xusb: Add Tegra194 support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Wayne Chang <waynec@nvidia.com>
> Signed-off-by: Wei-Cheng Chen <weichengc@nvidia.com>
> ---
> drivers/phy/tegra/xusb-tegra186.c | 33 ++++++++++++++++++++++++-------
> drivers/phy/tegra/xusb.h | 1 +
> 2 files changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/phy/tegra/xusb-tegra186.c b/drivers/phy/tegra/xusb-tegra186.c
> index bec9616c4a2..4452e73fb82 100644
> --- a/drivers/phy/tegra/xusb-tegra186.c
> +++ b/drivers/phy/tegra/xusb-tegra186.c
> @@ -20,8 +20,8 @@
> /* FUSE USB_CALIB registers */
> #define HS_CURR_LEVEL_PADX_SHIFT(x) ((x) ? (11 + (x - 1) * 6) : 0)
> #define HS_CURR_LEVEL_PAD_MASK 0x3f
> -#define HS_TERM_RANGE_ADJ_SHIFT 7
> -#define HS_TERM_RANGE_ADJ_MASK 0xf
> +#define HS_TERM_RANGE_ADJ_PADX_SHIFT(x) ((x) ? (5 + (x - 1) * 4) : 7)
> +#define HS_TERM_RANGE_ADJ_PAD_MASK 0xf
> #define HS_SQUELCH_SHIFT 29
> #define HS_SQUELCH_MASK 0x7
>
> @@ -253,7 +253,7 @@
> struct tegra_xusb_fuse_calibration {
> u32 *hs_curr_level;
> u32 hs_squelch;
> - u32 hs_term_range_adj;
> + u32 *hs_term_range_adj;
> u32 rpd_ctrl;
> };
>
> @@ -930,7 +930,7 @@ static int tegra186_utmi_phy_power_on(struct phy *phy)
>
> value = padctl_readl(padctl, XUSB_PADCTL_USB2_OTG_PADX_CTL1(index));
> value &= ~TERM_RANGE_ADJ(~0);
> - value |= TERM_RANGE_ADJ(priv->calib.hs_term_range_adj);
> + value |= TERM_RANGE_ADJ(priv->calib.hs_term_range_adj[index]);
> value &= ~RPD_CTRL(~0);
> value |= RPD_CTRL(priv->calib.rpd_ctrl);
> padctl_writel(padctl, value, XUSB_PADCTL_USB2_OTG_PADX_CTL1(index));
> @@ -1464,17 +1464,23 @@ static const char * const tegra186_usb3_functions[] = {
> static int
> tegra186_xusb_read_fuse_calibration(struct tegra186_xusb_padctl *padctl)
> {
> + const struct tegra_xusb_padctl_soc *soc = padctl->base.soc;
> struct device *dev = padctl->base.dev;
> unsigned int i, count;
> u32 value, *level;
> + u32 *hs_term_range_adj;
> int err;
>
> - count = padctl->base.soc->ports.usb2.count;
> + count = soc->ports.usb2.count;
>
> level = devm_kcalloc(dev, count, sizeof(u32), GFP_KERNEL);
> if (!level)
> return -ENOMEM;
>
> + hs_term_range_adj = devm_kcalloc(dev, count, sizeof(u32), GFP_KERNEL);
> + if (!hs_term_range_adj)
> + return -ENOMEM;
> +
> err = tegra_fuse_readl(TEGRA_FUSE_SKU_CALIB_0, &value);
> if (err)
> return dev_err_probe(dev, err,
> @@ -1490,8 +1496,8 @@ tegra186_xusb_read_fuse_calibration(struct tegra186_xusb_padctl *padctl)
>
> padctl->calib.hs_squelch = (value >> HS_SQUELCH_SHIFT) &
> HS_SQUELCH_MASK;
> - padctl->calib.hs_term_range_adj = (value >> HS_TERM_RANGE_ADJ_SHIFT) &
> - HS_TERM_RANGE_ADJ_MASK;
> + hs_term_range_adj[0] = (value >> HS_TERM_RANGE_ADJ_PADX_SHIFT(0)) &
> + HS_TERM_RANGE_ADJ_PAD_MASK;
>
> err = tegra_fuse_readl(TEGRA_FUSE_USB_CALIB_EXT_0, &value);
> if (err) {
> @@ -1503,6 +1509,17 @@ tegra186_xusb_read_fuse_calibration(struct tegra186_xusb_padctl *padctl)
>
> padctl->calib.rpd_ctrl = (value >> RPD_CTRL_SHIFT) & RPD_CTRL_MASK;
>
> + for (i = 1; i < count; i++) {
> + if (soc->has_per_pad_term)
> + hs_term_range_adj[i] =
> + (value >> HS_TERM_RANGE_ADJ_PADX_SHIFT(i)) &
> + HS_TERM_RANGE_ADJ_PAD_MASK;
> + else
> + hs_term_range_adj[i] = hs_term_range_adj[0];
> + }
> +
> + padctl->calib.hs_term_range_adj = hs_term_range_adj;
> +
> return 0;
> }
>
> @@ -1708,6 +1725,7 @@ const struct tegra_xusb_padctl_soc tegra194_xusb_padctl_soc = {
> .num_supplies = ARRAY_SIZE(tegra194_xusb_padctl_supply_names),
> .supports_gen2 = true,
> .poll_trk_completed = true,
> + .has_per_pad_term = true,
> };
> EXPORT_SYMBOL_GPL(tegra194_xusb_padctl_soc);
>
> @@ -1732,6 +1750,7 @@ const struct tegra_xusb_padctl_soc tegra234_xusb_padctl_soc = {
> .trk_hw_mode = false,
> .trk_update_on_idle = true,
> .supports_lp_cfg_en = true,
> + .has_per_pad_term = true,
> };
> EXPORT_SYMBOL_GPL(tegra234_xusb_padctl_soc);
> #endif
> diff --git a/drivers/phy/tegra/xusb.h b/drivers/phy/tegra/xusb.h
> index d2b5f956513..810b410672f 100644
> --- a/drivers/phy/tegra/xusb.h
> +++ b/drivers/phy/tegra/xusb.h
> @@ -436,6 +436,7 @@ struct tegra_xusb_padctl_soc {
> bool trk_hw_mode;
> bool trk_update_on_idle;
> bool supports_lp_cfg_en;
> + bool has_per_pad_term;
> };
>
> struct tegra_xusb_padctl {
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Thanks
Jon
--
nvpublic
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 6/6] phy: tegra: xusb: Move T186 .set_mode() to common implementation
From: Jon Hunter @ 2026-03-24 10:16 UTC (permalink / raw)
To: Diogo Ivo, Mathias Nyman, Greg Kroah-Hartman, Thierry Reding,
JC Kuo, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: linux-usb, linux-tegra, linux-kernel, linux-phy, devicetree
In-Reply-To: <20260127-diogo-tegra_phy-v2-6-787b9eed3ed5@tecnico.ulisboa.pt>
On 27/01/2026 15:11, Diogo Ivo wrote:
> Move the Tegra186 PHY .set_mode() callback to a common implementation.
> In order to do this first revert cefc1caee9dd.
This commit message does not seem complete.
Furthermore, I am not sure why we want to revert cefc1caee9dd. We
purposely moved the regulator_enable/disable into
tegra186_xusb_padctl_id_override() because it is tied to setting the
USB2_VBUS_ID. So I would prefer to keep it this way and move the
Tegra210 implementation in the same direction (if possible).
Jon
--
nvpublic
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 6/6] phy: tegra: xusb: Move T186 .set_mode() to common implementation
From: Diogo Ivo @ 2026-03-24 11:31 UTC (permalink / raw)
To: Jon Hunter, Mathias Nyman, Greg Kroah-Hartman, Thierry Reding,
JC Kuo, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: linux-usb, linux-tegra, linux-kernel, linux-phy, devicetree
In-Reply-To: <af04fc85-1ed4-4046-86ee-1ffcec8c44cd@nvidia.com>
On 3/24/26 10:16, Jon Hunter wrote:
>
> On 27/01/2026 15:11, Diogo Ivo wrote:
>> Move the Tegra186 PHY .set_mode() callback to a common implementation.
>> In order to do this first revert cefc1caee9dd.
>
> This commit message does not seem complete.
How so? It is succint but it states exactly what the commit does. It
reverts cefc1caee9dd and changes T186 to the common implementation
prepared in the previous patch.
> Furthermore, I am not sure why we want to revert cefc1caee9dd. We
> purposely moved the regulator_enable/disable into
> tegra186_xusb_padctl_id_override() because it is tied to setting the
> USB2_VBUS_ID. So I would prefer to keep it this way and move the
> Tegra210 implementation in the same direction (if possible).
I don't agree that this is the best solution.
We really benefit from a common implementation for the two platforms, not
only because of duplicate code but more importantly because without it
whenever a bug is found and fixed on either platform it most likely will
not be fixed on the other one. Case in point, cefc1caee9dd fixed a bug
on T186 but not the same bug on T210 (which then led to this series) since
the implementation was not shared among them. Were it the case that they
shared the implementation the fix would have come "free" for T210.
This will keep happening for as long as we have duplicate implementations,
which becomes more relevant since there is a severe lack of testing in
older Tegra platforms. I also thought about making the id_override()
implementation shared between T186 and T210 but that would be take more
changes since register definitions would need to be moved somewhere
else too.
Diogo
> Jon
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/6] usb: xhci: tegra: Remove redundant mutex when setting phy mode
From: Thierry Reding @ 2026-03-24 11:48 UTC (permalink / raw)
To: Diogo Ivo
Cc: Mathias Nyman, Greg Kroah-Hartman, Thierry Reding,
Jonathan Hunter, JC Kuo, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
linux-usb, linux-tegra, linux-kernel, linux-phy, devicetree
In-Reply-To: <20260127-diogo-tegra_phy-v2-2-787b9eed3ed5@tecnico.ulisboa.pt>
[-- Attachment #1.1: Type: text/plain, Size: 1227 bytes --]
On Tue, Jan 27, 2026 at 03:11:48PM +0000, Diogo Ivo wrote:
> As the PHY subsystem already synchronizes concurrent accesses to a PHY
> instance with a core-internal mutex remove the driver specific mutex
> synchronization.
>
> Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
> ---
> v1->v2:
> - New patch
> ---
> drivers/usb/host/xhci-tegra.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
> index 8b492871d21d..927861ca14f2 100644
> --- a/drivers/usb/host/xhci-tegra.c
> +++ b/drivers/usb/host/xhci-tegra.c
> @@ -1357,15 +1357,11 @@ static void tegra_xhci_id_work(struct work_struct *work)
>
> dev_dbg(tegra->dev, "host mode %s\n", str_on_off(tegra->host_mode));
>
> - mutex_lock(&tegra->lock);
> -
> if (tegra->host_mode)
> phy_set_mode_ext(phy, PHY_MODE_USB_OTG, USB_ROLE_HOST);
> else
> phy_set_mode_ext(phy, PHY_MODE_USB_OTG, USB_ROLE_NONE);
>
> - mutex_unlock(&tegra->lock);
> -
It looks to me like the mutex here is trying to protect against
tegra->host_mode changing while we're setting a different mode. That
doesn't seem to be taken care of by the PHY internal mutex.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: renesas: rcar-gen3-usb2: Simplify ID/VBUS detection logic
From: Prabhakar @ 2026-03-24 12:16 UTC (permalink / raw)
To: Yoshihiro Shimoda, Vinod Koul, Neil Armstrong, Geert Uytterhoeven,
Magnus Damm, Pavel Machek
Cc: linux-renesas-soc, linux-phy, linux-kernel, Prabhakar, Biju Das,
Fabrizio Castro, Lad Prabhakar
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Read the USB2_ADPCTRL register once in rcar_gen3_check_id() and reuse
the value instead of performing multiple MMIO reads.
Simplify the return logic by comparing the IDDIG and VBUSVALID bits
directly. This preserves the existing behaviour while improving code
clarity and avoiding redundant register accesses.
Reported-by: Pavel Machek <pavel@nabladev.com>
Closes: https://lore.kernel.org/all/acJV-Xq-2uq_JFMn@duo.ucw.cz/
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
Note, patch applies on top of next-20260323.
---
drivers/phy/renesas/phy-rcar-gen3-usb2.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 79e820e2fe55..74d7561dbf79 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -314,13 +314,14 @@ static void rcar_gen3_init_from_a_peri_to_a_host(struct rcar_gen3_chan *ch)
static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
{
if (ch->phy_data->vblvl_ctrl) {
+ u32 val = readl(ch->base + USB2_ADPCTRL);
bool vbus_valid;
bool device;
- device = !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_IDDIG);
- vbus_valid = !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_VBUSVALID);
+ device = !!(val & USB2_ADPCTRL_IDDIG);
+ vbus_valid = !!(val & USB2_ADPCTRL_VBUSVALID);
- return vbus_valid ? device : !device;
+ return device == vbus_valid;
}
if (!ch->uses_otg_pins)
--
2.53.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH] phy: renesas: rcar-gen3-usb2: Simplify ID/VBUS detection logic
From: Lad, Prabhakar @ 2026-03-24 12:18 UTC (permalink / raw)
To: Yoshihiro Shimoda, Vinod Koul, Neil Armstrong, Geert Uytterhoeven,
Magnus Damm, Pavel Machek
Cc: linux-renesas-soc, linux-phy, linux-kernel, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260324121608.3444943-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi All,
On Tue, Mar 24, 2026 at 12:16 PM Prabhakar <prabhakar.csengg@gmail.com> wrote:
>
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Read the USB2_ADPCTRL register once in rcar_gen3_check_id() and reuse
> the value instead of performing multiple MMIO reads.
>
> Simplify the return logic by comparing the IDDIG and VBUSVALID bits
> directly. This preserves the existing behaviour while improving code
> clarity and avoiding redundant register accesses.
>
> Reported-by: Pavel Machek <pavel@nabladev.com>
> Closes: https://lore.kernel.org/all/acJV-Xq-2uq_JFMn@duo.ucw.cz/
My bad, wrong link, https://lore.kernel.org/all/acJVCOdlchLiSe5n@duo.ucw.cz/
Cheers,
Prabhakar
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2 2/6] usb: xhci: tegra: Remove redundant mutex when setting phy mode
From: Diogo Ivo @ 2026-03-24 12:28 UTC (permalink / raw)
To: Thierry Reding
Cc: Mathias Nyman, Greg Kroah-Hartman, Thierry Reding,
Jonathan Hunter, JC Kuo, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
linux-usb, linux-tegra, linux-kernel, linux-phy, devicetree
In-Reply-To: <acJ50sQraVmy4zXs@orome>
On 3/24/26 11:48, Thierry Reding wrote:
> On Tue, Jan 27, 2026 at 03:11:48PM +0000, Diogo Ivo wrote:
>> As the PHY subsystem already synchronizes concurrent accesses to a PHY
>> instance with a core-internal mutex remove the driver specific mutex
>> synchronization.
>>
>> Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
>> ---
>> v1->v2:
>> - New patch
>> ---
>> drivers/usb/host/xhci-tegra.c | 4 ----
>> 1 file changed, 4 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
>> index 8b492871d21d..927861ca14f2 100644
>> --- a/drivers/usb/host/xhci-tegra.c
>> +++ b/drivers/usb/host/xhci-tegra.c
>> @@ -1357,15 +1357,11 @@ static void tegra_xhci_id_work(struct work_struct *work)
>>
>> dev_dbg(tegra->dev, "host mode %s\n", str_on_off(tegra->host_mode));
>>
>> - mutex_lock(&tegra->lock);
>> -
>> if (tegra->host_mode)
>> phy_set_mode_ext(phy, PHY_MODE_USB_OTG, USB_ROLE_HOST);
>> else
>> phy_set_mode_ext(phy, PHY_MODE_USB_OTG, USB_ROLE_NONE);
>>
>> - mutex_unlock(&tegra->lock);
>> -
>
> It looks to me like the mutex here is trying to protect against
> tegra->host_mode changing while we're setting a different mode. That
> doesn't seem to be taken care of by the PHY internal mutex.
I'm not sure I understand your point. Do you mean guarding against
tegra->host_mode changing in tegra_xhci_id_notify()? If so I don't see
how it would guard against that.
Diogo
> Thierry
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 2/7] dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel compatible
From: Nora Schiffer @ 2026-03-24 12:29 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1774354734.git.nora.schiffer@ew.tq-group.com>
The J722S gmii-sel is mostly identical to the AM64's, but additionally
supports SGMII. The AM64 compatible ti,am654-phy-gmii-sel is used as a
fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/phy/ti,phy-gmii-sel.yaml | 24 ++++++++++++-------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
index be41b4547ec6d..6e12a75100eb8 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
@@ -47,15 +47,21 @@ description: |
properties:
compatible:
- enum:
- - ti,am3352-phy-gmii-sel
- - ti,dra7xx-phy-gmii-sel
- - ti,am43xx-phy-gmii-sel
- - ti,dm814-phy-gmii-sel
- - ti,am654-phy-gmii-sel
- - ti,j7200-cpsw5g-phy-gmii-sel
- - ti,j721e-cpsw9g-phy-gmii-sel
- - ti,j784s4-cpsw9g-phy-gmii-sel
+ oneOf:
+ - items:
+ - enum:
+ - ti,am3352-phy-gmii-sel
+ - ti,dra7xx-phy-gmii-sel
+ - ti,am43xx-phy-gmii-sel
+ - ti,dm814-phy-gmii-sel
+ - ti,am654-phy-gmii-sel
+ - ti,j7200-cpsw5g-phy-gmii-sel
+ - ti,j721e-cpsw9g-phy-gmii-sel
+ - ti,j784s4-cpsw9g-phy-gmii-sel
+ - items:
+ - enum:
+ - ti,j722s-phy-gmii-sel
+ - const: ti,am654-phy-gmii-sel
reg:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 0/7] J722S SGMII support
From: Nora Schiffer @ 2026-03-24 12:29 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
The J722S CPSW and SERDES are very similar to the variants found on the
AM64, but they additionally support SGMII. Introduce new compatible
strings for the J722S to add this support to the drivers.
This is a prerequisite for the Single-Pair Ethernet interface of the
TQ-Systems MBa67xx baseboard for the TQMa67xx SoM, which will be
submitted separately.
v2:
- Keep support for the AM64 compatible strings as a fallback, adjust commit
messages (patches 1-3 and 7)
- No changes to patches 4-6
Nora Schiffer (7):
dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel
compatible
dt-bindings: net: ti: k3-am654-cpsw-nuss: Add ti,j722s-cpsw-nuss
compatible
phy: ti: phy-j721e-wiz: add support for J722S SoC family
phy: ti: gmii-sel: add support for J722S SoC family
net: ethernet: ti: am65-cpsw: add support for J722S SoC family
arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel
and CPSW3G
.../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 20 ++++++++++------
.../bindings/phy/ti,phy-gmii-sel.yaml | 24 ++++++++++++-------
.../bindings/phy/ti,phy-j721e-wiz.yaml | 20 ++++++++++------
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 12 ++++++++--
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 8 +++++++
drivers/phy/ti/phy-gmii-sel.c | 11 +++++++++
drivers/phy/ti/phy-j721e-wiz.c | 24 +++++++++++++++++++
7 files changed, 94 insertions(+), 25 deletions(-)
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v2 3/7] dt-bindings: net: ti: k3-am654-cpsw-nuss: Add ti,j722s-cpsw-nuss compatible
From: Nora Schiffer @ 2026-03-24 12:29 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1774354734.git.nora.schiffer@ew.tq-group.com>
The J722S CPSW3G is mostly identical to the AM64's, but additionally
supports SGMII. The AM64 compatible ti,am642-cpsw-nuss is used as a
fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 20 ++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
index a959c1d7e643a..70d25f5ff1cfe 100644
--- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
+++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
@@ -53,13 +53,19 @@ properties:
"#size-cells": true
compatible:
- enum:
- - ti,am642-cpsw-nuss
- - ti,am654-cpsw-nuss
- - ti,j7200-cpswxg-nuss
- - ti,j721e-cpsw-nuss
- - ti,j721e-cpswxg-nuss
- - ti,j784s4-cpswxg-nuss
+ oneOf:
+ - items:
+ - enum:
+ - ti,am642-cpsw-nuss
+ - ti,am654-cpsw-nuss
+ - ti,j7200-cpswxg-nuss
+ - ti,j721e-cpsw-nuss
+ - ti,j721e-cpswxg-nuss
+ - ti,j784s4-cpswxg-nuss
+ - items:
+ - enum:
+ - ti,j722s-cpsw-nuss
+ - const: ti,am642-cpsw-nuss
reg:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 4/7] phy: ti: phy-j721e-wiz: add support for J722S SoC family
From: Nora Schiffer @ 2026-03-24 12:29 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1774354734.git.nora.schiffer@ew.tq-group.com>
The J722S WIZ is mostly identical to the AM64's, but additionally supports
SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/phy/ti/phy-j721e-wiz.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 6b584706b913a..7531a8a049123 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -331,6 +331,7 @@ enum wiz_type {
J721E_WIZ_16G,
J721E_WIZ_10G, /* Also for J7200 SR1.0 */
AM64_WIZ_10G,
+ J722S_WIZ_10G,
J7200_WIZ_10G, /* J7200 SR2.0 */
J784S4_WIZ_10G,
J721S2_WIZ_10G,
@@ -1020,6 +1021,7 @@ static void wiz_clock_cleanup(struct wiz *wiz, struct device_node *node)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
case J784S4_WIZ_10G:
case J721S2_WIZ_10G:
@@ -1089,6 +1091,7 @@ static void wiz_clock_init(struct wiz *wiz)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
switch (rate) {
case REF_CLK_100MHZ:
@@ -1158,6 +1161,7 @@ static int wiz_clock_probe(struct wiz *wiz, struct device_node *node)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
case J784S4_WIZ_10G:
case J721S2_WIZ_10G:
@@ -1246,6 +1250,14 @@ static int wiz_phy_fullrt_div(struct wiz *wiz, int lane)
if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
return regmap_field_write(wiz->p0_fullrt_div[lane], 0x2);
break;
+
+ case J722S_WIZ_10G:
+ if (wiz->lane_phy_type[lane] == PHY_TYPE_PCIE)
+ return regmap_field_write(wiz->p0_fullrt_div[lane], 0x1);
+ if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
+ return regmap_field_write(wiz->p0_fullrt_div[lane], 0x2);
+ break;
+
default:
return 0;
}
@@ -1350,6 +1362,15 @@ static struct wiz_data am64_10g_data = {
.clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
};
+static struct wiz_data j722s_10g_data = {
+ .type = J722S_WIZ_10G,
+ .pll0_refclk_mux_sel = &pll0_refclk_mux_sel,
+ .pll1_refclk_mux_sel = &pll1_refclk_mux_sel,
+ .refclk_dig_sel = &refclk_dig_sel_10g,
+ .clk_mux_sel = clk_mux_sel_10g,
+ .clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
+};
+
static struct wiz_data j7200_pg2_10g_data = {
.type = J7200_WIZ_10G,
.pll0_refclk_mux_sel = &sup_pll0_refclk_mux_sel,
@@ -1389,6 +1410,9 @@ static const struct of_device_id wiz_id_table[] = {
{
.compatible = "ti,am64-wiz-10g", .data = &am64_10g_data,
},
+ {
+ .compatible = "ti,j722s-wiz-10g", .data = &j722s_10g_data,
+ },
{
.compatible = "ti,j7200-wiz-10g", .data = &j7200_pg2_10g_data,
},
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 1/7] dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
From: Nora Schiffer @ 2026-03-24 12:29 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1774354734.git.nora.schiffer@ew.tq-group.com>
The J722S WIZ is mostly identical to the AM64's, but additionally supports
SGMII. The AM64 compatible ti,am64-wiz-10g is used as a fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/phy/ti,phy-j721e-wiz.yaml | 20 ++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
index 3f16ff14484d2..283e3eedc0f31 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
@@ -12,13 +12,19 @@ maintainers:
properties:
compatible:
- enum:
- - ti,j721e-wiz-16g
- - ti,j721e-wiz-10g
- - ti,j721s2-wiz-10g
- - ti,am64-wiz-10g
- - ti,j7200-wiz-10g
- - ti,j784s4-wiz-10g
+ oneOf:
+ - items:
+ - enum:
+ - ti,j721e-wiz-16g
+ - ti,j721e-wiz-10g
+ - ti,j721s2-wiz-10g
+ - ti,am64-wiz-10g
+ - ti,j7200-wiz-10g
+ - ti,j784s4-wiz-10g
+ - items:
+ - enum:
+ - ti,j722s-wiz-10g
+ - const: ti,am64-wiz-10g
power-domains:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 6/7] net: ethernet: ti: am65-cpsw: add support for J722S SoC family
From: Nora Schiffer @ 2026-03-24 12:29 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1774354734.git.nora.schiffer@ew.tq-group.com>
The J722S CPSW3G is mostly identical to the AM64's, but additionally
supports SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index d9400599e80a4..7ac75fc8cdcf4 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -3468,6 +3468,13 @@ static const struct am65_cpsw_pdata am64x_cpswxg_pdata = {
.fdqring_mode = K3_RINGACC_RING_MODE_RING,
};
+static const struct am65_cpsw_pdata j722s_cpswxg_pdata = {
+ .quirks = AM64_CPSW_QUIRK_DMA_RX_TDOWN_IRQ,
+ .ale_dev_id = "am64-cpswxg",
+ .fdqring_mode = K3_RINGACC_RING_MODE_RING,
+ .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
+};
+
static const struct am65_cpsw_pdata j7200_cpswxg_pdata = {
.quirks = 0,
.ale_dev_id = "am64-cpswxg",
@@ -3495,6 +3502,7 @@ static const struct of_device_id am65_cpsw_nuss_of_mtable[] = {
{ .compatible = "ti,am654-cpsw-nuss", .data = &am65x_sr1_0},
{ .compatible = "ti,j721e-cpsw-nuss", .data = &j721e_pdata},
{ .compatible = "ti,am642-cpsw-nuss", .data = &am64x_cpswxg_pdata},
+ { .compatible = "ti,j722s-cpsw-nuss", .data = &j722s_cpswxg_pdata},
{ .compatible = "ti,j7200-cpswxg-nuss", .data = &j7200_cpswxg_pdata},
{ .compatible = "ti,j721e-cpswxg-nuss", .data = &j721e_cpswxg_pdata},
{ .compatible = "ti,j784s4-cpswxg-nuss", .data = &j784s4_cpswxg_pdata},
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 5/7] phy: ti: gmii-sel: add support for J722S SoC family
From: Nora Schiffer @ 2026-03-24 12:29 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1774354734.git.nora.schiffer@ew.tq-group.com>
The J722S gmii-sel is mostly identical to the AM64's, but additionally
supports SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/phy/ti/phy-gmii-sel.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c
index 6213c2b6005a5..4e242b1892334 100644
--- a/drivers/phy/ti/phy-gmii-sel.c
+++ b/drivers/phy/ti/phy-gmii-sel.c
@@ -251,6 +251,13 @@ struct phy_gmii_sel_soc_data phy_gmii_sel_soc_am654 = {
.regfields = phy_gmii_sel_fields_am654,
};
+static const
+struct phy_gmii_sel_soc_data phy_gmii_sel_soc_j722s = {
+ .use_of_data = true,
+ .regfields = phy_gmii_sel_fields_am654,
+ .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
+};
+
static const
struct phy_gmii_sel_soc_data phy_gmii_sel_cpsw5g_soc_j7200 = {
.use_of_data = true,
@@ -307,6 +314,10 @@ static const struct of_device_id phy_gmii_sel_id_table[] = {
.compatible = "ti,am654-phy-gmii-sel",
.data = &phy_gmii_sel_soc_am654,
},
+ {
+ .compatible = "ti,j722s-phy-gmii-sel",
+ .data = &phy_gmii_sel_soc_j722s,
+ },
{
.compatible = "ti,j7200-cpsw5g-phy-gmii-sel",
.data = &phy_gmii_sel_cpsw5g_soc_j7200,
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v2 7/7] arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel and CPSW3G
From: Nora Schiffer @ 2026-03-24 12:29 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo
Cc: Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1774354734.git.nora.schiffer@ew.tq-group.com>
Update WIZ, gmii-sel and CPSW3G to use the J722S-specific compatible
strings, enabling SGMII support. The fallback compatibles preserve
compatibility of the updated Device Trees with older kernels.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
index 9ee5d0c8ffd1e..70f430aa3a944 100644
--- a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
@@ -18,7 +18,7 @@ serdes_refclk: clk-0 {
&cbass_main {
serdes_wiz0: phy@f000000 {
- compatible = "ti,am64-wiz-10g";
+ compatible = "ti,j722s-wiz-10g", "ti,am64-wiz-10g";
ranges = <0x0f000000 0x0 0x0f000000 0x00010000>;
#address-cells = <1>;
#size-cells = <1>;
@@ -56,7 +56,7 @@ serdes0: serdes@f000000 {
};
serdes_wiz1: phy@f010000 {
- compatible = "ti,am64-wiz-10g";
+ compatible = "ti,j722s-wiz-10g", "ti,am64-wiz-10g";
ranges = <0x0f010000 0x0 0x0f010000 0x00010000>;
#address-cells = <1>;
#size-cells = <1>;
@@ -451,6 +451,14 @@ pcie0_ctrl: pcie0-ctrl@4070 {
};
};
+&cpsw3g {
+ compatible = "ti,j722s-cpsw-nuss", "ti,am642-cpsw-nuss";
+};
+
+&phy_gmii_sel {
+ compatible = "ti,j722s-phy-gmii-sel", "ti,am654-phy-gmii-sel";
+};
+
&oc_sram {
reg = <0x00 0x70000000 0x00 0x40000>;
ranges = <0x00 0x00 0x70000000 0x40000>;
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v5 2/4] dt-bindings: usb: dwc2: Add support for Canaan K230 SoC
From: Jiayu Du @ 2026-03-24 13:03 UTC (permalink / raw)
To: robh
Cc: neil.armstrong, robh, krzk+dt, pjw, palmer, aou, alex, linux-phy,
linux-usb, devicetree, linux-riscv, linux-kernel
In-Reply-To: <20260121145526.14672-3-jiayu.riscv@isrc.iscas.ac.cn>
On Wed, Jan 21, 2026 at 10:55:23PM +0800, Jiayu Du wrote:
> Add 'canaan,k230-usb' compatible string with 'snps,dwc2' as fallback
> for the DWC2 IP which is used by Canaan K230.
>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Jiayu Du <jiayu.riscv@isrc.iscas.ac.cn>
Hi Rob,
Will this patch2 be applied for next?
Best regards,
Jiayu Du
> ---
> Documentation/devicetree/bindings/usb/dwc2.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml
> index 6c3a10991b8b..352487c6392a 100644
> --- a/Documentation/devicetree/bindings/usb/dwc2.yaml
> +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml
> @@ -17,6 +17,9 @@ properties:
> compatible:
> oneOf:
> - const: brcm,bcm2835-usb
> + - items:
> + - const: canaan,k230-usb
> + - const: snps,dwc2
> - const: hisilicon,hi6220-usb
> - const: ingenic,jz4775-otg
> - const: ingenic,jz4780-otg
> --
> 2.52.0
>
>
> --
> linux-phy mailing list
> linux-phy@lists.infradead.org
> https://lists.infradead.org/mailman/listinfo/linux-phy
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: renesas: rcar-gen3-usb2: Simplify ID/VBUS detection logic
From: Geert Uytterhoeven @ 2026-03-24 13:05 UTC (permalink / raw)
To: Prabhakar
Cc: Yoshihiro Shimoda, Vinod Koul, Neil Armstrong, Magnus Damm,
Pavel Machek, linux-renesas-soc, linux-phy, linux-kernel,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260324121608.3444943-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar,
On Tue, 24 Mar 2026 at 13:16, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Read the USB2_ADPCTRL register once in rcar_gen3_check_id() and reuse
> the value instead of performing multiple MMIO reads.
>
> Simplify the return logic by comparing the IDDIG and VBUSVALID bits
> directly. This preserves the existing behaviour while improving code
> clarity and avoiding redundant register accesses.
>
> Reported-by: Pavel Machek <pavel@nabladev.com>
> Closes: https://lore.kernel.org/all/acJV-Xq-2uq_JFMn@duo.ucw.cz/
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Thanks for your patch!
> --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> @@ -314,13 +314,14 @@ static void rcar_gen3_init_from_a_peri_to_a_host(struct rcar_gen3_chan *ch)
> static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
> {
> if (ch->phy_data->vblvl_ctrl) {
> + u32 val = readl(ch->base + USB2_ADPCTRL);
> bool vbus_valid;
> bool device;
>
> - device = !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_IDDIG);
> - vbus_valid = !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_VBUSVALID);
> + device = !!(val & USB2_ADPCTRL_IDDIG);
> + vbus_valid = !!(val & USB2_ADPCTRL_VBUSVALID);
Perhaps combine variable declarations and assignments?
The "!!" is not needed when assigning to a bool.
>
> - return vbus_valid ? device : !device;
> + return device == vbus_valid;
> }
>
> if (!ch->uses_otg_pins)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox