[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 <[email protected]>
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 <[email protected]>
And... where are the users of this phy driver?
Jeff
[ Charset ISO-8859-1 unsupported, converting... ]
> 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 <[email protected]>
>
> 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:
> > 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:
>
>>> 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.
"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:
> > 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:
> > [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:
>
>> 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