Commit Graph

231 Commits

Author SHA1 Message Date
André Goddard Rosa af901ca181 tree-wide: fix assorted typos all over the place
That is "success", "unknown", "through", "performance", "[re|un]mapping"
, "access", "default", "reasonable", "[con]currently", "temperature"
, "channel", "[un]used", "application", "example","hierarchy", "therefore"
, "[over|under]flow", "contiguous", "threshold", "enough" and others.

Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-12-04 15:39:55 +01:00
David S. Miller 62d83681e5 Merge branch 'linux-2.6.33.y' of git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax 2009-11-06 05:01:54 -08:00
Inaky Perez-Gonzalez e7fec0bbf1 wimax/i2400m: fix inverted value in i2400ms_bus_setup()
Fix inverted setting of 'retries'; when we are in the probe() path, we
should retry to enable the function only once; otherwise until it
times out.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03 12:49:43 -08:00
Inaky Perez-Gonzalez 20d57f8e25 wimax/i2400m: fix SDIO debugfs dentry name
The SDIO specific debugfs dentry was being misnamed "i2400m-usb"
instead of "i2400m-sdio".

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03 12:49:42 -08:00
Inaky Perez-Gonzalez 5a039e7852 wimax/i2400m: fix bad assignment of return value in i2400mu_tx_bulk_out
The function was always setting the return value to the amount of
bytes transferred, overwriting the error code in error paths.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03 12:49:41 -08:00
Inaky Perez-Gonzalez faf57162e4 wimax/i2400m: handle USB stalls
When the device stalls, clear it and retry; if it keeps failing too
often, reset the device.

