On Thu, Jul 10, 2014 at 10:17:14AM +0200, Tom Gundersen wrote:
> Signed-off-by: Tom Gundersen
> Cc: Dmitry Eremin-Solenikov
> Cc: linux-zigbee-devel@lists.sourceforge.net
Acked-by: Alexander Aring
- Alex
--
Open sourc
The functions lowpan_give_skb_to_devices and process_data can return a negative
error code as well as NET_RX_XXX values. Before this patch if either function
returned an error code it would return NET_RX_SUCCESS even though the skb would
have been freed.
Signed-off-by: Martin Townsend
---
ne
Hi Martin,
yes you are right here, we talking about this some months ago and I
simple not having time to do anything for that.
There was also some 6lowpan cleanup patches...
I preparing now to have a "single point of pull" for david miller and
send david pull-request for all ieee802154 subsystem
Hi Martn,
I think we should do it right. I will take your patch as base and then
we look into the other calling function to make a "better" error
handling.
I will grab your patch and but it into the linux-wpan-next repository. I
will write some mail where this repository is and a how-to the new
"
On 10/07/14 12:47, Alexander Aring wrote:
> Hi Martin,
>
> yes you are right here, we talking about this some months ago and I
> simple not having time to do anything for that.
I remember but we are seeing our devices panic due to this. We have devices
that aren't linux based that are used in po
On Thu, Jul 10, 2014 at 02:11:41PM +0200, Alexander Aring wrote:
> Hi Martn,
...
>
> Normally it should into net, because it's a bugfix. But we can't do this
> because so many things need to be changed and this occurs in a merge conflict,
> then we put it in net-next.
>
I was wrong here, net is
Hi Martin,
On Thu, Jul 10, 2014 at 01:27:44PM +0100, Martin Townsend wrote:
>
> On 10/07/14 12:47, Alexander Aring wrote:
> > Hi Martin,
> >
> > yes you are right here, we talking about this some months ago and I
> > simple not having time to do anything for that.
> I remember but we are seeing o
Hi,
I already wrote the postmaster of vger.kernel.org a request for a new
mailinglist "linux-wpan". It's not sure to get this name, nevertheless I
reconfigured the existsing "friendly fork" at github to this new name,
see [0].
When I get the mailinglist on vger.kernel.org I will change the
infras
This patch fix the del_phy_response_event and change
IEEE802154_ADD_IFACE to IEEE802154_DEL_IFACE otherwise we run into
deadlock in calling of iz del.
Signed-off-by: Alexander Aring
---
src/iz-phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/iz-phy.c b/src/iz-phy.c
i
This file can be generated by ctags and should not show in git status.
Signed-off-by: Alexander Aring
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 759ee0f..21a13d4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,6 +15,7 @@ Makefile
misc/
*sta
Alex,
I've bitten the bullet and had an attempt at refactoring the receive path of
lowpan to
1)Remove all use of error codes like -EINVAL as these are really part of the
UAPI and we are not propogating error codes to user space.
2)Ensure skb is freed in one place at the top of the call stack, ie
Sorry should have said this should be applied against v3.15 version of
linux-net kernel.
-Martin
On 10/07/14 16:49, Martin Townsend wrote:
> Alex,
>
> I've bitten the bullet and had an attempt at refactoring the receive path of
> lowpan to
> 1)Remove all use of error codes like -EINVAL as these
Hi Martin,
now we have a problem here which I already told many times...
the IPHC code is shared between bluetooth and IEEE 802.15.4 and normally
we need to send changes to net/ieee802154/6lowpan_iphc.c also to
bluetooth.
That's why I want a new branch net/6lowpan/ with the iphc
implementation.
On Thu, Jul 10, 2014 at 06:27:24PM +0200, Alexander Aring wrote:
...
>
>
> My basic idea was to move the iphc code into "net/6lowpan" and then make
> a cleanup of the iphc implementation which also return a better error
> handling for 802.15.4 and bluetooth. Then fix error handling in
> "net/ieee
Hi Alex,
Yes I failed to appreciated that the code is shared with bluetooth,
sorry about that. I'll wait until the IPHC code is moved, it makes
sense to have a net/6lowpan as it can sit on top of other MAC layers not
just 802.15.4.
-Martin.
On 10/07/14 18:11, Alexander Aring wrote:
> On Thu,
On Thu, Jul 10, 2014 at 07:07:03PM +0100, Martin Townsend wrote:
> Hi Alex,
>
> Yes I failed to appreciated that the code is shared with bluetooth, sorry
> about that. I'll wait until the IPHC code is moved, it makes sense to have
> a net/6lowpan as it can sit on top of other MAC layers not just
16 matches
Mail list logo
