tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

At Tue, 22 Jun 2010 17:48:54 -0400, Thor Lancelot Simon 
<> wrote:
Subject: Re: porting OpenBSD's eephy(4) driver to replace makphy(4)
> 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.

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

                                                Greg A. Woods
                                                Planix, Inc.

<>       +1 416 218 0099

Attachment: pgpKyCe2GUMV8.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index