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 <wangchen@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The generic packet receive code takes care of setting
netdev->last_rx when necessary, for the sake of the
bonding ARP monitor.
Drivers need not do it any more.
Some cases had to be skipped over because the drivers
were making use of the ->last_rx value themselves.
Signed-off-by: David S. Miller <davem@davemloft.net>
For the common, open coded 'skb->mac.raw = skb->data' operation, so that we can
later turn skb->mac.raw into a offset, reducing the size of struct sk_buff in
64bit land while possibly keeping it as a pointer on 32bit.
This one touches just the most simple case, next will handle the slightly more
"complex" cases.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The modifications and bug fixes noted below were done by Realtime Control
Works and Contemporary Control Systems, Inc, Jan 2005. They were
incorporated into the 2.6 kernel by Jeff Morrow of Sierra Analytics, Feb
2007. <jmorrow@massspec.com>
The changes have been tested on a Contemporary Controls PCI20U-4000.
Summary of changes:
Arc-rawmode.c:
rx():
- Fixed error in received packet lengths; 256 byte packets were
being received as 257 bytes packets.
prepare_tx():
- Fixed error in transmit length calcs; 257 byte packets were being
transmitted as 260 byte packets.
com20020.c:
com20020_check():
- We now load the SETUP2 register if the 'clockm' parameter is
non-zero, instead of checking for ARC_CAN_10MBIT. The user is
now responsible for whether or not SETUP2 is loaded. If the
clock multiplier is non-zero, this means that the user wants a
baud rate greater than 2.5Mbps. This is not possible unless the
SETUP2 register is present (COM20020D, or COM20022). So, we're
relying on the user to be smart about what kind of chip he's
dealing with...
com20020-pci.c
- Added several entries to com20020pci_id_table[].
Signed-off-by: Jeff Morrow <jmorrow@massspec.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
This patch contains the following possible cleanups:
- make needlessly global code static
- arcnet.c: remove the unneeded EXPORT_SYMBOL(arc_proto_null)
- arcnet.c: remove the unneeded EXPORT_SYMBOL(arcnet_dump_packet)
To make Jeff happy, arcnet.c still prints
arcnet: v3.93 BETA 2000/04/29 - by Avery Pennarun et al.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Wang Chen
David S. Miller
Arnaldo Carvalho de Melo
Jeff Morrow
Adrian Bunk
Linus Torvalds