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
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
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
+++ b/Documen
struct bio **bio,
I applied both your patches and tested on Overdrive 3000. This fixes the
issue for me.
Added 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/
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 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
--- a
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 k
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&#x
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
level-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/mrf24
e 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
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
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
sed that you're no longer 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 interr
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
level-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/mrf24
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 is
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 mrf24
ll send you a patch to try with 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 a
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 pa
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 fo
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
--- a
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
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
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 straight-forwa
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'
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/mac8
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:
if
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
Issue a warning if a transmit complete interrupt doesn't happen in time.
Signed-off-by: Alan Ott
---
drivers/net/ieee802154/mrf24j40.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40.c
index 3106895..582c0a3 100644
Upon consulting the datasheet further, it does indicates a maximum speed
for SCK at 10MHz.
Signed-off-by: Alan Ott
---
drivers/net/ieee802154/mrf24j40.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40
Load the 64-bit Extended (IEEE) address into the hardware in the proper
byte order.
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
Activate pinctrl settings when used with a DT system.
Signed-off-by: Alan Ott
---
drivers/net/ieee802154/mrf24j40.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40.c
index 3f2c7aa..3106895 100644
--- a/drivers/net
These are fairly straight-forward.
Alan Ott (4):
mrf24j40: pinctrl support
mrf24j40: Warn if transmit interrupts timeout
mrf24j40: Increase max SPI speed to 10MHz
mrf24j40: Fix byte-order of IEEE address
drivers/net/ieee802154/mrf24j40.c | 15 +++
1 file changed, 11
.
Version 2 fixes a format issue pointed out by David Miller.
Alan Ott (2):
6lowpan: Refactor packet delivery into a function
6lowpan: Handle uncompressed IPv6 packets over 6LoWPAN
net/ieee802154/6lowpan.c | 79 ++--
1 file changed, 56 insertions(+), 23
Refactor the handing of the skb's to the individual lowpan devices into a
function.
Signed-off-by: Alan Ott
---
net/ieee802154/6lowpan.c | 38 --
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee8
Handle the reception of uncompressed packets (dispatch type = IPv6).
Signed-off-by: Alan Ott
---
net/ieee802154/6lowpan.c | 41 -
1 file changed, 32 insertions(+), 9 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index
On 01/16/2013 04:22 PM, David Miller wrote:
> From: Alan Ott
> Date: Wed, 16 Jan 2013 00:43:57 -0500
>
>> +local_skb = skb_copy_expand(skb, NET_SKB_PAD - 1,
>> +skb_tailroom(skb), GFP_ATOMIC);
> This is not inden
Refactor the handing of the skb's to the individual lowpan devices into a
function.
Signed-off-by: Alan Ott
---
net/ieee802154/6lowpan.c | 38 --
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee8
This has been tested by exchanging data with with the Contiki operating
system using a Redwire Econotag. Contiki had to be set to send uncompressed
data, and had to have a #define modified to enable reception and processing
of header-compressed packets when not set to send compressed data.
Alan
Handle the reception of uncompressed packets (dispatch type = IPv6).
Signed-off-by: Alan Ott
---
net/ieee802154/6lowpan.c | 41 -
1 file changed, 32 insertions(+), 9 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index
kfree_skb() indicates failure, which is where this is being used.
Signed-off-by: Alan Ott
---
net/mac802154/tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac802154/tx.c b/net/mac802154/tx.c
index db63914..4e09d07 100644
--- a/net/mac802154/tx.c
+++ b/net/mac802154
kfree_skb() was not getting called in the case of some failures.
This was pointed out by Eric Dumazet.
Signed-off-by: Alan Ott
---
net/mac802154/tx.c | 5 -
net/mac802154/wpan.c | 4 +++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/mac802154/tx.c b/net/mac802154
On 11/29/2012 08:55 PM, Alan Ott wrote:
> Change the threshold for framentation of a lowpan packet from
> using the MTU size to now use the MTU size minus the checksum length,
> which is added by the hardware. For IEEE 802.15.4, this effectively
> changes it from 127 bytes to 125 byt
Change the threshold for framentation of a lowpan packet from
using the MTU size to now use the MTU size minus the checksum length,
which is added by the hardware. For IEEE 802.15.4, this effectively
changes it from 127 bytes to 125 bytes.
Signed-off-by: Alan Ott
---
net/ieee802154/6lowpan.c
Driver for the Microchip MRF24J40 802.15.4 WPAN module.
Signed-off-by: Alan Ott
---
drivers/net/ieee802154/Kconfig| 11 +
drivers/net/ieee802154/Makefile | 1 +
drivers/net/ieee802154/mrf24j40.c | 767 ++
3 files changed, 779 insertions(+)
create
discussion can be found on the archives of the linux-zigbee
mailing list:
http://www.mail-archive.com/linux-zigbee-devel@lists.sourceforge.net/msg01014.html
Alan Ott (1):
ieee802154: MRF24J40 driver
drivers/net/ieee802154/Kconfig| 11 +
drivers/net/ieee802154/Makefile | 1 +
drivers
Before, it was impossible to remove a wpan device which had lowpan
attached to it.
Signed-off-by: Alan Ott
---
net/ieee802154/6lowpan.c | 44 +---
1 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154
Since lowpan_process_data() modifies the skb (by calling skb_pull()), we
need our own copy so that it doesn't affect the data received by other
protcols (in this case, af_ieee802154).
Signed-off-by: Alan Ott
---
net/ieee802154/6lowpan.c |9 -
1 files changed, 8 insertions(
v3 of this patch changes skb_copy() to skb_clone() in patch #1 at the
recommendation of Eric Dumazet
Alan Ott (2):
6lowpan: Make a copy of skb's delivered to 6lowpan
6lowpan: handle NETDEV_UNREGISTER event
net/ieee802154/6lowpan.c | 53 +++-
On 08/31/2012 03:01 AM, Eric Dumazet wrote:
> On Wed, 2012-08-29 at 22:39 -0400, Alan Ott wrote:
>> Since lowpan_process_data() modifies the skb (by calling skb_pull()), we
>> need our own copy so that it doesn't affect the data received by other
>> protcols (i
Driver for the Microchip MRF24J40 802.15.4 WPAN module.
Signed-off-by: Alan Ott
---
drivers/ieee802154/Kconfig| 11 +
drivers/ieee802154/Makefile |1 +
drivers/ieee802154/mrf24j40.c | 767 +
3 files changed, 779 insertions(+), 0 deletions
This is a driver for the Microchip MRF24J40 802.15.4 transceiver.
Versions 1-5 and discussion can be found on the archives of the linux-zigbee
mailing list:
http://www.mail-archive.com/linux-zigbee-devel@lists.sourceforge.net/msg01014.html
Alan Ott (1):
ieee802154: MRF24J40 driver
drivers
Before, it was impossible to remove a wpan device which had lowpan
attached to it.
Signed-off-by: Alan Ott
---
net/ieee802154/6lowpan.c | 44 +---
1 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154
Since lowpan_process_data() modifies the skb (by calling skb_pull()), we
need our own copy so that it doesn't affect the data received by other
protcols (in this case, af_ieee802154).
Signed-off-by: Alan Ott
---
net/ieee802154/6lowpan.c |9 -
1 files changed, 8 insertions(
Fixes for 6lowpan.
I'm sorry about the other two emails that just went out with the same
subject. One day I'm going to start getting these right on the first try.
Alan Ott (2):
6lowpan: Make a copy of skb's delivered to 6lowpan
6lowpan: handle NETDEV_UNREGISTER event
Before, it was impossible to remove a wpan device which had lowpan
attached to it.
Signed-off-by: Alan Ott
---
net/ieee802154/6lowpan.c | 44 +---
1 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154
Since lowpan_process_data() modifies the skb (by calling skb_pull()), we
need our own copy so that it doesn't affect the data received by other
protcols (in this case, af_ieee802154).
Signed-off-by: Alan Ott
---
net/ieee802154/6lowpan.c |9 -
1 files changed, 8 insertions(
84 matches
Mail list logo
