| Message ID | 20230405-net-next-topic-net-phy-reset-v1-0-7e5329f08002@pengutronix.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | Rework PHY reset handling | expand |
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
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,
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
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 >
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,