* Re: [PATCH 4/8] phy: zynqmp: Calibrate ILL if necessary
From: Sean Anderson @ 2026-02-10 16:42 UTC (permalink / raw)
To: Pandey, Radhey Shyam, Laurent Pinchart, Vinod Koul,
linux-phy@lists.infradead.org
Cc: Krzysztof Wilczyński, Lorenzo Pieralisi,
linux-kernel@vger.kernel.org, Simek, Michal,
linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
Neil Armstrong, Rob Herring, Havalige, Thippeswamy,
Manivannan Sadhasivam, Bjorn Helgaas
In-Reply-To: <CY1PR12MB9697F67210064132883611A8B762A@CY1PR12MB9697.namprd12.prod.outlook.com>
On 2/10/26 11:04, Pandey, Radhey Shyam wrote:
> [Public]
>
>> -----Original Message-----
>> From: Sean Anderson <sean.anderson@linux.dev>
>> Sent: Tuesday, February 3, 2026 5:51 AM
>> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>; Vinod Koul
>> <vkoul@kernel.org>; linux-phy@lists.infradead.org
>> Cc: Krzysztof Wilczyński <kwilczynski@kernel.org>; Lorenzo Pieralisi
>> <lpieralisi@kernel.org>; Pandey, Radhey Shyam
>> <radhey.shyam.pandey@amd.com>; linux-kernel@vger.kernel.org; Simek, Michal
>> <michal.simek@amd.com>; linux-arm-kernel@lists.infradead.org; linux-
>> pci@vger.kernel.org; Neil Armstrong <neil.armstrong@linaro.org>; Rob Herring
>> <robh@kernel.org>; Havalige, Thippeswamy <thippeswamy.havalige@amd.com>;
>> Manivannan Sadhasivam <mani@kernel.org>; Bjorn Helgaas
>> <bhelgaas@google.com>; Sean Anderson <sean.anderson@linux.dev>
>> Subject: [PATCH 4/8] phy: zynqmp: Calibrate ILL if necessary
>>
>> init_serdes in psu_init_gpl is supposed to calibrate the ILL. However, this
>> may fail if the reference clock is not running, such as if the clock needs
>> to be configured on boot. To work around this, add support for ILL
>> calibration in U-Boot. If the ILL is already calibrated (any non-zero
>> value) we skip calibration.
>>
>> The algorithm is substantially the same as serdes_illcalib [1], but it has
>> been updated for readability (and to remove all the "if (lane0_active)"
>> conditions). Due to the amount of register fields, many of which are
>> undocumented (especially the chicken bits), I have mostly used defines only
>> for the register names. There are certainly areas where register writes are
>> superfluous, but I have left these in order to minimize deviation from the
>> procedure in serdes_illcalib.
>
> Please consider splitting the patch in introducing calibrate ILL functions
> and then subsequently using them.
OK
> How did you validate the changes? functional testing is one part
> but I think better to match register configuration done in psu_init vs
> this series?
I've done this in the past, but I didn't do so with this version of the
driver. I'll make sure to do this comparison for v2. FWIW the ILL
values achieved through this procedure are fairly close to the values I
got from the firmware.
> Have we tried running on multiple designs having
> different GT lane and protocol combinations .
Currently tested with SATA on GTR2 (on [1]) and PCIe on GTR0/1 (custom
design). I've also tested SGMII and DP on the other lanes (although not
USB as mentioned in the cover letter). I'd definitely appreciate if you
(or anyone else) could test on some other boards.
[1] https://developer.seco.com/hardware/product/computer-on-modules/smarc-modules/som-smarc-zu-b71/
> There are multiple magic numbers. Consider renaming it to
> meaningful defines.
Some of the fields have very long names. E.g. L0_TX_ANA_TM_3 has two
fields that we set: TX_serializer_enable and
force_TX_serializer_enabled. Setting it would look like
xpsgtr_write_lanes(gtr_dev, lanes, L0_TX_ANA_TM_3,
L0_TX_ANA_TM_3_TX_SERIALIZER_ENABLE |
L0_TX_ANA_TM_3_FORCE_TX_SERIALIZER_ENABLE);
and there's really no way to get that under 80 characters. This is
probably the area where I could most improve things. But I'm not a fan
of tripling the line count since I think it makes it harder to follow
the flow of the initialization.
Other fields have poor documentation. E.g. L0_TM_IQ_ILL8 has a single
field ill_bypass_iq_polytrim_val documented as "IQ ILL polytrim bypass
value." I have no idea what this field does or why it needs to be set to
0xf3 so I can't really define a meaningful constant for it.
Lastly, some fields are not documented at all, notably UPHY_SPARE0.
In these latter two cases, I have not guessed at the semantics, but I'd
more than welcome any additional info.
>>
>> [1] Example implementation; xpsgtr_phy_illcalib coresponds to
>> serdes_illcalib_pcie_gen1:
>> https://source.denx.de/u-boot/u-boot/-/blob/v2026.01/board/xilinx/zynqmp/zynqmp-
>> zcu208-revA/psu_init_gpl.c?ref_type=tags#L710
>>
>> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
>> ---
>>
>> drivers/phy/xilinx/phy-zynqmp.c | 421 +++++++++++++++++++++++++++++++-
>> 1 file changed, 420 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
>> index 152af1702bbd..854b0ea04648 100644
>> --- a/drivers/phy/xilinx/phy-zynqmp.c
>> +++ b/drivers/phy/xilinx/phy-zynqmp.c
>> @@ -12,6 +12,7 @@
>> * PCIe should also work but that is experimental as of now.
>> */
>>
>> +#include <linux/bitfield.h>
>> #include <linux/clk.h>
>> #include <linux/debugfs.h>
>> #include <linux/delay.h>
>> @@ -31,6 +32,7 @@
>> */
>>
>> /* TX De-emphasis parameters */
>> +#define L0_TX_ANA_TM_3 0x000c
>> #define L0_TX_ANA_TM_18 0x0048
>> #define L0_TX_ANA_TM_118 0x01d8
>> #define L0_TX_ANA_TM_118_FORCE_17_0 BIT(0)
>> @@ -50,16 +52,49 @@
>> #define L0_TXPMD_TM_45_ENABLE_DP_POST2 BIT(5)
>>
>> /* PCS control parameters */
>> +#define L0_TM_ANA_BYP_4 0x1010
>> +#define L0_TM_ANA_BYP_7 0x1018
>> #define L0_TM_DIG_6 0x106c
>> +#define L0_TM_DIG_22 0x10ac
>> #define L0_TM_DIS_DESCRAMBLE_DECODER 0x0f
>> #define L0_TX_DIG_61 0x00f4
>> #define L0_TM_DISABLE_SCRAMBLE_ENCODER 0x0f
>> +#define L0_TM_AUX_0 0x10cc
>> +#define L0_TM_MISC2 0x189c
>> +#define L0_TM_MISC2_ILL_CAL_BYPASS BIT(7)
>> +#define L0_TM_IQ_ILL1 0x18f8
>> +#define L0_TM_IQ_ILL2 0x18fc
>
> #define L0_TM_IQ_ILL3 0x1900
>
> IQ_ILL(n) = 0x18f8 + (n - 1) * 4 ?
>
> Similarly for others (when applicable)?
OK
>> +#define L0_TM_ILL11 0x198c
>> +#define L0_TM_ILL12 0x1990
>> +#define L0_TM_E_ILL1 0x1924
>> +#define L0_TM_E_ILL2 0x1928
>> +#define L0_TM_IQ_ILL3 0x1900
>> +#define L0_TM_E_ILL3 0x192c
>> +#define L0_TM_IQ_ILL7 0x1910
>> +#define L0_TM_E_ILL7 0x193c
>> +#define L0_TM_ILL8 0x1980
>> +#define L0_TM_IQ_ILL8 0x1914
>> +#define L0_TM_IQ_ILL9 0x1918
>> +#define L0_TM_EQ0 0x194c
>> +#define L0_TM_EQ0_EQ_STG2_CTRL_BYP BIT(5)
>> +#define L0_TM_EQ1 0x1950
>> +#define L0_TM_EQ1_EQ_STG2_RL_PROG GENMASK(1, 0)
>> +#define L0_TM_EQ1_EQ_STG2_PREAMP_MODE_VAL BIT(2)
>> +#define L0_TM_E_ILL8 0x1940
>> +#define L0_TM_E_ILL9 0x1944
>> +#define L0_TM_ILL13 0x1994
>> +#define L0_TM_CDR5 0x1c14
>> +#define L0_TM_CDR5_FPHL_FSM_ACC_CYCLES GENMASK(7, 5)
>> +#define L0_TM_CDR5_FFL_PH0_INT_GAIN GENMASK(4, 0)
>> +#define L0_TM_CDR16 0x1c40
>>
>> /* PLL Test Mode register parameters */
>> +#define L0_TM_PLL_DIG_33 0x2084
>> #define L0_TM_PLL_DIG_37 0x2094
>> #define L0_TM_COARSE_CODE_LIMIT 0x10
>>
>> /* PLL SSC step size offsets */
>> +#define L0_PLL_FBDIV_FRAC_3_MSB 0x2360
>> #define L0_PLL_SS_STEPS_0_LSB 0x2368
>> #define L0_PLL_SS_STEPS_1_MSB 0x236c
>> #define L0_PLL_SS_STEP_SIZE_0_LSB 0x2370
>> @@ -69,6 +104,7 @@
>> #define L0_PLL_STATUS_READ_1 0x23e4
>>
>> /* SSC step size parameters */
>> +#define TM_FORCE_EN_FRAC BIT(6)
>> #define STEP_SIZE_0_MASK 0xff
>> #define STEP_SIZE_1_MASK 0xff
>> #define STEP_SIZE_2_MASK 0xff
>> @@ -76,6 +112,7 @@
>> #define STEP_SIZE_SHIFT 8
>> #define FORCE_STEP_SIZE 0x10
>> #define FORCE_STEPS 0x20
>> +#define TM_FORCE_EN BIT(7)
>> #define STEPS_0_MASK 0xff
>> #define STEPS_1_MASK 0x07
>>
>> @@ -84,6 +121,32 @@
>> #define L0_REF_CLK_LCL_SEL BIT(7)
>> #define L0_REF_CLK_SEL_MASK 0x9f
>>
>> +/* Built-in self-test parameters */
>> +#define L0_BIST_CTRL_1 0x3004
>> +#define L0_BIST_CTRL_2 0x3008
>> +#define L0_BIST_RUN_LEN_L 0x300c
>> +#define L0_BIST_ERR_INJ_POINT_L 0x3010
>> +#define L0_BIST_RUNLEN_ERR_INJ_H 0x3014
>> +#define L0_BIST_IDLE_TIME 0x3018
>> +#define L0_BIST_MARKER_L 0x301c
>> +#define L0_BIST_IDLE_CHAR_L 0x3020
>> +#define L0_BIST_MARKER_IDLE_H 0x3024
>> +#define L0_BIST_LOW_PULSE_TIME 0x3028
>> +#define L0_BIST_TOTAL_PULSE_TIME 0x302c
>> +#define L0_BIST_TEST_PAT_1 0x3030
>> +#define L0_BIST_TEST_PAT_2 0x3034
>> +#define L0_BIST_TEST_PAT_3 0x3038
>> +#define L0_BIST_TEST_PAT_4 0x303c
>> +#define L0_BIST_TEST_PAT_MSBS 0x3040
>> +#define L0_BIST_PKT_NUM 0x3044
>> +#define L0_BIST_FRM_IDLE_TIME 0x3048
>> +#define L0_BIST_PKT_CTR_L 0x304c
>> +#define L0_BIST_PKT_CTR_H 0x3050
>> +#define L0_BIST_ERR_CTR_L 0x3054
>> +#define L0_BIST_ERR_CTR_H 0x3058
>> +#define L0_BIST_FILLER_OUT 0x3068
>> +#define L0_BIST_FORCE_MK_RST 0x306c
>> +
>> /* Calibration digital logic parameters */
>> #define L3_TM_CALIB_DIG19 0xec4c
>> #define L3_CALIB_DONE_STATUS 0xef14
>> @@ -139,6 +202,9 @@ static const char *const xpsgtr_icm_str[] = {
>> #define TM_CMN_RST_SET 0x2
>> #define TM_CMN_RST_MASK 0x3
>>
>> +#define LPBK_CTRL0 0x10038
>> +#define LPBK_CTRL1 0x1003c
>> +
>> /* Bus width parameters */
>> #define TX_PROT_BUS_WIDTH 0x10040
>> #define RX_PROT_BUS_WIDTH 0x10044
>> @@ -148,9 +214,13 @@ static const char *const xpsgtr_icm_str[] = {
>> #define PROT_BUS_WIDTH_SHIFT(n) ((n) * 2)
>> #define PROT_BUS_WIDTH_MASK(n) GENMASK((n) * 2 + 1, (n) * 2)
>>
>> +#define UPHY_SPARE0 0X10098
>> +
>> /* Number of GT lanes */
>> #define NUM_LANES 4
>>
>> +#define SIOU_ECO_0 0x1c
>> +
>> /* SIOU SATA control register */
>> #define SATA_CONTROL_OFFSET 0x0100
>>
>> @@ -338,6 +408,33 @@ static void xpsgtr_restore_lane_regs(struct xpsgtr_dev
>> *gtr_dev)
>> gtr_dev->saved_regs[i]);
>> }
>>
>> +static inline void xpsgtr_write_lanes(struct xpsgtr_dev *gtr_dev,
>> + unsigned long *lanes, u32 reg, u32 value)
>> +{
>> + unsigned long lane;
>> +
>> + for_each_set_bit(lane, lanes, NUM_LANES) {
>> + void __iomem *addr = gtr_dev->serdes + lane * PHY_REG_OFFSET
>> + + reg;
>> +
>> + writel(value, addr);
>> + }
>> +}
>> +
>> +static inline void xpsgtr_clr_set_lanes(struct xpsgtr_dev *gtr_dev,
>> + unsigned long *lanes, u32 reg, u32 clr,
>> + u32 set)
>> +{
>> + unsigned long lane;
>> +
>> + for_each_set_bit(lane, lanes, NUM_LANES) {
>> + void __iomem *addr = gtr_dev->serdes + lane * PHY_REG_OFFSET
>> + + reg;
>> +
>> + writel((readl(addr) & ~clr) | set, addr);
>> + }
>> +}
>> +
>> /*
>> * Hardware Configuration
>> */
>> @@ -351,7 +448,7 @@ static int xpsgtr_wait_pll_lock(struct phy *phy)
>> u8 protocol = gtr_phy->protocol;
>> int ret;
>>
>> - dev_dbg(gtr_dev->dev, "Waiting for PLL lock\n");
>> + dev_vdbg(gtr_dev->dev, "Waiting for PLL lock\n");
>
> Unrelated change.
We reconfigure the PLL many times during ILL training, and this debug
output makes it difficult to read the ILL calibration debug.
>>
>> /*
>> * For DP and PCIe, only the instance 0 PLL is used. Switch to that phy
>> @@ -520,6 +617,231 @@ static void xpsgtr_bypass_scrambler_8b10b(struct
>> xpsgtr_phy *gtr_phy)
>> xpsgtr_write_phy(gtr_phy, L0_TX_DIG_61,
>> L0_TM_DISABLE_SCRAMBLE_ENCODER);
>> }
>>
>> +/* Enable or disable loopback */
>> +static void xpsgtr_phy_set_loopback(struct xpsgtr_phy *gtr_phy, bool enabled)
>> +{
>> + struct xpsgtr_dev *gtr_dev = gtr_phy->dev;
>> + u32 reg = gtr_phy->lane >= 2 ? LPBK_CTRL1 : LPBK_CTRL0;
>> + u32 shift = gtr_phy->lane & 1 ? 4 : 0;
>> +
>> + xpsgtr_clr_set(gtr_dev, reg, 7 << shift, (u32)enabled << shift);
>> +}
>> +
>> +static void xpsgtr_phy_set_ill(struct xpsgtr_phy *gtr_phy, u32 ill, bool gen2)
>> +{
>> + u32 val = 4 + ill * 8;
>> +
>> + if (gen2) {
>> + xpsgtr_write_phy(gtr_phy, L0_TM_E_ILL2, val & 0xff);
>> + xpsgtr_clr_set_phy(gtr_phy, L0_TM_ILL12, 0x0f,
>> + 1 << (val >> 8));
>> + } else {
>> + xpsgtr_write_phy(gtr_phy, L0_TM_E_ILL1, val & 0xff);
>> + xpsgtr_clr_set_phy(gtr_phy, L0_TM_ILL12, 0xf0,
>> + (val >> 4) & 0x10);
>> + }
>> +}
>> +
>> +static bool xpsgtr_ill_calibrated(struct xpsgtr_phy *gtr_phy)
>> +{
>> + u32 ill1 = xpsgtr_read_phy(gtr_phy, L0_TM_E_ILL1);
>> + u32 ill2 = xpsgtr_read_phy(gtr_phy, L0_TM_E_ILL2);
>> + u32 ill12 = xpsgtr_read_phy(gtr_phy, L0_TM_ILL12);
>> +
>> + dev_dbg(gtr_phy->dev->dev, "lane %u gen1 ILL was %u gen2 ILL was
>> %u\n",
>> + gtr_phy->lane, ill1 / 8 + (ill12 & 0x10 ? 32 : 0),
>> + ill2 / 8 + (ill12 & 0x02 ? 32 : 0));
>> + return ill1 || ill2 || ill12;
>> +}
>> +
>> +static void xpsgtr_init_ill(struct xpsgtr_phy *gtr_phy)
>> +{
>> + struct xpsgtr_dev *gtr_dev = gtr_phy->dev;
>> + struct clk *clk = gtr_dev->clk[gtr_phy->refclk];
>> + u32 ill123 = DIV_ROUND_CLOSEST(clk_get_rate(clk), 1000000);
>> +
>> + xpsgtr_clr_set_phy(gtr_phy, L0_TM_MISC2, 0,
>> L0_TM_MISC2_ILL_CAL_BYPASS);
>> + xpsgtr_write_phy(gtr_phy, L0_TM_IQ_ILL1, ill123);
>> + xpsgtr_write_phy(gtr_phy, L0_TM_IQ_ILL2, ill123);
>> + xpsgtr_write_phy(gtr_phy, L0_TM_IQ_ILL3, ill123);
>> + xpsgtr_write_phy(gtr_phy, L0_TM_IQ_ILL7, 0xf3);
>> + xpsgtr_write_phy(gtr_phy, L0_TM_E_ILL7, 0xf3);
>> + xpsgtr_write_phy(gtr_phy, L0_TM_ILL8, 0xff);
>> + xpsgtr_write_phy(gtr_phy, L0_TM_IQ_ILL8, 0xf3);
>> + xpsgtr_write_phy(gtr_phy, L0_TM_E_ILL8, 0xf3);
>> + xpsgtr_write_phy(gtr_phy, L0_TM_IQ_ILL9, 1);
>> + xpsgtr_write_phy(gtr_phy, L0_TM_E_ILL9, 1);
>> + xpsgtr_clr_set(gtr_dev, UPHY_SPARE0, BIT(5), 0);
>> +}
>> +
>> +static void xpsgtr_phy_illcalib(struct xpsgtr_dev *gtr_dev,
>> + unsigned long *lanes, bool gen2)
>> +{
>> + bool last_ok[NUM_LANES] = { 0 };
>> + int pass[NUM_LANES] = { 0 }, altpass[NUM_LANES] = { 0 };
>> + int best[NUM_LANES] = { 0 }, altbest[NUM_LANES] = { 0 };
>> + unsigned long lane;
>> + int i;
>> +
>> + /* Initialize the BIST */
>> + xpsgtr_clr_set_lanes(gtr_dev, lanes, L0_BIST_CTRL_1, 0xe0, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_FILLER_OUT, 1);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_FORCE_MK_RST, 1);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_TM_DIG_22, 0x20);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_CTRL_2, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_RUN_LEN_L, 0xf4);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_ERR_INJ_POINT_L, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_RUNLEN_ERR_INJ_H, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_IDLE_TIME, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_MARKER_L, 0xfb);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_IDLE_CHAR_L, 0xff);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_MARKER_IDLE_H, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_LOW_PULSE_TIME, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_TOTAL_PULSE_TIME, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_TEST_PAT_1, 0x4a);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_TEST_PAT_2, 0x4a);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_TEST_PAT_3, 0x4a);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_TEST_PAT_4, 0x4a);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_TEST_PAT_MSBS, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_PKT_NUM, 0x14);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_FRM_IDLE_TIME, 2);
>> + xpsgtr_clr_set_lanes(gtr_dev, lanes, L0_BIST_CTRL_1, 0xe0, 0);
>> +
>> + for (i = 0; i < 64; i++) {
>> + bool ok[NUM_LANES];
>> +
>> + for_each_set_bit(lane, lanes, NUM_LANES)
>> + xpsgtr_phy_set_ill(>r_dev->phys[lane], i, gen2);
>> +
>> + /* Reset lanes */
>> + xpsgtr_clr_set_lanes(gtr_dev, lanes, L0_TM_ANA_BYP_7, 0x20,
>> + 0x10);
>> + xpsgtr_write(gtr_dev, UPHY_SPARE0, 0x00);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_TM_ANA_BYP_4, 0x40);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_TM_PLL_DIG_33, 0x80);
>> + xpsgtr_write(gtr_dev, UPHY_SPARE0, 0x04);
>> + udelay(50);
>> + if (gen2)
>> + xpsgtr_write(gtr_dev, UPHY_SPARE0, 0x0e);
>> + xpsgtr_write(gtr_dev, UPHY_SPARE0, 0x06);
>> + if (gen2) {
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_TX_ANA_TM_3, 0x04);
>> + xpsgtr_write(gtr_dev, UPHY_SPARE0, 0x07);
>> + udelay(400);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_TX_ANA_TM_3, 0x0c);
>> + udelay(15);
>> + xpsgtr_write(gtr_dev, UPHY_SPARE0, 0x0f);
>> + udelay(100);
>> + }
>> +
>> + if (xpsgtr_wait_pll_lock(gtr_dev->phys[0].phy)) {
>> + memset(last_ok, 0, sizeof(last_ok));
>> + continue;
>> + }
>> +
>> + udelay(50);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_TM_ANA_BYP_4, 0xc0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_TM_ANA_BYP_4, 0x80);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_TM_PLL_DIG_33, 0xc0);
>> + udelay(50);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_TM_PLL_DIG_33, 0x80);
>> + udelay(50);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_TM_ANA_BYP_4, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_TM_PLL_DIG_33, 0);
>> + udelay(500);
>> +
>> + /* Do the BIST */
>> + for_each_set_bit(lane, lanes, NUM_LANES) {
>> + struct xpsgtr_phy *gtr_phy = >r_dev->phys[lane];
>> + u32 packets, errors;
>> +
>> + xpsgtr_phy_init_bus_width(gtr_phy, PROT_BUS_WIDTH_10);
>> + xpsgtr_phy_set_loopback(gtr_phy, true);
>> + xpsgtr_write_phy(gtr_phy, L0_TM_DIG_22, 0x20);
>> + xpsgtr_clr_set_phy(gtr_phy, L0_BIST_CTRL_1, 0, 1);
>> +
>> + udelay(200);
>> + xpsgtr_write_phy(gtr_phy, L0_BIST_CTRL_1, 0);
>> + packets = xpsgtr_read_phy(gtr_phy, L0_BIST_PKT_CTR_L);
>> + packets |= xpsgtr_read_phy(gtr_phy, L0_BIST_PKT_CTR_H)
>> << 8;
>> + errors = xpsgtr_read_phy(gtr_phy, L0_BIST_ERR_CTR_L);
>> + errors |= xpsgtr_read_phy(gtr_phy, L0_BIST_ERR_CTR_H)
>> << 8;
>> + ok[lane] = packets && !errors;
>> +
>> + dev_dbg(gtr_dev->dev,
>> + "lane %lu ILL %d packets %10u errors %10u\n",
>> + lane, i, packets, errors);
>> + }
>> +
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_CTRL_1, 0);
>> + xpsgtr_write(gtr_dev, UPHY_SPARE0, 0x00);
>> + xpsgtr_write(gtr_dev, UPHY_SPARE0, 0x02);
>> +
>> + for_each_set_bit(lane, lanes, NUM_LANES) {
>> + pass[lane] += ok[lane] && last_ok[lane];
>> + if (pass[lane] < 4) {
>> + if (!ok[lane] && i > 2) {
>> + if (altpass[lane] < pass[lane]) {
>> + altpass[lane] = pass[lane];
>> + altbest[lane] =
>> + (i - 1) - (pass[lane] + 1) / 2;
>> + }
>> + pass[lane] = 0;
>> + }
>> + } else if (!best[lane] && (!ok[lane] || i == 63) &&
>> + last_ok[lane]) {
>> + best[lane] = (i - 1) - (pass[lane] + 1) / 2;
>> + }
>> + }
>> +
>> + memcpy(last_ok, ok, sizeof(ok));
>> + }
>> +
>> + for_each_set_bit(lane, lanes, NUM_LANES) {
>> + dev_dbg(gtr_dev->dev, "lane %lu ILL best %d alt best %d\n",
>> + lane, best[lane], altbest[lane]);
>> +
>> + xpsgtr_phy_set_ill(>r_dev->phys[lane],
>> + best[lane] ?: altbest[lane], gen2);
>> + }
>> +
>> + /* Clean up */
>> + xpsgtr_clr_set_lanes(gtr_dev, lanes, L0_TM_ANA_BYP_7, 0x30, 0);
>> + xpsgtr_write(gtr_dev, UPHY_SPARE0, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_CTRL_1, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_CTRL_2, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_RUN_LEN_L, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_ERR_INJ_POINT_L, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_RUNLEN_ERR_INJ_H, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_IDLE_TIME, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_MARKER_L, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_IDLE_CHAR_L, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_MARKER_IDLE_H, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_LOW_PULSE_TIME, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_TOTAL_PULSE_TIME, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_TEST_PAT_1, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_TEST_PAT_2, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_TEST_PAT_3, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_TEST_PAT_4, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_TEST_PAT_MSBS, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_PKT_NUM, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_FRM_IDLE_TIME, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_PKT_CTR_L, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_PKT_CTR_H, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_ERR_CTR_L, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_ERR_CTR_H, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_FILLER_OUT, 1);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_BIST_FORCE_MK_RST, 0);
>> + xpsgtr_write_lanes(gtr_dev, lanes, L0_TM_DIG_22, 0);
>> +
>> + for_each_set_bit(lane, lanes, NUM_LANES) {
>> + struct xpsgtr_phy *gtr_phy = >r_dev->phys[lane];
>> +
>> + xpsgtr_phy_init_bus_width(gtr_phy, PROT_BUS_WIDTH_20);
>> + xpsgtr_phy_set_loopback(gtr_phy, false);
>> + }
>> +}
>> +
>> static int xpsgtr_common_init(struct xpsgtr_phy *gtr_phy)
>> {
>> int ret;
>> @@ -553,6 +875,37 @@ static void xpsgtr_phy_init_sata(struct xpsgtr_phy
>> *gtr_phy)
>> {
>> struct xpsgtr_dev *gtr_dev = gtr_phy->dev;
>>
>> + if (!xpsgtr_ill_calibrated(gtr_phy)) {
>> + DECLARE_BITMAP(lanes, NUM_LANES) = { 0 };
>> +
>> + xpsgtr_init_ill(gtr_phy);
>> + xpsgtr_write_phy(gtr_phy, L0_TM_E_ILL3, 100);
>> + xpsgtr_clr_set_phy(gtr_phy, L0_TM_ILL11, 0xf0, 0x20);
>> +
>> + __set_bit(gtr_phy->lane, lanes);
>> + xpsgtr_phy_illcalib(gtr_dev, lanes, false);
>> + xpsgtr_phy_set_ill(gtr_phy, 7, true);
>> + }
>> +
>> + /* Disable SSC */
>> + xpsgtr_write_phy(gtr_phy, L0_PLL_FBDIV_FRAC_3_MSB,
>> TM_FORCE_EN_FRAC);
>> + xpsgtr_clr_set_phy(gtr_phy, L0_PLL_SS_STEP_SIZE_3_MSB, 0,
>> TM_FORCE_EN);
>> +
>> + /* Disable Tx deemphasis */
>> + xpsgtr_write_phy(gtr_phy, L0_TM_CDR5,
>> + FIELD_PREP(L0_TM_CDR5_FPHL_FSM_ACC_CYCLES,
>> 7) |
>> + FIELD_PREP(L0_TM_CDR5_FFL_PH0_INT_GAIN, 6));
>> + xpsgtr_write_phy(gtr_phy, L0_TM_CDR16, 12);
>> +
>> + /* Configure equalization */
>> + xpsgtr_write_phy(gtr_phy, L0_TX_ANA_TM_118,
>> + L0_TX_ANA_TM_118_FORCE_17_0);
>> + xpsgtr_clr_set_phy(gtr_phy, L0_TM_EQ0, 0,
>> L0_TM_EQ0_EQ_STG2_CTRL_BYP);
>> + xpsgtr_clr_set_phy(gtr_phy, L0_TM_EQ1,
>> L0_TM_EQ1_EQ_STG2_RL_PROG,
>> + FIELD_PREP(L0_TM_EQ1_EQ_STG2_RL_PROG, 2) |
>> + L0_TM_EQ1_EQ_STG2_PREAMP_MODE_VAL);
>> + xpsgtr_write_phy(gtr_phy, L0_TX_ANA_TM_18, 2); /* -3.5 dB deemphasis */
>> +
>> xpsgtr_bypass_scrambler_8b10b(gtr_phy);
>>
>> writel(gtr_phy->lane, gtr_dev->siou + SATA_CONTROL_OFFSET);
>> @@ -565,6 +918,64 @@ static void xpsgtr_phy_init_sgmii(struct xpsgtr_phy
>> *gtr_phy)
>> xpsgtr_bypass_scrambler_8b10b(gtr_phy);
>> }
>>
>> +/* PCIe-specific initialization. */
>> +static int xpsgtr_phy_init_pcie(struct xpsgtr_phy *gtr_phy)
>> +{
>> + struct xpsgtr_dev *gtr_dev = gtr_phy->dev;
>> + DECLARE_BITMAP(lanes, NUM_LANES) = { 0 };
>> + unsigned long lane;
>> + bool calibrated = false;
>> +
>> + xpsgtr_clr_set_phy(gtr_phy, L0_TM_AUX_0, 0, 0x20);
>> +
>> + for (lane = 0; lane < NUM_LANES; lane++) {
>> + struct xpsgtr_phy *gtr_phy = >r_dev->phys[lane];
>> +
>> + if (gtr_phy->protocol != ICM_PROTOCOL_PCIE)
>> + continue;
>> +
>> + __set_bit(lane, lanes);
>> + calibrated = calibrated || xpsgtr_ill_calibrated(gtr_phy);
>> + }
>> +
>> + if (calibrated)
>> + return 0;
>> +
>> + /* Write default ILL config */
>> + for_each_set_bit(lane, lanes, NUM_LANES) {
>> + struct xpsgtr_phy *p = >r_dev->phys[lane];
>> +
>> + if (lane != gtr_phy->lane) {
>> + int ret = xpsgtr_common_init(p);
>> +
>> + if (ret)
>> + return ret;
>> + }
>> +
>> + xpsgtr_init_ill(p);
>> + xpsgtr_write_phy(p, L0_TM_E_ILL3, 0);
>> + xpsgtr_clr_set_phy(p, L0_TM_MISC2, 0,
>> + L0_TM_MISC2_ILL_CAL_BYPASS);
>> + }
>> +
>> + /* Perform the ILL calibration procedure */
>> + xpsgtr_phy_illcalib(gtr_dev, lanes, false);
>> + xpsgtr_phy_illcalib(gtr_dev, lanes, true);
>> +
>> + /* Disable PCIe ECO */
>> + writel(1, gtr_dev->siou + SIOU_ECO_0);
>> + return 0;
>> +}
>> +
>> +/* USB-specific initialization. */
>> +static void xpsgtr_phy_init_usb(struct xpsgtr_phy *gtr_phy)
>> +{
>> + xpsgtr_clr_set_phy(gtr_phy, L0_TM_AUX_0, 0, 0x20);
>> + xpsgtr_write_phy(gtr_phy, L0_TM_IQ_ILL8, 0xf3);
>> + xpsgtr_write_phy(gtr_phy, L0_TM_E_ILL8, 0xf3);
>> + xpsgtr_phy_set_ill(gtr_phy, 7, false);
>> +}
>> +
>> /* Configure TX de-emphasis and margining for DP. */
>> static void xpsgtr_phy_configure_dp(struct xpsgtr_phy *gtr_phy, unsigned int pre,
>> unsigned int voltage)
>> @@ -710,6 +1121,10 @@ static int xpsgtr_phy_init(struct phy *phy)
>> xpsgtr_phy_init_dp(gtr_phy);
>> break;
>>
>> + case ICM_PROTOCOL_PCIE:
>> + ret = xpsgtr_phy_init_pcie(gtr_phy);
>> + break;
>> +
>> case ICM_PROTOCOL_SATA:
>> xpsgtr_phy_init_sata(gtr_phy);
>> break;
>> @@ -717,6 +1132,10 @@ static int xpsgtr_phy_init(struct phy *phy)
>> case ICM_PROTOCOL_SGMII:
>> xpsgtr_phy_init_sgmii(gtr_phy);
>> break;
>> +
>> + case ICM_PROTOCOL_USB:
>> + xpsgtr_phy_init_usb(gtr_phy);
>> + break;
>> }
>>
>> out:
>> --
>> 2.35.1.1320.gc452695387.dirty
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH] phy: ti: j721e-wiz: Fix device_node leak in wiz_get_lane_phy_types()
From: Felix Gu @ 2026-02-10 18:14 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Kishon Vijay Abraham I, Jyri Sarha
Cc: linux-phy, linux-kernel, Felix Gu
The 'serdes' device_node is obtained using of_get_child_by_name(),
which increments the reference count. However, it is never put,
leading to a memory leak.
Use the __free(device_node) attribute to automatically decrement
the reference count when the 'serdes' variable goes out of scope.
Fixes: 7ae14cf581f2 ("phy: ti: j721e-wiz: Implement DisplayPort mode to the wiz driver")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/phy/ti/phy-j721e-wiz.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 12a19bf2875c..904541e9138e 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -1407,9 +1407,8 @@ MODULE_DEVICE_TABLE(of, wiz_id_table);
static int wiz_get_lane_phy_types(struct device *dev, struct wiz *wiz)
{
- struct device_node *serdes;
-
- serdes = of_get_child_by_name(dev->of_node, "serdes");
+ struct device_node *serdes __free(device_node) =
+ of_get_child_by_name(dev->of_node, "serdes");
if (!serdes) {
dev_err(dev, "%s: Getting \"serdes\"-node failed\n", __func__);
return -EINVAL;
---
base-commit: 193579fe01389bc21aff0051d13f24e8ea95b47d
change-id: 20260204-wiz-9a67604a034f
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v6 3/8] phy: Add driver for EyeQ5 Ethernet PHY wrapper
From: Vladimir Oltean @ 2026-02-10 19:35 UTC (permalink / raw)
To: Théo Lebrun
Cc: Vladimir Kondratiev, Grégory Clement, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul,
Kishon Vijay Abraham I, Michael Turquette, Stephen Boyd,
Philipp Zabel, Thomas Bogendoerfer, Neil Armstrong, linux-mips,
devicetree, linux-kernel, linux-phy, linux-clk, Benoît Monin,
Tawfik Bayouk, Thomas Petazzoni, Luca Ceresoli
In-Reply-To: <20260127-macb-phy-v6-3-cdd840588188@bootlin.com>
Hi Theo,
On Tue, Jan 27, 2026 at 06:09:31PM +0100, Théo Lebrun wrote:
> +static int eq5_phy_init(struct phy *phy)
> +{
> + struct eq5_phy_inst *inst = phy_get_drvdata(phy);
> + struct eq5_phy_private *priv = inst->priv;
> + struct device *dev = priv->dev;
> + u32 reg;
> +
> + dev_dbg(dev, "phy_init(inst=%td)\n", inst - priv->phys);
Nitpick: can you please remove the debugging prints and maybe add some
trace points to the PHY core if you feel strongly about having some
introspection?
> +
> + writel(0, inst->gp);
> + writel(0, inst->sgmii);
> +
> + udelay(5);
Could you please add a macro or comment hinting at the origin of the
magic number 5 here? You could also place these 3 lines in a common
helper, also called from eq5_phy_exit(), to avoid minor code
duplication.
> +
> + reg = readl(inst->gp) | EQ5_GP_TX_SWRST_DIS | EQ5_GP_TX_M_CLKE |
When you write 0 to inst->gp and then read it back, do you expect to
(a) get back 0 or
(b) are some fields non-resetting?
I see both as inconsistent, since if (a), you can remove the
readl(inst->gp) and expect the same result. And if (b), it also
shouldn't matter if you write zeroes a second time, if it was fine the
first time?
Shortly said, is readl(inst->gp) really needed?
> + EQ5_GP_SYS_SWRST_DIS | EQ5_GP_SYS_M_CLKE |
> + FIELD_PREP(EQ5_GP_RGMII_DRV, 0x9);
Quick sanity check on your proposal to use #phy-cells = <1>. This is not
a request to change anything.
What if you need to customize the RGMII drive strength (or some other
setting, maybe SGMII polarity if that is available) per lane, for a
particular board? How would you do that if each PHY does not have its
own OF node?
> + writel(reg, inst->gp);
> +
> + return 0;
> +}
> +
> +static int eq5_phy_exit(struct phy *phy)
> +{
> + struct eq5_phy_inst *inst = phy_get_drvdata(phy);
> + struct eq5_phy_private *priv = inst->priv;
> + struct device *dev = priv->dev;
> +
> + dev_dbg(dev, "phy_exit(inst=%td)\n", inst - priv->phys);
> +
> + writel(0, inst->gp);
> + writel(0, inst->sgmii);
> + udelay(5);
> +
> + return 0;
> +}
> +
> +static int eq5_phy_set_mode(struct phy *phy, enum phy_mode mode, int submode)
> +{
> + struct eq5_phy_inst *inst = phy_get_drvdata(phy);
> + struct eq5_phy_private *priv = inst->priv;
> + struct device *dev = priv->dev;
> +
> + dev_dbg(dev, "phy_set_mode(inst=%td, mode=%d, submode=%d)\n",
> + inst - priv->phys, mode, submode);
> +
> + if (mode != PHY_MODE_ETHERNET)
> + return -EOPNOTSUPP;
> +
> + if (!phy_interface_mode_is_rgmii(submode) &&
> + submode != PHY_INTERFACE_MODE_SGMII)
> + return -EOPNOTSUPP;
Both PHYs are equal in capabilities, and support both RGMII and SGMII,
correct? I see the driver is implemented as if they were, but it doesn't
hurt to ask.
> +
> + inst->phy_interface = submode;
Short story: don't rely on the phy_set_mode_ext() -> phy_power_on() order.
Implement the driver so that it works the other way around too.
Long story:
https://lore.kernel.org/netdev/aXzFH09AeIRawCwU@shell.armlinux.org.uk/
> + return 0;
> +}
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 2/8] phy: sort Kconfig and Makefile
From: Vladimir Oltean @ 2026-02-10 19:37 UTC (permalink / raw)
To: Théo Lebrun
Cc: Grégory Clement, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Kishon Vijay Abraham I,
Michael Turquette, Stephen Boyd, Philipp Zabel,
Thomas Bogendoerfer, Neil Armstrong, linux-mips, devicetree,
linux-kernel, linux-phy, linux-clk, Benoît Monin,
Tawfik Bayouk, Thomas Petazzoni, Luca Ceresoli
In-Reply-To: <20260127-macb-phy-v6-2-cdd840588188@bootlin.com>
Hi Theo,
On Tue, Jan 27, 2026 at 06:09:30PM +0100, Théo Lebrun wrote:
> Neither Kconfig nor Makefile are sorted; reorder them.
>
> $ diff -U100 <(grep ^config drivers/phy/Kconfig) \
> <(grep ^config drivers/phy/Kconfig | sort)
>
> $ diff -U100 <(grep ^obj-\\$ drivers/phy/Makefile) \
> <(grep ^obj-\\$ drivers/phy/Makefile | sort)
>
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
> ---
This patch is appreciated, however it no longer applies on top of
current linux-phy/next.
Since we are in the merge window currently, would you mind reposting in
2 weeks (or as RFC in the meantime)?
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: ti: j721e-wiz: Fix device_node leak in wiz_get_lane_phy_types()
From: Vladimir Oltean @ 2026-02-10 20:30 UTC (permalink / raw)
To: Felix Gu
Cc: Vinod Koul, Neil Armstrong, Kishon Vijay Abraham I, Jyri Sarha,
linux-phy, linux-kernel
In-Reply-To: <20260211-wiz-v1-1-fdd018d02f33@gmail.com>
Hi Felix,
On Wed, Feb 11, 2026 at 02:14:11AM +0800, Felix Gu wrote:
> The 'serdes' device_node is obtained using of_get_child_by_name(),
> which increments the reference count. However, it is never put,
> leading to a memory leak.
>
> Use the __free(device_node) attribute to automatically decrement
> the reference count when the 'serdes' variable goes out of scope.
>
> Fixes: 7ae14cf581f2 ("phy: ti: j721e-wiz: Implement DisplayPort mode to the wiz driver")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> ---
> drivers/phy/ti/phy-j721e-wiz.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
> index 12a19bf2875c..904541e9138e 100644
> --- a/drivers/phy/ti/phy-j721e-wiz.c
> +++ b/drivers/phy/ti/phy-j721e-wiz.c
> @@ -1407,9 +1407,8 @@ MODULE_DEVICE_TABLE(of, wiz_id_table);
>
> static int wiz_get_lane_phy_types(struct device *dev, struct wiz *wiz)
> {
> - struct device_node *serdes;
> -
> - serdes = of_get_child_by_name(dev->of_node, "serdes");
> + struct device_node *serdes __free(device_node) =
> + of_get_child_by_name(dev->of_node, "serdes");
> if (!serdes) {
> dev_err(dev, "%s: Getting \"serdes\"-node failed\n", __func__);
> return -EINVAL;
>
> ---
> base-commit: 193579fe01389bc21aff0051d13f24e8ea95b47d
> change-id: 20260204-wiz-9a67604a034f
>
> Best regards,
> --
> Felix Gu <ustc.gu@gmail.com>
>
>
You are fixing a bug from 2020 (v5.8) with functionality introduced in 2023,
creating avoidable headache for backporters (the oldest supported LTS is
5.10, where the cleanup API does not exist). Could we reimplement this
the "normal" of_node_put() way?
I realize this is not netdev, but this piece of advice from
Documentation/process/maintainer-netdev.rst regarding use in drivers
seems common sense and relevant here:
Low level cleanup constructs (such as ``__free()``) can be used when building
APIs and helpers, especially scoped iterators. However, direct use of
``__free()`` within networking core and drivers is discouraged.
Similar guidance applies to declaring variables mid-function.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH phy-next] phy: apple: apple: Check the actual ioremap return value
From: Vladimir Oltean @ 2026-02-10 20:48 UTC (permalink / raw)
To: Janne Grunau
Cc: Sven Peter, Neal Gompa, Vinod Koul, Neil Armstrong, Philipp Zabel,
asahi, linux-phy, linux-kernel, Dan Carpenter
In-Reply-To: <20260207-phy-apple-resource-err-ptr-v1-1-78735b07ed2d@jannau.net>
Hello Janne,
On Sat, Feb 07, 2026 at 05:40:34PM +0100, Janne Grunau wrote:
> The address where the devm_ioremap_resource() return value is stored is
> always a valid pointer. Check the actual return value instead as that
> that might be an error value.
>
> Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> Closes: https://lore.kernel.org/asahi/aYXvX1bYOXtYCgfC@stanley.mountain/
> Fixes: 8e98ca1e74db ("phy: apple: Add Apple Type-C PHY")
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> drivers/phy/apple/atc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/apple/atc.c b/drivers/phy/apple/atc.c
> index dc867f368b68748ea953e594ad998d7f965d8d1d..c144e273a555a741b49adfccbe046df83d193e03 100644
> --- a/drivers/phy/apple/atc.c
> +++ b/drivers/phy/apple/atc.c
> @@ -2206,7 +2206,7 @@ static int atcphy_map_resources(struct platform_device *pdev, struct apple_atcph
> for (int i = 0; i < ARRAY_SIZE(resources); i++) {
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, resources[i].name);
> *resources[i].addr = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(resources[i].addr))
> + if (IS_ERR(*resources[i].addr))
> return dev_err_probe(atcphy->dev, PTR_ERR(resources[i].addr),
> "Unable to map %s regs", resources[i].name);
This does not seem correct - every call site that tests a pointer for
IS_ERR() also decodes the error using PTR_ERR(). Whereas you are here
creating the pattern "if (IS_ERR(*a)) return PTR_ERR(a)".
Proven practice seems to tell us that insisting to save the
devm_ioremap_resource() return code directly in *resources[i].addr
is too complex here.
Would you consider creating a temporary "void __iomem *addr" local
variable, and set "*resources[i].addr = addr" only once it's validated?
This would make the code obviously correct upon review.
>
>
> ---
> base-commit: dbeea86fecef7cf2b93aded4525d74f6277376ef
> change-id: 20260207-phy-apple-resource-err-ptr-5923d1130465
>
> Best regards,
> --
> Janne Grunau <j@jannau.net>
>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 0/2] phy: microchip: lan966x: Allow to invert N and P signals
From: Vladimir Oltean @ 2026-02-11 12:22 UTC (permalink / raw)
To: Horatiu Vultur
Cc: Vladimir Oltean, vkoul, kishon, robh, krzk+dt, conor+dt,
linux-phy, devicetree, linux-kernel, Daniel Golle
In-Reply-To: <20251119192326.4bflaqkh4zvz2rib@skbuf>
Hi Horatiu,
On Wed, Nov 19, 2025 at 09:23:26PM +0200, Vladimir Oltean wrote:
> > Anyway I can wait with this patch series until you get your changes in.
>
> I will keep you copied to the patch set which I hope to send later today.
The generic description I was talking about has been merged as commit
e7556b59ba65 ("phy: add phy_get_rx_polarity() and phy_get_tx_polarity()").
This set should be dropped from Patchwork. You can send a new version
after the merge window closes, or an RFC at any time.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH V5 0/3] Add UFS support for x1e80100 SoC
From: Pradeep P V K @ 2026-02-11 13:29 UTC (permalink / raw)
To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, martin.petersen,
andersson, konradybcio, taniya.das, dmitry.baryshkov,
manivannan.sadhasivam
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
nitin.rawat, Pradeep P V K
Add UFSPHY, UFSHC compatible binding names and UFS devicetree
enablement changes for Qualcomm x1e80100 SoC.
Changes in V5:
- Rebased on linux-next (next-20260210) to resolve merge conflicts.
- Add RB-by for UFSHC dt-binding [Krzysztof]
- Add AB-by for UFSHC dt-binding [Mani]
- Add RB-by for SoC dtsi [Konrad, Abel, Taniya, Mani]
- Add RB-by for board dts [Konrad, Mani]
- Link to V4:
https://lore.kernel.org/all/20260106154207.1871487-1-pradeep.pragallapati@oss.qualcomm.com
Changes in V4:
- Update ufs@ with ufshc@ in SoC dtsi [Mani]
- Retain complete change history in cover letter [Dmitry]
- Remove "jedec,ufs-2.0" compatible from ufshc dt-bindings
and SoC dtsi files [Krzysztof, Mani]
- Remove RB-by tag from Krzysztof and AB-by tag from Mani on
UFSHC dt-binding file as it has changes and needs re-review.
- Add RB-by for QMP UFS PHY dt-binding [Krzysztof]
- Add RB-by for SoC dtsi [Konrad, Abel, Taniya, Mani]
- Add RB-by for board dts [Konrad]
- Link to V3:
https://lore.kernel.org/all/0689ae93-0684-4bf8-9bce-f9f32e56fe06@oss.qualcomm.com
Changes in V3:
- Update all dt-bindings commit messages with concise and informative
statements [Krzysztof]
- keep the QMP UFS PHY order by last compatible in numerical ascending
order [Krzysztof]
- Remove qcom,x1e80100-ufshc from select: enum: list of
qcom,sc7180-ufshc.yaml file [Krzysztof]
- Update subject prefix for all dt-bindings [Krzysztof]
- Add RB-by for SoC dtsi [Konrad, Abel, Taniya]
- Add RB-by for board dts [Konrad]
- Link to V2:
https://lore.kernel.org/all/20251231101951.1026163-1-pradeep.pragallapati@oss.qualcomm.com
Changes in V2:
- Update all dt-bindings commit messages to explain fallback
to SM8550 [Krzysztof]
- Pad register addresses to 8-digit hex format [Konrad]
- Place one compatible string per line [Konrad]
- Replace chip codenames with numeric identifiers throughout [Konrad]
- Fix dt_binding_check error in UFSHC dt-bindings [Rob]
- This series is rebased on GCC bindings and driver changes:
https://lore.kernel.org/lkml/20251230-ufs_symbol_clk-v1-0-47d46b24c087@oss.qualcomm.com/
- This series address issues and gaps noticed on:
https://lore.kernel.org/linux-devicetree/20250814005904.39173-2-harrison.vanderbyl@gmail.com/
https://lore.kernel.org/linux-devicetree/p3mhtj2rp6y2ezuwpd2gu7dwx5cbckfu4s4pazcudi4j2wogtr@4yecb2bkeyms/
- Link to V1:
https://lore.kernel.org/linux-phy/20251229060642.2807165-1-pradeep.pragallapati@oss.qualcomm.com/
---
Pradeep P V K (3):
dt-bindings: ufs: qcom,sc7180-ufshc: Add UFSHC compatible for x1e80100
arm64: dts: qcom: hamoa: Add UFS nodes for x1e80100 SoC
arm64: dts: qcom: hamoa-iot-evk: Enable UFS
.../bindings/ufs/qcom,sc7180-ufshc.yaml | 36 +++---
arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 18 +++
arch/arm64/boot/dts/qcom/hamoa.dtsi | 122 +++++++++++++++++-
3 files changed, 158 insertions(+), 18 deletions(-)
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH V5 1/3] dt-bindings: ufs: qcom,sc7180-ufshc: Add UFSHC compatible for x1e80100
From: Pradeep P V K @ 2026-02-11 13:29 UTC (permalink / raw)
To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, martin.petersen,
andersson, konradybcio, taniya.das, dmitry.baryshkov,
manivannan.sadhasivam
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
nitin.rawat, Pradeep P V K, Manivannan Sadhasivam,
Krzysztof Kozlowski
In-Reply-To: <20260211132926.3716716-1-pradeep.pragallapati@oss.qualcomm.com>
Add UFS Host Controller (UFSHC) compatible for x1e80100 SoC. Use
SM8550 as a fallback since x1e80100 is fully compatible with it.
Qualcomm UFSHC is no longer compatible with JEDEC UFS-2.0 binding.
Avoid using the "jedec,ufs-2.0" string in the compatible property.
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>
---
.../bindings/ufs/qcom,sc7180-ufshc.yaml | 36 +++++++++++--------
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml b/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml
index d94ef4e6b85a..fe18e41ebac7 100644
--- a/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml
+++ b/Documentation/devicetree/bindings/ufs/qcom,sc7180-ufshc.yaml
@@ -31,21 +31,27 @@ select:
properties:
compatible:
- items:
- - enum:
- - qcom,msm8998-ufshc
- - qcom,qcs8300-ufshc
- - qcom,sa8775p-ufshc
- - qcom,sc7180-ufshc
- - qcom,sc7280-ufshc
- - qcom,sc8180x-ufshc
- - qcom,sc8280xp-ufshc
- - qcom,sm8250-ufshc
- - qcom,sm8350-ufshc
- - qcom,sm8450-ufshc
- - qcom,sm8550-ufshc
- - const: qcom,ufshc
- - const: jedec,ufs-2.0
+ oneOf:
+ - items:
+ - enum:
+ - qcom,x1e80100-ufshc
+ - const: qcom,sm8550-ufshc
+ - const: qcom,ufshc
+ - items:
+ - enum:
+ - qcom,msm8998-ufshc
+ - qcom,qcs8300-ufshc
+ - qcom,sa8775p-ufshc
+ - qcom,sc7180-ufshc
+ - qcom,sc7280-ufshc
+ - qcom,sc8180x-ufshc
+ - qcom,sc8280xp-ufshc
+ - qcom,sm8250-ufshc
+ - qcom,sm8350-ufshc
+ - qcom,sm8450-ufshc
+ - qcom,sm8550-ufshc
+ - const: qcom,ufshc
+ - const: jedec,ufs-2.0
reg:
maxItems: 1
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH V5 2/3] arm64: dts: qcom: hamoa: Add UFS nodes for x1e80100 SoC
From: Pradeep P V K @ 2026-02-11 13:29 UTC (permalink / raw)
To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, martin.petersen,
andersson, konradybcio, taniya.das, dmitry.baryshkov,
manivannan.sadhasivam
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
nitin.rawat, Pradeep P V K, Konrad Dybcio, Abel Vesa,
Manivannan Sadhasivam
In-Reply-To: <20260211132926.3716716-1-pradeep.pragallapati@oss.qualcomm.com>
Add UFS host controller and PHY nodes for x1e80100 SoC.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/hamoa.dtsi | 122 +++++++++++++++++++++++++++-
1 file changed, 119 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index db65c392e618..5bffff1046e2 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -835,9 +835,9 @@ gcc: clock-controller@100000 {
<0>,
<0>,
<0>,
- <0>,
- <0>,
- <0>;
+ <&ufs_mem_phy 0>,
+ <&ufs_mem_phy 1>,
+ <&ufs_mem_phy 2>;
power-domains = <&rpmhpd RPMHPD_CX>;
#clock-cells = <1>;
@@ -3869,6 +3869,122 @@ pcie4_phy: phy@1c0e000 {
status = "disabled";
};
+ ufs_mem_phy: phy@1d80000 {
+ compatible = "qcom,x1e80100-qmp-ufs-phy",
+ "qcom,sm8550-qmp-ufs-phy";
+ reg = <0x0 0x01d80000 0x0 0x2000>;
+
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_UFS_PHY_PHY_AUX_CLK>,
+ <&tcsr TCSR_UFS_PHY_CLKREF_EN>;
+
+ clock-names = "ref",
+ "ref_aux",
+ "qref";
+ resets = <&ufs_mem_hc 0>;
+ reset-names = "ufsphy";
+
+ power-domains = <&gcc GCC_UFS_MEM_PHY_GDSC>;
+
+ #clock-cells = <1>;
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+
+ ufs_mem_hc: ufshc@1d84000 {
+ compatible = "qcom,x1e80100-ufshc",
+ "qcom,sm8550-ufshc",
+ "qcom,ufshc";
+ reg = <0x0 0x01d84000 0x0 0x3000>;
+
+ interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
+ <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>,
+ <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
+ <&rpmhcc RPMH_LN_BB_CLK3>,
+ <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
+ <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
+ <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
+ clock-names = "core_clk",
+ "bus_aggr_clk",
+ "iface_clk",
+ "core_clk_unipro",
+ "ref_clk",
+ "tx_lane0_sync_clk",
+ "rx_lane0_sync_clk",
+ "rx_lane1_sync_clk";
+
+ operating-points-v2 = <&ufs_opp_table>;
+
+ resets = <&gcc GCC_UFS_PHY_BCR>;
+ reset-names = "rst";
+
+ interconnects = <&aggre1_noc MASTER_UFS_MEM QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_UFS_MEM_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "ufs-ddr",
+ "cpu-ufs";
+
+ power-domains = <&gcc GCC_UFS_PHY_GDSC>;
+ required-opps = <&rpmhpd_opp_nom>;
+
+ iommus = <&apps_smmu 0x1a0 0>;
+ dma-coherent;
+
+ lanes-per-direction = <2>;
+
+ phys = <&ufs_mem_phy>;
+ phy-names = "ufsphy";
+
+ #reset-cells = <1>;
+
+ status = "disabled";
+
+ ufs_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-75000000 {
+ opp-hz = /bits/ 64 <75000000>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <75000000>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-150000000 {
+ opp-hz = /bits/ 64 <150000000>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <150000000>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <300000000>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>,
+ /bits/ 64 <0>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
cryptobam: dma-controller@1dc4000 {
compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
reg = <0x0 0x01dc4000 0x0 0x28000>;
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH V5 3/3] arm64: dts: qcom: hamoa-iot-evk: Enable UFS
From: Pradeep P V K @ 2026-02-11 13:29 UTC (permalink / raw)
To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, martin.petersen,
andersson, konradybcio, taniya.das, dmitry.baryshkov,
manivannan.sadhasivam
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, linux-scsi,
nitin.rawat, Pradeep P V K, Konrad Dybcio, Manivannan Sadhasivam
In-Reply-To: <20260211132926.3716716-1-pradeep.pragallapati@oss.qualcomm.com>
Enable UFS for HAMOA-IOT-EVK board.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
index 2390648a248f..fccf1d1bdc60 100644
--- a/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
+++ b/arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts
@@ -1461,6 +1461,24 @@ &uart21 {
status = "okay";
};
+&ufs_mem_phy {
+ vdda-phy-supply = <&vreg_l3i_0p8>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+
+ status = "okay";
+};
+
+&ufs_mem_hc {
+ reset-gpios = <&tlmm 238 GPIO_ACTIVE_LOW>;
+
+ vcc-supply = <&vreg_l17b_2p5>;
+ vcc-max-microamp = <1300000>;
+ vccq-supply = <&vreg_l2i_1p2>;
+ vccq-max-microamp = <1200000>;
+
+ status = "okay";
+};
+
&usb_1_ss0_dwc3_hs {
remote-endpoint = <&pmic_glink_ss0_hs_in>;
};
--
2.34.1
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [RESEND 1/1] phy: freescale: imx8qm-hsio: provide regmap names
From: Alexander Stein @ 2026-02-11 14:49 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: Alexander Stein, linux-phy, imx, linux-arm-kernel, linux-kernel
This driver uses multiple regmaps, which will causes name conflicts
in debugfs like:
debugfs: '5f1a0000.phy' already exists in 'regmap'
Fix this by using a dedicated regmap config for each resource, each
having a dedicated regmap name.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
Same as the one sent in December but with an updated CC list.
drivers/phy/freescale/phy-fsl-imx8qm-hsio.c | 23 +++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c b/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c
index 279b8ac7822df..4ab45c9f53dff 100644
--- a/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c
+++ b/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c
@@ -107,7 +107,22 @@ static const char * const lan2_pcieb_clks[] = {"apb_pclk2", "pclk2", "ctl1_crr",
static const char * const lan2_sata_clks[] = {"pclk2", "epcs_tx", "epcs_rx",
"phy1_crr", "misc_crr"};
-static const struct regmap_config regmap_config = {
+static const struct regmap_config regmap_phy_config = {
+ .name = "phy",
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+};
+
+static const struct regmap_config regmap_ctrl_config = {
+ .name = "ctrl",
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+};
+
+static const struct regmap_config regmap_misc_config = {
+ .name = "misc",
.reg_bits = 32,
.val_bits = 32,
.reg_stride = 4,
@@ -562,19 +577,19 @@ static int imx_hsio_probe(struct platform_device *pdev)
return PTR_ERR(priv->base);
off = devm_platform_ioremap_resource_byname(pdev, "phy");
- priv->phy = devm_regmap_init_mmio(dev, off, ®map_config);
+ priv->phy = devm_regmap_init_mmio(dev, off, ®map_phy_config);
if (IS_ERR(priv->phy))
return dev_err_probe(dev, PTR_ERR(priv->phy),
"unable to find phy csr registers\n");
off = devm_platform_ioremap_resource_byname(pdev, "ctrl");
- priv->ctrl = devm_regmap_init_mmio(dev, off, ®map_config);
+ priv->ctrl = devm_regmap_init_mmio(dev, off, ®map_ctrl_config);
if (IS_ERR(priv->ctrl))
return dev_err_probe(dev, PTR_ERR(priv->ctrl),
"unable to find ctrl csr registers\n");
off = devm_platform_ioremap_resource_byname(pdev, "misc");
- priv->misc = devm_regmap_init_mmio(dev, off, ®map_config);
+ priv->misc = devm_regmap_init_mmio(dev, off, ®map_misc_config);
if (IS_ERR(priv->misc))
return dev_err_probe(dev, PTR_ERR(priv->misc),
"unable to find misc csr registers\n");
--
2.43.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [RESEND 1/1] phy: freescale: imx8qm-hsio: provide regmap names
From: Frank Li @ 2026-02-11 15:31 UTC (permalink / raw)
To: Alexander Stein
Cc: Vinod Koul, Neil Armstrong, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-phy, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260211144949.1128122-1-alexander.stein@ew.tq-group.com>
On Wed, Feb 11, 2026 at 03:49:48PM +0100, Alexander Stein wrote:
> This driver uses multiple regmaps, which will causes name conflicts
> in debugfs like:
> debugfs: '5f1a0000.phy' already exists in 'regmap'
> Fix this by using a dedicated regmap config for each resource, each
> having a dedicated regmap name.
>
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Same as the one sent in December but with an updated CC list.
>
> drivers/phy/freescale/phy-fsl-imx8qm-hsio.c | 23 +++++++++++++++++----
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c b/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c
> index 279b8ac7822df..4ab45c9f53dff 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8qm-hsio.c
> @@ -107,7 +107,22 @@ static const char * const lan2_pcieb_clks[] = {"apb_pclk2", "pclk2", "ctl1_crr",
> static const char * const lan2_sata_clks[] = {"pclk2", "epcs_tx", "epcs_rx",
> "phy1_crr", "misc_crr"};
>
> -static const struct regmap_config regmap_config = {
> +static const struct regmap_config regmap_phy_config = {
> + .name = "phy",
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> +static const struct regmap_config regmap_ctrl_config = {
> + .name = "ctrl",
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> +static const struct regmap_config regmap_misc_config = {
> + .name = "misc",
> .reg_bits = 32,
> .val_bits = 32,
> .reg_stride = 4,
> @@ -562,19 +577,19 @@ static int imx_hsio_probe(struct platform_device *pdev)
> return PTR_ERR(priv->base);
>
> off = devm_platform_ioremap_resource_byname(pdev, "phy");
> - priv->phy = devm_regmap_init_mmio(dev, off, ®map_config);
> + priv->phy = devm_regmap_init_mmio(dev, off, ®map_phy_config);
> if (IS_ERR(priv->phy))
> return dev_err_probe(dev, PTR_ERR(priv->phy),
> "unable to find phy csr registers\n");
>
> off = devm_platform_ioremap_resource_byname(pdev, "ctrl");
> - priv->ctrl = devm_regmap_init_mmio(dev, off, ®map_config);
> + priv->ctrl = devm_regmap_init_mmio(dev, off, ®map_ctrl_config);
> if (IS_ERR(priv->ctrl))
> return dev_err_probe(dev, PTR_ERR(priv->ctrl),
> "unable to find ctrl csr registers\n");
>
> off = devm_platform_ioremap_resource_byname(pdev, "misc");
> - priv->misc = devm_regmap_init_mmio(dev, off, ®map_config);
> + priv->misc = devm_regmap_init_mmio(dev, off, ®map_misc_config);
> if (IS_ERR(priv->misc))
> return dev_err_probe(dev, PTR_ERR(priv->misc),
> "unable to find misc csr registers\n");
> --
> 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 net-next] doc: generic phy: update generic PHY documentation
From: Vladimir Oltean @ 2026-02-11 15:48 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Vinod Koul, Neil Armstrong, Jonathan Corbet, linux-doc, linux-phy
In-Reply-To: <E1vo0mF-00000007kbg-1OeA@rmk-PC.armlinux.org.uk>
On Thu, Feb 05, 2026 at 02:56:15PM +0000, Russell King (Oracle) wrote:
> Update the generic PHY documentation as a result of the discussion for
> the s32g submission.
>
> Link: https://lore.kernel.org/r/aXtvDn_-pCuKPrnf@vaman
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
> I didn't get any replies to my follow-up question to Vinod:
>
> Please also indicate in the documentation whether changing the submode
> of the serdes (particularly for ethernet) is permitted without doing a
> phy_power_down()..phy_power_up() dance around the phy_set_mode_ext()
> call.
There's certainly nothing *not* permitting that call sequence.
> I also didn't get any response to:
>
> For drivers such as stmmac, it will be important that details such as
> whether phy_est_mode*() can be called with the PHY powered on are
> riveted down and not left up to the generic PHY driver author - without
> that, generic PHYs basically aren't usable from SoC/platform
> independent code, and stmmac has bazillions of platform specific glue
> already because of (a) bad code structuring and (b) lack of
> generalisation through standardised interfaces that abstract platform
> differences.
>
> I want to be able for core stmmac code, or even phylink code (which
> is even more platform generic) to be able to make use of generic PHY
> stuff, but if the calls that can be made into generic PHY are platform
> dependent, that is a blocking issue against that, and makes me question
> why we have the generic PHY subsystem... it's not very generic if it
> exposes the differences of each implementation to users of its
> interfaces.
It may well be that the "one consumer, multiple PHY providers, requiring
unified behaviour" situation you bring up is sufficiently unique here,
with stmmac/phylink, that local conventions are not sufficient.
I'm not sure that precise answers exist for your questions. Rather,
it's best if you could lay out common sense requirements, and generic
PHY reviewers will make sure they are followed.
As far as the framework is concerned, power and mode are fundamentally
decoupled, so I think the documentation is actually muddying the waters,
more than anything, by talking about a preferred calling order.
If there's any connection between power and mode, it should be handled
internally by the PHY provider driver.
> Documentation/driver-api/phy/phy.rst | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/driver-api/phy/phy.rst b/Documentation/driver-api/phy/phy.rst
> index 719a2b3fd2ab..cf73e4fb0951 100644
> --- a/Documentation/driver-api/phy/phy.rst
> +++ b/Documentation/driver-api/phy/phy.rst
> @@ -142,6 +142,7 @@ Order of API calls
>
> [devm_][of_]phy_get()
> phy_init()
> + [phy_set_mode[_ext]()]
> phy_power_on()
> [phy_set_mode[_ext]()]
> ...
> @@ -154,7 +155,7 @@ but controllers should always call these functions to be compatible with other
> PHYs. Some PHYs may require :c:func:`phy_set_mode <phy_set_mode_ext>`, while
> others may use a default mode (typically configured via devicetree or other
> firmware). For compatibility, you should always call this function if you know
> -what mode you will be using. Generally, this function should be called after
> +what mode you will be using. Generally, this function should be called before
> :c:func:`phy_power_on`, although some PHY drivers may allow it at any time.
My 2 cents: I would actually remove any reference to any sort of preferred
call order. There's nothing in the framework to back up such a concept.
Just say that it is recommended for PHY provider drivers to not rely on
a particular calling order, such that PHY consumers have the freedom to
choose depending on what suits them best.
>
> Releasing a reference to the PHY
> --
> 2.47.3
>
>
> --
> 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 next] phy: renesas: rcar-gen3-usb2: Drop local devm_mux_state_get_optional()
From: Vinod Koul @ 2026-02-11 16:17 UTC (permalink / raw)
To: Ulf Hansson
Cc: Geert Uytterhoeven, Vladimir Oltean, Yoshihiro Shimoda,
Neil Armstrong, Josua Mayer, Wolfram Sang, Tommaso Merciai,
linux-phy, linux-mmc, linux-renesas-soc, linux-next, linux-kernel
In-Reply-To: <CAPDyKFpY2X8hephSfHq7rj_DaKX76ZSkWSCYXrGTEBUFHkvOzg@mail.gmail.com>
On 10-02-26, 14:34, Ulf Hansson wrote:
> On Tue, 10 Feb 2026 at 11:53, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
> >
> > Now the mux core provides devm_mux_state_get_optional():
> >
> > drivers/phy/renesas/phy-rcar-gen3-usb2.c:944:1: error: static declaration of ‘devm_mux_state_get_optional’ follows non-static
> > declaration
> > 944 | devm_mux_state_get_optional(struct device *dev, const char *mux_name)
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > In file included from drivers/phy/renesas/phy-rcar-gen3-usb2.c:20:
> > include/linux/mux/consumer.h:64:19: note: previous declaration of ‘devm_mux_state_get_optional’ with type ‘struct mux_state *(struct device *, const char *)’
> > 64 | struct mux_state *devm_mux_state_get_optional(struct device *dev, const char *mux_name);
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Fix this by dropping the temporary local wrapper.
> >
> > Fixes: ad314348ceb4fe1f ("mux: Add helper functions for getting optional and selected mux-state")
> > Fixes: 8bb92fd7a0407792 ("phy: renesas: rcar-gen3-usb2: Use mux-state for phyrst management")
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Thanks Geert for helping out!
>
> > ---
> > - ad314348ceb4fe1f is in mmc/next, and a PR has already been sent
> > https://lore.kernel.org/20260209133441.556464-1-ulf.hansson@linaro.org
> > - 8bb92fd7a0407792 is in phy/next
>
> Vinod, do you want to pick up the $subject patch as a fix for 7.0-rc1
> or do you prefer me to handle it?
Should I drop the 8bb92fd7a0407792 and it makes things easier for
everyone and then we can pick fixed commit for 7.1 cycle..
Does that work for everyone. I was about to send PR, will hold off for a
bit.
Thanks
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH next] phy: renesas: rcar-gen3-usb2: Drop local devm_mux_state_get_optional()
From: kernel test robot @ 2026-02-11 16:21 UTC (permalink / raw)
To: Geert Uytterhoeven, Yoshihiro Shimoda, Vinod Koul, Neil Armstrong,
Josua Mayer, Ulf Hansson, Wolfram Sang, Tommaso Merciai
Cc: llvm, oe-kbuild-all, linux-phy, linux-mmc, linux-renesas-soc,
linux-next, linux-kernel, Geert Uytterhoeven
In-Reply-To: <67c8c4f9bf9f09fd0c13daedef27b82ff389ddfb.1770720452.git.geert+renesas@glider.be>
Hi Geert,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20260209]
url: https://github.com/intel-lab-lkp/linux/commits/Geert-Uytterhoeven/phy-renesas-rcar-gen3-usb2-Drop-local-devm_mux_state_get_optional/20260210-185437
base: next-20260209
patch link: https://lore.kernel.org/r/67c8c4f9bf9f09fd0c13daedef27b82ff389ddfb.1770720452.git.geert%2Brenesas%40glider.be
patch subject: [PATCH next] phy: renesas: rcar-gen3-usb2: Drop local devm_mux_state_get_optional()
config: riscv-allyesconfig (https://download.01.org/0day-ci/archive/20260212/202602120031.iupmQxdk-lkp@intel.com/config)
compiler: clang version 16.0.6 (https://github.com/llvm/llvm-project 7cbf1a2591520c2491aa35339f227775f4d3adf6)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260212/202602120031.iupmQxdk-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602120031.iupmQxdk-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/phy/renesas/phy-rcar-gen3-usb2.c:1029:14: error: call to undeclared function 'devm_mux_state_get_optional'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
mux_state = devm_mux_state_get_optional(dev, NULL);
^
drivers/phy/renesas/phy-rcar-gen3-usb2.c:1029:14: note: did you mean 'devm_regulator_get_optional'?
include/linux/regulator/consumer.h:163:32: note: 'devm_regulator_get_optional' declared here
struct regulator *__must_check devm_regulator_get_optional(struct device *dev,
^
>> drivers/phy/renesas/phy-rcar-gen3-usb2.c:1029:12: error: incompatible integer to pointer conversion assigning to 'struct mux_state *' from 'int' [-Wint-conversion]
mux_state = devm_mux_state_get_optional(dev, NULL);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.
vim +/devm_mux_state_get_optional +1029 drivers/phy/renesas/phy-rcar-gen3-usb2.c
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 946
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 947 static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 948 {
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 949 struct device *dev = &pdev->dev;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 950 struct rcar_gen3_chan *channel;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 951 struct phy_provider *provider;
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 952 struct mux_state *mux_state;
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 953 int ret = 0, i, irq;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 954
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 955 if (!dev->of_node) {
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 956 dev_err(dev, "This driver needs device tree\n");
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 957 return -EINVAL;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 958 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 959
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 960 channel = devm_kzalloc(dev, sizeof(*channel), GFP_KERNEL);
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 961 if (!channel)
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 962 return -ENOMEM;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 963
0b5604affbec02 drivers/phy/renesas/phy-rcar-gen3-usb2.c Chunfeng Yun 2020-11-06 964 channel->base = devm_platform_ioremap_resource(pdev, 0);
801a69c787812f drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 965 if (IS_ERR(channel->base))
801a69c787812f drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 966 return PTR_ERR(channel->base);
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 967
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 968 channel->dr_mode = rcar_gen3_get_dr_mode(dev->of_node);
73801b90a38ff1 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 969 if (channel->dr_mode != USB_DR_MODE_UNKNOWN) {
979b519c7a1bff drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 970 channel->is_otg_channel = true;
8dde0008ffc9e2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 971 channel->uses_otg_pins = !of_property_read_bool(dev->of_node,
8dde0008ffc9e2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 972 "renesas,no-otg-pins");
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 973 channel->extcon = devm_extcon_dev_allocate(dev,
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 974 rcar_gen3_phy_cable);
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 975 if (IS_ERR(channel->extcon))
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 976 return PTR_ERR(channel->extcon);
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 977
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 978 ret = devm_extcon_dev_register(dev, channel->extcon);
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 979 if (ret < 0) {
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 980 dev_err(dev, "Failed to register extcon\n");
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 981 return ret;
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 982 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 983 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 984
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 985 channel->rstc = devm_reset_control_array_get_optional_shared(dev);
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 986 if (IS_ERR(channel->rstc))
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 987 return PTR_ERR(channel->rstc);
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 988
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 989 ret = reset_control_deassert(channel->rstc);
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 990 if (ret)
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 991 return ret;
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 992
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 993 ret = devm_add_action_or_reset(dev, rcar_gen3_reset_assert, channel->rstc);
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 994 if (ret)
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 995 return ret;
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 996
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 997 /*
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 998 * devm_phy_create() will call pm_runtime_enable(&phy->dev);
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 999 * And then, phy-core will manage runtime pm for this device.
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 1000 */
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1001 ret = devm_pm_runtime_enable(dev);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1002 if (ret)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1003 return dev_err_probe(dev, ret, "Failed to enable pm_runtime\n");
b0512a6ec0cd6d drivers/phy/renesas/phy-rcar-gen3-usb2.c Biju Das 2021-07-27 1004
f75806d26318c0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Lad Prabhakar 2025-08-08 1005 channel->phy_data = of_device_get_match_data(dev);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1006 if (!channel->phy_data)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1007 return -EINVAL;
5d8042e95fd471 drivers/phy/renesas/phy-rcar-gen3-usb2.c Biju Das 2019-04-10 1008
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1009 platform_set_drvdata(pdev, channel);
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1010 channel->dev = dev;
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1011
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1012 ret = rcar_gen3_phy_usb2_init_bus(channel);
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1013 if (ret)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1014 return ret;
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1015
55a387ebb9219c drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1016 spin_lock_init(&channel->lock);
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1017 for (i = 0; i < NUM_OF_PHYS; i++) {
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1018 channel->rphys[i].phy = devm_phy_create(dev, NULL,
f75806d26318c0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Lad Prabhakar 2025-08-08 1019 channel->phy_data->phy_usb2_ops);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1020 if (IS_ERR(channel->rphys[i].phy))
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1021 return dev_err_probe(dev, PTR_ERR(channel->rphys[i].phy),
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1022 "Failed to create USB2 PHY\n");
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1023
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1024 channel->rphys[i].ch = channel;
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1025 channel->rphys[i].int_enable_bits = rcar_gen3_int_enable[i];
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1026 phy_set_drvdata(channel->rphys[i].phy, &channel->rphys[i]);
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1027 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 1028
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 @1029 mux_state = devm_mux_state_get_optional(dev, NULL);
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1030 if (IS_ERR(mux_state))
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1031 return PTR_ERR(mux_state);
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1032 if (mux_state) {
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1033 ret = mux_state_select(mux_state);
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1034 if (ret)
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1035 return dev_err_probe(dev, ret, "Failed to select USB mux\n");
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1036
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1037 ret = devm_add_action_or_reset(dev, rcar_gen3_phy_mux_state_deselect,
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1038 mux_state);
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1039 if (ret)
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1040 return dev_err_probe(dev, ret,
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1041 "Failed to register USB mux state deselect\n");
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1042 }
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1043
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1044 if (channel->phy_data->no_adp_ctrl && channel->is_otg_channel) {
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1045 ret = rcar_gen3_phy_usb2_vbus_regulator_register(channel);
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1046 if (ret)
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1047 return ret;
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1048 } else {
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1049 channel->vbus = devm_regulator_get_optional(dev, "vbus");
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1050 }
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1051 if (IS_ERR(channel->vbus)) {
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1052 if (PTR_ERR(channel->vbus) == -EPROBE_DEFER)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1053 return PTR_ERR(channel->vbus);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1054
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1055 channel->vbus = NULL;
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1056 }
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1057
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1058 irq = platform_get_irq_optional(pdev, 0);
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1059 if (irq < 0 && irq != -ENXIO) {
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1060 return irq;
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1061 } else if (irq > 0) {
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1062 INIT_WORK(&channel->work, rcar_gen3_phy_usb2_work);
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1063 ret = devm_request_irq(dev, irq, rcar_gen3_phy_usb2_irq,
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1064 IRQF_SHARED, dev_name(dev), channel);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1065 if (ret < 0)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1066 return dev_err_probe(dev, ret,
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1067 "Failed to request irq (%d)\n",
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1068 irq);
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1069 }
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1070
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1071 provider = devm_of_phy_provider_register(dev, rcar_gen3_phy_usb2_xlate);
9bb86777fb71ee drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-11-09 1072 if (IS_ERR(provider)) {
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1073 return dev_err_probe(dev, PTR_ERR(provider),
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1074 "Failed to register PHY provider\n");
979b519c7a1bff drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 1075 } else if (channel->is_otg_channel) {
9bb86777fb71ee drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-11-09 1076 ret = device_create_file(dev, &dev_attr_role);
9bb86777fb71ee drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-11-09 1077 if (ret < 0)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1078 return ret;
9bb86777fb71ee drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-11-09 1079 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 1080
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 1081 return 0;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 1082 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 1083
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH next] phy: renesas: rcar-gen3-usb2: Drop local devm_mux_state_get_optional()
From: Geert Uytterhoeven @ 2026-02-11 16:30 UTC (permalink / raw)
To: Vinod Koul
Cc: Ulf Hansson, Vladimir Oltean, Yoshihiro Shimoda, Neil Armstrong,
Josua Mayer, Wolfram Sang, Tommaso Merciai, linux-phy, linux-mmc,
linux-renesas-soc, linux-next, linux-kernel
In-Reply-To: <aYyrsPTH1923jV7y@vaman>
Hi Vinod,
On Wed, 11 Feb 2026 at 17:17, Vinod Koul <vkoul@kernel.org> wrote:
> On 10-02-26, 14:34, Ulf Hansson wrote:
> > On Tue, 10 Feb 2026 at 11:53, Geert Uytterhoeven
> > <geert+renesas@glider.be> wrote:
> > > Now the mux core provides devm_mux_state_get_optional():
> > >
> > > drivers/phy/renesas/phy-rcar-gen3-usb2.c:944:1: error: static declaration of ‘devm_mux_state_get_optional’ follows non-static
> > > declaration
> > > 944 | devm_mux_state_get_optional(struct device *dev, const char *mux_name)
> > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > In file included from drivers/phy/renesas/phy-rcar-gen3-usb2.c:20:
> > > include/linux/mux/consumer.h:64:19: note: previous declaration of ‘devm_mux_state_get_optional’ with type ‘struct mux_state *(struct device *, const char *)’
> > > 64 | struct mux_state *devm_mux_state_get_optional(struct device *dev, const char *mux_name);
> > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > Fix this by dropping the temporary local wrapper.
> > >
> > > Fixes: ad314348ceb4fe1f ("mux: Add helper functions for getting optional and selected mux-state")
> > > Fixes: 8bb92fd7a0407792 ("phy: renesas: rcar-gen3-usb2: Use mux-state for phyrst management")
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > Thanks Geert for helping out!
> >
> > > ---
> > > - ad314348ceb4fe1f is in mmc/next, and a PR has already been sent
> > > https://lore.kernel.org/20260209133441.556464-1-ulf.hansson@linaro.org
> > > - 8bb92fd7a0407792 is in phy/next
> >
> > Vinod, do you want to pick up the $subject patch as a fix for 7.0-rc1
> > or do you prefer me to handle it?
>
> Should I drop the 8bb92fd7a0407792 and it makes things easier for
> everyone and then we can pick fixed commit for 7.1 cycle..
>
> Does that work for everyone. I was about to send PR, will hold off for a
> bit.
Alternatively, you can mention the semantic conflict in your PR to Linus,
and ask him to fold my patch into the merge commit.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next] doc: generic phy: update generic PHY documentation
From: Russell King (Oracle) @ 2026-02-11 18:15 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, Jonathan Corbet, linux-doc, linux-phy
In-Reply-To: <20260211154839.lbh4uovxr5b5s4nv@skbuf>
On Wed, Feb 11, 2026 at 05:48:39PM +0200, Vladimir Oltean wrote:
> My 2 cents: I would actually remove any reference to any sort of preferred
> call order. There's nothing in the framework to back up such a concept.
> Just say that it is recommended for PHY provider drivers to not rely on
> a particular calling order, such that PHY consumers have the freedom to
> choose depending on what suits them best.
Sending out this patch was a last ditch attempt to get a response to
improve the "generic" PHY subsystem, However, as the issue is now
almost two weeks old, and the current patch series causes a regression
according to Mohd's testing, I've rewritten the series to be a finer
set of smaller incremental changes.
This has meant dropping the idea of using the "generic" PHY subsystem
in generic code, because as "generic" PHY drivers are currently
written, that's just impossible given the current state of "generic"
PHY.
There are "generic" PHY drivers that require to be powered up for
any of the phy_set_*() functions to not error out. There are also
"generic" PHY drivers that require the PHY to be powered down
before calling phy_set_*() before the new setting taking effect
at PHY power up time. In this group there are drivers that error
out if phy_set_*() is called while the PHY is powered, and there
are drivers that silently accept the call, returning success, but
do not change the PHY mode.
This makes it pretty much impossible for platform independent code to
know the correct order to call the functions, and what to do if an
error or success is returned from any particular API call.
In other words, it's a trainwreck as currently implemented, and this
was my attempt to try and get some consistency.
--
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] phy: ti: j721e-wiz: Fix device_node leak in wiz_get_lane_phy_types()
From: Felix Gu @ 2026-02-11 18:47 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, Kishon Vijay Abraham I, Jyri Sarha,
linux-phy, linux-kernel
In-Reply-To: <20260210203018.dr6dwj55aob3phsd@skbuf>
On Wed, Feb 11, 2026 at 4:30 AM Vladimir Oltean <olteanv@gmail.com> wrote:
>
> Hi Felix,
>
> On Wed, Feb 11, 2026 at 02:14:11AM +0800, Felix Gu wrote:
> > The 'serdes' device_node is obtained using of_get_child_by_name(),
> > which increments the reference count. However, it is never put,
> > leading to a memory leak.
> >
> > Use the __free(device_node) attribute to automatically decrement
> > the reference count when the 'serdes' variable goes out of scope.
> >
> > Fixes: 7ae14cf581f2 ("phy: ti: j721e-wiz: Implement DisplayPort mode to the wiz driver")
> > Signed-off-by: Felix Gu <ustc.gu@gmail.com>
> > ---
> > drivers/phy/ti/phy-j721e-wiz.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
> > index 12a19bf2875c..904541e9138e 100644
> > --- a/drivers/phy/ti/phy-j721e-wiz.c
> > +++ b/drivers/phy/ti/phy-j721e-wiz.c
> > @@ -1407,9 +1407,8 @@ MODULE_DEVICE_TABLE(of, wiz_id_table);
> >
> > static int wiz_get_lane_phy_types(struct device *dev, struct wiz *wiz)
> > {
> > - struct device_node *serdes;
> > -
> > - serdes = of_get_child_by_name(dev->of_node, "serdes");
> > + struct device_node *serdes __free(device_node) =
> > + of_get_child_by_name(dev->of_node, "serdes");
> > if (!serdes) {
> > dev_err(dev, "%s: Getting \"serdes\"-node failed\n", __func__);
> > return -EINVAL;
> >
> > ---
> > base-commit: 193579fe01389bc21aff0051d13f24e8ea95b47d
> > change-id: 20260204-wiz-9a67604a034f
> >
> > Best regards,
> > --
> > Felix Gu <ustc.gu@gmail.com>
> >
> >
>
> You are fixing a bug from 2020 (v5.8) with functionality introduced in 2023,
> creating avoidable headache for backporters (the oldest supported LTS is
> 5.10, where the cleanup API does not exist). Could we reimplement this
> the "normal" of_node_put() way?
>
> I realize this is not netdev, but this piece of advice from
> Documentation/process/maintainer-netdev.rst regarding use in drivers
> seems common sense and relevant here:
>
> Low level cleanup constructs (such as ``__free()``) can be used when building
> APIs and helpers, especially scoped iterators. However, direct use of
> ``__free()`` within networking core and drivers is discouraged.
> Similar guidance applies to declaring variables mid-function.
Hi Vladimir,
I will fix it in V2.
Thanks,
Felix
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next] doc: generic phy: update generic PHY documentation
From: Vladimir Oltean @ 2026-02-11 19:30 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Vinod Koul, Neil Armstrong, Jonathan Corbet, linux-doc, linux-phy
In-Reply-To: <aYzHL1qwew5p-xoq@shell.armlinux.org.uk>
On Wed, Feb 11, 2026 at 06:15:11PM +0000, Russell King (Oracle) wrote:
> On Wed, Feb 11, 2026 at 05:48:39PM +0200, Vladimir Oltean wrote:
> > My 2 cents: I would actually remove any reference to any sort of preferred
> > call order. There's nothing in the framework to back up such a concept.
> > Just say that it is recommended for PHY provider drivers to not rely on
> > a particular calling order, such that PHY consumers have the freedom to
> > choose depending on what suits them best.
>
> Sending out this patch was a last ditch attempt to get a response to
> improve the "generic" PHY subsystem, However, as the issue is now
> almost two weeks old, and the current patch series causes a regression
> according to Mohd's testing, I've rewritten the series to be a finer
> set of smaller incremental changes.
>
> This has meant dropping the idea of using the "generic" PHY subsystem
> in generic code, because as "generic" PHY drivers are currently
> written, that's just impossible given the current state of "generic"
> PHY.
>
> There are "generic" PHY drivers that require to be powered up for
> any of the phy_set_*() functions to not error out. There are also
> "generic" PHY drivers that require the PHY to be powered down
> before calling phy_set_*() before the new setting taking effect
> at PHY power up time. In this group there are drivers that error
> out if phy_set_*() is called while the PHY is powered, and there
> are drivers that silently accept the call, returning success, but
> do not change the PHY mode.
Are we talking about PHY_MODE_ETHERNET generic PHYs here, or in general?
> This makes it pretty much impossible for platform independent code to
> know the correct order to call the functions, and what to do if an
> error or success is returned from any particular API call.
>
> In other words, it's a trainwreck as currently implemented, and this
> was my attempt to try and get some consistency.
Do you have a list of such PHYs relevant to phylink? We can still
document the expectation, and modify them.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next] doc: generic phy: update generic PHY documentation
From: Vladimir Oltean @ 2026-02-11 19:45 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Vinod Koul, Neil Armstrong, Jonathan Corbet, linux-doc, linux-phy
In-Reply-To: <20260211193006.ad2piivyoqhvg22r@skbuf>
On Wed, Feb 11, 2026 at 09:30:06PM +0200, Vladimir Oltean wrote:
> On Wed, Feb 11, 2026 at 06:15:11PM +0000, Russell King (Oracle) wrote:
> > On Wed, Feb 11, 2026 at 05:48:39PM +0200, Vladimir Oltean wrote:
> > > My 2 cents: I would actually remove any reference to any sort of preferred
> > > call order. There's nothing in the framework to back up such a concept.
> > > Just say that it is recommended for PHY provider drivers to not rely on
> > > a particular calling order, such that PHY consumers have the freedom to
> > > choose depending on what suits them best.
> >
> > Sending out this patch was a last ditch attempt to get a response to
> > improve the "generic" PHY subsystem, However, as the issue is now
> > almost two weeks old, and the current patch series causes a regression
> > according to Mohd's testing, I've rewritten the series to be a finer
> > set of smaller incremental changes.
> >
> > This has meant dropping the idea of using the "generic" PHY subsystem
> > in generic code, because as "generic" PHY drivers are currently
> > written, that's just impossible given the current state of "generic"
> > PHY.
> >
> > There are "generic" PHY drivers that require to be powered up for
> > any of the phy_set_*() functions to not error out. There are also
> > "generic" PHY drivers that require the PHY to be powered down
> > before calling phy_set_*() before the new setting taking effect
> > at PHY power up time. In this group there are drivers that error
> > out if phy_set_*() is called while the PHY is powered, and there
> > are drivers that silently accept the call, returning success, but
> > do not change the PHY mode.
>
> Are we talking about PHY_MODE_ETHERNET generic PHYs here, or in general?
>
> > This makes it pretty much impossible for platform independent code to
> > know the correct order to call the functions, and what to do if an
> > error or success is returned from any particular API call.
> >
> > In other words, it's a trainwreck as currently implemented, and this
> > was my attempt to try and get some consistency.
>
> Do you have a list of such PHYs relevant to phylink? We can still
> document the expectation, and modify them.
To (partially) answer my own question, here is what I found so far:
commit 5cb630925b49dd13bf3aa43f299b11615c8fe9cd
Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: Wed Feb 1 22:14:53 2023 +0900
net: renesas: rswitch: Add phy_power_{on,off}() calling
Some Ethernet PHYs (like marvell10g) will decide the host interface
mode by the media-side speed. So, the rswitch driver needs to
initialize one of the Ethernet SERDES (r8a779f0-eth-serdes) ports
after linked the Ethernet PHY up. The r8a779f0-eth-serdes driver has
.init() for initializing all ports and .power_on() for initializing
each port. So, add phy_power_{on,off} calling for it.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This needs to be changed, for sure.
I'll take a closer look tomorrow at the rest and see how bad the
situation is overall.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH net-next] doc: generic phy: update generic PHY documentation
From: Russell King (Oracle) @ 2026-02-11 20:31 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, Jonathan Corbet, linux-doc, linux-phy
In-Reply-To: <20260211193006.ad2piivyoqhvg22r@skbuf>
On Wed, Feb 11, 2026 at 09:30:06PM +0200, Vladimir Oltean wrote:
> On Wed, Feb 11, 2026 at 06:15:11PM +0000, Russell King (Oracle) wrote:
> > On Wed, Feb 11, 2026 at 05:48:39PM +0200, Vladimir Oltean wrote:
> > > My 2 cents: I would actually remove any reference to any sort of preferred
> > > call order. There's nothing in the framework to back up such a concept.
> > > Just say that it is recommended for PHY provider drivers to not rely on
> > > a particular calling order, such that PHY consumers have the freedom to
> > > choose depending on what suits them best.
> >
> > Sending out this patch was a last ditch attempt to get a response to
> > improve the "generic" PHY subsystem, However, as the issue is now
> > almost two weeks old, and the current patch series causes a regression
> > according to Mohd's testing, I've rewritten the series to be a finer
> > set of smaller incremental changes.
> >
> > This has meant dropping the idea of using the "generic" PHY subsystem
> > in generic code, because as "generic" PHY drivers are currently
> > written, that's just impossible given the current state of "generic"
> > PHY.
> >
> > There are "generic" PHY drivers that require to be powered up for
> > any of the phy_set_*() functions to not error out. There are also
> > "generic" PHY drivers that require the PHY to be powered down
> > before calling phy_set_*() before the new setting taking effect
> > at PHY power up time. In this group there are drivers that error
> > out if phy_set_*() is called while the PHY is powered, and there
> > are drivers that silently accept the call, returning success, but
> > do not change the PHY mode.
>
> Are we talking about PHY_MODE_ETHERNET generic PHYs here, or in general?
PHY_MODE_ETHERNET PHYs.
> > This makes it pretty much impossible for platform independent code to
> > know the correct order to call the functions, and what to do if an
> > error or success is returned from any particular API call.
> >
> > In other words, it's a trainwreck as currently implemented, and this
> > was my attempt to try and get some consistency.
>
> Do you have a list of such PHYs relevant to phylink? We can still
> document the expectation, and modify them.
These are the generic PHYs used for ethernet, so they are potential
cases for phylink to drive. They were found via:
grep ETHERNET drivers/phy -rl | xargs grep -l power_on
r8a779f0-ether-serdes: r8a779f0_eth_serdes_set_mode() records the
state, returning success, with no hardware programming. All hardware
programming for the desired mode is done via phy_power_on() call.
This driver requires the PHY to be powered down before phy_set_mode*()
otherwise it will accept the new mode but not reconfigure the hardware.
phy-mvebu-cp110-comphy: mvebu_comphy_set_mode() records the state in
struct members and does nothing more, returning success. This
requires the PHY to be powered down before phy_set_mode().
This driver requires the PHY to be powered down before phy_set_mode*()
otherwise it will accept the new mode but not reconfigure the hardware.
phy-mvebu-a3700-comphy: mvebu_a3700_comphy_set_mode() errors out if
mode is changed with PHY powered up:
/* Mode cannot be changed while the PHY is powered on */
if (phy->power_count &&
(lane->mode != mode || lane->submode != submode))
return -EBUSY;
This driver requires the PHY to be powered down before phy_set_mode*()
otherwise it will error out.
phy-fsl-lynx-28g: lynx_28g_set_mode() powers down the PHY if necessary,
sets the mode, before powering it back up.
This is the only driver that will tolerate phy_power_*() vs
phy_set_mode*() in any order.
phy-qcom-sgmii-eth: doesn't implement phy_set_mode*() but instead
implements phy_set_speed() and phy_calibrate(). phy_set_speed()
sets the mode and immediately calibrates, which presumably requires
the clocks enabled by qcom_dwmac_sgmii_phy_power_on(). No check
for PHY being powered, so my guess is that calling phy_set_speed()
with the PHY powered down will cause the status polling in
qcom_dwmac_sgmii_phy_calibrate() to time out.
This driver requires phy_power_on() before phy_set_speed().
sparx5_serdes: phy_power_*() controls power down mode, no check
in sparx5_serdes_set_mode() whether powered up, but config function
checks for e.g. PLL lock, which probably won't be locked if powered
down. Failures aren't propagated to the API caller.
This driver requires phy_power_on() before phy_set_mode*().
phy-mtk-xfi-tphy: while phy_power_*() controls clocks, it isn't
obvious whether these are required before mtk_xfi_tphy_setup() is
invoked. There are calls to usleep() implying a need to wait for
things to happen before the next register write, which presumably
require the clock to be running.
My guess is, this driver requires phy_power_on() before phy_set_mode*().
Categorisation of drivers:
drivers requiring powered down PHY before phy_set_mode*(), but are
silent if not: 2
drivers requiring powered down PHY before phy_set_mode*(), but error
out if not: 1
drivers that allow any power state before phy_set_mode*(): 1
drivers that do not implement .power_*() methods, allowing any
power state, but presumably require the phy_set_mode*() call to
setup the hardware: 5
drivers requiring powered up PHY before phy_set_mode*(): 3
So, the summary is... only _one_ driver allows the calls in any order.
The other 11 drivers are... stick a pin in the donkey and depending
on where the pin ends up determines the appropriate order that the
generic PHY APIs must be called for the driver to work correctly.
I think you'll agree that this is a very sorry state of affairs.
This is exactly why I think there needs to be better documentation.
I'm not sure that some kind of test code to validate the API would
work, because you'd need some way to test whether the PHY were in a
functional state, and that's difficult without the help of the
ethernet MAC.
--
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 next] phy: renesas: rcar-gen3-usb2: Drop local devm_mux_state_get_optional()
From: kernel test robot @ 2026-02-12 0:39 UTC (permalink / raw)
To: Geert Uytterhoeven, Yoshihiro Shimoda, Vinod Koul, Neil Armstrong,
Josua Mayer, Ulf Hansson, Wolfram Sang, Tommaso Merciai
Cc: oe-kbuild-all, linux-phy, linux-mmc, linux-renesas-soc,
linux-next, linux-kernel, Geert Uytterhoeven
In-Reply-To: <67c8c4f9bf9f09fd0c13daedef27b82ff389ddfb.1770720452.git.geert+renesas@glider.be>
Hi Geert,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20260209]
url: https://github.com/intel-lab-lkp/linux/commits/Geert-Uytterhoeven/phy-renesas-rcar-gen3-usb2-Drop-local-devm_mux_state_get_optional/20260210-185437
base: next-20260209
patch link: https://lore.kernel.org/r/67c8c4f9bf9f09fd0c13daedef27b82ff389ddfb.1770720452.git.geert%2Brenesas%40glider.be
patch subject: [PATCH next] phy: renesas: rcar-gen3-usb2: Drop local devm_mux_state_get_optional()
config: arm-allyesconfig (https://download.01.org/0day-ci/archive/20260212/202602120804.JhBk63IH-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260212/202602120804.JhBk63IH-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602120804.JhBk63IH-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/phy/renesas/phy-rcar-gen3-usb2.c: In function 'rcar_gen3_phy_usb2_probe':
>> drivers/phy/renesas/phy-rcar-gen3-usb2.c:1029:21: error: implicit declaration of function 'devm_mux_state_get_optional'; did you mean 'devm_regulator_get_optional'? [-Wimplicit-function-declaration]
1029 | mux_state = devm_mux_state_get_optional(dev, NULL);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
| devm_regulator_get_optional
>> drivers/phy/renesas/phy-rcar-gen3-usb2.c:1029:19: error: assignment to 'struct mux_state *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
1029 | mux_state = devm_mux_state_get_optional(dev, NULL);
| ^
vim +1029 drivers/phy/renesas/phy-rcar-gen3-usb2.c
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 946
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 947 static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 948 {
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 949 struct device *dev = &pdev->dev;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 950 struct rcar_gen3_chan *channel;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 951 struct phy_provider *provider;
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 952 struct mux_state *mux_state;
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 953 int ret = 0, i, irq;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 954
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 955 if (!dev->of_node) {
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 956 dev_err(dev, "This driver needs device tree\n");
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 957 return -EINVAL;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 958 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 959
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 960 channel = devm_kzalloc(dev, sizeof(*channel), GFP_KERNEL);
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 961 if (!channel)
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 962 return -ENOMEM;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 963
0b5604affbec02 drivers/phy/renesas/phy-rcar-gen3-usb2.c Chunfeng Yun 2020-11-06 964 channel->base = devm_platform_ioremap_resource(pdev, 0);
801a69c787812f drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 965 if (IS_ERR(channel->base))
801a69c787812f drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 966 return PTR_ERR(channel->base);
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 967
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 968 channel->dr_mode = rcar_gen3_get_dr_mode(dev->of_node);
73801b90a38ff1 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 969 if (channel->dr_mode != USB_DR_MODE_UNKNOWN) {
979b519c7a1bff drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 970 channel->is_otg_channel = true;
8dde0008ffc9e2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 971 channel->uses_otg_pins = !of_property_read_bool(dev->of_node,
8dde0008ffc9e2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 972 "renesas,no-otg-pins");
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 973 channel->extcon = devm_extcon_dev_allocate(dev,
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 974 rcar_gen3_phy_cable);
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 975 if (IS_ERR(channel->extcon))
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 976 return PTR_ERR(channel->extcon);
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 977
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 978 ret = devm_extcon_dev_register(dev, channel->extcon);
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 979 if (ret < 0) {
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 980 dev_err(dev, "Failed to register extcon\n");
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 981 return ret;
2b38543c8db1c7 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-04-29 982 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 983 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 984
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 985 channel->rstc = devm_reset_control_array_get_optional_shared(dev);
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 986 if (IS_ERR(channel->rstc))
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 987 return PTR_ERR(channel->rstc);
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 988
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 989 ret = reset_control_deassert(channel->rstc);
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 990 if (ret)
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 991 return ret;
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 992
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 993 ret = devm_add_action_or_reset(dev, rcar_gen3_reset_assert, channel->rstc);
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 994 if (ret)
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 995 return ret;
942a7a6bf4c6a8 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-11-19 996
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 997 /*
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 998 * devm_phy_create() will call pm_runtime_enable(&phy->dev);
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 999 * And then, phy-core will manage runtime pm for this device.
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 1000 */
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1001 ret = devm_pm_runtime_enable(dev);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1002 if (ret)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1003 return dev_err_probe(dev, ret, "Failed to enable pm_runtime\n");
b0512a6ec0cd6d drivers/phy/renesas/phy-rcar-gen3-usb2.c Biju Das 2021-07-27 1004
f75806d26318c0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Lad Prabhakar 2025-08-08 1005 channel->phy_data = of_device_get_match_data(dev);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1006 if (!channel->phy_data)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1007 return -EINVAL;
5d8042e95fd471 drivers/phy/renesas/phy-rcar-gen3-usb2.c Biju Das 2019-04-10 1008
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1009 platform_set_drvdata(pdev, channel);
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1010 channel->dev = dev;
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1011
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1012 ret = rcar_gen3_phy_usb2_init_bus(channel);
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1013 if (ret)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1014 return ret;
4eae16375357a2 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2024-08-22 1015
55a387ebb9219c drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1016 spin_lock_init(&channel->lock);
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1017 for (i = 0; i < NUM_OF_PHYS; i++) {
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1018 channel->rphys[i].phy = devm_phy_create(dev, NULL,
f75806d26318c0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Lad Prabhakar 2025-08-08 1019 channel->phy_data->phy_usb2_ops);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1020 if (IS_ERR(channel->rphys[i].phy))
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1021 return dev_err_probe(dev, PTR_ERR(channel->rphys[i].phy),
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1022 "Failed to create USB2 PHY\n");
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1023
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1024 channel->rphys[i].ch = channel;
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1025 channel->rphys[i].int_enable_bits = rcar_gen3_int_enable[i];
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1026 phy_set_drvdata(channel->rphys[i].phy, &channel->rphys[i]);
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1027 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 1028
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 @1029 mux_state = devm_mux_state_get_optional(dev, NULL);
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1030 if (IS_ERR(mux_state))
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1031 return PTR_ERR(mux_state);
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1032 if (mux_state) {
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1033 ret = mux_state_select(mux_state);
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1034 if (ret)
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1035 return dev_err_probe(dev, ret, "Failed to select USB mux\n");
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1036
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1037 ret = devm_add_action_or_reset(dev, rcar_gen3_phy_mux_state_deselect,
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1038 mux_state);
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1039 if (ret)
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1040 return dev_err_probe(dev, ret,
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1041 "Failed to register USB mux state deselect\n");
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1042 }
8bb92fd7a04077 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1043
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1044 if (channel->phy_data->no_adp_ctrl && channel->is_otg_channel) {
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1045 ret = rcar_gen3_phy_usb2_vbus_regulator_register(channel);
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1046 if (ret)
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1047 return ret;
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1048 } else {
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1049 channel->vbus = devm_regulator_get_optional(dev, "vbus");
b6d7dd157763e0 drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1050 }
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1051 if (IS_ERR(channel->vbus)) {
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1052 if (PTR_ERR(channel->vbus) == -EPROBE_DEFER)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1053 return PTR_ERR(channel->vbus);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1054
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1055 channel->vbus = NULL;
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1056 }
6dcfd7c300bf35 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-03-03 1057
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1058 irq = platform_get_irq_optional(pdev, 0);
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1059 if (irq < 0 && irq != -ENXIO) {
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1060 return irq;
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1061 } else if (irq > 0) {
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1062 INIT_WORK(&channel->work, rcar_gen3_phy_usb2_work);
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1063 ret = devm_request_irq(dev, irq, rcar_gen3_phy_usb2_irq,
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1064 IRQF_SHARED, dev_name(dev), channel);
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1065 if (ret < 0)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1066 return dev_err_probe(dev, ret,
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1067 "Failed to request irq (%d)\n",
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1068 irq);
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1069 }
de76809f60cc93 drivers/phy/renesas/phy-rcar-gen3-usb2.c Claudiu Beznea 2025-05-07 1070
549b6b55b00558 drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2019-04-11 1071 provider = devm_of_phy_provider_register(dev, rcar_gen3_phy_usb2_xlate);
9bb86777fb71ee drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-11-09 1072 if (IS_ERR(provider)) {
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1073 return dev_err_probe(dev, PTR_ERR(provider),
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1074 "Failed to register PHY provider\n");
979b519c7a1bff drivers/phy/renesas/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2018-09-21 1075 } else if (channel->is_otg_channel) {
9bb86777fb71ee drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-11-09 1076 ret = device_create_file(dev, &dev_attr_role);
9bb86777fb71ee drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-11-09 1077 if (ret < 0)
230c817a1601af drivers/phy/renesas/phy-rcar-gen3-usb2.c Tommaso Merciai 2025-12-22 1078 return ret;
9bb86777fb71ee drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2016-11-09 1079 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 1080
441a681b884347 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2017-03-14 1081 return 0;
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 1082 }
f3b5a8d9b50d71 drivers/phy/phy-rcar-gen3-usb2.c Yoshihiro Shimoda 2015-11-30 1083
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH 0/3] phy: spacemit: Add USB2 PHY support for K3 SoC
From: Yixun Lan @ 2026-02-12 1:38 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ze Huang
Cc: Junzhong Pan, linux-phy, devicetree, linux-riscv, spacemit,
linux-kernel, Yixun Lan
The series trys to add USB2 PHY support for SpacemiT K3 SoC,
while patch [2/3] implement a disconnect function which is
needed during next connection.
No DTS part has been inclueded in this series, instead I plan
to submit while adding USB host support.
Signed-off-by: Yixun Lan <dlan@kernel.org>
---
Yixun Lan (3):
dt-bindings: phy: spacemit: k3: add USB2 PHY support
phy: k1-usb: add disconnect function support
phy: k1-usb: k3: add USB2 PHY support
.../devicetree/bindings/phy/spacemit,usb2-phy.yaml | 6 ++-
drivers/phy/spacemit/phy-k1-usb2.c | 52 +++++++++++++++++++++-
2 files changed, 55 insertions(+), 3 deletions(-)
---
base-commit: dd39930f3d9c1d74a40b79d368e1f3d1555e919c
change-id: 20260124-11-k3-usb2-phy-c4630b990b1f
Best regards,
--
Yixun Lan <dlan@kernel.org>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH 1/3] dt-bindings: phy: spacemit: k3: add USB2 PHY support
From: Yixun Lan @ 2026-02-12 1:38 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ze Huang
Cc: Junzhong Pan, linux-phy, devicetree, linux-riscv, spacemit,
linux-kernel, Yixun Lan
In-Reply-To: <20260212-11-k3-usb2-phy-v1-0-43578592405d@kernel.org>
Introduce a compatible string for the USB2 PHY in SpacemiT K3 SoC. The IP
of USB2 PHY mostly shares the same functionalities with K1 SoC, while has
some register layout changes.
Signed-off-by: Yixun Lan <dlan@kernel.org>
---
Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml
index 43eaca90d88c..18025e5f60d6 100644
--- a/Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/spacemit,usb2-phy.yaml
@@ -4,14 +4,16 @@
$id: http://devicetree.org/schemas/phy/spacemit,usb2-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: SpacemiT K1 SoC USB 2.0 PHY
+title: SpacemiT K1/K3 SoC USB 2.0 PHY
maintainers:
- Ze Huang <huang.ze@linux.dev>
properties:
compatible:
- const: spacemit,k1-usb2-phy
+ enum:
+ - spacemit,k1-usb2-phy
+ - spacemit,k3-usb2-phy
reg:
maxItems: 1
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
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