We need to check the address that pci_alloc_consistent() returns since
it might fail.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
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 <alan@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
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 <martin-langer@gmx.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
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 <tsbogend@alpha.franken.de>
Acked-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
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 <wangchen@cn.fujitsu.com>
Acked-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
DE_UNALIGNED_16 is always being passed a u16 *, no need to have the
wrapper with two casts in it, just call get_unaligned directly.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
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 <grundler@parisc-linux.org>
Acked-by-stale-maintainer: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
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 <davem@davemloft.net>
The following patch is seems to fix the tulip suspend/resume panic:
http://bugzilla.kernel.org/show_bug.cgi?id=8952#c46
My attempts at a cleaner patch failed and Pavel thinks this is OK.
Original from: kernelbugs@tap.homeip.net
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
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 <avorontsov@ru.mvista.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
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 <avorontsov@ru.mvista.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
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 <tsbogend@alpha.franken.de>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
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 <jgarzik@redhat.com>
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 <grundler@parisc-linux.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
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 <grundler@parisc-linux.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
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 <bunk@kernel.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
When the chip dies (probably because of a bug somewhere in the driver),
de_stop_rxtx() fails and changing the media type crashes the whole machine.
Replace BUG_ON() in de_set_media() with a warning.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
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 <pozsy@uhulinux.hu> for posting/testing
a similar patch before:
http://lkml.org/lkml/2006/8/21/45
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
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 <mouw@nl.linux.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Changeset 16b110c3fd (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: David S. Miller <davem@davemloft.net>
* (trivial) endianness annotations
* don't bother with del_timer() from the inside of timer handler itself
* disable_ast() really ought to do del_timer_sync(), not del_timer()
* clean the timer handling in general.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
* descriptors inside the rx and tx rings are l-e
* don't cpu_to_le32() the argument of outl()
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Drivers do this to try to break out of the ->poll()'ing loop
when the device is being brought administratively down.
Now that we have a napi_disable() "pending" state we are going
to solve that problem generically.
Signed-off-by: David S. Miller <davem@davemloft.net>
This should fix the kernel warn/oops reported while routing.
The tulip driver has a fencepost bug with new NAPI in 2.6.24
It has an off by one bug if a full quantum is reached.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Accidently I reversed the order of pci_save_state and
pci_set_power_state in .suspend()/.resume() callbacks
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
When I removed net-modules.txt because it only contained ancient
information I missed that many Kconfig entries pointed to this ancient
information.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
- make the kconfig NAPI option prompt consistent across all net drivers
(other than EXPERIMENTAL; can it now be removed also, or is the new
napi_struct implementation now EXPERIMENTAL ?)
- remove comment about the now-deleted NAPI_HOWTO.txt file
- clean up typos in Tulip NAPI & Interrupt Mitigation
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
remove asm/bitops.h includes
including asm/bitops directly may cause compile errors. don't include it
and include linux/bitops instead. next patch will deny including asm header
directly.
Cc: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This will convert remaining non-obvious or naive calculations of array
sizes to use ARRAY_SIZE() macro.
Signed-off-by: Alejandro Martinez Ruiz <alex@flawedcode.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
This patch fixes an apparent potential null dereference bug where we
dereference dev before a null check. This patch simply remvoes the
can't-happen test for a null pointer.
Signed-off-by: Micah Gruber <micah.gruber@gmail.com>
Cc: Grant Grundler <grundler@parisc-linux.org>
Acked-by: Jeff Garzik <jeff@garzik.org>
Acked-by: Kyle McMartin <kyle@mcmartin.ca>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Clean up redundant PHY write line for ULi526x Ethernet
Driver.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
For the operations
get-tx-csum
get-sg
get-tso
get-ufo
the default ethtool_op_xxx behavior is fine for all drivers, so we
permit op==NULL to imply the default behavior.
This provides a more uniform behavior across all drivers, eliminating
ethtool(8) "ioctl not supported" errors on older drivers that had
not been updated for the latest sub-ioctls.
The ethtool_op_xxx() functions are left exported, in case anyone
wishes to call them directly from a driver-private implementation --
a not-uncommon case. Should an ethtool_op_xxx() helper remain unused
for a while, except by net/core/ethtool.c, we can un-export it at a
later date.
[ Resolved conflicts with set/get value ethtool patch... -DaveM ]
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
It's been a useless no-op for long enough in 2.6 so I figured it's time to
remove it. The number of people that could object because they're
maintaining unified 2.4 and 2.6 drivers is probably rather small.
[ Handled drivers added by netdev tree and some missed IRDA cases... -DaveM ]
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add suspend/resume support to the uli526x network driver (tested on x86_64,
with 'Ethernet controller: ALi Corporation M5263 Ethernet Controller, rev 40').
This patch is based on the suspend/resume code in the tg3 driver.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Several devices have multiple independant RX queues per net
device, and some have a single interrupt doorbell for several
queues.
In either case, it's easier to support layouts like that if the
structure representing the poll is independant from the net
device itself.
The signature of the ->poll() call back goes from:
int foo_poll(struct net_device *dev, int *budget)
to
int foo_poll(struct napi_struct *napi, int budget)
The caller is returned the number of RX packets processed (or
the number of "NAPI credits" consumed if you want to get
abstract). The callee no longer messes around bumping
dev->quota, *budget, etc. because that is all handled in the
caller upon return.
The napi_struct is to be embedded in the device driver private data
structures.
Furthermore, it is the driver's responsibility to disable all NAPI
instances in it's ->stop() device close handler. Since the
napi_struct is privatized into the driver's private data structures,
only the driver knows how to get at all of the napi_struct instances
it may have per-device.
With lots of help and suggestions from Rusty Russell, Roland Dreier,
Michael Chan, Jeff Garzik, and Jamal Hadi Salim.
Bug fixes from Thomas Graf, Roland Dreier, Peter Zijlstra,
Joseph Fannin, Scott Wood, Hans J. Koch, and Michael Chan.
[ Ported to current tree and all drivers converted. Integrated
Stephen's follow-on kerneldoc additions, and restored poll_list
handling to the old style to fix mutual exclusion issues. -DaveM ]
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
FUJITA Tomonori