Re: [Linux-zigbee-devel] [PATCHv2 linux-wpan] ieee802154: mrf24j40: Add support for MRF24J40MC

ic int mrf24j40_remove(struct spi_device *spi) >> } >> >> static const struct spi_device_id mrf24j40_ids[] = { >> -{ "mrf24j40", 0 }, >> -{ "mrf24j40ma", 0 }, >> +{ "mrf24j40", MRF24J40 }, >> +{

Re: [Linux-zigbee-devel] [PATCH] mrf24j40: seperate mrf24j40 h/w init and add checkings

On 04/23/2014 09:11 AM, Varka Bhadram wrote: > I followed the process that you mailed earlier, thnks for that. > > I am expecting the mail from Alan about the changes. Hi Varka, Is there a specific problem you're seeing? Typically in the kernel we expect the SPI controller to succeed for a coupl

Re: [Linux-zigbee-devel] MRF24J40MA on BeagleBone Black

On 11/08/2013 01:05 PM, Andersan Xiley wrote: > > I'm in doubt about buying the BeagleBone Black version. > > The project on the link below is suppose to work on the BeagleBone Black? > > https://github.com/beagleboard/kernel/tree/3.8 > Yes. Use the 3.11 branch. Use Craig Peacock's tutorial posted

Re: [Linux-zigbee-devel] mrf24j40 on BeagleBoneBlack Production Image 2013.06.20 Incompatible with baseboard for 'BB-BONE-MRF24J40'

On 11/08/2013 06:29 PM, Craig Peacock wrote: > Yes, got it working. Summary can be found: > http://wiki.beyondlogic.org/index.php/BeagleBoneBlack_IEEE802154_Microchip_MRF24J40 > > In brief, I fixed up the typo in > /kernel/firmware/capes/cape-bone-mrf24j40-00A0.dts and got to to > rebuild. Then the

Re: [Linux-zigbee-devel] Testing the MRF24J40 functionality on a custom cape

On 11/05/2013 10:09 AM, K F wrote: > Some research colleagues and I have designed a BBone cape which, among > other stuff, supports 802.15.4 communication (via the mrf24j40 chip). > We are in the process of testing this specific functionality, but we > get some errors I was hoping you could help

Re: [Linux-zigbee-devel] How to build latest net-next kernel for Ubuntu or other distro.

On 10/30/2013 11:01 PM, Randy Graham wrote: > Is there a preferred desktop linux distro for testing net-next kernels > on a amd64 desktop machine ? > Most can build and run mainline kernels fine. > Ideally, I would like to run the latest net-next kernel on my Ubuntu > 13.10 amd64 dev box. > Sh

Re: [Linux-zigbee-devel] Enable security

On 10/23/2013 10:05 PM, João Paulo Bodanese wrote: > Is it possible to enable security in the current stack implementation? We don't currently have security at the MAC layer. > I have read something related to IPsec extension of 6LoWPAN. Can you provide a link? ---

[Linux-zigbee-devel] [PATCH v1 3/3] mrf24j40: Use level-triggered interrupts

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

[Linux-zigbee-devel] [PATCH v1 2/3] mrf24j40: Use threaded IRQ handler

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

[Linux-zigbee-devel] [PATCH v1 1/3] mrf24j40: Move INIT_COMPLETION() to before packet transmission

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

[Linux-zigbee-devel] [PATCH v1 0/3] Fix race conditions in mrf24j40 interrupts

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

[Linux-zigbee-devel] [PATCH v2 0/2] 6lowpan default hardware address

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

[Linux-zigbee-devel] [PATCH v2 2/2] 6lowpan: Sync default hardware address of lowpan links to their wpan

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

[Linux-zigbee-devel] [PATCH v2 1/2] 6lowpan: Only make 6lowpan links to IEEE802154 devices

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

Re: [Linux-zigbee-devel] [PATCH] 6lowpan: Sync default hardware address of lowpan links to their wpan

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

[Linux-zigbee-devel] [PATCH] 6lowpan: Sync default hardware address of lowpan links to their wpan

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

Re: [Linux-zigbee-devel] [PATCH beta 1] 0/3] Fix race conditions in mrf24j40 interrupts

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

Re: [Linux-zigbee-devel] [PATCH beta 1] 0/3] Fix race conditions in mrf24j40 interrupts

ems. I'm glad, but surprised 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 c

Re: [Linux-zigbee-devel] [PATCH beta 1] 0/3] Fix race conditions in mrf24j40 interrupts

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

[Linux-zigbee-devel] [PATCH beta 1] 3/3] mrf24j40: Use level-triggered interrupts

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

[Linux-zigbee-devel] [PATCH beta 1] 1/3] mrf24j40: Move INIT_COMPLETION() to before packet transmission

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

[Linux-zigbee-devel] [PATCH beta 1] 2/3] mrf24j40: Use threaded IRQ handler

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

[Linux-zigbee-devel] [PATCH beta 1] 0/3] Fix race conditions in mrf24j40 interrupts

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

Re: [Linux-zigbee-devel] [PATCH 2/2] mrf24j40: Keep the interrupt line enabled

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

[Linux-zigbee-devel] [PATCH testing] mrf24j40: Move INIT_COMPLETION to before the packet is sent

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

Re: [Linux-zigbee-devel] [PATCH 2/2] mrf24j40: Keep the interrupt line enabled

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

Re: [Linux-zigbee-devel] [PATCH 2/2] mrf24j40: Keep the interrupt line enabled

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 p

Re: [Linux-zigbee-devel] [PATCH 1/2] mrf24j40: Avoid transmission while receiving a frame

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 > w

Re: [Linux-zigbee-devel] [PATCH v3 0/2] Enable izattach to change the baudrate

On 05/01/2013 03:54 PM, Tony Cheneau wrote: > This is a small patch for the izattach (part of the linux-zigbee userspace > tools). It enables the user to select the baudrate when communicating with > their IEEE 802.15.4 serial device. > > This is the 3rd version of these patches. Here is the list o

Re: [Linux-zigbee-devel] [PATCH v2 0/2] Enable izattach to change the baudrate

On 04/24/2013 10:49 AM, Tony Cheneau wrote: > This is a small patch for the izattach (part of the linux-zigbee userspace > tools). It enables the user to select the baudrate when communicating with > their IEEE 802.15.4 serial device. > > This is the 2nd version of these patches. Here is the list o

Re: [Linux-zigbee-devel] [PATCH 1/1] izattach: enable custom baudrate

On 04/19/2013 09:38 AM, Tony Cheneau wrote: > > Thanks Alan. I'll correct the spacing issue and split the patch in > two: one for getopt, and one for the baudrate setting. No no... Not one for getopt(). One for the formatting fix at VTIME.

Re: [Linux-zigbee-devel] [PATCH 1/1] izattach: enable custom baudrate

On 04/17/2013 05:23 PM, Tony Cheneau wrote: > Add a "baudrate" parameter on the CLI that enables the user to choose > from different baudrates. If no parameter is passed, the baudrate is set > to 115200 (retaining the previous behavior). > > Signed-off-by: Tony Cheneau > --- It looks like your ed

Re: [Linux-zigbee-devel] Load mrf24j40 on beaglebone

nregistered link info perations vlan > DBG<1>: Unregistered cache operations route/rule > DBG<1>: Unregistered cache operations route/route > DBG<1>: Unregistered cache operations route/qdisc > DBG<1>: Unregistered cache operations route/neightbl &

[Linux-zigbee-devel] [PATCH v2] mac802154: Keep track of the channel when changed

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

Re: [Linux-zigbee-devel] [PATCH] mac802154: Keep track of the channel when changed

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

[Linux-zigbee-devel] [PATCH] mrf24j40: Enable link-layer acknowledgement and retry

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

[Linux-zigbee-devel] [PATCH] mac802154: Keep track of the channel when changed

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

Re: [Linux-zigbee-devel] [RFC PATCH] ieee802154/nl-mac.c: make some MLME operations optional

On 03/31/2013 12:18 PM, Werner Almesberger wrote: > 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 do not check for NULL, any attempted use causes an oops. > > This patch makes the

[Linux-zigbee-devel] [PATCH v2 4/4] 6lowpan: handle dev_queue_xmit() error code properly

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

[Linux-zigbee-devel] [PATCH v2 1/4] mac802154: Do not try to resend failed packets

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

[Linux-zigbee-devel] [PATCH v2 2/4] mac802154: Use netif flow control

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

[Linux-zigbee-devel] [PATCH v2 0/4] 802.15.4 and 6LoWPAN Buffering Fixes

_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

[Linux-zigbee-devel] [PATCH v2 3/4] mac802154: Increase tx_buffer_len

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

Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets

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

Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets

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

Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets

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

Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets

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

Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets

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'

Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets

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

Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets

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

Re: [Linux-zigbee-devel] [PATCH 5/6] 6lowpan: handle dev_queue_xmit error code properly

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>> >

[Linux-zigbee-devel] [PATCH 3/6] mac802154: Use netif flow control

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

[Linux-zigbee-devel] [PATCH 5/6] 6lowpan: handle dev_queue_xmit error code properly

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

[Linux-zigbee-devel] [PATCH 4/6] mac802154: Increase tx_buffer_len

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

[Linux-zigbee-devel] [PATCH 0/6] 802.15.4 and 6LoWPAN Buffering Fixes

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

[Linux-zigbee-devel] [PATCH 6/6] 6lowpan: return the dev_queue_xmit() return value from lowpan_xmit()

. 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

[Linux-zigbee-devel] [PATCH 2/6] mac802154: Move xmit_attemps to stack

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

[Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets

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

Re: [Linux-zigbee-devel] [PATCH 2/3] ieee802154/at86rf230: Implement hardware address filter callback.

On 03/25/2013 06:43 PM, Alexander Aring wrote: > Hi, > > On Mon, Mar 25, 2013 at 11:31:11PM +0100, Alexander Aring wrote: >> Hi, >> >> On Sun, Mar 24, 2013 at 01:40:31PM +, Stefan Schmidt wrote: >>> Implement the filter function to update short address, pan id and ieee >>> address on change. Al

Re: [Linux-zigbee-devel] [PATCH v2 net-next 00/12] 6lowpan: Some more bug fixes

reassembly and header > compression. > > This code passed the checkpatch.pl tool with a few warnings, that I believe > are OK. It should apply cleanly on the latest net-next. > I and have been running some form of this patchset since October, and have reviewed it several times. Review

Re: [Linux-zigbee-devel] Install linux-zigbee tools in the Beaglebone

On 03/25/2013 04:16 PM, K F wrote: > I did echo $STAGING and re-checked the pkconfig files again, and they > all seemed OK. > I thought I was going crazy or something, so I deleted all files (I > mean everything, even source files) and started over. > Same behaviour. > Ok, interesting. Try it ag

Re: [Linux-zigbee-devel] [PATCH 2/3] ieee802154/at86rf230: Implement hardware address filter callback.

On 03/25/2013 02:56 PM, Stefan Schmidt wrote: > On Sun, 2013-03-24 at 20:19, Alan Ott wrote: >> Some of those lines break the 80 column rule. You might get away with >> it. It's up to you if you want to try. > If the rule of thumb has not changed lately it depends on how ugl

Re: [Linux-zigbee-devel] Install linux-zigbee tools in the Beaglebone

to force output) > make[1]: *** [arch/arm/boot/dts/am335x-bone.dtb] Error 2 > make[1]: *** Waiting for unfinished jobs > ERROR (duplicate_node_names): Duplicate node name > /bone_capemgr/capemaps/cape@7 > ERROR: Input tree has errors, aborting (use -f to force output) > make[1]:

Re: [Linux-zigbee-devel] Source address fix and at86rf230 address filter callback

On 03/25/2013 02:51 PM, Stefan Schmidt wrote: > On Sun, 2013-03-24 at 20:25, Alan Ott wrote: >> On 03/24/2013 09:40 AM, Stefan Schmidt wrote: >>> As promised here is the reworked patch to add the hardware address filter >>> callback for at86rf230. I added two more patch

Re: [Linux-zigbee-devel] Install linux-zigbee tools in the Beaglebone

On 03/25/2013 02:50 PM, K F wrote: > I'm using bash shell as well. > > My automake is version 1.11.6. > Autoconf is 2.69. Mine are very close to that 1.11.1 and 2.69. > > Using: > PKG_CONFIG_DIR= \ > PKG_CONFIG_LIBDIR=$STAGING/lib/pkgconfig:$STAGING/share/pkgconfig \ > PKG_CONFIG_SYSROOT_DIR

Re: [Linux-zigbee-devel] Load mrf24j40 on beaglebone

mething changed in the .dtsi (arch/arm/boot/dts/am33x*) Check that and see if you can find out why spi1_pins_s0 is failing. Alan. > > Thank you again, > > Best regards, > Joao Paulo > >

Re: [Linux-zigbee-devel] Install linux-zigbee tools in the Beaglebone

On 03/24/2013 08:35 PM, Alan Ott wrote: > On 03/24/2013 08:19 PM, K F wrote: >> Hi Alan, >> >> Yes, I'm using the absolute path and using echo $STAGING I can confirm >> that the environment variable is set properly (i.e. points to the >> right directory). >

Re: [Linux-zigbee-devel] Install linux-zigbee tools in the Beaglebone

On 03/24/2013 08:19 PM, K F wrote: > Hi Alan, > > Yes, I'm using the absolute path and using echo $STAGING I can confirm > that the environment variable is set properly (i.e. points to the > right directory). > > Also, the pkg-config files are OK as well. > They all start with: > > prefix=/home

Re: [Linux-zigbee-devel] Source address fix and at86rf230 address filter callback

On 03/24/2013 09:40 AM, Stefan Schmidt wrote: > As promised here is the reworked patch to add the hardware address filter > callback for at86rf230. I added two more patches that might be good to go in > as > well. > > I did not add DaveM yet as I wanted to get some review on these first. Just > le

Re: [Linux-zigbee-devel] [PATCH 2/3] ieee802154/at86rf230: Implement hardware address filter callback.

On 03/24/2013 09:40 AM, Stefan Schmidt wrote: > Implement the filter function to update short address, pan id and ieee > address on change. Allowing for hardware address filtering needed for > auto ACK. > > Signed-off-by: Stefan Schmidt > --- > drivers/net/ieee802154/at86rf230.c | 45 > +++

Re: [Linux-zigbee-devel] Install linux-zigbee tools in the Beaglebone

On 03/24/2013 09:16 AM, João Paulo Bodanese wrote: > Hi, > > I had the same problem when I was using arm-angstrom-linux-gnueabi > toolchain. My Makefile was: > > NL_CFLAGS = > -I/home/joao/JoaoPaulo/lowpan3/libnl-3.2.7/../out/home/joao/JoaoPaulo/lowpan3/libnl-3.2.7/../out/include/libnl3 > > > NL_

Re: [Linux-zigbee-devel] Install linux-zigbee tools in the Beaglebone

On 03/24/2013 08:24 AM, K F wrote: > I just noticed that the Makefile produced, defines the following: > > NL_CFLAGS = > -I/home/shaman/Beagle_stuff/../out/home/shaman/Beagle_stuff/../out/include/libnl3 > > > NL_LIBS = > -L/home/shaman/Beagle_stuff/../out/home/shaman/Beagle_stuff/../out/lib > -

Re: [Linux-zigbee-devel] Install linux-zigbee tools in the Beaglebone

On 03/23/2013 04:06 PM, K F wrote: > > I too was following the updated crossbuilding instructions (@ the > linux-zigbee Wiki) and got a similar error. > Libnl3 (3.2.7) files are installed at "out", as expected, but when > moving on to install the linux-zigbee tools I get the following at "make":

Re: [Linux-zigbee-devel] Install linux-zigbee tools in the Beaglebone

On 03/22/2013 11:40 AM, João Paulo Bodanese wrote: > I found the problem. I changed the toolchain to arm-linux-gnueabi and > now is compiling. > I don't know why the toolchain arm-angstrom-linux-gnueabi doesn't > compile the usertools for me. You may have needed a distclean or a git clean -fdx Al

Re: [Linux-zigbee-devel] RFC: mac802154 Packet Queueing and Slave Devices

On 03/21/2013 12:09 PM, Alan Ott wrote: > On 09/09/2012 08:43 PM, Alan Ott wrote: >> Tony and I were recently talking about packet queueing on 802.15.4. What >> currently happens (in net/mac802154/tx.c) is that each tx packet (skb) >> is stuck on a work queue, and the worke

Re: [Linux-zigbee-devel] RFC: mac802154 Packet Queueing and Slave Devices

On 09/09/2012 08:43 PM, Alan Ott wrote: > Tony and I were recently talking about packet queueing on 802.15.4. What > currently happens (in net/mac802154/tx.c) is that each tx packet (skb) > is stuck on a work queue, and the worker function then sends each packet > to the hardware dri

Re: [Linux-zigbee-devel] Install linux-zigbee tools in the Beaglebone

On 03/20/2013 12:18 PM, Alan Ott wrote: > Yes, it looks like my instructions were working because they were > pulling some of those includes from the system. Further, the --prefix > bit is not the right way to do it, but unfortunately, I can't get > libnl to use it that way. Pl

Re: [Linux-zigbee-devel] Econotag + serial driver + azattach error.

On 03/20/2013 10:58 AM, jonsm...@gmail.com wrote: > On Wed, Mar 20, 2013 at 10:47 AM, sjs205 wrote: >> Yes, I think this is what I am going to do. I'm not sure how this will work >> with regards to fedora Nvidia and VirtualBox drivers etc... I guess I may VirtualBox does work with 3.9-rc3 FWIW. B

Re: [Linux-zigbee-devel] Install linux-zigbee tools in the Beaglebone

rror] > /usr/include/netlink/netlink.h:58:14: note: expected 'struct nl_handle > *' but argument is of type 'struct nl_sock *' > cc1: all warnings being treated as errors > make[2]: *** [libcommon_la-genl.lo] Fehler 1 > make[2]: Verlasse Verzeichnis '/home/joa

Re: [Linux-zigbee-devel] contributing patches

On 03/20/2013 10:19 AM, Ralph Droms (rdroms) wrote: > I've gotten myself to the point of being able to generate patches for various > fixes to 6lowpan.c. Is there a recommended style for the scope of these > patches? For example, I will post some patches for header compression and > decompress

Re: [Linux-zigbee-devel] Serial driver

On 03/19/2013 10:40 AM, jonsm...@gmail.com wrote: > Does the daemon need to hold the serial port open so that the line > disciple doesn't reset? I'm not sure about "need," but the current implementation does hold it open (meaning you have to kill izattach if you want to reload the driver). > Mayb

Re: [Linux-zigbee-devel] Install linux-zigbee tools in the Beaglebone

On 03/19/2013 09:11 AM, João Paulo Bodanese wrote: > Hi Alan, > > Thanks for your help. > I got an error on building. I did the following steps: > > I extracted libnl-3.2.7.tar.gz and linux-zigbee > (git://github.com/tcheneau/linux-zigbee.git > ) side-by

Re: [Linux-zigbee-devel] Serial driver

On 03/19/2013 10:24 AM, jonsm...@gmail.com wrote: > I poked around with btusb a little. BT has it's own USB descriptor > set. That's not the same as using a ft2232 to attach to the mc13224 > UART. There is no way to do something btusb like on the ft2232. You > could do it on the cc2531. A cc2531

Re: [Linux-zigbee-devel] Serial driver

On 03/18/2013 10:57 PM, jonsm...@gmail.com wrote: > How does the Bluetooth HCI interface work? HCI is a serial line > protocol and it has a line discipline. A Bluetooth device attached > over a UART would need to set the line disciple. That's because UARTs > don't have any device identification mec

Re: [Linux-zigbee-devel] Serial driver

On 03/18/2013 07:07 PM, jonsm...@gmail.com wrote: > Why isn't the serial driver in mainline? The serial driver has a couple of outstanding issues which may or may not need to be corrected before it goes into mainline (since it is ultimately not up to me): 1. It needs a new name. Maybe ieee802154-

Re: [Linux-zigbee-devel] Website

On 03/18/2013 07:03 PM, jonsm...@gmail.com wrote: > On Mon, Mar 18, 2013 at 6:10 PM, Alan Ott wrote: >> On 03/18/2013 03:55 PM, jonsm...@gmail.com wrote: >>> This line is on the hardware page twice: >>> http://sourceforge.net/apps/trac/linux-

Re: [Linux-zigbee-devel] Install linux-zigbee tools in the Beaglebone

On 03/18/2013 04:45 AM, João Paulo Bodanese wrote: > I am trying to set up the demo that Alan presented at Linux Conference > Europe 2012. > I have already installed the 3.7-rc2 Linux kernel in the BeagleBone > with all the patches that its described in his website. Hi João, At this point you

Re: [Linux-zigbee-devel] Website

On 03/18/2013 03:55 PM, jonsm...@gmail.com wrote: > This line is on the hardware page twice: > http://sourceforge.net/apps/trac/linux-zigbee/wiki/HardwareSupport > > > AT86RF231Supportedat86rf230Atmel AT86RF231 device connected directly > to CPU/SoC via SPI bus. > Remove the copy in the legacy sect

[Linux-zigbee-devel] [PATCH 4/4] mrf24j40: Fix byte-order of IEEE address

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

[Linux-zigbee-devel] [PATCH 3/4] mrf24j40: Increase max SPI speed to 10MHz

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

[Linux-zigbee-devel] [PATCH 2/4] mrf24j40: Warn if transmit interrupts timeout

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

[Linux-zigbee-devel] [PATCH 1/4] mrf24j40: pinctrl support

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

[Linux-zigbee-devel] [PATCH 0/4] Misc MRF24J40 Fixes

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

[Linux-zigbee-devel] Return Codes from Netlink

Hi guys, In putting in Stefan's patch for setting short address, PAN ID, and channel from iz ("iz set" command), I noticed that the kernel will return a netlink status code if the PAN ID is invalid (0x)[1]. The code it returns is IEEE802154_NO_SHORT_ADDRESS which is defined in include/net/ieee

Re: [Linux-zigbee-devel] [PATCH] Allow to set PAN ID, short address and channel manually.

On 03/13/2013 03:25 AM, Wolf-Bastian Pöttner wrote: > This allows setting up a network without a PAN > coordinator. Necessary if you want to be compatible > with the contiki implementation. Applied, thanks. I also put in some code to handle a failed return code. Alan. --

Re: [Linux-zigbee-devel] [PATCH 1/2] configure.ac: check for python2.x

On 03/17/2013 06:53 PM, Alexander Aring wrote: > Hi Alan, > > On Sun, Mar 17, 2013 at 06:27:59PM -0400, Alan Ott wrote: >> On 03/17/2013 06:24 PM, Alexander Aring wrote: >>> Hi Alan, >>> >>> On Sun, Mar 17, 2013 at 05:38:00PM -0400, Alan Ott wrote: &g

Re: [Linux-zigbee-devel] [PATCH] Allow to set PAN ID, short address and channel manually.

On 03/17/2013 06:02 PM, Stefan Schmidt wrote: > Hello. > > On Sun, 2013-03-17 at 15:59, Alan Ott wrote: >> On 03/13/2013 11:30 AM, Alan Ott wrote: >>> On 03/13/2013 03:25 AM, Wolf-Bastian Pöttner wrote: >>>> This allows setting up a network without a PAN >

Re: [Linux-zigbee-devel] [PATCH 1/2] configure.ac: check for python2.x

On 03/17/2013 06:24 PM, Alexander Aring wrote: > Hi Alan, > > On Sun, Mar 17, 2013 at 05:38:00PM -0400, Alan Ott wrote: >> On 03/17/2013 04:40 PM, Alexander Aring wrote: >>> Hi Alan, >>> >>> On Sun, Mar 17, 2013 at 04:16:08PM -0400, Alan Ott wrote: &g

Re: [Linux-zigbee-devel] [PATCH 1/2] configure.ac: check for python2.x

On 03/17/2013 04:40 PM, Alexander Aring wrote: > Hi Alan, > > On Sun, Mar 17, 2013 at 04:16:08PM -0400, Alan Ott wrote: >> On 12/21/2012 12:37 AM, Alexander Aring wrote: >>> Check for python2.x at first. >>> >>> test_DQ.py works with python2.x only. >

Re: [Linux-zigbee-devel] [PATCH 2/2] addrdb: fix include dependency and remove redefined

On 12/21/2012 12:37 AM, Alexander Aring wrote: > Currently I get this compile error: > > coord-config-parse.h:106:14: error: unknown type name 'yyscan_t' > coord-config-parse.y:38:0: error: "YYDEBUG" redefined [-Werror] > > "yyscan_t" is defined in parser.h but parser.h need a include from > coord-

  1   2   3   >