From: Phoebe Buckheister
Date: Fri, 14 Mar 2014 21:23:56 +0100
> This patch set enforces network byte order on all internal operations and
> fields of the 802.15.4 stack and adds a general representation of 802.15.4
> headers with operations to create and parse those headers. This reduces code
>
On Fri, March 14, 2014 11:11 pm, Martin Townsend wrote:
> On 14/03/14 21:29, Phoebe Buckheister wrote:
>> They would look contiguous, but they won't be contiguous in memory.
>> Declarig the reserved field as u8:3 will cause the allocator to move
>> that
>> three-bit field to the next byte in memory
On 14/03/14 21:29, Phoebe Buckheister wrote:
> On Fri, March 14, 2014 10:07 pm, Martin Townsend wrote:
>> See below
> […]
>>> +struct ieee802154_hdr_fc {
>>> +#if defined(__LITTLE_ENDIAN_BITFIELD)
>>> + u16 type:3,
>>> + security_enabled:1,
>>> + frame_pending:1,
>>> + ack_reque
On Fri, March 14, 2014 10:07 pm, Martin Townsend wrote:
> See below
[…]
>> +struct ieee802154_hdr_fc {
>> +#if defined(__LITTLE_ENDIAN_BITFIELD)
>> +u16 type:3,
>> +security_enabled:1,
>> +frame_pending:1,
>> +ack_request:1,
>> +intra_pan:1,
>> +reserved:
See below
On 14/03/14 15:23, Phoebe Buckheister wrote:
> This patch provides a set of structures to represent 802.15.4 MAC
> headers, and a set of operations to push/pull/peek these structs from
> skbs. We cannot simply pointer-cast the skb MAC header pointer to these
> structs, because 802.15.4 h
On Fri, March 14, 2014 9:36 pm, Martin Townsend wrote:
> Hi Phoebe,
>
> To help me review this series and also so I can update my driver could
> you give me some background on endianess in the stack, ie what should be
> little endian, why it should be little endian etc. Sorry for being a
> pain, I'
Hi Phoebe,
To help me review this series and also so I can update my driver could
you give me some background on endianess in the stack, ie what should be
little endian, why it should be little endian etc. Sorry for being a
pain, I'm just trying to get my head around it all :)
Cheers,
Martin.
Fragmentation and reassembly information for 6lowpan is independent from
the 802.15.4 stack and used only by the 6lowpan reassembly process. Move
the ieee802154_frag_info struct to a private are, it needn't be in the
802.15.4 skb control block.
Signed-off-by: Phoebe Buckheister
---
include/net/i
This patch set enforces network byte order on all internal operations and
fields of the 802.15.4 stack and adds a general representation of 802.15.4
headers with operations to create and parse those headers. This reduces code
duplication in the current stack and also allows for upper layers to read
Use the operations on 802.15.4 header structs introduced in a previous
patch to create and parse all headers in the mac802154 stack. This patch
reduces code duplication between different parts of the mac802154 stack
that needed information from headers, and also fixes a few bugs that
seem to have g
Enable sparse warnings about endianness, replace the remaining fields
regarding network operations without explicit endianness annotations
with such that are annotated, and propagate this through the entire
stack.
Uses of ieee802154_addr_sa are not changed yet, this patch is only
concerned with al
Add a replacement ieee802154_addr struct with proper endianness on
fields. Short address fields are stored as __le16 as on the network,
extended (EUI64) addresses are __le64 as opposed to the u8[8] format
used previously. This disconnect with the netdev address, which is
stored as big-endian u8[8],
This patch provides a set of structures to represent 802.15.4 MAC
headers, and a set of operations to push/pull/peek these structs from
skbs. We cannot simply pointer-cast the skb MAC header pointer to these
structs, because 802.15.4 headers are wildly variable - depending on the
first three bytes,
Have mac802154 header_ops.create fail with -EMSGSIZE if the length
passed will be too large to fit a frame. Since 6lowpan will ensure that
no packet payload will be too large, pass a length of 0 there. 802.15.4
dgram sockets will also return -EMSGSIZE on payloads larger than the
device MTU instead
The struct as currently defined uses host byte order for some fields,
and most big endian/EUI display byte order for other fields. Inside the
stack, endianness should ideally match network byte order where possible
to minimize the number of byteswaps done in critical paths, but this
patch does not
Change all internal uses of ieee802154_addr_sa to ieee802154_addr,
except for those instances that communicate directly with userspace.
Signed-off-by: Phoebe Buckheister
---
drivers/net/ieee802154/fakehard.c | 8 +--
include/net/ieee802154_netdev.h | 12 ++--
include/net/nl802154.h
On Fri, March 14, 2014 8:53 pm, Martin Townsend wrote:
> Thanks Phoebe, I'll probably get shot down for proposing this as _sa is
> standard nomenclature but couldn't we use ieee802154_saddr or
> iee802154_sockaddr to avoid the unfortunate similarity with source
> address and avoid statements like t
Thanks Phoebe, I'll probably get shot down for proposing this as _sa is
standard nomenclature but couldn't we use ieee802154_saddr or
iee802154_sockaddr to avoid the unfortunate similarity with source
address and avoid statements like this:
+ struct ieee802154_addr_sa sa;
+ struct i
On Fri, 14 Mar 2014 16:00:39 +
David Laight wrote:
> From: Phoebe Buckheister
> > Add a replacement ieee802154_addr struct with proper endianness on
> > fields. Short address fields are stored as __le16 as on the network,
> > extended (EUI64) addresses are __le64 as opposed to the u8[8] forma
On Fri, 14 Mar 2014 16:11:52 +
Martin Townsend wrote:
> Hi Phoebe,
>
> Out of interest what does the _sa stand for?
sockaddr, since it came from the sockaddr struct and my goal was to use
it only there.
> Many thanks,
> Martin.
>
--
Hi Phoebe,
Out of interest what does the _sa stand for?
Many thanks,
Martin.
On 14/03/14 15:23, Phoebe Buckheister wrote:
> The struct as currently defined uses host byte order for some fields,
> and most big endian/EUI display byte order for other fields. Inside the
> stack, endianness should i
This patch set enforced network byte order on all internal operations and
fields of the 802.15.4 stack and adds a general representation of 802.15.4
headers with operations to create and parse those headers. This reduces code
duplication in the current stack and also allows for upper layers to read
Use the operations on 802.15.4 header structs introduced in a previous
patch to create and parse all headers in the mac802154 stack. This patch
reduces code duplication between different parts of the mac802154 stack
that needed information from headers, and also fixes a few bugs that
seem to have g
Have mac802154 header_ops.create fail with -EMSGSIZE if the length
passed will be too large to fit a frame. Since 6lowpan will ensure that
no packet payload will be too large, pass a length of 0 there. 802.15.4
dgram sockets will also return -EMSGSIZE on payloads larger than the
device MTU instead
Change all internal uses of ieee802154_addr_sa to ieee802154_addr,
except for those instances that communicate directly with userspace.
Signed-off-by: Phoebe Buckheister
---
drivers/net/ieee802154/fakehard.c |8 +--
include/net/ieee802154_netdev.h | 12 ++--
include/net/nl802154.h
This patch provides a set of structures to represent 802.15.4 MAC
headers, and a set of operations to push/pull/peek these structs from
skbs. We cannot simply pointer-cast the skb MAC header pointer to these
structs, because 802.15.4 headers are wildly variable - depending on the
first three bytes,
Add a replacement ieee802154_addr struct with proper endianness on
fields. Short address fields are stored as __le16 as on the network,
extended (EUI64) addresses are __le64 as opposed to the u8[8] format
used previously. This disconnect with the netdev address, which is
stored as big-endian u8[8],
The struct as currently defined uses host byte order for some fields,
and most big endian/EUI display byte order for other fields. Inside the
stack, endianness should ideally match network byte order where possible
to minimize the number of byteswaps done in critical paths, but this
patch does not
Enable sparse warnings about endianness, replace the remaining fields
regarding network operations without explicit endianness annotations
with such that are annotated, and propagate this through the entire
stack.
Uses of ieee802154_addr_sa are not changed yet, this patch is only
concerned with al
Fragmentation and reassembly information for 6lowpan is independent from
the 802.15.4 stack and used only by the 6lowpan reassembly process. Move
the ieee802154_frag_info struct to a private are, it needn't be in the
802.15.4 skb control block.
Signed-off-by: Phoebe Buckheister
---
include/net/i
Hi Alex,
Sounds like a good plan, I'll review the new patch series once you've
finished.
Cheers,
Martin.
On 14/03/14 11:04, Alexander Aring wrote:
> On Fri, Mar 14, 2014 at 08:49:51AM +, Martin Townsend wrote:
>> Hi Alex,
>>
>> Do we need to free local_skb if we fail?
>>
>> if (fail) {
>>
On Fri, Mar 14, 2014 at 12:10:02PM +0100, Alexander Aring wrote:
> While checkpatch another patch I got a:
>
> "WARNING: msleep < 20ms can sleep for up to 20ms"
>
> The datasheet of at86rf231 and at86rf212 says a minimum delay for reset
> pulse width and spi access latency after reset is 625 nano
Hi all,
this patch series is v2 of my lastest at86rf230 patch serie. If all seems
fine I will send it to netdev later.
I already sent the lockdep splats fix to net which is a bugfix for stable.
- Alex
changes since v2:
- change state change to STATE_TX_ON.
- add change reset timings patch.
-
This patch fix a unexpected state change for the at86rf231 chip.
We can't change into STATE_FORCE_TX_ON while the chip is in one of
SLEEP, P_ON, RESET, TRX_OFF, and all *_NOCLK states.
In this case we are in the TRX_OFF state. See datasheet [1] page 71 for
more information.
Without this patch you
This patch adds devicetree support for the at86rf230 driver.
Possible gpios to configure are "reset-gpio" and "sleep-gpio".
Also add support to configure the "irq-type" for the irq polarity
register.
Signed-off-by: Alexander Aring
---
drivers/net/ieee802154/at86rf230.c | 48
There is no need to lock the clearing of IRQ_TRX_END in status.
Signed-off-by: Alexander Aring
---
drivers/net/ieee802154/at86rf230.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ieee802154/at86rf230.c
b/drivers/net/ieee802154/at86rf230.c
index 08c974c..b438f9
This patch make the reset pin optionally. Some devices like the atben
from qi-hardware don't have a reset pin externally. The usually way is
to turn power off/on for the atben device to initiate a device reset.
Signed-off-by: Alexander Aring
---
drivers/net/ieee802154/at86rf230.c | 34 ++
While checkpatch another patch I got a:
"WARNING: msleep < 20ms can sleep for up to 20ms"
The datasheet of at86rf231 and at86rf212 says a minimum delay for reset
pulse width and spi access latency after reset is 625 nanoseconds.
This patch removes the 1 milliseconds sleep and replace it with a 1
On Fri, Mar 14, 2014 at 08:49:51AM +, Martin Townsend wrote:
> Hi Alex,
>
> Do we need to free local_skb if we fail?
>
> if (fail) {
> kfree_skb(local_skb);
> goto drop;
> }
>
Hi Martin, the correct error handling will be a big patch the reasons
are:
We have to convert all errno
Hi,
you detect a bigger problem... :-) I will send a seperate patch for
this and this should be go net-next fast. I will send it at linux-zigbee
at first.
Thanks!
- Alex
--
Learn Graph Databases - Download FREE O'Reilly
On Fri, Mar 14, 2014 at 10:53:33AM +0100, Alexander Aring wrote:
> OOps, this was a little bit too fast, it should look like:
>
> diff --git a/net/ieee802154/6lowpan_rtnl.c b/net/ieee802154/6lowpan_rtnl.c
> index 2a146fb..9f96c77 100644
> --- a/net/ieee802154/6lowpan_rtnl.c
> +++ b/net/ieee802154/
OOps, this was a little bit too fast, it should look like:
diff --git a/net/ieee802154/6lowpan_rtnl.c b/net/ieee802154/6lowpan_rtnl.c
index 2a146fb..9f96c77 100644
--- a/net/ieee802154/6lowpan_rtnl.c
+++ b/net/ieee802154/6lowpan_rtnl.c
@@ -189,7 +189,6 @@ static int process_data(struct sk_buff *sk
Hi Martin,
On Fri, Mar 14, 2014 at 08:49:51AM +, Martin Townsend wrote:
> Hi Alex,
>
> Do we need to free local_skb if we fail?
>
> if (fail) {
> kfree_skb(local_skb);
> goto drop;
> }
>
you are right here. The current memory management is a mess. But I found
the reason why it'
Hi Alex,
Apart from the one query it all looks good to me.
Reviewed-by: Martin Townsend
Cheers,
Martin.
On 10/03/14 10:20, Alexander Aring wrote:
> Hi,
>
> this patch series cleanups a little bit the current 6lowpan dataflow.
> Mostly used more function which we already included mainline and
On Fri, Mar 14, 2014 at 03:18:22AM +0100, Alexander Aring wrote:
> While checkpatch another patch I got a:
>
> "WARNING: msleep < 20ms can sleep for up to 20ms"
>
> The datasheet of at86rf231 and at86rf212 says a minimum delay for reset
> pulse width and spi access latency after reset is 625 nano
Hi Alex,
Do we need to free local_skb if we fail?
if (fail) {
kfree_skb(local_skb);
goto drop;
}
On 10/03/14 10:20, Alexander Aring wrote:
> This patch makes the data pointer in lowpan_fetch_skb optionally. We can
> use this if we doesn't care about the fetched data, ie
>
> Si
46 matches
Mail list logo
