Commit Graph

11 Commits

Author SHA1 Message Date
Thomas Weber
8839316121 Fix typos in comments
[Ss]ytem => [Ss]ystem
udpate => update
paramters => parameters
orginal => original

Signed-off-by: Thomas Weber <swirl@gmx.li>
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2010-03-16 11:47:56 +01:00
Alexey Dobriyan
b54452b07a const: struct nla_policy
Make remaining netlink policies as const.
Fixup coding style where needed.

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-02-18 14:30:18 -08:00
Joe Perches
f64f9e7192 net: Move && and || to end of previous line
Not including net/atm/

Compiled tested x86 allyesconfig only
Added a > 80 column line or two, which I ignored.
Existing checkpatch plaints willfully, cheerfully ignored.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-11-29 16:55:45 -08:00
Inaky Perez-Gonzalez
81d3f90538 wimax: allow WIMAX_RF_QUERY calls when state is still uninitialized
Until now, calls to wimax_rfkill() will be blocked until the device is
at least past the WIMAX_ST_UNINITIALIZED state, return -ENOMEDIUM when
the device is in the WIMAX_ST_DOWN state.

In parallel, wimax-tools would issue a wimax_rfkill(WIMAX_RF_QUERY)
call right after opening a handle with wimaxll_open() as means to
verify if the interface is really a WiMAX interface [newer kernel
version will have a call specifically for this].

The combination of these two facts is that in some cases, before the
driver has finalized initializing its device's firmware, a
wimaxll_open() call would fail, when it should not.

Thus, change the wimax_rfkill() code to allow queries when the device
is in WIMAX_ST_UNINITIALIZED state.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:56:14 +09:00
Inaky Perez-Gonzalez
c29eaf3fae wimax: indicate initial SW rfkill state is "blocked"
The WiMAX stack assumes that all WiMAX devices are SW OFF when they
are initialized. The recent changes in the RFKILL stack thus cause an
initial call after rfkill_register(), because by default, rfkill
considers devices to be SW ON upon registration.

So call rfkill_init_sw_state() to set it to SW OFF so
rfkill_register() doesn't do that unnecessary step.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-10-19 15:55:34 +09:00
Inaky Perez-Gonzalez
d2f4c10544 wimax: fix warning caused by not checking retval of rfkill_set_hw_state()
Caused by an API update. The return value can be safely ignored, as
there is notthing we can do with it.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
2009-06-11 11:12:48 -07:00
Johannes Berg
19d337dff9 rfkill: rewrite
This patch completely rewrites the rfkill core to address
the following deficiencies:

 * all rfkill drivers need to implement polling where necessary
   rather than having one central implementation

 * updating the rfkill state cannot be done from arbitrary
   contexts, forcing drivers to use schedule_work and requiring
   lots of code

 * rfkill drivers need to keep track of soft/hard blocked
   internally -- the core should do this

 * the rfkill API has many unexpected quirks, for example being
   asymmetric wrt. alloc/free and register/unregister

 * rfkill can call back into a driver from within a function the
   driver called -- this is prone to deadlocks and generally
   should be avoided

 * rfkill-input pointlessly is a separate module

 * drivers need to #ifdef rfkill functions (unless they want to
   depend on or select RFKILL) -- rfkill should provide inlines
   that do nothing if it isn't compiled in

 * the rfkill structure is not opaque -- drivers need to initialise
   it correctly (lots of sanity checking code required) -- instead
   force drivers to pass the right variables to rfkill_alloc()

 * the documentation is hard to read because it always assumes the
   reader is completely clueless and contains way TOO MANY CAPS

 * the rfkill code needlessly uses a lot of locks and atomic
   operations in locked sections

 * fix LED trigger to actually change the LED when the radio state
   changes -- this wasn't done before

Tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03 14:06:13 -04:00
Johannes Berg
621cac8529 rfkill: remove user_claim stuff
Almost all drivers do not support user_claim, so remove it
completely and always report -EOPNOTSUPP to userspace. Since
userspace cannot really drive rfkill _anyway_ (due to the
odd restrictions imposed by the documentation) having this
code is just pointless.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-22 16:54:27 -04:00
Johannes Berg
c1c6b14b22 rfkill: remove deprecated state constants
I only did superficial review, but these constants are stupid
to have and without proper warnings nobody will review the
code anyway, no amount of shouting will help.

Also fix wimax to use correct states.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-04-22 16:54:27 -04:00
Inaky Perez-Gonzalez
a2e9da4b09 wimax: testing for rfkill support should also test for CONFIG_RFKILL_MODULE
Current WiMAX rfkill code is missing the case where rfkill is compiled
in as modules and works only when rfkill is compiled in. This is not
correct. Fixed to test for CONFIG_RFKILL or CONFIG_RKILL_MODULE.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-01-08 11:08:01 -08:00
Inaky Perez-Gonzalez
3e65646bb1 wimax: basic API: kernel/user messaging, rfkill and reset
Implements the three basic operations provided by the stack's control
interface to WiMAX devices:

- Messaging channel between user space and driver/device

  This implements a direct communication channel between user space
  and the driver/device, by which free form messages can be sent back
  and forth.

  This is intended for device-specific features, vendor quirks, etc.

- RF-kill framework integration

  Provide most of the RF-Kill integration for WiMAX drivers so that
  all device drivers have to do is after wimax_dev_add() is call
  wimax_report_rfkill_{hw,sw}() to update initial state and then every
  time it changes.

  Provides wimax_rfkill() for the kernel to call to set software
  RF-Kill status and/or query current hardware and software switch
  status.

  Exports wimax_rfkill() over generic netlink to user space.

- Reset a WiMAX device

  Provides wimax_reset() for the kernel to reset a wimax device as
  needed and exports it over generic netlink to user space.

This API is clearly limited, as it still provides no way to do the
basic scan, connect and disconnect in a hardware independent way.  The
WiMAX case is more complex than WiFi due to the way networks are
discovered and provisioned.

The next developments are to add the basic operations so they can be
offerent by different drivers. However, we'd like to get more vendors
to jump in and provide feedback of how the user/kernel API/abstraction
layer should be.

The user space code for the i2400m, as of now, uses the messaging
channel, but that will change as the API evolves.

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