1. 20 2月, 2009 2 次提交
    • S
      smsc9420: fix another postfixed timeout · 9df8f4e3
      Steve Glendinning 提交于
      Roel Kluin recently fixed several instances where variables reach -1,
      but 0 is tested afterwards.  This patch fixes another, so the timeout
      will be correctly detected and a warning printed.
      Signed-off-by: NSteve Glendinning <steve.glendinning@smsc.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9df8f4e3
    • I
      wimax/i2400m: driver loads firmware v1.4 instead of v1.3 · 494ef10e
      Inaky Perez-Gonzalez 提交于
      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: NInaky Perez-Gonzalez <inaky@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      494ef10e
  2. 19 2月, 2009 8 次提交
  3. 18 2月, 2009 1 次提交
    • D
      net: Kill skb_truesize_check(), it only catches false-positives. · 92a0acce
      David S. Miller 提交于
      A long time ago we had bugs, primarily in TCP, where we would modify
      skb->truesize (for TSO queue collapsing) in ways which would corrupt
      the socket memory accounting.
      
      skb_truesize_check() was added in order to try and catch this error
      more systematically.
      
      However this debugging check has morphed into a Frankenstein of sorts
      and these days it does nothing other than catch false-positives.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      92a0acce
  4. 16 2月, 2009 1 次提交
    • T
      net: forcedeth: Fix wake-on-lan regression · 34edaa88
      Tobias Diedrich 提交于
      Commit f55c21fd ("forcedeth: call
      restore mac addr in nv_shutdown path"), which was introduced to fix
      the regression tracked at
      http://bugzilla.kernel.org/show_bug.cgi?id=11358 causes the
      wake-on-lan mac to be reversed in the shutdown path.  Apparently the
      forcedeth situation is rather messy in that the mac we need to
      writeback for a subsequent modprobe to work is exactly the reverse of
      what is needed for proper wake-on-lan.
      
      The following patch explains the situation in the comments and
      makes the call to nv_restore_mac_addr() conditional (only called if
      we are not really going for poweroff).
      
      Tobias Diedrich wrote:
      > Hmm, I had not tried WOL for some time.
      > With 2.6.29-rc3 is see the following behaviour:
      > 
      > State            WOL Behaviour
      > ------------------------------
      > shutdown         reversed MAC
      > disk/shutdown    reversed MAC
      > disk/platform    OK
      > 
      > Apparently nv_restore_mac_addr() restores the MAC in the wrong order
      > for WOL (at least for my PCI_DEVICE_ID_NVIDIA_NVENET_15).  platform
      > works, because the MAC is not touched in the nv_suspend() path.
      > 
      > A possible fix might be to only call nv_restore_mac_addr() if
      > system_state != SYSTEM_POWER_OFF.
      
      With the following patch:
      shutdown         OK
      disk/shutdown    OK
      disk/platform    OK
      kexec            OK
      Signed-off-by: NTobias Diedrich <ranma+kernel@tdiedrich.de>
      Tested-by: NPhilipp Matthias Hahn <pmhahn@titan.lahn.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      34edaa88
  5. 13 2月, 2009 21 次提交
  6. 12 2月, 2009 5 次提交
  7. 11 2月, 2009 2 次提交
    • M
      sunhme: Fix Quattro HME irq registration on proble failures · 7b7a799d
      Meelis Roos 提交于
      Currently, the sunhme driver installs SBus Quattro interrupt handler 
      when at least one HME card was initialized correctly and at least one 
      Quattro card is present. This breaks when a Quattro card fails 
      initialization for whatever reason - IRQ is registered and OOPS happens 
      when it fires.
      
      The solution, as suggested by David Miller, was to keep track which 
      cards of the Quattro bundles have been initialized, and request/free the 
      Quattro IRQ only when all four devices have been successfully 
      initialized.
      
      The patch only touches SBus initialization - PCI init already resets the 
      card pointer to NULL on init failure.
      
      The patch has been tested on Sun E3500 with SBus and PCI single HME 
      cards and one PCI Quattro HME card in a situation where any PCI card 
      failed init when the SBus routines tried to init them by mistake.
      
      Additionally it replaces Quattro request_irq panic with error return - 
      if this card fails to work, at least let the others work.
      
      Tested on E450 with PCI HME and PCI Quad HME.
      
      [ Minor coding style fixups -DaveM ]
      Signed-off-by: NMeelis Roos <mroos@linux.ee>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7b7a799d
    • M
      fore200: fix oops on failed firmware load · fcffd0d8
      Meelis Roos 提交于
      Fore 200 ATM driver fails to handle request_firmware failures and oopses 
      when no firmware file was found. Fix it by checking for the right return 
      values and propaganting the return value up.
      Signed-off-by: NMeelis Roos <mroos@linux.ee>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fcffd0d8