* Re: [PATCH net-next] xen-netfront: convert to GRO API and advertise this feature
From: Eric Dumazet @ 2013-09-23 5:58 UTC (permalink / raw)
To: Anirban Chakraborty
Cc: Wei Liu, <netdev@vger.kernel.org>,
<xen-devel@lists.xen.org>, Ian Campbell
In-Reply-To: <D310C490-3B7D-4937-95DC-AFC1682B60BE@juniper.net>
On Sun, 2013-09-22 at 23:09 +0000, Anirban Chakraborty wrote:
> On Sep 22, 2013, at 7:55 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > On Sat, 2013-09-21 at 17:05 +0100, Wei Liu wrote:
> >> Anirban was seeing netfront received MTU size packets, which downgraded
> >> throughput. The following patch makes netfront use GRO API which
> >> improves throughput for that case.
> >
> >> - netdev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO;
> >> + netdev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO |
> >> + NETIF_F_GRO;
> >
> >
> > This part is not needed.
>
> Shouldn't the flag be set? In dev_gro_receive() we do check if this flag is set or not:
>
> if (!(skb->dev->features & NETIF_F_GRO) || netpoll_rx_on(skb))
> goto normal;
Drivers do not set NETIF_F_GRO themselves, they do not need to.
Look at other drivers which are GRO ready : NETIF_F_GRO is enabled by
default by core networking stack, in register_netdevice()
dev->hw_features |= NETIF_F_SOFT_FEATURES;
dev->features |= NETIF_F_SOFT_FEATURES;
^ permalink raw reply
* Re: [PATCH 01/12] ping.h: Remove extern from function prototypes
From: David Miller @ 2013-09-23 5:51 UTC (permalink / raw)
To: joe; +Cc: netdev, linux-kernel
In-Reply-To: <b692aba58032f629907ea2d462c99b87906645ca.1379870986.git.joe@perches.com>
Series applied, thanks Joe.
^ permalink raw reply
* Re: [Xen-devel] [PATCH net-next] xen-netfront: convert to GRO API and advertise this feature
From: Jason Wang @ 2013-09-23 5:02 UTC (permalink / raw)
To: Anirban Chakraborty, Wei Liu
Cc: <netdev@vger.kernel.org>, Ian Campbell,
<xen-devel@lists.xen.org>
In-Reply-To: <9C83E3AC-719D-4290-8C19-A06356C4BFFA@juniper.net>
On 09/23/2013 07:04 AM, Anirban Chakraborty wrote:
> On Sep 22, 2013, at 5:09 AM, Wei Liu <wei.liu2@citrix.com> wrote:
>
>> On Sun, Sep 22, 2013 at 02:29:15PM +0800, Jason Wang wrote:
>>> On 09/22/2013 12:05 AM, Wei Liu wrote:
>>>> Anirban was seeing netfront received MTU size packets, which downgraded
>>>> throughput. The following patch makes netfront use GRO API which
>>>> improves throughput for that case.
>>>>
>>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>>>> Signed-off-by: Anirban Chakraborty <abchak@juniper.net>
>>>> Cc: Ian Campbell <ian.campbell@citrix.com>
>>> Maybe a dumb question: doesn't Xen depends on the driver of host card to
>>> do GRO and pass it to netfront? What the case that netfront can receive
>> The would be the ideal situation. Netback pushes large packets to
>> netfront and netfront sees large packets.
>>
>>> a MTU size packet, for a card that does not support GRO in host? Doing
>> However Anirban saw the case when backend interface receives large
>> packets but netfront sees MTU size packets, so my thought is there is
>> certain configuration that leads to this issue. As we cannot tell
>> users what to enable and what not to enable so I would like to solve
>> this within our driver.
>>
>>> GRO twice may introduce extra overheads.
>>>
>> AIUI if the packet that frontend sees is large already then the GRO path
>> is quite short which will not introduce heavy penalty, while on the
>> other hand if packet is segmented doing GRO improves throughput.
>>
> Thanks Wei, for explaining and submitting the patch. I would like add following to what you have already mentioned.
> In my configuration, I was seeing netback was pushing large packets to the guest (Centos 6.4) but the netfront was receiving MTU sized packets. With this patch on, I do see large packets received on the guest interface. As a result there was substantial throughput improvement in the guest side (2.8 Gbps to 3.8 Gbps). Also, note that the host NIC driver was enabled for GRO already.
>
> -Anirban
In this case, even if you still want to do GRO. It's better to find the
root cause of why the GSO packet were segmented (maybe GSO were not
enabled for netback?), since it introduces extra overheads.
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v2] qlge: call ql_core_dump() only if dump memory was allocated.
From: Jitendra Kalsaria @ 2013-09-23 4:41 UTC (permalink / raw)
To: Malahal Naineni, netdev
In-Reply-To: <1379712077-31750-1-git-send-email-malahal@us.ibm.com>
On 9/20/13 2:21 PM, "Malahal Naineni" <malahal@us.ibm.com> wrote:
>Also changed a log message to indicate that memory was not allocated
>instead of memory not available!
>
>Signed-off-by: Malahal Naineni <malahal@us.ibm.com>
>---
> drivers/net/ethernet/qlogic/qlge/qlge_dbg.c | 4 ++--
> drivers/net/ethernet/qlogic/qlge/qlge_mpi.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
Acked-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Thanks,
Jitendra
^ permalink raw reply
* [PATCH] i40e: using for_each_set_bit to simplify the code
From: Wei Yongjun @ 2013-09-23 3:39 UTC (permalink / raw)
To: jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan,
carolyn.wyborny, donald.c.skidmore, gregory.v.rose,
peter.p.waskiewicz.jr, alexander.h.duyck, john.ronciak,
tushar.n.dave, shannon.nelson, mitch.a.williams
Cc: yongjun_wei, e1000-devel, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Using for_each_set_bit() to simplify the code.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 64 ++++------------------
1 file changed, 12 insertions(+), 52 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 8967e58..84d7675 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -260,23 +260,17 @@ static void i40e_config_irq_link_list(struct i40e_vf *vf, u16 vsi_idx,
goto irq_list_done;
}
tempmap = vecmap->rxq_map;
- vsi_queue_id = find_first_bit(&tempmap, I40E_MAX_VSI_QP);
- while (vsi_queue_id < I40E_MAX_VSI_QP) {
+ for_each_set_bit(vsi_queue_id, &tempmap, I40E_MAX_VSI_QP) {
linklistmap |= (1 <<
(I40E_VIRTCHNL_SUPPORTED_QTYPES *
vsi_queue_id));
- vsi_queue_id =
- find_next_bit(&tempmap, I40E_MAX_VSI_QP, vsi_queue_id + 1);
}
tempmap = vecmap->txq_map;
- vsi_queue_id = find_first_bit(&tempmap, I40E_MAX_VSI_QP);
- while (vsi_queue_id < I40E_MAX_VSI_QP) {
+ for_each_set_bit(vsi_queue_id, &tempmap, I40E_MAX_VSI_QP) {
linklistmap |= (1 <<
(I40E_VIRTCHNL_SUPPORTED_QTYPES * vsi_queue_id
+ 1));
- vsi_queue_id = find_next_bit(&tempmap, I40E_MAX_VSI_QP,
- vsi_queue_id + 1);
}
next_q = find_first_bit(&linklistmap,
@@ -1291,27 +1285,21 @@ static int i40e_vc_config_irq_map_msg(struct i40e_vf *vf, u8 *msg, u16 msglen)
/* lookout for the invalid queue index */
tempmap = map->rxq_map;
- vsi_queue_id = find_first_bit(&tempmap, I40E_MAX_VSI_QP);
- while (vsi_queue_id < I40E_MAX_VSI_QP) {
+ for_each_set_bit(vsi_queue_id, &tempmap, I40E_MAX_VSI_QP) {
if (!i40e_vc_isvalid_queue_id(vf, vsi_id,
vsi_queue_id)) {
aq_ret = I40E_ERR_PARAM;
goto error_param;
}
- vsi_queue_id = find_next_bit(&tempmap, I40E_MAX_VSI_QP,
- vsi_queue_id + 1);
}
tempmap = map->txq_map;
- vsi_queue_id = find_first_bit(&tempmap, I40E_MAX_VSI_QP);
- while (vsi_queue_id < I40E_MAX_VSI_QP) {
+ for_each_set_bit(vsi_queue_id, &tempmap, I40E_MAX_VSI_QP) {
if (!i40e_vc_isvalid_queue_id(vf, vsi_id,
vsi_queue_id)) {
aq_ret = I40E_ERR_PARAM;
goto error_param;
}
- vsi_queue_id = find_next_bit(&tempmap, I40E_MAX_VSI_QP,
- vsi_queue_id + 1);
}
i40e_config_irq_link_list(vf, vsi_id, map);
@@ -1356,31 +1344,23 @@ static int i40e_vc_enable_queues_msg(struct i40e_vf *vf, u8 *msg, u16 msglen)
}
tempmap = vqs->rx_queues;
- queue_id = find_first_bit(&tempmap, I40E_MAX_VSI_QP);
- while (queue_id < I40E_MAX_VSI_QP) {
+ for_each_set_bit(queue_id, &tempmap, I40E_MAX_VSI_QP) {
if (!i40e_vc_isvalid_queue_id(vf, vsi_id, queue_id)) {
aq_ret = I40E_ERR_PARAM;
goto error_param;
}
i40e_ctrl_vsi_rx_queue(vf, vsi_id, queue_id,
I40E_QUEUE_CTRL_ENABLE);
-
- queue_id = find_next_bit(&tempmap, I40E_MAX_VSI_QP,
- queue_id + 1);
}
tempmap = vqs->tx_queues;
- queue_id = find_first_bit(&tempmap, I40E_MAX_VSI_QP);
- while (queue_id < I40E_MAX_VSI_QP) {
+ for_each_set_bit(queue_id, &tempmap, I40E_MAX_VSI_QP) {
if (!i40e_vc_isvalid_queue_id(vf, vsi_id, queue_id)) {
aq_ret = I40E_ERR_PARAM;
goto error_param;
}
i40e_ctrl_vsi_tx_queue(vf, vsi_id, queue_id,
I40E_QUEUE_CTRL_ENABLE);
-
- queue_id = find_next_bit(&tempmap, I40E_MAX_VSI_QP,
- queue_id + 1);
}
/* Poll the status register to make sure that the
@@ -1389,29 +1369,23 @@ static int i40e_vc_enable_queues_msg(struct i40e_vf *vf, u8 *msg, u16 msglen)
udelay(10);
tempmap = vqs->rx_queues;
- queue_id = find_first_bit(&tempmap, I40E_MAX_VSI_QP);
- while (queue_id < I40E_MAX_VSI_QP) {
+ for_each_set_bit(queue_id, &tempmap, I40E_MAX_VSI_QP) {
if (i40e_ctrl_vsi_rx_queue(vf, vsi_id, queue_id,
I40E_QUEUE_CTRL_ENABLECHECK)) {
dev_err(&pf->pdev->dev,
"Queue control check failed on RX queue %d of VSI %d VF %d\n",
queue_id, vsi_id, vf->vf_id);
}
- queue_id = find_next_bit(&tempmap, I40E_MAX_VSI_QP,
- queue_id + 1);
}
tempmap = vqs->tx_queues;
- queue_id = find_first_bit(&tempmap, I40E_MAX_VSI_QP);
- while (queue_id < I40E_MAX_VSI_QP) {
+ for_each_set_bit(queue_id, &tempmap, I40E_MAX_VSI_QP) {
if (i40e_ctrl_vsi_tx_queue(vf, vsi_id, queue_id,
I40E_QUEUE_CTRL_ENABLECHECK)) {
dev_err(&pf->pdev->dev,
"Queue control check failed on TX queue %d of VSI %d VF %d\n",
queue_id, vsi_id, vf->vf_id);
}
- queue_id = find_next_bit(&tempmap, I40E_MAX_VSI_QP,
- queue_id + 1);
}
error_param:
@@ -1455,31 +1429,23 @@ static int i40e_vc_disable_queues_msg(struct i40e_vf *vf, u8 *msg, u16 msglen)
}
tempmap = vqs->rx_queues;
- queue_id = find_first_bit(&tempmap, I40E_MAX_VSI_QP);
- while (queue_id < I40E_MAX_VSI_QP) {
+ for_each_set_bit(queue_id, &tempmap, I40E_MAX_VSI_QP) {
if (!i40e_vc_isvalid_queue_id(vf, vsi_id, queue_id)) {
aq_ret = I40E_ERR_PARAM;
goto error_param;
}
i40e_ctrl_vsi_rx_queue(vf, vsi_id, queue_id,
I40E_QUEUE_CTRL_DISABLE);
-
- queue_id = find_next_bit(&tempmap, I40E_MAX_VSI_QP,
- queue_id + 1);
}
tempmap = vqs->tx_queues;
- queue_id = find_first_bit(&tempmap, I40E_MAX_VSI_QP);
- while (queue_id < I40E_MAX_VSI_QP) {
+ for_each_set_bit(queue_id, &tempmap, I40E_MAX_VSI_QP) {
if (!i40e_vc_isvalid_queue_id(vf, vsi_id, queue_id)) {
aq_ret = I40E_ERR_PARAM;
goto error_param;
}
i40e_ctrl_vsi_tx_queue(vf, vsi_id, queue_id,
I40E_QUEUE_CTRL_DISABLE);
-
- queue_id = find_next_bit(&tempmap, I40E_MAX_VSI_QP,
- queue_id + 1);
}
/* Poll the status register to make sure that the
@@ -1488,29 +1454,23 @@ static int i40e_vc_disable_queues_msg(struct i40e_vf *vf, u8 *msg, u16 msglen)
udelay(10);
tempmap = vqs->rx_queues;
- queue_id = find_first_bit(&tempmap, I40E_MAX_VSI_QP);
- while (queue_id < I40E_MAX_VSI_QP) {
+ for_each_set_bit(queue_id, &tempmap, I40E_MAX_VSI_QP) {
if (i40e_ctrl_vsi_rx_queue(vf, vsi_id, queue_id,
I40E_QUEUE_CTRL_DISABLECHECK)) {
dev_err(&pf->pdev->dev,
"Queue control check failed on RX queue %d of VSI %d VF %d\n",
queue_id, vsi_id, vf->vf_id);
}
- queue_id = find_next_bit(&tempmap, I40E_MAX_VSI_QP,
- queue_id + 1);
}
tempmap = vqs->tx_queues;
- queue_id = find_first_bit(&tempmap, I40E_MAX_VSI_QP);
- while (queue_id < I40E_MAX_VSI_QP) {
+ for_each_set_bit(queue_id, &tempmap, I40E_MAX_VSI_QP) {
if (i40e_ctrl_vsi_tx_queue(vf, vsi_id, queue_id,
I40E_QUEUE_CTRL_DISABLECHECK)) {
dev_err(&pf->pdev->dev,
"Queue control check failed on TX queue %d of VSI %d VF %d\n",
queue_id, vsi_id, vf->vf_id);
}
- queue_id = find_next_bit(&tempmap, I40E_MAX_VSI_QP,
- queue_id + 1);
}
error_param:
^ permalink raw reply related
* [PATCH] i40e: remove unused including <linux/version.h>
From: Wei Yongjun @ 2013-09-23 3:39 UTC (permalink / raw)
To: jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan,
carolyn.wyborny, donald.c.skidmore, gregory.v.rose,
peter.p.waskiewicz.jr, alexander.h.duyck, john.ronciak,
tushar.n.dave, shannon.nelson
Cc: yongjun_wei, e1000-devel, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Remove including <linux/version.h> that don't need it.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/ethernet/intel/i40e/i40e.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h
index b5252eb..3f232ab 100644
--- a/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -46,7 +46,6 @@
#include <linux/sctp.h>
#include <linux/pkt_sched.h>
#include <linux/ipv6.h>
-#include <linux/version.h>
#include <net/checksum.h>
#include <net/ip6_checksum.h>
#include <linux/ethtool.h>
^ permalink raw reply related
* [PATCH] i40e: fix error return code in i40e_probe()
From: Wei Yongjun @ 2013-09-23 2:47 UTC (permalink / raw)
To: jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan,
carolyn.wyborny, donald.c.skidmore, gregory.v.rose,
peter.p.waskiewicz.jr, alexander.h.duyck, john.ronciak,
tushar.n.dave, shannon.nelson
Cc: yongjun_wei, e1000-devel, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Fix to return -ENOMEM in the memory alloc error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 601d482..117e014 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -7060,8 +7060,10 @@ static int i40e_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
*/
len = sizeof(struct i40e_vsi *) * pf->hw.func_caps.num_vsis;
pf->vsi = kzalloc(len, GFP_KERNEL);
- if (!pf->vsi)
+ if (!pf->vsi) {
+ err = -ENOMEM;
goto err_switch_setup;
+ }
err = i40e_setup_pf_switch(pf);
if (err) {
^ permalink raw reply related
* Re: [PATCH 01/12] ping.h: Remove extern from function prototypes
From: Joe Perches @ 2013-09-23 2:43 UTC (permalink / raw)
To: Ryan Mallon; +Cc: netdev, David S. Miller, linux-kernel
In-Reply-To: <523FA98E.4080908@gmail.com>
On Mon, 2013-09-23 at 12:38 +1000, Ryan Mallon wrote:
> A checkpatch rule might help,
Extant.
^ permalink raw reply
* Re: [PATCH 01/12] ping.h: Remove extern from function prototypes
From: Ryan Mallon @ 2013-09-23 2:38 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev, David S. Miller, linux-kernel
In-Reply-To: <1379902599.3575.9.camel@joe-AO722>
On 23/09/13 12:16, Joe Perches wrote:
> On Mon, 2013-09-23 at 11:59 +1000, Ryan Mallon wrote:
>> This seems like a lot of code churn for very little benefit. At a quick
>> glance:
>>
>> git grep extern include/ | wc -l
>> 11427
>>
>> Not all of those will need to be removed, but that is still a huge
>> number to change, and doesn't include extern usage in C files or local
>> headers. You are probably never going to remove all the instances, so
>> what is the point of just randomly doing a handful?
>
> Rather more than a handful.
>
> The ratio of function prototypes without extern to
> function prototypes with extern is currently ~2.5:1
>
> So:
>
> Standardization without extern
> Line count reduction (~10%)
> Miscellaneous neatening at the same time
> Removal of all unnecessary externs from include/net
>
> There are ~8500 instances in include/
> There are ~1500 instances in include/net/
>
> After this series, 0 in include/net/
>
> Start somewhere, go from there...
>
> $ git grep -E "^\s*\bextern(\s+\w+){1,4}\s*\(\s*[^\*]" include/ | wc -l
> 8395
> $ git grep -E "^\s*\bextern(\s+\w+){1,4}\s*\(\s*[^\*]" include/net/ | wc -l
> 1471
Right, and:
$ git grep -E "^\s*\bextern(\s+\w+){1,4}\s*\(\s*[^\*]" | wc -l
29104
Since there are lots of local/arch headers, and there are uses of extern
function prototypes in C files.
I don't see the real benefit though. Its like trying to "clean-up" the
difference between "unsigned x" and "unsigned int x", or any number of
other minor style differences. Either version, with or without the
extern, is correct, valid C code. Plus you will get people adding new
instances of extern because they don't know any better. A checkpatch
rule might help, but we all know how often people run that...
~Ryan
^ permalink raw reply
* Re: [net-next] hp100: replace hardcoded name in /proc/interrupts with interface name
From: Matthew Whitehead @ 2013-09-23 2:26 UTC (permalink / raw)
To: Mihir Singh; +Cc: netdev
In-Reply-To: <1379789289-10961-1-git-send-email-me@mihirsingh.com>
On Sat, Sep 21, 2013 at 06:48:09PM +0000, Mihir Singh wrote:
> The /proc/interrupts file displays hp100, which is not the accepted style. Printing eth%d is more helpful.
>
> Signed-off-by: Mihir Singh <me@mihirsingh.com>
> ---
> drivers/net/ethernet/hp/hp100.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/hp/hp100.c b/drivers/net/ethernet/hp/hp100.c
> index 91227d0..3786009 100644
> --- a/drivers/net/ethernet/hp/hp100.c
> +++ b/drivers/net/ethernet/hp/hp100.c
> @@ -1098,7 +1098,7 @@ static int hp100_open(struct net_device *dev)
> if (request_irq(dev->irq, hp100_interrupt,
> lp->bus == HP100_BUS_PCI || lp->bus ==
> HP100_BUS_EISA ? IRQF_SHARED : 0,
> - "hp100", dev)) {
> + dev->name, dev)) {
> printk("hp100: %s: unable to get IRQ %d\n", dev->name, dev->irq);
> return -EAGAIN;
> }
> --
> 1.8.1.2
>
> --
> 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
Reviewed-By: Matthew Whitehead <tedheadster@gmail.com>
^ permalink raw reply
* Re: [net-next] Fix hardcoded interrupt name lp->name to use system device value
From: Matthew Whitehead @ 2013-09-23 2:25 UTC (permalink / raw)
To: Nate Levesque; +Cc: netdev
In-Reply-To: <1379789381-3992-1-git-send-email-thenaterhood@gmail.com>
On Sat, Sep 21, 2013 at 06:49:41PM +0000, Nate Levesque wrote:
> The lance interrupt handler was using the hard-coded name which would make it difficult to tell where the interrupt came from. Changed to use the device name that made the interrupt.
>
> Signed-off-by: Nate Levesque <thenaterhood@gmail.com>
> ---
> drivers/net/ethernet/amd/lance.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/amd/lance.c b/drivers/net/ethernet/amd/lance.c
> index 5c72843..256f590 100644
> --- a/drivers/net/ethernet/amd/lance.c
> +++ b/drivers/net/ethernet/amd/lance.c
> @@ -754,7 +754,7 @@ lance_open(struct net_device *dev)
> int i;
>
> if (dev->irq == 0 ||
> - request_irq(dev->irq, lance_interrupt, 0, lp->name, dev)) {
> + request_irq(dev->irq, lance_interrupt, 0, dev->name, dev)) {
> return -EAGAIN;
> }
>
> --
> 1.8.1.2
>
> --
> 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
Reviewed-by: Matthew Whitehead <tedheadster@gmail.com>
^ permalink raw reply
* Re: [PATCH 01/12] ping.h: Remove extern from function prototypes
From: Joe Perches @ 2013-09-23 2:16 UTC (permalink / raw)
To: Ryan Mallon; +Cc: netdev, David S. Miller, linux-kernel
In-Reply-To: <523FA098.9050200@gmail.com>
On Mon, 2013-09-23 at 11:59 +1000, Ryan Mallon wrote:
> This seems like a lot of code churn for very little benefit. At a quick
> glance:
>
> git grep extern include/ | wc -l
> 11427
>
> Not all of those will need to be removed, but that is still a huge
> number to change, and doesn't include extern usage in C files or local
> headers. You are probably never going to remove all the instances, so
> what is the point of just randomly doing a handful?
Rather more than a handful.
The ratio of function prototypes without extern to
function prototypes with extern is currently ~2.5:1
So:
Standardization without extern
Line count reduction (~10%)
Miscellaneous neatening at the same time
Removal of all unnecessary externs from include/net
There are ~8500 instances in include/
There are ~1500 instances in include/net/
After this series, 0 in include/net/
Start somewhere, go from there...
$ git grep -E "^\s*\bextern(\s+\w+){1,4}\s*\(\s*[^\*]" include/ | wc -l
8395
$ git grep -E "^\s*\bextern(\s+\w+){1,4}\s*\(\s*[^\*]" include/net/ | wc -l
1471
^ permalink raw reply
* Re: [PATCH 01/12] ping.h: Remove extern from function prototypes
From: Ryan Mallon @ 2013-09-23 1:59 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev, David S. Miller, linux-kernel
In-Reply-To: <b692aba58032f629907ea2d462c99b87906645ca.1379870986.git.joe@perches.com>
On 23/09/13 03:32, Joe Perches wrote:
> There are a mix of function prototypes with and without extern
> in the kernel sources. Standardize on not using extern for
> function prototypes.
>
> Function prototypes don't need to be written with extern.
> extern is assumed by the compiler. Its use is as unnecessary as
> using auto to declare automatic/local variables in a block.
>
> Signed-off-by: Joe Perches <joe@perches.com>
This seems like a lot of code churn for very little benefit. At a quick
glance:
git grep extern include/ | wc -l
11427
Not all of those will need to be removed, but that is still a huge
number to change, and doesn't include extern usage in C files or local
headers. You are probably never going to remove all the instances, so
what is the point of just randomly doing a handful?
~Ryan
> ---
> include/net/ping.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/net/ping.h b/include/net/ping.h
> index 5db0224..3f67704 100644
> --- a/include/net/ping.h
> +++ b/include/net/ping.h
> @@ -103,8 +103,8 @@ void ping_seq_stop(struct seq_file *seq, void *v);
> int ping_proc_register(struct net *net, struct ping_seq_afinfo *afinfo);
> void ping_proc_unregister(struct net *net, struct ping_seq_afinfo *afinfo);
>
> -extern int __init ping_proc_init(void);
> -extern void ping_proc_exit(void);
> +int __init ping_proc_init(void);
> +void ping_proc_exit(void);
> #endif
>
> void __init ping_init(void);
>
^ permalink raw reply
* Hallo
From: Wonga Business Loan @ 2013-09-23 0:32 UTC (permalink / raw)
goedendag
Ik ben mevrouw Juliet kjell van Wonga Business Loan we zijn lening kredietverstrekkers en vastgoed, willen we degenen die financiële hulp nodig hebben te bereiken. Wij bieden zakelijke leningen, persoonlijke leningen, autoleningen, leningen, opleiding en medische leningen,
Wij bieden leningen aan bedrijven (klein of groot) Ook bieden wij leningen @ 3%-tarief. Onze missie is om de behoeftigen te helpen. Als belanghebbende aanvragers moeten de volgende gegevens in te dienen:
Naam van de aanvrager:
land:
Geslacht:
Bedrag dat nodig is:
doel:
duur:
Postcode:
telefoon:
Voldoen aan uw financiële behoeften is onze trots.
E-mail ons: wbl.org@manager.in.th
Lening goedkeuring manager
Mevrouw Julia kjell
^ permalink raw reply
* Re: [PATCH] ipv6: udp packets following an UFO enqueued packet need also be handled by UFO
From: Hannes Frederic Sowa @ 2013-09-23 0:43 UTC (permalink / raw)
To: netdev, yoshfuji, davem, dvyukov; +Cc: pjt, andreyknvl, kcc, therbert
In-Reply-To: <20130921042700.GB8070@order.stressinduktion.org>
On Sat, Sep 21, 2013 at 06:27:00AM +0200, Hannes Frederic Sowa wrote:
> In the following scenario the socket is corked:
> If the first UDP packet is larger then the mtu we try to append it to the
> write queue via ip6_ufo_append_data. A following packet, which is smaller
> than the mtu would be appended to the already queued up gso-skb via
> plain ip6_append_data. This causes random memory corruptions.
>
> In ip6_ufo_append_data we also have to be careful to not queue up the
> same skb multiple times. So setup the gso frame only when no first skb
> is available.
>
> This also fixes a shortcoming where we add the current packet's length to
> cork->length but return early because of a packet > mtu with dontfrag set
> (instead of sutracting it again).
>
> Found with trinity.
>
> Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Further analysis showed it is very probable that this fixes the bug Dmitry
reported. So I want to give proper credits:
Reported-by: Dmitry Vyukov <dvyukov@google.com>
^ permalink raw reply
* Re: [PATCH net-next] xen-netfront: convert to GRO API and advertise this feature
From: Anirban Chakraborty @ 2013-09-22 23:09 UTC (permalink / raw)
To: Eric Dumazet
Cc: Wei Liu, <netdev@vger.kernel.org>,
<xen-devel@lists.xen.org>, Ian Campbell
In-Reply-To: <1379861723.3431.10.camel@edumazet-glaptop>
On Sep 22, 2013, at 7:55 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sat, 2013-09-21 at 17:05 +0100, Wei Liu wrote:
>> Anirban was seeing netfront received MTU size packets, which downgraded
>> throughput. The following patch makes netfront use GRO API which
>> improves throughput for that case.
>
>> - netdev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO;
>> + netdev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO |
>> + NETIF_F_GRO;
>
>
> This part is not needed.
Shouldn't the flag be set? In dev_gro_receive() we do check if this flag is set or not:
if (!(skb->dev->features & NETIF_F_GRO) || netpoll_rx_on(skb))
goto normal;
-Anirban
^ permalink raw reply
* Re: [Xen-devel] [PATCH net-next] xen-netfront: convert to GRO API and advertise this feature
From: Anirban Chakraborty @ 2013-09-22 23:04 UTC (permalink / raw)
To: Wei Liu
Cc: Jason Wang, <netdev@vger.kernel.org>, Ian Campbell,
<xen-devel@lists.xen.org>
In-Reply-To: <20130922120936.GA4079@zion.uk.xensource.com>
On Sep 22, 2013, at 5:09 AM, Wei Liu <wei.liu2@citrix.com> wrote:
> On Sun, Sep 22, 2013 at 02:29:15PM +0800, Jason Wang wrote:
>> On 09/22/2013 12:05 AM, Wei Liu wrote:
>>> Anirban was seeing netfront received MTU size packets, which downgraded
>>> throughput. The following patch makes netfront use GRO API which
>>> improves throughput for that case.
>>>
>>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>>> Signed-off-by: Anirban Chakraborty <abchak@juniper.net>
>>> Cc: Ian Campbell <ian.campbell@citrix.com>
>>
>> Maybe a dumb question: doesn't Xen depends on the driver of host card to
>> do GRO and pass it to netfront? What the case that netfront can receive
>
> The would be the ideal situation. Netback pushes large packets to
> netfront and netfront sees large packets.
>
>> a MTU size packet, for a card that does not support GRO in host? Doing
>
> However Anirban saw the case when backend interface receives large
> packets but netfront sees MTU size packets, so my thought is there is
> certain configuration that leads to this issue. As we cannot tell
> users what to enable and what not to enable so I would like to solve
> this within our driver.
>
>> GRO twice may introduce extra overheads.
>>
>
> AIUI if the packet that frontend sees is large already then the GRO path
> is quite short which will not introduce heavy penalty, while on the
> other hand if packet is segmented doing GRO improves throughput.
>
Thanks Wei, for explaining and submitting the patch. I would like add following to what you have already mentioned.
In my configuration, I was seeing netback was pushing large packets to the guest (Centos 6.4) but the netfront was receiving MTU sized packets. With this patch on, I do see large packets received on the guest interface. As a result there was substantial throughput improvement in the guest side (2.8 Gbps to 3.8 Gbps). Also, note that the host NIC driver was enabled for GRO already.
-Anirban
^ permalink raw reply
* Re: [PATCH 2/5] Bluetooth: Fix assignment of 0/1 to bool variables
From: Gustavo Padovan @ 2013-09-22 22:21 UTC (permalink / raw)
To: Peter Senna Tschudin
Cc: marcel-kz+m5ild9QBg9hUCZPvPmw,
johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1379875453-20083-2-git-send-email-peter.senna-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Peter,
2013-09-22 Peter Senna Tschudin <peter.senna-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> Convert 0 to false and 1 to true when assigning values to bool
> variables. Inspired by commit 3db1cd5c05f35fb43eb134df6f321de4e63141f2.
>
> The simplified semantic patch that find this problem is as
> follows (http://coccinelle.lip6.fr/):
>
> @@
> bool b;
> @@
> (
> -b = 0
> +b = false
> |
> -b = 1
> +b = true
> )
>
> Signed-off-by: Peter Senna Tschudin <peter.senna-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> ---
> net/bluetooth/l2cap_core.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
Patch has been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: Bug - regression - Via velocity interface coming up freezes kernel
From: Francois Romieu @ 2013-09-22 22:11 UTC (permalink / raw)
To: Dirk Kraft; +Cc: netdev, Julia Lawall
In-Reply-To: <CAFES+i+OYq_dDtEqAqkW7qYDrtdzkqc9hBGBDODQuqgvFJE7zg@mail.gmail.com>
Dirk Kraft <dirk.kraft@gmail.com> :
[...]
> I observe problems with my machine freezing when bringing up the
> network interface (via velocity based). Detailed report below.
>
> First message was rejected because of html. Julia Lawall, sorry about
> sending multiple copies.
>
> [1.] One line summary of the problem:
> Via_velocity interface coming up freezes kernel - WARNING: CPU: 0 PID:
> 1529 at /build/buildd/linux-3.11.0/kernel/softirq.c:159
> local_bh_enable+0x60/0x90()
netif_receive_skb with irq disabled ?
You can try this one as a wild guess before I have more time to analyze.
diff --git a/drivers/net/ethernet/via/via-velocity.c b/drivers/net/ethernet/via/via-velocity.c
index d022bf9..64c42be 100644
--- a/drivers/net/ethernet/via/via-velocity.c
+++ b/drivers/net/ethernet/via/via-velocity.c
@@ -2172,16 +2172,13 @@ static int velocity_poll(struct napi_struct *napi, int budget)
unsigned int rx_done;
unsigned long flags;
- spin_lock_irqsave(&vptr->lock, flags);
/*
* Do rx and tx twice for performance (taken from the VIA
* out-of-tree driver).
*/
- rx_done = velocity_rx_srv(vptr, budget / 2);
- velocity_tx_srv(vptr);
- rx_done += velocity_rx_srv(vptr, budget - rx_done);
+ rx_done = velocity_rx_srv(vptr, budget);
+ spin_lock_irqsave(&vptr->lock, flags);
velocity_tx_srv(vptr);
-
/* If budget not fully consumed, exit the polling mode */
if (rx_done < budget) {
napi_complete(napi);
^ permalink raw reply related
* Re: [PATCH V2] wireless: rtlwifi: Replace variable with a brake
From: Peter Senna Tschudin @ 2013-09-22 20:24 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Larry.Finger, chaoming_li, Joe Perches, John Linville,
linux-wireless, netdev, linux-kernel, kernel-janitors
In-Reply-To: <523F4B76.80507@cogentembedded.com>
On Sun, Sep 22, 2013 at 9:56 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Hello.
>
> On 09/22/2013 11:50 PM, Peter Senna Tschudin wrote:
>
> You have a typo in the subject -- "brake" is a device to stop a vehicle.
> :-)
Thanks, there was other similar typo after ---
>
>
>> This patch removes the variable continual, and change the while loop
>> to break when efuse_data == 0xFF.
>
>
>> Tested by compilation only.
>
>
>> CC: Joe Perches <joe@perches.com>
>> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
>> ---
>> Changes from V1:
>> - Fix the indetation
>> - Remove remaining } from removed else
>
>
>> Please ignore the patch:
>> [PATCH 12/19] wireless: Change variable type to bool
>
>
>> And apply this one instead.
>
>
>> The variable continual was declared as int, but was used as bool. I
>> sent previous patch changing the variable type to bool, but Joe Perches
>> proposed that removing the variable and adding a brake would be better.
>
>
>> drivers/net/wireless/rtlwifi/efuse.c | 18 ++++++++----------
>> 1 file changed, 8 insertions(+), 10 deletions(-)
>
>
>> diff --git a/drivers/net/wireless/rtlwifi/efuse.c
>> b/drivers/net/wireless/rtlwifi/efuse.c
>> index 838a1ed..2aedd9f 100644
>> --- a/drivers/net/wireless/rtlwifi/efuse.c
>> +++ b/drivers/net/wireless/rtlwifi/efuse.c
>> @@ -1203,20 +1203,18 @@ static void efuse_power_switch(struct ieee80211_hw
>> *hw, u8 write, u8 pwrstate)
>>
>> static u16 efuse_get_current_size(struct ieee80211_hw *hw)
>> {
>> - int continual = true;
>> u16 efuse_addr = 0;
>> u8 hworden;
>> u8 efuse_data, word_cnts;
>>
>> - while (continual && efuse_one_byte_read(hw, efuse_addr,
>> &efuse_data)
>> - && (efuse_addr < EFUSE_MAX_SIZE)) {
>> - if (efuse_data != 0xFF) {
>> - hworden = efuse_data & 0x0F;
>> - word_cnts = efuse_calculate_word_cnts(hworden);
>> - efuse_addr = efuse_addr + (word_cnts * 2) + 1;
>> - } else {
>> - continual = false;
>> - }
>> + while (efuse_one_byte_read(hw, efuse_addr, &efuse_data) &&
>> + (efuse_addr < EFUSE_MAX_SIZE)) {
>
>
> Start this line under efuse_one_byte_read, please. Also, parens are not
> needed.
Fixed on V3.
Thanks!
>
> WBR, Sergei
>
--
Peter
^ permalink raw reply
* [PATCH V3] wireless: rtlwifi: Replace variable with a break
From: Peter Senna Tschudin @ 2013-09-22 20:22 UTC (permalink / raw)
To: Larry.Finger
Cc: joe, sergei.shtylyov, chaoming_li, linville, linux-wireless,
netdev, linux-kernel, kernel-janitors, Peter Senna Tschudin
This patch removes the variable continual, and change the while loop
to break when efuse_data == 0xFF.
Tested by compilation only.
CC: Joe Perches <joe@perches.com>
Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
---
Changes from V2:
- Fix typo in the subject
- Fix indentation
Changes from V1:
- Fix the indetation
- Remove remaining } from removed else
Please ignore the patch:
[PATCH 12/19] wireless: Change variable type to bool
And apply this one instead.
The variable continual was declared as int, but was used as bool. I
sent previous patch changing the variable type to bool, but Joe Perches
proposed that removing the variable and adding a break would be better.
drivers/net/wireless/rtlwifi/efuse.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/efuse.c b/drivers/net/wireless/rtlwifi/efuse.c
index 838a1ed..ae13fb9 100644
--- a/drivers/net/wireless/rtlwifi/efuse.c
+++ b/drivers/net/wireless/rtlwifi/efuse.c
@@ -1203,20 +1203,18 @@ static void efuse_power_switch(struct ieee80211_hw *hw, u8 write, u8 pwrstate)
static u16 efuse_get_current_size(struct ieee80211_hw *hw)
{
- int continual = true;
u16 efuse_addr = 0;
u8 hworden;
u8 efuse_data, word_cnts;
- while (continual && efuse_one_byte_read(hw, efuse_addr, &efuse_data)
- && (efuse_addr < EFUSE_MAX_SIZE)) {
- if (efuse_data != 0xFF) {
- hworden = efuse_data & 0x0F;
- word_cnts = efuse_calculate_word_cnts(hworden);
- efuse_addr = efuse_addr + (word_cnts * 2) + 1;
- } else {
- continual = false;
- }
+ while (efuse_one_byte_read(hw, efuse_addr, &efuse_data) &&
+ efuse_addr < EFUSE_MAX_SIZE) {
+ if (efuse_data == 0xFF)
+ break;
+
+ hworden = efuse_data & 0x0F;
+ word_cnts = efuse_calculate_word_cnts(hworden);
+ efuse_addr = efuse_addr + (word_cnts * 2) + 1;
}
return efuse_addr;
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2] declance: Remove `incompatible pointer type' warnings
From: Maciej W. Rozycki @ 2013-09-22 20:19 UTC (permalink / raw)
To: David Miller; +Cc: Sergei Shtylyov, netdev
In-Reply-To: <20130920.144304.2081229489870626586.davem@davemloft.net>
Revert damage caused by 43d620c82985b19008d87a437b4cf83f356264f7
[drivers/net: Remove casts of void *]:
.../declance.c: In function 'cp_to_buf':
.../declance.c:347: warning: assignment from incompatible pointer type
.../declance.c:348: warning: assignment from incompatible pointer type
.../declance.c: In function 'cp_from_buf':
.../declance.c:406: warning: assignment from incompatible pointer type
.../declance.c:407: warning: assignment from incompatible pointer type
Also add a `const' qualifier where applicable and adjust formatting.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
---
> Applied to net-next
Thanks, by Sergei's request please use this version instead that has the
reference to the original commit updated (no change to the patch itself).
Maciej
linux-declance-cast-fix.patch
Index: linux-mips-3.12.0-rc1-20130917-4maxp/drivers/net/ethernet/amd/declance.c
===================================================================
--- linux-mips-3.12.0-rc1-20130917-4maxp.orig/drivers/net/ethernet/amd/declance.c
+++ linux-mips-3.12.0-rc1-20130917-4maxp/drivers/net/ethernet/amd/declance.c
@@ -344,8 +344,8 @@ static void cp_to_buf(const int type, vo
}
clen = len & 1;
- rtp = tp;
- rfp = fp;
+ rtp = (unsigned char *)tp;
+ rfp = (const unsigned char *)fp;
while (clen--) {
*rtp++ = *rfp++;
}
@@ -372,8 +372,8 @@ static void cp_to_buf(const int type, vo
* do the rest, if any.
*/
clen = len & 15;
- rtp = (unsigned char *) tp;
- rfp = (unsigned char *) fp;
+ rtp = (unsigned char *)tp;
+ rfp = (const unsigned char *)fp;
while (clen--) {
*rtp++ = *rfp++;
}
@@ -403,8 +403,8 @@ static void cp_from_buf(const int type,
clen = len & 1;
- rtp = tp;
- rfp = fp;
+ rtp = (unsigned char *)tp;
+ rfp = (const unsigned char *)fp;
while (clen--) {
*rtp++ = *rfp++;
@@ -433,8 +433,8 @@ static void cp_from_buf(const int type,
* do the rest, if any.
*/
clen = len & 15;
- rtp = (unsigned char *) tp;
- rfp = (unsigned char *) fp;
+ rtp = (unsigned char *)tp;
+ rfp = (const unsigned char *)fp;
while (clen--) {
*rtp++ = *rfp++;
}
^ permalink raw reply
* Re: [PATCH V2] wireless: rtlwifi: Replace variable with a brake
From: Sergei Shtylyov @ 2013-09-22 19:56 UTC (permalink / raw)
To: Peter Senna Tschudin
Cc: Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ,
chaoming_li-kXabqFNEczNtrwSWzY7KCg, joe-6d6DIl74uiNBDgjK7y7TUQ,
linville-2XuSBdqkA4R54TAoqtyWWQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1379879410-22787-1-git-send-email-peter.senna-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hello.
On 09/22/2013 11:50 PM, Peter Senna Tschudin wrote:
You have a typo in the subject -- "brake" is a device to stop a vehicle. :-)
> This patch removes the variable continual, and change the while loop
> to break when efuse_data == 0xFF.
> Tested by compilation only.
> CC: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Peter Senna Tschudin <peter.senna-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> Changes from V1:
> - Fix the indetation
> - Remove remaining } from removed else
> Please ignore the patch:
> [PATCH 12/19] wireless: Change variable type to bool
> And apply this one instead.
> The variable continual was declared as int, but was used as bool. I
> sent previous patch changing the variable type to bool, but Joe Perches
> proposed that removing the variable and adding a brake would be better.
> drivers/net/wireless/rtlwifi/efuse.c | 18 ++++++++----------
> 1 file changed, 8 insertions(+), 10 deletions(-)
> diff --git a/drivers/net/wireless/rtlwifi/efuse.c b/drivers/net/wireless/rtlwifi/efuse.c
> index 838a1ed..2aedd9f 100644
> --- a/drivers/net/wireless/rtlwifi/efuse.c
> +++ b/drivers/net/wireless/rtlwifi/efuse.c
> @@ -1203,20 +1203,18 @@ static void efuse_power_switch(struct ieee80211_hw *hw, u8 write, u8 pwrstate)
>
> static u16 efuse_get_current_size(struct ieee80211_hw *hw)
> {
> - int continual = true;
> u16 efuse_addr = 0;
> u8 hworden;
> u8 efuse_data, word_cnts;
>
> - while (continual && efuse_one_byte_read(hw, efuse_addr, &efuse_data)
> - && (efuse_addr < EFUSE_MAX_SIZE)) {
> - if (efuse_data != 0xFF) {
> - hworden = efuse_data & 0x0F;
> - word_cnts = efuse_calculate_word_cnts(hworden);
> - efuse_addr = efuse_addr + (word_cnts * 2) + 1;
> - } else {
> - continual = false;
> - }
> + while (efuse_one_byte_read(hw, efuse_addr, &efuse_data) &&
> + (efuse_addr < EFUSE_MAX_SIZE)) {
Start this line under efuse_one_byte_read, please. Also, parens are not
needed.
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* [PATCH V2] wireless: rtlwifi: Replace variable with a brake
From: Peter Senna Tschudin @ 2013-09-22 19:50 UTC (permalink / raw)
To: Larry.Finger
Cc: chaoming_li, joe, linville, linux-wireless, netdev, linux-kernel,
kernel-janitors, Peter Senna Tschudin
This patch removes the variable continual, and change the while loop
to break when efuse_data == 0xFF.
Tested by compilation only.
CC: Joe Perches <joe@perches.com>
Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
---
Changes from V1:
- Fix the indetation
- Remove remaining } from removed else
Please ignore the patch:
[PATCH 12/19] wireless: Change variable type to bool
And apply this one instead.
The variable continual was declared as int, but was used as bool. I
sent previous patch changing the variable type to bool, but Joe Perches
proposed that removing the variable and adding a brake would be better.
drivers/net/wireless/rtlwifi/efuse.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/efuse.c b/drivers/net/wireless/rtlwifi/efuse.c
index 838a1ed..2aedd9f 100644
--- a/drivers/net/wireless/rtlwifi/efuse.c
+++ b/drivers/net/wireless/rtlwifi/efuse.c
@@ -1203,20 +1203,18 @@ static void efuse_power_switch(struct ieee80211_hw *hw, u8 write, u8 pwrstate)
static u16 efuse_get_current_size(struct ieee80211_hw *hw)
{
- int continual = true;
u16 efuse_addr = 0;
u8 hworden;
u8 efuse_data, word_cnts;
- while (continual && efuse_one_byte_read(hw, efuse_addr, &efuse_data)
- && (efuse_addr < EFUSE_MAX_SIZE)) {
- if (efuse_data != 0xFF) {
- hworden = efuse_data & 0x0F;
- word_cnts = efuse_calculate_word_cnts(hworden);
- efuse_addr = efuse_addr + (word_cnts * 2) + 1;
- } else {
- continual = false;
- }
+ while (efuse_one_byte_read(hw, efuse_addr, &efuse_data) &&
+ (efuse_addr < EFUSE_MAX_SIZE)) {
+ if (efuse_data == 0xFF)
+ break;
+
+ hworden = efuse_data & 0x0F;
+ word_cnts = efuse_calculate_word_cnts(hworden);
+ efuse_addr = efuse_addr + (word_cnts * 2) + 1;
}
return efuse_addr;
--
1.8.3.1
^ permalink raw reply related
* [PATCH] wireless: rtlwifi: Replace variable with a brake
From: Peter Senna Tschudin @ 2013-09-22 19:24 UTC (permalink / raw)
To: Larry.Finger
Cc: chaoming_li, joe, linville, linux-wireless, netdev, linux-kernel,
kernel-janitors, Peter Senna Tschudin
This patch removes the variable continual, and change the while loop
to break when efuse_data == 0xFF.
CC: Joe Perches <joe@perches.com>
Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
---
Please ignore the patch:
[PATCH 12/19] wireless: Change variable type to bool
And apply this one instead.
The variable continual was declared as int, but was used as bool. I
sent previous patch changing the variable type to bool, but Joe Perches
proposed that removing the variable and adding a brake would be better.
drivers/net/wireless/rtlwifi/efuse.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/efuse.c b/drivers/net/wireless/rtlwifi/efuse.c
index 838a1ed..d1328fc 100644
--- a/drivers/net/wireless/rtlwifi/efuse.c
+++ b/drivers/net/wireless/rtlwifi/efuse.c
@@ -1203,19 +1203,18 @@ static void efuse_power_switch(struct ieee80211_hw *hw, u8 write, u8 pwrstate)
static u16 efuse_get_current_size(struct ieee80211_hw *hw)
{
- int continual = true;
u16 efuse_addr = 0;
u8 hworden;
u8 efuse_data, word_cnts;
- while (continual && efuse_one_byte_read(hw, efuse_addr, &efuse_data)
- && (efuse_addr < EFUSE_MAX_SIZE)) {
- if (efuse_data != 0xFF) {
+ while (efuse_one_byte_read(hw, efuse_addr, &efuse_data) &&
+ (efuse_addr < EFUSE_MAX_SIZE)) {
+ if (efuse_data == 0xFF)
+ break;
+
hworden = efuse_data & 0x0F;
word_cnts = efuse_calculate_word_cnts(hworden);
efuse_addr = efuse_addr + (word_cnts * 2) + 1;
- } else {
- continual = false;
}
}
--
1.8.3.1
^ permalink raw reply related
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