10 Aug, 2015

1 commit

  • This patch fix a double word "the the"
    in Documentation/DocBook/networking.xml and
    Documentation/DocBook/networking/API-Wimax-report-rfkill-sw.html.

    These files are generated from comment in source, so I had to
    fix the typo in net/wimax/io-rfkill.c

    Signed-off-by: Masanari Iida
    Signed-off-by: David S. Miller

    Masanari Iida
     

08 Oct, 2014

1 commit


15 Nov, 2013

1 commit

  • This simplifies the code since there's no longer a need to
    have error handling in the registration.

    Unfortunately it means more extern function declarations are
    needed, but the overall goal would seem to justify this.

    Due to the removal of duplication in the netlink policies,
    this reduces the size of wimax by almost 1k.

    Signed-off-by: Johannes Berg
    Signed-off-by: David S. Miller

    Johannes Berg
     

01 Nov, 2011

1 commit


16 Mar, 2010

1 commit


19 Feb, 2010

1 commit


30 Nov, 2009

1 commit


19 Oct, 2009

2 commits

  • 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 Perez-Gonzalez
     
  • 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 Perez-Gonzalez
     

12 Jun, 2009

1 commit


04 Jun, 2009

1 commit

  • 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
    Signed-off-by: Henrique de Moraes Holschuh [thinkpad]
    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

23 Apr, 2009

2 commits

  • 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
    Signed-off-by: John W. Linville

    Johannes Berg
     
  • 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
    Signed-off-by: John W. Linville

    Johannes Berg
     

09 Jan, 2009

1 commit


08 Jan, 2009

1 commit

  • 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
    Signed-off-by: Greg Kroah-Hartman

    Inaky Perez-Gonzalez