[PATCH v2 1/4] net: phy: Port set/clear bits from Linux
To simply porting phy drivers from Linux to U-Boot, define phy_set_bits() and phy_clear_bits() functions with a similar API to those used in Linux.
The U-Boot versions of these functions include the `devad` argument which is not present in the Linux versions, to keep them aligned with the other phy functions in U-Boot.
Signed-off-by: Paul Barker paul.barker.ct@bp.renesas.com Reviewed-by: Marek Vasut marek.vasut+renesas@mailbox.org --- Changes v1->v2: - Split out of series adding RZ/G2L Ethernet support [1] - Added Marek's Reviewed-by tag
[1]: https://lore.kernel.org/all/20241024152448.102-1-paul.barker.ct@bp.renesas.c...
include/phy.h | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
diff --git a/include/phy.h b/include/phy.h index 36785031eeb0..510b0a21831b 100644 --- a/include/phy.h +++ b/include/phy.h @@ -333,6 +333,28 @@ int gen10g_startup(struct phy_device *phydev); int gen10g_shutdown(struct phy_device *phydev); int gen10g_discover_mmds(struct phy_device *phydev);
+/** + * phy_set_bits - Convenience function for setting bits in a PHY register + * @phydev: the phy_device struct + * @regnum: register number to write + * @val: bits to set + */ +static inline int phy_set_bits(struct phy_device *phydev, int devad, u32 regnum, u16 val) +{ + return phy_modify(phydev, devad, regnum, 0, val); +} + +/** + * phy_clear_bits - Convenience function for clearing bits in a PHY register + * @phydev: the phy_device struct + * @regnum: register number to write + * @val: bits to clear + */ +static inline int phy_clear_bits(struct phy_device *phydev, int devad, u32 regnum, u16 val) +{ + return phy_modify(phydev, devad, regnum, val, 0); +} + /** * U_BOOT_PHY_DRIVER() - Declare a new U-Boot driver * @__name: name of the driver
Micrel KSZ9131 PHY LED behavior is not correct when configured in Individual Mode, LED1 (Activity LED) is in the ON state when there is no-link.
Workaround this by setting bit 9 of register 0x1e after verifying that the LED configuration is Individual Mode.
This issue is described in KSZ9131RNX Silicon Errata DS80000693B [*] and according to that it will not be corrected in a future silicon revision.
[*] https://ww1.microchip.com/downloads/en/DeviceDoc/KSZ9131RNX-Silicon-Errata-a...
Based on commit 0316c7e66bbd in the Linux kernel.
Signed-off-by: Paul Barker paul.barker.ct@bp.renesas.com --- Changes v1->v2: - Split out of series adding RZ/G2L Ethernet support [1] - Add symbols KSZ9131RN_COMMON_CTRL, KSZ9131RN_COMMON_CTRL_LED_MODE, KSZ9131RN_LED_ERRATA_REG, KSZ9131RN_LED_ERRATA_BITS
[1]: https://lore.kernel.org/all/20241024152448.102-1-paul.barker.ct@bp.renesas.c...
drivers/net/phy/micrel_ksz90x1.c | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+)
diff --git a/drivers/net/phy/micrel_ksz90x1.c b/drivers/net/phy/micrel_ksz90x1.c index c48ae6e88f30..b33457910795 100644 --- a/drivers/net/phy/micrel_ksz90x1.c +++ b/drivers/net/phy/micrel_ksz90x1.c @@ -389,6 +389,12 @@ U_BOOT_PHY_DRIVER(ksz9031) = { #define KSZ9131RN_DLL_ENABLE_DELAY 0 #define KSZ9131RN_DLL_DISABLE_DELAY BIT(12)
+#define KSZ9131RN_COMMON_CTRL 0 +#define KSZ9131RN_COMMON_CTRL_LED_MODE BIT(4) + +#define KSZ9131RN_LED_ERRATA_REG 0x1e +#define KSZ9131RN_LED_ERRATA_BITS BIT(9) + static int ksz9131_config_rgmii_delay(struct phy_device *phydev) { struct phy_driver *drv = phydev->drv; @@ -436,6 +442,28 @@ static int ksz9131_config_rgmii_delay(struct phy_device *phydev) return ret; }
+/* Silicon Errata DS80000693B + * + * When LEDs are configured in Individual Mode, LED1 is ON in a no-link + * condition. Workaround is to set register 0x1e, bit 9, this way LED1 behaves + * according to the datasheet (off if there is no link). + */ +static int ksz9131_led_errata(struct phy_device *phydev) +{ + int reg; + + reg = phy_read_mmd(phydev, KSZ9131RN_MMD_COMMON_CTRL_REG, + KSZ9131RN_COMMON_CTRL); + if (reg < 0) + return reg; + + if (!(reg & KSZ9131RN_COMMON_CTRL_LED_MODE)) + return 0; + + return phy_set_bits(phydev, MDIO_DEVAD_NONE, KSZ9131RN_LED_ERRATA_REG, + KSZ9131RN_LED_ERRATA_BITS); +} + static int ksz9131_config(struct phy_device *phydev) { int ret; @@ -446,6 +474,10 @@ static int ksz9131_config(struct phy_device *phydev) return ret; }
+ ret = ksz9131_led_errata(phydev); + if (ret < 0) + return ret; + /* add an option to disable the gigabit feature of this PHY */ if (env_get("disable_giga")) { unsigned features;
Hi Paul,
On 11/20/24 10:49 AM, Paul Barker wrote:
Micrel KSZ9131 PHY LED behavior is not correct when configured in Individual Mode, LED1 (Activity LED) is in the ON state when there is no-link.
Workaround this by setting bit 9 of register 0x1e after verifying that the LED configuration is Individual Mode.
This issue is described in KSZ9131RNX Silicon Errata DS80000693B [*] and according to that it will not be corrected in a future silicon revision.
[*] https://ww1.microchip.com/downloads/en/DeviceDoc/KSZ9131RNX-Silicon-Errata-a...
Based on commit 0316c7e66bbd in the Linux kernel.
Signed-off-by: Paul Barker paul.barker.ct@bp.renesas.com
Changes v1->v2:
- Split out of series adding RZ/G2L Ethernet support [1]
- Add symbols KSZ9131RN_COMMON_CTRL, KSZ9131RN_COMMON_CTRL_LED_MODE, KSZ9131RN_LED_ERRATA_REG, KSZ9131RN_LED_ERRATA_BITS
drivers/net/phy/micrel_ksz90x1.c | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+)
diff --git a/drivers/net/phy/micrel_ksz90x1.c b/drivers/net/phy/micrel_ksz90x1.c index c48ae6e88f30..b33457910795 100644 --- a/drivers/net/phy/micrel_ksz90x1.c +++ b/drivers/net/phy/micrel_ksz90x1.c @@ -389,6 +389,12 @@ U_BOOT_PHY_DRIVER(ksz9031) = { #define KSZ9131RN_DLL_ENABLE_DELAY 0 #define KSZ9131RN_DLL_DISABLE_DELAY BIT(12)
+#define KSZ9131RN_COMMON_CTRL 0 +#define KSZ9131RN_COMMON_CTRL_LED_MODE BIT(4)
Can you rename or add a new symbol to explain what is what? This implies a mask basically but not what the mask being set means.
Can suggest something like:
KSZ9131RN_COMMON_CTRL_INDIVIDUAL_LED_MODE ....
+#define KSZ9131RN_LED_ERRATA_REG 0x1e +#define KSZ9131RN_LED_ERRATA_BITS BIT(9)
Yet we only set one bit, remove BITS or rename to BIT?
- static int ksz9131_config_rgmii_delay(struct phy_device *phydev) { struct phy_driver *drv = phydev->drv;
@@ -436,6 +442,28 @@ static int ksz9131_config_rgmii_delay(struct phy_device *phydev) return ret; }
+/* Silicon Errata DS80000693B
- When LEDs are configured in Individual Mode, LED1 is ON in a no-link
- condition. Workaround is to set register 0x1e, bit 9, this way LED1 behaves
- according to the datasheet (off if there is no link).
- */
+static int ksz9131_led_errata(struct phy_device *phydev) +{
- int reg;
- reg = phy_read_mmd(phydev, KSZ9131RN_MMD_COMMON_CTRL_REG,
KSZ9131RN_COMMON_CTRL);- if (reg < 0)
return reg;- if (!(reg & KSZ9131RN_COMMON_CTRL_LED_MODE))
.... or at the very least add a clear comment here what we're after :) (yes it's commented at the top of the function but right before the check is nice too I believe).
return 0;- return phy_set_bits(phydev, MDIO_DEVAD_NONE, KSZ9131RN_LED_ERRATA_REG,
KSZ9131RN_LED_ERRATA_BITS);+}
- static int ksz9131_config(struct phy_device *phydev) { int ret;
@@ -446,6 +474,10 @@ static int ksz9131_config(struct phy_device *phydev) return ret; }
- ret = ksz9131_led_errata(phydev);
- if (ret < 0)
return ret;
This seems to work but is happening a bit late.
Indeed, I need something to call the network stack for this to be happening. Meaning until I e.g. run `dhcp` in the CLI, the LED is still following the bad behavior.
I assume we cannot use the probe() callback for writing to registers?
Tested-by: Quentin Schulz quentin.schulz@cherry.de # RK3588 Tiger
Thanks! Quentin
On 11/25/24 6:23 PM, Quentin Schulz wrote:
[...]
@@ -446,6 +474,10 @@ static int ksz9131_config(struct phy_device *phydev) return ret; } + ret = ksz9131_led_errata(phydev); + if (ret < 0) + return ret;
This seems to work but is happening a bit late.
Indeed, I need something to call the network stack for this to be happening. Meaning until I e.g. run `dhcp` in the CLI, the LED is still following the bad behavior.
I assume we cannot use the probe() callback for writing to registers?
I'm afraid there is an inconsistency between U-Boot MAC drivers and when they configure the PHY. This is well visible on MX8MP, which has both FEC and EQoS/DWMAC MACs and they behave differently in this aspect. The question is, whether it makes sense to initialize the PHY before the MAC has been used, probably no, because that brings up hardware and adds to boot time. But at least aligning the behavior of the various MAC drivers would be nice.
Hi Marek, Quentin,
On 01/12/2024 18:57, Marek Vasut wrote:
On 11/25/24 6:23 PM, Quentin Schulz wrote:
[...]
@@ -446,6 +474,10 @@ static int ksz9131_config(struct phy_device *phydev) return ret; } + ret = ksz9131_led_errata(phydev); + if (ret < 0) + return ret;
This seems to work but is happening a bit late.
Indeed, I need something to call the network stack for this to be happening. Meaning until I e.g. run `dhcp` in the CLI, the LED is still following the bad behavior.
I assume we cannot use the probe() callback for writing to registers?
I'm afraid there is an inconsistency between U-Boot MAC drivers and when they configure the PHY. This is well visible on MX8MP, which has both FEC and EQoS/DWMAC MACs and they behave differently in this aspect. The question is, whether it makes sense to initialize the PHY before the MAC has been used, probably no, because that brings up hardware and adds to boot time. But at least aligning the behavior of the various MAC drivers would be nice.
Is there anything we can do in this driver to fix this?
Or should we merge this as-is and improve the MAC drivers later?
Thanks,
Hi Paul,
On 12/5/24 7:58 PM, Paul Barker wrote:
Hi Marek, Quentin,
On 01/12/2024 18:57, Marek Vasut wrote:
On 11/25/24 6:23 PM, Quentin Schulz wrote:
[...]
@@ -446,6 +474,10 @@ static int ksz9131_config(struct phy_device *phydev) return ret; } + ret = ksz9131_led_errata(phydev); + if (ret < 0) + return ret;
This seems to work but is happening a bit late.
Indeed, I need something to call the network stack for this to be happening. Meaning until I e.g. run `dhcp` in the CLI, the LED is still following the bad behavior.
I assume we cannot use the probe() callback for writing to registers?
I'm afraid there is an inconsistency between U-Boot MAC drivers and when they configure the PHY. This is well visible on MX8MP, which has both FEC and EQoS/DWMAC MACs and they behave differently in this aspect. The question is, whether it makes sense to initialize the PHY before the MAC has been used, probably no, because that brings up hardware and adds to boot time. But at least aligning the behavior of the various MAC drivers would be nice.
Is there anything we can do in this driver to fix this?
Or should we merge this as-is and improve the MAC drivers later?
This patch doesn't change anything or rely on some specific behavior so I'm of the opinion to merge it. Making the behavior of all MAC drivers consistent would be nice but has nothing to do with the PHY driver here I believe.
Cheers, Quentin
On 12/5/24 7:58 PM, Paul Barker wrote:
Hi Marek, Quentin,
On 01/12/2024 18:57, Marek Vasut wrote:
On 11/25/24 6:23 PM, Quentin Schulz wrote:
[...]
@@ -446,6 +474,10 @@ static int ksz9131_config(struct phy_device *phydev) return ret; } + ret = ksz9131_led_errata(phydev); + if (ret < 0) + return ret;
This seems to work but is happening a bit late.
Indeed, I need something to call the network stack for this to be happening. Meaning until I e.g. run `dhcp` in the CLI, the LED is still following the bad behavior.
I assume we cannot use the probe() callback for writing to registers?
I'm afraid there is an inconsistency between U-Boot MAC drivers and when they configure the PHY. This is well visible on MX8MP, which has both FEC and EQoS/DWMAC MACs and they behave differently in this aspect. The question is, whether it makes sense to initialize the PHY before the MAC has been used, probably no, because that brings up hardware and adds to boot time. But at least aligning the behavior of the various MAC drivers would be nice.
Is there anything we can do in this driver to fix this?
Or should we merge this as-is and improve the MAC drivers later?
I'd say merge it for 2025.04 , since this is an errata fix, but it would also be able to clean up the MAC driver mess eventually.
Various signal skew values may be set in the device tree for the ksz9131 Ethernet PHY. For example, the RZ/G2L board requires non-default values for rxc-skew-psec & txc-skew-psec.
This is based on the ksz9131 phy driver in Linux v6.11.
Signed-off-by: Paul Barker paul.barker.ct@bp.renesas.com Reviewed-by: Marek Vasut marek.vasut+renesas@mailbox.org --- Changes v1->v2: - Split out of series adding RZ/G2L Ethernet support [1] - Added Marek's Reviewed-by tag
[1]: https://lore.kernel.org/all/20241024152448.102-1-paul.barker.ct@bp.renesas.c...
drivers/net/phy/micrel_ksz90x1.c | 115 +++++++++++++++++++++++++++++++ 1 file changed, 115 insertions(+)
diff --git a/drivers/net/phy/micrel_ksz90x1.c b/drivers/net/phy/micrel_ksz90x1.c index b33457910795..e0b36f3fcdf9 100644 --- a/drivers/net/phy/micrel_ksz90x1.c +++ b/drivers/net/phy/micrel_ksz90x1.c @@ -395,6 +395,117 @@ U_BOOT_PHY_DRIVER(ksz9031) = { #define KSZ9131RN_LED_ERRATA_REG 0x1e #define KSZ9131RN_LED_ERRATA_BITS BIT(9)
+#define KSZ9131RN_CONTROL_PAD_SKEW 4 +#define KSZ9131RN_RX_DATA_PAD_SKEW 5 +#define KSZ9131RN_TX_DATA_PAD_SKEW 6 +#define KSZ9131RN_CLK_PAD_SKEW 8 + +#define KSZ9131RN_SKEW_5BIT_MAX 2400 +#define KSZ9131RN_SKEW_4BIT_MAX 800 +#define KSZ9131RN_OFFSET 700 +#define KSZ9131RN_STEP 100 + +static int ksz9131_of_load_skew_values(struct phy_device *phydev, + ofnode of_node, + u16 reg, size_t field_sz, + const char *field[], u8 numfields) +{ + int val[4] = {-(1 + KSZ9131RN_OFFSET), -(2 + KSZ9131RN_OFFSET), + -(3 + KSZ9131RN_OFFSET), -(4 + KSZ9131RN_OFFSET)}; + int skewval, skewmax = 0; + int matches = 0; + u16 maxval; + u16 newval; + u16 mask; + int i; + + /* psec properties in dts should mean x pico seconds */ + if (field_sz == 5) + skewmax = KSZ9131RN_SKEW_5BIT_MAX; + else + skewmax = KSZ9131RN_SKEW_4BIT_MAX; + + for (i = 0; i < numfields; i++) + if (!ofnode_read_s32(of_node, field[i], &skewval)) { + if (skewval < -KSZ9131RN_OFFSET) + skewval = -KSZ9131RN_OFFSET; + else if (skewval > skewmax) + skewval = skewmax; + + val[i] = skewval + KSZ9131RN_OFFSET; + matches++; + } + + if (!matches) + return 0; + + if (matches < numfields) + newval = phy_read_mmd(phydev, KSZ9131RN_MMD_COMMON_CTRL_REG, reg); + else + newval = 0; + + maxval = (field_sz == 4) ? 0xf : 0x1f; + for (i = 0; i < numfields; i++) + if (val[i] != -(i + 1 + KSZ9131RN_OFFSET)) { + mask = 0xffff; + mask ^= maxval << (field_sz * i); + newval = (newval & mask) | + (((val[i] / KSZ9131RN_STEP) & maxval) + << (field_sz * i)); + } + + return phy_write_mmd(phydev, KSZ9131RN_MMD_COMMON_CTRL_REG, reg, newval); +} + +static int ksz9131_of_load_all_skew_values(struct phy_device *phydev) +{ + const char *control_skews[2] = { "txen-skew-psec", "rxdv-skew-psec" }; + const char *clk_skews[2] = { "rxc-skew-psec", "txc-skew-psec" }; + const char *rx_data_skews[4] = { + "rxd0-skew-psec", "rxd1-skew-psec", + "rxd2-skew-psec", "rxd3-skew-psec" + }; + const char *tx_data_skews[4] = { + "txd0-skew-psec", "txd1-skew-psec", + "txd2-skew-psec", "txd3-skew-psec" + }; + struct ofnode_phandle_args phandle_args; + int ret; + + /* + * Silently ignore failure here as the device tree is not required to + * contain a phy node. + */ + if (dev_read_phandle_with_args(phydev->dev, "phy-handle", NULL, 0, 0, + &phandle_args)) + return 0; + + if (!ofnode_valid(phandle_args.node)) + return 0; + + ret = ksz9131_of_load_skew_values(phydev, phandle_args.node, + KSZ9131RN_CLK_PAD_SKEW, 5, + clk_skews, 2); + if (ret < 0) + return ret; + + ret = ksz9131_of_load_skew_values(phydev, phandle_args.node, + KSZ9131RN_CONTROL_PAD_SKEW, 4, + control_skews, 2); + if (ret < 0) + return ret; + + ret = ksz9131_of_load_skew_values(phydev, phandle_args.node, + KSZ9131RN_RX_DATA_PAD_SKEW, 4, + rx_data_skews, 4); + if (ret < 0) + return ret; + + return ksz9131_of_load_skew_values(phydev, phandle_args.node, + KSZ9131RN_TX_DATA_PAD_SKEW, 4, + tx_data_skews, 4); +} + static int ksz9131_config_rgmii_delay(struct phy_device *phydev) { struct phy_driver *drv = phydev->drv; @@ -474,6 +585,10 @@ static int ksz9131_config(struct phy_device *phydev) return ret; }
+ ret = ksz9131_of_load_all_skew_values(phydev); + if (ret < 0) + return ret; + ret = ksz9131_led_errata(phydev); if (ret < 0) return ret;
We can call phy_modify_mmd() instead of manually calling drv->readext() and drv->writeext().
Signed-off-by: Paul Barker paul.barker.ct@bp.renesas.com --- Changes v1->v2: - Split out of series adding RZ/G2L Ethernet support [1]
[1]: https://lore.kernel.org/all/20241024152448.102-1-paul.barker.ct@bp.renesas.c...
drivers/net/phy/micrel_ksz90x1.c | 26 ++++++++------------------ 1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/net/phy/micrel_ksz90x1.c b/drivers/net/phy/micrel_ksz90x1.c index e0b36f3fcdf9..2871d486c80d 100644 --- a/drivers/net/phy/micrel_ksz90x1.c +++ b/drivers/net/phy/micrel_ksz90x1.c @@ -508,8 +508,7 @@ static int ksz9131_of_load_all_skew_values(struct phy_device *phydev)
static int ksz9131_config_rgmii_delay(struct phy_device *phydev) { - struct phy_driver *drv = phydev->drv; - u16 rxcdll_val, txcdll_val, val; + u16 rxcdll_val, txcdll_val; int ret;
switch (phydev->interface) { @@ -533,24 +532,15 @@ static int ksz9131_config_rgmii_delay(struct phy_device *phydev) return 0; }
- val = drv->readext(phydev, 0, KSZ9131RN_MMD_COMMON_CTRL_REG, - KSZ9131RN_RXC_DLL_CTRL); - val &= ~KSZ9131RN_DLL_CTRL_BYPASS; - val |= rxcdll_val; - ret = drv->writeext(phydev, 0, KSZ9131RN_MMD_COMMON_CTRL_REG, - KSZ9131RN_RXC_DLL_CTRL, val); - if (ret) + ret = phy_modify_mmd(phydev, KSZ9131RN_MMD_COMMON_CTRL_REG, + KSZ9131RN_RXC_DLL_CTRL, KSZ9131RN_DLL_CTRL_BYPASS, + rxcdll_val); + if (ret < 0) return ret;
- val = drv->readext(phydev, 0, KSZ9131RN_MMD_COMMON_CTRL_REG, - KSZ9131RN_TXC_DLL_CTRL); - - val &= ~KSZ9131RN_DLL_CTRL_BYPASS; - val |= txcdll_val; - ret = drv->writeext(phydev, 0, KSZ9131RN_MMD_COMMON_CTRL_REG, - KSZ9131RN_TXC_DLL_CTRL, val); - - return ret; + return phy_modify_mmd(phydev, KSZ9131RN_MMD_COMMON_CTRL_REG, + KSZ9131RN_TXC_DLL_CTRL, KSZ9131RN_DLL_CTRL_BYPASS, + txcdll_val); }
/* Silicon Errata DS80000693B
On 11/20/24 10:49 AM, Paul Barker wrote:
We can call phy_modify_mmd() instead of manually calling drv->readext() and drv->writeext().
Signed-off-by: Paul Barker paul.barker.ct@bp.renesas.com
Reviewed-by: Marek Vasut marek.vasut+renesas@mailbox.org
Thanks !
Hi Paul,
On 11/20/24 10:49 AM, Paul Barker wrote:
To simply porting phy drivers from Linux to U-Boot, define phy_set_bits() and phy_clear_bits() functions with a similar API to those used in Linux.
The U-Boot versions of these functions include the `devad` argument which is not present in the Linux versions, to keep them aligned with the other phy functions in U-Boot.
Signed-off-by: Paul Barker paul.barker.ct@bp.renesas.com Reviewed-by: Marek Vasut marek.vasut+renesas@mailbox.org
Changes v1->v2:
- Split out of series adding RZ/G2L Ethernet support [1]
- Added Marek's Reviewed-by tag
include/phy.h | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
diff --git a/include/phy.h b/include/phy.h index 36785031eeb0..510b0a21831b 100644 --- a/include/phy.h +++ b/include/phy.h @@ -333,6 +333,28 @@ int gen10g_startup(struct phy_device *phydev); int gen10g_shutdown(struct phy_device *phydev); int gen10g_discover_mmds(struct phy_device *phydev);
+/**
- phy_set_bits - Convenience function for setting bits in a PHY register
- @phydev: the phy_device struct
Please document devad parameter here as well?
- @regnum: register number to write
- @val: bits to set
- */
+static inline int phy_set_bits(struct phy_device *phydev, int devad, u32 regnum, u16 val) +{
- return phy_modify(phydev, devad, regnum, 0, val);
+}
+/**
- phy_clear_bits - Convenience function for clearing bits in a PHY register
- @phydev: the phy_device struct
Please document devad parameter here as well?
- @regnum: register number to write
- @val: bits to clear
- */
+static inline int phy_clear_bits(struct phy_device *phydev, int devad, u32 regnum, u16 val) +{
Looking good to me otherwise.
Cheers, Quentin
On 25/11/2024 16:42, Quentin Schulz wrote:
Hi Paul,
On 11/20/24 10:49 AM, Paul Barker wrote:
To simply porting phy drivers from Linux to U-Boot, define phy_set_bits() and phy_clear_bits() functions with a similar API to those used in Linux.
The U-Boot versions of these functions include the `devad` argument which is not present in the Linux versions, to keep them aligned with the other phy functions in U-Boot.
Signed-off-by: Paul Barker paul.barker.ct@bp.renesas.com Reviewed-by: Marek Vasut marek.vasut+renesas@mailbox.org
Changes v1->v2:
- Split out of series adding RZ/G2L Ethernet support [1]
- Added Marek's Reviewed-by tag
include/phy.h | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
diff --git a/include/phy.h b/include/phy.h index 36785031eeb0..510b0a21831b 100644 --- a/include/phy.h +++ b/include/phy.h @@ -333,6 +333,28 @@ int gen10g_startup(struct phy_device *phydev); int gen10g_shutdown(struct phy_device *phydev); int gen10g_discover_mmds(struct phy_device *phydev);
+/**
- phy_set_bits - Convenience function for setting bits in a PHY register
- @phydev: the phy_device struct
Please document devad parameter here as well?
Ah, I forgot to add devad to the documentation comment when I added it to the function signature. I'll do that for v3.
- @regnum: register number to write
- @val: bits to set
- */
+static inline int phy_set_bits(struct phy_device *phydev, int devad, u32 regnum, u16 val) +{
- return phy_modify(phydev, devad, regnum, 0, val);
+}
+/**
- phy_clear_bits - Convenience function for clearing bits in a PHY register
- @phydev: the phy_device struct
Please document devad parameter here as well?
As above.
Thanks for the review!
participants (3)
-
Marek Vasut -
Paul Barker -
Quentin Schulz