[00/12] Rework PHY reset handling

Message ID 20230405-net-next-topic-net-phy-reset-v1-0-7e5329f08002@pengutronix.de
Headers
Series Rework PHY reset handling |

Message

Marco Felsch April 5, 2023, 9:26 a.m. UTC
  The current phy reset handling is broken in a way that it needs
pre-running firmware to setup the phy initially. Since the very first
step is to readout the PHYID1/2 registers before doing anything else.

The whole dection logic will fall apart if the pre-running firmware
don't setup the phy accordingly or the kernel boot resets GPIOs states
or disables clocks. In such cases the PHYID1/2 read access will fail and
so the whole detection will fail.

I fixed this via this series, the fix will include a new kernel API
called phy_device_atomic_register() which will do all necessary things
and return a 'struct phy_device' on success. So setting up a phy and the
phy state machine is more convenient.

I tested the series on a i.MX8MP-EVK and a custom board which have a
TJA1102 dual-port ethernet phy. Other testers are welcome :)

Regards,
  Marco

Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
Marco Felsch (12):
      net: phy: refactor phy_device_create function
      net: phy: refactor get_phy_device function
      net: phy: add phy_device_set_miits helper
      net: phy: unify get_phy_device and phy_device_create parameter list
      net: phy: add phy_id_broken support
      net: phy: add phy_device_atomic_register helper
      net: mdio: make use of phy_device_atomic_register helper
      net: phy: add possibility to specify mdio device parent
      net: phy: nxp-tja11xx: make use of phy_device_atomic_register()
      of: mdio: remove now unused of_mdiobus_phy_device_register()
      net: mdiobus: remove now unused fwnode helpers
      net: phy: add default gpio assert/deassert delay

 Documentation/firmware-guide/acpi/dsd/phy.rst     |   2 +-
 MAINTAINERS                                       |   1 -
 drivers/net/ethernet/adi/adin1110.c               |   6 +-
 drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c       |   8 +-
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c |  11 +-
 drivers/net/ethernet/socionext/netsec.c           |   7 +-
 drivers/net/mdio/Kconfig                          |   7 -
 drivers/net/mdio/Makefile                         |   1 -
 drivers/net/mdio/acpi_mdio.c                      |  20 +-
 drivers/net/mdio/fwnode_mdio.c                    | 183 ------------
 drivers/net/mdio/mdio-xgene.c                     |   6 +-
 drivers/net/mdio/of_mdio.c                        |  23 +-
 drivers/net/phy/bcm-phy-ptp.c                     |   2 +-
 drivers/net/phy/dp83640.c                         |   2 +-
 drivers/net/phy/fixed_phy.c                       |   6 +-
 drivers/net/phy/mdio_bus.c                        |   7 +-
 drivers/net/phy/micrel.c                          |   2 +-
 drivers/net/phy/mscc/mscc_ptp.c                   |   2 +-
 drivers/net/phy/nxp-c45-tja11xx.c                 |   2 +-
 drivers/net/phy/nxp-tja11xx.c                     |  47 ++-
 drivers/net/phy/phy_device.c                      | 348 +++++++++++++++++++---
 drivers/net/phy/sfp.c                             |   7 +-
 include/linux/fwnode_mdio.h                       |  35 ---
 include/linux/of_mdio.h                           |   8 -
 include/linux/phy.h                               |  46 ++-
 25 files changed, 442 insertions(+), 347 deletions(-)
---
base-commit: 054fbf7ff8143d35ca7d3bb5414bb44ee1574194
change-id: 20230405-net-next-topic-net-phy-reset-4f79ff7df4a0

Best regards,
  

Comments

Andrew Lunn April 5, 2023, 12:32 p.m. UTC | #1
On Wed, Apr 05, 2023 at 11:26:51AM +0200, Marco Felsch wrote:
> The current phy reset handling is broken in a way that it needs
> pre-running firmware to setup the phy initially. Since the very first
> step is to readout the PHYID1/2 registers before doing anything else.
> 
> The whole dection logic will fall apart if the pre-running firmware
> don't setup the phy accordingly or the kernel boot resets GPIOs states
> or disables clocks. In such cases the PHYID1/2 read access will fail and
> so the whole detection will fail.
> 
> I fixed this via this series, the fix will include a new kernel API
> called phy_device_atomic_register() which will do all necessary things
> and return a 'struct phy_device' on success. So setting up a phy and the
> phy state machine is more convenient.

Please add a section explaining why the current API is broken beyond
repair.  You need to justify adding a new call, rather than fixing the
existing code to just do what is necessary to allow the PHY to be
found.

	Andrew
  
Florian Fainelli April 5, 2023, 12:42 p.m. UTC | #2
Hi Marco,

On 4/5/2023 2:26 AM, Marco Felsch wrote:
> The current phy reset handling is broken in a way that it needs
> pre-running firmware to setup the phy initially. Since the very first
> step is to readout the PHYID1/2 registers before doing anything else.
> 
> The whole dection logic will fall apart if the pre-running firmware
> don't setup the phy accordingly or the kernel boot resets GPIOs states
> or disables clocks. In such cases the PHYID1/2 read access will fail and
> so the whole detection will fail.

PHY reset is a bit too broad and should need some clarifications between:

- external reset to the PHY whereby a hardware pin on the PHY IC may be used

- internal reset to the PHY whereby we call into the PHY driver 
soft_reset function to have the PHY software reset itself

You are changing the way the former happens, not the latter, at least 
not changing the latter intentionally if at all.

This is important because your cover letter will be in the merge commit 
in the networking tree.

Will do a more thorough review on a patch by patch basis. Thanks.

