if_wi attachment for mac-io

[Adrian Chadd]

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
> 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