Date: Sun, 25 Sep 2011 08:59:02 +0800 From: Adrian Chadd <adrian@freebsd.org> To: Justin Hibbits <jrh29@alumni.cwru.edu> Cc: freebsd-wireless@freebsd.org, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: if_wi attachment for mac-io Message-ID: <CAJ-VmonsSafn==nVpUyDAoOjp9SpVi8eVLFTYwtMi-4g8-Y55w@mail.gmail.com> In-Reply-To: <9CA9DCD5-2B81-443D-BAC9-1B5D9E703B15@alumni.cwru.edu> References: <9CA9DCD5-2B81-443D-BAC9-1B5D9E703B15@alumni.cwru.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24 September 2011 23:14, Justin Hibbits <jrh29@alumni.cwru.edu> wrote: > pci2:0:14:0: reprobing on driver added > wi0: <Apple Airport> mem 0x30000-0x300ff,0x1a000-0x1a0ff,0-0xff irq 57 on > macio0 > wi0: record read mismatch, rid=fd0b, got=bfd > wi0: using Unknown Lucent chip > wi0: record read mismatch, rid=fd20, got=20fd > wi0: Hermes Firmware: Station (0.0.0) > wi0: Sorry, this card is not supported (type 1, firmware ver 0) > device_attach: wi0 attach returned 45 > > > Is there a way to add a shim underneath the driver, or something else so as > not to be too intrusive to the if_wi driver? Hm, it looks like there's explicit casts to/from little endian in wi_read_rid() and wi_write_rid(). The bus read/write value swapping are already handled for you by the bus glue. What's left are the contents of buffers. I guess read/write_rid are using struct wi_lt_hdr implicitly without actually using the struct. * One form of communication with the Hermes is with what Lucent calls * LTV records, where LTV stands for Length, Type and Value. The length * and type are 16 bits and are in native byte order. The value is in * multiples of 16 bits and is in little endian byte order. If you look at wi_read_bap() and wi_write_bap(), they treat the buffer as a set of 16 bit words being read from WI_DATA0. I'd expect the CSR_READ_2() define to correctly swap the data from device to host order. I wonder about the correct endian-ness of the buffer read - ie, the bus space macro is turning it into a 16 bit host-endian data read. Ie, your PPC is in Big-endian mode, so the le16toh() macro isn't a NULL. I don't know why Bill used le16toh() here, if the length/value fields from the NIC are supposed to be host-order. I suggest just removing the le16toh() and htole16() calls in wi_read_rid() and wi_write_rid() as again these may be host-endian data. Code which calls wi_read_rid() and wi_read_bap() seem to do some explicit endian conversions of data fields but I bet there may be missing ones lurking here and there. So fixing up wi_read_rid() and wi_write_rid() may make probe/attach function, but you may find weird crap occuring. :-) Give that a shot, then look at the openbsd/netbsd wi driver to see if they've investigated and fixed endian issues. :) Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonsSafn==nVpUyDAoOjp9SpVi8eVLFTYwtMi-4g8-Y55w>