RE: Generic Ethernet PHY Driver Patch

[Jay Foster <jay at systech dot com>]

I could see doing that.  One idea would be to add a PHY device function
(config) to the _eth_phy_dev_entry structure.  If the function is undefined
(config==NULL), then the _eth_phy_cfg() function would perform the generic
PHY configuration operation by adjusting the advertisement register
(currently proposed patch).  If the config() function is defined
(config!=NULL), then the _eth_phy_cfg() function would call the PHY device
config() function to perform any such configuration.  This would provide a
mechanism for a PHY device to override the generic implementation when
necessary, while still permitting many PHY devices to use the generic code
(reduced code duplication).

In _eth_phy_cfg(), you could have:

	/* Reset PHY ... */

	if (f->dev->config != NULL)
		f->dev->config(f, mode);
	else
		/* generic PHY configuration */

	/* Restart PHY auto negotiation */

Jay

-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: Friday, April 28, 2006 3:59 PM
To: Jay Foster
Cc: eCos patches
Subject: RE: Generic Ethernet PHY Driver Patch


On Fri, 2006-04-28 at 13:50 -0700, Jay Foster wrote:
> I guess I still don't understand the issue.  The attached patch does not
> involve any CDL configury changes.  It deliberately leaves it up the the
> ethernet driver to decide how to determine the configuration value (hard
> coded, run-time, CDL, etc.).  This seems the most flexible.  I have
> applications that configure this from the ethernet driver initialization,
> and others that permit run-time configuration too.  Where, when, and how
the
> configuration is determined is beyond the scope of the PHY driver and left
> to the ethernet driver and/or application layer.

Sorry, my fault - I misread your changes.  The one problem I see with 
how this works (and indeed, I'm responsible) is that not all PHY devices
will use the same mechanisms or even registers to detect/adjust these
settings.  It may be necessary to have a way to define a function which 
performs the configuration magic on a PHY [type] basis.  For now though,
I'll merge these changes, but maybe we [collectively] should think about
what's required down the road.

> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Sent: Friday, April 28, 2006 10:10 AM
> To: Jay Foster
> Cc: eCos patches
> Subject: RE: Generic Ethernet PHY Driver Patch
> 
> 
> On Fri, 2006-04-28 at 10:03 -0700, Jay Foster wrote:
> > I don't understand what it is you are asking for.  Can you be more
> specific?
> 
> Rather than have these items set by CDL only, I think they should
> be set when the PHY is initialized by the ethernet driver.  For
> example, I have hardware which may have any selection of 1000Mb 
> (Gigabit), 100Mb or 10Mb devices and a single CDL selection is
> not adequate.  If we are to change/add to the PHY layer support,
> it only makes sense to do so in the most flexible manner.
> 
> > -----Original Message-----
> > From: Gary Thomas [mailto:gary@mlbassoc.com]
> > Sent: Thursday, April 27, 2006 4:48 PM
> > To: Jay Foster
> > Cc: eCos patches
> > Subject: Re: Generic Ethernet PHY Driver Patch
> > 
> > 
> > On Thu, 2006-04-27 at 11:35 -0700, Jay Foster wrote:
> > > Attached is a patch for the generic ethernet PHY driver that adds the
> > > capability to configure the PHY speed/duplex.
> > 
> > I would much prefer for the chosen speed/duplex to be passed in
> > when initializing the PHY and/or add a new call.  I have many
> > systems where one configuration does not fit all devices.
> > 
> > Could you rework your changes to have this flexibility?
> > 
> > Thanks
> > 
-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------