Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 05 12月, 2008 3 次提交
  3. 04 12月, 2008 2 次提交
  5. 03 12月, 2008 1 次提交
    • M
      bnx2: Add workaround to handle missed MSI. · efba0180
      由 Michael Chan 提交于 
      The bnx2 chips do not support per MSI vector masking.  On 5706/5708, new MSI
address/data are stored only when the MSI enable bit is toggled.  As a result,
SMP affinity no longer works in the latest kernel.  A more serious problem is
that the driver will no longer receive interrupts when the MSI receiving CPU
goes offline.

The workaround in this patch only addresses the problem of CPU going offline.
When that happens, the driver's timer function will detect that it is making
no forward progress on pending interrupt events and will recover from it.

Eric Dumazet reported the problem.

We also found that if an interrupt is internally asserted while MSI and INTA
are disabled, the chip will end up in the same state after MSI is re-enabled.
The same workaround is needed for this problem. 
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Tested-by: NEric Dumazet <dada1@cosmosbay.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      efba0180
  7. 01 12月, 2008 4 次提交
  9. 29 11月, 2008 2 次提交
  11. 27 11月, 2008 1 次提交
  13. 26 11月, 2008 7 次提交
  15. 25 11月, 2008 1 次提交
  17. 24 11月, 2008 2 次提交
  19. 22 11月, 2008 2 次提交
    • R
      net/hp-plus: fix link errors · 38ae07e4
      由 Randy Dunlap 提交于 
      Fix hp-plus driver link errors.
Builds as loadable module and kernel image driver.
All drivers that use 8390.o or 8390p.o that will build on
i386 with MCA/PCI/EISA/ISA were built successfully both
=m and =y.

