Hello.
On 26-03-2013 7:59, Tony Cheneau wrote:
> Signed-off-by: Tony Cheneau
> ---
> net/ieee802154/6lowpan.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
> diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
> index 61eee9d..f952451 100644
> --- a/net/ieee80
YOSHIFUJI Hideaki wrote:
> Alexander Aring wrote:
:
>> With your patch, which isn't working anymore:
>>
>> iphc0 = 7b, iphc1 = 3b
>> NH flag is set, next header carried inline: 3a
>> source address stateless compression
>> (lowpan_uncompress_addr) linklocal address:
>> 02 85 00 3a 20 00 00 00
>> u
Signed-off-by: YOSHIFUJI Hideaki
---
net/ieee802154/6lowpan.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ieee802154/6lowpan.h b/net/ieee802154/6lowpan.h
index 8c2251f..bba5f83 100644
--- a/net/ieee802154/6lowpan.h
+++ b/net/ieee802154/6lowpan.h
@@ -84,7 +84,7 @@
Hi,
Alexander Aring wrote:
> Hi,
>
> I don't know if this is a right solution for that, because other
> functions like addrconf_ifid_infiniband to manipulate eui after memcpy,
> too.
>
> But this patch solves my problems with ieee802154 stack.
What kind of problems do you have?
--yoshfuji
---
On Thu, 2013-03-07 at 21:13 +0100, Alexander Aring wrote:
> The function addrconf_ifid_eui64 will copy eui into dev->dev_addr.
> We need first to manipulate eui[0] before we call memcpy afterwards.
memcpy() does not work that way.
> Broken since commit:
> 5e98a36ed4bf6ea396170e3af0dd4fcbe51d772f
Hello.
On 04/02/2013 10:47 PM, Alan Ott wrote:
> Use netif_stop_queue() and netif_wake_queue() to control the flow of
> packets to mac802154 devices. Since many IEEE 802.15.4 devices have no
> output buffer, and since the mac802154 xmit() function is designed to
> block, netif_stop_queue() is ca
Alexander Aring wrote:
> Hi,
>
> On Fri, Mar 08, 2013 at 11:21:38AM +0900, YOSHIFUJI Hideaki wrote:
>> Hi,
>>
>> Alexander Aring wrote:
>>> Hi,
>>>
>>> I don't know if this is a right solution for that, because other
>>> functions like addrconf_ifid_infiniband to manipulate eui after memcpy,
>>> t
This makes documented use of "struct ieee802154_mlme_ops" follow
current use, in which some operations are regularly left out,
making them NULL. Since the calls did not check for NULL, any
attempted use caused an oops.
This patch makes the following operations optional and returns
EOPNOTSUPP if th
It served no purpose: we never call it from anywhere in the stack
and the only driver that did implement it (fakehard) merely provided
a dummy value.
There is also considerable doubt whether it would make sense to
even attempt beacon processing at this level in the Linux kernel.
Signed-off-by: We
The second of these two patches makes operations optional which we
currently use as if they were optional but they were not. This caused
some uses of linux-zigbee user space tools to oops the kernel.
This is an update of the patch I posted last week, with EINVAL changed
to EOPNOTSUPP, and correcte
On 04/02/2013 10:30 PM, David Miller wrote:
> From: Alan Ott
> Date: Tue, 02 Apr 2013 22:25:28 -0400
>
>> The workqueue in mac802154 is only needed because the current mac802154
>> xmit() function is designed to be blocking and synchronous.
>>
>> Prior to my patch (#3/6), that very same workqueue
Alan Ott wrote:
> 1. Most supported devices have only single packet output buffer, so
> blocking in the driver is the most straight-forward way to handle it.
> The alternative is to make each driver have a workqueue for xmit() (to
> lift the blocking out from atomic context). This makes each driver
From: Alan Ott
Date: Tue, 02 Apr 2013 22:25:28 -0400
> The workqueue in mac802154 is only needed because the current mac802154
> xmit() function is designed to be blocking and synchronous.
>
> Prior to my patch (#3/6), that very same workqueue would actually queue
> up packets (without bound). T
On 04/02/2013 10:03 PM, David Miller wrote:
> From: Alan Ott
> Date: Tue, 02 Apr 2013 21:59:37 -0400
>
>> On 04/02/2013 09:56 PM, David Miller wrote:
>>> From: Alan Ott
>>> Date: Tue, 02 Apr 2013 21:24:59 -0400
>>>
I like it for a couple of reasons.
1. Most supported devices have only s
From: Alan Ott
Date: Tue, 02 Apr 2013 21:59:37 -0400
> On 04/02/2013 09:56 PM, David Miller wrote:
>> From: Alan Ott
>> Date: Tue, 02 Apr 2013 21:24:59 -0400
>>
>>> I like it for a couple of reasons.
>>> 1. Most supported devices have only single packet output buffer, so
>>> blocking in the driv
On 04/02/2013 09:56 PM, David Miller wrote:
> From: Alan Ott
> Date: Tue, 02 Apr 2013 21:24:59 -0400
>
>> I like it for a couple of reasons.
>> 1. Most supported devices have only single packet output buffer, so
>> blocking in the driver is the most straight-forward way to handle it.
>> The altern
From: Alan Ott
Date: Tue, 02 Apr 2013 21:24:59 -0400
> I like it for a couple of reasons.
> 1. Most supported devices have only single packet output buffer, so
> blocking in the driver is the most straight-forward way to handle it.
> The alternative is to make each driver have a workqueue for xmi
On 04/02/2013 07:13 PM, Werner Almesberger wrote:
> Alan Ott wrote:
>> it's now my opinion that we should _not_ try to retransmit at
>> all in mac802154/tx.c.
> I think the currently blocking workqueue design is ugly and
> quite contrary to how most the rest of the stack works. So
> anything that k
Alan Ott wrote:
> it's now my opinion that we should _not_ try to retransmit at
> all in mac802154/tx.c.
I think the currently blocking workqueue design is ugly and
quite contrary to how most the rest of the stack works. So
anything that kills it has my blessing :-)
I do wonder though why it was
On 04/02/2013 05:28 PM, Alan Ott wrote:
> According to 7.5.6.5 of IEEE 802.15.4-2003, if the retransmission fails
> more than aMaxFrameRetries (3) times, it is assumed that it has failed.
> Since some transceivers (and I would assume most if not all) do this in
> hardware, it's now my opinion that
On 04/02/2013 04:28 PM, Alan Ott wrote:
> On 04/02/2013 03:11 PM, Alexander Smirnov wrote:
>> 2013/4/2 Alan Ott mailto:a...@signal11.us>>
>>
>> When ops->xmit() fails, immediately retry. Previously the packet was
>> sent
>> to the back of the workqueue.
>>
>> Signed-off-by: Alan Ott
On 04/02/2013 03:11 PM, Alexander Smirnov wrote:
> 2013/4/2 Alan Ott mailto:a...@signal11.us>>
>
> When ops->xmit() fails, immediately retry. Previously the packet was
> sent
> to the back of the workqueue.
>
> Signed-off-by: Alan Ott mailto:a...@signal11.us>>
> ---
> net
On 04/02/2013 03:21 PM, Alexander Smirnov wrote:
>
>
>
> 2013/4/2 Alan Ott mailto:a...@signal11.us>>
>
> dev_queue_xmit() can return positive error codes, so check for
> nonzero.
>
> Signed-off-by: Alan Ott mailto:a...@signal11.us>>
> ---
> net/ieee802154/6lowpan.c | 2 +-
>
2013/4/2 Alan Ott
> dev_queue_xmit() will return a positive value if the packet could not be
> queued, often because the real network device (in our case the mac802154
> wpan device) has its queue stopped. lowpan_xmit() should return that value
> to the higher layer so the higher layer will retr
2013/4/2 Alan Ott
> dev_queue_xmit() can return positive error codes, so check for nonzero.
>
> Signed-off-by: Alan Ott
> ---
> net/ieee802154/6lowpan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
> index e1b4580..
2013/4/2 Alan Ott
> When ops->xmit() fails, immediately retry. Previously the packet was sent
> to the back of the workqueue.
>
> Signed-off-by: Alan Ott
> ---
> net/mac802154/tx.c | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/net/mac802154/tx.c b/ne
Use netif_stop_queue() and netif_wake_queue() to control the flow of
packets to mac802154 devices. Since many IEEE 802.15.4 devices have no
output buffer, and since the mac802154 xmit() function is designed to
block, netif_stop_queue() is called after each packet.
Signed-off-by: Alan Ott
---
ne
dev_queue_xmit() can return positive error codes, so check for nonzero.
Signed-off-by: Alan Ott
---
net/ieee802154/6lowpan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index e1b4580..a68c792 100644
--- a/net/ieee802154/
Increase the buffer length from 10 to 300 packets. Consider that traffic on
mac802154 devices will often be 6LoWPAN, and a full-length (1280 octet)
IPv6 packet will fragment into 15 6LoWPAN fragments (because the MTU of
IEEE 802.15.4 is 127). A 300-packet queue is really 20 full-length IPv6
packet
These patches fix an issue in the 802.15.4 code where the output buffer
(which prior to this patchset is just a workqueue) can grow to an arbitrary
size. This is basically fixed as follows:
1. Use netif_stop_queue() and netif_wake_queue() to stop and start the
transmit queue, preventing packets f
dev_queue_xmit() will return a positive value if the packet could not be
queued, often because the real network device (in our case the mac802154
wpan device) has its queue stopped. lowpan_xmit() should return that value
to the higher layer so the higher layer will retry sending the packet.
Signe
There's no reason to have it in the work struct anymore.
Signed-off-by: Alan Ott
---
net/mac802154/tx.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/mac802154/tx.c b/net/mac802154/tx.c
index fbf937c..a248246 100644
--- a/net/mac802154/tx.c
+++ b/net/mac802154/tx.c
When ops->xmit() fails, immediately retry. Previously the packet was sent
to the back of the workqueue.
Signed-off-by: Alan Ott
---
net/mac802154/tx.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/net/mac802154/tx.c b/net/mac802154/tx.c
index 4e09d07..fbf9
33 matches
Mail list logo
