if_wi attachment for mac-io
adrian at freebsd.org
Sun Sep 25 00:59:03 UTC 2011
On 24 September 2011 23:14, Justin Hibbits <jrh29 at 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
> 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. :)
More information about the freebsd-wireless