Re: [PATCH] Add Broadcom PHY support

[Andy Fleming]

On Dec 5, 2006, at 00:03, Benjamin Herrenschmidt wrote:

> > I believe that this fiber enabling can be done by defining  
> > config_init in the phy_driver struct.
> >
> > struct phy_driver {
> > <snip>
> >         /* Called to initialize the PHY,
> > 	 * including after a reset */
> > 	int (*config_init)(struct phy_device *phydev);
> > <snip>
> > };
>
> Well... I don't know for sure... thing is, enabling the fiber mode  
> is a
> rather platform specific thing. So it's the MAC driver that knows  
> wether
> it wants it on a PHY and should call into the driver.
>
> It's difficult to abstract all possible PHY config options tho... some
> MACs might want to enable low power, some don't because they have  
> issues
> with it, that sort of thing, though.
>
> Not sure what the best solution is at this point... Maybe an ascii
> string to pass the PHY driver is the most flexible, though a bit  
> yucky,
> or we try to have a list of all the possible configuration options in
> phy.h and people just add new ones that they need as they add support
> for them...
>
> Sounds grossly like an in-kernel ioctl tho...


Each phy_device structure now has a dev_flags field that can be  
modified by the controller's code upon connecting.  The PHY driver  
can then check that field for PHY-specific, platform-specific  
interactions.  For instance, on the newer CDS, there's a Marvell PHY  
which requires configurable resistance changes to work in RGMII  
mode.  So there's a flag for that.  Basically, each PHY driver  
specifies its own flags, and the platform code is currently  
responsible for setting those flags appropriately.  A string might be  
more flexible, but I'm operating on the hope that there shouldn't be  
too many of these.

For Fiber mode, or other such changes, we might want to add another  
field, like the interface field, to describe standard external  
interfaces.  The call to phy_connect() is beginning to get a bit  
long, though.

Andy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/