From: Ben Warren <bwarren@qstreams.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] PATCH: add support for MII-connected ethernet switch for IPX42x
Date: Sat, 08 Dec 2007 19:44:05 -0500 [thread overview]
Message-ID: <475B3A55.7090801@qstreams.com> (raw)
In-Reply-To: <475B1913.7040902@discworld.dascon.de>
Michael Schwingen wrote:
> Jean-Christophe PLAGNIOL-VILLARD wrote:
>
>> If you have a switch between your phy and your cpu the speed and
>> the duplex must be specified by the phy driver.
>>
>>
> Which PHY driver? The NPE code directly calls miiphy_read to acces
> standard PHY registers, so where does a PHY driver come into play here?
>
>
The way that you're doing it is correct - there is no PHY driver, only
access methods. Hopefully this will change soon, but I'm unfortunately
being distracted.
>> The best way is to add a function that request the phy status
>> and do not wait the phy autonegociation like done in the kernel
>> by read_status callback and it's implementation
>> genphy_read_status.
>>
>>
> I do not really see how that should work, for multiple reasons:
> - speed/duplex on the MII bus depend on the attached switch and may be
> different from the speed/duplex on any of the PHYs that are attached to
> the switch.
>
The only thing that matters is the speed/duplexity of the MII bus, which
is fixed. When connected to a switch the link is always up, and the
state of the network port needs to be determined by higher layers, most
likely be a timeout.
> - most switches (Marvell 88E6060 or similar) have multiple downstream
> ports with PHYs - which one should I poll to get useful information?
> Simply waiting for a link on any port will not guarantee that this is
> the port via which the server is connected, so polling anything is
> pretty useless IMHO.
>
> - there are switches (Marvell 88E6050) that have no MDIO interface -
> they have a fixed MII speed/duplex, and the CPU has no way to know about
> the status of any of the PHYs.
>
>
There are others (Broadcom, anyway) that use SPI as control plane. The
bottom line is that for fixed interfaces like this, software needs to
hard-wire the link state, as you've done.
> I am a bit confused - could you please clarify in what direction the
> code should evolve to solve these problems better than my patch does?
>
>
Change the CONFIG_MII_ETHSWITCH to CONFIG_FIXED_PHY (as done in Linux)
and I'll be happy. Later on we need to change things to have port-wise
granularity, but we're not there yet.
> cu
> Michael
>
>
regards,
Ben
next prev parent reply other threads:[~2007-12-09 0:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-10 15:34 [U-Boot-Users] PATCH: add support for MII-connected ethernet switch for IPX42x Michael Schwingen
2007-12-08 12:40 ` Jean-Christophe PLAGNIOL-VILLARD
2007-12-08 22:22 ` Michael Schwingen
2007-12-09 0:44 ` Ben Warren [this message]
2007-12-09 9:21 ` Jean-Christophe PLAGNIOL-VILLARD
2007-12-09 16:45 ` Michael Schwingen
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=475B3A55.7090801@qstreams.com \
--to=bwarren@qstreams.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.