ARM patches for orinoco
David Gibson
hermes at gibson.dropbear.id.au
Thu Feb 28 14:17:41 EST 2002
On Wed, Feb 27, 2002 at 05:23:08PM -0700, Ben Greear wrote:
>
>
> David Gibson wrote:
>
> >On Mon, Feb 25, 2002 at 10:41:33PM -0700, Ben Greear wrote:
> >
> >>The patch is attached. Some of it you probably will not
> >>want (the debug stuff). The reset code doesn't actually
> >>seem to help me, but it is no worse than the current state
> >>(both of which are totally broken). I think that a more
> >>thorough reset (can you power the device down in software?)
> >>might help rejuvinate the system...
> >>
> >
> >Most cards can be powered down in software, but the means of doing so
> >depends on the interface type (PCMCIA / PLX / Airport).
>
> So, any idea how to figure out how to do a better reset of a
> CF orinoco card?
For CF, I have no idea. Probably you'd need to frob the CF controller
somehow to tell it to reset the card.
> Do you agree that a reset should occur after some number of
> timeouts (-110)?
Well, I'd prefer to know why the firmware is falling over in the first
place.
> >>The alignment pads and __attribute__ packed changes
> >>actually seem to make it work on ARM w/out special
> >>compilation hacks. I think these should definately
> >>go in... In the future, you may want to design your
> >>structures such that they are aligned to 4 byte boundaries,
> >>internally too. In other words, don't do this:
> >>
> >>struct foo {
> >> char a;
> >> uint32 i;
> >> uint16 u;
> >> char a1;
> >>};
> >>
> >>But instead, perhaps do this:
> >>struct foo {
> >> char a;
> >> char a1;
> >> uint16 u;
> >> uint32 i;
> >>};
> >>
> >
> >I've added the ((packed)) attribute to struct p8022_hdr, but not to
> >struct hermes. As long as each of the modules are compiled with the
> >same options it shouldn't matter how struct hermes is aligned - it's a
> >purely internal structure. The only structures where ((packed))
> >should matter are where they are mapped onto external byte streams -
> >actual packets from the card. In which case I obviously can't reorder
> >the elements.
>
> I suggested the alignment, because it would not be too hard to compile
> user-space differently aligned than kernel space. Then, the packed
> structs coming through the IOCTL interface may have different sizes
> or alignments. It's true that a careful user can deal with this, but
> if possible, why make them care?
None of the structures I define are passed through ioctl().
--
David Gibson | For every complex problem there is a
david at gibson.dropbear.id.au | solution which is simple, neat and
| wrong. -- H.L. Mencken
http://www.ozlabs.org/people/dgibson
More information about the wireless
mailing list