* Re: [RFC 2/4] tuntap: Publish tuntap maximum number of queues as module_param
From: Jason Wang @ 2014-08-25 2:57 UTC (permalink / raw)
To: Michael S. Tsirkin, Pankaj Gupta
Cc: Jiri Pirko, linux-kernel, netdev, davem, dgibson, vfalico,
edumazet, vyasevic, hkchu, wuzhy, xemul, therbert, bhutchings,
xii, stephen
In-Reply-To: <20140824111421.GC9561@redhat.com>
On 08/24/2014 07:14 PM, Michael S. Tsirkin wrote:
> On Fri, Aug 22, 2014 at 07:52:22AM -0400, Pankaj Gupta wrote:
>>> On 08/20/2014 07:17 PM, Michael S. Tsirkin wrote:
>>>> On Wed, Aug 20, 2014 at 12:58:17PM +0200, Jiri Pirko wrote:
>>>>>> Mon, Aug 18, 2014 at 03:37:18PM CEST, pagupta@redhat.com wrote:
>>>>>>>> This patch publishes maximum number of tun/tap queues allocated as a
>>>>>>>> read_only module parameter which a user space application like
>>>>>>>> libvirt
>>>>>>>> can make use of to limit maximum number of queues. Value of read_only
>>>>>>>> module parameter can be writable only at module load time. If no
>>>>>>>> value is set
>>>>>>>> at module load time a default value 256 is used which is equal to
>>>>>>>> maximum number
>>>>>>>> of vCPUS allowed by KVM.
>>>>>>>>
>>>>>>>> Administrator can specify maximum number of queues only at the driver
>>>>>>>> module load time.
>>>>>>>>
>>>>>>>> Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
>>>>>>>> ---
>>>>>>>> drivers/net/tun.c | 13 +++++++++++--
>>>>>>>> 1 files changed, 11 insertions(+), 2 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>>>>>>>> index acaaf67..1f518e2 100644
>>>>>>>> --- a/drivers/net/tun.c
>>>>>>>> +++ b/drivers/net/tun.c
>>>>>>>> @@ -119,6 +119,9 @@ struct tap_filter {
>>>>>>>>
>>>>>>>> #define TUN_FLOW_EXPIRE (3 * HZ)
>>>>>>>>
>>>>>>>> +static int max_tap_queues = MAX_TAP_QUEUES;
>>>>>>>> +module_param(max_tap_queues, int, S_IRUGO);
>>>>>> Please do not introduce new module paramaters. Please other ways to
>>>>>> interchange values with userspace.
>>>> I suggested this initially, but thinking more about it, I agree.
>>>>
>>>> It's a global limit (necessary to limit memory utilization by
>>>> userspace), but it should be possible to change it
>>>> after module load.
>>> How about pass this limit through ifr during TUNSETIFF, then
>>> alloc_netdev_mq() can use this limit.
>> Any other ideas/comments from the experts. Or shall I re-repost other patches
>> in the series except this patch until we agree on one.
>>
> It's kind of useless without a way for userspace to discover
> how many queues it can create, no?
>
We can implement ethtool_get_channels for tuntap. But I'm still not
clear why this is necessary.
^ permalink raw reply
* RE: [PATCH net-next 4/4] r8152: support firmware files
From: Hayes Wang @ 2014-08-25 3:23 UTC (permalink / raw)
To: Francois Romieu
Cc: netdev@vger.kernel.org, nic_swsd, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org
In-Reply-To: <20140824212055.GA30857@electric-eye.fr.zoreil.com>
Francois Romieu [mailto:romieu@fr.zoreil.com]
[...]
> > +static void rtl_request_firmware(struct r8152 *tp)
> > +{
> > + char *fw_name = NULL;
> > +
> > + if (tp->rtl_fw.fw)
> > + goto out_request;
> > +
> > + switch (tp->version) {
> > + case RTL_VER_01:
> > + fw_name = "rtl_nic/rtl8152-1.fw";
> > + break;
> > + case RTL_VER_02:
> > + fw_name = "rtl_nic/rtl8152-2.fw";
> > + break;
> > + case RTL_VER_03:
> > + fw_name = "rtl_nic/rtl8153-1.fw";
> > + break;
> > + case RTL_VER_04:
> > + fw_name = "rtl_nic/rtl8153-2.fw";
> > + break;
> > + case RTL_VER_05:
> > + fw_name = "rtl_nic/rtl8153-3.fw";
> > + break;
>
> The driver should use MODULE_FIRMWARE() for these files.
Oops. I would fix this. Thanks.
Best Regards,
Hayes
^ permalink raw reply
* RE: [PATCH net-next 0/4] r8152: firmware support
From: Hayes Wang @ 2014-08-25 3:43 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, nic_swsd,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20140822.194111.760144805197214266.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
From: David Miller [mailto:davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org]
[...]
> You haven't told us why you need to do this.
>
> These are just programming registers in the chip, and I see no reason
> to not keep these in the driver with real code.
>
> I'm not applying this series, you haven't explained what is happening
> here and the reason for doing so. Ironically, that's exactly what you
> are supposed to provide in this 0/4 header email.
The nic has the MCU inside which is used to fix the PHY,
MAC, and some behavior of the USB device. Each parts have
different methods of updating the firmware by accessing the
registers. The firmware files are used to deal with the
processes, so I need some functions to parse the firmware
files to update the fimrware code.
I would resend these. Sorry.
Best Regards,
Hayes
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* Re: [PATCH net-next 0/4] r8152: firmware support
From: David Miller @ 2014-08-25 4:26 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB2516177@RTITMBSV03.realtek.com.tw>
From: Hayes Wang <hayeswang@realtek.com>
Date: Mon, 25 Aug 2014 03:43:04 +0000
> From: David Miller [mailto:davem@davemloft.net]
> [...]
>> You haven't told us why you need to do this.
>>
>> These are just programming registers in the chip, and I see no reason
>> to not keep these in the driver with real code.
>>
>> I'm not applying this series, you haven't explained what is happening
>> here and the reason for doing so. Ironically, that's exactly what you
>> are supposed to provide in this 0/4 header email.
>
> The nic has the MCU inside which is used to fix the PHY,
> MAC, and some behavior of the USB device. Each parts have
> different methods of updating the firmware by accessing the
> registers. The firmware files are used to deal with the
> processes, so I need some functions to parse the firmware
> files to update the fimrware code.
That still doesn't convince me.
The functions I see you removing are just programming a set of
registers in some way.
And the firmware that is replacing those functions is just going to be
causing the same register writes, just even more obfuscated than it is
now.
You should keep the C functions which document and show clearly what
is being programmed in each chip.
Don't hide register programming behind firmware files, please.
^ permalink raw reply
* Re: [PATCH net-next v3 08/12] net: dsa: allow updating fixed PHY link information
From: David Miller @ 2014-08-25 4:56 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, davem, jhs, linville, alexander.h.duyck
In-Reply-To: <1408905869-10471-9-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Sun, 24 Aug 2014 11:44:25 -0700
> @@ -389,6 +401,7 @@ static void dsa_slave_phy_setup(struct dsa_slave_priv *p,
> struct dsa_switch *ds = p->parent;
> struct dsa_chip_data *cd = ds->pd;
> struct device_node *phy_dn, *port_dn;
> + unsigned int phy_is_fixed = 0;
Please make this a bool.
^ permalink raw reply
* Re: [net-next PATCH v2 02/15] net: rcu-ify tcf_proto
From: David Miller @ 2014-08-25 5:31 UTC (permalink / raw)
To: john.fastabend; +Cc: xiyou.wangcong, jhs, eric.dumazet, netdev, paulmck, brouer
In-Reply-To: <20140825004830.2180.70308.stgit@nitbit.x32>
From: John Fastabend <john.fastabend@gmail.com>
Date: Sun, 24 Aug 2014 17:48:31 -0700
> @@ -722,8 +724,9 @@ static void sfq_free(void *addr)
> static void sfq_destroy(struct Qdisc *sch)
> {
> struct sfq_sched_data *q = qdisc_priv(sch);
> + struct tcf_proto *fl = rtnl_dereference(q->filter_list);
>
> - tcf_destroy_chain(&q->filter_list);
> + tcf_destroy_chain(&fl);
This will cause tcf_destroy_chain() to set the local variable
'fl' to NULL rather than q->filter_list.
I don't see how this can be correct at all.
You need to make tcf_destroy_chain() take a pointer to an __rcu
pointer, and do the proper dereferencing and RCU assignments in
that chain destroy loop.
This might be why you're getting annotation warnings.
^ permalink raw reply
* Re: [PATCH net-next] net: Functions to report space available in device TX queues
From: David Miller @ 2014-08-25 5:35 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <alpine.DEB.2.02.1408241312500.30395@tomh.mtv.corp.google.com>
From: Tom Herbert <therbert@google.com>
Date: Sun, 24 Aug 2014 13:19:47 -0700 (PDT)
> +/**
> + * netdev_avail_queue - report how much space is availble for xmit
> + * @dev: network device
> + *
> + * Report the amount of space available in the TX queue in terms of
> + * number of bytes. This returns the number of bytes avaiable per
> + * DQL. This function may be called without taking the txlock on
> + * the device, however in that case the result should be taken as
> + * a (strong) hint.
> + */
> +static inline int netdev_avail_queue(struct net_device *dev_queue)
> +{
> + return netdev_tx_avail_queue(netdev_get_tx_queue(dev_queue, 0));
> +}
> +
This doesn't make any sense, you're only providing queue zero's
information.
You're passing in a net_device, calling it a "dev_queue" in the
variable name, the exlicitly using queue zero of that device in the
netdev_get_tx_queue() call.
Pretty confusing if you ask me :)
^ permalink raw reply
* Re: [PATCH net-next 0/3] IPV6 Code cleansing
From: David Miller @ 2014-08-25 5:38 UTC (permalink / raw)
To: ipm; +Cc: netdev
In-Reply-To: <1408913592-10630-1-git-send-email-ipm@chirality.org.uk>
From: Ian Morris <ipm@chirality.org.uk>
Date: Sun, 24 Aug 2014 21:53:09 +0100
> This sequence of patches reduces the number of checkpatch issues in the ipv6
> code. Other than changes to whitespace, there is no change to the code.
>
> There are no changes to object output as detected by objdump.
>
> Ian Morris (3):
> ipv6: White-space cleansing : Line Layouts
> ipv6: White-space cleansing : Structure layouts
> ipv6: White-space cleansing : gaps between function and symbol export
Series applied, thanks.
^ permalink raw reply
* Re: [RFC PATCH net-next 1/3] ixgbe: support netdev_ops->ndo_xmit_flush()
From: David Miller @ 2014-08-25 5:55 UTC (permalink / raw)
To: dborkman; +Cc: netdev
In-Reply-To: <1408887738-7661-2-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Sun, 24 Aug 2014 15:42:16 +0200
> + /* we need this if more than one processor can write to our tail
> + * at a time, it synchronizes IO on IA64/Altix systems
> + */
> + mmiowb();
Unlike for IGB, this doesn't exist in the IXGBE driver, please do not add
it.
^ permalink raw reply
* Re: [RFC PATCH net-next 3/3] packet: make use of deferred TX queue flushing
From: David Miller @ 2014-08-25 5:57 UTC (permalink / raw)
To: dborkman; +Cc: netdev
In-Reply-To: <1408887738-7661-4-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Sun, 24 Aug 2014 15:42:18 +0200
> This adds a first use-case of deferred tail pointer flushing
> for AF_PACKET's TX_RING in QDISC_BYPASS mode.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
If last_queue changes, you'll need to force a flush, does that
end up happening with your changes here? I really couldn't
tell for sure.
^ permalink raw reply
* Re: [PATCH 0/3] Basic deferred TX queue flushing infrastructure.
From: David Miller @ 2014-08-25 6:10 UTC (permalink / raw)
To: netdev; +Cc: therbert, jhs, hannes, edumazet, jeffrey.t.kirsher, rusty
In-Reply-To: <20140823.132811.751469424156827125.davem@davemloft.net>
In the interest of having something to readily build upon, I pushed
my changes into net-next with the bug fixed that Alexander Duyck
pointed out.
Don't panic, if this turns out to be the wrong interface we'll adjust
it or just completely revert my changes.
^ permalink raw reply
* Re: [RFC PATCH net-next 3/3] packet: make use of deferred TX queue flushing
From: Daniel Borkmann @ 2014-08-25 6:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20140824.225741.1546858244063296096.davem@davemloft.net>
On 08/25/2014 07:57 AM, David Miller wrote:
> From: Daniel Borkmann <dborkman@redhat.com>
> Date: Sun, 24 Aug 2014 15:42:18 +0200
>
>> This adds a first use-case of deferred tail pointer flushing
>> for AF_PACKET's TX_RING in QDISC_BYPASS mode.
>>
>> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
>
> If last_queue changes, you'll need to force a flush, does that
> end up happening with your changes here? I really couldn't
> tell for sure.
Yes indeed, I noticed that later on as well. :)
I will fix that up and resubmit the series, thanks.
^ permalink raw reply
* RE: [PATCH net-next 0/4] r8152: firmware support
From: Hayes Wang @ 2014-08-25 6:43 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, nic_swsd,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20140824.212614.2300459100680592586.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
From: David Miller [mailto:davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org]
[...]
> That still doesn't convince me.
>
> The functions I see you removing are just programming a set of
> registers in some way.
That is to clear the break point of the firmware. If a firmware exists,
you should clear it before updating a new one.
> And the firmware that is replacing those functions is just going to be
> causing the same register writes, just even more obfuscated than it is
> now.
>
> You should keep the C functions which document and show clearly what
> is being programmed in each chip.
>
> Don't hide register programming behind firmware files, please.
Excuse me. Some settings are relative the content of the firmware.
How should I deal with that parts. Take 8153 (RTL_VER_03) for
example.
1. wait PLA 0xb800 bit 6 = 1.
2. set patch key = 0x7000.
3. update the PHY firmware.
4. enable the firmware.
5. set USB 0xcfca bit 14 = 0.
6. clear break point (That is r8153_clear_bp()).
7. load the firmware about PLA and USB parts.
8. set the break point of the firmware.
9. set USB 0xcfca bit 14 = 1.
Except the step 3, 4, 6 and 7, the other steps depend on the
context of the firmware. That is, for different firmware, some
actions would be removed or added, and some settings would be
different. Especially the step 8, it often different for
different firmwares. Should I add some firmware version check
in the source code? Such as
if (fw_version == v1) {
...
load firmware
set break point of the firmware
...
} else if (fw_version == v2) {
...--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* Re: [PATCH net-next 0/4] r8152: firmware support
From: David Miller @ 2014-08-25 7:00 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <0835B3720019904CB8F7AA43166CEEB25161DF@RTITMBSV03.realtek.com.tw>
From: Hayes Wang <hayeswang@realtek.com>
Date: Mon, 25 Aug 2014 06:43:02 +0000
> Except the step 3, 4, 6 and 7, the other steps depend on the
> context of the firmware. That is, for different firmware, some
> actions would be removed or added, and some settings would be
> different. Especially the step 8, it often different for
> different firmwares. Should I add some firmware version check
> in the source code?
This is extremely poor design of the firmware, adding such constantly
changing dependencies and constantly changing programming sequences
just to get the firmare executing is a terrible idea.
You really need to sanitize this in some way, because what you have
posted is totally unacceptable to me.
^ permalink raw reply
* [PATCH net-next] r8152: check code with checkpatch.pl
From: Hayes Wang @ 2014-08-25 7:53 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-16-Taiwan-albertk@realtek.com>
626: CHECK: Alignment should match open parenthesis
646: CHECK: Alignment should match open parenthesis
655: CHECK: Alignment should match open parenthesis
695: CHECK: Alignment should match open parenthesis
729: CHECK: Alignment should match open parenthesis
739: CHECK: Alignment should match open parenthesis
976: WARNING: externs should be avoided in .c files
1314: CHECK: Alignment should match open parenthesis
1358: WARNING: networking block comments don't use an empty /* line, use /* Comment...
1402: WARNING: networking block comments don't use an empty /* line, use /* Comment...
1521: CHECK: multiple assignments should be avoided
1775: CHECK: Alignment should match open parenthesis
1838: CHECK: multiple assignments should be avoided
1843: CHECK: multiple assignments should be avoided
1847: CHECK: multiple assignments should be avoided
1850: WARNING: Missing a blank line after declarations
1864: CHECK: Alignment should match open parenthesis
1872: CHECK: braces {} should be used on all arms of this statement
1906: CHECK: usleep_range is preferred over udelay
2865: WARNING: networking block comments don't use an empty /* line, use /* Comment...
3088: CHECK: Alignment should match open parenthesis
total: 0 errors, 5 warnings, 16 checks, 3567 lines checked
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 66 ++++++++++++++++++++++++++-----------------------
1 file changed, 35 insertions(+), 31 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 87f7104..2470d9c 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -623,8 +623,8 @@ int get_registers(struct r8152 *tp, u16 value, u16 index, u16 size, void *data)
return -ENOMEM;
ret = usb_control_msg(tp->udev, usb_rcvctrlpipe(tp->udev, 0),
- RTL8152_REQ_GET_REGS, RTL8152_REQT_READ,
- value, index, tmp, size, 500);
+ RTL8152_REQ_GET_REGS, RTL8152_REQT_READ,
+ value, index, tmp, size, 500);
memcpy(data, tmp, size);
kfree(tmp);
@@ -643,8 +643,8 @@ int set_registers(struct r8152 *tp, u16 value, u16 index, u16 size, void *data)
return -ENOMEM;
ret = usb_control_msg(tp->udev, usb_sndctrlpipe(tp->udev, 0),
- RTL8152_REQ_SET_REGS, RTL8152_REQT_WRITE,
- value, index, tmp, size, 500);
+ RTL8152_REQ_SET_REGS, RTL8152_REQT_WRITE,
+ value, index, tmp, size, 500);
kfree(tmp);
@@ -652,7 +652,7 @@ int set_registers(struct r8152 *tp, u16 value, u16 index, u16 size, void *data)
}
static int generic_ocp_read(struct r8152 *tp, u16 index, u16 size,
- void *data, u16 type)
+ void *data, u16 type)
{
u16 limit = 64;
int ret = 0;
@@ -692,7 +692,7 @@ static int generic_ocp_read(struct r8152 *tp, u16 index, u16 size,
}
static int generic_ocp_write(struct r8152 *tp, u16 index, u16 byteen,
- u16 size, void *data, u16 type)
+ u16 size, void *data, u16 type)
{
int ret;
u16 byteen_start, byteen_end, byen;
@@ -726,8 +726,8 @@ static int generic_ocp_write(struct r8152 *tp, u16 index, u16 byteen,
while (size) {
if (size > limit) {
ret = set_registers(tp, index,
- type | BYTE_EN_DWORD,
- limit, data);
+ type | BYTE_EN_DWORD,
+ limit, data);
if (ret < 0)
goto error1;
@@ -736,8 +736,8 @@ static int generic_ocp_write(struct r8152 *tp, u16 index, u16 byteen,
size -= limit;
} else {
ret = set_registers(tp, index,
- type | BYTE_EN_DWORD,
- size, data);
+ type | BYTE_EN_DWORD,
+ size, data);
if (ret < 0)
goto error1;
@@ -972,8 +972,8 @@ void write_mii_word(struct net_device *netdev, int phy_id, int reg, int val)
usb_autopm_put_interface(tp->intf);
}
-static
-int r8152_submit_rx(struct r8152 *tp, struct rx_agg *agg, gfp_t mem_flags);
+static int
+r8152_submit_rx(struct r8152 *tp, struct rx_agg *agg, gfp_t mem_flags);
static inline void set_ethernet_addr(struct r8152 *tp)
{
@@ -1311,8 +1311,8 @@ static int alloc_all_mem(struct r8152 *tp)
tp->intr_interval = (int)ep_intr->desc.bInterval;
usb_fill_int_urb(tp->intr_urb, tp->udev, usb_rcvintpipe(tp->udev, 3),
- tp->intr_buff, INTBUFSIZE, intr_callback,
- tp, tp->intr_interval);
+ tp->intr_buff, INTBUFSIZE, intr_callback,
+ tp, tp->intr_interval);
return 0;
@@ -1354,8 +1354,7 @@ static inline __be16 get_protocol(struct sk_buff *skb)
return protocol;
}
-/*
- * r8152_csum_workaround()
+/* r8152_csum_workaround()
* The hw limites the value the transport offset. When the offset is out of the
* range, calculate the checksum by sw.
*/
@@ -1398,8 +1397,7 @@ drop:
}
}
-/*
- * msdn_giant_send_check()
+/* msdn_giant_send_check()
* According to the document of microsoft, the TCP Pseudo Header excludes the
* packet length for IPv6 TCP large packets.
*/
@@ -1518,7 +1516,8 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct tx_agg *agg)
spin_unlock(&tx_queue->lock);
tx_data = agg->head;
- agg->skb_num = agg->skb_len = 0;
+ agg->skb_num = 0;
+ agg->skb_len = 0;
remain = rx_buf_sz;
while (remain >= ETH_ZLEN + sizeof(struct tx_desc)) {
@@ -1772,8 +1771,8 @@ static
int r8152_submit_rx(struct r8152 *tp, struct rx_agg *agg, gfp_t mem_flags)
{
usb_fill_bulk_urb(agg->urb, tp->udev, usb_rcvbulkpipe(tp->udev, 1),
- agg->head, rx_buf_sz,
- (usb_complete_t)read_bulk_callback, agg);
+ agg->head, rx_buf_sz,
+ (usb_complete_t)read_bulk_callback, agg);
return usb_submit_urb(agg->urb, mem_flags);
}
@@ -1835,18 +1834,22 @@ static void _rtl8152_set_rx_mode(struct net_device *netdev)
/* Unconditionally log net taps. */
netif_notice(tp, link, netdev, "Promiscuous mode enabled\n");
ocp_data |= RCR_AM | RCR_AAP;
- mc_filter[1] = mc_filter[0] = 0xffffffff;
+ mc_filter[1] = 0xffffffff;
+ mc_filter[0] = 0xffffffff;
} else if ((netdev_mc_count(netdev) > multicast_filter_limit) ||
(netdev->flags & IFF_ALLMULTI)) {
/* Too many to filter perfectly -- accept all multicasts. */
ocp_data |= RCR_AM;
- mc_filter[1] = mc_filter[0] = 0xffffffff;
+ mc_filter[1] = 0xffffffff;
+ mc_filter[0] = 0xffffffff;
} else {
struct netdev_hw_addr *ha;
- mc_filter[1] = mc_filter[0] = 0;
+ mc_filter[1] = 0;
+ mc_filter[0] = 0;
netdev_for_each_mc_addr(ha, netdev) {
int bit_nr = ether_crc(ETH_ALEN, ha->addr) >> 26;
+
mc_filter[bit_nr >> 5] |= 1 << (bit_nr & 31);
ocp_data |= RCR_AM;
}
@@ -1861,7 +1864,7 @@ static void _rtl8152_set_rx_mode(struct net_device *netdev)
}
static netdev_tx_t rtl8152_start_xmit(struct sk_buff *skb,
- struct net_device *netdev)
+ struct net_device *netdev)
{
struct r8152 *tp = netdev_priv(netdev);
@@ -1877,8 +1880,9 @@ static netdev_tx_t rtl8152_start_xmit(struct sk_buff *skb,
usb_mark_last_busy(tp->udev);
tasklet_schedule(&tp->tl);
}
- } else if (skb_queue_len(&tp->tx_queue) > tp->tx_qlen)
+ } else if (skb_queue_len(&tp->tx_queue) > tp->tx_qlen) {
netif_stop_queue(netdev);
+ }
return NETDEV_TX_OK;
}
@@ -1903,7 +1907,7 @@ static void rtl8152_nic_reset(struct r8152 *tp)
for (i = 0; i < 1000; i++) {
if (!(ocp_read_byte(tp, MCU_TYPE_PLA, PLA_CR) & CR_RST))
break;
- udelay(100);
+ usleep_range(100, 400);
}
}
@@ -2861,8 +2865,7 @@ static int rtl8152_close(struct net_device *netdev)
if (res < 0) {
rtl_drop_queued_tx(tp);
} else {
- /*
- * The autosuspend may have been enabled and wouldn't
+ /* The autosuspend may have been enabled and wouldn't
* be disable when autoresume occurs, because the
* netif_running() would be false.
*/
@@ -3085,8 +3088,9 @@ static int rtl8152_resume(struct usb_interface *intf)
} else {
tp->rtl_ops.up(tp);
rtl8152_set_speed(tp, AUTONEG_ENABLE,
- tp->mii.supports_gmii ? SPEED_1000 : SPEED_100,
- DUPLEX_FULL);
+ tp->mii.supports_gmii ?
+ SPEED_1000 : SPEED_100,
+ DUPLEX_FULL);
}
tp->speed = 0;
netif_carrier_off(tp->netdev);
--
1.9.3
^ permalink raw reply related
* [PATCH v2] ray_cs: Add include guards
From: Rasmus Villemoes @ 2014-08-25 7:59 UTC (permalink / raw)
To: John W. Linville, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel, Rasmus Villemoes
In-Reply-To: <87ppfq85bh.fsf@purkki.adurom.net>
The files ray_cs.h and rayctl.h both contain two thirds of what
appears to be an include guard using the macro name RAYLINK_H (both
lack the #define). Since RAYLINK_H is not defined anywhere, the
#ifndefs are confusing no-ops. Add proper include guards using
different macro names.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
Notes:
v2: Change subject prefix and fix broken commit message.
drivers/net/wireless/ray_cs.h | 5 +++--
drivers/net/wireless/rayctl.h | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ray_cs.h b/drivers/net/wireless/ray_cs.h
index e79848f..524c2f0 100644
--- a/drivers/net/wireless/ray_cs.h
+++ b/drivers/net/wireless/ray_cs.h
@@ -3,7 +3,8 @@
Written by Corey Thomas
*/
-#ifndef RAYLINK_H
+#ifndef _RAY_CS_H_
+#define _RAY_CS_H_
struct beacon_rx {
struct mac_header mac;
@@ -69,4 +70,4 @@ typedef struct ray_dev_t {
} ray_dev_t;
/*****************************************************************************/
-#endif /* RAYLINK_H */
+#endif /* _RAY_CS_H_ */
diff --git a/drivers/net/wireless/rayctl.h b/drivers/net/wireless/rayctl.h
index 3c3b98b..b21ed64 100644
--- a/drivers/net/wireless/rayctl.h
+++ b/drivers/net/wireless/rayctl.h
@@ -1,4 +1,5 @@
-#ifndef RAYLINK_H
+#ifndef _RAYCTL_H_
+#define _RAYCTL_H_
typedef unsigned char UCHAR;
@@ -729,4 +730,4 @@ typedef struct snaphdr_t
#define RAY_IPX_TYPE 0x8137
#define APPLEARP_TYPE 0x80f3
/*****************************************************************************/
-#endif /* #ifndef RAYLINK_H */
+#endif /* _RAYCTL_H_ */
--
2.0.4
^ permalink raw reply related
* Re: [PATCH] cdc-ether: clean packet filter upon probe
From: Oliver Neukum @ 2014-08-25 8:07 UTC (permalink / raw)
To: Bjørn Mork; +Cc: davem, netdev
In-Reply-To: <87d2c2xm2k.fsf@nemi.mork.no>
On Fri, 2014-08-15 at 09:13 +0200, Bjørn Mork wrote:
> Oliver Neukum <oneukum@suse.de> writes:
>
> > On Thu, 2014-08-14 at 13:11 +0200, Bjørn Mork wrote:
> > Support for this request is mandatory.
>
> Yes, there is no problem for standard conforming ECM devices. I fully
> agree there.
>
> But standard conformance is unfortunately not something we can expect.
> My question was regarding the non-conforming devices, like the ones
> supported by th zaurus and rndis_host drivers. These drivers are made
You have a point. Yet another flag? Do you see an alternative?
Regards
Oliver
^ permalink raw reply
* Re: [PATCH V2 1/1] netfilter/jump_label: HAVE_JUMP_LABEL instead of CONFIG_JUMP_LABEL
From: Pablo Neira Ayuso @ 2014-08-25 8:38 UTC (permalink / raw)
To: Zhouyi Zhou
Cc: fw, kaber, kadlec, davem, netfilter-devel, coreteam, netdev,
linux-kernel, jbaron, Zhouyi Zhou
In-Reply-To: <1408675215-2893-1-git-send-email-yizhouzhou@ict.ac.cn>
On Fri, Aug 22, 2014 at 10:40:15AM +0800, Zhouyi Zhou wrote:
> Use HAVE_JUMP_LABEL as elsewhere in the kernel to ensure
> that the toolchain has the required support in addition to
> CONFIG_JUMP_LABEL being set.
Applied, thanks.
^ permalink raw reply
* Re: [hyperv] BUG at drivers/hv/channel.c:462 while changing MTU
From: Dan Carpenter @ 2014-08-25 9:36 UTC (permalink / raw)
To: Sitsofe Wheeler
Cc: Greg Kroah-Hartman, Jason Wang, Haiyang Zhang, linux-kernel,
Daniel Borkmann, netdev, devel, David S. Miller
In-Reply-To: <20140819123655.GC12160@sucs.org>
The code here is:
drivers/hv/channel.c
460 BUG_ON(ret != 0);
461 t = wait_for_completion_timeout(&info->waitevent, 5*HZ);
462 BUG_ON(t == 0);
So it calls BUG_ON() if the teardown takes more than 5 seconds. It's
most likely that there is a race condition somewhere. It's also
possible that it's just taking longer than 5 seconds for some odd
reason and the bug would go away if we raised it to 60 seconds.
BUG_ON() after 5 seconds seems like a very aggressive thing.
regards,
dan carpenter
^ permalink raw reply
* [PATCH] net: rds: Don't allocate rds_sock on stack
From: Mark Brown @ 2014-08-25 0:32 UTC (permalink / raw)
To: Chien Yen, David S. Miller; +Cc: rds-devel, netdev, linaro-kernel, Mark Brown
From: Mark Brown <broonie@linaro.org>
struct rds_sock is rather large ausing the following warning in an ARM
allmodconfig:
net/rds/iw_rdma.c:200:1: warning: the frame size of 1056 bytes is larger than 1024 bytes [-Wframe-larger-than=]
Fix this by dynamically allocating struct rds_sock in rds_iw_update_cm_id
instead of allocating it on the stack.
Signed-off-by: Mark Brown <broonie@linaro.org>
---
net/rds/iw_rdma.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/net/rds/iw_rdma.c b/net/rds/iw_rdma.c
index a817705..cee5daa 100644
--- a/net/rds/iw_rdma.c
+++ b/net/rds/iw_rdma.c
@@ -180,22 +180,28 @@ int rds_iw_update_cm_id(struct rds_iw_device *rds_iwdev, struct rdma_cm_id *cm_i
{
struct sockaddr_in *src_addr, *dst_addr;
struct rds_iw_device *rds_iwdev_old;
- struct rds_sock rs;
+ struct rds_sock *rs;
struct rdma_cm_id *pcm_id;
int rc;
+ rs = kzalloc(sizeof(*rs), GFP_KERNEL);
+ if (!rs)
+ return -ENOMEM;
+
src_addr = (struct sockaddr_in *)&cm_id->route.addr.src_addr;
dst_addr = (struct sockaddr_in *)&cm_id->route.addr.dst_addr;
- rs.rs_bound_addr = src_addr->sin_addr.s_addr;
- rs.rs_bound_port = src_addr->sin_port;
- rs.rs_conn_addr = dst_addr->sin_addr.s_addr;
- rs.rs_conn_port = dst_addr->sin_port;
+ rs->rs_bound_addr = src_addr->sin_addr.s_addr;
+ rs->rs_bound_port = src_addr->sin_port;
+ rs->rs_conn_addr = dst_addr->sin_addr.s_addr;
+ rs->rs_conn_port = dst_addr->sin_port;
- rc = rds_iw_get_device(&rs, &rds_iwdev_old, &pcm_id);
+ rc = rds_iw_get_device(rs, &rds_iwdev_old, &pcm_id);
if (rc)
rds_iw_remove_cm_id(rds_iwdev, cm_id);
+ kfree(rs);
+
return rds_iw_add_cm_id(rds_iwdev, cm_id);
}
--
2.1.0.rc1
^ permalink raw reply related
* Re: [PATCH net-next 02/17] tipc: Fix build.
From: Neil Horman @ 2014-08-25 10:21 UTC (permalink / raw)
To: Jon Maloy
Cc: davem, netdev, Paul Gortmaker, erik.hugne, ying.xue, maloy,
tipc-discussion
In-Reply-To: <1408745360-23560-3-git-send-email-jon.maloy@ericsson.com>
On Fri, Aug 22, 2014 at 06:09:05PM -0400, Jon Maloy wrote:
> From: "David S. Miller" <davem@davemloft.net>
>
> Missing semicolon in range check fix.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
> ---
> net/tipc/port.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/tipc/port.h b/net/tipc/port.h
> index a69118f..3087da3 100644
> --- a/net/tipc/port.h
> +++ b/net/tipc/port.h
> @@ -182,8 +182,9 @@ static inline int tipc_port_importance(struct tipc_port *port)
> static inline int tipc_port_set_importance(struct tipc_port *port, int imp)
> {
> if (imp > TIPC_CRITICAL_IMPORTANCE)
> - return -EINVAL
> + return -EINVAL;
> msg_set_importance(&port->phdr, (u32)imp);
> + return 0;
> }
>
Fold this in with the previous patch to avoid a FTBFS during a bisect.
Neil
^ permalink raw reply
* Re: [hyperv] BUG at drivers/hv/channel.c:462 while changing MTU
From: Richard Weinberger @ 2014-08-25 10:48 UTC (permalink / raw)
To: Sitsofe Wheeler
Cc: Greg Kroah-Hartman, Jason Wang, linux-kernel@vger.kernel.org,
David S. Miller, Daniel Borkmann, netdev@vger.kernel.org,
devel@linuxdriverproject.org, Haiyang Zhang
In-Reply-To: <20140820034116.GA3407@sucs.org>
via
On Wed, Aug 20, 2014 at 5:41 AM, Sitsofe Wheeler <sitsofe@gmail.com> wrote:
> Aug 20 04:04:41 ubuntuhv kernel: [ 9.230399] random: nonblocking pool is initialized
> Aug 20 04:04:41 ubuntuhv kernel: [ 10.338487] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
> Aug 20 04:04:41 ubuntuhv kernel: [ 11.099094] hv_storvsc vmbus_0_1: cmd 0x85 scsi status 0x2 srb status 0x6
> Aug 20 04:04:41 ubuntuhv kernel: [ 11.099901] hv_storvsc vmbus_0_1: cmd 0x85 scsi status 0x2 srb status 0x6
> Aug 20 04:04:43 ubuntuhv kernel: [ 12.999830] psmouse serio1: trackpoint: IBM TrackPoint firmware: 0x01, buttons: 0/0
> Aug 20 03:55:47 ubuntuhv kernel: [ 13.003659] input: TPPS/2 IBM TrackPoint as /devices/platform/i8042/serio1/input/input4
> Aug 20 03:57:28 ubuntuhv kernel: [ 113.711832] hv_netvsc vmbus_0_14: net device safe to remove
> Aug 20 03:57:28 ubuntuhv kernel: [ 113.713882] hv_netvsc: hv_netvsc channel opened successfully
> Aug 20 03:57:29 ubuntuhv kernel: [ 114.961312] hv_netvsc vmbus_0_14: Send section size: 6144, Section count:2560
> Aug 20 03:57:29 ubuntuhv kernel: [ 114.962711] hv_netvsc vmbus_0_14: Device MAC 00:15:5d:6f:02:af link state up
> Aug 20 03:57:34 ubuntuhv kernel: [ 120.027718] hv_netvsc vmbus_0_14: net device safe to remove
> Aug 20 03:57:34 ubuntuhv kernel: [ 120.030047] hv_netvsc: hv_netvsc channel opened successfully
> Aug 20 03:57:34 ubuntuhv kernel: [ 120.035422] hv_netvsc vmbus_0_14 eth0: unable to establish receive buffer's gpadl
> Aug 20 03:57:34 ubuntuhv kernel: [ 120.039778] hv_netvsc vmbus_0_14 eth0: unable to connect to NetVSP - 4
> Aug 20 03:57:34 ubuntuhv kernel: [ 120.039818] ------------[ cut here ]------------
> Aug 20 03:57:34 ubuntuhv kernel: [ 120.039832] kernel BUG at drivers/hv/channel.c:504!
This is one is also a rude BUG_ON:
ret = vmbus_post_msg(msg, sizeof(struct vmbus_channel_close_channel));
BUG_ON(ret != 0);
vmbus_post_msg() hv_post_message() can easily return !0.
i.e. if this kmalloc() fails:
addr = (unsigned long)kmalloc(sizeof(struct aligned_input), GFP_ATOMIC);
if (!addr)
return -ENOMEM;
--
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH] cdc-ether: clean packet filter upon probe
From: Bjørn Mork @ 2014-08-25 8:39 UTC (permalink / raw)
To: Oliver Neukum; +Cc: davem, netdev
In-Reply-To: <1408954063.10300.1.camel@linux-fkkt.site>
Oliver Neukum <oneukum@suse.de> writes:
> On Fri, 2014-08-15 at 09:13 +0200, Bjørn Mork wrote:
>> Oliver Neukum <oneukum@suse.de> writes:
>>
>> > On Thu, 2014-08-14 at 13:11 +0200, Bjørn Mork wrote:
>
>> > Support for this request is mandatory.
>>
>> Yes, there is no problem for standard conforming ECM devices. I fully
>> agree there.
>>
>> But standard conformance is unfortunately not something we can expect.
>> My question was regarding the non-conforming devices, like the ones
>> supported by th zaurus and rndis_host drivers. These drivers are made
>
> You have a point. Yet another flag? Do you see an alternative?
Note that I don't know whether this is a real problem or not. I don't
believe I have any zaurus or rndis_host devices.
But how about just splitting the .bind functions for true ECM devices
and the others, letting the zaurus and rndis_host driver continue to use
usbnet_cdc_bind with no filter setting? Maybe define a new unexported
.bind in cdc_ether for this purpose, moving the ECM specific
initialization there?
Maybe something along this (instead of the change to
usbnet_generic_cdc_bind)?:
static int usbnet_cdc_ecm_bind(struct usbnet *dev, struct usb_interface *intf)
{
int rv = usbnet_cdc_bind(dev, intf);
if (rv < 0)
return rv;
/* Some devices don't initialise properly. In particular
* the packet filter is not reset. There are devices that
* don't do reset all the way. So the packet filter should
* be set to a sane initial value.
*/
rv = usb_control_msg(dev->udev,
usb_sndctrlpipe(dev->udev, 0),
USB_CDC_SET_ETHERNET_PACKET_FILTER,
USB_TYPE_CLASS | USB_RECIP_INTERFACE,
USB_CDC_PACKET_TYPE_ALL_MULTICAST | USB_CDC_PACKET_TYPE_DIRECTED | USB_CDC_PACKET_TYPE_BROADCAST,
intf->cur_altsetting->desc.bInterfaceNumber,
NULL,
0,
USB_CTRL_SET_TIMEOUT);
if (rv < 0)
return rv;
return 0;
}
..
static const struct driver_info cdc_info = {
.description = "CDC Ethernet Device",
.flags = FLAG_ETHER | FLAG_POINTTOPOINT,
.bind = usbnet_cdc_ecm_bind,
.unbind = usbnet_cdc_unbind,
.status = usbnet_cdc_status,
.manage_power = usbnet_manage_power,
};
Bjørn
^ permalink raw reply
* [PATCH for -next] stmmac: simple cleanups
From: Pavel Machek @ 2014-08-25 11:31 UTC (permalink / raw)
To: David Miller; +Cc: peppe.cavallaro, netdev, linux-kernel
In-Reply-To: <20140822.123408.2064974279443073401.davem@davemloft.net>
This adds simple cleanups for stmmac, removing test we know is always
true, fixing whitespace, and moving code out of if().
Signed-off-by: Pavel Machek <pavel@denx.de>
---
Now against -net-next.
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index 9af50ba..493fe69 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -261,11 +261,11 @@ static int stmmac_ethtool_getsettings(struct net_device *dev,
ethtool_cmd_speed_set(cmd, priv->xstats.pcs_speed);
/* Get and convert ADV/LP_ADV from the HW AN registers */
- if (priv->hw->mac->get_adv)
- priv->hw->mac->get_adv(priv->hw, &adv);
- else
+ if (!priv->hw->mac->get_adv)
return -EOPNOTSUPP; /* should never happen indeed */
+ priv->hw->mac->get_adv(priv->hw, &adv);
+
/* Encoding of PSE bits is defined in 802.3z, 37.2.1.4 */
if (adv.pause & STMMAC_PCS_PAUSE)
@@ -340,19 +340,17 @@ static int stmmac_ethtool_setsettings(struct net_device *dev,
if (cmd->autoneg != AUTONEG_ENABLE)
return -EINVAL;
- if (cmd->autoneg == AUTONEG_ENABLE) {
- mask &= (ADVERTISED_1000baseT_Half |
+ mask &= (ADVERTISED_1000baseT_Half |
ADVERTISED_1000baseT_Full |
ADVERTISED_100baseT_Half |
ADVERTISED_100baseT_Full |
ADVERTISED_10baseT_Half |
ADVERTISED_10baseT_Full);
- spin_lock(&priv->lock);
- if (priv->hw->mac->ctrl_ane)
- priv->hw->mac->ctrl_ane(priv->hw, 1);
- spin_unlock(&priv->lock);
- }
+ spin_lock(&priv->lock);
+ if (priv->hw->mac->ctrl_ane)
+ priv->hw->mac->ctrl_ane(priv->hw, 1);
+ spin_unlock(&priv->lock);
return 0;
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 08addd6..8fcc64c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -818,7 +818,7 @@ static int stmmac_init_phy(struct net_device *dev)
/* Stop Advertising 1000BASE Capability if interface is not GMII */
if ((interface == PHY_INTERFACE_MODE_MII) ||
(interface == PHY_INTERFACE_MODE_RMII) ||
- (max_speed < 1000 && max_speed > 0))
+ (max_speed < 1000 && max_speed > 0))
phydev->advertising &= ~(SUPPORTED_1000baseT_Half |
SUPPORTED_1000baseT_Full);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index a5b1e1b..8dd0408 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -253,7 +253,7 @@ int stmmac_mdio_register(struct net_device *ndev)
}
/*
- * If we're going to bind the MAC to this PHY bus,
+ * If we're going to bind the MAC to this PHY bus,
* and no PHY number was provided to the MAC,
* use the one probed here.
*/
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply related
* Re: [PATCH] net: rds: Don't allocate rds_sock on stack
From: Arnd Bergmann @ 2014-08-25 11:33 UTC (permalink / raw)
To: linaro-kernel
Cc: Mark Brown, Chien Yen, David S. Miller, netdev, rds-devel,
Mark Brown
In-Reply-To: <1408926755-12277-1-git-send-email-broonie@kernel.org>
On Sunday 24 August 2014 19:32:35 Mark Brown wrote:
> From: Mark Brown <broonie@linaro.org>
>
> struct rds_sock is rather large ausing the following warning in an ARM
> allmodconfig:
>
> net/rds/iw_rdma.c:200:1: warning: the frame size of 1056 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>
> Fix this by dynamically allocating struct rds_sock in rds_iw_update_cm_id
> instead of allocating it on the stack.
>
> Signed-off-by: Mark Brown <broonie@linaro.org>
>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ 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