1. 16 Apr, 2009 23 commits
    • Herton Ronaldo Krzesinski's avatar
      rt2x00: prevent double kfree when failing to register hardware · f05faa31
      Herton Ronaldo Krzesinski authored
      In a scenario where there isn't any firmware available, we will have a
      double kfree of rt2x00dev->spec.channels_info when ieee80211_register_hw
      returns an error status inside rt2x00lib_probe_hw.
      
      The problem is that if ieee80211_register_hw fails, we call
      rt2x00lib_remove_hw twice:
      * first inside rt2x00lib_probe_hw upon failure of ieee80211_register_hw
      * error status is returned to rt2x00lib_probe_dev, which then sees it and
        calls in this case rt2x00lib_remove_dev that will again run
        rt2x00lib_remove_hw
      
      Prevent this avoiding calling rt2x00lib_remove_hw inside
      rt2x00lib_probe_hw
      
      Problem was detected with CONFIG_DEBUG_PAGEALLOC=y, CONFIG_SLUB_DEBUG=y,
      CONFIG_SLUB_DEBUG_ON=y, that dumps this with no firmware available:
      
      rt61pci 0000:00:07.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
      wmaster0 (rt61pci): not using net_device_ops yet
      phy0: Selected rate control algorithm 'pid'
      phy0: Failed to initialize wep: -2
      phy0 -> rt2x00lib_probe_dev: Error - Failed to initialize hw.
      =============================================================================
      BUG kmalloc-128: Object already free
      -----------------------------------------------------------------------------
      
      INFO: Allocated in rt61pci_probe_hw+0x3e5/0x6e0 [rt61pci] age=340 cpu=0 pid=21
      INFO: Freed in rt2x00lib_remove_hw+0x59/0x70 [rt2x00lib] age=0 cpu=0 pid=21
      INFO: Slab 0xc13ac3e0 objects=23 used=10 fp=0xdd59f6e0 flags=0x400000c3
      INFO: Object 0xdd59f6e0 @offset=1760 fp=0xdd59f790
      
      Bytes b4 0xdd59f6d0:  15 00 00 00 b2 8a fb ff 5a 5a 5a 5a 5a 5a 5a 5a ....².ûÿZZZZZZZZ
        Object 0xdd59f6e0:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
        Object 0xdd59f6f0:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
        Object 0xdd59f700:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
        Object 0xdd59f710:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
        Object 0xdd59f720:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
        Object 0xdd59f730:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
        Object 0xdd59f740:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
        Object 0xdd59f750:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk¥
       Redzone 0xdd59f760:  bb bb bb bb                                     »»»»
       Padding 0xdd59f788:  5a 5a 5a 5a 5a 5a 5a 5a                         ZZZZZZZZ
      Pid: 21, comm: stage1 Not tainted 2.6.29.1-desktop-1.1mnb #1
      Call Trace:
       [<c01abbb3>] print_trailer+0xd3/0x120
       [<c01abd37>] object_err+0x37/0x50
       [<c01acf57>] __slab_free+0xe7/0x2f0
       [<c01ad1de>] kfree+0x7e/0xd0
       [<e0e4a239>] ? rt2x00lib_remove_hw+0x59/0x70 [rt2x00lib]
       [<e0e4a239>] ? rt2x00lib_remove_hw+0x59/0x70 [rt2x00lib]
       [<e0e4a239>] rt2x00lib_remove_hw+0x59/0x70 [rt2x00lib]
       [<e0e4acc7>] rt2x00lib_remove_dev+0x37/0x50 [rt2x00lib]
       [<e0e4b087>] rt2x00lib_probe_dev+0x1a7/0x3b0 [rt2x00lib]
       [<e0eb288f>] rt2x00pci_probe+0xdf/0x1ee [rt2x00pci]
       [<c026b9ee>] local_pci_probe+0xe/0x10
       [<c026c750>] pci_device_probe+0x60/0x80
       [<c02d5c2a>] driver_probe_device+0x9a/0x2e0
       [<c02d5ef9>] __driver_attach+0x89/0x90
       [<c02d541b>] bus_for_each_dev+0x4b/0x70
       [<c026c690>] ? pci_device_remove+0x0/0x40
       [<c02d59d9>] driver_attach+0x19/0x20
       [<c02d5e70>] ? __driver_attach+0x0/0x90
       [<c02d4cef>] bus_add_driver+0x1cf/0x2a0
       [<c026c690>] ? pci_device_remove+0x0/0x40
       [<c02d60c9>] driver_register+0x69/0x140
       [<c026c9b0>] __pci_register_driver+0x40/0x80
       [<e0ecc000>] ? rt61pci_init+0x0/0x19 [rt61pci]
       [<e0ecc017>] rt61pci_init+0x17/0x19 [rt61pci]
       [<c0101116>] do_one_initcall+0x26/0x1c0
       [<c01ab90c>] ? slab_pad_check+0x3c/0x120
       [<c01ab90c>] ? slab_pad_check+0x3c/0x120
       [<c01ac8da>] ? check_object+0xda/0x210
       [<c01b0026>] ? percpu_free+0x46/0x50
       [<c01ad09e>] ? __slab_free+0x22e/0x2f0
       [<c01b0026>] ? percpu_free+0x46/0x50
       [<c01b0026>] ? percpu_free+0x46/0x50
       [<c01b0026>] ? percpu_free+0x46/0x50
       [<c01687ec>] ? stop_machine_destroy+0x3c/0x40
       [<c015e515>] ? load_module+0xa5/0x1c50
       [<e0ec5000>] ? rt61pci_eepromregister_read+0x0/0x40 [rt61pci]
       [<e0eb2000>] ? rt2x00pci_write_tx_data+0x0/0x90 [rt2x00pci]
       [<c03ac2fb>] ? mutex_lock+0xb/0x20
       [<c03ac2fb>] ? mutex_lock+0xb/0x20
       [<c017ad16>] ? tracepoint_update_probe_range+0x76/0xa0
       [<c017ad6f>] ? tracepoint_module_notify+0x2f/0x40
       [<c03b02ed>] ? notifier_call_chain+0x2d/0x70
       [<c014f0ed>] ? __blocking_notifier_call_chain+0x4d/0x60
       [<c014f11a>] ? blocking_notifier_call_chain+0x1a/0x20
       [<c0160156>] sys_init_module+0x96/0x1d0
       [<c019dad6>] ? sys_munmap+0x46/0x60
       [<c0105546>] syscall_call+0x7/0xb
      FIX kmalloc-128: Object at 0xdd59f6e0 not freed
      rt61pci 0000:00:07.0: PCI INT A disabled
      rt61pci: probe of 0000:00:07.0 failed with error -2
      Signed-off-by: default avatarHerton Ronaldo Krzesinski <herton@mandriva.com.br>
      Acked-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f05faa31
    • Johannes Berg's avatar
      fix iwl3945 registration regression · d60cc91a
      Johannes Berg authored
      I forgot that iwl3945 registration is separate from iwlagn.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d60cc91a
    • Michael Buesch's avatar
      mac80211: quiet beacon loss messages · a860402d
      Michael Buesch authored
      On Sunday 05 April 2009 11:29:38 Michael Buesch wrote:
      > On Sunday 05 April 2009 11:23:59 Jaswinder Singh Rajput wrote:
      > > With latest linus tree I am getting, .config file attached:
      > >
      > > [   22.895051] r8169: eth0: link down
      > > [   22.897564] ADDRCONF(NETDEV_UP): eth0: link is not ready
      > > [   22.928047] ADDRCONF(NETDEV_UP): wlan0: link is not ready
      > > [   22.982292] libvirtd used greatest stack depth: 4200 bytes left
      > > [   63.709879] wlan0: authenticate with AP 00:11:95:9e:df:f6
      > > [   63.712096] wlan0: authenticated
      > > [   63.712127] wlan0: associate with AP 00:11:95:9e:df:f6
      > > [   63.726831] wlan0: RX AssocResp from 00:11:95:9e:df:f6 (capab=0x471 status=0 aid=1)
      > > [   63.726855] wlan0: associated
      > > [   63.730093] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
      > > [   74.296087] wlan0: no IPv6 routers present
      > > [   79.349044] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  119.358200] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  179.354292] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  259.366044] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  359.348292] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  361.953459] packagekitd used greatest stack depth: 4160 bytes left
      > > [  478.824258] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  598.813343] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  718.817292] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  838.824567] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  958.815402] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1078.848434] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1198.822913] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1318.824931] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1438.814157] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1558.827336] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1678.823011] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1798.830589] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1918.828044] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 2038.827224] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 2116.517152] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 2158.840243] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 2278.827427] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      >
      >
      > I think this message should only show if CONFIG_MAC80211_VERBOSE_DEBUG is set.
      > It's kind of expected that we lose a beacon once in a while, so we shouldn't print
      > verbose messages to the kernel log (even if they are KERN_DEBUG).
      >
      > And besides that, I think one can easily remotely trigger this message and flood the logs.
      > So it should probably _also_ be ratelimited.
      
      Something like this:
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      a860402d
    • Michael Buesch's avatar
      b43: Do radio lock assertion in software · 591f3dc2
      Michael Buesch authored
      The assertion of the lock-bit in the hardware register is unreliable,
      because there are devices with quirks that will randomly set the bit.
      
      Do the assertion in software, only.
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      591f3dc2
    • Ivo van Doorn's avatar
      rt2x00: Add rt73usb USB IDs · 6aabd4c4
      Ivo van Doorn authored
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      6aabd4c4
    • Christian Lamparter's avatar
    • Christian Lamparter's avatar
      ar9170: add Cace Airpcap NX usb_id · 4fc298b8
      Christian Lamparter authored
      This patch adds a new device to ar9170usb.
      Reported-by: default avatarMike Kershaw/Dragorn <dragorn@kismetwireless.net>
      Signed-off-by: default avatarChristian Lamparter <chunkeey@web.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4fc298b8
    • Dan Williams's avatar
      airo: queue SIOCSIWAUTH-requested auth mode change for next commit · 011f5c5b
      Dan Williams authored
      Code was clearly wrong, plus callers expect the mode change to happen as
      soon as possible, not dropped on the floor until the next time some
      other config value changes and a commit happens.
      Signed-off-by: default avatarDan Williams <dcbw@redhat.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      011f5c5b
    • Jamie Lentin's avatar
      at76c50x-usb: Add device ID for OQO model 01+ · 02a9a392
      Jamie Lentin authored
      Add USB device ID for OQO 01+'s internal wireless LAN
      
      An OQO employee mentions the chip's true identity here:-
          ftp://ftp.oqo.com/unsupported/linux/OQOLinux.htmlSigned-off-by: default avatarJamie Lentin <jm@lentin.co.uk>
      Acked-by: default avatarKalle Valo <kalle.valo@iki.fi>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      02a9a392
    • Philip Rakity's avatar
      libertas: don't leak skb on receive error · f54930f3
      Philip Rakity authored
      Don't lead memory when receive errors
      Signed-off-by: default avatarPhilip Rakity <prakity@yahoo.com>
      Acked-by: default avatarDan Williams <dcbw@redhat.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f54930f3
    • Johannes Berg's avatar
      mac80211: correct wext transmit power handler · 47afbaf5
      Johannes Berg authored
      Wext makes no assumptions about the contents of
      data->txpower.fixed and data->txpower.value when
      data->txpower.disabled is set, so do not update
      the user-requested power level while disabling.
      
      Also, when wext configures a really _fixed_ power
      output [1], we should reject it instead of limiting it
      to the regulatory constraint. If the user wants to set
      a _limit_ [2] then we should honour that.
      
      [1] iwconfig wlan0 txpower 20dBm fixed
      [2] iwconfig wlan0 txpower 10dBm
      
      This fixes
      http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1942Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      47afbaf5
    • Pavel Roskin's avatar
    • Masakazu Mokuno's avatar
      net/ps3: Fix wireless AP connect error handling · c6dbe17f
      Masakazu Mokuno authored
      This patch fixes the bug that the driver tries to continue to
      connect(associate) to AP even if gelic_wl_do_{wpa,wep}_setup() fails,
      Signed-off-by: default avatarMasakazu Mokuno <mokuno@sm.sony.co.jp>
      Signed-off-by: default avatarGeoff Levand <geoffrey.levand@am.sony.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      c6dbe17f
    • Christian Lamparter's avatar
      p54spi: fix locking warning in p54spi_op_tx · 731c6531
      Christian Lamparter authored
      This patch fixes the following waring:
      > ------------[ cut here ]------------
      >WARNING: at kernel/softirq.c:138 local_bh_enable+0x54/0xbc()
      >Modules linked in: p54spi
      >[<c0034ff8>] (dump_stack+0x0/0x14)
      >[<c005b1a4>] (warn_on_slowpath+0x0/0x68)
      >[<c00604c8>] (local_bh_enable+0x0/0xbc)
      >[<bf000000>] (p54spi_op_tx+0x0/0x4c [p54spi])
      >[<c01a4d34>] (p54_sta_unlock+0x0/0x78)
      
      p54spi_op_tx needs to be called from different locking contexts.
      Therefore we have to protect the linked list with irqsave spinlocks.
      Reported-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarChristian Lamparter <chunkeey@web.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      731c6531
    • Christian Lamparter's avatar
      p54: replace MAC80211_LEDS with P54_LEDS in p54.h · 54082819
      Christian Lamparter authored
      I'm very sorry, as this change belongs to the other patch:
      "[PATCH] p54: fix SoftLED compile dependencies".
      however I must have somehow lost "git add" for that file.
      Signed-off-by: default avatarChristian Lamparter <chunkeey@web.de>
      Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      54082819
    • Michael Buesch's avatar
      b43: Refresh RX poison on buffer recycling · cf68636a
      Michael Buesch authored
      The RX buffer poison needs to be refreshed, if we recycle an RX buffer,
      because it might be (partially) overwritten by some DMA operations.
      
      Cc: stable@kernel.org
      Cc: Francesco Gringoli <francesco.gringoli@ing.unibs.it>
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      cf68636a
    • Michael Buesch's avatar
      b43: Poison RX buffers · ec9a1d8c
      Michael Buesch authored
      This patch adds poisoning and sanity checking to the RX DMA buffers.
      This is used for protection against buggy hardware/firmware that raises
      RX interrupts without doing an actual DMA transfer.
      
      This mechanism protects against rare "bad packets" (due to uninitialized skb data)
      and rare kernel crashes due to uninitialized RX headers.
      
      The poison is selected to not match on valid frames and to be cheap for checking.
      
      The poison check mechanism _might_ trigger incorrectly, if we are voluntarily
      receiving frames with bad PLCP headers. However, this is nonfatal, because the
      chance of such a match is basically zero and in case it happens it just results
      in dropping the packet.
      Bad-PLCP RX defaults to off, and you should leave it off unless you want to listen
      to the latest news broadcasted by your microwave oven.
      
      This patch also moves the initialization of the RX-header "length" field in front of
      the mapping of the DMA buffer. The CPU should not touch the buffer after we mapped it.
      
      Cc: stable@kernel.org
      Reported-by: default avatarFrancesco Gringoli <francesco.gringoli@ing.unibs.it>
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ec9a1d8c
    • Vasanthakumar Thiagarajan's avatar
      mac80211: Fix bug in getting rx status for frames pending in reorder buffer · b3631286
      Vasanthakumar Thiagarajan authored
      Currently rx status for frames which are completed from reorder buffer
      is taken from it's cb area which is not always right, cb is not holding
      the rx status when driver uses mac80211's non-irq rx handler to pass it's
      received frames. This results in dropping almost all frames from reorder
      buffer when security is enabled by doing double decryption (first in hw,
      second in sw because of wrong rx status). This patch copies rx status into
      cb area before the frame is put into reorder buffer. After this patch,
      there is a significant improvement in throughput with ath9k + WPA2(AES).
      Signed-off-by: default avatarVasanthakumar Thiagarajan <vasanth@atheros.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b3631286
    • Luis R. Rodriguez's avatar
      cfg80211: fix NULL pointer deference in reg_device_remove() · 0ad8acaf
      Luis R. Rodriguez authored
      We won't ever get here as regulatory_hint_core() can only fail
      on -ENOMEM and in that case we don't initialize cfg80211 but this is
      technically correct code.
      
      This is actually good for stable, where we don't check for -ENOMEM
      failure on __regulatory_hint()'s failure.
      
      Cc: stable@kernel.org
      Reported-by: default avatarQuentin Armitage <Quentin@armitage.org.uk>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0ad8acaf
    • Atsushi Nemoto's avatar
      phylib: Fix delay argument of schedule_delayed_work · 3664090e
      Atsushi Nemoto authored
      The commit a390d1f3 ("phylib: convert state_queue work to
      delayed_work") missed converting 'expires' value to 'delay' value.
      Signed-off-by: default avatarAtsushi Nemoto <anemo@mba.ocn.ne.jp>
      Acked-by: default avatarMarcin Slusarz <marcin.slusarz@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3664090e
    • Rafael J. Wysocki's avatar
      NET/ixgbe: Fix powering off during shutdown · 9d8d05ae
      Rafael J. Wysocki authored
      Prevent ixgbe from putting the adapter into D3 during shutdown except when
      we're going to power off the system, since doing that may generally cause
      problems with kexec to happen (such problems were observed for igb and
      forcedeth).  For this purpose seperate ixgbe_shutdown() from ixgbe_suspend()
      and use the appropriate PCI PM callbacks in both of them.
      Signed-off-by: default avatar"Rafael J. Wysocki" <rjw@sisk.pl>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9d8d05ae
    • Rafael J. Wysocki's avatar
      NET/e1000e: Fix powering off during shutdown · 4f9de721
      Rafael J. Wysocki authored
      Prevent e1000e from putting the adapter into D3 during shutdown except when
      we're going to power off the system, since doing that may generally cause
      problems with kexec to happen (such problems were observed for igb and
      forcedeth).  For this purpose seperate e1000e_shutdown() from e1000e_suspend()
      and use the appropriate PCI PM callbacks in both of them.
      Signed-off-by: default avatar"Rafael J. Wysocki" <rjw@sisk.pl>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4f9de721
    • Rafael J. Wysocki's avatar
      NET/e1000: Fix powering off during shutdown · b43fcd7d
      Rafael J. Wysocki authored
      Prevent e1000 from putting the adapter into D3 during shutdown except when
      we're going to power off the system, since doing that may generally cause
      problems with kexec to happen (such problems were observed for igb and
      forcedeth).  For this purpose seperate e1000_shutdown() from e1000_suspend()
      and use the appropriate PCI PM callbacks in both of them.
      Signed-off-by: default avatar"Rafael J. Wysocki" <rjw@sisk.pl>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b43fcd7d
  2. 15 Apr, 2009 13 commits
  3. 14 Apr, 2009 4 commits