mbox series

[v2,00/12] Series to deliver Ethernets for STM32MP13

Message ID 20230928122427.313271-1-christophe.roullier@foss.st.com
Headers show
Series Series to deliver Ethernets for STM32MP13 | expand

Message

Christophe ROULLIER Sept. 28, 2023, 12:24 p.m. UTC
STM32MP13 is STM32 SOC with 2 GMACs instances
This board have 2 RMII phy:
  -Ethernet1: RMII with crystal
  -Ethernet2: RMII without crystal
Rework dwmac glue to simplify management for next stm32

-V2: Update from remark of Andrew Lunn (split commit into a number of smaller patches)
     Update from Conor Dooley (yaml documentation)

Christophe Roullier (12):
  dt-bindings: net: add STM32MP13 compatible in documentation for stm32
  dt-bindings: net: add new property st,ext-phyclk in documentation for
    stm32
  dt-bindings: net: add phy-supply property for stm32
  net: ethernet: stmmac: rework glue to simplify management for next
    stm32
  net: ethernet: stmmac: add management of stm32mp13 for stm32
  net: ethernet: stmmac: stm32: update config management for phy wo
    cristal
  net: ethernet: stm32: clean the way to manage wol irqwake
  net: ethernet: stmmac: stm32: support the phy-supply regulator binding
  ARM: dts: stm32: add ethernet1 and ethernet2 support on stm32mp13
  ARM: dts: stm32: add ethernet1/2 RMII pins for STM32MP13F-DK board
  ARM: dts: stm32: add ethernet1 and ethernet2 for STM32MP135F-DK board
  ARM: multi_v7_defconfig: Add MCP23S08 pinctrl support

 .../devicetree/bindings/net/stm32-dwmac.yaml  |  90 ++++++-
 arch/arm/boot/dts/st/stm32mp13-pinctrl.dtsi   |  71 ++++++
 arch/arm/boot/dts/st/stm32mp131.dtsi          |  31 +++
 arch/arm/boot/dts/st/stm32mp133.dtsi          |  30 +++
 arch/arm/boot/dts/st/stm32mp135f-dk.dts       |  48 ++++
 arch/arm/configs/multi_v7_defconfig           |   1 +
 .../net/ethernet/stmicro/stmmac/dwmac-stm32.c | 229 +++++++++++++-----
 7 files changed, 425 insertions(+), 75 deletions(-)

Comments

Andrew Lunn Sept. 28, 2023, 5:53 p.m. UTC | #1
> +static int phy_power_on(struct stm32_dwmac *bsp_priv, bool enable)

I find this function name confusing, since 50% of the time it does not
actually power the PHY on. You never call it with anything other than
a static true/false value. So it might was well be two functions,
phy_power_on() and phy_power_off().

> +{
> +	int ret;
> +	struct device *dev = bsp_priv->dev;
> +
> +	if (!bsp_priv->regulator)
> +		return 0;
> +
> +	if (enable) {
> +		ret = regulator_enable(bsp_priv->regulator);
> +		if (ret)
> +			dev_err(dev, "fail to enable phy-supply\n");

Not all PHYs are usable in 0 picoseconds. You probably want a delay
here. Otherwise the first few accesses to it might not work.

      Andrew
Christophe ROULLIER Oct. 5, 2023, 11:21 a.m. UTC | #2
On 9/28/23 19:53, Andrew Lunn wrote:
>> +static int phy_power_on(struct stm32_dwmac *bsp_priv, bool enable)
> I find this function name confusing, since 50% of the time it does not
> actually power the PHY on. You never call it with anything other than
> a static true/false value. So it might was well be two functions,
> phy_power_on() and phy_power_off().

Hi,

I wanted to keep same implementation of all others Ethernet glues 
(dwmac-rk.c ...) to be consistent.

>> +{
>> +	int ret;
>> +	struct device *dev = bsp_priv->dev;
>> +
>> +	if (!bsp_priv->regulator)
>> +		return 0;
>> +
>> +	if (enable) {
>> +		ret = regulator_enable(bsp_priv->regulator);
>> +		if (ret)
>> +			dev_err(dev, "fail to enable phy-supply\n");
> Not all PHYs are usable in 0 picoseconds. You probably want a delay
> here. Otherwise the first few accesses to it might not work.
>
>        Andrew

You're right I will add a delay.

Thanks

Christophe