2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2013-03-25 08:26:24 +00:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2011-05-29 19:07:19 +02:00
|
|
|
|
2010-11-06 23:18:23 +01:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2010-12-17 22:22:33 +01:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 17:04:11 +09:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
firewire net, ipv4 arp: Extend hardware address and remove driver-level packet inspection.
Inspection of upper layer protocol is considered harmful, especially
if it is about ARP or other stateful upper layer protocol; driver
cannot (and should not) have full state of them.
IPv4 over Firewire module used to inspect ARP (both in sending path
and in receiving path), and record peer's GUID, max packet size, max
speed and fifo address. This patch removes such inspection by extending
our "hardware address" definition to include other information as well:
max packet size, max speed and fifo. By doing this, The neighbour
module in networking subsystem can cache them.
Note: As we have started ignoring sspd and max_rec in ARP/NDP, those
information will not be used in the driver when sending.
When a packet is being sent, the IP layer fills our pseudo header with
the extended "hardware address", including GUID and fifo. The driver
can look-up node-id (the real but rather volatile low-level address)
by GUID, and then the module can send the packet to the wire using
parameters provided in the extendedn hardware address.
This approach is realistic because IP over IEEE1394 (RFC2734) and IPv6
over IEEE1394 (RFC3146) share same "hardware address" format
in their address resolution protocols.
Here, extended "hardware address" is defined as follows:
union fwnet_hwaddr {
u8 u[16];
struct {
__be64 uniq_id; /* EUI-64 */
u8 max_rec; /* max packet size */
u8 sspd; /* max speed */
__be16 fifo_hi; /* hi 16bits of FIFO addr */
__be32 fifo_lo; /* lo 32bits of FIFO addr */
} __packed uc;
};
Note that Hardware address is declared as union, so that we can map full
IP address into this, when implementing MCAP (Multicast Cannel Allocation
Protocol) for IPv6, but IP and ARP subsystem do not need to know this
format in detail.
One difference between original ARP (RFC826) and 1394 ARP (RFC2734)
is that 1394 ARP Request/Reply do not contain the target hardware address
field (aka ar$tha). This difference is handled in the ARP subsystem.
CC: Stephan Gatzka <stephan.gatzka@gmail.com>
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-03-25 08:26:16 +00:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2010-11-14 14:35:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2013-03-25 08:26:24 +00:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2013-03-25 08:25:48 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
firewire: net: fix fragmented datagram_size off-by-one
RFC 2734 defines the datagram_size field in fragment encapsulation
headers thus:
datagram_size: The encoded size of the entire IP datagram. The
value of datagram_size [...] SHALL be one less than the value of
Total Length in the datagram's IP header (see STD 5, RFC 791).
Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
this field with a -/+1 offset:
ether1394_tx() /* transmit */
ether1394_encapsulate_prep()
hdr->ff.dg_size = dg_size - 1;
ether1394_data_handler() /* receive */
if (hdr->common.lf == ETH1394_HDR_LF_FF)
dg_size = hdr->ff.dg_size + 1;
else
dg_size = hdr->sf.dg_size + 1;
Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
byte sized datagrams in fragments with datagram_size=1499 if link
fragmentation is required.
Only firewire-net sets and gets datagram_size without this offset. The
result is lacking interoperability of firewire-net with OS X, Windows
XP, and presumably Linux' eth1394. (I did not test with the latter.)
For example, FTP data transfers to a Linux firewire-net box with max_rec
smaller than the 1500 bytes MTU
- from OS X fail entirely,
- from Win XP start out with a bunch of fragmented datagrams which
time out, then continue with unfragmented datagrams because Win XP
temporarily reduces the MTU to 576 bytes.
So let's fix firewire-net's datagram_size accessors.
Note that firewire-net thereby loses interoperability with unpatched
firewire-net, but only if link fragmentation is employed. (This happens
with large broadcast datagrams, and with large datagrams on several
FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
and it can be worked around by setting a small enough MTU.)
Cc: stable@vger.kernel.org
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2016-10-30 17:32:01 +01:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
firewire: net: fix fragmented datagram_size off-by-one
RFC 2734 defines the datagram_size field in fragment encapsulation
headers thus:
datagram_size: The encoded size of the entire IP datagram. The
value of datagram_size [...] SHALL be one less than the value of
Total Length in the datagram's IP header (see STD 5, RFC 791).
Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
this field with a -/+1 offset:
ether1394_tx() /* transmit */
ether1394_encapsulate_prep()
hdr->ff.dg_size = dg_size - 1;
ether1394_data_handler() /* receive */
if (hdr->common.lf == ETH1394_HDR_LF_FF)
dg_size = hdr->ff.dg_size + 1;
else
dg_size = hdr->sf.dg_size + 1;
Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
byte sized datagrams in fragments with datagram_size=1499 if link
fragmentation is required.
Only firewire-net sets and gets datagram_size without this offset. The
result is lacking interoperability of firewire-net with OS X, Windows
XP, and presumably Linux' eth1394. (I did not test with the latter.)
For example, FTP data transfers to a Linux firewire-net box with max_rec
smaller than the 1500 bytes MTU
- from OS X fail entirely,
- from Win XP start out with a bunch of fragmented datagrams which
time out, then continue with unfragmented datagrams because Win XP
temporarily reduces the MTU to 576 bytes.
So let's fix firewire-net's datagram_size accessors.
Note that firewire-net thereby loses interoperability with unpatched
firewire-net, but only if link fragmentation is employed. (This happens
with large broadcast datagrams, and with large datagrams on several
FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
and it can be worked around by setting a small enough MTU.)
Cc: stable@vger.kernel.org
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2016-10-30 17:32:01 +01:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
firewire: net: fix fragmented datagram_size off-by-one
RFC 2734 defines the datagram_size field in fragment encapsulation
headers thus:
datagram_size: The encoded size of the entire IP datagram. The
value of datagram_size [...] SHALL be one less than the value of
Total Length in the datagram's IP header (see STD 5, RFC 791).
Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
this field with a -/+1 offset:
ether1394_tx() /* transmit */
ether1394_encapsulate_prep()
hdr->ff.dg_size = dg_size - 1;
ether1394_data_handler() /* receive */
if (hdr->common.lf == ETH1394_HDR_LF_FF)
dg_size = hdr->ff.dg_size + 1;
else
dg_size = hdr->sf.dg_size + 1;
Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
byte sized datagrams in fragments with datagram_size=1499 if link
fragmentation is required.
Only firewire-net sets and gets datagram_size without this offset. The
result is lacking interoperability of firewire-net with OS X, Windows
XP, and presumably Linux' eth1394. (I did not test with the latter.)
For example, FTP data transfers to a Linux firewire-net box with max_rec
smaller than the 1500 bytes MTU
- from OS X fail entirely,
- from Win XP start out with a bunch of fragmented datagrams which
time out, then continue with unfragmented datagrams because Win XP
temporarily reduces the MTU to 576 bytes.
So let's fix firewire-net's datagram_size accessors.
Note that firewire-net thereby loses interoperability with unpatched
firewire-net, but only if link fragmentation is employed. (This happens
with large broadcast datagrams, and with large datagrams on several
FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
and it can be worked around by setting a small enough MTU.)
Cc: stable@vger.kernel.org
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2016-10-30 17:32:01 +01:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-06 23:18:23 +01:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2010-12-17 22:22:33 +01:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-06 23:18:23 +01:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-06 23:18:23 +01:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2010-11-06 23:18:23 +01:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
firewire net, ipv4 arp: Extend hardware address and remove driver-level packet inspection.
Inspection of upper layer protocol is considered harmful, especially
if it is about ARP or other stateful upper layer protocol; driver
cannot (and should not) have full state of them.
IPv4 over Firewire module used to inspect ARP (both in sending path
and in receiving path), and record peer's GUID, max packet size, max
speed and fifo address. This patch removes such inspection by extending
our "hardware address" definition to include other information as well:
max packet size, max speed and fifo. By doing this, The neighbour
module in networking subsystem can cache them.
Note: As we have started ignoring sspd and max_rec in ARP/NDP, those
information will not be used in the driver when sending.
When a packet is being sent, the IP layer fills our pseudo header with
the extended "hardware address", including GUID and fifo. The driver
can look-up node-id (the real but rather volatile low-level address)
by GUID, and then the module can send the packet to the wire using
parameters provided in the extendedn hardware address.
This approach is realistic because IP over IEEE1394 (RFC2734) and IPv6
over IEEE1394 (RFC3146) share same "hardware address" format
in their address resolution protocols.
Here, extended "hardware address" is defined as follows:
union fwnet_hwaddr {
u8 u[16];
struct {
__be64 uniq_id; /* EUI-64 */
u8 max_rec; /* max packet size */
u8 sspd; /* max speed */
__be16 fifo_hi; /* hi 16bits of FIFO addr */
__be32 fifo_lo; /* lo 32bits of FIFO addr */
} __packed uc;
};
Note that Hardware address is declared as union, so that we can map full
IP address into this, when implementing MCAP (Multicast Cannel Allocation
Protocol) for IPv6, but IP and ARP subsystem do not need to know this
format in detail.
One difference between original ARP (RFC826) and 1394 ARP (RFC2734)
is that 1394 ARP Request/Reply do not contain the target hardware address
field (aka ar$tha). This difference is handled in the ARP subsystem.
CC: Stephan Gatzka <stephan.gatzka@gmail.com>
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-03-25 08:26:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
networking: make skb_push & __skb_push return void pointers
It seems like a historic accident that these return unsigned char *,
and in many places that means casts are required, more often than not.
Make these functions return void * and remove all the casts across
the tree, adding a (u8 *) cast only where the unsigned char pointer
was used directly, all done with the following spatch:
@@
expression SKB, LEN;
typedef u8;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
@@
- *(fn(SKB, LEN))
+ *(u8 *)fn(SKB, LEN)
@@
expression E, SKB, LEN;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
type T;
@@
- E = ((T *)(fn(SKB, LEN)))
+ E = fn(SKB, LEN)
@@
expression SKB, LEN;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
@@
- fn(SKB, LEN)[0]
+ *(u8 *)fn(SKB, LEN)
Note that the last part there converts from push(...)[0] to the
more idiomatic *(u8 *)push(...).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:23 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2011-07-12 23:28:12 -07:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2011-07-12 23:28:12 -07:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2013-01-19 22:03:07 +00:00
|
|
|
|
2011-07-12 23:28:12 -07:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-19 22:03:07 +00:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-24 17:32:00 +01:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2013-01-19 22:03:07 +00:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2013-01-19 22:03:07 +00:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-30 22:57:33 -03:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2011-09-19 00:20:48 +02:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2013-03-25 08:25:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-25 08:26:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-25 08:25:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2013-01-19 21:43:40 +00:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
firewire net, ipv4 arp: Extend hardware address and remove driver-level packet inspection.
Inspection of upper layer protocol is considered harmful, especially
if it is about ARP or other stateful upper layer protocol; driver
cannot (and should not) have full state of them.
IPv4 over Firewire module used to inspect ARP (both in sending path
and in receiving path), and record peer's GUID, max packet size, max
speed and fifo address. This patch removes such inspection by extending
our "hardware address" definition to include other information as well:
max packet size, max speed and fifo. By doing this, The neighbour
module in networking subsystem can cache them.
Note: As we have started ignoring sspd and max_rec in ARP/NDP, those
information will not be used in the driver when sending.
When a packet is being sent, the IP layer fills our pseudo header with
the extended "hardware address", including GUID and fifo. The driver
can look-up node-id (the real but rather volatile low-level address)
by GUID, and then the module can send the packet to the wire using
parameters provided in the extendedn hardware address.
This approach is realistic because IP over IEEE1394 (RFC2734) and IPv6
over IEEE1394 (RFC3146) share same "hardware address" format
in their address resolution protocols.
Here, extended "hardware address" is defined as follows:
union fwnet_hwaddr {
u8 u[16];
struct {
__be64 uniq_id; /* EUI-64 */
u8 max_rec; /* max packet size */
u8 sspd; /* max speed */
__be16 fifo_hi; /* hi 16bits of FIFO addr */
__be32 fifo_lo; /* lo 32bits of FIFO addr */
} __packed uc;
};
Note that Hardware address is declared as union, so that we can map full
IP address into this, when implementing MCAP (Multicast Cannel Allocation
Protocol) for IPv6, but IP and ARP subsystem do not need to know this
format in detail.
One difference between original ARP (RFC826) and 1394 ARP (RFC2734)
is that 1394 ARP Request/Reply do not contain the target hardware address
field (aka ar$tha). This difference is handled in the ARP subsystem.
CC: Stephan Gatzka <stephan.gatzka@gmail.com>
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-03-25 08:26:16 +00:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
firewire net, ipv4 arp: Extend hardware address and remove driver-level packet inspection.
Inspection of upper layer protocol is considered harmful, especially
if it is about ARP or other stateful upper layer protocol; driver
cannot (and should not) have full state of them.
IPv4 over Firewire module used to inspect ARP (both in sending path
and in receiving path), and record peer's GUID, max packet size, max
speed and fifo address. This patch removes such inspection by extending
our "hardware address" definition to include other information as well:
max packet size, max speed and fifo. By doing this, The neighbour
module in networking subsystem can cache them.
Note: As we have started ignoring sspd and max_rec in ARP/NDP, those
information will not be used in the driver when sending.
When a packet is being sent, the IP layer fills our pseudo header with
the extended "hardware address", including GUID and fifo. The driver
can look-up node-id (the real but rather volatile low-level address)
by GUID, and then the module can send the packet to the wire using
parameters provided in the extendedn hardware address.
This approach is realistic because IP over IEEE1394 (RFC2734) and IPv6
over IEEE1394 (RFC3146) share same "hardware address" format
in their address resolution protocols.
Here, extended "hardware address" is defined as follows:
union fwnet_hwaddr {
u8 u[16];
struct {
__be64 uniq_id; /* EUI-64 */
u8 max_rec; /* max packet size */
u8 sspd; /* max speed */
__be16 fifo_hi; /* hi 16bits of FIFO addr */
__be32 fifo_lo; /* lo 32bits of FIFO addr */
} __packed uc;
};
Note that Hardware address is declared as union, so that we can map full
IP address into this, when implementing MCAP (Multicast Cannel Allocation
Protocol) for IPv6, but IP and ARP subsystem do not need to know this
format in detail.
One difference between original ARP (RFC826) and 1394 ARP (RFC2734)
is that 1394 ARP Request/Reply do not contain the target hardware address
field (aka ar$tha). This difference is handled in the ARP subsystem.
CC: Stephan Gatzka <stephan.gatzka@gmail.com>
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-03-25 08:26:16 +00:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2013-03-25 08:25:48 +00:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-14 11:46:57 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2013-03-28 13:38:25 +09:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2013-03-25 08:25:38 +00:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2010-08-16 23:45:54 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-29 21:28:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2013-01-19 22:03:07 +00:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2010-08-16 23:45:54 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2013-01-19 22:03:07 +00:00
|
|
|
|
networking: introduce and use skb_put_data()
A common pattern with skb_put() is to just want to memcpy()
some data into the new space, introduce skb_put_data() for
this.
An spatch similar to the one for skb_put_zero() converts many
of the places using it:
@@
identifier p, p2;
expression len, skb, data;
type t, t2;
@@
(
-p = skb_put(skb, len);
+p = skb_put_data(skb, data, len);
|
-p = (t)skb_put(skb, len);
+p = skb_put_data(skb, data, len);
)
(
p2 = (t2)p;
-memcpy(p2, data, len);
|
-memcpy(p, data, len);
)
@@
type t, t2;
identifier p, p2;
expression skb, data;
@@
t *p;
...
(
-p = skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
|
-p = (t *)skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
)
(
p2 = (t2)p;
-memcpy(p2, data, sizeof(*p));
|
-memcpy(p, data, sizeof(*p));
)
@@
expression skb, len, data;
@@
-memcpy(skb_put(skb, len), data, len);
+skb_put_data(skb, data, len);
(again, manually post-processed to retain some comments)
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:20 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2016-10-29 21:28:18 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2016-10-29 21:28:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
firewire: net: fix fragmented datagram_size off-by-one
RFC 2734 defines the datagram_size field in fragment encapsulation
headers thus:
datagram_size: The encoded size of the entire IP datagram. The
value of datagram_size [...] SHALL be one less than the value of
Total Length in the datagram's IP header (see STD 5, RFC 791).
Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
this field with a -/+1 offset:
ether1394_tx() /* transmit */
ether1394_encapsulate_prep()
hdr->ff.dg_size = dg_size - 1;
ether1394_data_handler() /* receive */
if (hdr->common.lf == ETH1394_HDR_LF_FF)
dg_size = hdr->ff.dg_size + 1;
else
dg_size = hdr->sf.dg_size + 1;
Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
byte sized datagrams in fragments with datagram_size=1499 if link
fragmentation is required.
Only firewire-net sets and gets datagram_size without this offset. The
result is lacking interoperability of firewire-net with OS X, Windows
XP, and presumably Linux' eth1394. (I did not test with the latter.)
For example, FTP data transfers to a Linux firewire-net box with max_rec
smaller than the 1500 bytes MTU
- from OS X fail entirely,
- from Win XP start out with a bunch of fragmented datagrams which
time out, then continue with unfragmented datagrams because Win XP
temporarily reduces the MTU to 576 bytes.
So let's fix firewire-net's datagram_size accessors.
Note that firewire-net thereby loses interoperability with unpatched
firewire-net, but only if link fragmentation is employed. (This happens
with large broadcast datagrams, and with large datagrams on several
FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
and it can be worked around by setting a small enough MTU.)
Cc: stable@vger.kernel.org
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2016-10-30 17:32:01 +01:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2016-10-29 21:28:18 +02:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-16 23:45:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2010-08-16 23:45:54 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-16 23:45:54 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2010-08-16 23:45:54 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-14 14:35:40 +01:00
|
|
|
|
2010-08-16 23:45:54 +02:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2010-08-16 23:45:54 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2010-06-20 22:50:35 +02:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-06-16 22:35:32 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-16 22:35:32 +02:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-06-16 22:35:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-19 12:48:36 +01:00
|
|
|
|
2009-06-16 22:35:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-06-16 22:35:32 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2016-10-29 21:28:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2016-10-29 21:28:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-25 08:26:24 +00:00
|
|
|
|
2016-10-29 21:28:18 +02:00
|
|
|
|
2013-03-25 08:26:24 +00:00
|
|
|
|
2016-10-29 21:28:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-28 20:04:32 +01:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-02 09:33:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-19 12:48:36 +01:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2010-01-18 22:36:49 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-14 14:35:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-18 22:36:49 +01:00
|
|
|
|
2010-11-06 12:36:13 +01:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2010-01-18 22:36:49 +01:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-18 22:36:49 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-06 23:18:23 +01:00
|
|
|
|
2010-11-06 16:57:28 +01:00
|
|
|
|
2010-11-14 14:35:40 +01:00
|
|
|
|
2010-01-18 22:36:49 +01:00
|
|
|
|
2010-11-06 12:36:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-18 22:36:49 +01:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2012-02-19 12:48:36 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2010-11-06 12:36:13 +01:00
|
|
|
|
2012-11-28 20:04:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2010-01-18 22:36:49 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2010-11-06 16:57:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-06 23:18:23 +01:00
|
|
|
|
2010-11-06 16:57:28 +01:00
|
|
|
|
2010-11-14 14:35:40 +01:00
|
|
|
|
2010-11-06 16:57:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-29 04:09:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2010-11-06 16:57:28 +01:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2010-11-06 16:57:28 +01:00
|
|
|
|
2010-11-29 04:09:53 +02:00
|
|
|
|
2012-02-19 12:48:36 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-29 04:09:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-18 22:25:15 +01:00
|
|
|
|
2010-11-29 04:09:53 +02:00
|
|
|
|
2014-02-18 22:25:15 +01:00
|
|
|
|
|
|
|
|
|
2010-11-06 16:57:28 +01:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2010-01-18 22:36:49 +01:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
networking: make skb_push & __skb_push return void pointers
It seems like a historic accident that these return unsigned char *,
and in many places that means casts are required, more often than not.
Make these functions return void * and remove all the casts across
the tree, adding a (u8 *) cast only where the unsigned char pointer
was used directly, all done with the following spatch:
@@
expression SKB, LEN;
typedef u8;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
@@
- *(fn(SKB, LEN))
+ *(u8 *)fn(SKB, LEN)
@@
expression E, SKB, LEN;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
type T;
@@
- E = ((T *)(fn(SKB, LEN)))
+ E = fn(SKB, LEN)
@@
expression SKB, LEN;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
@@
- fn(SKB, LEN)[0]
+ *(u8 *)fn(SKB, LEN)
Note that the last part there converts from push(...)[0] to the
more idiomatic *(u8 *)push(...).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:23 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
networking: make skb_push & __skb_push return void pointers
It seems like a historic accident that these return unsigned char *,
and in many places that means casts are required, more often than not.
Make these functions return void * and remove all the casts across
the tree, adding a (u8 *) cast only where the unsigned char pointer
was used directly, all done with the following spatch:
@@
expression SKB, LEN;
typedef u8;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
@@
- *(fn(SKB, LEN))
+ *(u8 *)fn(SKB, LEN)
@@
expression E, SKB, LEN;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
type T;
@@
- E = ((T *)(fn(SKB, LEN)))
+ E = fn(SKB, LEN)
@@
expression SKB, LEN;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
@@
- fn(SKB, LEN)[0]
+ *(u8 *)fn(SKB, LEN)
Note that the last part there converts from push(...)[0] to the
more idiomatic *(u8 *)push(...).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:23 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2013-03-25 08:26:24 +00:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2013-03-25 08:26:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-28 20:04:32 +01:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2013-03-25 08:26:24 +00:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-18 22:36:49 +01:00
|
|
|
|
|
|
|
|
|
2010-11-06 23:18:23 +01:00
|
|
|
|
2010-01-18 22:36:49 +01:00
|
|
|
|
2010-11-06 23:18:23 +01:00
|
|
|
|
|
|
|
|
|
2010-11-14 14:35:40 +01:00
|
|
|
|
2010-01-18 22:36:49 +01:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2010-01-18 22:36:49 +01:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-18 22:36:49 +01:00
|
|
|
|
|
|
|
|
|
2010-11-06 23:18:23 +01:00
|
|
|
|
2010-01-18 22:36:49 +01:00
|
|
|
|
2010-11-06 23:18:23 +01:00
|
|
|
|
|
|
|
|
|
2010-11-14 14:35:40 +01:00
|
|
|
|
2010-01-18 22:36:49 +01:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2016-05-03 16:33:13 +02:00
|
|
|
|
2010-01-18 22:36:49 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-08 10:42:26 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-08 10:45:50 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-08 10:43:25 +09:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2013-03-08 10:43:14 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-08 10:43:55 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-08 10:45:50 +09:00
|
|
|
|
2013-03-08 10:43:55 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-08 10:43:25 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-08 10:45:50 +09:00
|
|
|
|
2013-03-08 10:43:25 +09:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2013-03-08 10:43:25 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-08 10:45:50 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2013-03-08 10:43:25 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2013-03-08 10:43:25 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2013-03-08 10:43:25 +09:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-08 10:45:50 +09:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-08 10:45:50 +09:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2013-03-08 10:45:50 +09:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-17 22:22:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2013-03-08 10:43:14 +09:00
|
|
|
|
|
|
|
|
|
2013-03-25 08:25:57 +00:00
|
|
|
|
2013-03-08 10:43:14 +09:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2010-12-17 22:22:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2013-03-08 10:45:57 +09:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2013-03-08 10:45:57 +09:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-31 19:50:51 +00:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2010-11-14 14:35:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-25 08:25:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-25 08:26:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-25 08:25:38 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-25 08:25:48 +00:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
firewire net, ipv4 arp: Extend hardware address and remove driver-level packet inspection.
Inspection of upper layer protocol is considered harmful, especially
if it is about ARP or other stateful upper layer protocol; driver
cannot (and should not) have full state of them.
IPv4 over Firewire module used to inspect ARP (both in sending path
and in receiving path), and record peer's GUID, max packet size, max
speed and fifo address. This patch removes such inspection by extending
our "hardware address" definition to include other information as well:
max packet size, max speed and fifo. By doing this, The neighbour
module in networking subsystem can cache them.
Note: As we have started ignoring sspd and max_rec in ARP/NDP, those
information will not be used in the driver when sending.
When a packet is being sent, the IP layer fills our pseudo header with
the extended "hardware address", including GUID and fifo. The driver
can look-up node-id (the real but rather volatile low-level address)
by GUID, and then the module can send the packet to the wire using
parameters provided in the extendedn hardware address.
This approach is realistic because IP over IEEE1394 (RFC2734) and IPv6
over IEEE1394 (RFC3146) share same "hardware address" format
in their address resolution protocols.
Here, extended "hardware address" is defined as follows:
union fwnet_hwaddr {
u8 u[16];
struct {
__be64 uniq_id; /* EUI-64 */
u8 max_rec; /* max packet size */
u8 sspd; /* max speed */
__be16 fifo_hi; /* hi 16bits of FIFO addr */
__be32 fifo_lo; /* lo 32bits of FIFO addr */
} __packed uc;
};
Note that Hardware address is declared as union, so that we can map full
IP address into this, when implementing MCAP (Multicast Cannel Allocation
Protocol) for IPv6, but IP and ARP subsystem do not need to know this
format in detail.
One difference between original ARP (RFC826) and 1394 ARP (RFC2734)
is that 1394 ARP Request/Reply do not contain the target hardware address
field (aka ar$tha). This difference is handled in the ARP subsystem.
CC: Stephan Gatzka <stephan.gatzka@gmail.com>
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-03-25 08:26:16 +00:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
firewire net, ipv4 arp: Extend hardware address and remove driver-level packet inspection.
Inspection of upper layer protocol is considered harmful, especially
if it is about ARP or other stateful upper layer protocol; driver
cannot (and should not) have full state of them.
IPv4 over Firewire module used to inspect ARP (both in sending path
and in receiving path), and record peer's GUID, max packet size, max
speed and fifo address. This patch removes such inspection by extending
our "hardware address" definition to include other information as well:
max packet size, max speed and fifo. By doing this, The neighbour
module in networking subsystem can cache them.
Note: As we have started ignoring sspd and max_rec in ARP/NDP, those
information will not be used in the driver when sending.
When a packet is being sent, the IP layer fills our pseudo header with
the extended "hardware address", including GUID and fifo. The driver
can look-up node-id (the real but rather volatile low-level address)
by GUID, and then the module can send the packet to the wire using
parameters provided in the extendedn hardware address.
This approach is realistic because IP over IEEE1394 (RFC2734) and IPv6
over IEEE1394 (RFC3146) share same "hardware address" format
in their address resolution protocols.
Here, extended "hardware address" is defined as follows:
union fwnet_hwaddr {
u8 u[16];
struct {
__be64 uniq_id; /* EUI-64 */
u8 max_rec; /* max packet size */
u8 sspd; /* max speed */
__be16 fifo_hi; /* hi 16bits of FIFO addr */
__be32 fifo_lo; /* lo 32bits of FIFO addr */
} __packed uc;
};
Note that Hardware address is declared as union, so that we can map full
IP address into this, when implementing MCAP (Multicast Cannel Allocation
Protocol) for IPv6, but IP and ARP subsystem do not need to know this
format in detail.
One difference between original ARP (RFC826) and 1394 ARP (RFC2734)
is that 1394 ARP Request/Reply do not contain the target hardware address
field (aka ar$tha). This difference is handled in the ARP subsystem.
CC: Stephan Gatzka <stephan.gatzka@gmail.com>
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-03-25 08:26:16 +00:00
|
|
|
|
2010-11-14 14:35:40 +01:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
firewire net, ipv4 arp: Extend hardware address and remove driver-level packet inspection.
Inspection of upper layer protocol is considered harmful, especially
if it is about ARP or other stateful upper layer protocol; driver
cannot (and should not) have full state of them.
IPv4 over Firewire module used to inspect ARP (both in sending path
and in receiving path), and record peer's GUID, max packet size, max
speed and fifo address. This patch removes such inspection by extending
our "hardware address" definition to include other information as well:
max packet size, max speed and fifo. By doing this, The neighbour
module in networking subsystem can cache them.
Note: As we have started ignoring sspd and max_rec in ARP/NDP, those
information will not be used in the driver when sending.
When a packet is being sent, the IP layer fills our pseudo header with
the extended "hardware address", including GUID and fifo. The driver
can look-up node-id (the real but rather volatile low-level address)
by GUID, and then the module can send the packet to the wire using
parameters provided in the extendedn hardware address.
This approach is realistic because IP over IEEE1394 (RFC2734) and IPv6
over IEEE1394 (RFC3146) share same "hardware address" format
in their address resolution protocols.
Here, extended "hardware address" is defined as follows:
union fwnet_hwaddr {
u8 u[16];
struct {
__be64 uniq_id; /* EUI-64 */
u8 max_rec; /* max packet size */
u8 sspd; /* max speed */
__be16 fifo_hi; /* hi 16bits of FIFO addr */
__be32 fifo_lo; /* lo 32bits of FIFO addr */
} __packed uc;
};
Note that Hardware address is declared as union, so that we can map full
IP address into this, when implementing MCAP (Multicast Cannel Allocation
Protocol) for IPv6, but IP and ARP subsystem do not need to know this
format in detail.
One difference between original ARP (RFC826) and 1394 ARP (RFC2734)
is that 1394 ARP Request/Reply do not contain the target hardware address
field (aka ar$tha). This difference is handled in the ARP subsystem.
CC: Stephan Gatzka <stephan.gatzka@gmail.com>
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-03-25 08:26:16 +00:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2010-11-14 14:35:40 +01:00
|
|
|
|
|
|
|
|
|
2010-11-06 23:18:23 +01:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2010-11-06 23:18:23 +01:00
|
|
|
|
2010-01-18 22:36:49 +01:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-14 14:35:40 +01:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-08 04:22:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-14 11:47:44 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-14 14:35:40 +01:00
|
|
|
|
2010-12-08 04:22:57 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-16 20:43:55 +02:00
|
|
|
|
|
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-08 04:22:57 +02:00
|
|
|
|
2010-12-17 22:22:33 +01:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-09 18:15:00 +02:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-16 20:43:55 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
firewire net, ipv4 arp: Extend hardware address and remove driver-level packet inspection.
Inspection of upper layer protocol is considered harmful, especially
if it is about ARP or other stateful upper layer protocol; driver
cannot (and should not) have full state of them.
IPv4 over Firewire module used to inspect ARP (both in sending path
and in receiving path), and record peer's GUID, max packet size, max
speed and fifo address. This patch removes such inspection by extending
our "hardware address" definition to include other information as well:
max packet size, max speed and fifo. By doing this, The neighbour
module in networking subsystem can cache them.
Note: As we have started ignoring sspd and max_rec in ARP/NDP, those
information will not be used in the driver when sending.
When a packet is being sent, the IP layer fills our pseudo header with
the extended "hardware address", including GUID and fifo. The driver
can look-up node-id (the real but rather volatile low-level address)
by GUID, and then the module can send the packet to the wire using
parameters provided in the extendedn hardware address.
This approach is realistic because IP over IEEE1394 (RFC2734) and IPv6
over IEEE1394 (RFC3146) share same "hardware address" format
in their address resolution protocols.
Here, extended "hardware address" is defined as follows:
union fwnet_hwaddr {
u8 u[16];
struct {
__be64 uniq_id; /* EUI-64 */
u8 max_rec; /* max packet size */
u8 sspd; /* max speed */
__be16 fifo_hi; /* hi 16bits of FIFO addr */
__be32 fifo_lo; /* lo 32bits of FIFO addr */
} __packed uc;
};
Note that Hardware address is declared as union, so that we can map full
IP address into this, when implementing MCAP (Multicast Cannel Allocation
Protocol) for IPv6, but IP and ARP subsystem do not need to know this
format in detail.
One difference between original ARP (RFC826) and 1394 ARP (RFC2734)
is that 1394 ARP Request/Reply do not contain the target hardware address
field (aka ar$tha). This difference is handled in the ARP subsystem.
CC: Stephan Gatzka <stephan.gatzka@gmail.com>
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-03-25 08:26:16 +00:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
net: set name_assign_type in alloc_netdev()
Extend alloc_netdev{,_mq{,s}}() to take name_assign_type as argument, and convert
all users to pass NET_NAME_UNKNOWN.
Coccinelle patch:
@@
expression sizeof_priv, name, setup, txqs, rxqs, count;
@@
(
-alloc_netdev_mqs(sizeof_priv, name, setup, txqs, rxqs)
+alloc_netdev_mqs(sizeof_priv, name, NET_NAME_UNKNOWN, setup, txqs, rxqs)
|
-alloc_netdev_mq(sizeof_priv, name, setup, count)
+alloc_netdev_mq(sizeof_priv, name, NET_NAME_UNKNOWN, setup, count)
|
-alloc_netdev(sizeof_priv, name, setup)
+alloc_netdev(sizeof_priv, name, NET_NAME_UNKNOWN, setup)
)
v9: move comments here from the wrong commit
Signed-off-by: Tom Gundersen <teg@jklm.no>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-14 16:37:24 +02:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2014-04-29 18:49:47 +09:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-16 20:43:55 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-11-06 23:18:23 +01:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2013-03-25 08:25:57 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-02 21:09:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
firewire: net: set initial MTU = 1500 unconditionally, fix IPv6 on some CardBus cards
firewire-net, like the older eth1394 driver, reduced the initial MTU to
less than 1500 octets if the local link layer controller's asynchronous
packet reception limit was lower.
This is bogus, since this reception limit does not have anything to do
with the transmission limit. Neither did this reduction affect the TX
path positively, nor could it prevent link fragmentation at the RX path.
Many FireWire CardBus cards have a max_rec of 9, causing an initial MTU
of 1024 - 16 = 1008. RFC 2734 and RFC 3146 allow a minimum max_rec = 8,
which would result in an initial MTU of 512 - 16 = 496. On such cards,
IPv6 could only be employed if the MTU was manually increased to 1280 or
more, i.e. IPv6 would not work without intervention from userland.
We now always initialize the MTU to 1500, which is the default according
to RFC 2734 and RFC 3146.
On a VIA VT6316 based CardBus card which was affected by this, changing
the MTU from 1008 to 1500 also increases TX bandwidth by 6 %.
RX remains unaffected.
CC: netdev@vger.kernel.org
CC: linux1394-devel@lists.sourceforge.net
CC: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-10-23 16:30:56 +02:00
|
|
|
|
net: use core MTU range checking in misc drivers
firewire-net:
- set min/max_mtu
- remove fwnet_change_mtu
nes:
- set max_mtu
- clean up nes_netdev_change_mtu
xpnet:
- set min/max_mtu
- remove xpnet_dev_change_mtu
hippi:
- set min/max_mtu
- remove hippi_change_mtu
batman-adv:
- set max_mtu
- remove batadv_interface_change_mtu
- initialization is a little async, not 100% certain that max_mtu is set
in the optimal place, don't have hardware to test with
rionet:
- set min/max_mtu
- remove rionet_change_mtu
slip:
- set min/max_mtu
- streamline sl_change_mtu
um/net_kern:
- remove pointless ndo_change_mtu
hsi/clients/ssi_protocol:
- use core MTU range checking
- remove now redundant ssip_pn_set_mtu
ipoib:
- set a default max MTU value
- Note: ipoib's actual max MTU can vary, depending on if the device is in
connected mode or not, so we'll just set the max_mtu value to the max
possible, and let the ndo_change_mtu function continue to validate any new
MTU change requests with checks for CM or not. Note that ipoib has no
min_mtu set, and thus, the network core's mtu > 0 check is the only lower
bounds here.
mptlan:
- use net core MTU range checking
- remove now redundant mpt_lan_change_mtu
fddi:
- min_mtu = 21, max_mtu = 4470
- remove now redundant fddi_change_mtu (including export)
fjes:
- min_mtu = 8192, max_mtu = 65536
- The max_mtu value is actually one over IP_MAX_MTU here, but the idea is to
get past the core net MTU range checks so fjes_change_mtu can validate a
new MTU against what it supports (see fjes_support_mtu in fjes_hw.c)
hsr:
- min_mtu = 0 (calls ether_setup, max_mtu is 1500)
f_phonet:
- min_mtu = 6, max_mtu = 65541
u_ether:
- min_mtu = 14, max_mtu = 15412
phonet/pep-gprs:
- min_mtu = 576, max_mtu = 65530
- remove redundant gprs_set_mtu
CC: netdev@vger.kernel.org
CC: linux-rdma@vger.kernel.org
CC: Stefan Richter <stefanr@s5r6.in-berlin.de>
CC: Faisal Latif <faisal.latif@intel.com>
CC: linux-rdma@vger.kernel.org
CC: Cliff Whickman <cpw@sgi.com>
CC: Robin Holt <robinmholt@gmail.com>
CC: Jes Sorensen <jes@trained-monkey.org>
CC: Marek Lindner <mareklindner@neomailbox.ch>
CC: Simon Wunderlich <sw@simonwunderlich.de>
CC: Antonio Quartulli <a@unstable.cc>
CC: Sathya Prakash <sathya.prakash@broadcom.com>
CC: Chaitra P B <chaitra.basappa@broadcom.com>
CC: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>
CC: MPT-FusionLinux.pdl@broadcom.com
CC: Sebastian Reichel <sre@kernel.org>
CC: Felipe Balbi <balbi@kernel.org>
CC: Arvid Brodin <arvid.brodin@alten.se>
CC: Remi Denis-Courmont <courmisch@gmail.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-10-20 13:55:22 -04:00
|
|
|
|
2016-11-02 21:09:44 +01:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
firewire net, ipv4 arp: Extend hardware address and remove driver-level packet inspection.
Inspection of upper layer protocol is considered harmful, especially
if it is about ARP or other stateful upper layer protocol; driver
cannot (and should not) have full state of them.
IPv4 over Firewire module used to inspect ARP (both in sending path
and in receiving path), and record peer's GUID, max packet size, max
speed and fifo address. This patch removes such inspection by extending
our "hardware address" definition to include other information as well:
max packet size, max speed and fifo. By doing this, The neighbour
module in networking subsystem can cache them.
Note: As we have started ignoring sspd and max_rec in ARP/NDP, those
information will not be used in the driver when sending.
When a packet is being sent, the IP layer fills our pseudo header with
the extended "hardware address", including GUID and fifo. The driver
can look-up node-id (the real but rather volatile low-level address)
by GUID, and then the module can send the packet to the wire using
parameters provided in the extendedn hardware address.
This approach is realistic because IP over IEEE1394 (RFC2734) and IPv6
over IEEE1394 (RFC3146) share same "hardware address" format
in their address resolution protocols.
Here, extended "hardware address" is defined as follows:
union fwnet_hwaddr {
u8 u[16];
struct {
__be64 uniq_id; /* EUI-64 */
u8 max_rec; /* max packet size */
u8 sspd; /* max speed */
__be16 fifo_hi; /* hi 16bits of FIFO addr */
__be32 fifo_lo; /* lo 32bits of FIFO addr */
} __packed uc;
};
Note that Hardware address is declared as union, so that we can map full
IP address into this, when implementing MCAP (Multicast Cannel Allocation
Protocol) for IPv6, but IP and ARP subsystem do not need to know this
format in detail.
One difference between original ARP (RFC826) and 1394 ARP (RFC2734)
is that 1394 ARP Request/Reply do not contain the target hardware address
field (aka ar$tha). This difference is handled in the ARP subsystem.
CC: Stephan Gatzka <stephan.gatzka@gmail.com>
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-03-25 08:26:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2012-02-19 12:48:36 +01:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2013-03-25 08:26:24 +00:00
|
|
|
|
2012-02-19 12:48:36 +01:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
2009-06-16 20:43:55 +02:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2013-03-25 08:25:57 +00:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2013-03-25 08:25:57 +00:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-09 18:15:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-17 22:22:33 +01:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-17 22:22:33 +01:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2010-12-17 22:22:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2013-06-09 18:15:00 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2013-06-09 18:15:00 +02:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2010-11-06 23:18:23 +01:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2010-11-29 04:09:52 +02:00
|
|
|
|
|
|
|
|
|
2010-12-17 22:22:33 +01:00
|
|
|
|
2010-12-08 04:22:57 +02:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
2013-03-25 08:25:57 +00:00
|
|
|
|
|
|
|
|
|
2010-11-06 23:18:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-16 20:43:55 +02:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-06-14 11:45:27 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-25 08:26:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2012-02-18 22:01:54 +01:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2013-06-09 18:15:00 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2013-06-09 18:15:00 +02:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
|
|
|
|
|
2013-03-25 08:26:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2013-03-25 08:26:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-25 08:26:24 +00:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-25 08:26:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2013-03-25 08:26:24 +00:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-25 08:26:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2009-05-18 13:08:06 -04:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
2013-03-25 08:26:24 +00:00
|
|
|
|
2009-06-07 22:57:53 +02:00
|
|
|
|
|
|
|
|
|