All of lore.kernel.org
 help / color / mirror / Atom feed
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:56:06 -0700	[thread overview]
Message-ID: <50354766.7030700@boundarydevices.com> (raw)
In-Reply-To: <CAKWjMd5EXZnZhtPY3RJzWOFNq3w2zioSfiMyD4k8k7oL9+-3wA@mail.gmail.com>

On 08/22/2012 01:50 PM, Andy Fleming wrote:
> On Wed, Aug 22, 2012 at 3:11 PM, Eric Nelson
> <eric.nelson@boundarydevices.com>  wrote:
>> On 08/20/2012 05:35 PM, Andy Fleming wrote:
>>>
>>> On Monday, August 20, 2012, Troy Kisky wrote:
>>>
>>> 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?
>
> More like having the board code call into the driver, to tell it:
> Here's where to find your PHY.
>
>>
>>> 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.
>
> Oh, I understand, fully. My argument is actually that it's even worse
> than that. Imagine that there's a scenario where there's a valid PHY
> at 4 AND 6, but under certain circumstances, your controller is hooked
> up to 6. With the mask solution, the driver will always connect to 4
> (assuming your mask includes 4 and 6). So now, to solve that, you have
> to add more logic, but because the knowledge of the PHY is entirely
> encoded in the ethernet driver and the board config file, there's no
> way to insert logic, except in the driver.
>
> I think that many people will find the need to search the bus, and a
> mask like the one in this patch is a very good way. But the driver
> shouldn't do the searching, IMO.
>

Thanks for the clarification Andy. I didn't understand where you were
headed and it's now clear.

Regards,


Eric

  reply	other threads:[~2012-08-22 20:56 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
2012-08-22 20:50       ` Andy Fleming
2012-08-22 20:56         ` Eric Nelson [this message]
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=50354766.7030700@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 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.