Re: [Airo-linux-gen80211] BAP usage

[Daniel K. <da...@di...>]

>>>Dan Lanciani said:
 > Daniel Kalchev <da...@di...> wrote:
[...]
 > |Why not use the same BAP for reading/writing the same kind of data? For exa
     mple BAP0 for reading/writing frames and BAP1 for reading/writing LTV reco
     rds.
 > 
 > Usage of the BAPs is allocated not so much on the kind of data but on the
 > context of use.  Since there is no way to save and restore the state of a
 > BAP during an interrupt (or during an ordinary subroutine call for that
 > matter) interleaved access to the card has to use different BAPs.  One
 > typical strategy is to use one BAP from the mainline and a second from a
 > non-reentrant interrupt.  I don't know whether interleaved access really
 > buys you much these days, but if you didn't do things this way you would
 > have to disable interrupts to make any given BAP usage (from address setting
 > through the full data transfer stage) atomic.

I fully understand this point. Hopefully I finally found the last bug in the 
BSD/OS (actually, this is based on an early FreeBSD version) Aironet driver, 
in that it does not disable interrupts while servicing the sysctl call.

My assumption is, that all of the routines that do input/output (at least in 
the *BSD drivers), first seek to the appropriate position. Thus, writes and 
reads should be atomic. From what i have seen in the code, actual low-level 
routines do not disable interrupts. This is expected to be done in the calling 
routine, where it makes sense - you need to prevent access to the same 
resource during 'select data, get data, analyze data' not only in the 'select 
data, get data' part.

Anyway, for some reason the interrupt handling routine in BSD/OS does not seem 
to disable interrupts.

As far as I understand the Aironet hardware, it does have separate buffers for 
receive/transmit packets and for RID command and results. Thus, it's unlikely 
you can overwrite the received packets with packets to be sent. What might 
happen is you may have BAPs switched between packet read/write - thus my idea 
to use the same BAP for packet read/write.

In any case, one BAP is also sufficient :) if you disable interrupts often 
enough. Having more BAPs would have eliminated the costly BAP selection and 
seek calls at each I/O.

 > 
 > There is actually a third BAP available, but it has slightly different
 > semantics and is intended to allow an access point to fiddle with the
 > PSP bit masks and such.  It is also used for flashing and otherwise
 > talking to the boot block monitor.

Is this documented? RID access is usually synchronous in nature, so having one 
BAP for read, another for write and third to read/write RIDs would be very 
nice - and perhaps result in better performance.

Daniel