lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 10 Feb 2010 11:14:47 -0700 From: Grant Likely <grant.likely@...retlab.ca> To: John Linn <John.Linn@...inx.com> Cc: devicetree-discuss <devicetree-discuss@...ts.ozlabs.org>, netdev <netdev@...r.kernel.org>, Andy Fleming <afleming@...escale.com>, Scott Wood <scottwood@...escale.com> Subject: Re: phy address in the device tree, vs auto probing On Wed, Feb 10, 2010 at 9:52 AM, John Linn <John.Linn@...inx.com> wrote: >> -----Original Message----- >> From: glikely@...retlab.ca [mailto:glikely@...retlab.ca] On Behalf Of Grant Likely >> Sent: Wednesday, February 10, 2010 9:44 AM >> To: John Linn; devicetree-discuss; netdev >> Subject: Re: phy address in the device tree, vs auto probing >> >> (cc'ing devicetree-discuss and netdev mailing lists) >> >> On Tue, Feb 9, 2010 at 4:23 PM, John Linn <John.Linn@...inx.com> wrote: >> > Hi Grant, >> > >> > I notice that the OF driver for the mdio bus is not doing auto probing. >> > >> > As we start putting in the phy layer in the emac drivers, the device >> > trees tend to have the phy address in them, but we're not sure we really >> > like that. >> > >> > We really think that being able to let the kernel find the phy address >> > is a big benefit, otherwise this is one other piece of info the user has >> > to know and get right. >> > >> > Am I missing something here? >> >> No, you're not really missing something, but there is an inherent >> complexity in what you're wanting to do. Like i2c, MDIO is one of >> those busses that is hard to probe reliable. Some PHYs respond on >> more than one address, and there is no way to determine which MAC a >> PHY is wired up to. Many PHYs can live on a single MDIO bus. MACs >> with their own MDIO busses may still get wired to a PHY on a different >> bus. >> >> In the simple case where there is a one:one:one relationship between >> MAC, MDIO bus and PHY, then it should be okay to probe the PHY, >> correct? The question then must be asked; how does the kernel >> determine that it can use the simple case? Nobody has yet defined a >> way to describe that in the device tree; mostly because nobody has >> needed to yet. >> >> So, it is possible to do what you want, but you need a way to >> *explicitly* ask for that behaviour. ie, some way to indicate in a >> MAC node which MDIO bus the phy is on, and that the phy needs to be >> probed for. I think this should only be an option when the MDIO bus >> has only one PHY. Come up with a proposal and post it to the >> devicetree-discuss mailing list. > > Here's a couple ideas. See what everyone thinks as I'm not stuck on either. > > Thanks, > John > > 1. What if we just don't specific a phy address with a reg property which would specify to auto probe it and find the phy as illustrated below? > > > Ethernet_MAC: ethernet@...00000 { > #address-cells = <1>; > #size-cells = <1>; > phy-handle = <&phy0>; > mdio { > #address-cells = <1>; > #size-cells = <0>; > phy0: phy@7 { > } ; > } ; > > 2. Or a special value (-1 or something not 0 - 31) in the phy address that specifies to auto probe as illustrated below. > phy0: phy@7 { > reg = <-1>; > } ; I don't like abusing the reg property in this way. I wonder if a new empty property would be a better way to indicate this. Maybe "phy-probe-address;"? It would also be important to specify in the binding that only one phy node is allowed when phy-probe-address is used. Also, without a known reg the 'phy@7' name is inaccurate. Drop the @7. Scott, Andy: any thoughts? g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists