* [PATCH] enic: enic_main: fix sparse warnings
From: Lad Prabhakar @ 2015-02-05 15:34 UTC (permalink / raw)
To: Christian Benvenuti, Sujith Sankar, Govindarajulu Varadarajan,
Neel Patel, netdev
Cc: linux-kernel, Lad, Prabhakar
From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
this patch fixes following sparse warnings:
enic_main.c:92:28: warning: symbol 'mod_table' was not declared. Should it be static?
enic_main.c:109:28: warning: symbol 'mod_range' was not declared. Should it be static?
enic_main.c:1306:5: warning: symbol 'enic_busy_poll' was not declared. Should it be static?
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
Found this issue on linux-next (gcc version 4.8.2,
sparse version 0.4.5-rc1)and applies on top linux-next.
drivers/net/ethernet/cisco/enic/enic_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index ee44c82..9cbe038 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -89,7 +89,7 @@ MODULE_DEVICE_TABLE(pci, enic_id_table);
* coalescing timer values
* {rx_rate in Mbps, mapping percentage of the range}
*/
-struct enic_intr_mod_table mod_table[ENIC_MAX_COALESCE_TIMERS + 1] = {
+static struct enic_intr_mod_table mod_table[ENIC_MAX_COALESCE_TIMERS + 1] = {
{4000, 0},
{4400, 10},
{5060, 20},
@@ -106,7 +106,7 @@ struct enic_intr_mod_table mod_table[ENIC_MAX_COALESCE_TIMERS + 1] = {
/* This table helps the driver to pick different ranges for rx coalescing
* timer depending on the link speed.
*/
-struct enic_intr_mod_range mod_range[ENIC_MAX_LINK_SPEEDS] = {
+static struct enic_intr_mod_range mod_range[ENIC_MAX_LINK_SPEEDS] = {
{0, 0}, /* 0 - 4 Gbps */
{0, 3}, /* 4 - 10 Gbps */
{3, 6}, /* 10 - 40 Gbps */
@@ -1303,7 +1303,7 @@ static void enic_set_rx_cpu_rmap(struct enic *enic)
#endif /* CONFIG_RFS_ACCEL */
#ifdef CONFIG_NET_RX_BUSY_POLL
-int enic_busy_poll(struct napi_struct *napi)
+static int enic_busy_poll(struct napi_struct *napi)
{
struct net_device *netdev = napi->dev;
struct enic *enic = netdev_priv(netdev);
--
1.9.1
^ permalink raw reply related
* [PATCH] flowcache: Fix kernel panic in flow_cache_flush_task
From: Miroslav Urbanek @ 2015-02-05 15:36 UTC (permalink / raw)
To: Steffen Klassert
Cc: Herbert Xu, David S. Miller, Netdev, Linux Kernel, Linus Torvalds,
Tomáš Charvát, Jan Hejl
flow_cache_flush_task references a structure member flow_cache_gc_work
where it should reference flow_cache_flush_task instead.
Kernel panic occurs on kernels using IPsec during XFRM garbage
collection. The garbage collection interval can be shortened using the
following sysctl settings:
net.ipv4.xfrm4_gc_thresh=4
net.ipv6.xfrm6_gc_thresh=4
With the default settings, our productions servers crash approximately
once a week. With the settings above, they crash immediately.
Fixes: ca925cf1534e ("flowcache: Make flow cache name space aware")
Reported-by: Tomáš Charvát <tc@excello.cz>
Tested-by: Jan Hejl <jh@excello.cz>
Signed-off-by: Miroslav Urbanek <mu@miroslavurbanek.com>
---
net/core/flow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/flow.c b/net/core/flow.c
index a0348fd..1033725 100644
--- a/net/core/flow.c
+++ b/net/core/flow.c
@@ -379,7 +379,7 @@ done:
static void flow_cache_flush_task(struct work_struct *work)
{
struct netns_xfrm *xfrm = container_of(work, struct netns_xfrm,
- flow_cache_gc_work);
+ flow_cache_flush_work);
struct net *net = container_of(xfrm, struct net, xfrm);
flow_cache_flush(net);
--
2.0.4
^ permalink raw reply related
* [PATCH] net/macb: fix sparse warning
From: Lad Prabhakar @ 2015-02-05 15:40 UTC (permalink / raw)
To: Nicolas Ferre, netdev; +Cc: linux-kernel, Lad, Prabhakar
From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
this patch fixes following sparse warning:
macb.c:2038:26: warning: symbol 'gem_ethtool_ops' was not declared. Should it be static?
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
Found this issue on linux-next (gcc version 4.8.2,
sparse version 0.4.5-rc1)and applies on top linux-next.
drivers/net/ethernet/cadence/macb.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 31dc080..e6ad68a 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -821,6 +821,7 @@ struct macb {
};
extern const struct ethtool_ops macb_ethtool_ops;
+extern const struct ethtool_ops gem_ethtool_ops;
int macb_mii_init(struct macb *bp);
int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
--
1.9.1
^ permalink raw reply related
* [PATCH] net: bnx2x: fix sparse warnings
From: Lad Prabhakar @ 2015-02-05 15:47 UTC (permalink / raw)
To: Ariel Elior, netdev; +Cc: linux-kernel, Lad, Prabhakar
From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
this patch fixes following sparse warnings:
bnx2x_main.c:9172:6: warning: symbol 'bnx2x_stop_ptp' was not declared. Should it be static?
bnx2x_main.c:13321:6: warning: symbol 'bnx2x_register_phc' was not declared. Should it be static?
bnx2x_main.c:14638:5: warning: symbol 'bnx2x_enable_ptp_packets' was not declared. Should it be static?
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
Found this issue on linux-next (gcc version 4.8.2,
sparse version 0.4.5-rc1)and applies on top linux-next.
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 0758c8b..7155e1d 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -9169,7 +9169,7 @@ static void bnx2x_disable_ptp(struct bnx2x *bp)
}
/* Called during unload, to stop PTP-related stuff */
-void bnx2x_stop_ptp(struct bnx2x *bp)
+static void bnx2x_stop_ptp(struct bnx2x *bp)
{
/* Cancel PTP work queue. Should be done after the Tx queues are
* drained to prevent additional scheduling.
@@ -13318,7 +13318,7 @@ static int bnx2x_ptp_enable(struct ptp_clock_info *ptp,
return -ENOTSUPP;
}
-void bnx2x_register_phc(struct bnx2x *bp)
+static void bnx2x_register_phc(struct bnx2x *bp)
{
/* Fill the ptp_clock_info struct and register PTP clock*/
bp->ptp_clock_info.owner = THIS_MODULE;
@@ -14635,7 +14635,7 @@ static int bnx2x_send_reset_timesync_ramrod(struct bnx2x *bp)
return bnx2x_func_state_change(bp, &func_params);
}
-int bnx2x_enable_ptp_packets(struct bnx2x *bp)
+static int bnx2x_enable_ptp_packets(struct bnx2x *bp)
{
struct bnx2x_queue_state_params q_params;
int rc, i;
--
1.9.1
^ permalink raw reply related
* RE: [PATCH] NetCP: Deletion of unnecessary checks before two function calls
From: Kwok, WingMan @ 2015-02-05 15:50 UTC (permalink / raw)
To: Dan Carpenter
Cc: SF Markus Elfring, Karicheri, Muralidharan,
netdev@vger.kernel.org, LKML, kernel-janitors@vger.kernel.org,
Julia Lawall
In-Reply-To: <20150205120138.GD5336@mwanda>
Dan,
Thanks. We'll look into it and send a patch soon.
Regards,
WingMan
> -----Original Message-----
> From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
> Sent: Thursday, February 05, 2015 7:02 AM
> To: Kwok, WingMan
> Cc: SF Markus Elfring; Karicheri, Muralidharan; Kwok, WingMan;
> netdev@vger.kernel.org; LKML; kernel-janitors@vger.kernel.org; Julia Lawall
> Subject: Re: [PATCH] NetCP: Deletion of unnecessary checks before two
> function calls
>
> Hi Wingman,
>
> There are some bugs in this error handling.
>
> On Tue, Feb 03, 2015 at 08:22:23PM +0100, SF Markus Elfring wrote:
> > diff --git a/drivers/net/ethernet/ti/netcp_ethss.c
> b/drivers/net/ethernet/ti/netcp_ethss.c
> > index fa1041a..cbd6dde 100644
> > --- a/drivers/net/ethernet/ti/netcp_ethss.c
> > +++ b/drivers/net/ethernet/ti/netcp_ethss.c
> > @@ -2010,12 +2010,10 @@ static int gbe_probe(struct netcp_device
> *netcp_device, struct device *dev,
> > quit:
> > if (gbe_dev->hw_stats)
> > devm_kfree(dev, gbe_dev->hw_stats);
> > - if (gbe_dev->ale)
> > - cpsw_ale_destroy(gbe_dev->ale);
> > + cpsw_ale_destroy(gbe_dev->ale);
> > if (gbe_dev->ss_regs)
> > devm_iounmap(dev, gbe_dev->ss_regs);
> > - if (interfaces)
> > - of_node_put(interfaces);
> > + of_node_put(interfaces);
> ^^^^^^^^^^
> "interfaces" is sometimes unintialized in this code. I don't know why
> GCC doesn't catch this... :(
>
> This is a "one rrr bug", which is caused because you just have one error
> label "quit" which handles all the error handling. Please read my
> Google+ comment on error handling.
>
> https://plus.google.com/106378716002406849458/posts/dnanfhQ4mHQ
>
> > devm_kfree(dev, gbe_dev);
> ^^^^^^^^^^^^^^^^^^^^^^^^
> This is not the right way to use the devm_ interface. These things are
> freed automatically on error or when we are done with them. This driver
> is double freeing pretty much everything. Grep for devm_kfree() and
> fix everything.
>
> I don't know why kbuild didn't catch this...
>
> regards
> dan carpenter
^ permalink raw reply
* Re: [PATCH bluetooth-next v2] ieee802154: fix netns settings
From: Marcel Holtmann @ 2015-02-05 16:03 UTC (permalink / raw)
To: Alexander Aring
Cc: Nicolas Dichtel, Network Development, David S. Miller, linux-wpan
In-Reply-To: <20150205091016.GC12279@omega>
Hi Alex,
>>> 6LoWPAN currently doesn't supports x-netns and works only in init_net.
>>>
>>> With this patch, we ensure that:
>>> - the wpan interface cannot be moved to another netns;
>>> - the 6lowpan interface cannot be moved to another netns;
>>> - the wpan interface is in the same netns than the 6lowpan interface;
>>> - the 6lowpan interface is in init_net.
>>>
>>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>>
>> Acked-by: Alexander Aring <alex.aring@gmail.com>
>>
>> Marcel, can you please queue this for bluetooth-next?
>>
>
> ping.
I completely missed this one and it is not even showing up in my local archive. Care to resend it with your ack attached to it.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] net/macb: fix sparse warning
From: Nicolas Ferre @ 2015-02-05 16:06 UTC (permalink / raw)
To: Lad Prabhakar, netdev; +Cc: linux-kernel
In-Reply-To: <1423150846-7027-1-git-send-email-prabhakar.csengg@gmail.com>
Le 05/02/2015 16:40, Lad Prabhakar a écrit :
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warning:
>
> macb.c:2038:26: warning: symbol 'gem_ethtool_ops' was not declared. Should it be static?
Well, actually this function doesn't need to be exported and indeed
should be marked as static.
I'm not against this patch, but removing the export macro and making it
as static should do the trick even better.
Bye,
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> ---
> Found this issue on linux-next (gcc version 4.8.2,
> sparse version 0.4.5-rc1)and applies on top linux-next.
>
> drivers/net/ethernet/cadence/macb.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
> index 31dc080..e6ad68a 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -821,6 +821,7 @@ struct macb {
> };
>
> extern const struct ethtool_ops macb_ethtool_ops;
> +extern const struct ethtool_ops gem_ethtool_ops;
>
> int macb_mii_init(struct macb *bp);
> int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
>
--
Nicolas Ferre
^ permalink raw reply
* RE: PROBLEM: Bnx2x Checksum/Length Error Over GRE Tunnel
From: Yuval Mintz @ 2015-02-05 16:13 UTC (permalink / raw)
To: Eren Türkay; +Cc: netdev, Eric Dumazet
In-Reply-To: <54D1EDCE.3030602@skyatlas.com>
> I am not sure if tx offloading will affect the VM performance. Regardless of OVS
> problem, there seems to be a bug with segmentation offloading as it's only
> possible to use the interface with "tx off". I have compiled the kernel with
> debugging on and I can enable debugging on related parts in the kernel for
> further information.
>
> > Here I easily reach line rate with a single flow.
> >
> > ip tunnel add gre1 mode gre remote 10.246.11.52 local 10.246.11.51 ip
> > link set gre1 up ip addr add 7.7.8.51/24 dev gre1
>
> ip tunnel add gre1 mode gre remote 10.20.0.162 local 10.20.0.161 ip l set gre1
> up ip addr add 7.7.8.161/24 dev gre1
Tried this on latest net-next [using iproute2] and I didn't manage to hit the
issue you've indicated.
I.e., traffic seemed to work fine on gre tunnels using both mtu sizes and
regardless of whether Tx-checksum-offload was enabled or disabled.
Is there anything else which is worth mentioning in your setup?
Thanks,
Yuval
^ permalink raw reply
* [PATCH v2] net/macb: fix sparse warning
From: Lad Prabhakar @ 2015-02-05 16:21 UTC (permalink / raw)
To: Nicolas Ferre, netdev; +Cc: linux-kernel, Lad, Prabhakar
From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
this patch fixes following sparse warning:
macb.c:2038:26: warning: symbol 'gem_ethtool_ops' was not declared. Should it be static?
Alongside drops exporting of gem_ethtool_ops as there is no need.
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
Found this issue on linux-next (gcc version 4.8.2,
sparse version 0.4.5-rc1)and applies on top linux-next.
drivers/net/ethernet/cadence/macb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 4f7bd13..ad76b8e 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2035,7 +2035,7 @@ const struct ethtool_ops macb_ethtool_ops = {
};
EXPORT_SYMBOL_GPL(macb_ethtool_ops);
-const struct ethtool_ops gem_ethtool_ops = {
+static const struct ethtool_ops gem_ethtool_ops = {
.get_settings = macb_get_settings,
.set_settings = macb_set_settings,
.get_regs_len = macb_get_regs_len,
@@ -2046,7 +2046,6 @@ const struct ethtool_ops gem_ethtool_ops = {
.get_strings = gem_get_ethtool_strings,
.get_sset_count = gem_get_sset_count,
};
-EXPORT_SYMBOL_GPL(gem_ethtool_ops);
int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] net/macb: fix sparse warning
From: Lad, Prabhakar @ 2015-02-05 16:22 UTC (permalink / raw)
To: Nicolas Ferre; +Cc: netdev, LKML
In-Reply-To: <54D3951C.1080200@atmel.com>
On Thu, Feb 5, 2015 at 4:06 PM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> Le 05/02/2015 16:40, Lad Prabhakar a écrit :
>> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>>
>> this patch fixes following sparse warning:
>>
>> macb.c:2038:26: warning: symbol 'gem_ethtool_ops' was not declared. Should it be static?
>
> Well, actually this function doesn't need to be exported and indeed
> should be marked as static.
>
> I'm not against this patch, but removing the export macro and making it
> as static should do the trick even better.
>
Done!
[1] https://patchwork.kernel.org/patch/5785511/
Cheers,
--Prabhakar Lad
^ permalink raw reply
* Re: [PATCH] net/macb: fix sparse warning
From: Eric Dumazet @ 2015-02-05 16:29 UTC (permalink / raw)
To: Lad Prabhakar; +Cc: Nicolas Ferre, netdev, linux-kernel, Xander Huff
In-Reply-To: <1423150846-7027-1-git-send-email-prabhakar.csengg@gmail.com>
On Thu, 2015-02-05 at 15:40 +0000, Lad Prabhakar wrote:
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warning:
>
> macb.c:2038:26: warning: symbol 'gem_ethtool_ops' was not declared. Should it be static?
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> ---
> Found this issue on linux-next (gcc version 4.8.2,
> sparse version 0.4.5-rc1)and applies on top linux-next.
>
> drivers/net/ethernet/cadence/macb.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
> index 31dc080..e6ad68a 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -821,6 +821,7 @@ struct macb {
> };
>
> extern const struct ethtool_ops macb_ethtool_ops;
> +extern const struct ethtool_ops gem_ethtool_ops;
>
> int macb_mii_init(struct macb *bp);
> int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
Certainly not.
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 4f7bd13796b87b873a198ffd0760dedbb9077ed4..ad76b8e35a00e188e39d00f4c5f70d97c3df5363 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2035,7 +2035,7 @@ const struct ethtool_ops macb_ethtool_ops = {
};
EXPORT_SYMBOL_GPL(macb_ethtool_ops);
-const struct ethtool_ops gem_ethtool_ops = {
+static const struct ethtool_ops gem_ethtool_ops = {
.get_settings = macb_get_settings,
.set_settings = macb_set_settings,
.get_regs_len = macb_get_regs_len,
@@ -2046,7 +2046,6 @@ const struct ethtool_ops gem_ethtool_ops = {
.get_strings = gem_get_ethtool_strings,
.get_sset_count = gem_get_sset_count,
};
-EXPORT_SYMBOL_GPL(gem_ethtool_ops);
int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
^ permalink raw reply related
* Re: [PATCH] net: bnx2x: fix sparse warnings
From: Eric Dumazet @ 2015-02-05 16:30 UTC (permalink / raw)
To: Lad Prabhakar; +Cc: Ariel Elior, netdev, linux-kernel
In-Reply-To: <1423151237-20746-1-git-send-email-prabhakar.csengg@gmail.com>
On Thu, 2015-02-05 at 15:47 +0000, Lad Prabhakar wrote:
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warnings:
>
> bnx2x_main.c:9172:6: warning: symbol 'bnx2x_stop_ptp' was not declared. Should it be static?
> bnx2x_main.c:13321:6: warning: symbol 'bnx2x_register_phc' was not declared. Should it be static?
> bnx2x_main.c:14638:5: warning: symbol 'bnx2x_enable_ptp_packets' was not declared. Should it be static?
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> ---
Note there is no need to cc lkml for such patches, netdev is more than
enough.
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH v2] net/macb: fix sparse warning
From: Nicolas Ferre @ 2015-02-05 16:40 UTC (permalink / raw)
To: Lad Prabhakar, netdev, Eric Dumazet; +Cc: linux-kernel
In-Reply-To: <1423153267-1768-1-git-send-email-prabhakar.csengg@gmail.com>
Le 05/02/2015 17:21, Lad Prabhakar a écrit :
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warning:
>
> macb.c:2038:26: warning: symbol 'gem_ethtool_ops' was not declared. Should it be static?
>
> Alongside drops exporting of gem_ethtool_ops as there is no need.
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Okay with this one:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks! Bye,
> ---
> Found this issue on linux-next (gcc version 4.8.2,
> sparse version 0.4.5-rc1)and applies on top linux-next.
>
> drivers/net/ethernet/cadence/macb.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index 4f7bd13..ad76b8e 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -2035,7 +2035,7 @@ const struct ethtool_ops macb_ethtool_ops = {
> };
> EXPORT_SYMBOL_GPL(macb_ethtool_ops);
>
> -const struct ethtool_ops gem_ethtool_ops = {
> +static const struct ethtool_ops gem_ethtool_ops = {
> .get_settings = macb_get_settings,
> .set_settings = macb_set_settings,
> .get_regs_len = macb_get_regs_len,
> @@ -2046,7 +2046,6 @@ const struct ethtool_ops gem_ethtool_ops = {
> .get_strings = gem_get_ethtool_strings,
> .get_sset_count = gem_get_sset_count,
> };
> -EXPORT_SYMBOL_GPL(gem_ethtool_ops);
>
> int macb_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
> {
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH] flowcache: Fix kernel panic in flow_cache_flush_task
From: Eric Dumazet @ 2015-02-05 16:44 UTC (permalink / raw)
To: Miroslav Urbanek
Cc: Steffen Klassert, Herbert Xu, David S. Miller, Netdev,
Linux Kernel, Linus Torvalds, Tomáš Charvát,
Jan Hejl, Fan Du
In-Reply-To: <20150205153649.GA3278@miroslavurbanek.com>
On Thu, 2015-02-05 at 16:36 +0100, Miroslav Urbanek wrote:
> flow_cache_flush_task references a structure member flow_cache_gc_work
> where it should reference flow_cache_flush_task instead.
>
> Kernel panic occurs on kernels using IPsec during XFRM garbage
> collection. The garbage collection interval can be shortened using the
> following sysctl settings:
>
> net.ipv4.xfrm4_gc_thresh=4
> net.ipv6.xfrm6_gc_thresh=4
>
> With the default settings, our productions servers crash approximately
> once a week. With the settings above, they crash immediately.
>
> Fixes: ca925cf1534e ("flowcache: Make flow cache name space aware")
> Reported-by: Tomáš Charvát <tc@excello.cz>
> Tested-by: Jan Hejl <jh@excello.cz>
> Signed-off-by: Miroslav Urbanek <mu@miroslavurbanek.com>
> ---
Nice catch !
Ok, but you do not need to cc so many people/lists
netdev is fine, and we usually CC patch author, just in case.
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net-next v2] hyper-v: allow access to vmbus from userspace driver
From: Stephen Hemminger @ 2015-02-05 16:50 UTC (permalink / raw)
To: Vitaly Kuznetsov
Cc: dev-VfR2kkLFssw, devel-tBiZLqfeLfOHmIFyCCdPziST3g8Odh+X,
Haiyang Zhang, KY Srinivasan, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87egq4r5ao.fsf-hpI3/L/TUU23oHxwIazZmlaTQe2KTcn/@public.gmane.org>
On Thu, 05 Feb 2015 12:01:03 +0100
Vitaly Kuznetsov <vkuznets-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org> writes:
>
> > This is enables the hyper-v driver for DPDK <dev-VfR2kkLFssw@public.gmane.org>.
> > The hv_uio driver needs to access the shared vmbus monitor
> > pages.
>
> Why can't we just make vmbus_connection struct public?
>
> >
> > I would also like to put hv_uio in upstream kernel like other
> > uio drivers, but need to get API accepted with DPDK first.
> >
> > Signed-off-by: Stas Egorov <segorov-nYU0QVwCCFFWk0Htik3J/w@public.gmane.org>
> > Signed-off-by: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
> >
> > ---
> > v2 - simplify and rename to vmbus_get_monitor_pages
> >
> > drivers/hv/connection.c | 20 +++++++++++++++++---
> > include/linux/hyperv.h | 3 +++
> > 2 files changed, 20 insertions(+), 3 deletions(-)
> >
> > --- a/drivers/hv/connection.c 2015-02-03 10:58:51.751752450 -0800
> > +++ b/drivers/hv/connection.c 2015-02-04 14:59:51.636194383 -0800
> > @@ -64,6 +64,15 @@ static __u32 vmbus_get_next_version(__u3
> > }
> > }
> >
> > +void vmbus_get_monitor_pages(unsigned long *int_page,
> > + unsigned long monitor_pages[2])
> > +{
>
> Too weird to be a public interface in my opinion.
>
> > + *int_page = (unsigned long)vmbus_connection.int_page;
> > + monitor_pages[0] = (unsigned long)vmbus_connection.monitor_pages[0];
> > + monitor_pages[1] = (unsigned long)vmbus_connection.monitor_pages[1];
> > +}
> > +EXPORT_SYMBOL_GPL(vmbus_get_monitor_pages);
> > +
> > static int vmbus_negotiate_version(struct vmbus_channel_msginfo *msginfo,
> > __u32 version)
> > {
> > @@ -347,10 +356,7 @@ static void process_chn_event(u32 relid)
> > else
> > bytes_to_read = 0;
> > } while (read_state && (bytes_to_read != 0));
> > - } else {
> > - pr_err("no channel callback for relid - %u\n", relid);
> > }
> > -
> > }
>
> This change wasn't mentioned in your commit msg.
Was in earlier commit. Need to prevent driver from logging error
when device is not claimed directly by existing kernel devices.
^ permalink raw reply
* RE: [PATCH] hyperv: fix sparse warnings
From: Haiyang Zhang @ 2015-02-05 17:04 UTC (permalink / raw)
To: Lad Prabhakar, KY Srinivasan, devel@linuxdriverproject.org
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1423148793-19610-1-git-send-email-prabhakar.csengg@gmail.com>
> -----Original Message-----
> From: Lad Prabhakar [mailto:prabhakar.csengg@gmail.com]
> Sent: Thursday, February 5, 2015 10:07 AM
> To: KY Srinivasan; Haiyang Zhang; devel@linuxdriverproject.org
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Lad, Prabhakar
> Subject: [PATCH] hyperv: fix sparse warnings
>
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warnings:
>
> netvsc.c:688:5: warning: symbol 'netvsc_copy_to_send_buf' was not
> declared. Should it be static?
> rndis_filter.c:627:5: warning: symbol 'rndis_filter_set_offload_params'
> was not declared. Should it be static?
> rndis_filter.c:702:5: warning: symbol 'rndis_filter_set_rss_param' was
> not declared. Should it be static?
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] bridge: Let bridge not age 'externally' learnt FDB entries, they are removed when 'external' entity notifies the aging
From: Scott Feldman @ 2015-02-05 17:10 UTC (permalink / raw)
To: B Viswanath
Cc: Siva Mannem, David Miller, Roopa Prabhu, Netdev,
Jiří Pírko
In-Reply-To: <CAN+pFwJQQMFmmm1f7tSPCmaSr2GE_L8Pua+Rz7tvK9CFnr63Tg@mail.gmail.com>
On Thu, Feb 5, 2015 at 3:05 AM, B Viswanath <marichika4@gmail.com> wrote:
> On 5 February 2015 at 15:56, Siva Mannem <siva.mannem.lnx@gmail.com> wrote:
>> On Thu, Feb 5, 2015 at 1:23 PM, David Miller <davem@davemloft.net> wrote:
>>> From: Scott Feldman <sfeldma@gmail.com>
>>> Date: Wed, 4 Feb 2015 23:13:07 -0800
>>>
>>>> I'd like to see this patch reverted so we can have a more
>>>> comprehensive discussion/solution. With this patch applied, the only
>>>> user (rocker) of NETDEV_SWITCH_FDB_ADD is broken. So please undo this
>>>> patch so rocker isn't broken and let's work on a knob to suit both
>>>> modes: 1) let bridge manage aging, 2) let device manage aging.
>>>
>>> Patch reverted.
>>
>> I now see why rocker is broken. Sorry for the churn.
>> As Scott/Roopa suggested, a new flag IFLA_BRPORT_AGING_SYNC (similar
>> to IFLA_BRPORT_LEARNING_SYNC) can be defined and stored in
>> net_bridge_port->flags when user configures it. Some thing like below.
>>
>> $ sudo bridge link set dev swp1 ageing_sync on self
>>
>> And bridge ageing logic does not age externally learnt entry *only* if
>> IFLA_BRPORT_AGING_SYNC flag on fdb entry's net_bridge_port is set.
>> This ensures that existing behavior continues to be default behavior
>> and is of no harm to rocker.
>>
>> Please let me know your comments on above approach.
>
> I am not sure you really want to pass on this burden of deciding who
> should age to the end user. I think user should not be forced to be
> aware of all the device and driver properties.
>
> May be a different way would be that -
>
> 1. driver specifies whether it can supporting ageing by itself (the
> chip) during registration.
> 2. driver also allows that kernel turn off the driver/device ageing.
> 3. when a bridge is created with all ports from same device which
> supports ageing (and which is currently enabled), then bridge defers
> ageing to driver. Otherwise bridge disables ageing on all
> participating devices and takes care of ageing by itself.
> 4. When ageing is disabled on a device, all other bridges that use any
> ports from that device start ageing themselves.
>
> I guess this sounds complicated, but it can ensure that user gets the
> best default behaviour based on the device. Any alternate suggestions
> ?
>
> Thanks
> vissu
>
>> --
>> Regards,
>> Siva Mannem.
>> --
>> 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
* Re: Throughput regression with `tcp: refine TSO autosizing`
From: Eric Dumazet @ 2015-02-05 17:10 UTC (permalink / raw)
To: Michal Kazior; +Cc: Neal Cardwell, linux-wireless, Network Development, eyalpe
In-Reply-To: <1423147286.31870.59.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, 2015-02-05 at 06:41 -0800, Eric Dumazet wrote:
> Not at all. This basically removes backpressure.
>
> A single UDP socket can now blast packets regardless of SO_SNDBUF
> limits.
>
> This basically remove years of work trying to fix bufferbloat.
>
> I still do not understand why increasing tcp_limit_output_bytes is not
> working for you.
Oh well, tcp_limit_output_bytes might be ok.
In fact, the problem comes from GSO assumption. Maybe Herbert was right,
when he suggested TCP would be simpler if we enforced GSO...
When GSO is used, the thing works because 2*skb->truesize is roughly 2
ms worth of traffic.
Because you do not use GSO, and tx completions are slow, we need this :
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 65caf8b95e17..ac01b4cd0035 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2044,7 +2044,8 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
break;
/* TCP Small Queues :
- * Control number of packets in qdisc/devices to two packets / or ~1 ms.
+ * Control number of packets in qdisc/devices to two packets /
+ * or ~2 ms (sk->sk_pacing_rate >> 9) in case GSO is off.
* This allows for :
* - better RTT estimation and ACK scheduling
* - faster recovery
@@ -2053,7 +2054,7 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
* of queued bytes to ensure line rate.
* One example is wifi aggregation (802.11 AMPDU)
*/
- limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 10);
+ limit = max(2 * skb->truesize, sk->sk_pacing_rate >> 9);
limit = min_t(u32, limit, sysctl_tcp_limit_output_bytes);
if (atomic_read(&sk->sk_wmem_alloc) > limit) {
^ permalink raw reply related
* [PATCH bluetooth-next v3] ieee802154: fix netns settings
From: Nicolas Dichtel @ 2015-02-05 17:21 UTC (permalink / raw)
To: marcel; +Cc: alex.aring, netdev, davem, Nicolas Dichtel
In-Reply-To: <1DEA1346-A348-434E-90F3-80E9EDC7E181@holtmann.org>
6LoWPAN currently doesn't supports x-netns and works only in init_net.
With this patch, we ensure that:
- the wpan interface cannot be moved to another netns;
- the 6lowpan interface cannot be moved to another netns;
- the wpan interface is in the same netns than the 6lowpan interface;
- the 6lowpan interface is in init_net.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Alexander Aring <alex.aring@gmail.com>
---
Note: only compile tested.
v3: rebase on head of bluetooth-next
add the Acked-by line
v2: update patch title
rebase the patch on bluetooth-next
update flag features in cfg802154_netdev_notifier_call
net/ieee802154/6lowpan/core.c | 6 ++++--
net/ieee802154/core.c | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c
index 055fbb71ba6f..dfd3c6007f60 100644
--- a/net/ieee802154/6lowpan/core.c
+++ b/net/ieee802154/6lowpan/core.c
@@ -126,6 +126,7 @@ static void lowpan_setup(struct net_device *dev)
dev->header_ops = &lowpan_header_ops;
dev->ml_priv = &lowpan_mlme;
dev->destructor = free_netdev;
+ dev->features |= NETIF_F_NETNS_LOCAL;
}
static int lowpan_validate(struct nlattr *tb[], struct nlattr *data[])
@@ -148,10 +149,11 @@ static int lowpan_newlink(struct net *src_net, struct net_device *dev,
pr_debug("adding new link\n");
- if (!tb[IFLA_LINK])
+ if (!tb[IFLA_LINK] ||
+ !net_eq(dev_net(dev), &init_net))
return -EINVAL;
/* find and hold real wpan device */
- real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
+ real_dev = dev_get_by_index(dev_net(dev), nla_get_u32(tb[IFLA_LINK]));
if (!real_dev)
return -ENODEV;
if (real_dev->type != ARPHRD_IEEE802154) {
diff --git a/net/ieee802154/core.c b/net/ieee802154/core.c
index 18bc7e738507..888d0991c761 100644
--- a/net/ieee802154/core.c
+++ b/net/ieee802154/core.c
@@ -225,6 +225,7 @@ static int cfg802154_netdev_notifier_call(struct notifier_block *nb,
switch (state) {
/* TODO NETDEV_DEVTYPE */
case NETDEV_REGISTER:
+ dev->features |= NETIF_F_NETNS_LOCAL;
wpan_dev->identifier = ++rdev->wpan_dev_id;
list_add_rcu(&wpan_dev->list, &rdev->wpan_dev_list);
rdev->devlist_generation++;
--
2.2.2
^ permalink raw reply related
* Re: [PATCH net-next 3/4] ethtool: add RX_ALLOC_ORDER to tunable
From: Govindarajulu Varadarajan @ 2015-02-05 17:28 UTC (permalink / raw)
To: David Miller; +Cc: _govind, netdev, ssujith, benve, edumazet, ben
In-Reply-To: <alpine.LNX.2.03.1502031326260.22700@ws.cisco>
On Tue, 3 Feb 2015, Govindarajulu Varadarajan wrote:
> On Mon, 2 Feb 2015, David Miller wrote:
>
>> From: Govindarajulu Varadarajan <_govind@gmx.com>
>> Date: Sat, 31 Jan 2015 17:58:09 +0530
>>
>>> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
>>
>> This is terrible.
>>
>> You haven't explained what this means.
>>
>> And to tell you the truth, from what I can tell this tunable is
>> very specific to how you have implemented RX frags in the enic
>> driver in this series and won't necessarily translate to how
>> other drivers manage RX buffers.
>>
>
> Yes I agree that this is too specific to driver. From my knowledge mlx4 also
> uses similar frag allocation from large order page. Other that these two
> drivers, this facility may not make sense to other drivers.
>
> On systems with huge memory we can go higher than order-3, and if user sees
> that
> order-3 are failing, he should be able to reduce the order.
>
> Since this is very driver specific, are you fine if I move this to device
> sysfs?
>
I hope there are no issues with the patch 1 & 2. Should I drop the
'changing order' patches and resend patch 1 & 2 alone?
^ permalink raw reply
* Re: [PATCH bluetooth-next v3] ieee802154: fix netns settings
From: Alexander Aring @ 2015-02-05 17:31 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: marcel, netdev, davem
In-Reply-To: <1423156890-13382-1-git-send-email-nicolas.dichtel@6wind.com>
Hi Nicolas,
On Thu, Feb 05, 2015 at 06:21:30PM +0100, Nicolas Dichtel wrote:
> 6LoWPAN currently doesn't supports x-netns and works only in init_net.
>
> With this patch, we ensure that:
> - the wpan interface cannot be moved to another netns;
> - the 6lowpan interface cannot be moved to another netns;
> - the wpan interface is in the same netns than the 6lowpan interface;
> - the 6lowpan interface is in init_net.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Acked-by: Alexander Aring <alex.aring@gmail.com>
thanks for resend this patch and added my ack, thanks.
- Alex
^ permalink raw reply
* Re: [PATCH] flowcache: Fix kernel panic in flow_cache_flush_task
From: Miroslav Urbanek @ 2015-02-05 17:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: Steffen Klassert, Netdev, Tomáš Charvát, Jan Hejl
In-Reply-To: <1423154648.31870.81.camel@edumazet-glaptop2.roam.corp.google.com>
Thanks for the tip. It's my first kernel patch, so I wanted to make
sure it won't get lost :-)
Anyway, I also looked into the function flow_cache_fini. Isn't it
necessary to flush/cancel scheduled works here? Something like:
flush_work(&net->xfrm.flow_cache_flush_work);
flush_work(&net->xfrm.flow_cache_gc_work);
I'm not sure if it is a bug or not. Could it happen that there is a
scheduled work while the kernel calls flow_cache_fini?
I originally suspected this was the real bug we hit, but we don't use
net namespaces, so our kernels never call flow_cache_fini.
>
> Nice catch !
>
> Ok, but you do not need to cc so many people/lists
>
> netdev is fine, and we usually CC patch author, just in case.
>
> Acked-by: Eric Dumazet <edumazet@google.com>
>
^ permalink raw reply
* [PATCH net] rtnetlink: ifla_vf_policy: fix misuses of NLA_BINARY
From: Daniel Borkmann @ 2015-02-05 17:44 UTC (permalink / raw)
To: davem; +Cc: netdev, Daniel Borkmann, Mitch Williams, Jeff Kirsher
ifla_vf_policy[] is wrong in advertising its individual member types as
NLA_BINARY since .type = NLA_BINARY in combination with .len declares the
len member as *max* attribute length [0, len].
The issue is that when do_setvfinfo() is being called to set up a VF
through ndo handler, we could set corrupted data if the attribute length
is less than the size of the related structure itself.
The intent is exactly the opposite, namely to make sure to pass at least
data of minimum size of len.
Fixes: ebc08a6f47ee ("rtnetlink: Add VF config code to rtnetlink")
Cc: Mitch Williams <mitch.a.williams@intel.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
net/core/rtnetlink.c | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 446cbaf..5daabfd 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1237,18 +1237,12 @@ static const struct nla_policy ifla_vfinfo_policy[IFLA_VF_INFO_MAX+1] = {
};
static const struct nla_policy ifla_vf_policy[IFLA_VF_MAX+1] = {
- [IFLA_VF_MAC] = { .type = NLA_BINARY,
- .len = sizeof(struct ifla_vf_mac) },
- [IFLA_VF_VLAN] = { .type = NLA_BINARY,
- .len = sizeof(struct ifla_vf_vlan) },
- [IFLA_VF_TX_RATE] = { .type = NLA_BINARY,
- .len = sizeof(struct ifla_vf_tx_rate) },
- [IFLA_VF_SPOOFCHK] = { .type = NLA_BINARY,
- .len = sizeof(struct ifla_vf_spoofchk) },
- [IFLA_VF_RATE] = { .type = NLA_BINARY,
- .len = sizeof(struct ifla_vf_rate) },
- [IFLA_VF_LINK_STATE] = { .type = NLA_BINARY,
- .len = sizeof(struct ifla_vf_link_state) },
+ [IFLA_VF_MAC] = { .len = sizeof(struct ifla_vf_mac) },
+ [IFLA_VF_VLAN] = { .len = sizeof(struct ifla_vf_vlan) },
+ [IFLA_VF_TX_RATE] = { .len = sizeof(struct ifla_vf_tx_rate) },
+ [IFLA_VF_SPOOFCHK] = { .len = sizeof(struct ifla_vf_spoofchk) },
+ [IFLA_VF_RATE] = { .len = sizeof(struct ifla_vf_rate) },
+ [IFLA_VF_LINK_STATE] = { .len = sizeof(struct ifla_vf_link_state) },
};
static const struct nla_policy ifla_port_policy[IFLA_PORT_MAX+1] = {
--
1.9.3
^ permalink raw reply related
* [GIT] [3.20] 2nd NFC update
From: Samuel Ortiz @ 2015-02-05 17:47 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
Hi David,
Here goes one last NFC pull request for 3.20.
It brings:
- NCI NFCEE (NFC Execution Environment, typically an embedded or
external secure element) discovery and enabling/disabling support.
In order to communicate with an NFCEE, we also added NCI's logical
connections support to the NCI stack.
- HCI over NCI protocol support. Some secure elements only understand
HCI and thus we need to send them HCI frames when they're part of
an NCI chipset.
- NFC_EVT_TRANSACTION userspace API addition. Whenever an application
running on a secure element needs to notify its host counterpart,
we send an NFC_EVENT_SE_TRANSACTION event to userspace through the
NFC netlink socket.
- Secure element and HCI transaction event support for the st21nfcb
chipset.
Thanks in advance for pulling them in.
The following changes since commit 86b3bfe914f41c2d47d5882d06e1261cc58fb5e9:
pkt_sched: fq: remove useless TIME_WAIT check (2015-01-28 23:23:57 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next.git tags/nfc-next-3.20-2
for you to fetch changes up to fa00e8fed457841cb24219dbe3cfba7d56de6317:
NFC: nci: Move NFCEE discovery logic (2015-02-04 09:15:18 +0100)
----------------------------------------------------------------
Christophe Ricard (17):
NFC: nci: Add dynamic logical connections support
NFC: nci: Add NCI NFCEE constants
NFC: nci: Add NFCEE discover support
NFC: nci: Add NFCEE enabling and disabling support
NFC: nci: Support logical connections management
NFC: nci: Add HCI over NCI protocol support
NFC: st21nfcb: Add support for secure element
NFC: Forward NFC_EVT_TRANSACTION to user space
NFC: nci: Add RF NFCEE action notification support
NFC: nci: Change NCI state machine to LISTEN_ACTIVE
NFC: st21nfcb: Add HCI transaction event support
NFC: st21nfca: Add HCI transaction event support
NFC: nci: Add reference to the RF logical connection
NFC: nci: Support all destinations type when creating a connection
NFC: nci: Change credits field to credits_cnt
NFC: nci: Move logical connection structure allocation
NFC: nci: Move NFCEE discovery logic
drivers/nfc/st21nfca/st21nfca_se.c | 21 ++
drivers/nfc/st21nfcb/Makefile | 2 +-
drivers/nfc/st21nfcb/st21nfcb.c | 11 +-
drivers/nfc/st21nfcb/st21nfcb.h | 2 +
drivers/nfc/st21nfcb/st21nfcb_se.c | 707 +++++++++++++++++++++++++++++++++++++
drivers/nfc/st21nfcb/st21nfcb_se.h | 61 ++++
include/net/nfc/nci.h | 97 +++++
include/net/nfc/nci_core.h | 137 ++++++-
include/net/nfc/nfc.h | 27 ++
include/uapi/linux/nfc.h | 1 +
net/nfc/core.c | 21 ++
net/nfc/nci/Makefile | 2 +-
net/nfc/nci/core.c | 169 ++++++++-
net/nfc/nci/data.c | 56 ++-
net/nfc/nci/hci.c | 694 ++++++++++++++++++++++++++++++++++++
net/nfc/nci/ntf.c | 77 +++-
net/nfc/nci/rsp.c | 120 ++++++-
net/nfc/netlink.c | 47 +++
net/nfc/nfc.h | 2 +
19 files changed, 2203 insertions(+), 51 deletions(-)
create mode 100644 drivers/nfc/st21nfcb/st21nfcb_se.c
create mode 100644 drivers/nfc/st21nfcb/st21nfcb_se.h
create mode 100644 net/nfc/nci/hci.c
^ permalink raw reply
* Re: [PATCH v2] socket.7: add description for SO_BUSY_POLL
From: Eliezer Tamir @ 2015-02-05 17:48 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-man, David Miller, lkml, netdev, Andrew Morton,
Eliezer Tamir
In-Reply-To: <CAKgNAki16GXAs5J5cXPzftxxrvaugOvQSamVsGe4jFQF9V=fAQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 05/02/2015 15:17, Michael Kerrisk (man-pages) wrote:
> On 20 January 2014 at 18:28, Eliezer Tamir
> <eliezer.tamir-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>> On 20/01/2014 18:28, Michael Kerrisk (man-pages) wrote:
>>> On 07/10/2013 04:18 PM, Eliezer Tamir wrote:
>>>> Add description for the SO_BUSY_POLL socket option to the socket(7) manpage.
>>>
>>> Long after the fact, I've applied this. Thanks, Eliezer.
>>>
>>> Would you be willing also to write a patch for the POLL_BUSY_LOOP flag of
>>> poll()?
>>
>> Yes, Me or someone from our team will do that.
>
> Hi Eliezer,
>
> Could you or someone from your team send me a POLL_BUSY_LOOP doc patch?
Hi Michael,
Right now POLL_BUSY_LOOP is only used internally to control busylooping,
as a signal between sock_poll() and do_poll().
Our original intention was to expose that to the users of epoll().
The work on epoll() support is not finished yet.
I think we should not document this until we finalize epoll() support.
Thanks,
Eliezer
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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