porting OpenBSD's eephy(4) driver to replace makphy(4)

[Greg A. Woods]

I've run into a situation where I've been trying to use Marvell Yukon-2
ethernet ports on an embedded PC board along with Marvell 88E1112 PHYs
that have been mis-configured/mis-wired to think they have 1000base-SX
optical connections when in fact they're using copper over a backplane
connector. Unfortunately there are no public docs available for the
88E1112 (and apparently even those available under NDA are nothing to
marvel at :-)).

I found that OpenBSD's eephy(4) driver would at least get them into the
right mode (still can't test a link due to other problems(*)) and I also
found that it was infinitely easier to port the whole driver over than
it was to try to port the fixes and upgrades to NetBSD's makphy(4)
driver. The eephy(4) driver seems to completely replace all the
functionality in makphy(4), and it seems to support a bunch more chips.

The port was relatively easy (at least to NetBSD-4, which I'm still
stuck using for a wee bit longer). The harder part was that there were
some fixes also necessary in the msk(4) driver as well, and I'm not 100%
certain I've found the best way to make them work. Similar changes
might be necessary for the sk(4) driver as well, at least if it also
wants to use eephy(4) on any fibre cards.

Anyway, I'm wondering if anyone would be interested in getting this
driver into NetBSD to replace makphy(4) or not. I'll probably be moving
it to my netbsd-5 branch soon, and if necessary I could probably provide
patches for -current, though testing them would be next to impossible.
Diff's available on request -- or I can file something with send-pr.


(*) I can't actually get a link established on this board as apparently
the vendor is having problems with the chipset on the switch/service
module that this board is connected to over the backplane -- and there's
a very good chance they're having the exact same problem I tried to fix
on the embedded PC side too. :-)

[Thor Lancelot Simon]

Post by Greg A. Woods
Anyway, I'm wondering if anyone would be interested in getting this
driver into NetBSD to replace makphy(4) or not. I'll probably be moving
it to my netbsd-5 branch soon, and if necessary I could probably provide
patches for -current, though testing them would be next to impossible.
Diff's available on request -- or I can file something with send-pr.

It probably needs pretty vigorous testing with the external and integrated
Marvell PHYs on various Intel cards as well. I think OpenBSD uses the
other driver for the Intel Gig-E so it's quite unlikely that eephy has had
any testing with Intel's "Marvell" PHYs.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg A. Woods]

At Tue, 22 Jun 2010 17:48:54 -0400, Thor Lancelot Simon <***@panix.com> wrote:
Subject: Re: porting OpenBSD's eephy(4) driver to replace makphy(4)

Post by Thor Lancelot Simon
It probably needs pretty vigorous testing with the external and integrated
Marvell PHYs on various Intel cards as well.

From code inspection I would say OpenBSD's eephy(4) is a strict
super-set of NetBSD's makphy(4), and outside of another read through by
someone else who is experienced with PHY drivers, I don't think there
can be any loss by replacing makphy(4) with eephy(4) for existing uses
of makphy(4), but that's why I'm asking here.

Post by Thor Lancelot Simon
I think OpenBSD uses the
other driver for the Intel Gig-E so it's quite unlikely that eephy has had
any testing with Intel's "Marvell" PHYs.

Do you mean with the OpenBSD em(4) driver? I.e. the one with built-in
PHY support written by Intel themselves for FreeBSD, then ported to
OpenBSD? I thought though Intel only ever used their own chips on their
own cards, especially in the more recent Gig-E and 10Gig-E varieties,
including those this driver is supposed to support.


Or do you mean the Intel i82653 chip which according to miidevs seems to
match with the variant Marvell OUI number? I can't find any indication
it really is a variant of a Marvell 88Exxxx chip, and as I say I can't
find any indication on Intel's web site that Intel have ever used any
Marvell chips in their designs. In any case I think NetBSD only ever
uses ikphy(4) for that one anyway, and makphy(4) would never attach to
it in the first place because it doesn't include any entries in
makphys[] with the identical model number (0x000a).



My own worries were more with whether SysKonnect cards, particularly
fibre adapters, would require tweaking of the fibre mode hacks I've done
to msk(4) for these Marvell Yukon-2 chips and the Marvel 88E81112 PHY,
and especially if the support for recognising fibre modes would also
have to be included in the sk(4) variant of the driver as well.



BTW, further reports from the vendor on the systems I'm working on
suggest that they screwed up the backplane interconnect and that they'll
probably have to replace some modules in the system, as well as of
course upgrade the firmware on the other side so that it presents the
internal interfaces for configuration as well. If they ship us new
modules that work sooner than later maybe I'll finally be able to see if
this eephy(4) driver's 88E1112 support works for me or not.... :-)

[Thor Lancelot Simon]

Post by Greg A. Woods

Post by Thor Lancelot Simon
I think OpenBSD uses the
other driver for the Intel Gig-E so it's quite unlikely that eephy has had
any testing with Intel's "Marvell" PHYs.

Do you mean with the OpenBSD em(4) driver? I.e. the one with built-in
PHY support written by Intel themselves for FreeBSD, then ported to
OpenBSD? I thought though Intel only ever used their own chips on their
own cards, especially in the more recent Gig-E and 10Gig-E varieties,
including those this driver is supposed to support.

The early Intel cards without integrated PHY often used Marvell PHYs.
Many if not most of the Intel PHYs are derived from the separate Marvell
PHYs and some of the early integrated ones even claim to be made by
Marvell.

Since em(4) doesn't use the generic MII/PHY framework there will have been
no testing of eephy for these cases on OpenBSD. It probably wants some,
lest we break wm(4) by replacing makphy.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Greg A. Woods
[...]
Or do you mean the Intel i82653 chip which according to miidevs seems to
match with the variant Marvell OUI number? I can't find any indication
it really is a variant of a Marvell 88Exxxx chip, and as I say I can't
find any indication on Intel's web site that Intel have ever used any
Marvell chips in their designs. In any case I think NetBSD only ever
uses ikphy(4) for that one anyway, and makphy(4) would never attach to
it in the first place because it doesn't include any entries in
makphys[] with the identical model number (0x000a).

wm0 at pci3 dev 2 function 0: Intel i82546GB 1000BASE-T Ethernet, rev. 3
wm0: interrupting at irq 7
wm0: Ethernet address 00:30:48:30:56:be
makphy0 at wm0 phy 1: Marvell 88E1011 Gigabit PHY, rev. 5
makphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto