Message ID | 20230405-net-next-topic-net-phy-reset-v1-0-7e5329f08002@pengutronix.de |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp172456vqo; Wed, 5 Apr 2023 02:38:38 -0700 (PDT) X-Google-Smtp-Source: AKy350aNvtQZYFuBLRDBF7OQsuO6rsMWaIkf2/Q/u/CTJCEKe0AWZUiAYADqbetJL9GEHtfyWTbU X-Received: by 2002:aa7:d7d9:0:b0:502:4ba4:76 with SMTP id e25-20020aa7d7d9000000b005024ba40076mr1047655eds.7.1680687518114; Wed, 05 Apr 2023 02:38:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680687518; cv=none; d=google.com; s=arc-20160816; b=mBUkQh0JpmqQJlDdCAD9SifLe5YQj7sC4entgbvCz3lOC02cvqwmCSl6xQGJwqBMVL 8VOW2BbeZP0yTCD4C6yMKvX22tKnFPVMKTozyalcwkMHPoKQ+hwmxCKwb1iLt/ymuw0G QCXUswMG0AcGSCo+M6zvBu3VXz2A16Nwm3elZr1Gvj3QZC11EhOv3P/mV8ZjTp0BK/ve Osl3ZlIekoZzl8t3RhkJFIduoqB+HX4zQVJYKYAJslrNuw8I/IZf0SGmHDQHUUE+1x0T /jsit67jsr7Ji0r8iaglQbYF9LnQxsFFEy3qF0TcaKyNBh17Lbp9hA/LE+Z4PiKAvgUx 9z+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:content-transfer-encoding:mime-version :message-id:date:subject:from; bh=Je8p+ElgbMWHwSChEO9BBlTTuXahfg6C1KMv0UkyYHo=; b=doqTqDxrZ67LFOyBRACclcFr9bt3La2vX+ca5JmOD1pstVPQPmZuexWv50/SZFN1x2 gmyKMewyUAU4RPcO/aO73gnHr3X4sJqcDwreAlQwhZehnlwX06xCQWPsCeFWflfQLoxP 95meJO5iTYm7DLlQEdCPRO01FRYVYZjrPc6FNzjmBrIa1nLQAdhnu/O/rj1V976kzi1D Ty612ZJD85Zkr0zuaVI6e329rxTRpdWjwfa7sj4C5tyQ9djRYiwP0G6gmqy0EMcTUEjg sgKRNsrcNItBy/RxlSOFdDuC+sQsI8yMxAJwaNdVw6yVRp5vsbZ+9nyq1Gy2iR8GnTEP Mosg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r13-20020a170906280d00b0091fff42ea83si12154907ejc.273.2023.04.05.02.38.14; Wed, 05 Apr 2023 02:38:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237488AbjDEJ3C (ORCPT <rfc822;lkml4gm@gmail.com> + 99 others); Wed, 5 Apr 2023 05:29:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53358 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237534AbjDEJ2e (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 5 Apr 2023 05:28:34 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4DB9C5BA6 for <linux-kernel@vger.kernel.org>; Wed, 5 Apr 2023 02:28:06 -0700 (PDT) Received: from dude02.red.stw.pengutronix.de ([2a0a:edc0:0:1101:1d::28]) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from <m.felsch@pengutronix.de>) id 1pjzPx-0004pA-P4; Wed, 05 Apr 2023 11:27:01 +0200 From: Marco Felsch <m.felsch@pengutronix.de> Subject: [PATCH 00/12] Rework PHY reset handling Date: Wed, 05 Apr 2023 11:26:51 +0200 Message-Id: <20230405-net-next-topic-net-phy-reset-v1-0-7e5329f08002@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIANs+LWQC/x2NQQrDMAwEvxJ0rsFNXUL7ldKD40i1ICjGckpKy N8rcljY2cPsDoqVUeHZ7VDxy8qLGFwvHaQc5YOOJ2PofX/zwd+dYLNszbWlcDqx5J+rqNYCDQ+ iYaIQPZhijIpurFFSNoms82xjqUi8nZ+v93H8AdfhtMyDAAAA To: Andrew Lunn <andrew@lunn.ch>, Heiner Kallweit <hkallweit1@gmail.com>, Russell King <linux@armlinux.org.uk>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Florian Fainelli <f.fainelli@gmail.com>, Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, Richard Cochran <richardcochran@gmail.com>, Radu Pirea <radu-nicolae.pirea@oss.nxp.com>, Shyam Sundar S K <Shyam-sundar.S-k@amd.com>, Yisen Zhuang <yisen.zhuang@huawei.com>, Salil Mehta <salil.mehta@huawei.com>, Jassi Brar <jaswinder.singh@linaro.org>, Ilias Apalodimas <ilias.apalodimas@linaro.org>, Iyappan Subramanian <iyappan@os.amperecomputing.com>, Keyur Chudgar <keyur@os.amperecomputing.com>, Quan Nguyen <quan@os.amperecomputing.com>, "Rafael J. Wysocki" <rafael@kernel.org>, Len Brown <lenb@kernel.org>, Rob Herring <robh+dt@kernel.org>, Frank Rowand <frowand.list@gmail.com> Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, devicetree@vger.kernel.org, kernel@pengutronix.de X-Mailer: b4 0.12.1 X-SA-Exim-Connect-IP: 2a0a:edc0:0:1101:1d::28 X-SA-Exim-Mail-From: m.felsch@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762328594616181625?= X-GMAIL-MSGID: =?utf-8?q?1762328594616181625?= |
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
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 >