[prev in list] [next in list] [prev in thread] [next in thread]
List: freebsd-ppc
Subject: Re: if_wi attachment for mac-io
From: Adrian Chadd <adrian () freebsd ! org>
Date: 2011-09-25 0:59:02
Message-ID: CAJ-VmonsSafn==nVpUyDAoOjp9SpVi8eVLFTYwtMi-4g8-Y55w () mail ! gmail ! com
[Download RAW message or body]
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
_______________________________________________
freebsd-ppc@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ppc
To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic