On Mon, 2006-05-01 at 15:09 -0500, Mark Schank wrote:
> The Cogent CSB655 used the Broadcom Dual Phy. They eventually redesigned
> the board and switched to two single Broadcom phys, but they continued to
> control both phys through MAC0, which is the actual purpose of the dual-phy
> hack. I am a user of the CSB655, so I sort of care.
>
> Will the new PHY framework allow a second PHY for a second MAC (MAC1) be
> controlled from the first MAC's (MAC0) mdio interface?
should'nt be a problem (as opposed to the bosporus case... see below)...
I assume the phy-addresses on which the boarcom dual phy is configured
are the same for all Cogent CSB655 boards?
does this need to be autodetected dynamically at runtime, or can we rely
on a compile time Kconfig-conditional to set a static phy-addr<->eth%
d-phy mapping for this board-specific case? Or de we really need such a
complex mii_probe() function to detect weird scenarios? :)
using static phy addr mappings would also allow for setting
board-specific phy-irq assignments, which would then be handled by the
phylib facilities, instead of polling the status of phy with a timer;
(and in case we don't have any board-specific compile time setting, we
can still fall back to search the phy-addresses for a PHY at runtime as
the generic case)
while at it, what about that CONFIG_MIPS_BOSPORUS special case? why
doesn't the 2nd MAC see any PHY? how is the 2nd MAC connected to the
physical world?
#ifdef CONFIG_MIPS_BOSPORUS
/* This is a workaround for the Micrel/Kendin 5 port switch
The second MAC doesn't see a PHY connected... so we need to
trick it into thinking we have one.
If this kernel is run on another Au1500 development board
the stub will be found as well as the actual PHY. However,
the last found PHY will be used... usually at Addr 31 (Db1500).
*/
> Yes, I acknowledge this was a bad design, but its what I am stuck with.
:-)
--
Herbert Valerio Riedel <hvr@xxxxxxx>