> 
> I fixed this via this series, the fix will include a new kernel API
> called phy_device_atomic_register() which will do all necessary things
> and return a 'struct phy_device' on success. So setting up a phy and the
> phy state machine is more convenient.
> 
> I tested the series on a i.MX8MP-EVK and a custom board which have a
> TJA1102 dual-port ethernet phy. Other testers are welcome :)
> 
> Regards,
>    Marco
> 
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> ---
> Marco Felsch (12):
>        net: phy: refactor phy_device_create function
>        net: phy: refactor get_phy_device function
>        net: phy: add phy_device_set_miits helper
>        net: phy: unify get_phy_device and phy_device_create parameter list
>        net: phy: add phy_id_broken support
>        net: phy: add phy_device_atomic_register helper
>        net: mdio: make use of phy_device_atomic_register helper
>        net: phy: add possibility to specify mdio device parent
>        net: phy: nxp-tja11xx: make use of phy_device_atomic_register()
>        of: mdio: remove now unused of_mdiobus_phy_device_register()
>        net: mdiobus: remove now unused fwnode helpers
>        net: phy: add default gpio assert/deassert delay
> 
>   Documentation/firmware-guide/acpi/dsd/phy.rst     |   2 +-
>   MAINTAINERS                                       |   1 -
>   drivers/net/ethernet/adi/adin1110.c               |   6 +-
>   drivers/net/ethernet/amd/xgbe/xgbe-phy-v2.c       |   8 +-
>   drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c |  11 +-
>   drivers/net/ethernet/socionext/netsec.c           |   7 +-
>   drivers/net/mdio/Kconfig                          |   7 -
>   drivers/net/mdio/Makefile                         |   1 -
>   drivers/net/mdio/acpi_mdio.c                      |  20 +-
>   drivers/net/mdio/fwnode_mdio.c                    | 183 ------------
>   drivers/net/mdio/mdio-xgene.c                     |   6 +-
>   drivers/net/mdio/of_mdio.c                        |  23 +-
>   drivers/net/phy/bcm-phy-ptp.c                     |   2 +-
>   drivers/net/phy/dp83640.c                         |   2 +-
>   drivers/net/phy/fixed_phy.c                       |   6 +-
>   drivers/net/phy/mdio_bus.c                        |   7 +-
>   drivers/net/phy/micrel.c                          |   2 +-
>   drivers/net/phy/mscc/mscc_ptp.c                   |   2 +-
>   drivers/net/phy/nxp-c45-tja11xx.c                 |   2 +-
>   drivers/net/phy/nxp-tja11xx.c                     |  47 ++-
>   drivers/net/phy/phy_device.c                      | 348 +++++++++++++++++++---
>   drivers/net/phy/sfp.c                             |   7 +-
>   include/linux/fwnode_mdio.h                       |  35 ---
>   include/linux/of_mdio.h                           |   8 -
>   include/linux/phy.h                               |  46 ++-
>   25 files changed, 442 insertions(+), 347 deletions(-)
> ---
> base-commit: 054fbf7ff8143d35ca7d3bb5414bb44ee1574194
> change-id: 20230405-net-next-topic-net-phy-reset-4f79ff7df4a0
> 
> Best regards,
  
Marco Felsch April 5, 2023, 2:42 p.m. UTC | #3
Hi Florian,

On 23-04-05, Florian Fainelli wrote:
> Hi Marco,
> 
> On 4/5/2023 2:26 AM, Marco Felsch wrote:
> > The current phy reset handling is broken in a way that it needs
> > pre-running firmware to setup the phy initially. Since the very first
> > step is to readout the PHYID1/2 registers before doing anything else.
> > 
> > The whole dection logic will fall apart if the pre-running firmware
> > don't setup the phy accordingly or the kernel boot resets GPIOs states
> > or disables clocks. In such cases the PHYID1/2 read access will fail and
> > so the whole detection will fail.
> 
> PHY reset is a bit too broad and should need some clarifications between:
> 
> - external reset to the PHY whereby a hardware pin on the PHY IC may be used
> 
> - internal reset to the PHY whereby we call into the PHY driver soft_reset
> function to have the PHY software reset itself
> 
> You are changing the way the former happens, not the latter, at least not
> changing the latter intentionally if at all.

Yes.

> This is important because your cover letter will be in the merge commit in
> the networking tree.

Ah okay, I didn't know that. I will adapt the cover letter accordingly.

> Will do a more thorough review on a patch by patch basis. Thanks.

Thanks a lot, looking forward to it.

Regards,
  Marco
  
Marco Felsch April 5, 2023, 3:31 p.m. UTC | #4
Hi Andrew,

On 23-04-05, Andrew Lunn wrote:
> On Wed, Apr 05, 2023 at 11:26:51AM +0200, Marco Felsch wrote:
> > The current phy reset handling is broken in a way that it needs
> > pre-running firmware to setup the phy initially. Since the very first
> > step is to readout the PHYID1/2 registers before doing anything else.
> > 
> > The whole dection logic will fall apart if the pre-running firmware
> > don't setup the phy accordingly or the kernel boot resets GPIOs states
> > or disables clocks. In such cases the PHYID1/2 read access will fail and
> > so the whole detection will fail.
> > 
> > I fixed this via this series, the fix will include a new kernel API
> > called phy_device_atomic_register() which will do all necessary things
> > and return a 'struct phy_device' on success. So setting up a phy and the
> > phy state machine is more convenient.
> 
> Please add a section explaining why the current API is broken beyond
> repair.  You need to justify adding a new call, rather than fixing the
> existing code to just do what is necessary to allow the PHY to be
> found.

TIL from Florian that you use the cover-letter information in your merge
commits. I will adapt the cover-letter accordingly and mention why this
PR introduces a new API.

Regards,
  Marco


> 
> 	Andrew
>