* Re: llc: remove noisy WARN from llc_mac_hdr_init
From: David Miller @ 2014-01-29 2:01 UTC (permalink / raw)
To: davej; +Cc: netdev
In-Reply-To: <20140128213052.GA10689@redhat.com>
From: Dave Jones <davej@redhat.com>
Date: Tue, 28 Jan 2014 16:30:52 -0500
> Sending malformed llc packets triggers this spew, which seems excessive.
...
> Until 2009, this was a printk, when it was changed in
> bf9ae5386bc: "llc: use dev_hard_header".
>
> Let userland figure out what -EINVAL means by itself.
>
> Signed-off-by: Dave Jones <davej@fedoraproject.org>
Applied, thanks Dave.
^ permalink raw reply
* Re: [GIT PULL] AF_RXRPC fixes
From: David Miller @ 2014-01-29 2:05 UTC (permalink / raw)
To: dhowells; +Cc: netdev, linux-afs, tim, khoroshilov, linux-kernel
In-Reply-To: <8672.1390928856@warthog.procyon.org.uk>
From: David Howells <dhowells@redhat.com>
Date: Tue, 28 Jan 2014 17:07:36 +0000
> Here are some small AF_RXRPC fixes.
>
> (1) Fix a place where a spinlock is taken conditionally but is released
> unconditionally.
>
> (2) Fix a double-free that happens when cleaning up on a checksum error.
>
> (3) Fix handling of CHECKSUM_PARTIAL whilst delivering messages to userspace.
Pulled, thanks David.
^ permalink raw reply
* Re: [PATCH] [trivial] net: Fix warning on make htmldocs caused by skbuff.c
From: David Miller @ 2014-01-29 2:06 UTC (permalink / raw)
To: standby24x7; +Cc: trivial, netdev, linux-kernel
In-Reply-To: <1390925128-20768-1-git-send-email-standby24x7@gmail.com>
From: Masanari Iida <standby24x7@gmail.com>
Date: Wed, 29 Jan 2014 01:05:28 +0900
> This patch fixed following Warning while executing "make htmldocs".
>
> Warning(/net/core/skbuff.c:2164): No description found for parameter 'from'
> Warning(/net/core/skbuff.c:2164): Excess function parameter 'source'
> description in 'skb_zerocopy'
> Replace "@source" with "@from" fixed the warning.
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] tun: add device name(iff) field to proc fdinfo entry
From: David Miller @ 2014-01-29 2:08 UTC (permalink / raw)
To: yamato; +Cc: netdev
In-Reply-To: <1390928051-6113-1-git-send-email-yamato@redhat.com>
From: Masatake YAMATO <yamato@redhat.com>
Date: Wed, 29 Jan 2014 01:54:11 +0900
> # cat /proc/4565/fdinfo/25
> pos: 138
> flags: 0104002
> iff: vnet0
Please properly indent iff just like the other fdinfo fields
are.
Thanks.
^ permalink raw reply
* Re: [PATCH net] bnx2x: Fix generic option settings
From: David Miller @ 2014-01-29 2:09 UTC (permalink / raw)
To: yanivr; +Cc: netdev, ariele
In-Reply-To: <1390922931-2137-1-git-send-email-yanivr@broadcom.com>
From: Yaniv Rosner <yanivr@broadcom.com>
Date: Tue, 28 Jan 2014 17:28:51 +0200
> When user tried to change generic options using "ethtool -s" command, while SFP
> module is plugged out or during module detection, the command would have failed
> with "Unsupported port type" message. The fix is to ignore the port option in
> case it's same as the current port configuration.
>
> Signed-off-by: Yaniv Rosner <yanivr@broadcom.com>
> Signed-off-by: Ariel Elior <ariele@broadcom.com>
Applied, thanks.
^ permalink raw reply
* [PATCH regression] dma-debug: fix overlap detection
From: Dan Williams @ 2014-01-29 3:00 UTC (permalink / raw)
To: akpm; +Cc: Sander Eikelenboom, netdev, linux-kernel, Francois Romieu
Commit 0abdd7a81b7e "dma-debug: introduce debug_dma_assert_idle()" was
reworked to expand the overlap counter to the full range expressable by
3 tag bits, but it has a thinko in treating the overlap counter as a
pure reference count for the entry.
Instead of deleting when the reference-count drops to zero, we need to
delete when the overlap-count drops below zero. Also, when detecting
overflow we can just test the overlap-count > MAX rather than applying
special meaning to 0.
Cc: Francois Romieu <romieu@fr.zoreil.com>
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
Regression report available here:
http://marc.info/?l=linux-netdev&m=139073373932386&w=2
This patch, now tested on the original net_dma case, sees the expected
handful of reports before the eventual data corruption occurs.
lib/dma-debug.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index c38083871f11..2defd1308b04 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -463,7 +463,7 @@ static int active_pfn_set_overlap(unsigned long pfn, int overlap)
int i;
if (overlap > ACTIVE_PFN_MAX_OVERLAP || overlap < 0)
- return 0;
+ return overlap;
for (i = RADIX_TREE_MAX_TAGS - 1; i >= 0; i--)
if (overlap & 1 << i)
@@ -486,7 +486,7 @@ static void active_pfn_inc_overlap(unsigned long pfn)
* debug_dma_assert_idle() as the pfn may be marked idle
* prematurely.
*/
- WARN_ONCE(overlap == 0,
+ WARN_ONCE(overlap > ACTIVE_PFN_MAX_OVERLAP,
"DMA-API: exceeded %d overlapping mappings of pfn %lx\n",
ACTIVE_PFN_MAX_OVERLAP, pfn);
}
@@ -517,7 +517,11 @@ static void active_pfn_remove(struct dma_debug_entry *entry)
unsigned long flags;
spin_lock_irqsave(&radix_lock, flags);
- if (active_pfn_dec_overlap(entry->pfn) == 0)
+ /* since we are counting overlaps the final put of the
+ * entry->pfn will occur when the overlap count is 0.
+ * active_pfn_dec_overlap() returns -1 in that case
+ */
+ if (active_pfn_dec_overlap(entry->pfn) < 0)
radix_tree_delete(&dma_active_pfn, entry->pfn);
spin_unlock_irqrestore(&radix_lock, flags);
}
^ permalink raw reply related
* Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
From: Dan Williams @ 2014-01-29 3:06 UTC (permalink / raw)
To: Francois Romieu
Cc: Sander Eikelenboom, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Andrew Morton, Linus Torvalds
In-Reply-To: <20140127000305.GA14236@electric-eye.fr.zoreil.com>
On Sun, Jan 26, 2014 at 4:03 PM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> Sander Eikelenboom <linux@eikelenboom.it> :
> [...]
>> I have got a regression with a 3.14-mw kernel (last commit is 4ba9920e5e9c0e16b5ed24292d45322907bb9035):
>> It looks like it's related to the rtl8169 ...
>>
>> --
>> Sander
>>
>> Jan 26 11:36:26 serveerstertje kernel: [ 89.105537] ------------[ cut here ]------------
>> Jan 26 11:36:26 serveerstertje kernel: [ 89.116779] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:491 add_dma_entry+0x103/0x130()
>> Jan 26 11:36:26 serveerstertje kernel: [ 89.128148] DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
>> Jan 26 11:36:26 serveerstertje kernel: [ 89.139397] Modules linked in:
>> Jan 26 11:36:26 serveerstertje kernel: [ 89.150535] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0-20140125-mw-pcireset+ #1
>> Jan 26 11:36:26 serveerstertje kernel: [ 89.161784] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010
>> Jan 26 11:36:26 serveerstertje kernel: [ 89.172965] 0000000000000009 ffff88005f603838 ffffffff81acbcfa ffffffff822134e0
>> Jan 26 11:36:26 serveerstertje kernel: [ 89.184156] ffff88005f603888 ffff88005f603878 ffffffff810bdf62 ffff880000000000
>> Jan 26 11:36:26 serveerstertje kernel: [ 89.195186] 0000000000055ebe 00000000ffffffef 0000000000000200 ffff8800592ea098
>> Jan 26 11:36:26 serveerstertje kernel: [ 89.206227] Call Trace:
>> Jan 26 11:36:26 serveerstertje kernel: [ 89.217027] <IRQ> [<ffffffff81acbcfa>] dump_stack+0x46/0x58
>> Jan 26 11:36:26 serveerstertje kernel: [ 89.227907] [<ffffffff810bdf62>] warn_slowpath_common+0x82/0xb0
>> Jan 26 11:36:26 serveerstertje kernel: [ 89.238678] [<ffffffff810be031>] warn_slowpath_fmt+0x41/0x50
>> Jan 26 11:36:26 serveerstertje kernel: [ 89.249336] [<ffffffff81471c5a>] ? active_pfn_read_overlap+0x3a/0x70
>> Jan 26 11:36:26 serveerstertje kernel: [ 89.259904] [<ffffffff814729e3>] add_dma_entry+0x103/0x130
>> Jan 26 11:36:26 serveerstertje kernel: [ 89.270416] [<ffffffff81472de6>] debug_dma_map_page+0x126/0x150
>> Jan 26 11:36:26 serveerstertje kernel: [ 89.280840] [<ffffffff81714686>] rtl8169_start_xmit+0x216/0xa20
> [r8169 and xen stuff]
>
> Dan, I miss the part of the debug code that tells where the mappings were
> previously set.
In this case it was a facepalm mistake on my part. The mappings were
not being properly accounted in the last revision of the patch I sent.
I copied you on the fix [1].
--
Dan
[1]: http://marc.info/?l=linux-netdev&m=139096447627032&w=2
^ permalink raw reply
* Re: [PATCH 3/3] net: via-rhine: add OF bus binding
From: Tony Prisk @ 2014-01-29 3:44 UTC (permalink / raw)
To: Alexey Charkov, Rob Herring
Cc: netdev, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Roger Luethi,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CABjd4Yxo0Pp+QtTuXhKBT9KdVhUk12x2L8+FBL_ZWmPYopG2JQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 29/01/14 07:27, Alexey Charkov wrote:
> 2014/1/27 Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>> On Mon, Jan 27, 2014 at 5:51 AM, Alexey Charkov <alchark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> This should make the driver usable with VIA/WonderMedia ARM-based
>>> Systems-on-Chip integrated Rhine III adapters. Note that these
>>> are always in MMIO mode, and don't have any known EEPROM.
>>>
>>> Signed-off-by: Alexey Charkov <alchark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> Signed-off-by: Roger Luethi <rl-7uj+XXdSDtwfv37vnLkPlQ@public.gmane.org>
>>> ---
>>> .../devicetree/bindings/net/via-rhine.txt | 18 ++
>>> drivers/net/ethernet/via/Kconfig | 2 +-
>>> drivers/net/ethernet/via/via-rhine.c | 293 +++++++++++++--------
>>> 3 files changed, 200 insertions(+), 113 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/net/via-rhine.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/via-rhine.txt b/Documentation/devicetree/bindings/net/via-rhine.txt
>>> new file mode 100644
>>> index 0000000..684dd3a
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/net/via-rhine.txt
>>> @@ -0,0 +1,18 @@
>>> +* VIA Rhine 10/100 Network Controller
>>> +
>>> +Required properties:
>>> +- compatible : Should be "via,rhine"
>> This should be more specific rather than...
>>
>>> +- reg : Address and length of the io space
>>> +- interrupts : Should contain the controller interrupt line
>>> +- rhine,revision : Rhine core revision, used to inform the
>>> + driver of quirks and capabilities to expect from
>>> + the device. Mimics the respective PCI attribute.
>> having this property. The OF match table can then have the quirks set
>> based on compatible strings.
> Sounds fair. Do you think something like the following would fly?
>
> Required properties:
> - compatible : Should be "via,rhine-soc-vt8500" for integrated Rhine
> cores found in SoC's such as VIA VT8500, WonderMedia WM8950 and
> possibly others. These are listed as 1106:3106 rev. 0x84 on the
> virtual PCI bus under vendor-provided kernels.
Does it need a special name? I would have assumed they are using their
own IP for the VT6105 or VT6106S.
Then you can use it to add quirks later on if needed.
Regards
Tony Prisk
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: Re: [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Chen-Yu Tsai @ 2014-01-29 4:01 UTC (permalink / raw)
To: linux-sunxi
Cc: Johannes Berg, David S. Miller, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-wireless
In-Reply-To: <20140127142400.GI3867@lukather>
Hi,
On Mon, Jan 27, 2014 at 10:24 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi,
>
> On Fri, Jan 17, 2014 at 02:47:29PM +0800, Chen-Yu Tsai wrote:
>> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>> ---
>> .../devicetree/bindings/rfkill/rfkill-gpio.txt | 26 ++++++++++++++++++++++
>> net/rfkill/rfkill-gpio.c | 23 +++++++++++++++++++
>> 2 files changed, 49 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
>>
>> diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
>> new file mode 100644
>> index 0000000..8a07ea4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
>> @@ -0,0 +1,26 @@
>> +GPIO controlled RFKILL devices
>> +
>> +Required properties:
>> +- compatible : Must be "rfkill-gpio".
>> +- rfkill-name : Name of RFKILL device
>> +- rfkill-type : Type of RFKILL device: 1 for WiFi, 2 for BlueTooth
>> +- NAME_shutdown-gpios : GPIO phandle to shutdown control
>> + (phandle must be the second)
>
> Can't it be handled by a regulator?
>
>> +- NAME_reset-gpios : GPIO phandle to reset control
>
> And this one using the reset framework?
The driver is already used in platform device and ACPI fashions.
AFAIK, ACPI only passes the GPIO lines. Preferably the behavior
and requirements between the different usages remain the same.
Cheers
ChenYu
^ permalink raw reply
* Re: Help testing for USB ethernet/xHCI regression
From: Mark Lord @ 2014-01-29 4:30 UTC (permalink / raw)
To: Sarah Sharp; +Cc: Greg Kroah-Hartman, linux-usb, netdev, David Laight
In-Reply-To: <20140128203007.GA3311@xanatos>
[-- Attachment #1: Type: text/plain, Size: 687 bytes --]
On 14-01-28 03:30 PM, Sarah Sharp wrote:
..
> Can you please pull this branch, which contains a 3.13 kernel with
> David's patch reverted, and test whether your USB ethernet device works
> or fails?
Fails. dmesg log attached.
All I do is something akin to this:
mount /server/ /x
mount --bind / /t
mirrordir -v --strict-mtimes /t /x/backups/empress
"mirrordir" is similar to "rsync", but less cryptic.
The sequence above maintains a clone of the root filesystem
of my ultrabook ("empress") on an NFS server over GigE.
> Also, please double check to see if vanilla 3.13 works or fails.
Okay, will try that before bed.
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
[-- Attachment #2: log.gz --]
[-- Type: application/x-gzip, Size: 9359 bytes --]
^ permalink raw reply
* Re: Help testing for USB ethernet/xHCI regression
From: Mark Lord @ 2014-01-29 4:54 UTC (permalink / raw)
To: Sarah Sharp; +Cc: Greg Kroah-Hartman, linux-usb, netdev, David Laight
In-Reply-To: <52E883FB.7010704@pobox.com>
On 14-01-28 11:30 PM, Mark Lord wrote:
> On 14-01-28 03:30 PM, Sarah Sharp wrote:
> ..
>> Can you please pull this branch, which contains a 3.13 kernel with
>> David's patch reverted, and test whether your USB ethernet device works
>> or fails?
>
> Fails. dmesg log attached.
> All I do is something akin to this:
>
> mount /server/ /x
> mount --bind / /t
> mirrordir -v --strict-mtimes /t /x/backups/empress
>
> "mirrordir" is similar to "rsync", but less cryptic.
> The sequence above maintains a clone of the root filesystem
> of my ultrabook ("empress") on an NFS server over GigE.
>
>> Also, please double check to see if vanilla 3.13 works or fails.
>
> Okay, will try that before bed.
Vanilla 3.13 does not appear to have the USB3 ethernet lockup issue,
and even USB3 hot-plug appears to be working again (was not working in 3.13-rc4).
Cheers
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply
* Re: [PATCH 3/3] net: via-rhine: add OF bus binding
From: Alexey Charkov @ 2014-01-29 5:20 UTC (permalink / raw)
To: Tony Prisk
Cc: Rob Herring, netdev,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Roger Luethi,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <52E87929.30708-ci5G2KO2hbZ+pU9mqzGVBQ@public.gmane.org>
2014/1/29 Tony Prisk <linux-ci5G2KO2hbZ+pU9mqzGVBQ@public.gmane.org>:
> On 29/01/14 07:27, Alexey Charkov wrote:
>>
>> 2014/1/27 Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>>
>>> On Mon, Jan 27, 2014 at 5:51 AM, Alexey Charkov <alchark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> wrote:
>>>>
>>>> This should make the driver usable with VIA/WonderMedia ARM-based
>>>> Systems-on-Chip integrated Rhine III adapters. Note that these
>>>> are always in MMIO mode, and don't have any known EEPROM.
>>>>
>>>> Signed-off-by: Alexey Charkov <alchark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> Signed-off-by: Roger Luethi <rl-7uj+XXdSDtwfv37vnLkPlQ@public.gmane.org>
>>>> ---
>>>> .../devicetree/bindings/net/via-rhine.txt | 18 ++
>>>> drivers/net/ethernet/via/Kconfig | 2 +-
>>>> drivers/net/ethernet/via/via-rhine.c | 293
>>>> +++++++++++++--------
>>>> 3 files changed, 200 insertions(+), 113 deletions(-)
>>>> create mode 100644 Documentation/devicetree/bindings/net/via-rhine.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/net/via-rhine.txt
>>>> b/Documentation/devicetree/bindings/net/via-rhine.txt
>>>> new file mode 100644
>>>> index 0000000..684dd3a
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/net/via-rhine.txt
>>>> @@ -0,0 +1,18 @@
>>>> +* VIA Rhine 10/100 Network Controller
>>>> +
>>>> +Required properties:
>>>> +- compatible : Should be "via,rhine"
>>>
>>> This should be more specific rather than...
>>>
>>>> +- reg : Address and length of the io space
>>>> +- interrupts : Should contain the controller interrupt line
>>>> +- rhine,revision : Rhine core revision, used to inform the
>>>> + driver of quirks and capabilities to expect from
>>>> + the device. Mimics the respective PCI attribute.
>>>
>>> having this property. The OF match table can then have the quirks set
>>> based on compatible strings.
>>
>> Sounds fair. Do you think something like the following would fly?
>>
>> Required properties:
>> - compatible : Should be "via,rhine-soc-vt8500" for integrated Rhine
>> cores found in SoC's such as VIA VT8500, WonderMedia WM8950 and
>> possibly others. These are listed as 1106:3106 rev. 0x84 on the
>> virtual PCI bus under vendor-provided kernels.
>
> Does it need a special name? I would have assumed they are using their own
> IP for the VT6105 or VT6106S.
> Then you can use it to add quirks later on if needed.
The problem is that I have no reliable source for the exact name of
the IP block. The lookup table within the driver says that rev. 0x83
is VT6105_B0, and rev. 0x8A is VT6105L (and it doesn't contain any
entry for 0x84, so our case gets treated as 0x83 currently).
If we only differentiate them by the compatible string, I would be
reluctant to call it vt6105 or vt6106 or whatever else without knowing
for sure. Otherwise, if at some point we need to add any quirks
specific to rev. 0x84, we wouldn't be able to do that without
side-effects.
Thoughts welcome :)
Thanks,
Alexey
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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] tun: add device name(iff) field to proc fdinfo entry
From: Masatake YAMATO @ 2014-01-29 5:33 UTC (permalink / raw)
To: davem; +Cc: netdev, yamato
In-Reply-To: <20140128.180819.623844973390653379.davem@davemloft.net>
A file descriptor opened for /dev/net/tun and a tun device are
connected with ioctl. Though understanding the connection is
important for trouble shooting, no way is given to a user to know
the connected device for a given file descriptor at userland.
This patch adds a new fdinfo field for the device name connected to
a file descriptor opened for /dev/net/tun.
Here is an example of the field:
# lsof | grep tun
qemu-syst 4565 qemu 25u CHR 10,200 0t138 12921 /dev/net/tun
...
# cat /proc/4565/fdinfo/25
pos: 138
flags: 0104002
iff: vnet0
# ip link show dev vnet0
8: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
changelog:
(v2): indent iff just like the other fdinfo fields are.
Suggested by David Miller <davem@davemloft.net>.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
drivers/net/tun.c | 28 +++++++++++++++++++++++++++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index bcf01af..8651c31 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -69,6 +69,7 @@
#include <net/netns/generic.h>
#include <net/rtnetlink.h>
#include <net/sock.h>
+#include <linux/seq_file.h>
#include <asm/uaccess.h>
@@ -2228,6 +2229,28 @@ static int tun_chr_close(struct inode *inode, struct file *file)
return 0;
}
+#ifdef CONFIG_PROC_FS
+static int tun_chr_show_fdinfo(struct seq_file *m, struct file *f)
+{
+ struct tun_struct *tun;
+ struct ifreq ifr;
+ int ret;
+
+ memset(&ifr, 0, sizeof(ifr));
+
+ rtnl_lock();
+ tun = tun_get(f);
+ if (tun)
+ tun_get_iff(current->nsproxy->net_ns, tun, &ifr);
+ rtnl_unlock();
+
+ if (tun)
+ tun_put(tun);
+
+ return seq_printf(m, "iff:\t%s\n", ifr.ifr_name);
+}
+#endif
+
static const struct file_operations tun_fops = {
.owner = THIS_MODULE,
.llseek = no_llseek,
@@ -2242,7 +2265,10 @@ static const struct file_operations tun_fops = {
#endif
.open = tun_chr_open,
.release = tun_chr_close,
- .fasync = tun_chr_fasync
+ .fasync = tun_chr_fasync,
+#ifdef CONFIG_PROC_FS
+ .show_fdinfo = tun_chr_show_fdinfo,
+#endif
};
static struct miscdevice tun_miscdev = {
--
1.8.5.3
^ permalink raw reply related
* [PATCH v2 0/4]
From: Max Filippov @ 2014-01-29 6:00 UTC (permalink / raw)
To: linux-xtensa, netdev, linux-kernel
Cc: Chris Zankel, Marc Gauthier, David S. Miller, Ben Hutchings,
Florian Fainelli, Max Filippov
Hello David, Ben, Florian, Chris and everybody,
this series improves ethoc behavior in gigabit environment:
- first patch introduces two phylib setters for 'advertising' and 'supported'
fields of struct phy_device;
- second patch disables gigabit advertisement in the attached PHY making
possible to use gigabit link without any additional setup;
- third patch adds support to set up MII management bus frequency, adding
new fields to platform data and to OF bindings;
- fourth patch adds basic ethtool support to ethoc driver.
These changes allow to use KC-705 board with 50MHz xtensa core and OpenCores
10/100 Mbps MAC connected to gigabit network without any additional setup.
Changes v1->v2:
- new patch "phy: provide accessors for 'advertising' and 'supported' fields";
- disable both gigabit advertisement and support;
- drop MDIO bus frequency configurability, always configure for standard
2.5MHz;
- allow using common clock framework to provide ethoc clock;
- new patch: "net: ethoc: implement ethtool operations";
- drop device tree bindings documentation patch until common bindings format
for network drivers is decided.
Max Filippov (4):
phy: provide accessors for 'advertising' and 'supported' fields
net: ethoc: don't advertise gigabit speed on attached PHY
net: ethoc: set up MII management bus clock
net: ethoc: implement ethtool operations
drivers/net/ethernet/ethoc.c | 130 ++++++++++++++++++++++++++++++++++++++++++-
include/linux/phy.h | 12 ++++
include/net/ethoc.h | 1 +
3 files changed, 141 insertions(+), 2 deletions(-)
--
1.8.1.4
^ permalink raw reply
* [PATCH v2 1/4] phy: provide accessors for 'advertising' and 'supported' fields
From: Max Filippov @ 2014-01-29 6:00 UTC (permalink / raw)
To: linux-xtensa, netdev, linux-kernel
Cc: Chris Zankel, Marc Gauthier, David S. Miller, Ben Hutchings,
Florian Fainelli, Max Filippov
In-Reply-To: <1390975218-13863-1-git-send-email-jcmvbkbc@gmail.com>
Many network drivers directly modify phy_device::advertising and
phy_device::supported. Provide accessors to these fields to better
isolate phylib from its users.
Suggested-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
Changes v1->v2:
- new patch
include/linux/phy.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 48a4dc3..2ae58f8 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -559,6 +559,18 @@ static inline int phy_read_status(struct phy_device *phydev) {
return phydev->drv->read_status(phydev);
}
+static inline void phy_update_advert(struct phy_device *phydev, u32 clear,
+ u32 set)
+{
+ phydev->advertising = (phydev->advertising & ~clear) | set;
+}
+
+static inline void phy_update_supported(struct phy_device *phydev, u32 clear,
+ u32 set)
+{
+ phydev->supported = (phydev->supported & ~clear) | set;
+}
+
int genphy_setup_forced(struct phy_device *phydev);
int genphy_restart_aneg(struct phy_device *phydev);
int genphy_config_aneg(struct phy_device *phydev);
--
1.8.1.4
^ permalink raw reply related
* [PATCH v2 2/4] net: ethoc: don't advertise gigabit speed on attached PHY
From: Max Filippov @ 2014-01-29 6:00 UTC (permalink / raw)
To: linux-xtensa, netdev, linux-kernel
Cc: Chris Zankel, Marc Gauthier, David S. Miller, Ben Hutchings,
Florian Fainelli, Max Filippov
In-Reply-To: <1390975218-13863-1-git-send-email-jcmvbkbc@gmail.com>
OpenCores 10/100 Mbps MAC does not support speeds above 100 Mbps, but does
not disable advertisement when PHY supports them. This results in
non-functioning network when the MAC is connected to a gigabit PHY connected
to a gigabit switch.
The fix is to disable gigabit speed advertisement on attached PHY
unconditionally.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
Changes v1->v2:
- disable both gigabit advertisement and support.
drivers/net/ethernet/ethoc.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
index 4de8cfd..5643b2d 100644
--- a/drivers/net/ethernet/ethoc.c
+++ b/drivers/net/ethernet/ethoc.c
@@ -688,6 +688,14 @@ static int ethoc_mdio_probe(struct net_device *dev)
}
priv->phy = phy;
+ phy_update_advert(phy,
+ ADVERTISED_1000baseT_Full |
+ ADVERTISED_1000baseT_Half, 0);
+ phy_start_aneg(phy);
+ phy_update_supported(phy,
+ SUPPORTED_1000baseT_Full |
+ SUPPORTED_1000baseT_Half, 0);
+
return 0;
}
--
1.8.1.4
^ permalink raw reply related
* [PATCH v2 3/4] net: ethoc: set up MII management bus clock
From: Max Filippov @ 2014-01-29 6:00 UTC (permalink / raw)
To: linux-xtensa, netdev, linux-kernel
Cc: Chris Zankel, Marc Gauthier, David S. Miller, Ben Hutchings,
Florian Fainelli, Max Filippov
In-Reply-To: <1390975218-13863-1-git-send-email-jcmvbkbc@gmail.com>
MII management bus clock is derived from the MAC clock by dividing it by
MIIMODER register CLKDIV field value. This value may need to be set up
in case it is undefined or its default value is too high (and
communication with PHY is too slow) or too low (and communication with
PHY is impossible). The value of CLKDIV is not specified directly, but
is derived from the MAC clock for the default MII management bus frequency
of 2.5MHz. The MAC clock may be specified in the platform data, or as
either 'clock-frequency' or 'clocks' device tree attribute.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
Changes v1->v2:
- drop MDIO bus frequency configurability, always configure for standard
2.5MHz;
- allow using common clock framework to provide ethoc clock.
drivers/net/ethernet/ethoc.c | 37 +++++++++++++++++++++++++++++++++++--
include/net/ethoc.h | 1 +
2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
index 5643b2d..5854d41 100644
--- a/drivers/net/ethernet/ethoc.c
+++ b/drivers/net/ethernet/ethoc.c
@@ -13,6 +13,7 @@
#include <linux/dma-mapping.h>
#include <linux/etherdevice.h>
+#include <linux/clk.h>
#include <linux/crc32.h>
#include <linux/interrupt.h>
#include <linux/io.h>
@@ -216,6 +217,7 @@ struct ethoc {
struct phy_device *phy;
struct mii_bus *mdio;
+ struct clk *clk;
s8 phy_id;
};
@@ -925,6 +927,8 @@ static int ethoc_probe(struct platform_device *pdev)
int num_bd;
int ret = 0;
bool random_mac = false;
+ u32 eth_clkfreq = 0;
+ struct ethoc_platform_data *pdata = dev_get_platdata(&pdev->dev);
/* allocate networking device */
netdev = alloc_etherdev(sizeof(struct ethoc));
@@ -1038,8 +1042,7 @@ static int ethoc_probe(struct platform_device *pdev)
}
/* Allow the platform setup code to pass in a MAC address. */
- if (dev_get_platdata(&pdev->dev)) {
- struct ethoc_platform_data *pdata = dev_get_platdata(&pdev->dev);
+ if (pdata) {
memcpy(netdev->dev_addr, pdata->hwaddr, IFHWADDRLEN);
priv->phy_id = pdata->phy_id;
} else {
@@ -1077,6 +1080,32 @@ static int ethoc_probe(struct platform_device *pdev)
if (random_mac)
netdev->addr_assign_type = NET_ADDR_RANDOM;
+ /* Allow the platform setup code to adjust MII management bus clock. */
+ if (pdata)
+ eth_clkfreq = pdata->eth_clkfreq;
+ else
+ of_property_read_u32(pdev->dev.of_node,
+ "clock-frequency", ð_clkfreq);
+ if (!eth_clkfreq) {
+ struct clk *clk = clk_get(&pdev->dev, NULL);
+
+ if (!IS_ERR(clk)) {
+ priv->clk = clk;
+ clk_prepare_enable(clk);
+ eth_clkfreq = clk_get_rate(clk);
+ }
+ }
+ if (eth_clkfreq) {
+ u32 clkdiv = MIIMODER_CLKDIV(eth_clkfreq / 2500000 + 1);
+
+ if (!clkdiv)
+ clkdiv = 2;
+ dev_dbg(&pdev->dev, "setting MII clkdiv to %u\n", clkdiv);
+ ethoc_write(priv, MIIMODER,
+ (ethoc_read(priv, MIIMODER) & MIIMODER_NOPRE) |
+ clkdiv);
+ }
+
/* register MII bus */
priv->mdio = mdiobus_alloc();
if (!priv->mdio) {
@@ -1141,6 +1170,8 @@ free_mdio:
kfree(priv->mdio->irq);
mdiobus_free(priv->mdio);
free:
+ if (priv->clk)
+ clk_disable_unprepare(priv->clk);
free_netdev(netdev);
out:
return ret;
@@ -1165,6 +1196,8 @@ static int ethoc_remove(struct platform_device *pdev)
kfree(priv->mdio->irq);
mdiobus_free(priv->mdio);
}
+ if (priv->clk)
+ clk_disable_unprepare(priv->clk);
unregister_netdev(netdev);
free_netdev(netdev);
}
diff --git a/include/net/ethoc.h b/include/net/ethoc.h
index 96f3789..2a2d6bb 100644
--- a/include/net/ethoc.h
+++ b/include/net/ethoc.h
@@ -16,6 +16,7 @@
struct ethoc_platform_data {
u8 hwaddr[IFHWADDRLEN];
s8 phy_id;
+ u32 eth_clkfreq;
};
#endif /* !LINUX_NET_ETHOC_H */
--
1.8.1.4
^ permalink raw reply related
* [PATCH v2 4/4] net: ethoc: implement ethtool operations
From: Max Filippov @ 2014-01-29 6:00 UTC (permalink / raw)
To: linux-xtensa, netdev, linux-kernel
Cc: Chris Zankel, Marc Gauthier, David S. Miller, Ben Hutchings,
Florian Fainelli, Max Filippov
In-Reply-To: <1390975218-13863-1-git-send-email-jcmvbkbc@gmail.com>
The following methods are implemented:
- get/set settings;
- get registers length/registers;
- get link state (standard implementation);
- get/set ring parameters;
- get timestamping info (standard implementation).
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
Changes v1->v2:
- new patch.
drivers/net/ethernet/ethoc.c | 85 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 85 insertions(+)
diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
index 5854d41..2f8b174 100644
--- a/drivers/net/ethernet/ethoc.c
+++ b/drivers/net/ethernet/ethoc.c
@@ -52,6 +52,7 @@ MODULE_PARM_DESC(buffer_size, "DMA buffer allocation size");
#define ETH_HASH0 0x48
#define ETH_HASH1 0x4c
#define ETH_TXCTRL 0x50
+#define ETH_END 0x54
/* mode register */
#define MODER_RXEN (1 << 0) /* receive enable */
@@ -180,6 +181,7 @@ MODULE_PARM_DESC(buffer_size, "DMA buffer allocation size");
* @membase: pointer to buffer memory region
* @dma_alloc: dma allocated buffer size
* @io_region_size: I/O memory region size
+ * @num_bd: number of buffer descriptors
* @num_tx: number of send buffers
* @cur_tx: last send buffer written
* @dty_tx: last buffer actually sent
@@ -200,6 +202,7 @@ struct ethoc {
int dma_alloc;
resource_size_t io_region_size;
+ unsigned int num_bd;
unsigned int num_tx;
unsigned int cur_tx;
unsigned int dty_tx;
@@ -900,6 +903,86 @@ out:
return NETDEV_TX_OK;
}
+static int ethoc_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+ struct ethoc *priv = netdev_priv(dev);
+ struct phy_device *phydev = priv->phy;
+
+ if (!phydev)
+ return -ENODEV;
+
+ return phy_ethtool_gset(phydev, cmd);
+}
+
+static int ethoc_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+ struct ethoc *priv = netdev_priv(dev);
+ struct phy_device *phydev = priv->phy;
+
+ if (!phydev)
+ return -ENODEV;
+
+ return phy_ethtool_sset(phydev, cmd);
+}
+
+static int ethoc_get_regs_len(struct net_device *netdev)
+{
+ return ETH_END;
+}
+
+static void ethoc_get_regs(struct net_device *dev, struct ethtool_regs *regs,
+ void *p)
+{
+ struct ethoc *priv = netdev_priv(dev);
+ u32 *regs_buff = p;
+ unsigned i;
+
+ regs->version = 0;
+ for (i = 0; i < ETH_END / sizeof(u32); ++i)
+ regs_buff[i] = ethoc_read(priv, i * sizeof(u32));
+}
+
+static void ethoc_get_ringparam(struct net_device *dev,
+ struct ethtool_ringparam *ring)
+{
+ struct ethoc *priv = netdev_priv(dev);
+
+ ring->rx_max_pending = priv->num_bd;
+ ring->rx_mini_max_pending = 0;
+ ring->rx_jumbo_max_pending = 0;
+ ring->tx_max_pending = priv->num_bd;
+
+ ring->rx_pending = priv->num_rx;
+ ring->rx_mini_pending = 0;
+ ring->rx_jumbo_pending = 0;
+ ring->tx_pending = priv->num_tx;
+}
+
+static int ethoc_set_ringparam(struct net_device *dev,
+ struct ethtool_ringparam *ring)
+{
+ struct ethoc *priv = netdev_priv(dev);
+
+ if (netif_running(dev))
+ return -EBUSY;
+ priv->num_tx = rounddown_pow_of_two(ring->tx_pending);
+ priv->num_rx = priv->num_bd - priv->num_tx;
+ if (priv->num_rx > ring->rx_pending)
+ priv->num_rx = ring->rx_pending;
+ return 0;
+}
+
+const struct ethtool_ops ethoc_ethtool_ops = {
+ .get_settings = ethoc_get_settings,
+ .set_settings = ethoc_set_settings,
+ .get_regs_len = ethoc_get_regs_len,
+ .get_regs = ethoc_get_regs,
+ .get_link = ethtool_op_get_link,
+ .get_ringparam = ethoc_get_ringparam,
+ .set_ringparam = ethoc_set_ringparam,
+ .get_ts_info = ethtool_op_get_ts_info,
+};
+
static const struct net_device_ops ethoc_netdev_ops = {
.ndo_open = ethoc_open,
.ndo_stop = ethoc_stop,
@@ -1028,6 +1111,7 @@ static int ethoc_probe(struct platform_device *pdev)
ret = -ENODEV;
goto error;
}
+ priv->num_bd = num_bd;
/* num_tx must be a power of two */
priv->num_tx = rounddown_pow_of_two(num_bd >> 1);
priv->num_rx = num_bd - priv->num_tx;
@@ -1148,6 +1232,7 @@ static int ethoc_probe(struct platform_device *pdev)
netdev->netdev_ops = ðoc_netdev_ops;
netdev->watchdog_timeo = ETHOC_TIMEOUT;
netdev->features |= 0;
+ netdev->ethtool_ops = ðoc_ethtool_ops;
/* setup NAPI */
netif_napi_add(netdev, &priv->napi, ethoc_poll, 64);
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH v2 0/4] OpenCores 10/100 MAC fixes for gigabit environment
From: Max Filippov @ 2014-01-29 6:17 UTC (permalink / raw)
To: linux-xtensa@linux-xtensa.org, netdev, LKML
Cc: Chris Zankel, Marc Gauthier, David S. Miller, Ben Hutchings,
Florian Fainelli, Max Filippov
Fixed the subject.
On Wed, Jan 29, 2014 at 10:00 AM, Max Filippov <jcmvbkbc@gmail.com> wrote:
> Hello David, Ben, Florian, Chris and everybody,
>
> this series improves ethoc behavior in gigabit environment:
> - first patch introduces two phylib setters for 'advertising' and 'supported'
> fields of struct phy_device;
> - second patch disables gigabit advertisement in the attached PHY making
> possible to use gigabit link without any additional setup;
> - third patch adds support to set up MII management bus frequency, adding
> new fields to platform data and to OF bindings;
> - fourth patch adds basic ethtool support to ethoc driver.
>
> These changes allow to use KC-705 board with 50MHz xtensa core and OpenCores
> 10/100 Mbps MAC connected to gigabit network without any additional setup.
>
> Changes v1->v2:
> - new patch "phy: provide accessors for 'advertising' and 'supported' fields";
> - disable both gigabit advertisement and support;
> - drop MDIO bus frequency configurability, always configure for standard
> 2.5MHz;
> - allow using common clock framework to provide ethoc clock;
> - new patch: "net: ethoc: implement ethtool operations";
> - drop device tree bindings documentation patch until common bindings format
> for network drivers is decided.
>
> Max Filippov (4):
> phy: provide accessors for 'advertising' and 'supported' fields
> net: ethoc: don't advertise gigabit speed on attached PHY
> net: ethoc: set up MII management bus clock
> net: ethoc: implement ethtool operations
>
> drivers/net/ethernet/ethoc.c | 130 ++++++++++++++++++++++++++++++++++++++++++-
> include/linux/phy.h | 12 ++++
> include/net/ethoc.h | 1 +
> 3 files changed, 141 insertions(+), 2 deletions(-)
>
> --
> 1.8.1.4
--
Thanks.
-- Max
^ permalink raw reply
* [PATCH] ipv6: default route for link local address is not added while assigning a address
From: Sohny Thomas @ 2014-01-29 6:41 UTC (permalink / raw)
To: netdev, linux-kernel, yoshfuji, Nicolas Dichtel, davem, kumuda
Resending this on netdev mailing list:
Default route for link local address is configured automatically if
NETWORKING_IPV6=yes is in ifcfg-eth*.
When the route table for the interface is flushed and a new address is
added to the same device with out removing linklocal addr, default route
for link local address has to added by default.
I have found the issue to be caused by this checkin
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/net/ipv6?id=62b54dd91567686a1cb118f76a72d5f4764a86dd
According to this change :
He removes adding a link local route if any other address is added ,
applicable across all interfaces though there's mentioned only lo interface
So below patch fixes for other devices
Signed-off-by: Sohny THomas <sohthoma@linux.vnet.ibm.com>
-----
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index f62c72b..a8a4df9 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1763,6 +1763,16 @@ static int addrconf_ifid_infiniband(u8 *eui,
struct net_device *dev)
return 0;
}
+static void addrconf_add_lroute(struct net_device *dev)
+{
+ struct in6_addr addr;
+
+ ipv6_addr_set(&addr, htonl(0xFE800000), 0, 0, 0);
+ addrconf_prefix_route(&addr, 64, dev, 0, 0);
+}
+
+
+
static int __ipv6_isatap_ifid(u8 *eui, __be32 addr)
{
if (addr == 0)
@@ -2010,8 +2020,10 @@ static struct inet6_dev *addrconf_add_dev(struct
net_device *dev)
return ERR_PTR(-EACCES);
/* Add default multicast route */
- if (!(dev->flags & IFF_LOOPBACK))
+ if (!(dev->flags & IFF_LOOPBACK)){
addrconf_add_mroute(dev);
+ addrconf_add_lroute(dev);
+ }
return idev;
}
^ permalink raw reply related
* Re: [PATCH v2 2/4] net: ethoc: don't advertise gigabit speed on attached PHY
From: Florian Fainelli @ 2014-01-29 6:47 UTC (permalink / raw)
To: Max Filippov, linux-xtensa, netdev, linux-kernel
Cc: Chris Zankel, Marc Gauthier, David S. Miller, Ben Hutchings
In-Reply-To: <1390975218-13863-3-git-send-email-jcmvbkbc@gmail.com>
Hi Max,
Le 28/01/2014 22:00, Max Filippov a écrit :
> OpenCores 10/100 Mbps MAC does not support speeds above 100 Mbps, but does
> not disable advertisement when PHY supports them. This results in
> non-functioning network when the MAC is connected to a gigabit PHY connected
> to a gigabit switch.
>
> The fix is to disable gigabit speed advertisement on attached PHY
> unconditionally.
>
> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
> ---
> Changes v1->v2:
> - disable both gigabit advertisement and support.
>
> drivers/net/ethernet/ethoc.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
> index 4de8cfd..5643b2d 100644
> --- a/drivers/net/ethernet/ethoc.c
> +++ b/drivers/net/ethernet/ethoc.c
> @@ -688,6 +688,14 @@ static int ethoc_mdio_probe(struct net_device *dev)
> }
>
> priv->phy = phy;
> + phy_update_advert(phy,
> + ADVERTISED_1000baseT_Full |
> + ADVERTISED_1000baseT_Half, 0);
> + phy_start_aneg(phy);
This does not look necessary, you should not have to call
phy_start_aneg() because the PHY state machine is not yet started, at
best this calls does nothing.
> + phy_update_supported(phy,
> + SUPPORTED_1000baseT_Full |
> + SUPPORTED_1000baseT_Half, 0);
> +
> return 0;
> }
>
>
^ permalink raw reply
* Re: [PATCH v2 4/4] net: ethoc: implement ethtool operations
From: Florian Fainelli @ 2014-01-29 6:52 UTC (permalink / raw)
To: Max Filippov, linux-xtensa, netdev, linux-kernel
Cc: Chris Zankel, Marc Gauthier, David S. Miller, Ben Hutchings
In-Reply-To: <1390975218-13863-5-git-send-email-jcmvbkbc@gmail.com>
Le 28/01/2014 22:00, Max Filippov a écrit :
> The following methods are implemented:
> - get/set settings;
> - get registers length/registers;
> - get link state (standard implementation);
> - get/set ring parameters;
> - get timestamping info (standard implementation).
Ideally you should have one patch per ethtool callback that you
implement just in case something happens to break, only the specific
patch can reverted/referenced.
>
> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
> ---
> Changes v1->v2:
> - new patch.
>
> drivers/net/ethernet/ethoc.c | 85 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 85 insertions(+)
>
> diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
> index 5854d41..2f8b174 100644
> --- a/drivers/net/ethernet/ethoc.c
> +++ b/drivers/net/ethernet/ethoc.c
> @@ -52,6 +52,7 @@ MODULE_PARM_DESC(buffer_size, "DMA buffer allocation size");
> #define ETH_HASH0 0x48
> #define ETH_HASH1 0x4c
> #define ETH_TXCTRL 0x50
> +#define ETH_END 0x54
>
> /* mode register */
> #define MODER_RXEN (1 << 0) /* receive enable */
> @@ -180,6 +181,7 @@ MODULE_PARM_DESC(buffer_size, "DMA buffer allocation size");
> * @membase: pointer to buffer memory region
> * @dma_alloc: dma allocated buffer size
> * @io_region_size: I/O memory region size
> + * @num_bd: number of buffer descriptors
> * @num_tx: number of send buffers
> * @cur_tx: last send buffer written
> * @dty_tx: last buffer actually sent
> @@ -200,6 +202,7 @@ struct ethoc {
> int dma_alloc;
> resource_size_t io_region_size;
>
> + unsigned int num_bd;
> unsigned int num_tx;
> unsigned int cur_tx;
> unsigned int dty_tx;
> @@ -900,6 +903,86 @@ out:
> return NETDEV_TX_OK;
> }
>
> +static int ethoc_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
> +{
> + struct ethoc *priv = netdev_priv(dev);
> + struct phy_device *phydev = priv->phy;
> +
> + if (!phydev)
> + return -ENODEV;
> +
> + return phy_ethtool_gset(phydev, cmd);
> +}
> +
> +static int ethoc_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
> +{
> + struct ethoc *priv = netdev_priv(dev);
> + struct phy_device *phydev = priv->phy;
> +
> + if (!phydev)
> + return -ENODEV;
> +
> + return phy_ethtool_sset(phydev, cmd);
> +}
> +
> +static int ethoc_get_regs_len(struct net_device *netdev)
> +{
> + return ETH_END;
> +}
> +
> +static void ethoc_get_regs(struct net_device *dev, struct ethtool_regs *regs,
> + void *p)
> +{
> + struct ethoc *priv = netdev_priv(dev);
> + u32 *regs_buff = p;
> + unsigned i;
> +
> + regs->version = 0;
> + for (i = 0; i < ETH_END / sizeof(u32); ++i)
> + regs_buff[i] = ethoc_read(priv, i * sizeof(u32));
> +}
> +
> +static void ethoc_get_ringparam(struct net_device *dev,
> + struct ethtool_ringparam *ring)
> +{
> + struct ethoc *priv = netdev_priv(dev);
> +
> + ring->rx_max_pending = priv->num_bd;
> + ring->rx_mini_max_pending = 0;
> + ring->rx_jumbo_max_pending = 0;
> + ring->tx_max_pending = priv->num_bd;
> +
> + ring->rx_pending = priv->num_rx;
> + ring->rx_mini_pending = 0;
> + ring->rx_jumbo_pending = 0;
> + ring->tx_pending = priv->num_tx;
> +}
> +
> +static int ethoc_set_ringparam(struct net_device *dev,
> + struct ethtool_ringparam *ring)
> +{
> + struct ethoc *priv = netdev_priv(dev);
> +
> + if (netif_running(dev))
> + return -EBUSY;
> + priv->num_tx = rounddown_pow_of_two(ring->tx_pending);
> + priv->num_rx = priv->num_bd - priv->num_tx;
> + if (priv->num_rx > ring->rx_pending)
> + priv->num_rx = ring->rx_pending;
> + return 0;
> +}
> +
> +const struct ethtool_ops ethoc_ethtool_ops = {
> + .get_settings = ethoc_get_settings,
> + .set_settings = ethoc_set_settings,
> + .get_regs_len = ethoc_get_regs_len,
> + .get_regs = ethoc_get_regs,
> + .get_link = ethtool_op_get_link,
> + .get_ringparam = ethoc_get_ringparam,
> + .set_ringparam = ethoc_set_ringparam,
> + .get_ts_info = ethtool_op_get_ts_info,
> +};
> +
> static const struct net_device_ops ethoc_netdev_ops = {
> .ndo_open = ethoc_open,
> .ndo_stop = ethoc_stop,
> @@ -1028,6 +1111,7 @@ static int ethoc_probe(struct platform_device *pdev)
> ret = -ENODEV;
> goto error;
> }
> + priv->num_bd = num_bd;
> /* num_tx must be a power of two */
> priv->num_tx = rounddown_pow_of_two(num_bd >> 1);
> priv->num_rx = num_bd - priv->num_tx;
> @@ -1148,6 +1232,7 @@ static int ethoc_probe(struct platform_device *pdev)
> netdev->netdev_ops = ðoc_netdev_ops;
> netdev->watchdog_timeo = ETHOC_TIMEOUT;
> netdev->features |= 0;
> + netdev->ethtool_ops = ðoc_ethtool_ops;
>
> /* setup NAPI */
> netif_napi_add(netdev, &priv->napi, ethoc_poll, 64);
>
^ permalink raw reply
* Re: [PATCH v2 2/4] net: ethoc: don't advertise gigabit speed on attached PHY
From: Max Filippov @ 2014-01-29 7:01 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-xtensa@linux-xtensa.org, netdev, LKML, Chris Zankel,
Marc Gauthier, David S. Miller, Ben Hutchings
In-Reply-To: <52E8A407.1020809@gmail.com>
On Wed, Jan 29, 2014 at 10:47 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Hi Max,
>
> Le 28/01/2014 22:00, Max Filippov a écrit :
>
>> OpenCores 10/100 Mbps MAC does not support speeds above 100 Mbps, but does
>> not disable advertisement when PHY supports them. This results in
>> non-functioning network when the MAC is connected to a gigabit PHY
>> connected
>> to a gigabit switch.
>>
>> The fix is to disable gigabit speed advertisement on attached PHY
>> unconditionally.
>>
>> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
>> ---
>> Changes v1->v2:
>> - disable both gigabit advertisement and support.
>>
>> drivers/net/ethernet/ethoc.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
>> index 4de8cfd..5643b2d 100644
>> --- a/drivers/net/ethernet/ethoc.c
>> +++ b/drivers/net/ethernet/ethoc.c
>> @@ -688,6 +688,14 @@ static int ethoc_mdio_probe(struct net_device *dev)
>> }
>>
>> priv->phy = phy;
>> + phy_update_advert(phy,
>> + ADVERTISED_1000baseT_Full |
>> + ADVERTISED_1000baseT_Half, 0);
>> + phy_start_aneg(phy);
>
>
> This does not look necessary, you should not have to call phy_start_aneg()
> because the PHY state machine is not yet started, at best this calls does
> nothing.
This call actually makes the whole thing work, because otherwise once gigabit
support is cleared from the supported mask genphy_config_advert does not
update gigabit advertisement register, leaving it enabled.
>> + phy_update_supported(phy,
>> + SUPPORTED_1000baseT_Full |
>> + SUPPORTED_1000baseT_Half, 0);
>> +
>> return 0;
>> }
>>
>>
>
--
Thanks.
-- Max
^ permalink raw reply
* Re: [PATCH v2 3/4] net: ethoc: set up MII management bus clock
From: Florian Fainelli @ 2014-01-29 7:01 UTC (permalink / raw)
To: Max Filippov, linux-xtensa, netdev, linux-kernel
Cc: Chris Zankel, Marc Gauthier, David S. Miller, Ben Hutchings
In-Reply-To: <1390975218-13863-4-git-send-email-jcmvbkbc@gmail.com>
Le 28/01/2014 22:00, Max Filippov a écrit :
> MII management bus clock is derived from the MAC clock by dividing it by
> MIIMODER register CLKDIV field value. This value may need to be set up
> in case it is undefined or its default value is too high (and
> communication with PHY is too slow) or too low (and communication with
> PHY is impossible). The value of CLKDIV is not specified directly, but
> is derived from the MAC clock for the default MII management bus frequency
> of 2.5MHz. The MAC clock may be specified in the platform data, or as
> either 'clock-frequency' or 'clocks' device tree attribute.
>
> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
> ---
> Changes v1->v2:
> - drop MDIO bus frequency configurability, always configure for standard
> 2.5MHz;
> - allow using common clock framework to provide ethoc clock.
>
> drivers/net/ethernet/ethoc.c | 37 +++++++++++++++++++++++++++++++++++--
> include/net/ethoc.h | 1 +
> 2 files changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
> index 5643b2d..5854d41 100644
> --- a/drivers/net/ethernet/ethoc.c
> +++ b/drivers/net/ethernet/ethoc.c
> @@ -13,6 +13,7 @@
>
> #include <linux/dma-mapping.h>
> #include <linux/etherdevice.h>
> +#include <linux/clk.h>
> #include <linux/crc32.h>
> #include <linux/interrupt.h>
> #include <linux/io.h>
> @@ -216,6 +217,7 @@ struct ethoc {
>
> struct phy_device *phy;
> struct mii_bus *mdio;
> + struct clk *clk;
> s8 phy_id;
> };
>
> @@ -925,6 +927,8 @@ static int ethoc_probe(struct platform_device *pdev)
> int num_bd;
> int ret = 0;
> bool random_mac = false;
> + u32 eth_clkfreq = 0;
> + struct ethoc_platform_data *pdata = dev_get_platdata(&pdev->dev);
>
> /* allocate networking device */
> netdev = alloc_etherdev(sizeof(struct ethoc));
> @@ -1038,8 +1042,7 @@ static int ethoc_probe(struct platform_device *pdev)
> }
>
> /* Allow the platform setup code to pass in a MAC address. */
> - if (dev_get_platdata(&pdev->dev)) {
> - struct ethoc_platform_data *pdata = dev_get_platdata(&pdev->dev);
> + if (pdata) {
> memcpy(netdev->dev_addr, pdata->hwaddr, IFHWADDRLEN);
> priv->phy_id = pdata->phy_id;
> } else {
> @@ -1077,6 +1080,32 @@ static int ethoc_probe(struct platform_device *pdev)
> if (random_mac)
> netdev->addr_assign_type = NET_ADDR_RANDOM;
>
> + /* Allow the platform setup code to adjust MII management bus clock. */
> + if (pdata)
> + eth_clkfreq = pdata->eth_clkfreq;
Since this is a new member, why not make it a struct clk pointer
directly so you could simplify the code path?
> + else
> + of_property_read_u32(pdev->dev.of_node,
> + "clock-frequency", ð_clkfreq);
> + if (!eth_clkfreq) {
> + struct clk *clk = clk_get(&pdev->dev, NULL);
> +
> + if (!IS_ERR(clk)) {
> + priv->clk = clk;
> + clk_prepare_enable(clk);
> + eth_clkfreq = clk_get_rate(clk);
> + }
> + }
> + if (eth_clkfreq) {
> + u32 clkdiv = MIIMODER_CLKDIV(eth_clkfreq / 2500000 + 1);
> +
> + if (!clkdiv)
> + clkdiv = 2;
> + dev_dbg(&pdev->dev, "setting MII clkdiv to %u\n", clkdiv);
> + ethoc_write(priv, MIIMODER,
> + (ethoc_read(priv, MIIMODER) & MIIMODER_NOPRE) |
> + clkdiv);
> + }
This does look a bit convoluted, and it looks like the clk_get() or
getting the clock-frequency property should boil down to being the same
thing with of_clk_get() as it should resolve all clocks phandles and
fetch their frequencies appropriately.
> +
> /* register MII bus */
> priv->mdio = mdiobus_alloc();
> if (!priv->mdio) {
> @@ -1141,6 +1170,8 @@ free_mdio:
> kfree(priv->mdio->irq);
> mdiobus_free(priv->mdio);
> free:
> + if (priv->clk)
> + clk_disable_unprepare(priv->clk);
This should probbaly be if (!IS_ERR(priv-clk)).
> free_netdev(netdev);
> out:
> return ret;
> @@ -1165,6 +1196,8 @@ static int ethoc_remove(struct platform_device *pdev)
> kfree(priv->mdio->irq);
> mdiobus_free(priv->mdio);
> }
> + if (priv->clk)
> + clk_disable_unprepare(priv->clk);
Same here
> unregister_netdev(netdev);
> free_netdev(netdev);
> }
> diff --git a/include/net/ethoc.h b/include/net/ethoc.h
> index 96f3789..2a2d6bb 100644
> --- a/include/net/ethoc.h
> +++ b/include/net/ethoc.h
> @@ -16,6 +16,7 @@
> struct ethoc_platform_data {
> u8 hwaddr[IFHWADDRLEN];
> s8 phy_id;
> + u32 eth_clkfreq;
> };
>
> #endif /* !LINUX_NET_ETHOC_H */
>
^ permalink raw reply
* Re: 8% performance improved by change tap interact with kernel stack
From: Qin Chuanyu @ 2014-01-29 7:12 UTC (permalink / raw)
To: Eric Dumazet
Cc: jasowang, Michael S. Tsirkin, Anthony Liguori, KVM list, netdev,
Peter Klausler
In-Reply-To: <1390920560.28432.8.camel@edumazet-glaptop2.roam.corp.google.com>
On 2014/1/28 22:49, Eric Dumazet wrote:
> On Tue, 2014-01-28 at 16:14 +0800, Qin Chuanyu wrote:
>> according perf test result，I found that there are 5%-8% cpu cost on
>> softirq by use netif_rx_ni called in tun_get_user.
>>
>> so I changed the function which cause skb transmitted more quickly.
>> from
>> tun_get_user ->
>> netif_rx_ni(skb);
>> to
>> tun_get_user ->
>> rcu_read_lock_bh();
>> netif_receive_skb(skb);
>> rcu_read_unlock_bh();
>
> No idea why you use rcu here ?
In my first version, I forgot to add lock when called netif_receive_skb
then I met a dad spinlock when using tcpdump.
tcpdump receive skb in netif_receive_skb but also in dev_queue_xmit.
and I have notice dev_queue_xmit add rcu_read_lock_bh before
transmitting skb, and this lock avoid race between softirq and transmit
thread.
/* Disable soft irqs for various locks below. Also
* stops preemption for RCU.
*/
rcu_read_lock_bh();
Now I try to xmit skb in vhost thread, so I did the same thing.
^ 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