netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: rpjday@crashcourse.ca
Cc: netdev@vger.kernel.org
Subject: Re: how to distinguish between PHYs that are not distinguished in the device tree?
Date: Wed, 12 Dec 2018 16:51:28 +0100	[thread overview]
Message-ID: <20181212155128.GE1549@lunn.ch> (raw)
In-Reply-To: <20181212081655.Horde.FyM4hCmkknDNGR4H7b95n1Y@crashcourse.ca>

On Wed, Dec 12, 2018 at 08:16:55AM -0500, rpjday@crashcourse.ca wrote:
>  (i asked about this on the kernel newbies list earlier as a kind of
> puzzle but i think i really want a definitive answer so i'm taking it
> to the experts. (i will *try* to be concise.)
> 
>   imagine i'm building a bunch of 8-port switches, using PHYs from
> acme corp, who manufacture four different PHYs that differ only in
> their supported speeds, with PHY IDs that differ only in the final
> nybble which identifies the PHY speed:
> 
>   0x1234.5671   1G
>   0x1234.5672   2.5G
>   0x1234.5675   5G
>   0x1234.567A   10G
> 
>   the problem i have is that i have been handed a bucket of mixed
> PHYs of all four types that are visually indistinguishable -- the
> only way to tell them apart is, upon system boot, i can read a given
> H/W register which precisely identifies the type of PHY of the four
> possible types. however, in this situation, all i can do is reach into
> the bucket, grab eight random PHYs, bolt them in, and somehow later
> dynamically identify them at runtime. how to do this?
> 
>   first, i can't identify the precise PHY ID in the device tree file
> since i have no idea what type will be at each of the eight PHY addresses,
> so i will "wildcard" the compatible value for each of them thusly (where
> the final nybble of zero is, of course, irrelevant):
> 
>   compatible = "ethernet-phy-id1234.5670"

You don't need to specify any compatible string in the device
tree. The PHY subsystem looks at the ID registers to determine which
PHY driver to load. You only need to use ethernet-phy-id1234.5670 when
the PHY has the wrong ID in its registers.

>   moving over to the driver, it seems pretty clear that, since the
> PHY IDs i'm getting from the device tree are acme-generic, i would
> have:
> 
>   #define PHY_ID_ACME_WILDCARD  0x12345670
> 
>   #define PHY_ID_ACME_1G        0x12345671
>   #define PHY_ID_ACME_2G        0x12345672
>   #define PHY_ID_ACME_5G        0x12345675
>   #define PHY_ID_ACME_10G       0x1234567A
> 
>   #define PHY_ID_ACME_MASK      0xfffffff0
>         ...
>   static struct mdio_device_id __maybe_unused acme_tbl[] = {
>         { PHY_ID_ACME_WILDCARD, 0xfffffff0 },
>         { }
>   };

 
>   static struct phy_driver acme_driver[] = { {
>         .phy_id         = PHY_ID_ACME_WILDCARD,
>         .name           = "An ACME PHY",
>         .phy_id_mask    = PHY_ID_ACME_MASK,
>         .features       = PHY_BASIC_FEATURES,

You should try to set .features correct. So ideally, you want one
entry per PHY, listing to exact ID, the mask of 0xffffffff, and
.features set appropriately.

	  Andrew

  reply	other threads:[~2018-12-12 15:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-12 13:16 how to distinguish between PHYs that are not distinguished in the device tree? rpjday
2018-12-12 15:51 ` Andrew Lunn [this message]
2018-12-12 16:02   ` rpjday

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=20181212155128.GE1549@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=netdev@vger.kernel.org \
    --cc=rpjday@crashcourse.ca \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).