MII PHY support?

MII PHY support?

[Jim Chapman]

Is anyone working on adding MII PHY support?

I've implemented support for my custom 8260 board which has a quad enet
phy. Now I'm about to add code into fcc_enet.c to handle things like
link autonegotiation and state changes. But before I go too far, I
thought it would be useful to find out if I am about to duplicate work.

I'm not ready to publish anything yet; I already have generic MII
support (not ppc specific) with hooks to phy device specific drivers and
architecture dependent h/w interface (i.e. board dependent 8260 MDIO).
Over time, new phy device drivers could be added and support for other
boards too. I envisage new ioctls to control/view the phy, and patching
ifconfig to use them.

Please let me know if you know of similar work.

Thanks

Jim


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MII PHY support?

[Dan Malek]

Jim Chapman wrote:
>
> Is anyone working on adding MII PHY support?

I try.  I have recently received two more boards with completely
different PHYs and MII implementations (through an FPGA), so I don't
know what the hell to do now.  I understand the great flexibility
by not providing a standard MDIO interface (like the 8xx), but it
really makes implementing standard software difficult.

> I've implemented support for my custom 8260 board which has a quad enet
> phy. Now I'm about to add code into fcc_enet.c to handle things like
> link autonegotiation and state changes.

Go for it.  The plan was to take the code from the 8xx FEC driver that
does a similar thing and move that to the 8260 FCC driver.  The challenge
on the 8260 is we don't get interrupts from MDIO transfers, so we can't
really just port it.  Send me small bits and pieces, I'll test it on
boards I have and we can work with anyone else here that is interested.

> I'm not ready to publish anything yet; I already have generic MII
> support (not ppc specific) with hooks to phy device specific drivers and
> architecture dependent h/w interface (i.e. board dependent 8260 MDIO).

Maybe we should just move this into a separate source file instead of
making a big configuration mess of the FCC Ethernet driver.  I'm about
to do that for some 8xx FEC functions as well.

> Over time, new phy device drivers could be added and support for other
> boards too. I envisage new ioctls to control/view the phy, and patching
> ifconfig to use them.

Is it necessary for ifconfig (or anything else) to access the control
registers in the PHY?  I haven't seen that in any of the other drivers
for other PHYs.  Don't forget to look into drivers/net for example
or other ideas :-).

Thanks.  Have fun!


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MII PHY support?

[Thomas Lange]

Dan Malek wrote:

> Maybe we should just move this into a separate source file instead of
> making a big configuration mess of the FCC Ethernet driver.  I'm about
> to do that for some 8xx FEC functions as well.

We have a custom board (GTH) with an 860 using the SCC and the FEC for
ethernet, so we have two transceivers on board.
To support auto neg. and full duplex on the SCC, we need to be able to
communicate with both transceivers. Since this communication is done
on the same MDIO pins, it would be nice to move the code out of the
fec driver and make it possible to use for scc ethernet too.

/Thomas Lange/


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MII PHY support?

[Magnus Damm]

Dan Malek wrote:

> Maybe we should just move this into a separate source file instead of
> making a big configuration mess of the FCC Ethernet driver.  I'm about
> to do that for some 8xx FEC functions as well.

the MII stuff is shared between many other drivers in the Linux kernel.
I've seen PCMCIA hardware that bitbangs some port to play around with
the
PHY registers. So, some generic bitbanging code with callbacks for the
bitsetting would be nice for them.

Have a look at the mii-tool program from the net-tools package!

Cheers /

magnus

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/