1. 05 Oct, 2010 1 commit
  2. 11 May, 2010 6 commits
    • Prasanna S Panchamukhi's avatar
      wimax/i2400m: Move module params to other file so they can be static · 9d7fdf1b
      Prasanna S Panchamukhi authored
      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>
      9d7fdf1b
    • Prasanna S. Panchamukhi's avatar
      wimax/i2400m: reserve additional space in the TX queue's buffer while... · 27502908
      Prasanna S. Panchamukhi authored
      wimax/i2400m: reserve additional space in the TX queue's buffer while allocating space for a new message header
      
      Increase the possibilities of including at least one payload by reserving
      some additional space in the TX queue while allocating TX queue's space
      for new message header. Please refer the documentation in the code for details.
      Signed-off-by: default avatarPrasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
      27502908
    • Prasanna S. Panchamukhi's avatar
      wimax i2400m: fix race condition while accessing rx_roq by using kref count · d11a6e44
      Prasanna S. Panchamukhi authored
      This patch fixes the race condition when one thread tries to destroy
      the memory allocated for rx_roq, while another thread still happen
      to access rx_roq.
      Such a race condition occurs when i2400m-sdio kernel module gets
      unloaded, destroying the memory allocated for rx_roq while rx_roq
      is accessed by i2400m_rx_edata(), as explained below:
      $thread1                                $thread2
      $ void i2400m_rx_edata()                $
      $Access rx_roq[]                        $
      $roq = &i2400m->rx_roq[ro_cin]          $
      $ i2400m_roq_[reset/queue/update_ws]    $
      $                                       $ void i2400m_rx_release();
      $                                       $kfree(rx->roq);
      $                                       $rx->roq = NULL;
      $Oops! rx_roq is NULL
      
      This patch fixes the race condition using refcount approach.
      Signed-off-by: default avatarPrasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
      d11a6e44
    • Cindy H Kao's avatar
      wimax/i2400m: add the error recovery mechanism on TX path · 599e5953
      Cindy H Kao authored
      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: default avatarCindy H Kao <cindy.h.kao@intel.com>
      599e5953
    • Cindy H Kao's avatar
      wimax/i2400m: fix for missed reset events if triggered by dev_reset_handle() · f4e41345
      Cindy H Kao authored
      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: default avatarCindy H Kao <cindy.h.kao@intel.com>
      f4e41345
    • Prasanna S. Panchamukhi's avatar
      wimax/i2400m: move I2400M_MAX_MTU enum from netdev.c to i2400m.h · 080de04e
      Prasanna S. Panchamukhi authored
      This patch moves I2400M_MAX_MTU enum defined in netdev.c to i2400m.h.
      Follow up changes will make use of this value in other location,
      thus requiring it to be moved to a global header file i2400m.h.
      Signed-off-by: default avatarPrasanna S. Panchamukhi <prasannax.s.panchamukhi@intel.com>
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      080de04e
  3. 09 Feb, 2010 1 commit
  4. 03 Nov, 2009 1 commit
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: introduce i2400m_reset(), stopping TX and carrier · c931ceeb
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      c931ceeb
  5. 19 Oct, 2009 17 commits
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: make i2400m->bus_dev_{stop,start}() optional · 097acbef
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      097acbef
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: queue device's report until the driver is ready for them · a0beba21
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      a0beba21
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: move i2400m_init() out of i2400m.h · af77dfa7
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      af77dfa7
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: fix deadlock: don't do BUS reset under i2400m->init_mutex · b9ee9501
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      b9ee9501
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: Implement pre/post reset support in the USB driver · 3725d8c9
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      3725d8c9
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: do bootmode buffer management in i2400m_setup/release() · 2869da85
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      2869da85
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: introduce i2400m->bus_setup/release · 0856ccf2
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      0856ccf2
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: clarify and fix i2400m->{ready,updown} · c2315b4e
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      c2315b4e
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: cleanup initialization/destruction flow · 8f90f3ee
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      8f90f3ee
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: on device stop, clean up pending wake & TX work · ac53aed9
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      ac53aed9
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: cache firmware on system suspend · 7b43ca70
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      7b43ca70
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: add reason argument to i2400m_dev_reset_handle() · 3ef6129e
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      3ef6129e
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: clean up & add a payload argument to i2400m_schedule_work() · b0fbcb2a
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      b0fbcb2a
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: support extended firmware format · bfc44187
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      bfc44187
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: rework bootrom initialization to be more flexible · aba3792a
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      aba3792a
    • Dirk Brandewie's avatar
      wimax/i2400m: Make boot retries a BUS-specific parameter · c3083658
      Dirk Brandewie authored
      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: default avatarDirk Brandewie <dirk.j.brandewie@intel.com>
      Signed-off-by: default avatarCindy H Kao <cindy.h.kao@intel.com>
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      c3083658
    • Dirk Brandewie's avatar
      wimax/i2400m: Ensure boot mode cmd and ack buffers are alloc'd before first message · a134fd6b
      Dirk Brandewie authored
      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: default avatarDirk Brandewie <dirk.j.brandewie@intel.com>
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      a134fd6b
  6. 16 Jun, 2009 1 commit
    • GeunSik Lim's avatar
      debugfs: Fix terminology inconsistency of dir name to mount debugfs filesystem. · 156f5a78
      GeunSik Lim authored
      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: default avatarGeunSik 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: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      156f5a78
  7. 11 Jun, 2009 3 commits
    • Dirk Brandewie's avatar
      wimax/i2400m: move boot time poke table out of common driver · 7308a0c2
      Dirk Brandewie authored
      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: default avatarDirk Brandewie <dirk.j.brandewie@intel.com>
      7308a0c2
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: Allow bus-specific driver to specify retry count · ecddfd5e
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      ecddfd5e
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: introduce module parameter to disable entering power save · fb101674
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      fb101674
  8. 29 May, 2009 1 commit
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: generate fake source MAC address with random_ether_addr() · fe442683
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      fe442683
  9. 02 Mar, 2009 5 commits
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: implement RX reorder support · c747583d
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c747583d
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: support extended data RX protocol (no need to reallocate skbs) · fd5c565c
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fd5c565c
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: allow control of the base-station idle mode timeout · 8987691a
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8987691a
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: firmware_check() encodes the firmware version in i2400m->fw_version · 6a0f7ab8
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6a0f7ab8
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: add the ability to fallback to other firmware files if the default is not there · 1039abbc
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1039abbc
  10. 20 Feb, 2009 1 commit
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: driver loads firmware v1.4 instead of v1.3 · 494ef10e
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      494ef10e
  11. 01 Feb, 2009 1 commit
  12. 07 Jan, 2009 1 commit