Commit Graph

50 Commits

Author SHA1 Message Date
Lucas De Marchi 25985edced Fix common misspellings
Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-03-31 11:26:23 -03:00
Linus Torvalds 008d23e485 Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial
* 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (43 commits)
  Documentation/trace/events.txt: Remove obsolete sched_signal_send.
  writeback: fix global_dirty_limits comment runtime -> real-time
  ppc: fix comment typo singal -> signal
  drivers: fix comment typo diable -> disable.
  m68k: fix comment typo diable -> disable.
  wireless: comment typo fix diable -> disable.
  media: comment typo fix diable -> disable.
  remove doc for obsolete dynamic-printk kernel-parameter
  remove extraneous 'is' from Documentation/iostats.txt
  Fix spelling milisec -> ms in snd_ps3 module parameter description
  Fix spelling mistakes in comments
  Revert conflicting V4L changes
  i7core_edac: fix typos in comments
  mm/rmap.c: fix comment
  sound, ca0106: Fix assignment to 'channel'.
  hrtimer: fix a typo in comment
  init/Kconfig: fix typo
  anon_inodes: fix wrong function name in comment
  fix comment typos concerning "consistent"
  poll: fix a typo in comment
  ...

Fix up trivial conflicts in:
 - drivers/net/wireless/iwlwifi/iwl-core.c (moved to iwl-legacy.c)
 - fs/ext4/ext4.h

Also fix missed 'diabled' typo in drivers/net/bnx2x/bnx2x.h while at it.
2011-01-13 10:05:56 -08:00
Tejun Heo 781ba45676 i2400m: drop i2400m_schedule_work()
i2400m implements dynamic work allocation and queueing mechanism in
i2400_schedule_work(); however, this is only used for reset and
recovery which can be served equally well with preallocated per device
works.

Replace i2400m_schedule_work() with two work structs in struct i2400m.
These works are explicitly canceled when the device is released making
calls to flush_scheduled_work(), which is being deprecated,
unnecessary.

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Cc: linux-wimax@intel.com
Cc: netdev@vger.kernel.org
2010-12-12 16:45:14 +01:00
Uwe Kleine-König b595076a18 tree-wide: fix comment/printk typos
"gadget", "through", "command", "maintain", "maintain", "controller", "address",
"between", "initiali[zs]e", "instead", "function", "select", "already",
"equal", "access", "management", "hierarchy", "registration", "interest",
"relative", "memory", "offset", "already",

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2010-11-01 15:38:34 -04:00
stephen hemminger e3d32687a6 wimax: make functions local
Make wimax variables and functions local if possible.
Compile tested only.

This also removes a couple of unused EXPORT_SYMBOL.
If this breaks some out of tree code, please fix that
by putting the code in the kernel tree.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-05 00:47:38 -07:00
David S. Miller 1cdc5abf40 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax 2010-05-15 23:14:16 -07:00
Joe Perches a4b770972b drivers/net: Remove unnecessary returns from void function()s
This patch removes from drivers/net/ all the unnecessary
return; statements that precede the last closing brace of
void functions.

It does not remove the returns that are immediately
preceded by a label as gcc doesn't like that.

It also does not remove null void functions with return.

Done via:
$ grep -rP --include=*.[ch] -l "return;\n}" net/ | \
  xargs perl -i -e 'local $/ ; while (<>) { s/\n[ \t\n]+return;\n}/\n}/g; print; }'

with some cleanups by hand.

Compile tested x86 allmodconfig only.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-05-14 00:19:28 -07:00
Prasanna S Panchamukhi 9d7fdf1ba9 wimax/i2400m: Move module params to other file so they can be static
This patch moves the module parameters to the file where they
can be avoided to be global and allow them to be static.

The module param : idle_mode_disabled and power_save_disabled
are moved from  driver.c to control.c. Also these module parameters
are declared to be static as they are not required to be global anymore.
The module param : rx_reorder_disabled is moved from driver.c file to
rx.c file. Also this parameter is declated as static as it is not
required to be global anymore.

Signed-off-by: Prasanna S Panchamukhi<prasannax.s.panchamukhi@intel.com>
2010-05-11 14:10:24 -07:00
Cindy H Kao 2354161dd3 wimax/i2400m: Correct the error path handlers order in i2400m_post_reset()
When bus_setup fails in i2400m_post_reset(), it falls to the error path handler
"error_bus_setup:" which includes unlock the mutext. However, we didn't ever
try to the obtain the lock when running bus_setup.

