1. 19 Oct, 2009 40 commits
    • 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: when stopping the device, cancel any pending message · 5eeae35b
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      5eeae35b
    • Cindy H Kao's avatar
      wimax/i2400m: change the bcf_len to exclude the extended header size · 28cff50d
      Cindy H Kao authored
      The actual fw->size may not equal to the bcf size indicated in
      the bcf header if the extended bcf debug header is added in the tail.
      
      To reflect the actual fw size that will be downloaded to the device,
      it is now retrived from from the size field indicated in the bcf header.
      
      All of the headers (if there are extended headers) should indicate same
      value for the size field since only one set of firmware chunks is downloaded
      Signed-off-by: default avatarCindy H Kao <cindy.h.kao@intel.com>
      28cff50d
    • Cindy H Kao's avatar
      wimax/i2400m: use JUMP cmd for last FW chunk indication · 6f4fc90a
      Cindy H Kao authored
      Both secure and non-secure boot must set the JUMP command in the
      bootmode header as the last FW chunk, so we change to use the JUMP
      command to decide if the FW chunk download is completed.
      
      Since we tend to use one single FW to support both secure and non-secure
      boot for most of the time, I2400M_BRH_SIGNED_JUMP is actually found
      even for non-secure boot. But in case the FW does come with
      I2400M_BRH_JUMP, we check for both of them in i2400m_dnload_bcf().
      Signed-off-by: default avatarCindy H Kao <cindy.h.kao@intel.com>
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      6f4fc90a
    • Inaky Perez-Gonzalez's avatar
      wimax: allow WIMAX_RF_QUERY calls when state is still uninitialized · 81d3f905
      Inaky Perez-Gonzalez authored
      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: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      81d3f905
    • Inaky Perez-Gonzalez's avatar
      wimax: allow user space to send messages once the device is registered · de9315fa
      Inaky Perez-Gonzalez authored
      It makes sense that the messaging pipe to the device can be used
      before the device is fully ready, as long as it is registered with the
      stack. Some debugging tools need it.
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      de9315fa
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: fix race condition with tcpdump et al · 9835fd84
      Inaky Perez-Gonzalez authored
      tcpdump and friends were not being able to decode packets sent via
      WiMAX; they had a zero ethernet type, even when the stack was properly
      sending them to the device with the right type.
      
      It happens that the driver was overwriting the (fake) ethernet header
      for creating the hardware header and that was bitting the cloning used
      by tcpdump (et al) to look into the packets.
      
      Use pkskb_expand_head() [method copied from the e1000 driver] to fix.
      
      Thanks to Herbert Xu and Andi Kleen for helping to diagnose and
      pointing to the right fix.
      
      Cc: Herbert Xu <gondor.apana.org.au>
      Cc: Andi Kleen <andi@firstfloor.org>
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      9835fd84
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: reduce verbosity of debug messages in boot mode · e1633fd6
      Inaky Perez-Gonzalez authored
      Missed a debug message that was being constantly printed as a
      dev_err(); became annoying. Demote it to a debug message.
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      e1633fd6
    • 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: don't overwrite error codes when failing to load firmware · cb5b756f
      Inaky Perez-Gonzalez authored
      Make sure that i2400m_dev_bootstrap() doesn't overwrite the last known
      error code with -ENOENT; when a firmware fails to load, we want to
      know the cause and not a generic error code.
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      cb5b756f
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: implement .reset_resume in USB subdriver · 1a5a73c0
      Inaky Perez-Gonzalez authored
      Current driver didn't implement the .reset_resume method. The i2400m
      normally always reset on a comeback from system standby/hibernation.
      
      This requires previously applied commits to cache the firmware image
      file.
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      1a5a73c0
    • 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
    • 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>
      7329012e
    • 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>
      f8fc3295
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: on firmware upload, select BCF header that matches device's request · 10607c86
      Inaky Perez-Gonzalez authored
      Devices based on the i2400m emit a "barker" (32 bit unsigned) when
      they boot. This barker is used to select, in the firmware file image,
      which header should be used to process the rest of the file.
      
      This commit implements said support, completing the series started by
      previous commits.
      
      We modify the i2400m_fw_dnload() firmware loading path by adding a
      call to i2400m_bcf_hdr_find() [new function], in which the right BCF
      header [as listed in i2400m->fw_hdrs by i2400m_fw_check()] is
      located. Then this header is fed to i2400m_dnload_init() and
      i2400m_dnload_finalize().
      
      The changes to i2400m_dnload_finalize() are smaller than they look;
      they add the bcf_hdr argument and use that instead of bcf. Likewise in
      i2400m_dnload_init().
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      10607c86
    • 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: verify firmware format version is known · fabce1a4
      Inaky Perez-Gonzalez authored
      Make sure the bootloading code checks that the format of the file is
      understood (major version match). This also fixes a dumb typo in
      extracting the major version field.
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      fabce1a4
    • 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
      option.
      
      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>
      923d708f
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: retry loading firmware files in sequence · ebc5f62b
      Inaky Perez-Gonzalez authored
      The i2400m firmware loader is given a list of firmware files to try to
      load by the probe() function (which can be different based on the
      device's model / generation).
      
      Current code didn't attempt to load, check and try to boot with each
      file, but just to try to load if off disk. This is limiting in some
      cases, where we might want to try to load a firmware and if it fails
      to load onto the device, just fall back to another one.
      
      This changes the behaviour so all files are tried for being loaded
      from disk, checked and uploaded to the device until one suceeds in
      bringing the device up.
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      ebc5f62b
    • 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
    • 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>
      32742e61
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: workaround not-so-working %zd printf format · 59bdc4be
      Inaky Perez-Gonzalez authored
      The kernel's %zd modifier does not really work. Use %ld (has to cast
      ssize_t to long).
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      59bdc4be
    • 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>
      4c2b1a11
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: add missing debug submodule definition · 4dc1bf07
      Inaky Perez-Gonzalez authored
      The i2400m driver was missing the definition for the sysfs debug
      level, which is declared in debug-levels.h.
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      4dc1bf07
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: during probe, call sdio_disable at most once · c77ca950
      Inaky Perez-Gonzalez authored
      In the Intel Wireless Multicomm 3200, the initialization is
      orchestrated by a component called Top. This component also monitors
      how many times a function is reset (via sdio_disable) to detect
      possible issues and will reset the whole multifunction device if any
      function triggers a maximum reset level.
      
      During WiMAX's probe, the driver needs to wait for Top to come up
      before it can enable the WiMAX function. If it cannot, it will return
      -ENODEV and the Top driver will rescan the SDIO bus once done
      loading.
      
      Currently, the WiMAX SDIO probe routine was trying a few times before
      returning -ENODEV, and this was triggering Top's too-many-resets
      detector. This is, in any case, unnecessary because the Top driver will
      force the bus rescan when the functions can be probed successfully.
      
      Added then a maxtries argument to i2400ms_enable_func() and set it to
      1 when calling from probe. We want to reuse this function instead of
      flat calling out sdio_enable_func() to take advantage of hardware
      quirk workarounds.
      Reported-by: default avatarCindy H Kao <cindy.h.kao@intel.com>
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      c77ca950
    • Cindy H Kao's avatar
      wimax/i2400m: don't write to memory allocated by request_firmware() · 8d8fe198
      Cindy H Kao authored
      In kernel 2.6.31, the firmware requested to ram could be marked
      with read only attribute, and we can't write any thing directly
      to the memory when setting up the last JUMP brh cmd.
      
      Changed so that the scratch buffer is used.
      Signed-off-by: default avatarCindy H Kao <cindy.h.kao@intel.com>
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      8d8fe198
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: be smarter about copying command buffer to bm_cmd_buf · 77e1251a
      Inaky Perez-Gonzalez authored
      Because some underlying bus APIs (like USB) don't like data buffers in
      the stack or vmalloced areas, the i2400m driver provides a scratch
      buffer (i2400m->bm_cmd_buf) for said low-level drivers to copy command
      data to before passing it to said API. This is only used during boot
      mode.
      
      However, at some the code was copying the buffer even when the command
      was already specified in said buffer. This is ok, but it needs to be
      more careful. As thus, change so that:
      
      (a) the copy happens only if command buffer is not the scratch buffer
      
      (b) use memmove() in case there is overlapping
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      77e1251a
    • Cindy H Kao's avatar
      wimax/i2400m/sdio: clear the INTR status bit after reading size · 339ccc36
      Cindy H Kao authored
      In order to avoid issues during high-load traffic, the interrupt
      status register has to be cleared ONLY after the RX size is read.
      Signed-off-by: default avatarCindy H Kao <cindy.h.kao@intel.com>
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      339ccc36
    • Dirk Brandewie's avatar
      wimax/i2400m: USB driver uses a configurable endpoint map · 2093586d
      Dirk Brandewie authored
      Newer generations of the i2400m USB WiMAX device use a different
      endpoint map; in order to make it easy to support it, we make the
      endpoint-to-function mapeable instead of static.
      Signed-off-by: default avatarDirk Brandewie <dirk.j.brandewie@intel.com>
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      2093586d
    • Cindy H Kao's avatar
      wimax/iwmc3200: increase wait time before enable retry · 8bec9a5e
      Cindy H Kao authored
      When trying to enable the iwmc3200 WiMAX SDIO function, we loop
      waiting for the top controller to be up and running (at which point we
      can succesfully enable the function). Between each try we wait for
      I2400MS_INIT_SLEEP_INTERVAL ms.
      
      Integration tests have found the current value of 10ms to be too
      short; it was upped to 100ms to give more time to the top controller
      to be ready.
      Signed-off-by: default avatarCindy H Kao <cindy.h.kao@intel.com>
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      8bec9a5e
    • Cindy H Kao's avatar
      wimax/iwmc3200: don't disable the SDIO function if enable fails · 5c29e21d
      Cindy H Kao authored
      In the iwmc3200, disabling the WiMAX SDIO function when enable fails
      would possibly result in a device reset triggered by the iwmc3200's
      top controller since it monitors the bus reset activities from each
      SDIO function. In any case, the disable makes no sense; if the enable
      fails, it should not be disabled.
      
      Thus we remove the unecessary sdio_disable_func() in
      i2400ms_enable_function().
      Signed-off-by: default avatarCindy H Kao <cindy.h.kao@intel.com>
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      5c29e21d
    • Cindy H Kao's avatar
      wimax/iwmc3200: overwrite SDIO IOR timeout value to avoid platform hang · f2696fbd
      Cindy H Kao authored
      The default SDIO IOE wait timeout returned from iwmc3200-wimax's CCCR
      is not efficient. This inefficiency will actually cause problems on
      Moorestown platforms (system hang).
      
      This is a sillicon bug that requires a software patch to by
      overwritting func->enable_timeout. The new value I2400MS_IOR_TIMEOUT
      is recommended and verified from the system integration results.
      
      Future sillicon releases will have this default value corrected in the
      future.
      Signed-off-by: default avatarCindy H Kao <cindy.h.kao@intel.com>
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      f2696fbd