Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 20 11月, 2008 4 次提交
  3. 17 11月, 2008 2 次提交
  5. 16 11月, 2008 10 次提交
  7. 15 11月, 2008 7 次提交
  9. 14 11月, 2008 1 次提交
  11. 13 11月, 2008 6 次提交
    • N
      bnx2: fix poll_controller to pass proper structures and check all rx queues · b2af2c1d
      由 Neil Horman 提交于 
      Fix bnx2 so that netpoll works properly.  Specifically:

1) Fix parameters to bnx2_interrupt to be a struct bnx2_napi rather than a
struct net_device

2) Fix poll_controller method to check every queue in the rx case so frames
aren't missed
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b2af2c1d
    • D
      niu: Fix readq implementation when architecture does not provide one. · e23a59e1
      由 David S. Miller 提交于 
      This fixes a TX hang reported by Jesper Dangaard Brouer.

When an architecutre cannot provide a fully functional
64-bit atomic readq/writeq, the driver must implement
it's own.  This is because only the driver can say whether
doing something like using two 32-bit reads to implement
the full 64-bit read will actually work properly.

In particular one of the issues is whether the top 32-bits
or the bottom 32-bits of the 64-bit register should be read
first.  There could be side effects, and in fact that is
exactly the problem here.

The TX_CS register has counters in the upper 32-bits and
state bits in the lower 32-bits.  A read clears the state
bits.

We would read the counter half before the state bit half.
That first read would clear the state bits, and then the
driver thinks that no interrupts are pending because the
interrupt indication state bits are seen clear every time.

Fix this by reading the bottom half before the upper half.
Tested-by: NJesper Dangaard Brouer <jdb@comx.dk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e23a59e1
    • J
      hostap: pad the skb->cb usage in lieu of a proper fix · f7cd1686
      由 Johannes Berg 提交于 
      Like mac80211 did, this driver makes 'clever' use of skb->cb to pass
information along with an skb as it is requeued from the virtual device
to the physical wireless device.  Unfortunately, that trick no longer
works...

Unlike mac80211, code complexity and driver apathy makes this hack
the best option we have in the short run.  Hopefully someone will
eventually be motivated to code a proper fix before all the effected
hardware dies.

(Above text by me.  Johannes officially disavows all knowledge of this
hack. -- JWL)
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f7cd1686
    • B
      rtl8187 : support for Sitecom WL-168 0001 v4 · f3c76918
      由 Bob Jolliffe 提交于 
      the Sitecom 0001 v4 with product id 0x0df6:0028, uses Realtek's
RTL8187B and work fine with new 2.6.27 driver.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f3c76918
    • I
      rtl8187: Add Abocom USB ID · 8f7c41d4
      由 Ivan Kuten 提交于 
      Signed-off-by: NIvan Kuten <ivan.kuten@promwad.com>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8f7c41d4
    • S
      RDMA/cxgb3: Fix deadlock in iw_cxgb3 (hang when configuring interface) · b3e123cf
      由 Steve Wise 提交于 
      When the iw_cxgb3 module's cxgb3_client "add" func gets called by the
cxgb3 module, the iwarp driver ends up calling the ethtool ops
get_drvinfo function in cxgb3 to get the fw version and other info.
Currently the iwarp driver grabs the rtnl lock around this down call
to serialize.  As of 2.6.27 or so, things changed such that the rtnl
lock is held around the call to the netdev driver open function.  Also
the cxgb3_client "add" function doesn't get called if the device is
down.

So, if you load cxgb3, then load iw_cxgb3, then ifconfig up the
device, the iw_cxgb3 add func gets called with the rtnl_lock held.  If
you load cxgb3, ifconfig up the device, then load iw_cxgb3, the add
func gets called without the rtnl_lock held.  The former causes the
deadlock, the latter does not.

In addition, there are iw_cxgb3 sysfs handlers that also can call down
into cxgb3 to gather the fw and hw versions.  These can be called
concurrently on different processors and at any time.  Thus we need to
push this serialization down in the cxgb3 driver get_drvinfo func.

