* Re: How to assign sockaddr_nl->nl_groups when using connector
From: Evgeniy Polyakov @ 2013-03-20 18:29 UTC (permalink / raw)
To: vaughan; +Cc: netdev, KY Srinivasan, devel@linuxdriverproject.org
In-Reply-To: <5147CA4F.5050801@oracle.com>
Hi
On Tue, Mar 19, 2013 at 10:15:43AM +0800, vaughan (vaughan.cao@oracle.com) wrote:
> I am not quite sure how to assign nl_groups when using connector. You
> Documentation/connector/connector.txt don't explain it very clearly. I
> thought it's a bitmask representing only 32 groups.
> If I just want to subscribe only one group such as CN_KVP_IDX, what
> shall I do? Which one below is correct?
> a) l_local.nl_groups = CN_KVP_IDX;
> Or
> b) l_local.nl_groups = 1 << (CN_KVP_IDX -1)
> and bind with bind(s, (struct sockaddr *)&l_local, sizeof(struct
> sockaddr_nl)).
Iirc, first groups, created before bitmap-to-number conversion were
actually bitmaps, but then broadcast interface was obsoleted.
One should use NETLINK_ADD_MEMBERSHIP interface and specify gruop number
directly.
> I ran your example in Documentation/connector/. 'l_local.nl_groups = -1'
> in ucon.c seems subscribe all channels, because if I start cgred
> service, ucon will receive messages with idx=1.
>
> And it seems setsockopt is not needed now, for it is done by
> netlink_autobind? You even comment it out using '#if 0' in
> Documentation/connector/ucon.c.
>
> Could you do me a favor to check
> http://driverdev.linuxdriverproject.org/pipermail/devel/2013-March/036306.html
> to see if my understanding is correct or not? Thanks.
Yes, you are right.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH 2/2] sh_eth: check TSU registers ioremap() error
From: Denis Kirjanov @ 2013-03-20 18:20 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: David Miller, netdev, nobuhiro.iwamatsu.yj
In-Reply-To: <514A0B15.7000900@cogentembedded.com>
It doesn't make sense to worry about branch misprediction during probe() :)
On 3/20/13, Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> wrote:
> On 03/20/2013 10:04 PM, Sergei Shtylyov wrote:
>
>>
>>>
>>>> One must check the result of ioremap() -- in this case it prevents
>>>> potential
>>>> kernel oops when initializing TSU registers further on...
>>>>
>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>> Applied and queued up for -stable.
>>
>> Thanks. However, do you really think it's needed in stable? It's
>> only error path, after all...
>
> I forgot to add "unlikely" to the "error path". I usually don't mark
> such patches for stable, when I'm not in a hurry. :-)
>
> WBR, Sergei
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] fec: Fix the build as module
From: Fabio Estevam @ 2013-03-20 18:19 UTC (permalink / raw)
To: davem; +Cc: Frank.Li, u.kleine-koenig, netdev, Fabio Estevam
From: Fabio Estevam <fabio.estevam@freescale.com>
Since commit ff43da86c69 (NET: FEC: dynamtic check DMA desc buff type) the
following build error happens when CONFIG_FEC=m
ERROR: "fec_ptp_init" [drivers/net/ethernet/freescale/fec.ko] undefined!
ERROR: "fec_ptp_ioctl" [drivers/net/ethernet/freescale/fec.ko] undefined!
ERROR: "fec_ptp_start_cyclecounter" [drivers/net/ethernet/freescale/fec.ko] undefined!
Fix it by exporting the required fec_ptp symbols.
Reported-by: Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/net/ethernet/freescale/fec_ptp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fec_ptp.c b/drivers/net/ethernet/freescale/fec_ptp.c
index 1f17ca0..0d8df40 100644
--- a/drivers/net/ethernet/freescale/fec_ptp.c
+++ b/drivers/net/ethernet/freescale/fec_ptp.c
@@ -128,6 +128,7 @@ void fec_ptp_start_cyclecounter(struct net_device *ndev)
spin_unlock_irqrestore(&fep->tmreg_lock, flags);
}
+EXPORT_SYMBOL(fec_ptp_start_cyclecounter);
/**
* fec_ptp_adjfreq - adjust ptp cycle frequency
@@ -318,6 +319,7 @@ int fec_ptp_ioctl(struct net_device *ndev, struct ifreq *ifr, int cmd)
return copy_to_user(ifr->ifr_data, &config, sizeof(config)) ?
-EFAULT : 0;
}
+EXPORT_SYMBOL(fec_ptp_ioctl);
/**
* fec_time_keep - call timecounter_read every second to avoid timer overrun
@@ -383,3 +385,4 @@ void fec_ptp_init(struct net_device *ndev, struct platform_device *pdev)
pr_info("registered PHC device on %s\n", ndev->name);
}
}
+EXPORT_SYMBOL(fec_ptp_init);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 2/2] sh_eth: check TSU registers ioremap() error
From: Sergei Shtylyov @ 2013-03-20 19:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev, nobuhiro.iwamatsu.yj
In-Reply-To: <514A0835.6070104@cogentembedded.com>
On 03/20/2013 10:04 PM, Sergei Shtylyov wrote:
>
>>
>>> One must check the result of ioremap() -- in this case it prevents
>>> potential
>>> kernel oops when initializing TSU registers further on...
>>>
>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>> Applied and queued up for -stable.
>
> Thanks. However, do you really think it's needed in stable? It's
> only error path, after all...
I forgot to add "unlikely" to the "error path". I usually don't mark
such patches for stable, when I'm not in a hurry. :-)
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v3 1/1 net-next] NET: FEC: dynamtic check DMA desc buff type
From: Fabio Estevam @ 2013-03-20 18:06 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Frank Li, lznuaa, davem, s.hauer, netdev, shawn.guo,
linux-arm-kernel, kernel
In-Reply-To: <20130320160418.GG20530@pengutronix.de>
On Wed, Mar 20, 2013 at 1:04 PM, Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> Hello,
>
> On Fri, Jan 04, 2013 at 10:04:23AM +0800, Frank Li wrote:
>> MX6 and mx28 support enhanced DMA descriptor buff to support 1588
>> ptp. But MX25, MX3x, MX5x can't support enhanced DMA descriptor buff.
>> Check fec type and choose correct DMA descriptor buff type.
>>
>> Remove static config CONFIG_FEC_PTP.
>> ptp function will be auto detected.
> Your patch (now as ff43da86c69d76a726ffe7d1666148960dc1d108 in v3.9-rc1)
> breaks building with CONFIG_FEC=m:
>
> ERROR: "fec_ptp_init" [drivers/net/ethernet/freescale/fec.ko] undefined!
> ERROR: "fec_ptp_ioctl" [drivers/net/ethernet/freescale/fec.ko] undefined!
> ERROR: "fec_ptp_start_cyclecounter" [drivers/net/ethernet/freescale/fec.ko] undefined!
What about this fix?
---
drivers/net/ethernet/freescale/fec_ptp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fec_ptp.c
b/drivers/net/ethernet/freescale/fec_ptp.c
index 1f17ca0..0d8df40 100644
--- a/drivers/net/ethernet/freescale/fec_ptp.c
+++ b/drivers/net/ethernet/freescale/fec_ptp.c
@@ -128,6 +128,7 @@ void fec_ptp_start_cyclecounter(struct net_device *ndev)
spin_unlock_irqrestore(&fep->tmreg_lock, flags);
}
+EXPORT_SYMBOL(fec_ptp_start_cyclecounter);
/**
* fec_ptp_adjfreq - adjust ptp cycle frequency
@@ -318,6 +319,7 @@ int fec_ptp_ioctl(struct net_device *ndev, struct
ifreq *ifr, int cmd)
return copy_to_user(ifr->ifr_data, &config, sizeof(config)) ?
-EFAULT : 0;
}
+EXPORT_SYMBOL(fec_ptp_ioctl);
/**
* fec_time_keep - call timecounter_read every second to avoid timer overrun
@@ -383,3 +385,4 @@ void fec_ptp_init(struct net_device *ndev, struct
platform_device *pdev)
pr_info("registered PHC device on %s\n", ndev->name);
}
}
+EXPORT_SYMBOL(fec_ptp_init);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 1/2] sh_eth: fix bitbang memory leak
From: Sergei Shtylyov @ 2013-03-20 19:06 UTC (permalink / raw)
To: David Miller; +Cc: netdev, nobuhiro.iwamatsu.yj
In-Reply-To: <20130320.122346.949755604432580585.davem@davemloft.net>
Hello.
On 03/20/2013 07:23 PM, David Miller wrote:
>
>> sh_mdio_init() allocates pointer to 'struct bb_info' but only stores it locally,
>> so that sh_mdio_release() can't free it on driver unload. Add the pointer to
>> 'struct bb_info' to 'struct sh_eth_private', so that sh_mdio_init() can save
>> 'bitbang' variable for sh_mdio_release() to be able to free it later...
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Applied and queued up for -stable.
Thank you for the quick reaction! :-)
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2/2] sh_eth: check TSU registers ioremap() error
From: Sergei Shtylyov @ 2013-03-20 19:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev, nobuhiro.iwamatsu.yj
In-Reply-To: <20130320.122352.1542334118729356561.davem@davemloft.net>
Hello.
On 03/20/2013 07:23 PM, David Miller wrote:
> From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Date: Wed, 20 Mar 2013 02:41:32 +0300
>
>> One must check the result of ioremap() -- in this case it prevents potential
>> kernel oops when initializing TSU registers further on...
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Applied and queued up for -stable.
Thanks. However, do you really think it's needed in stable? It's
only error path, after all...
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next] net: fix psock_fanout selftest hash collision
From: David Miller @ 2013-03-20 17:59 UTC (permalink / raw)
To: willemb; +Cc: netdev
In-Reply-To: <20130320.123344.1566685302188091721.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 20 Mar 2013 12:33:44 -0400 (EDT)
> From: Willem de Bruijn <willemb@google.com>
> Date: Wed, 20 Mar 2013 02:42:44 -0400
>
>> Fix flaky results with PACKET_FANOUT_HASH depending on whether the
>> two flows hash into the same packet socket or not.
>>
>> Also adds tests for PACKET_FANOUT_LB and PACKET_FANOUT_CPU and
>> replaces the counting method with a packet ring.
>>
>> Signed-off-by: Willem de Bruijn <willemb@google.com>
>
> Applied, thanks. I'll retest on my sparc64 box later today.
Unfortunately, it's still broken there:
--------------------
running psock_fanout test
--------------------
test: control single socket
test: control multiple sockets
test: datapath 0x0
info: count=0,0, expect=0,0
info: count=0,0, expect=15,5
ERROR: incorrect queue lengths
info: count=0,0, expect=20,5
ERROR: incorrect queue lengths
info: trying alternate ports (4)
test: datapath 0x0
info: count=0,0, expect=0,0
info: count=0,0, expect=15,5
ERROR: incorrect queue lengths
info: count=0,0, expect=20,5
ERROR: incorrect queue lengths
info: trying alternate ports (3)
test: datapath 0x0
info: count=0,0, expect=0,0
info: count=0,0, expect=15,5
ERROR: incorrect queue lengths
info: count=0,0, expect=20,5
ERROR: incorrect queue lengths
info: trying alternate ports (2)
test: datapath 0x0
info: count=0,0, expect=0,0
info: count=0,0, expect=15,5
ERROR: incorrect queue lengths
info: count=0,0, expect=20,5
ERROR: incorrect queue lengths
info: trying alternate ports (1)
test: datapath 0x0
info: count=0,0, expect=0,0
info: count=0,0, expect=15,5
ERROR: incorrect queue lengths
info: count=0,0, expect=20,5
ERROR: incorrect queue lengths
info: trying alternate ports (0)
test: datapath 0x0
info: count=0,0, expect=0,0
info: count=0,0, expect=15,5
ERROR: incorrect queue lengths
info: count=0,0, expect=20,5
ERROR: incorrect queue lengths
test: datapath 0x1000
info: count=0,0, expect=0,0
info: count=0,0, expect=15,5
ERROR: incorrect queue lengths
info: count=0,0, expect=20,15
ERROR: incorrect queue lengths
test: datapath 0x1
info: count=0,0, expect=0,0
info: count=0,0, expect=10,10
ERROR: incorrect queue lengths
info: count=0,0, expect=18,17
ERROR: incorrect queue lengths
test: datapath 0x3
info: count=0,0, expect=0,0
info: count=0,0, expect=20,0
ERROR: incorrect queue lengths
info: count=0,0, expect=20,15
ERROR: incorrect queue lengths
test: datapath 0x2
info: count=0,0, expect=0,0
info: count=0,0, expect=20,0
ERROR: incorrect queue lengths
info: count=0,0, expect=20,0
ERROR: incorrect queue lengths
test: datapath 0x2
info: count=0,0, expect=0,0
info: count=0,0, expect=0,20
ERROR: incorrect queue lengths
info: count=0,0, expect=0,20
ERROR: incorrect queue lengths
[FAIL]
^ permalink raw reply
* Re: [regression] [analyzed] fragmentation broken for tunnel devices
From: David Miller @ 2013-03-20 17:46 UTC (permalink / raw)
To: timo.teras; +Cc: netdev
In-Reply-To: <20130320101318.4196d93a@vostro>
From: Timo Teras <timo.teras@iki.fi>
Date: Wed, 20 Mar 2013 10:13:18 +0200
Thanks for investigating this issue.
> 3) Reimplement fragmentation in tunnel devices. This means some
> duplication of code. But now that there's GRO support in tunnels, this
> would seem the most performant option.
I think this is the best option, especially in the long term.
^ permalink raw reply
* Re: [PATCH 1/1]core:Change a wrong explain about dev_get_by_name
From: Eric Dumazet @ 2013-03-20 17:43 UTC (permalink / raw)
To: Ben Hutchings; +Cc: tingwei liu, netdev, Alexey Kuznetsov, davem
In-Reply-To: <1363799443.2677.2.camel@bwh-desktop.uk.solarflarecom.com>
On Wed, 2013-03-20 at 17:10 +0000, Ben Hutchings wrote:
> If they are wrongly documented as 'can be called from any context', yes.
Wow, thats really useful.
Why is this function not allowed from hard irq context, we have no idea.
Why someone would like to call it from hard irq context, we have no
idea.
I hope to get a clear explanation here, not only playing with words.
Thanks
^ permalink raw reply
* Re: [PATCH 1/2] genetlink: trigger BUG_ON if a group name is too long
From: Ben Hutchings @ 2013-03-20 17:32 UTC (permalink / raw)
To: David Miller; +Cc: yamato, netdev
In-Reply-To: <20130320.120705.58997943737455552.davem@davemloft.net>
On Wed, 2013-03-20 at 12:07 -0400, David Miller wrote:
> From: Masatake YAMATO <yamato@redhat.com>
> Date: Tue, 19 Mar 2013 20:47:27 +0900
>
> > Trigger BUG_ON if a group name is longer than GENL_NAMSIZ.
> >
> > Signed-off-by: Masatake YAMATO <yamato@redhat.com>
>
> Applied, thanks.
>
> Although I'm disappointed that the compiler doesn't say anything about
> this in the assignment.
>
> We're assigning "char[16] = STRING" and it doesn't say anything if the
> final NULL char doesn't fit into the array.
Unfortunately the C standard says this is allowed. (Though the C++
standard says it's not!) That doesn't mean the compiler can't warn
about it, of course.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] chelsio: add headroom in RX path
From: David Miller @ 2013-03-20 17:29 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1363797199.3333.18.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 20 Mar 2013 09:33:19 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Drivers should reserve some headroom in skb used in receive path,
> to avoid future head reallocation.
>
> One possible way to do that is to use dev_alloc_skb() instead
> of alloc_skb(), so that NET_SKB_PAD bytes are reserved.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] dynticks: avoid flow_cache_flush() interrupting every core
From: David Miller @ 2013-03-20 17:29 UTC (permalink / raw)
To: fweisbec
Cc: cmetcalf, netdev, linux-kernel, gilad, sasha.levin, akpm, paulmck,
yoshfuji
In-Reply-To: <CAFTL4hwUuRdxUNF0rA9DVNREyBign6FRnAXFp_W+-YfYUfzU9Q@mail.gmail.com>
From: Frederic Weisbecker <fweisbec@gmail.com>
Date: Wed, 20 Mar 2013 17:37:04 +0100
> 2013/3/20 David Miller <davem@davemloft.net>:
>> From: Chris Metcalf <cmetcalf@tilera.com>
>> Date: Tue, 19 Mar 2013 17:35:58 -0400
>>
>>> Previously, if you did an "ifconfig down" or similar on one core, and
>>> the kernel had CONFIG_XFRM enabled, every core would be interrupted to
>>> check its percpu flow list for items that could be garbage collected.
>>>
>>> With this change, we generate a mask of cores that actually have any
>>> percpu items, and only interrupt those cores. When we are trying to
>>> isolate a set of cpus from interrupts, this is important to do.
>>>
>>> Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
>>> ---
>>> This change stands alone so could be taken into the net tree if
>>> desired, but it is most useful in the context of Frederic Weisbecker's
>>> linux-dynticks work. So it could be taken up through either tree,
>>> but it certainly needs sign-off from someone familiar with net/core/flow.c.
>>
>> I'm find with this going into the dynticks changes:
>>
>> Acked-by: David S. Miller <davem@davemloft.net>
>
> At it looks pretty self-contained, can that perhaps go through the
> networking tree?
Fair enough, applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH v3 1/1 net-next] NET: FEC: dynamtic check DMA desc buff type
From: Ben Hutchings @ 2013-03-20 17:28 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Frank Li, lznuaa, davem, s.hauer, netdev, shawn.guo,
linux-arm-kernel, kernel
In-Reply-To: <20130320160418.GG20530@pengutronix.de>
On Wed, 2013-03-20 at 17:04 +0100, Uwe Kleine-König wrote:
> Hello,
>
> On Fri, Jan 04, 2013 at 10:04:23AM +0800, Frank Li wrote:
> > MX6 and mx28 support enhanced DMA descriptor buff to support 1588
> > ptp. But MX25, MX3x, MX5x can't support enhanced DMA descriptor buff.
> > Check fec type and choose correct DMA descriptor buff type.
> >
> > Remove static config CONFIG_FEC_PTP.
> > ptp function will be auto detected.
> Your patch (now as ff43da86c69d76a726ffe7d1666148960dc1d108 in v3.9-rc1)
> breaks building with CONFIG_FEC=m:
>
> ERROR: "fec_ptp_init" [drivers/net/ethernet/freescale/fec.ko] undefined!
> ERROR: "fec_ptp_ioctl" [drivers/net/ethernet/freescale/fec.ko] undefined!
> ERROR: "fec_ptp_start_cyclecounter" [drivers/net/ethernet/freescale/fec.ko] undefined!
>
> IMHO you should build fec.o and fec_ptp.o into the same module as they
> cannot live without each other anyhow.
They are in the same module. So I don't see how that error is possible.
> Having said I wonder if it would be worthwile to support FEC without
> PTP_1588_CLOCK. For example make the above three functions static
> inlines if CONFIG_PTP_1588_CLOCK=n and drop the select on the latter.
See previous discussions:
<http://thread.gmane.org/gmane.linux.kernel/1363200/focus=1376659>,
<http://thread.gmane.org/gmane.linux.network/247963>,
<http://thread.gmane.org/gmane.linux.network/247823/focus=248173>
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: AER revised
From: David Miller @ 2013-03-20 17:27 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, eilong, ariele
In-Reply-To: <1363792888-29392-1-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Wed, 20 Mar 2013 17:21:28 +0200
> Revised bnx2x implementation of PCI Express Advanced Error Recovery -
> stop and free driver resources according to the AER flow (instead of the
> currently implemented `hope-for-the-best' release approach), and do not make
> any assumptions on the HW state after slot reset.
>
> Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
> Signed-off-by: Ariel Elior <ariele@broadcom.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: fec: make local function fec_poll_controller() static
From: David Miller @ 2013-03-20 17:26 UTC (permalink / raw)
To: weiyj.lk
Cc: grant.likely, rob.herring, Frank.Li, shawn.guo, fabio.estevam,
s.hauer, yongjun_wei, netdev, devicetree-discuss
In-Reply-To: <CAPgLHd-ZLKjHdqc_Bm44co+9eTF48TOg9zY8c1jbqeG+jnn3GQ@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Wed, 20 Mar 2013 23:06:11 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> fec_poll_controller() was not declared. It should be static.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH] net: ethernet: davinci_emac: make local function emac_poll_controller() static
From: David Miller @ 2013-03-20 17:26 UTC (permalink / raw)
To: weiyj.lk
Cc: grant.likely, rob.herring, mugunthanvnm, jiri, agust, bhutchings,
yongjun_wei, netdev, devicetree-discuss
In-Reply-To: <CAPgLHd8=u1jepO+Z0HExYyyybaYtVcdqk0yhtmnLUieUhEGLTw@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Wed, 20 Mar 2013 23:01:45 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> emac_poll_controller() was not declared. It should be static.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH 5/5] net: mdio-octeon: Use module_platform_driver()
From: David Miller @ 2013-03-20 17:26 UTC (permalink / raw)
To: sachin.kamat; +Cc: netdev, ddaney
In-Reply-To: <1363779692-4395-5-git-send-email-sachin.kamat@linaro.org>
From: Sachin Kamat <sachin.kamat@linaro.org>
Date: Wed, 20 Mar 2013 17:11:32 +0530
> module_platform_driver macro removes some boilerplate and
> simplifies the code.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Applied.
^ permalink raw reply
* Re: [PATCH 4/5] net: mdio-gpio: Use module_platform_driver()
From: David Miller @ 2013-03-20 17:26 UTC (permalink / raw)
To: sachin.kamat; +Cc: netdev
In-Reply-To: <1363779692-4395-4-git-send-email-sachin.kamat@linaro.org>
From: Sachin Kamat <sachin.kamat@linaro.org>
Date: Wed, 20 Mar 2013 17:11:31 +0530
> module_platform_driver macro removes some boilerplate and
> simplifies the code.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Applied.
^ permalink raw reply
* Re: [PATCH 3/5] net: au1k_ir: Use module_platform_driver()
From: David Miller @ 2013-03-20 17:26 UTC (permalink / raw)
To: sachin.kamat; +Cc: netdev, samuel
In-Reply-To: <1363779692-4395-3-git-send-email-sachin.kamat@linaro.org>
From: Sachin Kamat <sachin.kamat@linaro.org>
Date: Wed, 20 Mar 2013 17:11:30 +0530
> module_platform_driver macro removes some boilerplate and
> simplifies the code.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> Cc: Samuel Ortiz <samuel@sortiz.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/5] net: s6gmac: Use module_platform_driver()
From: David Miller @ 2013-03-20 17:26 UTC (permalink / raw)
To: sachin.kamat; +Cc: netdev
In-Reply-To: <1363779692-4395-2-git-send-email-sachin.kamat@linaro.org>
From: Sachin Kamat <sachin.kamat@linaro.org>
Date: Wed, 20 Mar 2013 17:11:29 +0530
> module_platform_driver macro removes some boilerplate and
> simplifies the code.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/5] net: ks8695net: Use module_platform_driver()
From: David Miller @ 2013-03-20 17:25 UTC (permalink / raw)
To: sachin.kamat; +Cc: netdev
In-Reply-To: <1363779692-4395-1-git-send-email-sachin.kamat@linaro.org>
From: Sachin Kamat <sachin.kamat@linaro.org>
Date: Wed, 20 Mar 2013 17:11:28 +0530
> module_platform_driver macro removes some boilerplate and
> simplifies the code.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Applied.
^ permalink raw reply
* Re: [PATCH v2 1/1] connector: Added coredumping event to the process connector
From: David Miller @ 2013-03-20 17:24 UTC (permalink / raw)
To: jderehag; +Cc: zbr, netdev, linux-kernel
In-Reply-To: <1363762205-26206-1-git-send-email-jderehag@hotmail.com>
From: Jesper Derehag <jderehag@hotmail.com>
Date: Wed, 20 Mar 2013 07:50:05 +0100
> Process connector can now also detect coredumping events.
> Main aim of patch is get notified at start of coredumping, instead of having to wait for it to finish and then being notified through EXIT event.
> Could be used for instance by process-managers that want to get notified as soon as possible about process failures, and not necessarily beeing notified after coredump, which could be in the order of minutes depending on size of coredump, piping and so on.
>
> Signed-off-by: Jesper Derehag <jderehag@hotmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/4][net-next] gianfar: Address napi polling issues
From: David Miller @ 2013-03-20 17:22 UTC (permalink / raw)
To: claudiu.manoil; +Cc: netdev, paul.gortmaker
In-Reply-To: <1363714805-9142-1-git-send-email-claudiu.manoil@freescale.com>
From: Claudiu Manoil <claudiu.manoil@freescale.com>
Date: Tue, 19 Mar 2013 19:40:01 +0200
> Hello David, Paul,
>
> These patches take on several issues in the current napi polling
> routine, affecting mostly the newer Multi Queue Multi Group
> (MQ_MG_MODE) devices. Seems that the code for these devices
> has been neglected.
>
> Tested on p1010 (single core, multi q), p1020 (dual core, multi q)
> and p2020 (dual core, single q mode).
All applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 net-next 4/4] filter: add minimal BPF JIT emitted image disassembler
From: David Miller @ 2013-03-20 17:17 UTC (permalink / raw)
To: dborkman; +Cc: netdev, eric.dumazet, edumazet
In-Reply-To: <1363711172-9728-5-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Tue, 19 Mar 2013 17:39:32 +0100
> This is a minimal stand-alone user space helper, that allows for debugging or
> verification of emitted BPF JIT images.
As Ben Hutchings suggested, please respin this such that the tool
goes somewhere under tools/
Creating a tools/net/ subdirectory for small programs like this is
fine.
Thanks!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox