Hi Ben,
how does look like your propose work about PHY lib?
Thanks, Michal
Hi Michal, Michal Simek wrote:
Hi Ben,
how does look like your propose work about PHY lib?
Thanks, Michal
I'd like to have the PHY library included in the 02.2009 release. One of the things I'm struggling with is how so specify MDIO busses and PHY addresses. For example, is it preferable to have a bunch of CONFIG_PHY_ADDR_x or a board-code struct? How to link/register PHYs with MDIO buses, since conceivably a board could have hardware MDIO and/or bit-banged MDIO, and any PHY could be on any bus.
If we pulled all board info from a device tree, as people were talking about a few months ago, this would be easy and scalable. I don't know the status of that idea, and am very interested in what you and others think.
regards, Ben
Dear Ben,
In message 492C4475.70306@gmail.com you wrote:
I'd like to have the PHY library included in the 02.2009 release. One
v2009.02, that is :-)
If we pulled all board info from a device tree, as people were talking about a few months ago, this would be easy and scalable. I don't know the status of that idea, and am very interested in what you and others think.
I would really appreciate a move into this direction.
BTW - Wolfgang: do you still plan to rebase & post your "Configure U-Boot with a Device Tree" patches? They must have grown out of sync terribly?
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Dear Ben,
In message 492C4475.70306@gmail.com you wrote:
I'd like to have the PHY library included in the 02.2009 release. One
v2009.02, that is :-)
If we pulled all board info from a device tree, as people were talking about a few months ago, this would be easy and scalable. I don't know the status of that idea, and am very interested in what you and others think.
I would really appreciate a move into this direction.
BTW - Wolfgang: do you still plan to rebase & post your "Configure U-Boot with a Device Tree" patches? They must have grown out of sync terribly?
Well, not really. The patch providing access to the FDT is quite simple, making use of it is another subject and requires a FDT aware device interface, in the first place. Search for
"[U-Boot-Users] using a flat device tree to drive u-boot config"
to find the last discussion on this topic.
Wolfgang.
Dear Wolfgang,
In message 492C5744.5010205@grandegger.com you wrote:
BTW - Wolfgang: do you still plan to rebase & post your "Configure U-Boot with a Device Tree" patches? They must have grown out of sync terribly?
Well, not really. The patch providing access to the FDT is quite simple, making use of it is another subject and requires a FDT aware device interface, in the first place. Search for
"[U-Boot-Users] using a flat device tree to drive u-boot config"
to find the last discussion on this topic.
yes, I know. Maybe we should make the old stuff available in a branch in our git repo so we can at least show others the existing code? That would require little effort and probably be a good base for further discussions?
Best regards,
Wolfgang Denk
On Tue, Nov 25, 2008 at 12:31 PM, Ben Warren biggerbadderben@gmail.com wrote:
Hi Michal, Michal Simek wrote:
Hi Ben,
how does look like your propose work about PHY lib?
Thanks, Michal
I'd like to have the PHY library included in the 02.2009 release. One of the things I'm struggling with is how so specify MDIO busses and PHY addresses. For example, is it preferable to have a bunch of CONFIG_PHY_ADDR_x or a board-code struct? How to link/register PHYs with MDIO buses, since conceivably a board could have hardware MDIO and/or bit-banged MDIO, and any PHY could be on any bus.
I think the board-code should pass it in. Each nic just needs a pointer to its PHY. Some boards will have hard-coded addresses, and some will have addresses that change depending on circumstances (the DS boards use different PHYs when they are operating in SGMII mode, for instance). Some boards will even have set it up so you have to scan for a PHY. Many PCI nics seem to require this, despite its inherent fragility.
So I think if the board code were able to find PHY handles, then we can let the boards decide how to get that information (and eventually transition to pulling it out of a device tree)
Andy
participants (5)
-
Andy Fleming -
Ben Warren -
Michal Simek -
Wolfgang Denk -
Wolfgang Grandegger