From: Andrew Lunn <andrew@lunn.ch> To: Jeremy Linton <jeremy.linton@arm.com> Cc: Calvin Johnson <calvin.johnson@oss.nxp.com>, Andy Shevchenko <andy.shevchenko@gmail.com>, "Rafael J . Wysocki" <rafael@kernel.org>, Russell King - ARM Linux admin <linux@armlinux.org.uk>, linux.cj@gmail.com, Florian Fainelli <f.fainelli@gmail.com>, Cristi Sovaiala <cristian.sovaiala@nxp.com>, Florin Laurentiu Chiculita <florinlaurentiu.chiculita@nxp.com>, Ioana Ciornei <ioana.ciornei@nxp.com>, Madalin Bucur <madalin.bucur@oss.nxp.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Heikki Krogerus <heikki.krogerus@linux.intel.com>, Varun Sethi <V.Sethi@nxp.com>, "Rajesh V . Bikkina" <rajesh.bikkina@nxp.com>, ACPI Devel Maling List <linux-acpi@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Diana Madalina Craciun <diana.craciun@nxp.com>, netdev <netdev@vger.kernel.org>, Marcin Wojtas <mw@semihalf.com>, Laurentiu Tudor <laurentiu.tudor@nxp.com>, Makarand Pawagi <makarand.pawagi@nxp.com>, linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>, Pankaj Bansal <pankaj.bansal@nxp.com>, "David S. Miller" <davem@davemloft.net>, Heiner Kallweit <hkallweit1@gmail.com> Subject: Re: [net-next PATCH v3 4/5] net: phy: Introduce fwnode_get_phy_id() Date: Fri, 8 May 2020 22:27:22 +0200 [thread overview] Message-ID: <20200508202722.GI298574@lunn.ch> (raw) In-Reply-To: <1e33605e-42fd-baf8-7584-e8fcd5ca6fd3@arm.com> > > There is a very small number of devices where the vendor messed up, > > and did not put valid contents in the ID registers. In such cases, we > > can read the IDs from device tree. These are then used in exactly the > > same way as if they were read from the device. > > > > Is that the case here? Sorry, I don't understand the question? > Also, how much of this was caused by uboot being deficient None. It is a silicon issue. The PHY chip simply has the wrong or no ID value in the registers. > > Not exactly true. It is the combination of can the bus master do C45 > > and can the device do C45. Unfortunately, we have no knowledge of the > > bus masters capabilities, if it can do C45. And many MDIO drivers will > > do a C22 transaction when asked to perform a C45 transaction. All new > > submissions for MDIO drivers i ask for EOPNOTSUPP to be returned if > > C45 is not supported. But we cannot rely on that. Too much history > > > > > > > I tend to agree with you on this. Even for DT, ideal case, IMO should be: > > > > > > 1) mdiobus_scan scans the mdiobus for c22 devices by reading phy id from > > > registers 2 and 3 > > > 2) if not found scan for c45 devices <= looks like this is missing in Linux > > > 3) look for phy_id from compatible string. > > > > It is somewhat more complex, in that there are a small number of > > devices which will respond to both C22 and C45. Generally, you want to > > use C45 if supported. So you would want to do the C45 scan first. But > > then the earlier problem comes to play, you have no idea if the bus > > master actually correctly supports C45. > > But this shouldn't this be implied by the mdio vendor/model? Nope. Many MDIO bus masters don't even appear in DT, because they are embedded into the MAC driver. The MAC driver just instantiates an MDIO device, maybe passing a pointer where to find the PHY properties in DT. If the MDIO bus master is in its own address range, then it probably does exist in device tree, and has a compatible string. But that just gets the driver loaded, it says nothing about what it is capable of, C22 and or C45. And there are cases where the MDIO bus is embedded inside an Ethernet switch, which is hanging off another MDIO bus, etc. > How much of this can be simplified for ACPI buy ignoring the legacy and > putting some guides around the ACPI/platform requirements? You can probably ignore the phy-idXXXX.YYYY compatible, since that is working around silicon issues, and put in place some guidelines that the PHY silicon needs to conform to the basics of C22 and C45 in terms of ID registers. C45 you are going to need. ACPI tends to be more high end devices, which in general have higher speed network interfaces. Multi-Gige PHYs tend to be C45. But there is also interest in using ACPI on 1G PHYs where the majority is C22. Andrew
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew@lunn.ch> To: Jeremy Linton <jeremy.linton@arm.com> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>, "Rafael J . Wysocki" <rafael@kernel.org>, Cristi Sovaiala <cristian.sovaiala@nxp.com>, Ioana Ciornei <ioana.ciornei@nxp.com>, Florian Fainelli <f.fainelli@gmail.com>, "Rajesh V . Bikkina" <rajesh.bikkina@nxp.com>, Pankaj Bansal <pankaj.bansal@nxp.com>, Russell King - ARM Linux admin <linux@armlinux.org.uk>, Diana Madalina Craciun <diana.craciun@nxp.com>, ACPI Devel Maling List <linux-acpi@vger.kernel.org>, Andy Shevchenko <andy.shevchenko@gmail.com>, Florin Laurentiu Chiculita <florinlaurentiu.chiculita@nxp.com>, Madalin Bucur <madalin.bucur@oss.nxp.com>, Makarand Pawagi <makarand.pawagi@nxp.com>, Varun Sethi <V.Sethi@nxp.com>, Marcin Wojtas <mw@semihalf.com>, linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>, Laurentiu Tudor <laurentiu.tudor@nxp.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Calvin Johnson <calvin.johnson@oss.nxp.com>, linux.cj@gmail.com, netdev <netdev@vger.kernel.org>, "David S. Miller" <davem@davemloft.net>, Heiner Kallweit <hkallweit1@gmail.com> Subject: Re: [net-next PATCH v3 4/5] net: phy: Introduce fwnode_get_phy_id() Date: Fri, 8 May 2020 22:27:22 +0200 [thread overview] Message-ID: <20200508202722.GI298574@lunn.ch> (raw) In-Reply-To: <1e33605e-42fd-baf8-7584-e8fcd5ca6fd3@arm.com> > > There is a very small number of devices where the vendor messed up, > > and did not put valid contents in the ID registers. In such cases, we > > can read the IDs from device tree. These are then used in exactly the > > same way as if they were read from the device. > > > > Is that the case here? Sorry, I don't understand the question? > Also, how much of this was caused by uboot being deficient None. It is a silicon issue. The PHY chip simply has the wrong or no ID value in the registers. > > Not exactly true. It is the combination of can the bus master do C45 > > and can the device do C45. Unfortunately, we have no knowledge of the > > bus masters capabilities, if it can do C45. And many MDIO drivers will > > do a C22 transaction when asked to perform a C45 transaction. All new > > submissions for MDIO drivers i ask for EOPNOTSUPP to be returned if > > C45 is not supported. But we cannot rely on that. Too much history > > > > > > > I tend to agree with you on this. Even for DT, ideal case, IMO should be: > > > > > > 1) mdiobus_scan scans the mdiobus for c22 devices by reading phy id from > > > registers 2 and 3 > > > 2) if not found scan for c45 devices <= looks like this is missing in Linux > > > 3) look for phy_id from compatible string. > > > > It is somewhat more complex, in that there are a small number of > > devices which will respond to both C22 and C45. Generally, you want to > > use C45 if supported. So you would want to do the C45 scan first. But > > then the earlier problem comes to play, you have no idea if the bus > > master actually correctly supports C45. > > But this shouldn't this be implied by the mdio vendor/model? Nope. Many MDIO bus masters don't even appear in DT, because they are embedded into the MAC driver. The MAC driver just instantiates an MDIO device, maybe passing a pointer where to find the PHY properties in DT. If the MDIO bus master is in its own address range, then it probably does exist in device tree, and has a compatible string. But that just gets the driver loaded, it says nothing about what it is capable of, C22 and or C45. And there are cases where the MDIO bus is embedded inside an Ethernet switch, which is hanging off another MDIO bus, etc. > How much of this can be simplified for ACPI buy ignoring the legacy and > putting some guides around the ACPI/platform requirements? You can probably ignore the phy-idXXXX.YYYY compatible, since that is working around silicon issues, and put in place some guidelines that the PHY silicon needs to conform to the basics of C22 and C45 in terms of ID registers. C45 you are going to need. ACPI tends to be more high end devices, which in general have higher speed network interfaces. Multi-Gige PHYs tend to be C45. But there is also interest in using ACPI on 1G PHYs where the majority is C22. Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-05-08 20:27 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-05 13:29 [net-next PATCH v3 0/5] Introduce new fwnode based APIs to support phylink and phy layers Calvin Johnson 2020-05-05 13:29 ` Calvin Johnson 2020-05-05 13:29 ` [net-next PATCH v3 1/5] net: phy: Introduce phy related fwnode functions Calvin Johnson 2020-05-05 13:29 ` Calvin Johnson 2020-05-05 14:44 ` Russell King - ARM Linux admin 2020-05-05 14:44 ` Russell King - ARM Linux admin 2020-05-05 23:21 ` kbuild test robot 2020-05-05 23:21 ` kbuild test robot 2020-05-05 23:39 ` Russell King - ARM Linux admin 2020-05-05 23:39 ` Russell King - ARM Linux admin 2020-05-06 0:07 ` kbuild test robot 2020-05-06 0:07 ` kbuild test robot 2020-05-05 13:29 ` [net-next PATCH v3 2/5] net: phy: alphabetically sort header includes Calvin Johnson 2020-05-05 13:29 ` Calvin Johnson 2020-05-05 13:29 ` [net-next PATCH v3 3/5] phylink: Introduce phylink_fwnode_phy_connect() Calvin Johnson 2020-05-05 13:29 ` Calvin Johnson 2020-05-05 14:13 ` Andy Shevchenko 2020-05-05 14:13 ` Andy Shevchenko 2020-05-05 14:35 ` Russell King - ARM Linux admin 2020-05-05 14:35 ` Russell King - ARM Linux admin 2020-05-05 13:29 ` [net-next PATCH v3 4/5] net: phy: Introduce fwnode_get_phy_id() Calvin Johnson 2020-05-05 13:29 ` Calvin Johnson 2020-05-05 14:15 ` Andy Shevchenko 2020-05-05 14:15 ` Andy Shevchenko 2020-05-05 14:20 ` Russell King - ARM Linux admin 2020-05-05 14:20 ` Russell King - ARM Linux admin 2020-05-07 13:26 ` Jeremy Linton 2020-05-07 13:26 ` Jeremy Linton 2020-05-07 17:27 ` Andy Shevchenko 2020-05-07 17:27 ` Andy Shevchenko 2020-05-07 19:54 ` Jeremy Linton 2020-05-07 19:54 ` Jeremy Linton 2020-05-08 16:07 ` Calvin Johnson 2020-05-08 16:07 ` Calvin Johnson 2020-05-08 18:13 ` Andrew Lunn 2020-05-08 18:13 ` Andrew Lunn 2020-05-08 19:18 ` Jeremy Linton 2020-05-08 19:18 ` Jeremy Linton 2020-05-08 20:27 ` Andrew Lunn [this message] 2020-05-08 20:27 ` Andrew Lunn 2020-05-08 22:48 ` Jeremy Linton 2020-05-08 22:48 ` Jeremy Linton 2020-05-08 23:42 ` Andrew Lunn 2020-05-08 23:42 ` Andrew Lunn 2020-05-09 0:11 ` Jeremy Linton 2020-05-09 0:11 ` Jeremy Linton 2020-05-11 8:00 ` Calvin Johnson 2020-05-11 8:00 ` Calvin Johnson 2020-05-11 9:38 ` Russell King - ARM Linux admin 2020-05-11 9:38 ` Russell King - ARM Linux admin 2020-05-11 10:29 ` Calvin Johnson 2020-05-11 10:29 ` Calvin Johnson 2020-05-11 10:48 ` Russell King - ARM Linux admin 2020-05-11 10:48 ` Russell King - ARM Linux admin 2020-05-11 12:02 ` Calvin Johnson 2020-05-11 12:02 ` Calvin Johnson 2020-05-11 13:04 ` Andrew Lunn 2020-05-11 13:04 ` Andrew Lunn 2020-05-11 13:35 ` Russell King - ARM Linux admin 2020-05-11 13:35 ` Russell King - ARM Linux admin 2020-05-11 14:59 ` Calvin Johnson 2020-05-11 14:59 ` Calvin Johnson 2020-05-11 7:39 ` Calvin Johnson 2020-05-11 7:39 ` Calvin Johnson 2020-05-11 5:52 ` Calvin Johnson 2020-05-11 5:52 ` Calvin Johnson 2020-05-11 12:53 ` Andrew Lunn 2020-05-11 12:53 ` Andrew Lunn 2020-05-05 13:29 ` [net-next PATCH v3 5/5] net: mdiobus: Introduce fwnode_mdiobus_register_phy() Calvin Johnson 2020-05-05 13:29 ` Calvin Johnson 2020-05-05 14:22 ` Andy Shevchenko 2020-05-05 14:22 ` Andy Shevchenko 2020-05-07 7:44 ` Calvin Johnson 2020-05-07 7:44 ` Calvin Johnson 2020-05-07 9:10 ` Andy Shevchenko 2020-05-07 9:10 ` Andy Shevchenko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200508202722.GI298574@lunn.ch \ --to=andrew@lunn.ch \ --cc=V.Sethi@nxp.com \ --cc=andy.shevchenko@gmail.com \ --cc=calvin.johnson@oss.nxp.com \ --cc=cristian.sovaiala@nxp.com \ --cc=davem@davemloft.net \ --cc=diana.craciun@nxp.com \ --cc=f.fainelli@gmail.com \ --cc=florinlaurentiu.chiculita@nxp.com \ --cc=gregkh@linuxfoundation.org \ --cc=heikki.krogerus@linux.intel.com \ --cc=hkallweit1@gmail.com \ --cc=ioana.ciornei@nxp.com \ --cc=jeremy.linton@arm.com \ --cc=laurentiu.tudor@nxp.com \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux.cj@gmail.com \ --cc=linux@armlinux.org.uk \ --cc=madalin.bucur@oss.nxp.com \ --cc=makarand.pawagi@nxp.com \ --cc=mw@semihalf.com \ --cc=netdev@vger.kernel.org \ --cc=pankaj.bansal@nxp.com \ --cc=rafael@kernel.org \ --cc=rajesh.bikkina@nxp.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.