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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
