* 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
* Re: [PATCH v2] tun: add device name(iff) field to proc fdinfo entry
From: David Miller @ 2014-01-29 7:19 UTC (permalink / raw)
To: yamato; +Cc: netdev
In-Reply-To: <1390973614-3929-1-git-send-email-yamato@redhat.com>
From: Masatake YAMATO <yamato@redhat.com>
Date: Wed, 29 Jan 2014 14:33:34 +0900
> (v2): indent iff just like the other fdinfo fields are.
> Suggested by David Miller <davem@davemloft.net>.
Please fix the build warnings generated by your changes:
drivers/net/tun.c: In function ‘tun_chr_show_fdinfo’:
drivers/net/tun.c:2237:6: warning: unused variable ‘ret’ [-Wunused-variable]
^ permalink raw reply
* Re: [PATCH stable 3.11+] can: bcm: add skb destructor
From: Andre Naujoks @ 2014-01-29 7:40 UTC (permalink / raw)
To: Eric Dumazet, Oliver Hartkopp; +Cc: David Miller, Linux Netdev List
In-Reply-To: <1390953066.28432.26.camel@edumazet-glaptop2.roam.corp.google.com>
On 29.01.2014 00:51, schrieb Eric Dumazet:
> On Tue, 2014-01-28 at 23:49 +0100, Oliver Hartkopp wrote:
>
>> The sbk->sk reference is used to make sure in AF_CAN to identify the
>> originating socket (if any) to not deliver echoed CAN frames to the
>> originating application.
>>
>> See first check in raw_rcv() in net/can/raw.c
>
> Nice, this is buggy.
>
>>
>>>
>>> Instead of understanding the issue, it seems this patch exactly shutup
>>> the useful warning.
>>
>> I would have been happy to have this a warning and not a bug as you
>> implemented it.
>>
>
> Yes, I understand you are not happy of our work to discover CAN bugs.
>
>> I don't need this warning as I'm using skb_alloc in the cases where CAN frames
>> are generated autonomously. They are not triggered through a direct socket
>> write operation nor do they need to take case about any sock wmem.
>>
>> The useful warning/bug might be nice for common use cases. I'm using plain
>> skb_alloc here for fire-and-forget skbs.
>>
>> So I need to shutup the useful warning or revert the two commits at
>> skb_orphan(). I would prefer the latter.
>>
>>>
>>> If you set skb->sk, then you expect a future reader of skb->sk to be
>>> 100% sure the socket did not disappear.
>>
>> It's a fire-and-forget skb. I don't need to care if the socket disappears.
>> If it disappears no new traffic is generated. That's enough.
>>
>>>
>>> I do not see this explained in the changelog.
>>>
>>
>> I hopefully was able to make it more clearly.
>> See Documentation/networking/can.txt
>>
>
>
> Just take a reference on the damn socket, and we do not have to worry.
>
> bcm_tx_send() suffers from the same problem
>
> can_send() is buggy as well :
>
> newskb->sk = skb->sk; // line 293
>
> dev_queue_xmit() can queue a packet a long time, and some packet qdisc
> even look at skb->sk.
>
> So this is really wrong to assume only net/can can assume things about
> skb->sk, and not care of net/core or net/sched users.
>
> I absolutely disagree with your patch. You need quite different _real_
> fixes.
Hi.
Even if this is a bug in the CAN BCM implementation. Your "fix" just
enabled a user space application to shut down any machine with a kernel
containing the BUG_ON patch.
If the BCM implementation is broken, it needs to be fixed. But this is a
regression that causes Kernel crashes, where there were none before.
As I am using the BCM, I would rather have a flawed but working
implementation than an unusable one. If the empty socket destructor
enables the system to work again, then I would like to see it. But, like
Oliver, I would prefer the BUG_ON patch reverted at least until this
issue is resolved.
Regards
Andre
>
>
>
^ permalink raw reply
* Re: 8% performance improved by change tap interact with kernel stack
From: Qin Chuanyu @ 2014-01-29 7:41 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: jasowang, Anthony Liguori, KVM list, netdev
In-Reply-To: <20140128103325.GA17794@redhat.com>
On 2014/1/28 18:33, Michael S. Tsirkin wrote:
>>> Nice.
>>> What about CPU utilization?
>>> It's trivially easy to speed up networking by
>>> burning up a lot of CPU so we must make sure it's
>>> not doing that.
>>> And I think we should see some tests with TCP as well, and
>>> try several message sizes.
>>>
>>>
>> Yes, by burning up more CPU we could get better performance easily.
>> So I have bond vhost thread and interrupt of nic on CPU1 while testing.
>>
>> modified before, the idle of CPU1 is 0%-1% while testing.
>> and after modify, the idle of CPU1 is 2%-3% while testing
>>
>> TCP also could gain from this, but pps is less than UDP, so I think
>> the improvement would be not so obviously.
>
> Still need to test this doesn't regress but overall looks convincing to me.
> Could you send a patch, accompanied by testing results for
> throughput latency and cpu utilization for tcp and udp
> with various message sizes?
>
> Thanks!
>
because of spring festival of china, the test result would be given two
week later.
throughput would be test by netperf, and latency would be tested by
qperf. Is that OK?
^ permalink raw reply
* Re: [PATCH 0/2] DT: net: davinci_emac: couple more properties actually optional
From: David Miller @ 2014-01-29 7:43 UTC (permalink / raw)
To: sergei.shtylyov
Cc: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, devicetree, linux-doc, davinci-linux-open-source
In-Reply-To: <201401280245.35745.sergei.shtylyov@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Tue, 28 Jan 2014 02:45:34 +0300
> Though described as required, couple more properties in the DaVinci EMAC
> binding are actually optional, as the driver will happily function without them.
> The patchset is against DaveM's 'net.git' tree this time.
>
> [1/2] DT: net: davinci_emac: "ti,davinci-rmii-en" property is actually optional
> [2/2] DT: net: davinci_emac: "ti,davinci-no-bd-ram" property is actually optional
Series applied with the "has/have" thing fixed.
Thanks.
^ permalink raw reply
* [PATCH v3] tun: add device name(iff) field to proc fdinfo entry
From: Masatake YAMATO @ 2014-01-29 7:43 UTC (permalink / raw)
To: davem; +Cc: netdev, yamato
In-Reply-To: <20140128.231947.1827551289841225189.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.
v3: remove unused variable.
Both are suggested by David Miller <davem@davemloft.net>.
Signed-off-by: Masatake YAMATO <yamato@redhat.com>
---
drivers/net/tun.c | 27 ++++++++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index bcf01af..44c4db8 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,27 @@ 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;
+
+ 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 +2264,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
* Re: [PATCH stable 3.11+] can: bcm: add skb destructor
From: David Miller @ 2014-01-29 7:46 UTC (permalink / raw)
To: nautsch2; +Cc: eric.dumazet, socketcan, netdev
In-Reply-To: <52E8B053.2030808@gmail.com>
From: Andre Naujoks <nautsch2@gmail.com>
Date: Wed, 29 Jan 2014 08:40:03 +0100
> Even if this is a bug in the CAN BCM implementation. Your "fix" just
> enabled a user space application to shut down any machine with a kernel
> containing the BUG_ON patch.
Rather, he detected a potential stray pointer reference to freed data
that was caused by the CAN code which would difficult if not
impossible to detect otherwise.
That's even more dangerous, and you should be thanking him.
^ 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