Re: [Linux-zigbee-devel] [PATCH v2 bluetooth-next] Simplify lowpan receive path so skb is freed in lowpan_rcv when dropped.

2014-09-09 Thread Martin Townsend
Hi Alex, On 08/09/14 19:36, Alexander Aring wrote: > Hi Martin, > > On Mon, Sep 08, 2014 at 07:13:02PM +0100, Martin Townsend wrote: > ... Hi, I'll respin and include the memory leak fix and this patch and a couple of others I have and send as a series to bluetooth. What bluet

Re: [Linux-zigbee-devel] [PATCH v2 bluetooth-next] Simplify lowpan receive path so skb is freed in lowpan_rcv when dropped.

2014-09-09 Thread Martin Townsend
Hi Alex, On 08/09/14 19:55, Alexander Aring wrote: > Hi Martin, > > On Mon, Sep 08, 2014 at 08:36:52PM +0200, Alexander Aring wrote: >> Hi Martin, >> >> On Mon, Sep 08, 2014 at 07:13:02PM +0100, Martin Townsend wrote: >> ... > Hi, > > I'll respin and include the memory leak fix and thi

Re: [Linux-zigbee-devel] [PATCH v2 bluetooth-next] Simplify lowpan receive path so skb is freed in lowpan_rcv when dropped.

2014-09-09 Thread Alexander Aring
Hi Martin, On Tue, Sep 09, 2014 at 10:28:36AM +0100, Martin Townsend wrote: ... > > I thought more about that, you mean the receiving part only? So the > > uncompression. The point is that we don't have no interface for an user > > that can decide if he like to use UDP compression like RFC 6282 or

Re: [Linux-zigbee-devel] [PATCH v2 bluetooth-next] Simplify lowpan receive path so skb is freed in lowpan_rcv when dropped.

2014-09-09 Thread Alexander Aring
On Tue, Sep 09, 2014 at 11:46:52AM +0200, Alexander Aring wrote: > Hi Martin, > > On Tue, Sep 09, 2014 at 10:28:36AM +0100, Martin Townsend wrote: > ... > > > I thought more about that, you mean the receiving part only? So the > > > uncompression. The point is that we don't have no interface for a

Re: [Linux-zigbee-devel] [PATCH v2 bluetooth-next] Simplify lowpan receive path so skb is freed in lowpan_rcv when dropped.

2014-09-09 Thread Martin Townsend
Hi Alex, On 09/09/14 10:46, Alexander Aring wrote: > Hi Martin, > > On Tue, Sep 09, 2014 at 10:28:36AM +0100, Martin Townsend wrote: > ... >>> I thought more about that, you mean the receiving part only? So the >>> uncompression. The point is that we don't have no interface for an user >>> that ca

Re: [Linux-zigbee-devel] [PATCH v2 bluetooth-next] Simplify lowpan receive path so skb is freed in lowpan_rcv when dropped.

2014-09-09 Thread Alexander Aring
Hi Martin, On Tue, Sep 09, 2014 at 11:17:15AM +0100, Martin Townsend wrote: > Hi Alex, > > On 09/09/14 10:46, Alexander Aring wrote: > > Hi Martin, > > > > On Tue, Sep 09, 2014 at 10:28:36AM +0100, Martin Townsend wrote: > > ... > >>> I thought more about that, you mean the receiving part only? S

Re: [Linux-zigbee-devel] [PATCH v2 bluetooth-next] Simplify lowpan receive path so skb is freed in lowpan_rcv when dropped.

2014-09-09 Thread Martin Townsend
Hi Alex, On 09/09/14 11:47, Alexander Aring wrote: > Hi Martin, > > On Tue, Sep 09, 2014 at 11:17:15AM +0100, Martin Townsend wrote: >> Hi Alex, >> >> On 09/09/14 10:46, Alexander Aring wrote: >>> Hi Martin, >>> >>> On Tue, Sep 09, 2014 at 10:28:36AM +0100, Martin Townsend wrote: >>> ... > I t

Re: [Linux-zigbee-devel] [PATCH v2 bluetooth-next] Simplify lowpan receive path so skb is freed in lowpan_rcv when dropped.

2014-09-09 Thread Marcel Holtmann
Hi Alex, >> >> The GHC spec states that a device indicates it's GHC capability using a >> 6LoWPAN Capability Indication Option (6CIO), this is an ND option. As far >> as I can see there is no type assigned yet by IANA so I was wondering if we >> should have this as an experimental configurati

Re: [Linux-zigbee-devel] [PATCH v2 bluetooth-next] Simplify lowpan receive path so skb is freed in lowpan_rcv when dropped.

2014-09-09 Thread Alexander Aring
Hi Marcel, On Tue, Sep 09, 2014 at 06:44:56AM -0700, Marcel Holtmann wrote: > Hi Alex, > > >> > >> The GHC spec states that a device indicates it's GHC capability using a > >> 6LoWPAN Capability Indication Option (6CIO), this is an ND option. As far > >> as I can see there is no type assigned