Re: [PATCH] Add Broadcom PHY support

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

quoted

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