[PATCH] Add Broadcom PHY support

[PATCH] Add Broadcom PHY support

This patch adds a driver to support the bcm5421s and bcm5461s PHY

Kernel version:  linux-2.6.18-rc6

Signed-off-by: Amy Fong <redacted>

Amy Fong wrote:

[PATCH] Add Broadcom PHY support

This patch adds a driver to support the bcm5421s and bcm5461s PHY

Kernel version:  linux-2.6.18-rc6

Signed-off-by: Amy Fong <redacted>

And... where are the users of this phy driver?

	Jeff

[ Charset ISO-8859-1 unsupported, converting... ]

Amy Fong wrote:

quoted

[PATCH] Add Broadcom PHY support

This patch adds a driver to support the bcm5421s and bcm5461s PHY

Kernel version:  linux-2.6.18-rc6

Signed-off-by: Amy Fong <redacted>

And... where are the users of this phy driver?

	Jeff

This phy driver is used by the WRS's sbc8560 (bcm5421s) and sbc843x (bcm5461s) via the gianfar driver.

Amy

On Tue, 19 Sep 2006, Amy Fong wrote:

quoted

And... where are the users of this phy driver?

[...]

This phy driver is used by the WRS's sbc8560 (bcm5421s) and sbc843x 
(bcm5461s) via the gianfar driver.

 And sb1250-mac.c would be happy to use it too.

  Maciej

Maciej W. Rozycki wrote:

On Tue, 19 Sep 2006, Amy Fong wrote:

quoted

quoted

And... where are the users of this phy driver?

[...]

quoted

This phy driver is used by the WRS's sbc8560 (bcm5421s) and sbc843x 
(bcm5461s) via the gianfar driver.

 And sb1250-mac.c would be happy to use it too.

"would be happy to" != "is using".   I don't want to add a phy driver 
until there are already active users in the kernel.

	Jeff

On Tue, 19 Sep 2006, Jeff Garzik wrote:

quoted

 And sb1250-mac.c would be happy to use it too.

"would be happy to" != "is using".   I don't want to add a phy driver until
there are already active users in the kernel.

 Fair enough, but Amy may be looking forward to seeing yet another piece 
of code using the new driver. ;-)

  Maciej

On Fri, 2006-09-15 at 16:15 -0400, Amy Fong wrote:

[PATCH] Add Broadcom PHY support

This patch adds a driver to support the bcm5421s and bcm5461s PHY

Kernel version:  linux-2.6.18-rc6

Signed-off-by: Amy Fong 

Some 5421's need special initialisation (see drivers/net/sungem_phy.c),
might be worth having them there too. I was also wondering... for
spidernet, we need to enable the fiber mode on the PHY. Does phylib has
an API for that ?

I'd like to look into moving sungem and spidernet over to phylib.

Ben.

On Fri, 2006-09-15 at 16:15 -0400, Amy Fong wrote:

quoted

[PATCH] Add Broadcom PHY support

This patch adds a driver to support the bcm5421s and bcm5461s PHY

Kernel version:  linux-2.6.18-rc6

Signed-off-by: Amy Fong 

Some 5421's need special initialisation (see drivers/net/sungem_phy.c),
might be worth having them there too. I was also wondering... for
spidernet, we need to enable the fiber mode on the PHY. Does phylib has
an API for that ?

I'd like to look into moving sungem and spidernet over to phylib.

Ben.

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>
};

ie.

static struct phy_driver bcm5421s_driver = {
<snip>
	.config_init = bcm5421s_phy_config,
<snip>
};

int bcm5421s_phy_config(struct phy_device *phydev)
{
...
	/* enable fiber mode here... */
...
}

Amy

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...

Ben.

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