Date: Wed, 02 Apr 2008 13:38:52 -0500 From: Nathan Whitehorn <nathanw@uchicago.edu> To: Marcel Moolenaar <xcllnt@mac.com> Cc: freebsd-ppc@freebsd.org Subject: Re: BMAC Ethernet Driver Message-ID: <47F3D2BC.7060001@uchicago.edu> In-Reply-To: <C83E8810-B68B-49B5-A7F4-8B72A4FFFFDA@mac.com> References: <47E06B23.7060400@uchicago.edu> <20080325023040.ab0daa19.stas@FreeBSD.org> <47E8527B.2050002@uchicago.edu> <47F39EF4.8040800@uchicago.edu> <C83E8810-B68B-49B5-A7F4-8B72A4FFFFDA@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar wrote: > > On Apr 2, 2008, at 7:57 AM, Nathan Whitehorn wrote: >> I've refreshed the BMAC tarball at >> http://home.physics.wisc.edu/~nwhitehorn/bm.tgz. >> >> It supports multicast and full-duplex operation now, the code is a >> little more style(9) compliant, and I don't think I have anything >> left to do unless someone finds some bugs. The patch to macio is also >> now included in the tarball. >> >> To support full-duplex operation, I had to do a hack to reset >> autonegotiation on the PHY (firmware puts the PHY in a weird state >> where its registers claim it did autonegotiation, but it always ends >> up in half-duplex mode). This is done in this way: >> >> sc->sc_mii = device_get_softc(sc->sc_miibus); >> LIST_FOREACH(child, &sc->sc_mii->mii_phys, mii_list) { >> mii_phy_auto(child); >> } >> >> Is a better course to modify lxtphy's attach routine to do this >> there? Or should this stay in bm? > > I lean towards putting it in the PHY driver itself. I expect > a PHY reset to do the right thing and in this case it doesn't > seem to do that. That does seem less hackish. What I don't know is whether Apple ever shipped machines with other PHYs and the BMAC chip, and whether those have the same problem. > From what you say it seems that the driver is commitable at > this time. I can't test it, but I can definitely commit. > Just let me know... I would like some tests with one of the other two revisions of the chip, of course, but any fixes should be minor. The real concern, on my part, for committing it is whether the macio IRQ patch breaks anything. If you have both an interrupts property and an AAPL,interrupts in OF, with multiple interrupts listed, it will cause all of the AAPL,interrupts IRQ resources to be renumbered. At the moment, we only support two devices (SCC and macio ATA) hanging off macio, so the set of things to be checked is limited. I know that the ATA code still works, but I suspect it might break the scc UART support, since it has several interrupts. So if you have any mac hardware at all with an SCC part you can test, it might be good to check that before committing. -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47F3D2BC.7060001>