Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 23 7月, 2008 1 次提交
  3. 28 6月, 2008 1 次提交
  5. 25 6月, 2008 1 次提交
  7. 12 6月, 2008 1 次提交
    • D
      net: Eliminate flush_scheduled_work() calls while RTNL is held. · 4bb073c0
      由 David S. Miller 提交于 
      If the RTNL is held when we invoke flush_scheduled_work() we could
deadlock.  One such case is linkwatch, it is a work struct which tries
to grab the RTNL semaphore.

The most common case are net driver ->stop() methods.  The
simplest conversion is to instead use cancel_{delayed_}work_sync()
explicitly on the various work struct the driver uses.

This is an OK transformation because these work structs are doing
things like resetting the chip, restarting link negotiation, and so
forth.  And if we're bringing down the device, we're about to turn the
chip off and reset it anways.  So if we cancel a pending work event,
that's fine here.

Some drivers were working around this deadlock by using a msleep()
polling loop of some sort, and those cases are converted to instead
use cancel_{delayed_}work_sync() as well.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4bb073c0
  9. 31 5月, 2008 1 次提交
  11. 22 5月, 2008 1 次提交
    • A
      uli526x: add support for netpoll · 7fa0cba3
      由 Anton Vorontsov 提交于 
      This patch adds netpoll support for the uli526x ethernet driver --
simply call the interrupt handler for polling.

To do this without disable_irq()/enable_irq() pair we should fully
protect the handler. Luckily, it's already using irqsave spinlock,
the only unprotected place is interrupts re-enabling write. It was
safe to re-enable interrupts without holding the spinlock, but with
netpoll possibility now it doesn't seem so.

Patch was tested using netconsole and KGDBoE.
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      7fa0cba3
  13. 07 5月, 2008 2 次提交
    • A
      uli526x: fix endianness issues in the setup frame · e284e5c6
      由 Anton Vorontsov 提交于 
      This patch fixes uli526x driver's issues on a PowerPC boards: uli chip
is unable to receive the packets.

It appears that send_frame_filter prepares the setup frame in the
endianness unsafe manner. On a big endian machines we should shift
the address nibble by two bytes.
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      e284e5c6
    • A
      uli526x: initialize the hardware prior to requesting interrupts · afd8e399
      由 Anton Vorontsov 提交于 
      The firmware on MPC8610HPCD boards enables ULI ethernet and leaves it
in some funky state before booting Linux. For drivers, it's always good
idea to (re)initialize the hardware prior to requesting interrupts.

This patch fixes the following oops:

Oops: Kernel access of bad area, sig: 11 [#1]
MPC86xx HPCD
NIP: c0172820 LR: c017287c CTR: 00000000
[...]
NIP [c0172820] allocate_rx_buffer+0x2c/0xb0
LR [c017287c] allocate_rx_buffer+0x88/0xb0
Call Trace:
[df82bdc0] [c017287c] allocate_rx_buffer+0x88/0xb0 (unreliable)
[df82bde0] [c0173000] uli526x_interrupt+0xe4/0x49c
[df82be20] [c0045418] request_irq+0xf0/0x114
[df82be50] [c01737b0] uli526x_open+0x48/0x160
[df82be70] [c0201184] dev_open+0xb0/0xe8
[df82be80] [c0200104] dev_change_flags+0x90/0x1bc
[df82bea0] [c035fab0] ip_auto_config+0x214/0xef4
[df82bf60] [c03421c8] kernel_init+0xc4/0x2ac
[df82bff0] [c0010834] kernel_thread+0x44/0x60
Instruction dump:
4e800020 9421ffe0 7c0802a6 bfa10014 7c7e1b78 90010024 80030060 83e30054
2b80002f 419d0078 3fa0c039 48000058 <907f0010> 80630088 2f830000 419e0014
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      afd8e399
  15. 29 4月, 2008 1 次提交
  17. 17 4月, 2008 2 次提交
    • P
      [netdrvr] tulip: Better MWI workaround for 21143 rev 65 chip errata · 10c64620
      由 Peter Horton 提交于 
      This patch works around the MWI bug on the DC21143 rev 65 Tulip by
ensuring that the receive buffers don't end on a cache line boundary
(as documented in the errata).

This patch is required for the MIPS based Cobalt Qube/RaQ as
supporting the extra PCI commands seems to reduce the chance of a hard
lockup between the Tulip and the PCI bridge.
Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      10c64620
    • J
      [netdrvr] tulip/winbond-840: don't let tulip.h symbol stomp ours · 48dd59e3
      由 Jeff Garzik 提交于 
      winbond-840 shares tulip.h with the tulip driver, because they share
many (but not all) of the same register definitions.

This is useful for the register definitions, but not helpful when it
comes to symbols that are shared among the tulip driver's C modules,
but not meant to be shared outside that one driver.

Thus, PKT_BUF_SZ is a symbol internal to tulip, but it was intruding
upon a similar symbol in winbond-840's namespace.  This was not a
problem as long as the two symbols had the same value, but upcoming
patches result in differing symbol values.
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      48dd59e3
  19. 29 3月, 2008 1 次提交
    • G
      [netdrvr] tulip_read_eeprom fixes for BUG 4420 · 209261c0
      由 Grant Grundler 提交于 
      If "location" is > "addr_len" bits, the high bits of location would interfere
with the READ_CMD sent to the eeprom controller.

A patch was submitted to bug:
    http://bugzilla.kernel.org/show_bug.cgi?id=4420

which simply truncated the "location", read whatever was in "location
modulo addr_len", and returned that value. That avoids confusing the
eeprom but seems like the wrong solution to me.

Correct would be to not read beyond "1 << addr_len" address of the eeprom.
I am submitting two changes to implement this:
1) tulip_read_eeprom will return zero (since we can't return -EINVAL)
   if this is attempted (defensive programming).
2) In tulip_core.c, fix the tulip_read_eeprom caller so they don't
   iterate past addr_len bits and make sure the entire tp->eeprom[]
   array is cleared.

I konw we don't strictly need both. I would prefer both in the tree
since it documents the issue and provides a second "defense" from
the bug from creeping back in.
Signed-off-by: NGrant Grundler <grundler@parisc-linux.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      209261c0
  21. 17 3月, 2008 2 次提交
  23. 05 3月, 2008 1 次提交
  25. 24 2月, 2008 1 次提交
  27. 06 2月, 2008 1 次提交
  29. 29 1月, 2008 2 次提交
  31. 23 1月, 2008 1 次提交
    • D
      [TULIP] DMFE: Fix SROM parsing regression. · 4c93566e
      由 David S. Miller 提交于 
      Changeset 16b110c3 (dmfe warning fix)
bothed up the offsets read from the SROM so that it doesn't read the
same datums it used to.

The change made transformations like turning:

	"srom + 34"

into

	"(__le32 *)srom + 34/4"

which doesn't work because 4 does not divide evenly
into 34 so we're using a different pointer offset
than in the original code.

I've changed theses cases in dmfe_parse_srom() to
consistently use "(type *)(srom + offset)" preserving
the offsets from the original code.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4c93566e
  33. 13 1月, 2008 3 次提交
  35. 09 1月, 2008 2 次提交
  37. 24 11月, 2007 2 次提交
  39. 13 11月, 2007 1 次提交
  41. 20 10月, 2007 3 次提交
  43. 16 10月, 2007 1 次提交
  45. 15 10月, 2007 2 次提交
  47. 11 10月, 2007 6 次提交