From: Martin Townsend <martin.townsend@xsilon.com>
To: Alexander Aring <alex.aring@gmail.com>
Cc: Martin Townsend <mtownsend1973@gmail.com>,
linux-zigbee-devel@lists.sourceforge.net,
linux-bluetooth@vger.kernel.org, linux-wpan@vger.kernel.org,
marcel@holtmann.org
Subject: Re: [PATCH][linux-bluetooth 2/3] 6lowpan: Move skb delivery from IPHC.
Date: Thu, 11 Sep 2014 10:33:33 +0100 [thread overview]
Message-ID: <54116C6D.3090004@xsilon.com> (raw)
In-Reply-To: <20140911090144.GC19675@omega>
Hi Alex,
On 11/09/14 10:01, Alexander Aring wrote:
> Hi Martin,
>
> On Thu, Sep 11, 2014 at 09:25:56AM +0100, Martin Townsend wrote:
>> Hi Alex,
>>
>> On 11/09/14 09:18, Alexander Aring wrote:
>>> On Wed, Sep 10, 2014 at 03:06:07PM +0100, Martin Townsend wrote:
>>>> Passing the skb from 6lowpan up to the higher layers is not a
>>>> function of IPHC. By moving it out of IPHC we also remove the
>>>> need to support error code returns with NET_RX codes.
>>>> It also makes the lowpan_rcv function more extendable as we
>>>> can support more compression schemes.
>>>>
>>> I will ack this. But please sperate this patch in two. First renaming
>>> the function namens and then removing deliver callback.
>> ok, but should this not be the other way around
>> moving delivery into receive and then by doing this processs_data naturally becomes IPHC decompress so it can be renamed.
>>> btw. The correct tag is bluetooth not linux-bluetooth, or bluetooth-next.
>>>
>>>
>>>
>>> Also this doesn't fix anything? Then this is for bluetooth-next. I know
>>> this depends on the Patch 1/3. Marcel, do you have any a nice solution
>>> about this, that we can deal with huge fixes in bluetooth and new features
>>> for bluetooth-next. Or simple wait when it's merged?
>> I disagree, this with the previous patch fixes error handling in lowpan_rcv. By moving the skb delivery out of IPHC you automatically fix the nightmare which is returning a mixture of NET_RX codes with error codes. IPHC now only returns error codes or success. Delivery is done where is should be in the receive function and can deal with NET_RX codes.
> ok. When this is a part of the fix and 1/3 "prepare" the fix, then put
> this handling into patch "1/3" to really fix the issue from patch 1/3.
I'm sorry I don't quite understand. Are you saying that I should combine patches 1 and 2 into a single patch?
- Martin.
> - Alex
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-09-11 9:33 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-10 14:06 [PATCH][linux-bluetooth 0/3] Fix lowpan_rcv Martin Townsend
2014-09-10 14:06 ` Martin Townsend
2014-09-10 14:06 ` [PATCH][linux-bluetooth 1/3] 6lowpan: skb freed locally from lowpan_rcv Martin Townsend
2014-09-11 7:58 ` Alexander Aring
2014-09-11 8:07 ` Alexander Aring
2014-09-11 8:32 ` Martin Townsend
2014-09-10 14:06 ` [PATCH][linux-bluetooth 2/3] 6lowpan: Move skb delivery from IPHC Martin Townsend
2014-09-11 8:18 ` Alexander Aring
2014-09-11 8:25 ` Martin Townsend
2014-09-11 9:01 ` Alexander Aring
2014-09-11 9:33 ` Martin Townsend [this message]
2014-09-11 9:53 ` Alexander Aring
2014-09-11 10:12 ` Martin Townsend
2014-09-11 10:25 ` Alexander Aring
2014-09-12 9:18 ` Jukka Rissanen
2014-09-11 14:11 ` Marcel Holtmann
2014-09-10 14:06 ` [PATCH][linux-bluetooth 3/3] 6lowpan: Refactored lowpan_rcv so it's RFC compliant Martin Townsend
2014-09-11 8:53 ` Alexander Aring
2014-09-11 9:09 ` Alexander Aring
2014-09-11 9:21 ` Alexander Aring
2014-09-11 9:30 ` Martin Townsend
2014-09-11 9:50 ` Alexander Aring
2014-09-11 10:09 ` Martin Townsend
2014-09-11 10:33 ` Alexander Aring
2014-09-11 10:45 ` Martin Townsend
2014-09-11 10:55 ` Alexander Aring
2014-09-11 11:00 ` Alexander Aring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54116C6D.3090004@xsilon.com \
--to=martin.townsend@xsilon.com \
--cc=alex.aring@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-wpan@vger.kernel.org \
--cc=linux-zigbee-devel@lists.sourceforge.net \
--cc=marcel@holtmann.org \
--cc=mtownsend1973@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).