Now that hostap is being included in the Linux 2.6.x kernel - USB support

[Chris Rankin]

Hi,

I have been studying the linux-wlan-ng USB code with
regards to integrating it with the new hostap code in
Linux 2.6.11-pre. It looks like the USB code works as
follows:

BULK-OUT endpoint for both command requests and TX
data
BULK-IN endpoint for both command responses and RX
data

Each command has a "struct hfa384x_usbctlx" object (a
CTLX), which contains:
- one URB
- one completion object to signal when the CTLX is
dead
- two timer_list objects; one to timeout the request's
  ACK from the hardware, and the other to timeout the
  hardware's response.

Commands are stored on the "struct hfa384x_usbctlxq"
(CTLXQ), which is one field on the adapter's "struct
hfa384x". The CTLXQ consists of three linked lists
(called "pending", "active" and "finished"), and a
controlling spinlock.

The theory is that the hardware can only process one
command at a time. However, Linux may need to queue up
several commands for asynchronous dispatch. Hence
CTLXs start on the "pending" list, are moved
one-by-one
to the "active" list (which should only ever contain
one CTLX at a time), and are finally moved to the
"finished" list so that any other non-USB-related
completion work can be done. To be precise, the
"finished" queue contains either CTLX objects that are
awaiting an asynchronous completion handler to be
scheduled (on a bottom-half), or CTLX objects that
have fallen so completely off the rails that the
driver doesn't know what else to do with them. This
last case should be VERY unlikely, but does at least
allow
the memory still to be deallocated when the driver is
unloaded.

The "struct hfa384x" object contains (specific to
USB):
- a pointer to the "struct usb_device" object
- an URB for the RX data
- an URB for the TX data
- the command queue (CTLXQ)
- a "work_flags" bit field.
- a "struct work_struct" object, so that we can
  schedule "maintenance" work for the USB device which
  cannot be performed during interrupt context. For
  example, resetting the IN or OUT pipe in case the
URB 
  handling gets into trouble. The nature of this work
  is determined by setting bits on the work_flags
  field.


URB submission.
---------------
The TX and CTLX request URBs have separate callback
functions on the BULK-OUT pipe, whereas the CTLX
response and RX URBs share a common callback function
on the BULK-IN pipe. The BULK-IN callback determines
the correct action to take by examining the "type"
field on the hfa384x_usbin_t object (the contents on
the urb->transfer_buffer).

The CTLX object is searched for on the "active" list.
(There *should* only be one CTLX object on the
"active" list, of course. But paranoia is your
friend... The CTLX object knows what type of request
it was for, and this should match the type of the
reply that we've just received.)


So it looks as if in order to integrate the USB code
into hostap, we would need synchronous and
asynchronous command handling, and to allow TX and RX
data to be transported via URBs. (linux-wlan-ng also
has synchronous and asynchronous reading and writing
of RIDs and MEM; I'm not sure what all that is about.)

Basically, it looks as if hostap_hw.c is going to need
to be split into two pieces: common piece for the
HFA348x-specific functions, and another to encapsulate
how the driver talks to the hardware.

Does anyone who is familiar with the hostap code have
any insight into this, please?

Thanks,
Chris



	
	
		
___________________________________________________________ 
ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com