Skip to content
  1. May 10, 2012
  2. May 09, 2012
  3. May 08, 2012
  4. May 07, 2012
    • Bjørn Mork's avatar
      cdc_ether: Ignore bogus union descriptor for RNDIS devices · 6eddcb4c
      Bjørn Mork authored
      
      
      Some RNDIS devices include a bogus CDC Union descriptor pointing
      to non-existing interfaces.  The RNDIS code is already prepared
      to handle devices without a CDC Union descriptor by hardwiring
      the driver to use interfaces 0 and 1, which is correct for the
      devices with the bogus descriptor as well. So we can reuse the
      existing workaround.
      
      Cc: Markus Kolb <linux-201011@tower-net.de>
      Cc: Iker Salmón San Millán <shaola@esdebian.org>
      Cc: Jonathan Nieder <jrnieder@gmail.com>
      Cc: Oliver Neukum <oliver@neukum.org>
      Cc: 655387@bugs.debian.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6eddcb4c
    • Ariel Elior's avatar
      bnx2x: bug fix when loading after SAN boot · 24f06716
      Ariel Elior authored
      
      
      This is a bug fix for an "interface fails to load" issue.
      The issue occurs when bnx2x driver loads after UNDI driver was previously
      loaded over the chip. In such a scenario the UNDI driver is loaded and operates
      in the pre-boot kernel, within its own specific host memory address range.
      When the pre-boot stage is complete, the real kernel is loaded, in a new and
      distinct host memory address range. The transition from pre-boot stage to boot
      is asynchronous from UNDI point of view.
      
      A race condition occurs when UNDI driver triggers a DMAE transaction to valid
      host addresses in the pre-boot stage, when control is diverted to the real
      kernel. This results in access to illegal addresses by our HW as the addresses
      which were valid in the preboot stage are no longer considered valid.
      Specifically, the 'was_error' bit in the pci glue of our device is set. This
      causes all following pci transactions from chip to host to timeout (in
      accordance to the pci spec).
      
      Signed-off-by: default avatarAriel Elior <ariele@broadcom.com>
      Signed-off-by: default avatarEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      24f06716
  5. May 05, 2012
  6. May 04, 2012
  7. May 03, 2012