ur ack when you are happy so I can apply it
to my tree?
Acked-by: Alan Ott <a...@signal11.us>
BIT_TXNIE | BIT_TXNIE, BIT_TXNIE | BIT_TXNIE);
+ BIT_TXNIE | BIT_RXIE, BIT_TXNIE | BIT_RXIE);
}
static int mrf24j40_set_channel(struct ieee802154_hw *hw, u8 page, u8 channel)
Could you review this and give me your ack when you are happy so I can apply it
to my tree?
A
return -EINVAL;
+ ret = -EINVAL;
+ goto err_register_device;
}
ret = mrf24j40_hw_init(devrec);
Acked-by: Alan Ott <a...@signal11.us>
ret = -EINVAL;
+ goto err_register_device;
}
ret = mrf24j40_hw_init(devrec);
Acked-by: Alan Ott
Update documented paths for arm64 files to match current tree.
Signed-off-by: Alan Ott
---
Documentation/efi-stub.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt
index 7747024..e157469 100644
--- a/Documentation
Update documented paths for arm64 files to match current tree.
Signed-off-by: Alan Ott <a...@softiron.co.uk>
---
Documentation/efi-stub.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt
index 7747024..e
On 11/28/2015 11:03 AM, Alan Ott wrote:
Update documented paths for arm64 files to match current tree.
---
Documentation/efi-stub.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt
index 7747024..e157469 100644
Update documented paths for arm64 files to match current tree.
---
Documentation/efi-stub.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt
index 7747024..e157469 100644
--- a/Documentation/efi-stub.txt
+++
Update documented paths for arm64 files to match current tree.
---
Documentation/efi-stub.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt
index 7747024..e157469 100644
--- a/Documentation/efi-stub.txt
+++
On 11/28/2015 11:03 AM, Alan Ott wrote:
Update documented paths for arm64 files to match current tree.
---
Documentation/efi-stub.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt
index 7747024..e157469 100644
linux-arm-kernel, since arm64 triggers this issue.
Thanks Ming and testers for your hard work on this.
Tested-by: Alan Ott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
bio->bi_seg_back_size)
+ bio->bi_seg_back_size = seg_size;
+
+ return do_split ? new : NULL;
}
void blk_queue_split(struct request_queue *q, struct bio **bio,
I applied both your patches and tested on Overdrive 3000. This fixes the
issue for me.
Added linux-arm-kernel
On 06/23/2015 10:52 AM, Antonio Borneo wrote:
In ancient times it was necessary to manually initialize the bus
field of an spi_driver to spi_bus_type. These days this is done in
spi_register_driver(), so we can drop the manual assignment.
Signed-off-by: Antonio Borneo
To: Alan Ott
To: Alan Ott a...@signal11.us
To: Alexander Aring alex.ar...@gmail.com
To: Varka Bhadram varkabhad...@gmail.com
To: linux-w...@vger.kernel.org
To: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ieee802154/cc2520.c | 1 -
drivers/net/ieee802154/mrf24j40.c | 1 -
2 files
Alan is the original author of the driver. This change was discussed
with the 802.15.4 subsystem maintainer, Alexander Aring.
Signed-off-by: Alan Ott
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2f85f55..c066da4 100644
Alan is the original author of the driver. This change was discussed
with the 802.15.4 subsystem maintainer, Alexander Aring.
Signed-off-by: Alan Ott a...@signal11.us
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2f85f55..c066da4 100644
On 01/17/2014 08:20 PM, Russell King - ARM Linux wrote:
On Fri, Jan 17, 2014 at 07:57:16PM -0500, Alan Ott wrote:
On 01/17/2014 08:46 AM, Russell King - ARM Linux wrote:
My suspicion therefore is that some other thread must have died while
holding the mmap_sem, so there's probably a kernel
On 01/17/2014 08:20 PM, Russell King - ARM Linux wrote:
On Fri, Jan 17, 2014 at 07:57:16PM -0500, Alan Ott wrote:
On 01/17/2014 08:46 AM, Russell King - ARM Linux wrote:
My suspicion therefore is that some other thread must have died while
holding the mmap_sem, so there's probably a kernel
On 01/17/2014 08:46 AM, Russell King - ARM Linux wrote:
On Wed, Jan 15, 2014 at 08:13:04PM -0500, Alan Ott wrote:
So my questions are:
1. Why don't I see a full backtrace beyond the exception stack? It's the
same when dump_stack() is called manually.
No idea - it looks like you're not using
On 01/17/2014 08:46 AM, Russell King - ARM Linux wrote:
On Wed, Jan 15, 2014 at 08:13:04PM -0500, Alan Ott wrote:
So my questions are:
1. Why don't I see a full backtrace beyond the exception stack? It's the
same when dump_stack() is called manually.
No idea - it looks like you're not using
Hello,
I have a deadlock that I'm trying to understand. The symptom is multiple
tasks trying to acquire a read lock (down_read()) on mm->mmap_sem in
do_page_fault(). I'll be right up front and say that this is a fairly
old kernel (2.6.37 TI PSP kernel) on a fairly old processor DaVinci 6446.
Hello,
I have a deadlock that I'm trying to understand. The symptom is multiple
tasks trying to acquire a read lock (down_read()) on mm-mmap_sem in
do_page_fault(). I'll be right up front and say that this is a fairly
old kernel (2.6.37 TI PSP kernel) on a fairly old processor DaVinci 6446.
Eliminate all the workqueue and interrupt enable/disable.
Signed-off-by: Alan Ott
---
drivers/net/ieee802154/mrf24j40.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40.c
index
This avoids a race condition where complete(tx_complete) could be called
before tx_complete is initialized.
Signed-off-by: Alan Ott
---
drivers/net/ieee802154/mrf24j40.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net
-triggered fixes this issue.
Signed-off-by: Alan Ott
---
drivers/net/ieee802154/mrf24j40.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40.c
index c1bc688..0632d34 100644
--- a/drivers/net/ieee802154/mrf24j40.c
the enable/disable of
interrupts in the driver has recently been a lighning rod whenever issues
arise related to interrupts (costing engineering time), and since threaded
interrupts are the right way to do it.
Alan Ott (3):
mrf24j40: Move INIT_COMPLETION() to before packet transmission
mrf24j40: Use
Refuse to create 6lowpan links if the actual hardware interface is
of any type other than ARPHRD_IEEE802154.
Signed-off-by: Alan Ott
Suggested-by: Alexander Aring
---
net/ieee802154/6lowpan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154
When a lowpan link to a wpan device is created, set the hardware address
of the lowpan link to that of the wpan device.
Signed-off-by: Alan Ott
---
net/ieee802154/6lowpan.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 8f56b2b
Alexander Aring suggested that devices desired to be linked to 6lowpan
be checked for actually being of type IEEE802154, since IEEE802154 devices
are all that are supported by 6lowpan at present.
Alan Ott (2):
6lowpan: Only make 6lowpan links to IEEE802154 devices
6lowpan: Sync default
On 10/05/2013 08:24 PM, Alexander Aring wrote:
Hi Alan,
On Sat, Oct 05, 2013 at 05:38:00PM -0400, Alan Ott wrote:
When a lowpan link to a wpan device is created, set the hardware address
of the lowpan link to that of the wpan device.
Signed-off-by: Alan Ott
---
net/ieee802154/6lowpan.c | 3
When a lowpan link to a wpan device is created, set the hardware address
of the lowpan link to that of the wpan device.
Signed-off-by: Alan Ott
---
net/ieee802154/6lowpan.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index c85e71e
When a lowpan link to a wpan device is created, set the hardware address
of the lowpan link to that of the wpan device.
Signed-off-by: Alan Ott a...@signal11.us
---
net/ieee802154/6lowpan.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
On 10/05/2013 08:24 PM, Alexander Aring wrote:
Hi Alan,
On Sat, Oct 05, 2013 at 05:38:00PM -0400, Alan Ott wrote:
When a lowpan link to a wpan device is created, set the hardware address
of the lowpan link to that of the wpan device.
Signed-off-by: Alan Otta...@signal11.us
---
net
Alexander Aring suggested that devices desired to be linked to 6lowpan
be checked for actually being of type IEEE802154, since IEEE802154 devices
are all that are supported by 6lowpan at present.
Alan Ott (2):
6lowpan: Only make 6lowpan links to IEEE802154 devices
6lowpan: Sync default
When a lowpan link to a wpan device is created, set the hardware address
of the lowpan link to that of the wpan device.
Signed-off-by: Alan Ott a...@signal11.us
---
net/ieee802154/6lowpan.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
Refuse to create 6lowpan links if the actual hardware interface is
of any type other than ARPHRD_IEEE802154.
Signed-off-by: Alan Ott a...@signal11.us
Suggested-by: Alexander Aring alex.ar...@gmail.com
---
net/ieee802154/6lowpan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net
-triggered fixes this issue.
Signed-off-by: Alan Ott a...@signal11.us
---
drivers/net/ieee802154/mrf24j40.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40.c
index c1bc688..0632d34 100644
--- a/drivers/net
the enable/disable of
interrupts in the driver has recently been a lighning rod whenever issues
arise related to interrupts (costing engineering time), and since threaded
interrupts are the right way to do it.
Alan Ott (3):
mrf24j40: Move INIT_COMPLETION() to before packet transmission
mrf24j40: Use
This avoids a race condition where complete(tx_complete) could be called
before tx_complete is initialized.
Signed-off-by: Alan Ott a...@signal11.us
---
drivers/net/ieee802154/mrf24j40.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b
Eliminate all the workqueue and interrupt enable/disable.
Signed-off-by: Alan Ott a...@signal11.us
---
drivers/net/ieee802154/mrf24j40.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154
On 05/23/2013 01:54 PM, David Hauweele wrote:
> 2013/5/23 Alan Ott :
>> On 5/22/13 4:32 PM, David Hauweele wrote:
>>>
>>> I cannot use level-triggered interrupts with GPIO on the RPi, so I
>>> cannot test this specific patch.
>>
>>
>> Is th
seeing issues.
Alan.
2013/5/22 Alan Ott :
On 05/21/2013 10:01 PM, Alan Ott wrote:
David Hauweele noticed that the mrf24j40 would hang arbitrarily after some
period of heavy traffic. Two race conditions were discovered, and the
driver was changed to use threaded interrupts, since the enable/disable
seeing issues.
Alan.
2013/5/22 Alan Ott a...@signal11.us:
On 05/21/2013 10:01 PM, Alan Ott wrote:
David Hauweele noticed that the mrf24j40 would hang arbitrarily after some
period of heavy traffic. Two race conditions were discovered, and the
driver was changed to use threaded interrupts, since
On 05/23/2013 01:54 PM, David Hauweele wrote:
2013/5/23 Alan Ott a...@signal11.us:
On 5/22/13 4:32 PM, David Hauweele wrote:
I cannot use level-triggered interrupts with GPIO on the RPi, so I
cannot test this specific patch.
Is there another interrupt line you can tie into which does
On 05/21/2013 10:01 PM, Alan Ott wrote:
> David Hauweele noticed that the mrf24j40 would hang arbitrarily after some
> period of heavy traffic. Two race conditions were discovered, and the
> driver was changed to use threaded interrupts, since the enable/disable of
> interrupts in th
arise related to interrupts (costing engineering time), and since threaded
interrupts are the right way to do it.
Alan Ott (3):
mrf24j40: Move INIT_COMPLETION() to before packet transmission
mrf24j40: Use threaded IRQ handler
mrf24j40: Use level-triggered interrupts
drivers/net/ieee802154
This avoids a race condition where complete(tx_complete) could be called
before tx_complete is initialized.
Signed-off-by: Alan Ott
---
drivers/net/ieee802154/mrf24j40.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net
Eliminate all the workqueue and interrupt enable/disable.
Signed-off-by: Alan Ott
---
drivers/net/ieee802154/mrf24j40.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40.c
index
-triggered fixes this issue.
Signed-off-by: Alan Ott
---
drivers/net/ieee802154/mrf24j40.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40.c
index a55ab8d..d59dbff 100644
--- a/drivers/net/ieee802154/mrf24j40.c
On 05/21/2013 12:17 PM, David Hauweele wrote:
> 2013/5/20 Alan Ott :
>> On 05/16/2013 05:34 PM, David Hauweele wrote:
>>> I have seen the interrupt line going low forever with heavy traffic.
>> I've been doing some testing today and I can reproduce your issue i
On 05/21/2013 12:17 PM, David Hauweele wrote:
2013/5/20 Alan Ott a...@signal11.us:
On 05/16/2013 05:34 PM, David Hauweele wrote:
I have seen the interrupt line going low forever with heavy traffic.
I've been doing some testing today and I can reproduce your issue if I
ping -f both ways
-triggered fixes this issue.
Signed-off-by: Alan Ott a...@signal11.us
---
drivers/net/ieee802154/mrf24j40.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40.c
index a55ab8d..d59dbff 100644
--- a/drivers/net
Eliminate all the workqueue and interrupt enable/disable.
Signed-off-by: Alan Ott a...@signal11.us
---
drivers/net/ieee802154/mrf24j40.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154
This avoids a race condition where complete(tx_complete) could be called
before tx_complete is initialized.
Signed-off-by: Alan Ott a...@signal11.us
---
drivers/net/ieee802154/mrf24j40.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b
arise related to interrupts (costing engineering time), and since threaded
interrupts are the right way to do it.
Alan Ott (3):
mrf24j40: Move INIT_COMPLETION() to before packet transmission
mrf24j40: Use threaded IRQ handler
mrf24j40: Use level-triggered interrupts
drivers/net/ieee802154
On 05/21/2013 10:01 PM, Alan Ott wrote:
David Hauweele noticed that the mrf24j40 would hang arbitrarily after some
period of heavy traffic. Two race conditions were discovered, and the
driver was changed to use threaded interrupts, since the enable/disable of
interrupts in the driver has
This avoids a race condition where the tx_complete interrupt could happen
before the completion is initialized.
---
David H,
Try this out and see if it changes anything for you. I put a bunch of
schedule_timeout()s in mrf24j40_tx() to basically guarantee that a reception
will happen during
threaded
interrupts to try.
I'm trying to determine exactly what's the cause of the interrupt line
being stuck low.
Alan.
>
> 2013/5/14 Alan Ott :
>> On 5/9/13 11:19 AM, David Hauweele wrote:
>>> Disabling the interrupt line could miss an IRQ and leave the line into a
>>>
exactly what's the cause of the interrupt line
being stuck low.
Alan.
2013/5/14 Alan Ott a...@signal11.us:
On 5/9/13 11:19 AM, David Hauweele wrote:
Disabling the interrupt line could miss an IRQ and leave the line into a
low state hence locking the driver.
Have you observed this? My
This avoids a race condition where the tx_complete interrupt could happen
before the completion is initialized.
---
David H,
Try this out and see if it changes anything for you. I put a bunch of
schedule_timeout()s in mrf24j40_tx() to basically guarantee that a reception
will happen during
On 5/9/13 11:19 AM, David Hauweele wrote:
Disabling the interrupt line could miss an IRQ and leave the line into a
low state hence locking the driver.
Have you observed this? My understanding is that the interrupt won't be
lost but instead delayed until enable_irq() is called.
I got this
On 5/9/13 11:19 AM, David Hauweele wrote:
The transceiver may fail under heavy traffic when a frame is transmitted
while receiving another frame.
This patch uses a mutex to separate the transmission and reception of
frames along with a secondary working queue to avoid a deadlock while
waiting
On 5/9/13 11:19 AM, David Hauweele wrote:
The transceiver may fail under heavy traffic when a frame is transmitted
while receiving another frame.
This patch uses a mutex to separate the transmission and reception of
frames along with a secondary working queue to avoid a deadlock while
waiting
On 5/9/13 11:19 AM, David Hauweele wrote:
Disabling the interrupt line could miss an IRQ and leave the line into a
low state hence locking the driver.
Have you observed this? My understanding is that the interrupt won't be
lost but instead delayed until enable_irq() is called.
I got this
and
current_page and make sure they are updated when the channel has been
changed.
Signed-off-by: Alan Ott
---
net/mac802154/mib.c | 12 +++-
net/mac802154/tx.c | 3 +++
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/net/mac802154/mib.c b/net/mac802154/mib.c
index f03e55f..8ded97c
On 04/05/2013 05:05 PM, Werner Almesberger wrote:
> Alan Ott wrote:
>> Prevent set_channel() from getting called every time a packet is sent. This
>> looks like it was an oversight.
> at86rf230.c and derivatives avoid this problem by setting
> phy->current_* in the *_chann
the log level for this failure to debug
level.
Signed-off-by: Alan Ott
---
drivers/net/ieee802154/mrf24j40.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40.c
index 6481faf..556151d 100644
Prevent set_channel() from getting called every time a packet is sent. This
looks like it was an oversight.
Signed-off-by: Alan Ott
---
net/mac802154/tx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/mac802154/tx.c b/net/mac802154/tx.c
index 3fd3e07..6d16473 100644
--- a/net
Prevent set_channel() from getting called every time a packet is sent. This
looks like it was an oversight.
Signed-off-by: Alan Ott a...@signal11.us
---
net/mac802154/tx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/mac802154/tx.c b/net/mac802154/tx.c
index 3fd3e07..6d16473 100644
the log level for this failure to debug
level.
Signed-off-by: Alan Ott a...@signal11.us
---
drivers/net/ieee802154/mrf24j40.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40.c
index 6481faf..556151d
On 04/05/2013 05:05 PM, Werner Almesberger wrote:
Alan Ott wrote:
Prevent set_channel() from getting called every time a packet is sent. This
looks like it was an oversight.
at86rf230.c and derivatives avoid this problem by setting
phy-current_* in the *_channel function.
But I'd agree
and
current_page and make sure they are updated when the channel has been
changed.
Signed-off-by: Alan Ott a...@signal11.us
---
net/mac802154/mib.c | 12 +++-
net/mac802154/tx.c | 3 +++
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/net/mac802154/mib.c b/net/mac802154/mib.c
index
packets.
With a queue length of 10, an entire IPv6 packet was unable to get queued
at one time, causing fragments to be dropped, and making reassembly
impossible.
Signed-off-by: Alan Ott
---
net/mac802154/wpan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac802154/wpan.c
_not_
retry sending packets on failure. I believe this to be consistent with the
802.15.4 specification (Section 7.5.6.4.3 of IEEE 802.15.4-2006)
Alan Ott (4):
mac802154: Do not try to resend failed packets
mac802154: Use netif flow control
mac802154: Increase tx_buffer_len
6lowpan: handle
do it in mac802154.
Signed-off-by: Alan Ott
---
net/mac802154/mac802154.h | 2 --
net/mac802154/tx.c| 12 ++--
2 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/net/mac802154/mac802154.h b/net/mac802154/mac802154.h
index 21fa386..5c9e021 100644
--- a/net/mac802
layer so the higher layer will retry sending the packet.
Signed-off-by: Alan Ott
---
net/ieee802154/6lowpan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index e1b4580..55e1fd5 100644
--- a/net/ieee802154/6lowpan.c
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
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
it in mac802154.
Signed-off-by: Alan Ott a...@signal11.us
---
net/mac802154/mac802154.h | 2 --
net/mac802154/tx.c| 12 ++--
2 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/net/mac802154/mac802154.h b/net/mac802154/mac802154.h
index 21fa386..5c9e021 100644
layer so the higher layer will retry sending the packet.
Signed-off-by: Alan Ott a...@signal11.us
---
net/ieee802154/6lowpan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index e1b4580..55e1fd5 100644
--- a/net
_not_
retry sending packets on failure. I believe this to be consistent with the
802.15.4 specification (Section 7.5.6.4.3 of IEEE 802.15.4-2006)
Alan Ott (4):
mac802154: Do not try to resend failed packets
mac802154: Use netif flow control
mac802154: Increase tx_buffer_len
6lowpan: handle
packets.
With a queue length of 10, an entire IPv6 packet was unable to get queued
at one time, causing fragments to be dropped, and making reassembly
impossible.
Signed-off-by: Alan Ott a...@signal11.us
---
net/mac802154/wpan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net
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
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 coupl
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 str
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
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 no
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 th
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: Al
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
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
packets.
With a queue length of 10, an entire IPv6 packet was unable to get queued
at one time, causing fragments to be dropped, and making reassembly
impossible.
Signed-off-by: Alan Ott
---
net/mac802154/wpan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac802154/wpan.c
properly in the 6LoWPAN code (and
return the proper errors to the higher layers). This will cause the higher
layers to retry later if the mac802154 queue is full.
2. Fix the retry of transmit failures in mac802154.
Alan Ott (6):
mac802154: Immediately retry sending failed packets
mac802154: Move
.
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 a68c792..55e1fd5 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1142,7 +1142,7 @@ out
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 4e09
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
dev_queue_xmit() can return positive error codes, so check for nonzero.
Signed-off-by: Alan Ott a...@signal11.us
---
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
When ops-xmit() fails, immediately retry. Previously the packet was sent
to the back of the workqueue.
Signed-off-by: Alan Ott a...@signal11.us
---
net/mac802154/tx.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/net/mac802154/tx.c b/net/mac802154/tx.c
.
Signed-off-by: Alan Ott a...@signal11.us
---
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 a68c792..55e1fd5 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1142,7 +1142,7
properly in the 6LoWPAN code (and
return the proper errors to the higher layers). This will cause the higher
layers to retry later if the mac802154 queue is full.
2. Fix the retry of transmit failures in mac802154.
Alan Ott (6):
mac802154: Immediately retry sending failed packets
mac802154: Move
1 - 100 of 168 matches
Mail list logo
