On Wed, Jan 29, 2014 at 6:07 PM, Phoebe Buckheister
wrote:
> On Tue, 28 Jan 2014 23:40:41 +0400
> Dmitry Eremin-Solenikov wrote:
>> Never ever put spi transfer buffer onto the stack. It is not dma safe.
>> Use kmalloc/kzalloc.
>
> Noted. The GFP_DMA flag just confused for a few minutes, but looki
Hello colleagues,
Right now there are two parallel threads onto this topic
ongoing on the ML, so I decided to start a third one.
Regarding handling of checksum, sizes, fields, etc.
MAC frame (max 127 bytes) consists of header, payload
and FCS (2 bytes).
FCS is used to check that incoming frame
On Wed, Jan 29, 2014 at 5:34 PM, Phoebe Buckheister
wrote:
> On Tue, 28 Jan 2014 23:23:17 +0400
> Dmitry Eremin-Solenikov wrote:
>> Ok. You actually forced me to open the -2011 standard.
>> Now I have the impression that LBT is a property of the channel band
>> (let's call it subpage - several ch
On Tue, 28 Jan 2014 23:40:41 +0400
Dmitry Eremin-Solenikov wrote:
> Never ever put spi transfer buffer onto the stack. It is not dma safe.
> Use kmalloc/kzalloc.
Noted. The GFP_DMA flag just confused for a few minutes, but looking at
some DMA Documentation, apparently all kmalloc() memory is safe
On Tue, 28 Jan 2014 23:23:17 +0400
Dmitry Eremin-Solenikov wrote:
> General question: do you base on rf212 or rf212B chips (there is an
> app note on Atmel's site describing differences between those chips).
> It is ok to target only one version of the chip, provided you put a
> notice in the sour
Hello
On Wed, Jan 29, 2014 at 3:53 PM, Varka Bhadram wrote:
> hai...
>
> please clarify the below doubts..
>
> 1. Is the mac layer (mac802154) is able to fragment the packets or not ?
No. MAC layer is simple - either pass the packet that fits the hw limits,
or drop it away. Fragmenting is next l
On Wed, Jan 29, 2014 at 12:20:50PM +, Martin Townsend wrote:
> Hi Alex,
>
> I've been testing your latest changes and I'm now able to send large
> pings and can see the fragmented packets on wireshark :) I can now get
> the libcoap examples working (which didn't on the 3.10 kernel I was
>
> [2.354345] protocol is buggy, dev wpan0
This is a result of 6lowpan not setting skb header pointers correctly.
If you correctly build the skbs in _deliver, you'll lose those warnings
and also get MAC headers in lowpan frames for little extra cost (just
copy them over from the last fragm
Hi Alex,
I've been testing your latest changes and I'm now able to send large
pings and can see the fragmented packets on wireshark :) I can now get
the libcoap examples working (which didn't on the 3.10 kernel I was
using before). :)
One thing I have noticed is that it fragments earlier th
hai...
please clarify the below doubts..
1. Is the mac layer (mac802154) is able to fragment the packets or not ?
Because h/w driver is reading the received packets and putting in the skb. This
skb [skb->data] will consist of more than one packet. Dividing the entire
packet into single single p
10 matches
Mail list logo
