1. 06 Nov, 2009 3 commits
  2. 05 Nov, 2009 2 commits
  3. 04 Nov, 2009 2 commits
  4. 03 Nov, 2009 5 commits
  5. 02 Nov, 2009 1 commit
  6. 30 Oct, 2009 3 commits
  7. 29 Oct, 2009 10 commits
  8. 28 Oct, 2009 3 commits
  9. 27 Oct, 2009 2 commits
  10. 22 Oct, 2009 1 commit
  11. 20 Oct, 2009 3 commits
  12. 19 Oct, 2009 5 commits
    • Dirk Brandewie's avatar
      wimax/i6x50: add Intel WiFi/WiMAX Link 6050 Series support · 7329012e
      Dirk Brandewie authored
      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: default avatarDirk Brandewie <dirk.j.brandewie@intel.com>
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
    • Cindy H Kao's avatar
      wimax/iwmc3200: add new sdio device ID to support iwmc3200 2.5GHz sku · f8fc3295
      Cindy H Kao authored
      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: default avatarCindy H Kao <cindy.h.kao@intel.com>
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: fix reboot echo/ack barker deadlock · 923d708f
      Inaky Perez-Gonzalez authored
      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
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: decide properly if using signed vs non-signed firmware loading · 32742e61
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
    • Inaky Perez-Gonzalez's avatar
      wimax: allow specifying debug levels as command line option · 4c2b1a11
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>