From: Calvin Johnson <calvin.johnson@oss.nxp.com> To: Jeremy Linton <jeremy.linton@arm.com> Cc: 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, Andrew Lunn <andrew@lunn.ch>, 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 21:37:55 +0530 [thread overview] Message-ID: <20200508160755.GB10296@lsv03152.swis.in-blr01.nxp.com> (raw) In-Reply-To: <83ab4ca4-9c34-4cdd-4413-3b4cdf96727d@arm.com> On Thu, May 07, 2020 at 02:54:09PM -0500, Jeremy Linton wrote: > Hi, > > On 5/7/20 12:27 PM, Andy Shevchenko wrote: > > On Thu, May 7, 2020 at 4:26 PM Jeremy Linton <jeremy.linton@arm.com> wrote: > > > On 5/5/20 8:29 AM, Calvin Johnson wrote: > > > > > > + if (sscanf(cp, "ethernet-phy-id%4x.%4x", > > > > + &upper, &lower) == 2) { > > > > + *phy_id = ((upper & 0xFFFF) << 16) | (lower & 0xFFFF); > > > > + return 0; > > > > + } > > > > > Isn't the ACPI _CID() conceptually similar to the DT compatible > > > property? > > > > Where? > > Not, sure I understand exactly what your asking. AFAIK, in general the dt > property is used to select a device driver/etc based on a more to less > compatible set of substrings. The phy case is a bit different because it > codes a numerical part number into the string rather than just using > arbitrary strings to select a driver and device. But it uses that as a > vendor selector for binding to the correct driver/device. > > Rephrasing the ACPI spec, the _CID() is either a single compatible id, or a > list of ids in order of preference. Each id is either a HID (string or EISA > type id) or a bus specific string encoding vendor/device/etc. (https://elixir.bootlin.com/linux/v5.7-rc4/source/drivers/acpi/acpica/utids.c#L186). > One of the examples is "PCI\VEN_vvvv&DEV_dddd" > > So that latter case seems to be almost exactly what we have here. Got your point. Yes, the ACPI spec says the same. If we are using _CID as a string, then it must be a string that uses a bus-specific nomenclature. This AFAIU may take the format "PHY\VEN_IDvvvv&ID_DDDD" as you mentioned below and not "ethernet-phy-id004d.d072" as used in DT. So, we need to define it some where in the Linux ACPI Documentation. I don't see any best place to document this. Any suggestions? > > > > > > It even appears to be getting used in a similar way to > > > identify particular phy drivers in this case. > > > > _CID() is a string. It can't be used as pure number. > > > > It does have a numeric version defined for EISA types. OTOH I suspect that > your right. If there were a "PHY\VEN_IDvvvv&ID_DDDD" definition, it may not > be ideal to parse it. Instead the normal ACPI model of exactly matching the > complete string in the phy driver might be more appropriate. IMO, it should be fine to parse the string to extract the phy_id. Is there any reason why we cannot do this? > > Similarly to how I suspect the next patch's use of "compatible" isn't ideal > either, because whether a device is c45 or not, should tend to be fixed to a > particular vendor/device implementation and not a firmware provided > property. 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. Meanwhile, please note some usage of compatible property in edk2-platforms: https://github.com/tianocore/edk2-platforms/blob/master/Platform/96Boards/Secure96Dxe/Secure96.asl#L20 https://github.com/tianocore/edk2-platforms/blob/master/Silicon/Marvell/Armada7k8k/AcpiTables/Armada80x0McBin/Dsdt.asl#L280 https://github.com/tianocore/edk2-platforms/blob/master/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Optee.asl#L17 Regards Calvin
WARNING: multiple messages have this Message-ID (diff)
From: Calvin Johnson <calvin.johnson@oss.nxp.com> To: Jeremy Linton <jeremy.linton@arm.com> Cc: Andrew Lunn <andrew@lunn.ch>, 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>, 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 21:37:55 +0530 [thread overview] Message-ID: <20200508160755.GB10296@lsv03152.swis.in-blr01.nxp.com> (raw) In-Reply-To: <83ab4ca4-9c34-4cdd-4413-3b4cdf96727d@arm.com> On Thu, May 07, 2020 at 02:54:09PM -0500, Jeremy Linton wrote: > Hi, > > On 5/7/20 12:27 PM, Andy Shevchenko wrote: > > On Thu, May 7, 2020 at 4:26 PM Jeremy Linton <jeremy.linton@arm.com> wrote: > > > On 5/5/20 8:29 AM, Calvin Johnson wrote: > > > > > > + if (sscanf(cp, "ethernet-phy-id%4x.%4x", > > > > + &upper, &lower) == 2) { > > > > + *phy_id = ((upper & 0xFFFF) << 16) | (lower & 0xFFFF); > > > > + return 0; > > > > + } > > > > > Isn't the ACPI _CID() conceptually similar to the DT compatible > > > property? > > > > Where? > > Not, sure I understand exactly what your asking. AFAIK, in general the dt > property is used to select a device driver/etc based on a more to less > compatible set of substrings. The phy case is a bit different because it > codes a numerical part number into the string rather than just using > arbitrary strings to select a driver and device. But it uses that as a > vendor selector for binding to the correct driver/device. > > Rephrasing the ACPI spec, the _CID() is either a single compatible id, or a > list of ids in order of preference. Each id is either a HID (string or EISA > type id) or a bus specific string encoding vendor/device/etc. (https://elixir.bootlin.com/linux/v5.7-rc4/source/drivers/acpi/acpica/utids.c#L186). > One of the examples is "PCI\VEN_vvvv&DEV_dddd" > > So that latter case seems to be almost exactly what we have here. Got your point. Yes, the ACPI spec says the same. If we are using _CID as a string, then it must be a string that uses a bus-specific nomenclature. This AFAIU may take the format "PHY\VEN_IDvvvv&ID_DDDD" as you mentioned below and not "ethernet-phy-id004d.d072" as used in DT. So, we need to define it some where in the Linux ACPI Documentation. I don't see any best place to document this. Any suggestions? > > > > > > It even appears to be getting used in a similar way to > > > identify particular phy drivers in this case. > > > > _CID() is a string. It can't be used as pure number. > > > > It does have a numeric version defined for EISA types. OTOH I suspect that > your right. If there were a "PHY\VEN_IDvvvv&ID_DDDD" definition, it may not > be ideal to parse it. Instead the normal ACPI model of exactly matching the > complete string in the phy driver might be more appropriate. IMO, it should be fine to parse the string to extract the phy_id. Is there any reason why we cannot do this? > > Similarly to how I suspect the next patch's use of "compatible" isn't ideal > either, because whether a device is c45 or not, should tend to be fixed to a > particular vendor/device implementation and not a firmware provided > property. 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. Meanwhile, please note some usage of compatible property in edk2-platforms: https://github.com/tianocore/edk2-platforms/blob/master/Platform/96Boards/Secure96Dxe/Secure96.asl#L20 https://github.com/tianocore/edk2-platforms/blob/master/Silicon/Marvell/Armada7k8k/AcpiTables/Armada80x0McBin/Dsdt.asl#L280 https://github.com/tianocore/edk2-platforms/blob/master/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Optee.asl#L17 Regards Calvin _______________________________________________ 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 16:08 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 [this message] 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 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=20200508160755.GB10296@lsv03152.swis.in-blr01.nxp.com \ --to=calvin.johnson@oss.nxp.com \ --cc=V.Sethi@nxp.com \ --cc=andrew@lunn.ch \ --cc=andy.shevchenko@gmail.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.