From: Eric Nelson <eric.nelson@boundarydevices.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V1 1/3] phy: add phy_connect_by_mask
Date: Wed, 22 Aug 2012 13:11:10 -0700 [thread overview]
Message-ID: <50353CDE.90901@boundarydevices.com> (raw)
In-Reply-To: <CAKWjMd66_kLVyotpcBvz_pVv61zdMifMHByFLR_xpFMWGjbCZQ@mail.gmail.com>
On 08/20/2012 05:35 PM, Andy Fleming wrote:
> On Monday, August 20, 2012, Troy Kisky wrote:
>
>> It is useful to be able to try a range of
>> possible phy addresses to connect.
>
>
>
> This seems like it just encourages a bad habit. How do you envision this
> working on a system with multiple Ethernet controllers? Or with more PHYs
> than Ethernet controllers? While it is often the case that the PHY is the
> only one on a bus, I think it's a bad idea to codify that notion in the
> driver (I know, it was already like that).
>
> It's best if the driver make the reasonable assumption that its PHY address
> is known when it comes up, and let the board code, which can be aware that
> the PHY may exist in varying locations, search for the PHY.
A mask with a single bit set is about as specific as you can get, right?
Are you asking for something more extensible, like a callback into
board-specific code?
> With that approach, the driver won't have to change when some board
> designer makes the PHY topology even stranger, and I would support
> a PHYLIB function to do searching much as you've specified.
The primary reason for this change is that it's not only the board
designer, but also the purchasing manager or manufacturer who can
change the address.
Since the PHY addresses are often driven by the state of LEDs on
an ethernet connector, swapping part numbers can result in different
PHY addresses. We run into this on our Nitrogen6X boards where
PoE-enabled jacks result in a different PHY address from a standard jack.
> But the board-specific code needs to be able to tell the driver definitively
> which PHY belongs to it.
>
>
> Andy
next prev parent reply other threads:[~2012-08-22 20:11 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-20 22:48 [U-Boot] [PATCH V1 1/3] phy: add phy_connect_by_mask Troy Kisky
2012-08-20 22:48 ` [U-Boot] [PATCH V1 2/3] fec_mxc: use phy_connect_by_mask Troy Kisky
2012-08-20 22:48 ` [U-Boot] [PATCH V1 3/3] mx6qsabrelite: set CONFIG_FEC_MXC_PHYMASK Troy Kisky
2012-08-20 23:07 ` [U-Boot] [PATCH V1 1/3] phy: add phy_connect_by_mask Troy Kisky
2012-08-21 0:35 ` Andy Fleming
2012-08-22 19:59 ` Troy Kisky
2012-08-22 20:40 ` Andy Fleming
2012-08-22 20:50 ` Joe Hershberger
2012-08-22 21:21 ` Troy Kisky
2012-09-26 17:26 ` Joe Hershberger
2012-09-26 17:47 ` Troy Kisky
2012-08-22 20:11 ` Eric Nelson [this message]
2012-08-22 20:50 ` Andy Fleming
2012-08-22 20:56 ` Eric Nelson
2012-10-23 2:40 ` [U-Boot] [PATCH V3 0/9] separate miiphy from ethernet Troy Kisky
2012-10-23 2:40 ` [U-Boot] [PATCH V3 1/9] doc/README.fec_mxc: add documentation Troy Kisky
2012-10-23 2:40 ` [U-Boot] [PATCH V3 2/9] net: fec_mxc: delete CONFIG_FEC_MXC_MULTI Troy Kisky
2012-10-23 2:40 ` [U-Boot] [PATCH V3 3/9] net: fec_mxc: change fec_mii_setspeed parameter Troy Kisky
2012-10-23 2:40 ` [U-Boot] [PATCH V3 4/9] net: fec_mxc: have fecmxc_initialize call fecmxc_initialize_multi Troy Kisky
2012-10-23 2:40 ` [U-Boot] [PATCH V3 5/9] phy: add phy_find_by_mask/phy_connect_dev Troy Kisky
2012-10-23 2:40 ` [U-Boot] [PATCH V3 6/9] net: fec_mxc: use fec_set_dev_name to set name Troy Kisky
2012-10-23 2:40 ` [U-Boot] [PATCH V3 7/9] net: fec_mxc: only call phy_connect in fec_probe Troy Kisky
2012-10-23 2:40 ` [U-Boot] [PATCH V3 8/9] net: fec_mxc: get phydev before fec_probe Troy Kisky
2012-10-23 2:40 ` [U-Boot] [PATCH V3 9/9] mx6qsabrelite: search mii phy address 4-7 Troy Kisky
2012-11-10 7:28 ` [U-Boot] [PATCH V3 0/9] separate miiphy from ethernet Stefano Babic
2013-01-22 23:48 ` Troy Kisky
2013-01-23 8:48 ` Stefano Babic
2013-01-23 19:06 ` Troy Kisky
2013-01-24 9:09 ` Stefano Babic
2013-01-23 22:35 ` Troy Kisky
2013-01-03 22:00 ` Troy Kisky
2013-01-28 6:00 ` Stefano Babic
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=50353CDE.90901@boundarydevices.com \
--to=eric.nelson@boundarydevices.com \
--cc=u-boot@lists.denx.de \
/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