drivers/built-in.o: In function `hpp_open':
hp-plus.c:(.text+0xac06c): undefined reference to `eip_interrupt'
hp-plus.c:(.text+0xac0d7): undefined reference to `eip_open'
drivers/built-in.o: In function `hpp_close':
hp-plus.c:(.text+0xac1bb): undefined reference to `eip_close'
drivers/built-in.o: In function `hpp_probe1':
hp-plus.c:(.init.text+0xa98a): undefined reference to `NS8390p_init'
drivers/built-in.o: In function `hp_plus_probe':
(.init.text+0xa9fe): undefined reference to `__alloc_eip_netdev'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      38ae07e4
    • C
      axnet_cs / pcnet_cs: moving PCMCIA_DEVICE_PROD_ID for Netgear FA411 · 208fbec5
      由 Cord Walter 提交于 
      Hi,

after noticing that my Netgear FA411 (PCMCIA-NIC) [1] stopped working with
the release of the 2.6.25 kernel (sidux-version), I checked the
respective driver sources and noticed that the pcnet_cs driver bailed
out with "use axnet_cs instead" for the Netgear FA411, but axnet_cs
doesn't claim this ID.

I compiled a kernel with the PCMCIA-ID for the netgear card moved to
axnet_cs from pcnet_cs which worked. I then contacted sidux-kernel
maintainer Stefan Lippers-Hollmann who turned the info into this patch
and integrated it into the kernel:

<http://svn.berlios.de/svnroot/repos/fullstory/linux-sidux-2.6/trunk/debian/patches/features/2.6.27.4_PCMCIA_move-PCMCIA-ID-for-Netgear-FA411-from-pcnet_cs-to-axnet_cs.patch>

This works for me and AFAIK there were no reports of any breakage for
other devices on sidux-support.

This looks like a trivial patch, but since I have very limited
experience with kernel modifications  I might be woefully wrong there.
But if there are no side effects of this patch, is it possible to get it
into the official kernel?

I can provide more detailed information on the affected hardware if
necessary.

-cord

[1]
Socket 1 Device 0:      [axnet_cs]              (bus ID: 1.0)
        Configuration:  state: on
        Product Name:   NETGEAR FA411 Fast Ethernet
        Identification: manf_id: 0x0149 card_id: 0x0411
                        function: 6 (network)
                        prod_id(1): "NETGEAR" (0x9aa79dc3)
                        prod_id(2): "FA411" (0x40fad875)
                        prod_id(3): "Fast Ethernet" (0xb4be14e3)
                        prod_id(4): --- (---)

From: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Date: Sat, 1 Nov 2008 23:53:04 +0000
Subject: PCMCIA: move PCMCIA ID for Netgear FA411 from pcnet_cs to axnet_cs:

Since kernel 2.6.25, commit 61da96be
(pcnet_cs: if AX88190-based card, printk "use axnet_cs instead" message.),
pcnet_cs bails out with "use axnet_cs instead" for the Netgear FA411, but
axnet_cs doesn't claim this ID.

Socket 1 Device 0:      [axnet_cs]              (bus ID: 1.0)
        Configuration:  state: on
        Product Name:   NETGEAR FA411 Fast Ethernet
        Identification: manf_id: 0x0149 card_id: 0x0411
                        function: 6 (network)
                        prod_id(1): "NETGEAR" (0x9aa79dc3)
                        prod_id(2): "FA411" (0x40fad875)
                        prod_id(3): "Fast Ethernet" (0xb4be14e3)
                        prod_id(4): --- (---)

Cc: stable <stable@kernel.org> [2.6.25, 2.6.26, 2.6.27]
Signed-off-by: NStefan Lippers-Hollmann <s.l-h@gmx.de>
Signed-off-by: NCord Walter <qord@cwalter.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      208fbec5
  21. 21 11月, 2008 1 次提交
  23. 20 11月, 2008 10 次提交
  25. 19 11月, 2008 3 次提交
    • J
      iwlagn: fix RX skb alignment · 4018517a
      由 Johannes Berg 提交于 
      So I dug deeper into the DMA problems I had with iwlagn and a kind soul
helped me in that he said something about pci-e alignment and mentioned
the iwl_rx_allocate function to check for crossing 4KB boundaries. Since
there's 8KB A-MPDU support, crossing 4k boundaries didn't seem like
something the device would fail with, but when I looked into the
function for a minute anyway I stumbled over this little gem:

	BUG_ON(rxb->dma_addr & (~DMA_BIT_MASK(36) & 0xff));

Clearly, that is a totally bogus check, one would hope the compiler
removes it entirely. (Think about it)

After fixing it, I obviously ran into it, nothing guarantees the
alignment the way you want it,  because of the way skbs and their
headroom are allocated. I won't explain that here nor double-check that
I'm right, that goes beyond what most of the CC'ed people care about.

So then I came up with the patch below, and so far my system has
survived minutes with 64K pages, when it would previously fail in
seconds. And I haven't seen a single instance of the TX bug either. But
when you see the patch it'll be pretty obvious to you why.

This should fix the following reported kernel bugs:

http://bugzilla.kernel.org/show_bug.cgi?id=11596
http://bugzilla.kernel.org/show_bug.cgi?id=11393
http://bugzilla.kernel.org/show_bug.cgi?id=11983

I haven't checked if there are any elsewhere, but I suppose RHBZ will
have a few instances too...

I'd like to ask anyone who is CC'ed (those are people I know ran into
the bug) to try this patch.

I am convinced that this patch is correct in spirit, but I haven't
understood why, for example, there are so many unmap calls. I'm not
entirely convinced that this is the only bug leading to the TX reply
errors.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4018517a
    • J
      mac80211: remove ieee80211_notify_mac · 8e3bad65
      由 Johannes Berg 提交于 
      Before ieee80211_notify_mac() was added, it was presented with the
use case of using it to tell mac80211 that the association may
have been lost because the firmware crashed/reset.

Since then, it has also been used by iwlwifi to (slightly) speed
up re-association after resume, a workaround around the fact that
mac80211 has no suspend/resume handling yet. It is also not used
by any other drivers, so clearly it cannot be necessary for "good
enough" suspend/resume.

Unfortunately, the callback suffers from a severe problem: It only
works for station mode. If suspend/resume happens while in IBSS or
any other mode (but station), then the callback is pointless.

Recently, it has created a number of locking issues, first because
it required rtnl locking rather than RCU due to calling sleeping
functions within the critical section, and now because it's called
by iwlwifi from the mac80211 workqueue that may not use the rtnl
because it is flushed under rtnl.
(cf. http://bugzilla.kernel.org/show_bug.cgi?id=12046)

I think, therefore, that we should take a step back, remove it
entirely for now and add the small feature it provided properly.
For suspend and resume we will need to introduce new hooks, and for
the case where the firmware was reset the driver will probably
simply just pretend it has done a suspend/resume cycle to get
mac80211 to reprogram the hardware completely, not just try to
connect to the current AP again in station mode. When doing so, we
will need to take into account locking issues and possibly defer
to schedule_work from within mac80211 for the resume operation,
while the suspend operation must be done directly.

Proper suspend/resume should also not necessarily try to reconnect
to the current AP, the time spent in suspend may have been short
enough to not be disconnected from the AP, mac80211 will detect
that the AP went out of range quickly if it did, and if the
association is lost then the AP will disassoc as soon as a data
frame is sent. We might also take into account WWOL then, and
have mac80211 program the hardware into such a mode where it is
available and requested.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8e3bad65
    • J
      libertas_tf: fix skb tail pointer · 9b44fb89
      由 Johannes Berg 提交于 
      skb->tail can't be meant here because it's not the same across 32/64 bit
compilations. This means there's no way the current driver can work on
64-bit architectures.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Cc: stable@kernel.org [2.6.27]
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9b44fb89
  27. 17 11月, 2008 1 次提交