This specially happens when running on virtual machines; the real
hardware doesn't seem to trip on stalls too much, except for a few
reports in the mailing list (still to be confirmed this is the cause,
although it seems likely.

NOTE: it is not clear if the URB has to be resubmitted fully or start
only at the offset of the first transaction sent. Can't find
documentation to clarify one end or the other.

Tests that just resubmit the whole URB seemed to work in my
environment.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03 12:49:40 -08:00
Inaky Perez-Gonzalez fae92216da wimax/i2400m: don't retry SDIO enable in probe() paths
The iwmc3200 has a quirk where retrying SDIO enable during the probe()
path causes bad interactions with the TOP function controller that
causes a reset storm. The workaround is simply not to retry an SDIO
enable in said path (and still do in the reset / reinitialization
paths).

The driver does so by checking i2400ms->debugfs_dentry to see if it
has been initialized; if not, it is in the probe() path. Document said
fact in i2400ms->debugfs_entry.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03 12:49:39 -08:00
Inaky Perez-Gonzalez 02eb41ef2a wimax/i2400m: correctly identify all iwmc3200-based SKUs
Different paths of the i2400m SDIO driver need to take care of a few
SKU-specific quirks. For the ones that are common to to all the
iwmc3200 based devices, introduce i2400ms->iwmc3200 [set in
i2400ms_probe()], so it doesn't have to check against the list of
iwmc3200 SKU IDs on each quirk site.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03 12:49:38 -08:00
Inaky Perez-Gonzalez 296bd4bdd0 wimax/i2400m: Fix USB timeout specifications (to ms from HZ)
The USB code was incorrectly specifiying timeouts to be in jiffies vs
msecs. On top of that, lower it to 200ms, as 1s is really too long
(doesn't allow the watchdog to trip a reset if the device timesout too
often).

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03 12:49:37 -08:00
Inaky Perez-Gonzalez 5ab5a7215a wimax/i2400m: fix device getting stuck in IDLE mode
The i2400m, when conected, will negotiate with the WiMAX basestation
to put the link in IDLE mode when it is not being used. Upon RX/TX
traffic, the link has to be restablished and that might require some
crypto handshakes and maybe a DHCP renew.

This process might take up to 20 (!) seconds and in some cases we were
seeing network watchdog warnings that weren't needed.

So the network watchdog timeout is updated to be slightly above that
20s threshold. As well, the driver itself will double check if the
device is stuck in IDLE mode -- if that happens, the device will be
reset (in this case the queue is also woken up to remove bogus--once
the device is reset--warnings).

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03 12:49:36 -08:00
Inaky Perez-Gonzalez c931ceeb78 wimax/i2400m: introduce i2400m_reset(), stopping TX and carrier
Currently the i2400m driver was resetting by just calling
i2400m->bus_reset(). However, this was missing stopping the TX queue
and downing the carrier. This was causing, for the corner case of the
driver reseting a device that refuses to go out of idle mode, that a
few packets would be queued and more than one reset would go through,
making the recovery a wee bit messy.

To avoid introducing the same cleanup in all the bus-specific driver,
introduced a i2400m_reset() function that takes care of house cleaning
and then calling the bus-level reset implementation.

The bulk of the changes in all files are just to rename the call from
i2400m->bus_reset() to i2400m_reset().

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03 12:49:36 -08:00
Inaky Perez-Gonzalez 55a662d646 wimax/i2400m: implement passive mode as a module option
Some versions of the user space Intel WiMAX daemon need to have full
control over the device initialization sequence. By setting the module
option i2400.passive_mode to 1, the driver defers all device
configuration and initialization to user space.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-11-03 12:49:34 -08:00
Tomas Winkler ce5eb7a292 i2400m-sdio: select IWMC3200TOP in Kconfig
i2400m-sdio requires iwmc3200top for its operation

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Acked-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-10-19 23:22:51 -07:00
Inaky Perez-Gonzalez a8ee303cae wimax/i2400m: SDIO: fix oops on reset when TXing on uninitialized data
Currently the SDIO part of the TX resources were initialized/released
with bus_dev_{start,stop}.

The generic code's TX subsystem is destroyed afterwards, so there is a
window from the bus-TX destruction to the generic-TX destruction where
the generic-TX code might call into bus-TX to do transactions.

The SDIO code cannot really cope with this (whereas in USB, how it is
laid out, it correctly ignores it). In any case, it made no sense for
the SDIO TX code to be in i2400m->bus_dev_start/stop(), so moved to
i2400m->bus_setup/release(), which also takes care of the oops.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:25 +09:00
Inaky Perez-Gonzalez 097acbeff9 wimax/i2400m: make i2400m->bus_dev_{stop,start}() optional
In coming commits, the i2400m SDIO driver will not use
i2400m->bus_dev_stop().

Thus changed to check before calling, as an empty stub has more
overhead than a call to check if the function pointer is non-NULL.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:23 +09:00
Inaky Perez-Gonzalez 4a78fd9a73 wimax/i2400m: fix oops caused by race condition when exiting USB kthreads
Current i2400m USB code had to threads (one for processing RX, one for
TX). When calling i2400m_{tx,rx}_release(), it would crash if the
thread had exited already due to an error.

So changed the code to have the thread fill in/out
i2400mu->{tx,rx}_kthread under a spinlock; then the _release()
function will call kthread_stop() only if {rx,tx}_kthread is still
set.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:22 +09:00
Inaky Perez-Gonzalez 0c96859d7a wimax/i2400m: Let device's status reports change the device state
Currently __i2400m_dev_start was forcing, after uploading firmware and
doing a few checks to WIMAX_ST_UNINITIALIZED.

This can be overriding state changes that the device might have caused
by sending reports; thus it makes more sense to remove it and let the
device update the status on its own by sending reports.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:21 +09:00
Inaky Perez-Gonzalez 46c501473d wimax/i2400m: fix oops in TX when tearing down the device
All the entry points into the TX module should check if the device has
been torn down. Otherwise, when the device resets or shuts down, there
are windows when a call to i2400m_tx*() will oops the system.

For that, make i2400m_tx_release() set i2400m->tx_buf to NULL under
the tx_lock. Then, any entry point [i2400m_tx(), _tx_msg_sent(),
_tx_msg_get()] will check for i2400m->tx_buf to be NULL and exit
gracefully.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:20 +09:00
Inaky Perez-Gonzalez a0beba21c3 wimax/i2400m: queue device's report until the driver is ready for them
The i2400m might start sending reports to the driver before it is done
setting up all the infrastructure needed for handling them.

Currently we were just dropping them when the driver wasn't ready and
that is bad in certain situations, as the sync between the driver's
idea of the device's state and the device's state dissapears.

This changes that by implementing a queue for handling
reports. Incoming reports are appended to it and a workstruct is woken
to process the list of queued reports.

When the device is not yet ready to handle them, the workstruct is not
woken, but at soon as the device becomes ready again, the queue is
processed.

As a consequence of this, i2400m_queue_work() is no longer used, and
thus removed.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:19 +09:00
Inaky Perez-Gonzalez af77dfa781 wimax/i2400m: move i2400m_init() out of i2400m.h
Upcoming changes will have to add things to this function that expose
more internals, which would mean more forward declarators.

Frankly, it doesn't need to be an inline, so moved to driver.c, where
the declarations will be taken from the header file.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:19 +09:00
Inaky Perez-Gonzalez b9ee95010b wimax/i2400m: fix deadlock: don't do BUS reset under i2400m->init_mutex
Since the addition of the pre/post reset handlers, it became clear
that we cannot do a I2400M-RT-BUS type reset while holding the
init_mutex, as in the case of USB, it will deadlock when trying to
call i2400m_pre_reset().

Thus, the following changes:

 - clarify the fact that calling bus_reset() w/ I2400M_RT_BUS while
   holding init_mutex is a no-no.

 - i2400m_dev_reset_handle() will do a BUS reset to recover a gone
   device after unlocking init_mutex.

 - in the USB reset implementation, when cold and warm reset fails,
   fallback to QUEUING a usb reset, not executing a USB reset, so it
   happens from another context and does not deadlock.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:18 +09:00
Inaky Perez-Gonzalez 5eeae35b9a wimax/i2400m: when stopping the device, cancel any pending message
The stop procedure for the device must make sure that any task that is
waiting on a message is properly cancelled.

This was being taken care of only by the __i2400m_dev_reset_handle()
path and the rest was working by chance because the waits have a
timeout.

Fixed by adding a proper cancellation in __i2400m_dev_stop().

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:17 +09:00
Cindy H Kao 28cff50d99 wimax/i2400m: change the bcf_len to exclude the extended header size
The actual fw->size may not equal to the bcf size indicated in
the bcf header if the extended bcf debug header is added in the tail.

To reflect the actual fw size that will be downloaded to the device,
it is now retrived from from the size field indicated in the bcf header.

All of the headers (if there are extended headers) should indicate same
value for the size field since only one set of firmware chunks is downloaded

Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
2009-10-19 15:56:16 +09:00
Cindy H Kao 6f4fc90a36 wimax/i2400m: use JUMP cmd for last FW chunk indication
Both secure and non-secure boot must set the JUMP command in the
bootmode header as the last FW chunk, so we change to use the JUMP
command to decide if the FW chunk download is completed.

Since we tend to use one single FW to support both secure and non-secure
boot for most of the time, I2400M_BRH_SIGNED_JUMP is actually found
even for non-secure boot. But in case the FW does come with
I2400M_BRH_JUMP, we check for both of them in i2400m_dnload_bcf().

Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:15 +09:00
Inaky Perez-Gonzalez 9835fd8499 wimax/i2400m: fix race condition with tcpdump et al
tcpdump and friends were not being able to decode packets sent via
WiMAX; they had a zero ethernet type, even when the stack was properly
sending them to the device with the right type.

It happens that the driver was overwriting the (fake) ethernet header
for creating the hardware header and that was bitting the cloning used
by tcpdump (et al) to look into the packets.

Use pkskb_expand_head() [method copied from the e1000 driver] to fix.

Thanks to Herbert Xu and Andi Kleen for helping to diagnose and
pointing to the right fix.

Cc: Herbert Xu <gondor.apana.org.au>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:12 +09:00
Inaky Perez-Gonzalez e1633fd636 wimax/i2400m: reduce verbosity of debug messages in boot mode
Missed a debug message that was being constantly printed as a
dev_err(); became annoying. Demote it to a debug message.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:11 +09:00
Inaky Perez-Gonzalez 3725d8c974 wimax/i2400m: Implement pre/post reset support in the USB driver
The USB stack can callback a driver is about to be reset by an
external entity and right after it, so the driver can save state and
then restore it.

This commit implements said support; it is implemented actually in the
core, bus-generic driver [i2400m_{pre,post}_reset()] and used by the
bus-specific drivers. This way the SDIO driver can also use it once
said support is brought to the SDIO stack.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:10 +09:00
Inaky Perez-Gonzalez 2869da8587 wimax/i2400m: do bootmode buffer management in i2400m_setup/release()
After the introduction of i2400m->bus_setup/release, there is no more
race condition where the bootmode buffers are needed before
i2400m_setup() is called.

Before, the SDIO driver would setup RX before calling i2400m_setup()
and thus need those buffers; now RX setup is done in
i2400m->bus_setup(), which is called by i2400m_setup().

Thus, all the bootmode buffer management can now be done completely
inside i2400m_setup()/i2400m_release(), removing complexity from the
bus-specific drivers.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:09 +09:00
Inaky Perez-Gonzalez 0856ccf29d wimax/i2400m: introduce i2400m->bus_setup/release
The SDIO subdriver of the i2400m requires certain steps to be done
before we do any acces to the device, even for doing firmware upload.

This lead to a few ugly hacks, which basically involve doing those
steps in probe() before calling i2400m_setup() and undoing them in
disconnect() after claling i2400m_release(); but then, much of those
steps have to be repeated when resetting the device, suspending, etc
(in upcoming pre/post reset support).

Thus, a new pair of optional, bus-specific calls
i2400m->bus_{setup/release} are introduced. These are used to setup
basic infrastructure needed to load firmware onto the device.

This commit also updates the SDIO subdriver to use said calls.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:08 +09:00
Inaky Perez-Gonzalez c2315b4ea9 wimax/i2400m: clarify and fix i2400m->{ready,updown}
The i2400m driver uses two different bits to distinguish how much the
driver is up. i2400m->ready is used to denote that the infrastructure
to communicate with the device is up and running. i2400m->updown is
used to indicate if 'ready' and the device is up and running, ready to
take control and data traffic.

However, all this was pretty dirty and not clear, with many open spots
where race conditions were present.

This commit cleans up the situation by:

 - documenting the usage of both bits

 - setting them only in specific, well controlled places
   (i2400m_dev_start, i2400m_dev_stop)

 - ensuring the i2400m workqueue can't get in the middle of the
   setting by flushing it when i2400m->ready is set to zero. This
   allows the report hook not having to check again for the bit to be
   set [rx.c:i2400m_report_hook_work()].

 - using i2400m->updown to determine if the device is up and running
   instead of the wimax state in i2400m_dev_reset_handle().

 - not loosing missed messages sent by the hardware before
   i2400m->ready is set. In rx.c, whatever the device sends can be
   sent to user space over the message pipes as soon as the wimax
   device is registered, so don't wait for i2400m->ready to be set.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:07 +09:00
Inaky Perez-Gonzalez 8f90f3ee83 wimax/i2400m: cleanup initialization/destruction flow
Currently the i2400m driver was starting in a weird way: registering a
network device, setting the device up and then registering a WiMAX
device.

This is an historic artifact, and was causing issues, a some early
reports the device sends were getting lost by issue of the wimax_dev
not being registered.

Fix said situation by doing the wimax device registration in
i2400m_setup() after network device registration and before starting
thed device.

As well, removed spurious setting of the state to UNINITIALIZED;
i2400m.dev_start() does that already.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:06 +09:00
Inaky Perez-Gonzalez ac53aed934 wimax/i2400m: on device stop, clean up pending wake & TX work
When the i2400m device needs to wake up an idle WiMAX connection, it
schedules a workqueue job to do it.

Currently, only when the network stack called the _stop() method this
work struct was being cancelled. This has to be done every time the
device is stopped.

So add a call in i2400m_dev_stop() to take care of such cleanup, which
is now wrapped in i2400m_net_wake_stop().

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:05 +09:00
Inaky Perez-Gonzalez cb5b756f74 wimax/i2400m: don't overwrite error codes when failing to load firmware
Make sure that i2400m_dev_bootstrap() doesn't overwrite the last known
error code with -ENOENT; when a firmware fails to load, we want to
know the cause and not a generic error code.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:04 +09:00
Inaky Perez-Gonzalez 1a5a73c0c5 wimax/i2400m: implement .reset_resume in USB subdriver
Current driver didn't implement the .reset_resume method. The i2400m
normally always reset on a comeback from system standby/hibernation.

This requires previously applied commits to cache the firmware image
file.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:03 +09:00
Inaky Perez-Gonzalez 7b43ca708a wimax/i2400m: cache firmware on system suspend
In preparation for a reset_resume implementation, have the firmware
image be cached in memory when the system goes to suspend and released
when out.

This is needed in case the device resets during suspend; the driver
can't load firmware until resume is completed or bad deadlocks
happen.

The modus operandi for this was copied from the Orinoco USB driver.

The caching is done with a kobject to avoid race conditions when
releasing it. The fw loader path is altered only to first check for a
cached image before trying to load from disk. A Power Management event
notifier is register to call i2400m_fw_cache() or i2400m_fw_uncache()
which take care of the actual cache management.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:02 +09:00
Inaky Perez-Gonzalez 3ef6129e57 wimax/i2400m: add reason argument to i2400m_dev_reset_handle()
In preparation for reset_resume support, in which the same code path
is going to be used, add a diagnostic message to dev_reset_handle()
that can be used to distinguish how the device got there.

This uses the new payload argument added to i2400m_schedule_work() by
the previous commit.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:01 +09:00
Inaky Perez-Gonzalez b0fbcb2a0b wimax/i2400m: clean up & add a payload argument to i2400m_schedule_work()
Forthcoming commits use having a payload argument added to
i2400m_schedule_work(), which then becomes nearly identical to
i2400m_queue_work().

This patch thus cleans up both's implementation, making it share
common helpers and adding the payload argument to
i2400m_schedule_work().

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:00 +09:00
Dirk Brandewie 7329012e67 wimax/i6x50: add Intel WiFi/WiMAX Link 6050 Series support
Add support for the WiMAX device in the Intel WiFi/WiMAX Link 6050
Series; this involves:

 - adding the device ID to bind to and an endpoint mapping for the
   driver to use.

 - at probe() time, some things are set depending on the device id:

   + the list of firmware names to try

   + mapping of endpoints

Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:59 +09:00
Cindy H Kao f8fc329557 wimax/iwmc3200: add new sdio device ID to support iwmc3200 2.5GHz sku
Different sdio device IDs are designated to support different intel
wimax silicon sku. The new macro SDIO_DEVICE_ID_IWMC3200_WIMAX_2G5(0x1407)
is added to support iwmc3200 2.5GHz sku.  The existing
SDIO_DEVICE_ID_IWMC3200_WIMAX(0x1402) is for iwmc3200 general sku.

Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:59 +09:00
Inaky Perez-Gonzalez 10607c86e1 wimax/i2400m: on firmware upload, select BCF header that matches device's request
Devices based on the i2400m emit a "barker" (32 bit unsigned) when
they boot. This barker is used to select, in the firmware file image,
which header should be used to process the rest of the file.

This commit implements said support, completing the series started by
previous commits.

We modify the i2400m_fw_dnload() firmware loading path by adding a
call to i2400m_bcf_hdr_find() [new function], in which the right BCF
header [as listed in i2400m->fw_hdrs by i2400m_fw_check()] is
located. Then this header is fed to i2400m_dnload_init() and
i2400m_dnload_finalize().

The changes to i2400m_dnload_finalize() are smaller than they look;
they add the bcf_hdr argument and use that instead of bcf. Likewise in
i2400m_dnload_init().

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:58 +09:00
Inaky Perez-Gonzalez bfc44187bb wimax/i2400m: support extended firmware format
The SBCF firmware format has been extended to support extra headers
after the main payload. These extra headers are used to sign the
firmware code with more than one certificate. This eases up
distributing single code images that work in more than one SKU of the
device.

The changes to support this feature will be spread in a series of
commits. This one just adds the support to parse the extra headers and
store them in i2400m->fw_hdrs. Coming changes to the loader code will
use that to determine which header to upload to the device.

The i2400m_fw_check() function now iterates over all the headers and
for each, calls i2400m_fw_hdr_check(), which does some basic checks on
each header. It then stores the headers for the bootloader code to use.

The i2400m_dev_bootstrap() function has been modified to cleanup
i2400m->fw_hdrs when done.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:57 +09:00
Inaky Perez-Gonzalez fabce1a485 wimax/i2400m: verify firmware format version is known
Make sure the bootloading code checks that the format of the file is
understood (major version match). This also fixes a dumb typo in
extracting the major version field.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:56 +09:00
Inaky Perez-Gonzalez 923d708fed wimax/i2400m: fix reboot echo/ack barker deadlock
The i2400m based devices can get in a sort of a deadlock some times;
when they boot, they send a reboot "barker" (a magic number) and then
the driver has to echo that same barker to ack reception
(echo/ack). Then the device does a final ack by sending an ACK barker.

The first time this happens, we don't know ahead of time with barker
the device is going to send, as different device models and SKUs will
send different barker depending on the EEPROM programming.

If the device has sent the barker before the driver has been able to
read it, the driver looses, as it doesn't know which barker it has to
echo/ack back. With older devices, we tried a couple of combinations
and that always worked; but now, with adding support for more, in
which we have an unlimited number of new barkers, that is not an
option.

So we rework said case so that when the device gets stuck, we just
cycle through all the known types until one forces the device to send
an ack. Otherwise, the driver gives up and aborts.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:55 +09:00
Inaky Perez-Gonzalez ebc5f62b76 wimax/i2400m: retry loading firmware files in sequence
The i2400m firmware loader is given a list of firmware files to try to
load by the probe() function (which can be different based on the
device's model / generation).

Current code didn't attempt to load, check and try to boot with each
file, but just to try to load if off disk. This is limiting in some
cases, where we might want to try to load a firmware and if it fails
to load onto the device, just fall back to another one.

This changes the behaviour so all files are tried for being loaded
from disk, checked and uploaded to the device until one suceeds in
bringing the device up.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:54 +09:00
Inaky Perez-Gonzalez aba3792ac2 wimax/i2400m: rework bootrom initialization to be more flexible
This modifies the bootrom initialization code of the i2400m driver so
it can more easily support upcoming hardware.

Currently, the code detects two types of barkers (magic numbers) sent
by the device to indicate the types of firmware it would take (signed
vs non-signed).

This schema is extended so that multiple reboot barkers are
recognized; upcoming hw will expose more types barkers which will have
to match a header in the firmware image before we can load it.

For that, a barker database is introduced; the first time the device
sends a barker, it is matched in the database. That gives the driver
the information needed to decide how to upload the firmware and which
types of firmware to use. The database can be populated from module
parameters.

The execution flow is not altered; a new function
(i2400m_is_boot_barker) is introduced to determine in the RX path if
the device has sent a boot barker. This function is becoming heavier,
so it is put away from the hot reception path [this is why there is
some reorganization in sdio-rx.c:i2400ms_rx and
usb-notifc.c:i2400mu_notification_grok()].

The documentation on the process has also been updated.

All these modifications are heavily based on previous work by Dirk
Brandewie <dirk.brandewie@intel.com>.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:53 +09:00
Inaky Perez-Gonzalez 32742e6158 wimax/i2400m: decide properly if using signed vs non-signed firmware loading
The i2400m based devices can boot two main types of firmware images:
signed and non-signed. Signed images have signature data included that
must match that of a certificate stored in the device.

Currently the code is making the decission on what type of firmware
load (signed vs non-signed) is going to be loaded based on a hardcoded
decission in __i2400m_ack_verify(), based on the barker the device
sent upon boot.

This is not flexible enough as future hardware will emit more barkers;
thus the bit has to be set in a place where there is better knowledge
of what is going on. This will be done in follow-up commits -- however
this patch paves the way for it.

So the querying of the mode is packed into i2400m_boot_is_signed();
the main changes are just using i2400m_boot_is_signed() to determine
the method to follow and setting i2400m->sboot in
i2400m_is_boot_barker(). The modifications in i2400m_dnload_init() and
i2400m_dnload_finalize() are just reorganizing the order of the if
blocks and thus look larger than they really are.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:52 +09:00
Inaky Perez-Gonzalez 59bdc4be0b wimax/i2400m: workaround not-so-working %zd printf format
The kernel's %zd modifier does not really work. Use %ld (has to cast
ssize_t to long).

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:51 +09:00
Inaky Perez-Gonzalez 4c2b1a1164 wimax: allow specifying debug levels as command line option
Add "debug" module options to all the wimax modules (including
drivers) so that the debug levels can be set upon kernel boot or
module load time.

This is needed as currently there was a limitation where the debug
levels could only be set when a device was succesfully
enumerated. This made it difficult to debug issues that made a device
not probe properly.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:50 +09:00
Inaky Perez-Gonzalez 4dc1bf074e wimax/i2400m: add missing debug submodule definition
The i2400m driver was missing the definition for the sysfs debug
level, which is declared in debug-levels.h.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:49 +09:00
Inaky Perez-Gonzalez c77ca950ab wimax/i2400m: during probe, call sdio_disable at most once
In the Intel Wireless Multicomm 3200, the initialization is
orchestrated by a component called Top. This component also monitors
how many times a function is reset (via sdio_disable) to detect
possible issues and will reset the whole multifunction device if any
function triggers a maximum reset level.

During WiMAX's probe, the driver needs to wait for Top to come up
before it can enable the WiMAX function. If it cannot, it will return
-ENODEV and the Top driver will rescan the SDIO bus once done
loading.

Currently, the WiMAX SDIO probe routine was trying a few times before
returning -ENODEV, and this was triggering Top's too-many-resets
detector. This is, in any case, unnecessary because the Top driver will
force the bus rescan when the functions can be probed successfully.

Added then a maxtries argument to i2400ms_enable_func() and set it to
1 when calling from probe. We want to reuse this function instead of
flat calling out sdio_enable_func() to take advantage of hardware
quirk workarounds.

Reported-by: Cindy H Kao <cindy.h.kao@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:48 +09:00
Cindy H Kao 8d8fe198c6 wimax/i2400m: don't write to memory allocated by request_firmware()
In kernel 2.6.31, the firmware requested to ram could be marked
with read only attribute, and we can't write any thing directly
to the memory when setting up the last JUMP brh cmd.

Changed so that the scratch buffer is used.

Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:47 +09:00
Inaky Perez-Gonzalez 77e1251a7c wimax/i2400m: be smarter about copying command buffer to bm_cmd_buf
Because some underlying bus APIs (like USB) don't like data buffers in
the stack or vmalloced areas, the i2400m driver provides a scratch
buffer (i2400m->bm_cmd_buf) for said low-level drivers to copy command
data to before passing it to said API. This is only used during boot
mode.

However, at some the code was copying the buffer even when the command
was already specified in said buffer. This is ok, but it needs to be
more careful. As thus, change so that:

(a) the copy happens only if command buffer is not the scratch buffer

(b) use memmove() in case there is overlapping

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:46 +09:00
Cindy H Kao 339ccc362c wimax/i2400m/sdio: clear the INTR status bit after reading size
In order to avoid issues during high-load traffic, the interrupt
status register has to be cleared ONLY after the RX size is read.

Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:45 +09:00
Dirk Brandewie 2093586de2 wimax/i2400m: USB driver uses a configurable endpoint map
Newer generations of the i2400m USB WiMAX device use a different
endpoint map; in order to make it easy to support it, we make the
endpoint-to-function mapeable instead of static.

Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:44 +09:00
Cindy H Kao 8bec9a5efd wimax/iwmc3200: increase wait time before enable retry
When trying to enable the iwmc3200 WiMAX SDIO function, we loop
waiting for the top controller to be up and running (at which point we
can succesfully enable the function). Between each try we wait for
I2400MS_INIT_SLEEP_INTERVAL ms.

Integration tests have found the current value of 10ms to be too
short; it was upped to 100ms to give more time to the top controller
to be ready.

Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:43 +09:00
Cindy H Kao 5c29e21d47 wimax/iwmc3200: don't disable the SDIO function if enable fails
In the iwmc3200, disabling the WiMAX SDIO function when enable fails
would possibly result in a device reset triggered by the iwmc3200's
top controller since it monitors the bus reset activities from each
SDIO function. In any case, the disable makes no sense; if the enable
fails, it should not be disabled.

Thus we remove the unecessary sdio_disable_func() in
i2400ms_enable_function().

Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:42 +09:00
Cindy H Kao f2696fbdb6 wimax/iwmc3200: overwrite SDIO IOR timeout value to avoid platform hang
The default SDIO IOE wait timeout returned from iwmc3200-wimax's CCCR
is not efficient. This inefficiency will actually cause problems on
Moorestown platforms (system hang).

This is a sillicon bug that requires a software patch to by
overwritting func->enable_timeout. The new value I2400MS_IOR_TIMEOUT
is recommended and verified from the system integration results.

Future sillicon releases will have this default value corrected in the
future.

Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:41 +09:00
Dirk Brandewie c30836580b wimax/i2400m: Make boot retries a BUS-specific parameter
In i2400m-based devices, the driver's bootloader will retry to load
the firmware when things go wrong. The driver currently has a constant
(I2400M_BOOT_RETRIES) which governs the max number of tries.

However, different SKUs of the same hardware may admit or require
different numbers of retries due to it's particulars, so it is made a
BUS specific parameter and different values are assigned for 5x50
devices versus the 3200 ones.

Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:40 +09:00
Dirk Brandewie a134fd6b10 wimax/i2400m: Ensure boot mode cmd and ack buffers are alloc'd before first message
The change to the SDIO boot mode RX chain could try to use the cmd and
ack buffers befor they were allocated.  USB does not have the problem
but both were changed for consistency's sake.

Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:39 +09:00
Dirk Brandewie 81b182a754 wimax/i2400m: Update comments to talk about SDIO reset and not USB.
Fixing comments from original cut and paste error

Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:38 +09:00
Dan Williams abb3073383 i2400m: minimal ethtool support
Add minimal ethtool support for carrier detection.

Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:37 +09:00
Roel Kluin 2d44f204ad wimax: misplaced parenthesis
Fix misplaced parenthesis

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:36 +09:00
Roel Kluin a6346fa583 i2400m: keep index within ms_to_errno[]
Ensure that index `status' remains within ms_to_errno[]

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:35 +09:00
Cindy H Kao 5b45bfe501 wimax/i2400m: fix the bootmode RX deadlock in SDIO driver
i2400ms_bus_bm_wait_for_ack() causes a race condition. It happens
because this function clears i2400ms->bm_ack_size before waiting for
an interrupt, which is set by the interrupt service routine i2400ms_rx()
to indicate reception and size of received data; thus, if the interrupt
came right before the clearing/waiting, it is lost.

The fix is clear the bm_ack_size to -EINPROGRESS before we are enabling
the RX interrupt configuration in i2400ms_rx_setup(). Then everytime
when the interrupt service routine i2400ms_rx() is invoked during bootmode,
bm_ack_size is updated with the actual rx_size and it is cleared to
-EINPROGRESS again after the RX data is handled.

Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:33 +09:00
Oliver Neukum 663ebb4aa2 wimax/i2400m/usb: remove unnecessary power management primitive in i2400m
This patch removes an unneeded power management primitive.
Power management is automatically enabled as probe ends.

Signed-off-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:32 +09:00
Marcel Holtmann 384912ed19 net: Add DEVTYPE support for Ethernet based devices
The Ethernet framing is used for a lot of devices these days. Most
prominent are WiFi and WiMAX based devices. However for userspace
application it is important to classify these devices correctly and
not only see them as Ethernet devices. The daemons like HAL, DeviceKit
or even NetworkManager with udev support tries to do the classification
in userspace with a lot trickery and extra system calls. This is not
good and actually reaches its limitations. Especially since the kernel
does know the type of the Ethernet device it is pretty stupid.

To solve this problem the underlying device type needs to be set and
then the value will be exported as DEVTYPE via uevents and available
within udev.

  # cat /sys/class/net/wlan0/uevent
  DEVTYPE=wlan
  INTERFACE=wlan0
  IFINDEX=5

This is similar to subsystems like USB and SCSI that distinguish
between hosts, devices, disks, partitions etc.

The new SET_NETDEV_DEVTYPE() is a convenience helper to set the actual
device type. All device types are free form, but for convenience the
same strings as used with RFKILL are choosen.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-09-11 12:54:55 -07:00
Stephen Hemminger d0cf9c0dad wireless: convert drivers to netdev_tx_t
Mostly just simple conversions:
  * ray_cs had bogus return of NET_TX_LOCKED but driver
    was not using NETIF_F_LLTX
  * hostap and ipw2x00 had some code that returned value
    from a called function that also had to change to return netdev_tx_t

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-09-01 01:14:04 -07:00
Tomas Winkler 51def0bea9 imwc3200: move iwmc3200 SDIO ids to sdio_ids.h
1. add intel's sdio vendor id to sdio_ids.h
2. move iwmc3200 sdio devices' ids to sdio_ids.h

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-26 19:25:47 -07:00
GeunSik Lim 156f5a7801 debugfs: Fix terminology inconsistency of dir name to mount debugfs filesystem.
Many developers use "/debug/" or "/debugfs/" or "/sys/kernel/debug/"
directory name to mount debugfs filesystem for ftrace according to
./Documentation/tracers/ftrace.txt file.

And, three directory names(ex:/debug/, /debugfs/, /sys/kernel/debug/) is
existed in kernel source like ftrace, DRM, Wireless, Documentation,
Network[sky2]files to mount debugfs filesystem.

debugfs means debug filesystem for debugging easy to use by greg kroah
hartman. "/sys/kernel/debug/" name is suitable as directory name
of debugfs filesystem.
- debugfs related reference: http://lwn.net/Articles/334546/

Fix inconsistency of directory name to mount debugfs filesystem.

* From Steven Rostedt
  - find_debugfs() and tracing_files() in this patch.

Signed-off-by: GeunSik Lim <geunsik.lim@samsung.com>
Acked-by     : Inaky Perez-Gonzalez <inaky@linux.intel.com>
Reviewed-by  : Steven Rostedt <rostedt@goodmis.org>
Reviewed-by  : James Smart <james.smart@emulex.com>
CC: Jiri Kosina <trivial@kernel.org>
CC: David Airlie <airlied@linux.ie>
CC: Peter Osterlund <petero2@telia.com>
CC: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
CC: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
CC: Masami Hiramatsu <mhiramat@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15 21:30:28 -07:00
Inaky Perez-Gonzalez 98eb0f53e2 wimax: fix gcc warnings in sh4 when calling BUG()
SH4's BUG() seems to confuse the compiler as it is considered to
return; thus, some functions would trigger usage of uninitialized
variables or non-void functions returning void.

Work around by initializing/returning.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11 11:47:39 -07:00
Cindy H Kao 0bcfc5ef01 wimax/i2400m: use -EL3RST to indicate device reset instead of -ERESTARTSYS
When the i2400m device resets, the driver code will force some
functions to return a -ERESTARTSYS error code, which can is used by
the caller to determine which recovery actions to take.

However, in certain situations the only thing that can be done is to
bubble up said error code to user space, for handling.

However, -ERESTARSYS was a poor choice, as it is supposed to be used
by the kernel only.

As such, replace -ERESTARTSYS with -EL3RST; as well, in
i2400m_msg_to_dev(), when the device is in boot mode (following a
recent reset), return -EL3RST instead of -ENODEV (meaning the device
is in bootrom mode after a reset, not that the device was
disconnected, and thus, normal commands cannot be executed).

Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
2009-06-11 03:30:26 -07:00
Cindy H Kao 8b5b30ee7d wimax/i2400m: when bootstrap fails, reinitialize the bootrom
When a device reset happens during firmware load [in
i2400m_dev_bootstrap()], __i2400m_dev_start() will retry a number of
times. However, for those retries to be able to accomplish anything,
the device's bootrom has to be reinitialized.

Thus, on the retry path, pass the I2400M_MAC_REINIT to the firmware
load code.

Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
2009-06-11 03:30:26 -07:00
Inaky Perez-Gonzalez 16820c166d wimax/i2400m/sdio: Move all the RX code to a unified, IRQ based receive routine
The current SDIO code was working in polling mode for boot-mode
(firmware load) mode. This was causing issues on some hardware.

Moved all the RX code to use a unified IRQ handler that based on the
type of data the device is sending can discriminate and decide which
is the right destination.

As well, all the reads from the device are made to be at least the
block size (256); the driver will ignore the rest when not needed.

Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11 03:30:25 -07:00
Inaky Perez-Gonzalez 6e053d6c79 wimax/i2400m: don't reset device when bootrom init retries are exceeded
When i2400m_bootrom_init() fails to put the device into a state of
being ready to accept firmware, the driver was currently trying to
reset it if it failed to do so. This is not too useful; as part of
trying to put the device in the right state a few resets have already
been tried.

At this point, things are probably fried out and an extra reset might
do more harm than good (for example causing reseting of other
functions in the same composite device).

So it is left up to the callers to determine the error path to take
(at the end this is always i2400m_setup(), who depending on how many
retries are left, might give up on the device).

From a fix by Cindy H. Kao.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11 03:30:25 -07:00
Dirk Brandewie 1c0b2dd757 wimax/i2400m/sdio: Add device specific poke table.
Add a poke table for the SDIO device (as it is different than USB).

Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
2009-06-11 03:30:24 -07:00
Dirk Brandewie 7308a0c239 wimax/i2400m: move boot time poke table out of common driver
This change moves the table of "pokes" performed on the device at boot
time to the bus specific portion of the driver.

Different models of the i2400m device supported by this driver require
different poke tables, thus having a single table that works for all
is impossible. For that, the table is moved to the bus-specific
driver, who can decide which table to use based on the specifics of
the device and point the generic driver to it.

Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
2009-06-11 03:30:24 -07:00
Inaky Perez-Gonzalez ecddfd5ed7 wimax/i2400m: Allow bus-specific driver to specify retry count
The code that sets up the i2400m (firmware load and general driver
setup after it) includes a couple of retry loops.

The SDIO device sometimes can get in more complicated corners than the
USB one (due to its interaction with other SDIO functions), that
require trying a few more times.

To solve that, without having a failing USB device taking longer to be
considered dead, allow the retry counts to be specified by the
bus-specific driver, which the general driver takes as a parameter.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11 03:30:23 -07:00
Inaky Perez-Gonzalez b4013f91cd wimax/i2400m: if a device reboot happens during probe, handle it
When a device reboot happens when we are under probe, with init_mutex
taken, make sure we can recover. Have dev_reset_handle set boot mode
and i2400m_msg_to_dev() will see it and fail gracefully instead of
timing out.

Found and diagnosed by Cindy H. Kao.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11 03:30:23 -07:00
Inaky Perez-Gonzalez 59063afa0a wimax/i2400m: fix oops when the TX FIFO fills up due to a missing check
When the TX FIFO filled up and i2400m_tx_new() failed to allocate a
new TX message header, a missing check for said condition was causing a
kernel oops when trying to dereference a NULL i2400m->tx_msg pointer.

Found and diagnosed by Cindy H. Kao.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11 03:30:22 -07:00
Inaky Perez-Gonzalez b4bd07e3b1 wimax/i2400m: don't reset device on i2400m_dev_shutdown()
i2400m_dev_shutdown() tried to reset the device to put it in a known
state before shutting down.

But that turned out to be pointless. We reach this case in two paths:

 1 - when the device resets, to clean up state
 2 - when the driver is unloaded, for the same

however, in both cases it is pointless; in (1) the device is already
reset, why do it again? in (2) we can't -- the USB stack, for example,
doesn't allow communicating with the device when the driver is being
unbound and if the device is disconnected, the device is gone already.

So just remove it. Leave the function as a placeholder for future
cleanups that will be done from data allocated by the driver during
device operation.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11 03:30:22 -07:00
Inaky Perez-Gonzalez 2971a5bac8 wimax/i2400m: fix panic due to missed corner cases on tail_room calculation
i2400m_tx_skip_tail() needs to handle the special case of being called
when the tail room that is left over in the FIFO is zero.

This happens when a TX message header was opened at the very end of
the FIFO (without payloads). The i2400m_tx_close() code already marked
said TX message (header) to be skipped and this function should be
doing nothing.

It is called anyway because it is part of a common "corner case" path
handling which takes care of more cases than only this one.

The tail room computation was also improved to take care of the case
when tx_in is at the end of the buffer boundary; tail_room has to be
modded (%) to the buffer size. To do that in a single well-documented
place, __i2400m_tx_tail_room() is introduced and used.

Treat i2400m->tx_in == 0 as a corner case and handle it accordingly.

Found and diagnosed by Cindy H. Kao.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11 03:30:21 -07:00
Inaky Perez-Gonzalez c56affafdd wimax/i2400m: fix panic/warnings caused by missed check on empty TX message
In some situations, when a new TX message header is started, there
might be no space for data payloads. In this case the message is left
with zero payloads and the i2400m_tx_close() function has just to mark
it as "to skip". If it tries to go ahead it will overwrite things
because there is no space to add padding as defined by the
bus-specific layer. This can cause buffer overruns and in some stress
cases, panics.

Found and diagnosed by Cindy H. Kao.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11 03:30:21 -07:00
Inaky Perez-Gonzalez 8593a1967f wimax/i2400m: rename misleading I2400M_PL_PAD to I2400M_PL_ALIGN
The constant is being use as an alignment factor, not as a padding
factor; made reading/reviewing the code quite confusing.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11 03:30:20 -07:00
Dirk Brandewie 10b1de6b77 wimax/i2400m/sdio: Implement I2400M_RT_BUS reset type
This reset type causes the WiMAX function to be disabled and
re-enabled, which will force the WiMAX device to reset and enter boot
mode.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
2009-06-11 03:30:20 -07:00
Dirk Brandewie ead6823991 wimax/i2400m: Change d_printf() level for secure boot messages
Changing debug level of print out to support validation engineers
getting the messages they need.

Signed-off-by:  <dirk.j.brandewie@intel.com>
2009-06-11 03:30:19 -07:00
Inaky Perez-Gonzalez 16eafba8de wimax/i2400m: i2400m_schedule_work() doesn't need i2400m->work_queue
By mistake, the BUG_ON() check was left in there and it will fail when
called if i2400m->work_queue is still not setup.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11 03:30:19 -07:00
Inaky Perez-Gonzalez e9a6b45be5 wimax/i2400m: i2400m's work queue should be initialized before RX support
RX support is the only user of the work-queue, to process
reports/notifications from the device. Thus, it needs the work queue
to be initialized first.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11 03:30:18 -07:00
Inaky Perez-Gonzalez fff1068559 wimax/i2400m: don't call netif_start_queue() in _tx_msg_sent()
Reported and fixed by Cindy H Kao.

When the device is stopped __i2400m_dev_stop() stops the network
queue.

However, when this is done in the middle of heavy network operation,
when the bus-specific subdriver is still wrapping up and it reports a
sent TX transaction with _tx_msg_sent() right after the device was
stopped, the queue was being started again, which was causing a stream
of oopsen and finally a panic.

In any case, said call has no place there. It's a left over from an
early implementation that was discarded later on.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11 03:30:18 -07:00
Inaky Perez-Gonzalez fb10167478 wimax/i2400m: introduce module parameter to disable entering power save
The i2400m driver waits for the device to report being ready for
entering power save before asking it to do so. This module parameter
allows control of said operation; if disabled, the driver won't ask
the device to enter power save mode.

This is useful in setups where power saving is not so important or
when the overhead imposed by network reentry after power save is not
acceptable; by combining this with parameter 'idle_mode_disabled', the
driver will always maintain both the connection and the device in
active state.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11 03:30:17 -07:00
Inaky Perez-Gonzalez 2618ab774e wimax/i2400m: usb: fix device reset on autosuspend while not yet idle
When the i2400m is connected to a network, the host interface (USB)
cannot be suspended. For that to happen, the device has to have
negotiated with the basestation to put the link on IDLE state.

If the host tries to put the device in standby while it is connected
but not idle, the device resets, as the driver should not do that.

To avoid triggering that, when the USB susbsytem requires the driver
to autosuspend the device, the driver checks if the device is not yet
idle. If it is not, the request is requested (will be retried again
later on after the autosuspend timeout). At some point the device will
enter idle and the request will succeed (unless of course, there is
network traffic, but at that point, there is no idle neither in the
link or the host interface).

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-05-28 18:02:27 -07:00
Inaky Perez-Gonzalez a0a4c4c9e5 wimax/i2400m: sdio: set the block size before enabling the function
From a fix by Cindy H Kao:

  Block size has to be set before sending IOE enable because the
  firmware reads the block size register before it reads IOE register.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-05-28 18:02:11 -07:00
Inaky Perez-Gonzalez 052991d7ac wimax/i2400m: remove redundant readiness checks from i2400m_report_tlv_*()
Functions i2400m_report_tlv*() are only called from
i2400m_report_hook(), called in a workqueue by
i2400m_report_hook_work(). The scheduler checks for device readiness
before scheduling.

Added an extra check for readiness in i2400m_report_hook_work(), which
makes all the checks down the line redundant.

Obviously the device state could change in the middle, but error
handling would take care of that.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-05-28 18:01:58 -07:00
Inaky Perez-Gonzalez 8ac1101f8c wimax/i2400m: factor out 'state report's TLV handling to a function
i2400m_report_state_hook() is going to get messier as we add handling
code.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-05-28 18:01:49 -07:00
Inaky Perez-Gonzalez 223beea238 wimax/i2400m: allow kernel commands to device to be logged too
By running 'echo 1 > /sys/kernel/debug/wimax:wmxX/i2400m/trace_msg_from_user',
the driver will echo to user space all the commands being sent to the
device from user space, along with the responses.

However, this only helps with the commands being sent from user space;
with this patch, the trace hook is moved to i2400m_msg_to_dev(), which
is the single access point for running commands to the device (both by
user space and the kernel driver). This allows better debugging by
having a complete stream of commands/acks and reports.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-05-28 18:01:42 -07:00
Inaky Perez-Gonzalez 44b849d11b wimax/i2400m: trace commands sent from user space on the "echo" pipe
When commands are sent from user space, trace both the command sent
and the answer received over the "echo" pipe instead of over the
"trace" pipe when command tracing is enabled. As well, when the device
sends a reports/indications, send it over the "echo" pipe.

The "trace" pipe is used by the device to send firmware traces;
gets confusing. Another named pipe makes it easier to split debug
information.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-05-28 18:01:35 -07:00
Inaky Perez-Gonzalez fe44268385 wimax/i2400m: generate fake source MAC address with random_ether_addr()
The WiMAX i2400m driver needs to generate a fake source MAC address to
fake an ethernet header (for destination, the card's MAC is
used). This is the source of the packet, which is the basestation it
came from. The basestation's mac address is not usable for this, as it
uses its own namespace and it is not always available.

Currently the fake source MAC address was being set to all zeros,
which was causing trouble with bridging.

Use random_ether_addr() to generate a proper one that creates no
trouble.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-05-28 18:01:24 -07:00
Inaky Perez-Gonzalez 4e5b6d006b wimax/i2400m: fix device crash: fix optimization in _roq_queue_update_ws
When the i2400m receives data and the device indicates there has to be
reordering, we keep an sliding window implementation to sort the
packets before sending them to the network stack.

One of the "operations" that the device indicates is "queue a packet
and update the window start". When the queue is empty, this is
equivalent to "deliver the packet and update the window start".

That case was optimized in i2400m_roq_queue_update_ws() so that we
would not pointlessly queue and dequeue a packet. However, when the
optimization was active, it wasn't updating the window start. That
caused the reorder management code to get confused later on with what
seemed to be wrong reorder requests from the device.

Thus the fix implemented is to do the right thing and update the
window start in both cases, when the queue is empty (and the
optimization is done) and when not.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-05-14 18:00:32 -07:00
Randy Dunlap ff5e2b4732 wimax: fix i2400m printk formats
Fix printk format warnings:

drivers/net/wimax/i2400m/netdev.c:523: warning: format '%zu' expects type 'size_t', but argument 7 has type 'unsigned int'
drivers/net/wimax/i2400m/netdev.c:548: warning: format '%zu' expects type 'size_t', but argument 7 has type 'unsigned int'

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-11 23:24:03 -07:00
Inaky Perez-Gonzalez c747583d19 wimax/i2400m: implement RX reorder support
Allow the device to give the driver RX data with reorder information.

When that is done, the device will indicate the driver if a packet has
to be held in a (sorted) queue. It will also tell the driver when held
packets have to be released to the OS.

This is done to improve the WiMAX-protocol level retransmission
support when missing frames are detected.

The code docs provide details about the implementation.

In general, this just hooks into the RX path in rx.c; if a packet with
the reorder bit in the RX header is detected, the reorder information
in the header is extracted and one of the four main reorder operations
are executed. In one case (queue) no packet will be delivered to the
networking stack, just queued, whereas in the others (reset, update_ws
and queue_update_ws), queued packet might be delivered depending on
the window start for the specific queue.

The modifications to files other than rx.c are:

- control.c: during device initialization, enable reordering support
  if the rx_reorder_disabled module parameter is not enabled

- driver.c: expose a rx_reorder_disable module parameter and call
  i2400m_rx_setup/release() to initialize/shutdown RX reorder
  support.

- i2400m.h: introduce members in 'struct i2400m' needed for
  implementing reorder support.

- linux/i2400m.h: introduce TLVs, commands and constant definitions
  related to RX reorder

Last but not least, the rx reorder code includes an small circular log
where the last N reorder operations are recorded to be displayed in
case of inconsistency. Otherwise diagnosing issues would be almost
impossible.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-02 03:10:28 -08:00
Harvey Harrison 61b8d2688a wimax: replace uses of __constant_{endian}
Base versions handle constant folding now.

Edited by Inaky to fix conflicts due to changes in netdev.c

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-02 03:10:27 -08:00
Inaky Perez-Gonzalez fd5c565c0c wimax/i2400m: support extended data RX protocol (no need to reallocate skbs)
Newer i2400m firmwares (>= v1.4) extend the data RX protocol so that
each packet has a 16 byte header. This header is mainly used to
implement host reordeing (which is addressed in later commits).

However, this header also allows us to overwrite it (once data has
been extracted) with an Ethernet header and deliver to the networking
stack without having to reallocate the skb (as it happened in fw <=
v1.3) to make room for it.

- control.c: indicate the device [dev_initialize()] that the driver
  wants to use the extended data RX protocol. Also involves adding the
  definition of the needed data types in include/linux/wimax/i2400m.h.

- rx.c: handle the new payload type for the extended RX data
  protocol. Prepares the skb for delivery to
  netdev.c:i2400m_net_erx().

- netdev.c: Introduce i2400m_net_erx() that adds the fake ethernet
  address to a prepared skb and delivers it to the networking
  stack.

- cleanup: in most instances in rx.c, the variable 'single' was
  renamed to 'single_last' for it better conveys its meaning.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-02 03:10:26 -08:00
Kay Sievers 347707baa7 wimax: struct device - replace bus_id with dev_name(), dev_set_name()
Cc: inaky.perez-gonzalez@intel.com
Cc: linux-wimax@intel.com
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-02 03:10:26 -08:00
Inaky Perez-Gonzalez 8987691a4a wimax/i2400m: allow control of the base-station idle mode timeout
For power saving reasons, WiMAX links can be put in idle mode while
connected after a certain time of the link not being used for tx or
rx. In this mode, the device pages the base-station regularly and when
data is ready to be transmitted, the link is revived.

This patch allows the user to control the time the device has to be
idle before it decides to go to idle mode from a sysfs
interace.

It also updates the initialization code to acknowledge the module
variable 'idle_mode_disabled' when the firmware is a newer version
(upcoming 1.4 vs 2.6.29's v1.3).

The method for setting the idle mode timeout in the older firmwares is
much more limited and can be only done at initialization time. Thus,
the sysfs file will return -ENOSYS on older ones.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-02 03:10:25 -08:00
Inaky Perez-Gonzalez 6a0f7ab830 wimax/i2400m: firmware_check() encodes the firmware version in i2400m->fw_version
Upcoming modifications will need to test for the running firmware
version before activating a feature or not. This is helpful to
implement backward compatibility with older firmware versions.

Modify i2400m_firmware_check() to encode in i2400m->fw_version the
major and minor version numbers of the firmware interface.

As well, move the call to be done as the very first operation once we
have communication with the device during probe() [in
__i2400m_dev_start()]. This is needed so any operation that is
executed afterwards can determine which fw version it is talking to.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-02 03:10:24 -08:00
Inaky Perez-Gonzalez efa05d0f0a wimax/i2400m: drop support for deprecated major fw interface, add for new minor
Firmware interface version 8.x.x has long been deprecated and is no
longer supported (nor available, as it is a preproduction firmware),
so it can be safely dropped.

Add support for firmware interface v9.2.x (current is 9.1.x). Firmware
version 9.2.x is backwards compatible with 9.1.x; new features are
enabled if switches are pressed to turn them on. Forthcoming commits
to the driver will start pressing those switches when the firmware
interface supports it.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-02 03:10:23 -08:00
Inaky Perez-Gonzalez 1039abbc5b wimax/i2400m: add the ability to fallback to other firmware files if the default is not there
In order to support backwards compatibility with older firmwares when
a driver is updated by a new kernel release, the i2400m bus drivers
can declare a list of firmware files they can work with (in general
these will be each a different version). The firmware loader will try
them in sequence until one loads.

Thus, if a user doesn't have the latest and greatest firmware that a
newly installed kernel would require, the driver would fall back to
the firmware from a previous release.

To support this, the i2400m->bus_fw_name is changed to be a NULL
terminated array firmware file names (and renamed to bus_fw_names) and
we add a new entry (i2400m->fw_name) that points to the name of the
firmware being currently used. All code that needs to print the
firmware file name uses i2400m->fw_name instead of the old
i2400m->bus_fw_name.

The code in i2400m_dev_bootstrap() that loads the firmware is changed
with an iterator over the firmware file name list that tries to load
each form user space, using the first one that succeeds in
request_firmware() (and thus stopping the iteration).

The USB and SDIO bus drivers are updated to take advantage of this and
reflect which firmwares they support.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-03-02 03:10:23 -08:00
Wei Yongjun c71a2699c5 i2400m: remove some pointless conditionals before kfree_skb()
Remove some pointless conditionals before kfree_skb().

Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-02-26 23:07:31 -08:00
David S. Miller e70049b9e7 Merge branch 'master' of /home/davem/src/GIT/linux-2.6/ 2009-02-24 03:50:29 -08:00
Inaky Perez-Gonzalez 494ef10eba wimax/i2400m: driver loads firmware v1.4 instead of v1.3
This is a one liner change to have the driver use by default the v1.4
of the i2400m firmware instead of v1.3. The v1.4 version of the
firmware has been submitted to David Woodhouse for inclusion in the
linux-firmware tree and it is already available at
http://linuxwimax.org/Download.

The reason for this change is that the 1.3 release of the user space
software and firmware has a few issues that will make it difficult to
use with currently deployed commercial networks such as Xohm and
Clearwire.

As well, the new 1.4 release of the user space software (which matches
the 1.4 firmware) has intermitent issues with the 1.3 firmware.

The 1.4 release in http://linuxwimax.org/Download has been widely
deployed and tested with the codebase in 2.6.29-rc, the 1.4 firmware
and the 1.4 user space components.

We understand it is quite late in the rc process for such a change,
but would like to ask for the change to be taken into consideration.

Alternatively, a user could always force feed a 1.4 firmware into a
driver that doesn't have this modification by:

$ cd /lib/firmware
$ mv i2400m-fw-usb-1.3.sbcf i2400m-fw-usb-1.3.real.sbcf
$ ln -sf i2400m-fw-usb-1.4.sbc i2400m-fw-usb-1.3.sbcf

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-02-20 00:35:04 -08:00
Harvey Harrison ee437770c4 wimax: replace uses of __constant_{endian}
Base versions handle constant folding now.

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Acked-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-02-01 00:43:54 -08:00
David S. Miller 05bee47377 Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
Conflicts:
	drivers/net/e1000/e1000_main.c
2009-01-30 14:31:07 -08:00
Inaky Perez-Gonzalez 1af7ad5104 wimax: fix build issue when debugfs is disabled
As reported by Toralf Förster and Randy Dunlap.

- http://linuxwimax.org/pipermail/wimax/2009-January/000460.html

- http://lkml.org/lkml/2009/1/29/279

The definitions needed for the wimax stack and i2400m driver debug
infrastructure was, by mistake, compiled depending on CONFIG_DEBUG_FS
(by them being placed in the debugfs.c files); thus the build broke in
2.6.29-rc3 when debugging was enabled (CONFIG_WIMAX_DEBUG) and
DEBUG_FS was disabled.

These definitions are always needed if debug is enabled at compile
time (independently of DEBUG_FS being or not enabled), so moving them
to a file that is always compiled fixes the issue.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-01-29 17:18:31 -08:00
Inaky Perez-Gonzalez a962dc2520 wimax/i2400m: convert to net_device_ops
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-01-21 14:03:35 -08:00
Inaky Perez-Gonzalez f4895b8bc8 wimax/i2400m: error paths that need to free an skb should use kfree_skb()
Roel Kluin reported a bug in two error paths where skbs were wrongly
being freed using kfree(). He provided a fix where it was replaced to
kfree_skb(), as it should be.

However, in i2400mu_rx(), the error path was missing returning an
indication of the failure. Changed to reset rx_skb to NULL and return
it to the caller, i2400mu_rxd(). It will be treated as a transient
error and just ignore the packet.

Depending on the buffering conditions inside the device, the data
packet might be dropped or the device will signal the host again for
data-ready-to-read and the host will retry.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-01-19 17:58:08 -08:00
Inaky Perez-Gonzalez 9fd7a1d92b i2400m/usb: wrap USB power saving in #ifdef CONFIG_PM
Current code was assuming PM was always enabled, which is not
correct. Code which accesses members in the struct usb_device that are
dependant on CONFIG_PM must be protected the same.

Reported by Randy Dunlap from a build error in the linux-next tree on
07/01/2009.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-01-08 11:08:25 -08:00
Inaky Perez-Gonzalez 143ee2d555 i2400m: Makefile and Kconfig
Integrate the i2400m driver into the kernel's build and Kconfig.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07 10:00:22 -08:00
Inaky Perez-Gonzalez 514ec71f72 i2400m/SDIO: TX and RX path backends
Implements the backend so that the generic driver can TX/RX to/from
the SDIO device.

For RX, when data is ready the SDIO IRQ is fired and that will
allocate an skb, put all the data there and then pass it to the
generic driver RX code for processing and delivery.

TX, when kicked by the generic driver, will schedule work on a
driver-specific workqueue that pulls data from the TX FIFO and sends
it to the device until it drains it.

Thread contexts are needed as SDIO functions are blocking.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07 10:00:22 -08:00
Inaky Perez-Gonzalez 020bb6f30b i2400m/SDIO: firmware upload backend
This implements the backends for the generic driver (i2400m) to be
able to load firmware to the SDIO device.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07 10:00:22 -08:00
Inaky Perez-Gonzalez a0848826bf i2400m/SDIO: probe/disconnect, dev init/shutdown and reset backends
Implements probe/disconnect for the SDIO device, as well as main
backends for the generic driver to control the SDIO device
(bus_dev_start(), bus_dev_stop() and bus_reset()).

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07 10:00:22 -08:00
Inaky Perez-Gonzalez 17d559af96 i2400m/SDIO: header for the SDIO subdriver
This contains the common function declaration and constants for the
SDIO driver for the 2400m Wireless WiMAX Connection and it's debug
level settings.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07 10:00:22 -08:00
Inaky Perez-Gonzalez a8ebf98f54 i2400m/USB: TX and RX path backends
Implements the backend so that the generic driver can TX/RX to/from
the USB device.

TX is implemented with a kthread sitting in a never-ending loop that
when kicked by the generic driver's TX code will pull data from the TX
FIFO and send it to the device until it drains it. Then it goes back
sleep, waiting for another kick.

RX is implemented in a similar fashion, but reads are kicked in by the
device notifying in the interrupt endpoint that data is ready. Device
reset notifications are also sent via the notification endpoint.

We need a thread contexts to run USB autopm functions (blocking) and
to process the received data (can get to be heavy in processing
time).

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07 10:00:21 -08:00
Inaky Perez-Gonzalez 795038107b i2400m/USB: firmware upload backend
This implements the backends for the generic driver (i2400m) to be
able to load firmware to the USB device.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07 10:00:21 -08:00
Inaky Perez-Gonzalez f398e4240f i2400m/USB: probe/disconnect, dev init/shutdown and reset backends
Implements probe/disconnect for the USB device, as well as main
backends for the generic driver to control the USB device
(bus_dev_start(), bus_dev_stop() and bus_reset()).

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07 10:00:21 -08:00
Inaky Perez-Gonzalez 11a7d0e314 i2400m/USB: header for the USB bus driver
This contains the common function declaration and constants for the
USB driver for the 2400m Wireless WiMAX Connection, as well as it's
debug level settings.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07 10:00:21 -08:00
Inaky Perez-Gonzalez c71228caf9 i2400m: debugfs controls
Expose knobs to control the device (induce reset, power saving,
querying tx or rx stats, internal debug information and debug level
manipulation).

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07 10:00:20 -08:00
Inaky Perez-Gonzalez 3a35a1d0bd i2400m: various functions for device management
This is a collection of functions used to control the device (plus a
few helpers).

There are utilities for handling TLV buffers, hooks on the device's
reports to act on device changes of state [i2400m_report_hook()], on
acks to commands [i2400m_msg_ack_hook()], a helper for sending
commands to the device and blocking until a reply arrives
[i2400m_msg_to_dev()], a few high level commands for manipulating the
device state, powersaving mode and configuration plus the routines to
setup the device once communication is established with it
[i2400m_dev_initialize()].

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07 10:00:19 -08:00
Inaky Perez-Gonzalez aa5a7acabe i2400m: RX and TX data/control paths
Handling of TX/RX data to/from the i2400m device (IP packets, control
and diagnostics). On RX, this parses the received read transaction
from the device, breaks it in chunks and passes it to the
corresponding subsystems (network and control).

Transmission to the device is done through a software FIFO, as
data/control frames can be coalesced (while the device is reading the
previous tx transaction, others accumulate). A FIFO is used because at
the end it is resource-cheaper that scatter/gather over USB. As well,
most traffic is going to be download (vs upload).

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07 10:00:19 -08:00
Inaky Perez-Gonzalez 467cc396fb i2400m: firmware loading and bootrom initialization
Implements the firmware loader (using the bus-specific driver's
backends for the actual upload). The most critical thing in here is
the piece that puts the device in boot-mode from any other
(undetermined) state, otherwise, it is just pushing the bytes from the
firmware file to the device.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07 10:00:19 -08:00
Inaky Perez-Gonzalez ce6cde9280 i2400m: linkage to the networking stack
Implementation of the glue to the network stack so the WiMAX device
shows up as an Ethernet device.

Initially we shot for implementing a Pure IP device -- however, the
world seems to turn around Ethernet devices. Main issues were with the
ISC DHCP client and servers (as they don't understand types other than
Ethernet and Token Ring).

We proceeded to register with IANA the PureIP hw type, so that DHCP
requests could declare such. We also created patches to the main ISC
DHCP versions to support it. However, until all that permeates into
deployments, there is going to be a long time.

So we moved back to wrap Ethernet frames around the PureIP device. At
the time being this has overhead; we need to reallocate with space for
an Ethernet header. The reason is the device-to-host protocol
coalesces many network packets into a single message, so we can't
introduce Ethernet headers without overwriting valid data from other
packets.

Coming-soon versions of the firmware have this issue solved.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07 10:00:18 -08:00
Inaky Perez-Gonzalez 024f7f31ed i2400m: Generic probe/disconnect, reset and message passing
Implements the generic probe and disconnect functions that will be
called by the USB and SDIO driver's probe/disconnect functions.

Implements the backends for the WiMAX stack's basic operations:
message passing, rfkill control and reset.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07 10:00:18 -08:00
Inaky Perez-Gonzalez ea24652d25 i2400m: host/device procotol and core driver definitions
The wimax/i2400m.h defines the structures and constants for the
host-device protocols:

 - boot / firmware upload protocol

 - general data transport protocol

 - control protocol

It is done in such a way that can also be used verbatim by user space.

drivers/net/wimax/i2400m.h defines all the APIs used by the core,
bus-generic driver (i2400m) and the bus specific drivers
(i2400m-BUSNAME). It also gives a roadmap to the driver
implementation.

debug-levels.h adds the core driver's debug settings.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-01-07 10:00:18 -08:00