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 08:35:30 -1000 From: Mitch Bradley <wmb@...mworks.com> To: Grant Likely <grant.likely@...retlab.ca> CC: John Linn <John.Linn@...inx.com>, Scott Wood <scottwood@...escale.com>, netdev <netdev@...r.kernel.org>, devicetree-discuss <devicetree-discuss@...ts.ozlabs.org>, Andy Fleming <afleming@...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? >> > > This case is somewhat similar to "wildcard nodes" on unprobed SCSI > buses, going all the way back to pre-1275 Open Boot. Since full > probing of a SCSI bus could take a really long time (spin-up delays > etc), Open Boot would usually create a bus node for the host > controller and populate it with a disk node and a tape node, neither > of which had a reg property. That meant that there was a good chance > that you might find such devices on that bus, but their specific SCSI > bus addresses had not yet been determined. In addition to those > wildcard nodes, similar nodes with extant reg properties could also > appear, asserting the presence of a known device at the given > address. The node matching algorithm first looks for an exact match > with a reg property, and failing that, looks for a wildcard match. > FYI, wildcard matching is defined in section 4.3.3 clause (b) and section 4.3.5 of IEEE 1275-1994. -- 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