Date: Wed, 02 Apr 2008 19:19:44 -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: <47F422A0.9080907@uchicago.edu> In-Reply-To: <47F3D2BC.7060001@uchicago.edu> 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> <47F3D2BC.7060001@uchicago.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Nathan Whitehorn wrote: > 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. [snip] >>> 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. After some poking around, it looks like pretty much all machines with BMAC NICs also have lxtphy. Some powerbooks appear to have nsphy instead. It also appears that the Sun HME chip has the same problem with nsphy (which is not surprising, since BMAC is the cheap Apple variant of HME). I decided to duplicate the solution to the problem from there (setting MIIF_FORCEANEG in lxtphy_attach() if lxtphy is attached to bm). Since there are at least some machines with bm and nsphy, we might also want to check for bm there in addition to hme. I've refreshed the tarball with the patch. >> 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. As it turns out, this description is not quite accurate -- it will break devices with children with more than one interrupt. This description fits SCC, where each child has three interrupts (one for general stuff, and two for the DBDMA channels). Thus SCC channel B is likely to stop working without some fixups to its interrupt allocation on macio. -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47F422A0.9080907>