Hi Juuso On Sunday 07 December 2008, juuso.oikarinen@xxxxxxxxx wrote: > >From: ext Inaky Perez-Gonzalez [mailto:inaky@xxxxxxxxxxxxxxx] > >There is -- keep in mind, however, that for the case of the > >i2400m, the kernel cutline has to be at the NAP level. All the > >NSP operations will have to be implemented in user space using > >the NAP-based primitives offered by the driver/hw. > > AFAIK this is a logical point for the cutline. > > In my perspective, including NSP level stuff in the chipset would seem > to include lots of device independent code in the device, which really > shouldn't exist there. Sorry for the lag, but it took some time until I could put all the bits and pieces I had holted together in good shape. So here is the interface definition (very draft and rough) that I am pondering: [EXISTING] Command: reset() Resets the device Command: rfkill(state) stat: ON, OFF, QUERY Changes the software RFKILL switch, returns information about both software and hardware rfkill switches. Signal: state_change(old_state, new_state, [...]) [EXISTING] old_state: see enum wimax_st new_state: see enum wimax_st [...]: depending on the state transition, information that explains why the state transition happened (why the old state was left, why the new one was entered). CONNECTING -> CONNECTED: append connection_info structure? Sent on every state change. [NEW: NAP level] Command: nap_start_scan(channel list) channel: struct { channel-ID, center freq, bandwidth, fft width, preamble } Starts an scan in the channels listed in the channel list. If a scan is already executing, returns -EBUSY. Signals caused: - nap_scan_result(): zero or more signals as NAPs are found; when done scanning all the channels, sends an empty nap_scan_result() signal to indicate termination of the scan. - state_change(): from READY to SCANNING Requires: - Device to be in ready state, otherwise return error Pending: - Add a cookie argument that would be echoed back in the nap_scan_result() signal? This would help to identify scan results coming from one run or another. Command: nap_stop_scan() Cancels an ongoing scan; forces a nap_scap_result() signal to be sent. Signals caused: - state_change(): from SCANNING to READY Requires: - Device to be in SCANNING state, otherwise return error Signal: nap_scan_result(scan_status, nap list) scan_status: enum { inprogress, cancelled, done } nap: { channel-ID, preamble[where found], BSID / MASK, RSSI / CINR / LinkQ } Sent to report scan results; first argument indicate the current status of the scan process. Second is a list of found NAPs. The driver should try as much as possible to report NAPs as they are found, rather than waiting until completing the scan of the whole channel list. The scan process can be lengthy and it should be possible to see early results as soon as possible. RSSI/CINR/LinkQuality: provided raw. Pending: - Progress information? - Provide number of scanned channels (assuming all hw does) -- too hw specific? - Let the driver come out with a percentage based on device specific info Command: nap_query_nsp_list(NAP=BSID/MASK) -> NSP list NAP=BSID/MASK: NAP specification using a BSID/MASK as returned in the scan results NSP: { ID, Name } Query the NAP provide NSP information using SII. Requires: - device in state READY Pending: - Same as connect with NAP=BSID/MASK - Maybe merge with nap_query_nsp_realm()? Command: nap_query_nsp_realm(NAP=BSID/MASK, NSPid) -> NSP realm NAP=BSID/MASK: NAP specification using a BSID/MASK as returned in the scan results NSPid: ID of an NSP serverd by the NAP NSPrealm: realm for EAP Requires: - device in state READY Pending: - Same as connect with NAP=BSID/MASK - This could be merged with nap_query_nsp_list() into a nap_query_nsp(). If the NSPid is provided, then also the realm is queried. Depends on if the hw can do it. - FIXME: not really clear this is all that necessary; as said in the mailing list, this should be a signal that is sent while we are connecting and the value becomes available Command: nap_connect(NAP=BSID/MASK, [NSPid]) NAP=BSID/MASK: NAP specification using a BSID/MASK as returned in the scan results NSPid: id of the NSP we are attempting connection to (for obtaining the realm) Starts the connection process to the given NAP. This moves the device to the CONNECTING state. If the connection is successful, it will transition to the CONNECTED state. Signals caused: - state_change(): from READY to CONNECTING; later on, as the process goes on, from CONNECTING to CONNECTED (on successful connection), from CONNECTING to any other (on unsuccessful connection). Requires: - device must be in the READY state. Pending: - Maybe it makes more sense for the stack to kind of cache the scan results and assign an ID/handle to each nap; on connect time, we just indicate said ID. The nap_connect() implementation can then just lookup the results list kept in the kernel and find the relevant information there. Signal: nap_nsp_realm() -> { NSPid, REALM } During connect, if an NSPid was provided, then the REALM for EAP authentication with it is retuned by this signal. Command: nap_get_link_info() -> link_info link_info: { BSID, RSSI, CINR, FIXME } Return information about the currently connected NAP. Pending: - Returns the same information that is sent in the state_change signal (when transitioning from CONNECTING to CONNECTED)? Command: nap_disconnect() Disconnect from the NAP the device is connected to. Also cancels a pending connect. Signals caused: - state_change(): from CONNECTING to READY or from CONNECTED to READY. Requires: - device in CONNECTED or CONNECTING state Signal: dhcp_renew() The network requests that a DHCP renegotiation is done. I am supposedly on vacation now, so my responsiveness to email will tend to lag a bit :) -- Inaky