The patch is to fix the misplaced error path handler "error_bus_setup:".

Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
2010-05-11 14:05:47 -07:00
Cindy H Kao 599e595384 wimax/i2400m: add the error recovery mechanism on TX path
This patch adds an error recovery mechanism on TX path.
The intention is to bring back the device to some known state
whenever TX sees -110 (-ETIMEOUT) on copying the data to the HW FIFO.

The TX failure could mean a device bus stuck or function stuck, so
the current error recovery implementation is to trigger a bus reset
and expect this can bring back the device.

Since the TX work is done in a thread context, there may be a queue of TX works
already that all hit the -ETIMEOUT error condition because the device has
somewhat stuck already. We don't want any consecutive bus resets simply because
multiple TX works in the queue all hit the same device erratum, the flag
"error_recovery" is introduced to denote if we are ready for taking any
error recovery. See @error_recovery doc in i2400m.h.

Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
2010-05-11 14:05:39 -07:00
Cindy H Kao f4e4134581 wimax/i2400m: fix for missed reset events if triggered by dev_reset_handle()
The problem is only seen on SDIO interface since on USB, a bus reset would
really re-probe the driver, but on SDIO interface, a bus reset will not
re-enumerate the SDIO bus, so no driver re-probe is happening. Therefore,
on SDIO interface, the reset event should be still detected and handled by
dev_reset_handle().

Problem description:
Whenever a reboot barker is received during operational mode (i2400m->boot_mode == 0),
dev_reset_handle() is invoked to handle that function reset event.
dev_reset_handle() then sets the flag i2400m->boot_mode to 1 indicating the device is
back to bootmode before proceeding to dev_stop() and dev_start().
If dev_start() returns failure, a bus reset is triggered by dev_reset_handle().

The flag i2400m->boot_mode then remains 1 when the second reboot barker arrives.
However the interrupt service routine i2400ms_rx() instead of invoking dev_reset_handle()
to handle that reset event, it filters out that boot event to bootmode because it sees
the flag i2400m->boot_mode equal to 1.

The fix:
Maintain the flag i2400m->boot_mode within dev_reset_handle() and set the flag
i2400m->boot_mode to 1 when entering dev_reset_handle(). It remains 1
until the dev_reset_handle() issues a bus reset. ie: the bus reset is
taking place just like it happens for the first time during operational mode.

To denote the actual device state and the state we expect, a flag i2400m->alive
is introduced in addition to the existing flag i2400m->updown.
It's maintained with the same way for i2400m->updown but instead of reflecting
the actual state like i2400m->updown does, i2400m->alive maintains the state
we expect. i2400m->alive is set 1 just like whenever i2400m->updown is set 1.
Yet i2400m->alive remains 1 since we expect the device to be up all the time
until the driver is removed. See the doc for @alive in i2400m.h.

An enumeration I2400M_BUS_RESET_RETRIES is added to define the maximum number of
bus resets that a device reboot can retry.

A counter i2400m->bus_reset_retries is added to track how many bus resets
have been retried in one device reboot. If I2400M_BUS_RESET_RETRIES bus resets
were retried in this boot, we give up any further retrying so the device would enter
low power state. The counter i2400m->bus_reset_retries is incremented whenever
dev_reset_handle() is issuing a bus reset and is cleared to 0 when dev_start() is
successfully done, ie: a successful reboot.

Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
2010-05-11 14:05:30 -07:00
Cindy H Kao 49d72df3f6 wimax/i2400m: correct the error path handlers in dev_start()
This fix is to correct order of the handlers in the error path
of dev_start(). When i2400m_firmware_check fails, all the works done
before it should be released or cleared.

Signed-off-by: Cindy H Kao <cindy.h.kao@intel.com>
2010-05-11 14:04:54 -07:00
Tejun Heo 5a0e3ad6af include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-30 22:02:32 +09:00
hartleys 4754b3de93 drivers/net/wimax/i2400m/driver.c: use %pM to show MAC address
Use the %pM kernel extension to display the MAC address.

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-01-07 01:14:01 -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 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 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 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
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 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
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 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
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
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 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 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 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 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 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
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 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 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