On Tue, 2014-06-10 at 18:11 +0200, Phoebe Buckheister wrote:
> Only one WPAN devices can be active at any given time, so only deliver
> packets to that one interface that is actually up. Multiple monitors may
> be up at any given time, but we don't have to deliver to monitors that
> are down either
On Tue, 2014-06-10 at 17:08 +0200, Phoebe Buckheister wrote:
> Only one WPAN devices can be active at any given time, so only deliver
> packets to that one interface that is actually up.
>
> Signed-off-by: Phoebe Buckheister
> ---
> net/mac802154/wpan.c | 12 +++-
> 1 file changed, 7 i
On Tue, 2014-03-18 at 22:56 -0600, Jean Sacren wrote:
> Stating it is a "fix" is not a false statement at all. !! falsely
> changes the value to be int TWICE for nothing! Are you still not
> convinced?
I think you are mistaken.
X = !!(a) makes sure X is 0 or 1.
Its a valid and useful construct.
On Tue, 2014-03-18 at 20:42 -0700, Joe Perches wrote:
> On Tue, 2014-03-18 at 20:32 -0700, Eric Dumazet wrote:
> > On Tue, 2014-03-18 at 21:19 -0600, Jean Sacren wrote:
> >
> > > 2) Fix the initializer by deleting the double logical negation
> > >operator
On Tue, 2014-03-18 at 21:19 -0600, Jean Sacren wrote:
> 2) Fix the initializer by deleting the double logical negation
>operators as they don't serve any purpose.
>
...
>
> static int phy_set_lbt(struct wpan_phy *phy, struct genl_info *info)
> {
> - u8 on = !!nla_get_u8(info->attrs[IE
On Mon, 2014-02-10 at 19:21 +0100, Alexander Aring wrote:
> no problem. Maybe you can try to give me some explanation what you did
> there?
>
> I see you make a lockdep_set_class for each tx queue and assign the
> lowpan_netdev_xmit_lock_key. So why it's better to make a own
> "lock_key".
This
On Mon, 2014-02-10 at 18:33 +0100, Alexander Aring wrote:
> Hi Eric,
>
> On Sun, Feb 09, 2014 at 04:41:47AM -0800, Eric Dumazet wrote:
> >
> > Please try the following fix, thanks for this report !
> >
> > diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154
On Sun, 2014-02-09 at 11:20 +0100, Alexander Aring wrote:
> Hi,
>
> I got some locking issues with CONFIG_PROVE_LOCKING enabled and need help.
>
> Full output:
>
> =
> [ INFO: possible recursive locking detected ]
> 3.13.0-08605-g8f2b630-dirty #105 Not
On Thu, 2013-11-14 at 16:48 +0100, Alexander Aring wrote:
> The current 6LoWPAN udp compression/uncompression is completely broken.
> This patch series fix a lot of udp compression/uncompression issues and
> add support parsing with lowpan_fetch_skb function.
If its broken, why targeting net-next
On Thu, 2013-03-07 at 22:41 +, Ben Hutchings wrote:
> On Thu, 2013-03-07 at 21:13 +0100, Alexander Aring wrote:
> > The function addrconf_ifid_eui64 will copy eui into dev->dev_addr.
> > We need first to manipulate eui[0] before we call memcpy afterwards.
>
> memcpy() does not work that way.
>
On Tue, 2013-02-05 at 19:13 +0100, Alexander Aring wrote:
> Ahh, you mean to put it on the stack. :-)
>
> Sorry about that.
No problem ;)
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall befo
On Tue, 2013-02-05 at 19:00 +0100, Alexander Aring wrote:
> I don't know how I can do that. head is a temp buffer.
> At the end of this function stands:
>
> memcpy(skb_push(skb, pos), head, pos)
>
> and 'pos' is determined at runtime. skb_push will add data to the
> start of buffer, so head buff
On Tue, 2013-02-05 at 16:34 +0100, Alexander Aring wrote:
> I got this message at runtime:
>
> [ 48.847347] BUG: scheduling while atomic: swapper/0/0/0x4100
> [ 48.853870] Modules linked in: autofs4
> [ 48.857891] [] (unwind_backtrace+0x0/0x11c) from []
> (__schedule_bug+0x48/0x5c)
> [
On Tue, 2012-10-23 at 16:50 +0200, Tony Cheneau wrote:
> >
> > + hlen = (type == LOWPAN_DISPATCH_FRAG1 ? LOWPAN_FRAG1_HEAD_SIZE :
> > + LOWPAN_FRAGN_HEAD_SIZE);
> >
> > So the L for LOWPAN_FRAGN_HEAD_SIZE should be underneath the t for
> > type.
> Will do as well.
By the way parens a
On Sun, 2012-09-09 at 20:43 -0400, Alan Ott wrote:
> Hi,
>
> Tony and I were recently talking about packet queueing on 802.15.4. What
> currently happens (in net/mac802154/tx.c) is that each tx packet (skb)
> is stuck on a work queue, and the worker function then sends each packet
> to the hardwar
On Wed, 2012-08-29 at 22:39 -0400, Alan Ott wrote:
> Since lowpan_process_data() modifies the skb (by calling skb_pull()), we
> need our own copy so that it doesn't affect the data received by other
> protcols (in this case, af_ieee802154).
>
> Signed-off-by: Alan Ott
> ---
> net/ieee802154/6low
Le jeudi 20 octobre 2011 à 15:17 +0400, Alexander Smirnov a écrit :
> Hello everybody,
>
> below is the patch which adds support for fragmentation in 6LoWPAN
> point to point networks. This activity needs because of difference
> in MTU: 1280 ipv6 and 128 ieee802.15.4
>
> This patch is just a draf
Le jeudi 20 octobre 2011 à 17:13 +0400, Dmitry Eremin-Solenikov a
écrit :
> Hi, Alexander, colleagues,
>
> On 10/20/2011 04:50 PM, Alexander Smirnov wrote:
> > Hi Eric,
> >
> > thank you for the replies. And another question I forgot to ask:
> >
> > when I send fragments, I still have original skb
Le jeudi 20 octobre 2011 à 16:50 +0400, Alexander Smirnov a écrit :
> Hi Eric,
>
> thank you for the replies. And another question I forgot to ask:
>
> when I send fragments, I still have original skb buffer. What should I
> do with it, is there any
> "proper/good" ways to drop it? Because I've a
19 matches
Mail list logo
