08 Jan, 2009

7 commits


26 Dec, 2008

1 commit


23 Dec, 2008

1 commit

  • When the napi api was changed to separate its 1:1 binding to the net_device
    struct, the netif_rx_[prep|schedule|complete] api failed to remove the now
    vestigual net_device structure parameter. This patch cleans up that api by
    properly removing it..

    Signed-off-by: Neil Horman
    Signed-off-by: David S. Miller

    Neil Horman
     

13 Nov, 2008

1 commit

  • We have some reasons to kill netdev->priv:
    1. netdev->priv is equal to netdev_priv().
    2. netdev_priv() wraps the calculation of netdev->priv's offset, obviously
    netdev_priv() is more flexible than netdev->priv.
    But we cann't kill netdev->priv, because so many drivers reference to it
    directly.

    This patch is a safe convert for netdev->priv to netdev_priv(netdev).
    Since all of the netdev->priv is only for read.
    But it is too big to be sent in one mail.
    I split it to 4 parts and make every part smaller than 100,000 bytes,
    which is max size allowed by vger.

    Signed-off-by: Wang Chen
    Signed-off-by: David S. Miller

    Wang Chen
     

11 Nov, 2008

1 commit


04 Nov, 2008

1 commit


31 Oct, 2008

1 commit


28 Oct, 2008

2 commits

  • This converts pretty much everything to print_mac. There were
    a few things that had conflicts which I have just dropped for
    now, no harm done.

    I've built an allyesconfig with this and looked at the files
    that weren't built very carefully, but it's a huge patch.

    Signed-off-by: Johannes Berg
    Signed-off-by: David S. Miller

    Johannes Berg
     
  • We need to check the address that pci_alloc_consistent() returns since
    it might fail.

    Signed-off-by: FUJITA Tomonori
    Signed-off-by: Jeff Garzik

    FUJITA Tomonori
     

14 Oct, 2008

2 commits

  • Clean up the various different email addresses of mine listed in the code
    to a single current and valid address. As Dave says his network merges
    for 2.6.28 are now done this seems a good point to send them in where
    they won't risk disrupting real changes.

    Signed-off-by: Alan Cox
    Signed-off-by: David S. Miller

    Alan Cox
     
  • The de2104x returns sometimes a wrong MAC address. The wrong one is
    like the original one, but it comes with an one byte shift. I found
    this bug on an older alpha ev5 cpu. More details are available in Gentoo
    bugreport #240718.

    It seems the hardware is sometimes a little bit too slow for an
    immediate access. This patch solves the problem by introducing a small
    udelay.

    Signed-off-by: Martin Langer
    Signed-off-by: David S. Miller

    Martin Langer
     

25 Sep, 2008

1 commit

  • The de2104x did a pci_disable_device() in it's close function, but
    the open function never does a pci_enable_device() and assumes that
    the device is already enabled. Considering that downing the interface
    is just a temporary thing the pci_disable_device() isn't a pretty good
    idea and removing it from the close function just fixes the bug.

    Signed-off-by: Thomas Bogendoerfer
    Acked-by: Grant Grundler
    Signed-off-by: Jeff Garzik

    Thomas Bogendoerfer
     

23 Sep, 2008

1 commit


23 Jul, 2008

1 commit

  • IFF_PROMISC flag shouldn't be set or cleared by drivers, because
    whether device be promisc mode is decided by how many upper layer
    callers being referenced to it.
    And the promisc changing feature of de4x5 ioctl is developer debug
    feature, we can remove it now.

    Signed-off-by: Wang Chen
    Acked-by: Grant Grundler
    Signed-off-by: Jeff Garzik

    Wang Chen
     

28 Jun, 2008

1 commit


25 Jun, 2008

1 commit

  • Three basic changes to the comments at the top of each file:
    1) remove stale "Maintained by" line...I prefer people look in MAINTAINERS.
    2) Drop reference to stale sf.net/tulip website (I didn't see anything
    of value there)
    3) Point people at bugzilla.kernel.org to submit bugs...will always
    get tracked regardless of who the maintainer is.

    Signed-off-by: Grant Grundler
    Acked-by-stale-maintainer: Jeff Garzik
    Signed-off-by: Jeff Garzik

    Grant Grundler
     

12 Jun, 2008

1 commit

  • 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: David S. Miller

    David S. Miller
     

31 May, 2008

1 commit


22 May, 2008

1 commit

  • 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: Anton Vorontsov
    Signed-off-by: Jeff Garzik

    Anton Vorontsov
     

07 May, 2008

2 commits

  • 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: Anton Vorontsov
    Signed-off-by: Jeff Garzik

    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 80630088 2f830000 419e0014

    Signed-off-by: Anton Vorontsov
    Signed-off-by: Jeff Garzik

    Anton Vorontsov
     

29 Apr, 2008

1 commit


17 Apr, 2008

2 commits

  • 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: Thomas Bogendoerfer
    Signed-off-by: Jeff Garzik

    Peter Horton
     
  • 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: Jeff Garzik

    Jeff Garzik
     

03 Apr, 2008

1 commit


29 Mar, 2008

1 commit

  • 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: Grant Grundler
    Signed-off-by: Jeff Garzik

    Grant Grundler
     

23 Mar, 2008

1 commit


17 Mar, 2008

2 commits

  • This untested patch _should_ fix:
    "(net de2104x) Kernel panic with de2104x tulip driver on boot"
    http://bugzilla.kernel.org/show_bug.cgi?id=3156

    But the bug submitter isn't responding. Same fix has been applied
    to tulip.c (several years ago) and uli526x.c (Feb 2008) drivers.

    [ The panic reported in the bug report was removed in a recently
    (march 2008) accepted patch from Ondrej Zary. ]

    Signed-off-by: Grant Grundler
    Signed-off-by: Jeff Garzik

    Grant Grundler
     
  • The xircom_tulip_cb driver has been replaced the xircom_cb driver, and
    since it depended on BROKEN_ON_SMP it e.g. was no longer present in many
    distribution kernels.

    This patch therefore removes it.

    Signed-off-by: Adrian Bunk
    Signed-off-by: Jeff Garzik

    Adrian Bunk
     

05 Mar, 2008

1 commit


24 Feb, 2008

1 commit

  • Patch fixes:
    http://bugzilla.kernel.org/show_bug.cgi?id=5839

    Init sequence needs to poll phy until phy reset is complete. This is the
    same problem that I fixed in 2002 in tulip driver.

    Thanks to manty@manty.net for testing this patch.
    Thanks to Pozsar Balazs for posting/testing
    a similar patch before:
    http://lkml.org/lkml/2006/8/21/45

    Signed-off-by: Grant Grundler
    Signed-off-by: Jeff Garzik

    Grant Grundler
     

06 Feb, 2008

1 commit

  • Changes in other networking paths uncovered a bug in the xircom_cb
    driver which made the kernel spew lots of the following error messages:

    BUG eth1 code -5 qlen 0

    It turned out that the driver returned -EIO when there was no
    descriptor available for sending packets. It should return
    NETDEV_TX_BUSY instead. This was discussed on the netdev list before,
    see http://thread.gmane.org/gmane.linux.network/84603 .

    Signed-off-by: Erik Mouw
    Signed-off-by: Jeff Garzik

    Erik Mouw
     

29 Jan, 2008

2 commits