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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel