From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Warren Date: Sat, 08 Dec 2007 19:44:05 -0500 Subject: [U-Boot-Users] PATCH: add support for MII-connected ethernet switch for IPX42x In-Reply-To: <475B1913.7040902@discworld.dascon.de> References: <20071110153448.GA11033@discworld.dascon.de> <20071208124024.GA32116@game.jcrosoft.org> <475B1913.7040902@discworld.dascon.de> Message-ID: <475B3A55.7090801@qstreams.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.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