The fix is to remove rtnl lock usage, and use a per-device lock in cxgb3.
Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
Acked-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      b3e123cf
  13. 11 11月, 2008 5 次提交
    • D
      [netdrvr] smc911x: fix for driver resume (and compilation warning) · 347c8d83
      由 Dasgupta, Romit 提交于 
      I am trying out suspend, resume on an OMAP3 based board. What I see
during resume is that the SMC911x driver resume routing gets stuck
after trying to transmit the packet out of the controller. Some debug
messages below:

--> smc911x_drv_resume
eth0: --> smc911x_reset
eth0: smc911x_reset timeout waiting for PM restore
eth0: --> smc911x_enable
eth0: --> smc911x_phy_configure()
eth0: --> smc911x_phy_reset()
eth0: phy caps=0x782d
eth0: phy advertised caps=0x0de1
eth0: --> smc911x_phy_check_media
smc911x_phy_read: phyaddr=0x1, phyreg=0x01, phydata=0x7809
smc911x_phy_read: phyaddr=0x1, phyreg=0x01, phydata=0x7809
eth0: link down
Restarting tasks ... eth0: --> smc911x_hard_start_xmit
eth0: --> smc911x_hardware_send_pkt
eth0: --> smc911x_hard_start_xmit
eth0: --> smc911x_hardware_send_pkt
eth0: --> smc911x_hard_start_xmit
eth0: --> smc911x_hardware_send_pkt
nfs: server 172.24.190.217 not responding, still trying
nfs: server 172.24.190.217 not responding, still trying

The following change makes it work fine: (The change within
smc911x_drv_probe function was to get rid of a compilation warning).
Signed-off-by: NRomit Dasgupta <romit@ti.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      347c8d83
    • S
      RDMA/cxgb3: deadlock in iw_cxgb3 can cause hang when configuring interface. · cf3760da
      由 Steve Wise 提交于 
      When the iw_cxgb3 module's cxgb3_client "add" func gets called by the
cxgb3 module, the iwarp driver ends up calling the ethtool ops get_drvinfo
function in cxgb3 to get the fw version and other info.  Currently the
iwarp driver grabs the rtnl lock around this down call to serialize.
As of 2.6.27 or so, things changed such that the rtnl lock is held around
the call to the netdev driver open function.  Also the cxgb3_client "add"
function doesn't get called if the device is down.

So, if you load cxgb3, then load iw_cxgb3, then ifconfig up the device,
the iw_cxgb3 add func gets called with the rtnl_lock held.   If you
load cxgb3, ifconfig up the device, then load iw_cxgb3, the add func
gets called without the rtnl_lock held.  The former causes the deadlock,
the latter does not.

In addition, there are iw_cxgb3 sysfs handlers that also can call
down into cxgb3 to gather the fw and hw versions.  These can be called
concurrently on different processors and at any time.  Thus we need to
push this serialization down in the cxgb3 driver get_drvinfo func.

The fix is to remove rtnl lock usage, and use a per-device lock in cxgb3.
Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      cf3760da
    • D
      cxgb3 - Limit multiqueue setting to msi-x · f9ee3882
      由 Divy Le Ray 提交于 
      Allow multiqueue setting in MSI-X mode only
Signed-off-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      f9ee3882
    • D
      cxgb3 - eeprom read fixes · 9f64306b
      由 Divy Le Ray 提交于 
      Protect against invalid phy entries in the eeprom.
Extend eeprom access timeout.
Signed-off-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      9f64306b
    • B
      myri10ge: fix stop/go ordering even more · 8c2f5fa5
      由 Brice Goglin 提交于 
      The doorbell writes may be seen out of order by the firmware if they
are in WC memory since the tx spin(un)lock does not flush WC writes.
Hence if the "stop" is written on a different CPU than the "go", it
is possible that the stop will arrive after the go unless we add an
explicit memory barrier (and mmiowb() is not enough).

It fixes transmit hangs in multi tx queue mode.
Signed-off-by: NBrice Goglin <brice@myri.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      8c2f5fa5
  15. 07 11月, 2008 5 次提交