mum datagram size /with/ link fragmentation is 0xfff = 4095
for unicast and broadcast. This is because the RFC 2734 fragment
encapsulation header field for datagram size is only 12 bits wide.
Fixes: 5d48f00d836a('firewire: net: fix maximum possible MTU')
Signed-off-by: Stefan Richter
---
dri
Fixes: d894be57ca92('ethernet: use net core MTU range checking in more drivers')
CC: Jarod Wilson
CC: Thomas Falcon
Signed-off-by: Stefan Richter
---
drivers/net/ethernet/broadcom/sb1250-mac.c | 2 +-
drivers/net/ethernet/ibm/ibmveth.c | 2 +-
2 files changed, 2 insert
h 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-de...@lists.sourceforge.net
CC: Jarod Wilson
Signed-off-by: Stefan Richter
---
v2: use ETH_DATA_LEN, add comment
drivers/firewire/net.
h 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-de...@lists.sourceforge.net
CC: Jarod Wilson
Signed-off-by: Stefan Richter
---
drivers/firewire/net.c | 8 +---
1 file changed, 1 inse
TU range checking in misc drivers')
CC: netdev@vger.kernel.org
CC: linux1394-de...@lists.sourceforge.net
CC: Jarod Wilson
Signed-off-by: Stefan Richter
---
drivers/firewire/net.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/firewire/net.c b/drivers/fir
Adding Cc: linux1394-devel, dropping several Ccs, no additional comment.
On Oct 22 Stefan Richter wrote:
> On Oct 20 Jarod Wilson wrote:
> > firewire-net:
> > - set min/max_mtu
> > - remove fwnet_change_mtu
> [...]
> > --- a/drivers/firewire/net.c
&g
net->mtu should be initialized to 1500, not less. But such a change
should be done in a separate patch.
--
Stefan Richter
-==- =-=- =-==-
http://arcgraph.de/sr/
On Oct 22 Stefan Richter wrote:
> On Oct 19 Jarod Wilson wrote:
> > On Thu, Oct 20, 2016 at 12:38:46AM +0200, Stefan Richter wrote:
> > > On Oct 19 Sabrina Dubroca wrote:
> > > > 2016-10-18, 22:33:33 -0400, Jarod Wilson wrote:
[...]
> > > > > @@ -14
> The 8191 was simply transplanted from right here. I think altering the
> value should be the subject of a separate patch.
You transplanted the value but dropped the comment. Though Denis' reply
sounds like the comment should have been /* FIXME, set by RxDMAFrameLen */.
--
Stefan Richter
-==- =-=- =-==-
http://arcgraph.de/sr/
On Oct 19 Jarod Wilson wrote:
> On Thu, Oct 20, 2016 at 12:38:46AM +0200, Stefan Richter wrote:
> > On Oct 19 Sabrina Dubroca wrote:
> > > 2016-10-18, 22:33:33 -0400, Jarod Wilson wrote:
> > > [...]
> > > > diff --git a/drivers/firewire/net.c b/drivers/firewi
attempt to
find the maximum speed and size that is supported by all potential
listeners). This limits the payload to 512 bytes.
Unicast packets are transmitted via IEEE 1394 asynchronous write request
packets at optimum speed. In most cases, this means that 2048 bytes
payload is possible, in so
) which AFAIU features the mentioned
changes.
--
Stefan Richter
-=-==--- --=- =--==
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
th Ethernet, would be at least as interesting as
bonding several FireWire interfaces, since most FireWire equipped
machines come with only one FireWire link and one or two Ethernet links.
--
Stefan Richter
-=-=-=== =-=- -===-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line &q
may "just work".
Sounds promising. I will keep an eye on it.
--
Stefan Richter
-=-=-=== =-=- -==-=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
ew occurrences of EOPNOTSUPP. Unless I
missed something, they are all related to setting the hardware address
of the interface. AFAICS this is impossible with IP over FireWire. If
it is crucial to bonding to be able to change the slaves' hardware
addresses, then you are out of luck.
--
Stefa
Nick Piggin wrote:
> Stefan Richter wrote:
>> Nick Piggin wrote:
>>
>>> I don't know why people would assume volatile of atomics. AFAIK, most
>>> of the documentation is pretty clear that all the atomic stuff can be
>>> reordered etc. except for those
e of
a some infrastructure code here and there)...
> and learning the Linux memory model, they can still be productive
> writing safely locked code.
Provided they are aware that they might not have the full picture of the
lockless primitives. :-)
--
Stefan Richter
-=-=-=== =--- =---=
h
me,
I don't plan to continue with an actual audit of the drivers I maintain.
It's an important issue, but my current time budget will restrict me to
look at it ad hoc, per case. (Open bugs have higher priority than
potential bugs.)
--
Stefan Richter
-=-=-=== =--- =---=
http://arcgraph.de
Nick Piggin wrote:
> Stefan Richter wrote:
>> For architecture port authors, there is Documentation/atomic_ops.txt.
>> Driver authors also can learn something from that document, as it
>> indirectly documents the atomic_t and bitops APIs.
>
> "Semantics an
er. Sure, now
that I learned of these properties I can start to audit code and insert
barriers where I believe they are needed, but this simply means that
almost all occurrences of atomic_read will get barriers (unless there
already are implicit but more or less obvious barriers like msleep).
--
St
atomic_dec(&j->DSPWrite);
>
> ...besides that, there are couple of more similar cases in the same file
> (with braces)...
Generally, ixj.c has several occurrences of couples of atomic write and
atomic read which potentially do not do what the author wanted.
--
Stefan Richter
-=-
I wrote:
> Herbert Xu wrote:
>> On Thu, Aug 16, 2007 at 10:06:31AM +0200, Stefan Richter wrote:
[...]
>>> expectation that each
>>> occurrence of atomic_read actually results in a load operation, i.e. is
>>> not optimized away.
[...]
>> Can you find an act
Herbert Xu wrote:
> On Thu, Aug 16, 2007 at 10:06:31AM +0200, Stefan Richter wrote:
>> >
>> > Do you (or anyone else for that matter) have an example of this?
>>
>> The only code I somewhat know, the ieee1394 subsystem, was perhaps
>> authored and is cu
subsystem brings to light. I now noticed an apparently
unused struct member in the bitrotting pcilynx driver, and more
importantly, a pairing of two atomic_t variables in raw1394 that should
be audited for race conditions and for possible replacement by plain int.
--
Stefan Richter
-=-=-=== =--
c = atomic_read(a);
if (c != b) {
b = c;
i = 0;
}
}
> Nope, we're calling schedule which is a rather heavy-weight
> barrier.
How does the compiler know that msleep() has got barrier()s?
--
Stefan Richt
st);
/* If we get a reset before we are done waiting, then
* start the waiting over again */
if (generation != g)
g = generation, i = 0;
}
[... scan bus, using generation ...]
}
exit:
[...]
thing_more();
> }
>
> static void C(atomic_t *a)
> {
> A(a);
> B(b);
/* ^ typo */
B(a);
> }
>
> Would this need forget(a) after A(a)?
>
> (Is the latter actually answered in C99 or is it compiler-dependent?)
--
Stefan Richter
-=-=-
Satyam Sharma wrote:
> On Wed, 15 Aug 2007, Stefan Richter wrote:
>> Doesn't "atomic WRT all processors" require volatility?
>
> No, it definitely doesn't. Why should it?
>
> "Atomic w.r.t. all processors" is just your normal, simple "
ones who must be fixed instead, IMHO. ]
LDD3 says on page 125: "The following operations are defined for the
type [atomic_t] and are guaranteed to be atomic with respect to all
processors of an SMP computer."
Doesn't "atomic WRT all processors" require volatility?
--
Stef
http://lkml.org/lkml/2007/6/30/107 :
| I don't see how git could tell you to Cc net patches to
| [EMAIL PROTECTED]
Ditto with problem reports.
For example, Cc'ing linux1394-devel on FireWire topics is a lot more
important than Cc'ing me.
--
Stefan Richter
-=-=-=== =--- -
ht
Robert P. J. Day wrote:
> i *did* submit a preliminary patch once upon a time, and it
> (predictably) went nowhere.
A patch which pulls the word "experimental" into prompts or adds a
dedicated directive for tagging of options? Can't find it in archive
observed that feature requests
don't set anything in motion until a first patch is sent. Even a patch
that is far from perfect can get things going really quickly. (If the
requested feature makes sense to other people.)
--
Stefan Richter
-=-=-=== -=== =--==
http://arcgraph.de/sr/
-
To unsu
Cornelia Huck wrote:
> On Thu, 12 Jul 2007 07:47:52 +0200,
> Stefan Richter <[EMAIL PROTECTED]> wrote:
>> Also keep in mind that either device_move() should update the numa_node,
>> or the subsystems which call device_move() should explicitly update it
>> on their
Yinghai Lu wrote:
> Stefan Richter wrote:
>> Yinghai Lu wrote:
>>> original default is -1, and this patch just try to use parent's node as
>>> default.
>>
>> But in many cases, the patch does so at a time when the parent is not
>> yet known.
> t
Yinghai Lu wrote:
> original default is -1, and this patch just try to use parent's node as
> default.
But in many cases, the patch does so at a time when the parent is not
yet known.
--
Stefan Richter
-=-=-=== -=== -==--
http://arcgraph.de/sr/
-
To unsubscribe from this list: se
I wrote:
> - device_move() should update the device.node.
device.numa_node of course.
--
Stefan Richter
-=-=-=== -=== -=-==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo
ivers/input/gameport/gameport.c::
gameport_init_port() which sets the parent device *after* the
call to device_initialize().
- device_move() should update the device.node.
--
Stefan Richter
-=-=-=== -=== -=-==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line &
Association of a host device with a node on NUMA machines optimizes
allocations of skbs given from the networking stack to eth1394.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
Note, in Linux 2.6.20 and earlier and 2.6.23 and later, eth1394 calls
or will call SET_NETD
its on top of ohci1394 = PCI driver for FireWire
controllers.)
I guess it should be the lowlevel's pci_dev.dev, unless the midlayer
cares to set
set_dev_node(&midlayer_dev.dev, dev_to_node(midlayer_dev.dev.parent));
And either way, for full effect of NUMA awareness in the highlevel
network dr
On 2 Apr, I wrote:
> +static int eth1394_data_len = 1500;
> +module_param_named(mtu, eth1394_data_len, int, S_IRUGO | S_IWUSR);
> +MODULE_PARM_DESC(mtu, "MTU (default = 1500)");
Can be solved without a new module load parameter.
From: Stefan Richter <[EMAIL PROTECT
Adjust white space and line wraps. Remove unnecessary parentheses and
braces, unused macros, and some of the more redundant comments.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/eth1394.c | 426 +
drivers/ieee1394/eth1394.h
Move common code into an extra function. This implicitly adds a missing
node_info->fifo = CSR1212_INVALID_ADDR_SPACE; to .update.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/eth1394.c | 48 -
1 file changed, 16 insertio
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/eth1394.c | 40 ++---
1 file changed, 16 insertions(+), 24 deletions(-)
Index: linux/drivers/ieee1394/eth
Call only eth1394's own host reset handler from .tx_timeout, not the
reset hooks of all other IEEE 1394 drivers.
A minor drawback of this patch is that ether1394_host_reset by timeout
is not serialized against ether1394_host_reset by bus reset.
Signed-off-by: Stefan Richter <[EMAIL P
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/eth1394.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
Index: linux/drivers/ieee1394/eth1394.c
===
--- linux.orig/drivers/ie
The old argument calculated the correct value in a wrong way.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/eth1394.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/drivers/ieee1394/eth
e1394/eth1394.h | 24 -
2 files changed, 268 insertions(+), 359 deletions(-)
--
Stefan Richter
-=-=-=== -=-- ---=-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/eth1394.c |2 ++
1 file changed, 2 insertions(+)
Index: linux/drivers/ieee1394/eth1394.c
===
--- linux.orig/drivers/ieee1394/eth1394.c
+++ linux/d
This patch actually doesn't change anything because there was always 0
== NETDEV_TX_OK returned before.
TODO: Return NETDEV_TX_BUSY in error case and test in different error
conditions.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/eth13
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/eth1394.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Index: linux/drivers/ieee1394/eth1394.c
===
--- linux.orig/drivers/ieee1394/eth
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/eth1394.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
Index: linux/drivers/ieee1394/eth1394.c
===
--- linux.orig/drivers/ieee1394/eth
offset > fi->offset + fi->len - 1 == !(offset < fi->offset + fi->len)
offset + len - 1 < fi->offset == !(offset + len > fi->offset)
!(A || B) == (!A && !B)
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/eth1394.c |
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/eth1394.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
Index: linux/drivers/ieee1394/eth1394.c
===
--- linux.orig/d
We can't reconfigure the MAC address, hence we don't need the callback.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/eth1394.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
Index: linux/drivers/ie
because CONFIG_IEEE1394_ETH1394 depends on it.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/eth1394.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
Index: linux/drivers/ieee1394/eth
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/eth1394.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
Index: linux/drivers/ieee1394/eth1394.c
===
--- linux.orig/d
quite low to me.
We use it to keep track of IEEE 1394 transactions [ = outgoing request
&& (incoming response || expiry)], with completion of transactions often
in-order due to mostly single-threaded usage, but sometimes out-of-order
(may happen regardless of multithreaded or single-thread
[] sys_ioctl+0x6a/0xa0
>> [] system_call+0x7e/0x83
>> [<2b2d76ab98a9>]
>
> is this a real scenario, or is this a case of "firewire is special and
> needs it's own rules"?
Well, firewire is special, but that should already be addressed by this
patch: "lock
...and __constant_ntohs, __constant_ntohl, __constant_cpu_to_be32 too
where possible. Htons and friends are resolved to constants in these
places anyway. Also fix an endianess glitch in a log message, spotted
by Alexey Dobriyan.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
d
Alexey Dobriyan wrote on 2006-05-27:
On Sat, May 27, 2006 at 12:05:40PM +0200, Stefan Richter wrote:
Did you have the chance to test your patch on different
platforms and with different peer OSs/platforms?
Unfortunately not.
The patch works OK on an x86/Linux host with x86/WinXP peer and
x_stream_connect()
differs a bit from stock unix_stream_connect(). I see spin_lock_bh() in
2.6.17-rc5-mm3 where 2.6.17-rc5 has spin_lock().
(added Cc: netdev)
--
Stefan Richter
-=-=-==- -==- --==-
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe net
d unmaintained)? If not, I
could send it along with a few other 1394 patches to akpm soon.
--
Stefan Richter
-=-=-==- -=-= ==-==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordom
62 matches
Mail list logo
