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