* Re: [PATCH RFC net-next] net: Allow name change of IFF_UP interfaces
From: Andrew Lunn @ 2017-08-10 14:10 UTC (permalink / raw)
To: Vitaly Kuznetsov
Cc: ????????????, network dev, Linux Kernel Mailing List,
David S. Miller, Eric Dumazet, Stephen Hemminger
In-Reply-To: <871sojyfv0.fsf@vitty.brq.redhat.com>
> >> Can you think of any particular real world scenarios which are broken by
> >> the change?
> >
> > How about:
> >
> > man 8 dhclient-script
> >
> > The interface name is passed in $interface to the scripts. Do we get
> > the old name or the new name? I suspect scripts are going to break if
> > they are given the old name, which no longer exists.
>
> Yes but why would anyone change interface name while dhclient-script is
> running? Things will also go wrong if you try bringing interface down
> during the run or do some other configuration, right?
dhclient already handles the interface going down. sendto/recvfrom
fails and returns an error code. As far as i remember, dhclient then
exits.
> Running multiple configuration tools at the same moment is a bad
> idea, you never know what you're gonna end up with.
It could be argued that configuring an interface vs renaming an
interface are at different levels.
Andrew
^ permalink raw reply
* Re: [PATCH RFC net-next] net: Allow name change of IFF_UP interfaces
From: Andrew Lunn @ 2017-08-10 14:13 UTC (permalink / raw)
To: Vitaly Kuznetsov
Cc: Eric Dumazet, network dev, David S. Miller, Eric Dumazet,
Stephen Hemminger
In-Reply-To: <87poc3wxkl.fsf@vitty.brq.redhat.com>
> We are - rtnetlink_event() does the job. We, however, don't have a
> special IFLA_EVENT_* for name change and end up with IFLA_EVENT_NONE.
What is in this event? Old and new name? Just the new name?
Andrew
^ permalink raw reply
* Re: [PATCHv2 1/2] drivers: net: davinci_mdio: remove busy loop on wait user access
From: Andrew Lunn @ 2017-08-10 14:40 UTC (permalink / raw)
To: Max Uvarov; +Cc: netdev, linux-omap, grygorii.strashko
In-Reply-To: <1502351267-23841-1-git-send-email-muvarov@gmail.com>
On Thu, Aug 10, 2017 at 10:47:46AM +0300, Max Uvarov wrote:
> Polling 14 mdio devices on single mdio bus eats 30% of 1Ghz cpu time
> due to busy loop in wait(). Add small delay to relax cpu.
Hi Max
Please include a cover note when you have multiple patches in a
series.
With 14 devices, it makes sense to swap to using PHY interrupts if you
can. That should prevent the PHY state machine polling the PHYs every
second.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v2] net: stmmac: Use the right logging function in stmmac_mdio_register
From: Romain Perier @ 2017-08-10 14:43 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Giuseppe Cavallaro, Alexandre Torgue, netdev, linux-kernel
In-Reply-To: <20170810135653.GB24790@lunn.ch>
Hi Andrew,
Le 10/08/2017 à 15:56, Andrew Lunn a écrit :
> On Thu, Aug 10, 2017 at 09:38:26AM +0200, Romain Perier wrote:
>> Currently, the function stmmac_mdio_register() is only used by
>> stmmac_dvr_probe() from stmmac_main.c, in order to register the MDIO bus
>> and probe information about the PHY. As this function is called before
>> calling register_netdev(), all messages logged from stmmac_mdio_register
>> are prefixed by "(unnamed net_device)". The goal of netdev_info or
>> netdev_err is to dump useful infos about a net_device, when this data
>> structure is partially initialized, there is no point for using these
>> functions.
>>
>> This commit fixes the issue by replacing all netdev_*() by the
>> corresponding dev_*() function for logging. The last netdev_info is
>> replaced by phy_attached_info(), as a valid phydev can be used at this
>> point.
>>
>> Signed-off-by: Romain Perier <romain.perier@collabora.com>
>> ---
>>
>> Changes in v2:
>> - Replaced dev_info() by phy_attached_print()
>> - Simplified message because informations were redudant
>> - Updated commit message
>>
>> drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 11 ++++++-----
>> 1 file changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
>> index db157a47000c..e0fbf8657103 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
>> @@ -204,6 +204,7 @@ int stmmac_mdio_register(struct net_device *ndev)
>> struct stmmac_priv *priv = netdev_priv(ndev);
>> struct stmmac_mdio_bus_data *mdio_bus_data = priv->plat->mdio_bus_data;
>> struct device_node *mdio_node = priv->plat->mdio_node;
>> + struct device *dev = ndev->dev.parent;
>> int addr, found;
>>
>> if (!mdio_bus_data)
>> @@ -237,7 +238,7 @@ int stmmac_mdio_register(struct net_device *ndev)
>> else
>> err = mdiobus_register(new_bus);
>> if (err != 0) {
>> - netdev_err(ndev, "Cannot register the MDIO bus\n");
>> + dev_err(dev, "Cannot register the MDIO bus\n");
>> goto bus_register_fail;
>> }
>>
>> @@ -285,14 +286,14 @@ int stmmac_mdio_register(struct net_device *ndev)
>> irq_str = irq_num;
>> break;
>> }
>> - netdev_info(ndev, "PHY ID %08x at %d IRQ %s (%s)%s\n",
>> - phydev->phy_id, addr, irq_str, phydev_name(phydev),
>> - act ? " active" : "");
>> + phy_attached_print(phydev, "PHY ID %08x IRQ %s %s\n",
>> + phydev->phy_id, irq_str,
>> + act ? " active" : "");
> I don't want to go round and round with this patch, with feature creep.
>
> But there are only two drivers which use phy_attached_print() to print
> more than the standard printed by phy_attached_info().
> phy_attached_info() will give you the driver name, so do you need the
> ID? phy_attached_info() prints the irq as a number, rather than a nice
> string.
>
> act is just odd. The loop is effectively phy_find_first(). The act
> means it has found a phy, but not the phy indicated in the platform
> data, but it is going to use it anyway!
>
> So i will give:
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>
> but if you think phy_attached_info() is acceptable, that would be
> great.
>
> Andrew
Good point, initially I just wanted to propose a fix about logging and
not change the message, in order to avoid to lose informations (but
that's very arguable).
phy_attached_print or phy_attached_info already display the model of the
PHY, so I think that removing PHY ID is okay, because in this case it is
completely useless.
I will post a v3 with your Reviewed-by:
Romain
^ permalink raw reply
* [PATCH net-next 0/6] rtnetlink: fix initial rtnl pushdown fallout
From: Florian Westphal @ 2017-08-10 14:52 UTC (permalink / raw)
To: netdev
This series fixes various bugs and splats reported since the
allow-handler-to-run-with-no-rtnl series went in.
Last patch adds a script that can be used to add further
tests in case more bugs are reported.
In case you prefer reverting the original series instead of
fixing fallout I can resend this patch on its own.
^ permalink raw reply
* [PATCH net-next 1/6] rtnetlink: use rcu_dereference_raw to silence rcu splat
From: Florian Westphal @ 2017-08-10 14:52 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
In-Reply-To: <20170810145302.30391-1-fw@strlen.de>
Ido reports a rcu splat in __rtnl_register.
The splat is correct; as rtnl_register doesn't grab any logs
and doesn't use rcu locks either. It has always been like this.
handler families are not registered in parallel so there are no
races wrt. the kmalloc ordering.
The only reason to use rcu_dereference in the first place was to
avoid sparse from complaining about this.
Thus this switches to _raw() to not have rcu checks here.
The alternative is to add rtnl locking to register/unregister,
however, I don't see a compelling reason to do so as this has been
lockless for the past twenty years or so.
Fixes: 6853dd4881 ("rtnetlink: protect handler table with rcu")
Reported-by: Ido Schimmel <idosch@idosch.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/core/rtnetlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index dd4e50dfa248..a5bc5bd0dc12 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -172,7 +172,7 @@ int __rtnl_register(int protocol, int msgtype,
BUG_ON(protocol < 0 || protocol > RTNL_FAMILY_MAX);
msgindex = rtm_msgindex(msgtype);
- tab = rcu_dereference(rtnl_msg_handlers[protocol]);
+ tab = rcu_dereference_raw(rtnl_msg_handlers[protocol]);
if (tab == NULL) {
tab = kcalloc(RTM_NR_MSGTYPES, sizeof(*tab), GFP_KERNEL);
if (tab == NULL)
--
2.13.0
^ permalink raw reply related
* [PATCH net-next 2/6] rtnetlink: do not use RTM_GETLINK directly
From: Florian Westphal @ 2017-08-10 14:52 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
In-Reply-To: <20170810145302.30391-1-fw@strlen.de>
Userspace sends RTM_GETLINK type, but the kernel substracts
RTM_BASE from this, i.e. 'type' doesn't contain RTM_GETLINK
anymore but instead RTM_GETLINK - RTM_BASE.
This caused the calcit callback to not be invoked when it
should have been (and vice versa).
While at it, also fix a off-by one when checking family index. vs
handler array size.
Fixes: e1fa6d216dd ("rtnetlink: call rtnl_calcit directly")
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/core/rtnetlink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index a5bc5bd0dc12..a9b5ebc1af21 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -4167,7 +4167,7 @@ static int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh,
if (kind != 2 && !netlink_net_capable(skb, CAP_NET_ADMIN))
return -EPERM;
- if (family > ARRAY_SIZE(rtnl_msg_handlers))
+ if (family >= ARRAY_SIZE(rtnl_msg_handlers))
family = PF_UNSPEC;
rcu_read_lock();
@@ -4196,7 +4196,7 @@ static int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh,
refcount_inc(&rtnl_msg_handlers_ref[family]);
- if (type == RTM_GETLINK)
+ if (type == RTM_GETLINK - RTM_BASE)
min_dump_alloc = rtnl_calcit(skb, nlh);
rcu_read_unlock();
--
2.13.0
^ permalink raw reply related
* [PATCH net-next 3/6] rtnetlink: switch rtnl_link_get_slave_info_data_size to rcu
From: Florian Westphal @ 2017-08-10 14:52 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
In-Reply-To: <20170810145302.30391-1-fw@strlen.de>
David Ahern reports following splat:
RTNL: assertion failed at net/core/dev.c (5717)
netdev_master_upper_dev_get+0x5f/0x70
if_nlmsg_size+0x158/0x240
rtnl_calcit.isra.26+0xa3/0xf0
rtnl_link_get_slave_info_data_size currently assumes RTNL protection, but
there appears to be no hard requirement for this, so use rcu instead.
At the time of this writing, there are three 'get_slave_size' callbacks
(now invoked under rcu): bond_get_slave_size, vrf_get_slave_size and
br_port_get_slave_size, all return constant only (i.e. they don't sleep).
Fixes: 6853dd488119 ("rtnetlink: protect handler table with rcu")
Reported-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/core/rtnetlink.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index a9b5ebc1af21..087f2434813a 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -402,16 +402,24 @@ static size_t rtnl_link_get_slave_info_data_size(const struct net_device *dev)
{
struct net_device *master_dev;
const struct rtnl_link_ops *ops;
+ size_t size = 0;
- master_dev = netdev_master_upper_dev_get((struct net_device *) dev);
+ rcu_read_lock();
+
+ master_dev = netdev_master_upper_dev_get_rcu((struct net_device *)dev);
if (!master_dev)
- return 0;
+ goto out;
+
ops = master_dev->rtnl_link_ops;
if (!ops || !ops->get_slave_size)
- return 0;
+ goto out;
/* IFLA_INFO_SLAVE_DATA + nested data */
- return nla_total_size(sizeof(struct nlattr)) +
+ size = nla_total_size(sizeof(struct nlattr)) +
ops->get_slave_size(master_dev, dev);
+
+out:
+ rcu_read_unlock();
+ return size;
}
static size_t rtnl_link_get_size(const struct net_device *dev)
--
2.13.0
^ permalink raw reply related
* [PATCH net-next 4/6] rtnetlink: init handler refcounts to 1
From: Florian Westphal @ 2017-08-10 14:53 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
In-Reply-To: <20170810145302.30391-1-fw@strlen.de>
If using CONFIG_REFCOUNT_FULL=y we get following splat:
refcount_t: increment on 0; use-after-free.
WARNING: CPU: 0 PID: 304 at lib/refcount.c:152 refcount_inc+0x47/0x50
Call Trace:
rtnetlink_rcv_msg+0x191/0x260
...
This warning is harmless (0 is "no callback running", not "memory
was freed").
Use '1' as the new 'no handler is running' base instead of 0 to avoid
this.
Fixes: 019a316992ee ("rtnetlink: add reference counting to prevent module unload while dump is in progress")
Reported-by: Sabrina Dubroca <sdubroca@redhat.com>
Reported-by: kernel test robot <fengguang.wu@intel.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/core/rtnetlink.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 087f2434813a..59eda6952bc9 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -262,7 +262,7 @@ void rtnl_unregister_all(int protocol)
synchronize_net();
- while (refcount_read(&rtnl_msg_handlers_ref[protocol]) > 0)
+ while (refcount_read(&rtnl_msg_handlers_ref[protocol]) > 1)
schedule();
kfree(handlers);
}
@@ -4324,6 +4324,11 @@ static struct pernet_operations rtnetlink_net_ops = {
void __init rtnetlink_init(void)
{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(rtnl_msg_handlers_ref); i++)
+ refcount_set(&rtnl_msg_handlers_ref[i], 1);
+
if (register_pernet_subsys(&rtnetlink_net_ops))
panic("rtnetlink_init: cannot initialize rtnetlink\n");
--
2.13.0
^ permalink raw reply related
* [PATCH net-next 5/6] rtnetlink: fallback to UNSPEC if current family has no doit callback
From: Florian Westphal @ 2017-08-10 14:53 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
In-Reply-To: <20170810145302.30391-1-fw@strlen.de>
We need to use PF_UNSPEC in case the requested family has no doit
callback, otherwise this now fails with EOPNOTSUPP instead of running the
unspec doit callback, as before.
Fixes: 6853dd488119 ("rtnetlink: protect handler table with rcu")
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/core/rtnetlink.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 59eda6952bc9..9e9f1419be60 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -4221,6 +4221,12 @@ static int rtnetlink_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh,
return err;
}
+ doit = READ_ONCE(handlers[type].doit);
+ if (!doit) {
+ family = PF_UNSPEC;
+ handlers = rcu_dereference(rtnl_msg_handlers[family]);
+ }
+
flags = READ_ONCE(handlers[type].flags);
if (flags & RTNL_FLAG_DOIT_UNLOCKED) {
refcount_inc(&rtnl_msg_handlers_ref[family]);
--
2.13.0
^ permalink raw reply related
* [PATCH net-next 6/6] selftests: add rtnetlink test script
From: Florian Westphal @ 2017-08-10 14:53 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
In-Reply-To: <20170810145302.30391-1-fw@strlen.de>
add a simple script to exercise some rtnetlink call paths, so KASAN,
lockdep etc. can yell at developer before patches are sent upstream.
This can be extended to also cover bond, team, vrf and the like.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
This test crashes the kernel, fix is already queued here:
https://patchwork.ozlabs.org/patch/800144/
tools/testing/selftests/net/Makefile | 2 +-
tools/testing/selftests/net/rtnetlink.sh | 199 +++++++++++++++++++++++++++++++
2 files changed, 200 insertions(+), 1 deletion(-)
create mode 100755 tools/testing/selftests/net/rtnetlink.sh
diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
index 6135a8448900..de1f5772b878 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -3,7 +3,7 @@
CFLAGS = -Wall -Wl,--no-as-needed -O2 -g
CFLAGS += -I../../../../usr/include/
-TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh
+TEST_PROGS := run_netsocktests run_afpackettests test_bpf.sh netdevice.sh rtnetlink.sh
TEST_GEN_FILES = socket
TEST_GEN_FILES += psock_fanout psock_tpacket
TEST_GEN_FILES += reuseport_bpf reuseport_bpf_cpu reuseport_bpf_numa
diff --git a/tools/testing/selftests/net/rtnetlink.sh b/tools/testing/selftests/net/rtnetlink.sh
new file mode 100755
index 000000000000..5b04ad912525
--- /dev/null
+++ b/tools/testing/selftests/net/rtnetlink.sh
@@ -0,0 +1,199 @@
+#!/bin/sh
+#
+# This test is for checking rtnetlink callpaths, and get as much coverage as possible.
+#
+# set -e
+
+devdummy="test-dummy0"
+ret=0
+
+# set global exit status, but never reset nonzero one.
+check_err()
+{
+ if [ $ret -eq 0 ]; then
+ ret=$1
+ fi
+}
+
+kci_add_dummy()
+{
+ ip link add name "$devdummy" type dummy
+ check_err $?
+ ip link set "$devdummy" up
+ check_err $?
+}
+
+kci_del_dummy()
+{
+ ip link del dev "$devdummy"
+ check_err $?
+}
+
+# add a bridge with vlans on top
+kci_test_bridge()
+{
+ devbr="test-br0"
+ vlandev="testbr-vlan1"
+
+ ret=0
+ ip link add name "$devbr" type bridge
+ check_err $?
+
+ ip link set dev "$devdummy" master "$devbr"
+ check_err $?
+
+ ip link set "$devbr" up
+ check_err $?
+
+ ip link add link "$devbr" name "$vlandev" type vlan id 1
+ check_err $?
+ ip addr add dev "$vlandev" 10.200.7.23/30
+ check_err $?
+ ip -6 addr add dev "$vlandev" dead:42::1234/64
+ check_err $?
+ ip -d link > /dev/null
+ check_err $?
+ ip r s t all > /dev/null
+ check_err $?
+ ip -6 addr del dev "$vlandev" dead:42::1234/64
+ check_err $?
+
+ ip link del dev "$vlandev"
+ check_err $?
+ ip link del dev "$devbr"
+ check_err $?
+
+ if [ $ret -ne 0 ];then
+ echo "FAIL: bridge setup"
+ return 1
+ fi
+ echo "PASS: bridge setup"
+
+}
+
+kci_test_gre()
+{
+ gredev=neta
+ rem=10.42.42.1
+ loc=10.0.0.1
+
+ ret=0
+ ip tunnel add $gredev mode gre remote $rem local $loc ttl 1
+ check_err $?
+ ip link set $gredev up
+ check_err $?
+ ip addr add 10.23.7.10 dev $gredev
+ check_err $?
+ ip route add 10.23.8.0/30 dev $gredev
+ check_err $?
+ ip addr add dev "$devdummy" 10.23.7.11/24
+ check_err $?
+ ip link > /dev/null
+ check_err $?
+ ip addr > /dev/null
+ check_err $?
+ ip addr del dev "$devdummy" 10.23.7.11/24
+ check_err $?
+
+ ip link del $gredev
+ check_err $?
+
+ if [ $ret -ne 0 ];then
+ echo "FAIL: gre tunnel endpoint"
+ return 1
+ fi
+ echo "PASS: gre tunnel endpoint"
+}
+
+# tc uses rtnetlink too, for full tc testing
+# please see tools/testing/selftests/tc-testing.
+kci_test_tc()
+{
+ dev=lo
+ ret=0
+
+ tc qdisc add dev "$dev" root handle 1: htb
+ check_err $?
+ tc class add dev "$dev" parent 1: classid 1:10 htb rate 1mbit
+ check_err $?
+ tc filter add dev "$dev" parent 1:0 prio 5 handle ffe: protocol ip u32 divisor 256
+ check_err $?
+ tc filter add dev "$dev" parent 1:0 prio 5 handle ffd: protocol ip u32 divisor 256
+ check_err $?
+ tc filter add dev "$dev" parent 1:0 prio 5 handle ffc: protocol ip u32 divisor 256
+ check_err $?
+ tc filter add dev "$dev" protocol ip parent 1: prio 5 handle ffe:2:3 u32 ht ffe:2: match ip src 10.0.0.3 flowid 1:10
+ check_err $?
+ tc filter add dev "$dev" protocol ip parent 1: prio 5 handle ffe:2:2 u32 ht ffe:2: match ip src 10.0.0.2 flowid 1:10
+ check_err $?
+ tc filter show dev "$dev" parent 1:0 > /dev/null
+ check_err $?
+ tc filter del dev "$dev" protocol ip parent 1: prio 5 handle ffe:2:3 u32
+ check_err $?
+ tc filter show dev "$dev" parent 1:0 > /dev/null
+ check_err $?
+ tc qdisc del dev "$dev" root handle 1: htb
+ check_err $?
+
+ if [ $ret -ne 0 ];then
+ echo "FAIL: tc htb hierarchy"
+ return 1
+ fi
+ echo "PASS: tc htb hierarchy"
+
+}
+
+kci_test_polrouting()
+{
+ ret=0
+ ip rule add fwmark 1 lookup 100
+ check_err $?
+ ip route add local 0.0.0.0/0 dev lo table 100
+ check_err $?
+ ip r s t all > /dev/null
+ check_err $?
+ ip rule del fwmark 1 lookup 100
+ check_err $?
+ ip route del local 0.0.0.0/0 dev lo table 100
+ check_err $?
+
+ if [ $ret -ne 0 ];then
+ echo "FAIL: policy route test"
+ return 1
+ fi
+ echo "PASS: policy routing"
+}
+
+kci_test_rtnl()
+{
+ kci_add_dummy
+ if [ $ret -ne 0 ];then
+ echo "FAIL: cannot add dummy interface"
+ return 1
+ fi
+
+ kci_test_polrouting
+ kci_test_tc
+ kci_test_gre
+ kci_test_bridge
+
+ kci_del_dummy
+}
+
+#check for needed privileges
+if [ "$(id -u)" -ne 0 ];then
+ echo "SKIP: Need root privileges"
+ exit 0
+fi
+
+for x in ip tc;do
+ $x -Version 2>/dev/null >/dev/null
+ if [ $? -ne 0 ];then
+ echo "SKIP: Could not run test without the $x tool"
+ exit 0
+ fi
+done
+
+kci_test_rtnl
+
+exit $ret
--
2.13.0
^ permalink raw reply related
* [PATCH v3] net: stmmac: Use the right logging function in stmmac_mdio_register
From: Romain Perier @ 2017-08-10 14:56 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue
Cc: Andrew Lunn, netdev, linux-kernel, Romain Perier
Currently, the function stmmac_mdio_register() is only used by
stmmac_dvr_probe() from stmmac_main.c, in order to register the MDIO bus
and probe information about the PHY. As this function is called before
calling register_netdev(), all messages logged from stmmac_mdio_register
are prefixed by "(unnamed net_device)". The goal of netdev_info or
netdev_err is to dump useful infos about a net_device, when this data
structure is partially initialized, there is no point for using these
functions.
This commit fixes the issue by replacing all netdev_*() by the
corresponding dev_*() function for logging. The last netdev_info is
replaced by phy_attached_info(), as a valid phydev can be used at this
point.
Signed-off-by: Romain Perier <romain.perier@collabora.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
Changes in v3:
- Replaced phy_attached_print by phy_attached_info, makes more sense
- Added Reviewed-by tag by Andrew
Changes in v2:
- Replaced dev_info() by phy_attached_print()
- Simplified message because informations were redudant
- Updated commit message
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index db157a47000c..72ec711fcba2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -204,6 +204,7 @@ int stmmac_mdio_register(struct net_device *ndev)
struct stmmac_priv *priv = netdev_priv(ndev);
struct stmmac_mdio_bus_data *mdio_bus_data = priv->plat->mdio_bus_data;
struct device_node *mdio_node = priv->plat->mdio_node;
+ struct device *dev = ndev->dev.parent;
int addr, found;
if (!mdio_bus_data)
@@ -237,7 +238,7 @@ int stmmac_mdio_register(struct net_device *ndev)
else
err = mdiobus_register(new_bus);
if (err != 0) {
- netdev_err(ndev, "Cannot register the MDIO bus\n");
+ dev_err(dev, "Cannot register the MDIO bus\n");
goto bus_register_fail;
}
@@ -285,14 +286,12 @@ int stmmac_mdio_register(struct net_device *ndev)
irq_str = irq_num;
break;
}
- netdev_info(ndev, "PHY ID %08x at %d IRQ %s (%s)%s\n",
- phydev->phy_id, addr, irq_str, phydev_name(phydev),
- act ? " active" : "");
+ phy_attached_info(phydev);
found = 1;
}
if (!found && !mdio_node) {
- netdev_warn(ndev, "No PHY found\n");
+ dev_warn(dev, "No PHY found\n");
mdiobus_unregister(new_bus);
mdiobus_free(new_bus);
return -ENODEV;
--
2.11.0
^ permalink raw reply related
* [patch v1 2/2] Change Kconfig description
From: Ohad Oz @ 2017-08-10 17:11 UTC (permalink / raw)
To: davem; +Cc: netdev, jiri, saeedm, vadimp, system-sw-low-level, Ohad Oz
In-Reply-To: <1502385112-103765-1-git-send-email-ohado@mellanox.com>
Mellanox devices can be cards or switch therefore naming it device.
Signed-off-by: Ohad Oz <ohado@mellanox.com>
---
drivers/net/ethernet/mellanox/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/Kconfig b/drivers/net/ethernet/mellanox/Kconfig
index 0949741..01c3623 100644
--- a/drivers/net/ethernet/mellanox/Kconfig
+++ b/drivers/net/ethernet/mellanox/Kconfig
@@ -7,7 +7,7 @@ config NET_VENDOR_MELLANOX
default y
depends on PCI || I2C
---help---
- If you have a network (Ethernet) card belonging to this class, say Y.
+ If you have a network (Ethernet) device belonging to this class, say Y.
Note that the answer to this question doesn't directly affect the
kernel: saying N will just cause the configurator to skip all
--
2.8.0
^ permalink raw reply related
* [patch v1 1/2] Allow Mellanox network vendor to be configured if only I2C bus is configured
From: Ohad Oz @ 2017-08-10 17:11 UTC (permalink / raw)
To: davem; +Cc: netdev, jiri, saeedm, vadimp, system-sw-low-level, Ohad Oz
Patch allows Mellanox devices on system with no PCI, but with I2C only.
Signed-off-by: Ohad Oz <ohado@mellanox.com>
---
drivers/net/ethernet/mellanox/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/Kconfig b/drivers/net/ethernet/mellanox/Kconfig
index 84a2007..0949741 100644
--- a/drivers/net/ethernet/mellanox/Kconfig
+++ b/drivers/net/ethernet/mellanox/Kconfig
@@ -5,7 +5,7 @@
config NET_VENDOR_MELLANOX
bool "Mellanox devices"
default y
- depends on PCI
+ depends on PCI || I2C
---help---
If you have a network (Ethernet) card belonging to this class, say Y.
--
2.8.0
^ permalink raw reply related
* Re: [PATCH net-next] phylink: Fix an uninitialized variable bug
From: Andrew Lunn @ 2017-08-10 15:21 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Russell King, Florian Fainelli, netdev, kernel-janitors
In-Reply-To: <20170809213550.rga6tlohagu2pm2y@mwanda>
On Thu, Aug 10, 2017 at 12:35:50AM +0300, Dan Carpenter wrote:
> "ret" isn't necessarily initialized here.
>
> Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH RFC net-next] net: Allow name change of IFF_UP interfaces
From: Vitaly Kuznetsov @ 2017-08-10 15:24 UTC (permalink / raw)
To: Andrew Lunn
Cc: Eric Dumazet, network dev, David S. Miller, Eric Dumazet,
Stephen Hemminger
In-Reply-To: <20170810141358.GD24790@lunn.ch>
Andrew Lunn <andrew@lunn.ch> writes:
>> We are - rtnetlink_event() does the job. We, however, don't have a
>> special IFLA_EVENT_* for name change and end up with IFLA_EVENT_NONE.
>
> What is in this event? Old and new name? Just the new name?
Basically, it's everything we know about the interface - type, index,
name, mtu, qdisc, ... - see rtnl_fill_ifinfo(). Back to your question -
it's only the new name.
--
Vitaly
^ permalink raw reply
* Re: [PATCH v4 1/4] can: dev: Add support for limiting configured bitrate
From: Marc Kleine-Budde @ 2017-08-10 15:29 UTC (permalink / raw)
To: Franklin S Cooper Jr, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-can-u79uwXL29TY76Z2rM5mHXA, wg-5Yr1BZd7O62+XT7JhA+gdA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
dev.kurt-yI9piX4KPfawT/RRk36CISFp6vIno51x, andrew-g2DYL2Zd6BY,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
socketcan-fJ+pQTUTwRTk1uMJSBkQmQ
In-Reply-To: <20170810005916.27163-2-fcooper-l0cyMroinI0@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 5037 bytes --]
Hello,
sorry for stepping in late....
On 08/10/2017 02:59 AM, Franklin S Cooper Jr wrote:
> Various CAN or CAN-FD IP may be able to run at a faster rate than
> what the transceiver the CAN node is connected to. This can lead to
> unexpected errors. However, CAN transceivers typically have fixed
> limitations and provide no means to discover these limitations at
> runtime. Therefore, add support for a can-transceiver node that
> can be reused by other CAN peripheral drivers to determine for both
> CAN and CAN-FD what the max bitrate that can be used. If the user
> tries to configure CAN to pass these maximum bitrates it will throw
> an error.
>
> Signed-off-by: Franklin S Cooper Jr <fcooper-l0cyMroinI0@public.gmane.org>
> ---
> Version 4 changes:
> Used can-transceiver instead of fixed-transceiver.
>
> drivers/net/can/dev.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/can/dev.h | 5 +++++
> 2 files changed, 55 insertions(+)
>
> diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
> index 365a8cc..372108f 100644
> --- a/drivers/net/can/dev.c
> +++ b/drivers/net/can/dev.c
> @@ -27,6 +27,7 @@
> #include <linux/can/skb.h>
> #include <linux/can/netlink.h>
> #include <linux/can/led.h>
> +#include <linux/of.h>
> #include <net/rtnetlink.h>
>
> #define MOD_DESC "CAN device driver interface"
> @@ -814,6 +815,39 @@ int open_candev(struct net_device *dev)
> }
> EXPORT_SYMBOL_GPL(open_candev);
>
> +#ifdef CONFIG_OF
> +/*
> + * Common function that can be used to understand the limitation of
> + * a transceiver when it provides no means to determine these limitations
> + * at runtime.
> + */
> +void of_can_transceiver(struct net_device *dev)
> +{
> + struct device_node *dn;
> + struct can_priv *priv = netdev_priv(dev);
> + struct device_node *np;
> + unsigned int max_bitrate;
> + int ret;
> +
> + np = dev->dev.parent->of_node;
> +
> + dn = of_get_child_by_name(np, "can-transceiver");
> + if (!dn)
> + return;
> +
> + max_bitrate = 0;
> + ret = of_property_read_u32(dn, "max-bitrate", &max_bitrate);
IIRC the last argument is only modified in case of no error, so what about:
ret = of_property_read_u32(dn, "max-bitrate",
&priv->max_bitrate);
> +
> + if (max_bitrate > 0) {
> + priv->max_bitrate = max_bitrate;
> + priv->is_bitrate_limited = true;
Do we need is_bitrate_limited...
> + } else if (ret != -EINVAL) {
> + netdev_warn(dev, "Invalid value for transceiver max bitrate\n");
> + }
> +}
> +EXPORT_SYMBOL(of_can_transceiver);
> +#endif
> +
> /*
> * Common close function for cleanup before the device gets closed.
> *
> @@ -913,6 +947,14 @@ static int can_changelink(struct net_device *dev, struct nlattr *tb[],
> priv->bitrate_const_cnt);
> if (err)
> return err;
> +
> + if (priv->is_bitrate_limited &&
> + bt.bitrate > priv->max_bitrate) {
...can we just use priv->max_bitrate?
if (priv->max_bitrate && bt.bitrate > priv->max_bitrate)
> + netdev_err(dev, "arbitration bitrate surpasses transceiver capabilities of %d bps\n",
> + priv->max_bitrate);
> + return -EINVAL;
> + }
> +
> memcpy(&priv->bittiming, &bt, sizeof(bt));
>
> if (priv->do_set_bittiming) {
> @@ -997,6 +1039,14 @@ static int can_changelink(struct net_device *dev, struct nlattr *tb[],
> priv->data_bitrate_const_cnt);
> if (err)
> return err;
> +
> + if (priv->is_bitrate_limited &&
> + dbt.bitrate > priv->max_bitrate) {
> + netdev_err(dev, "canfd data bitrate surpasses transceiver capabilities of %d bps\n",
> + priv->max_bitrate);
> + return -EINVAL;
> + }
> +
> memcpy(&priv->data_bittiming, &dbt, sizeof(dbt));
>
> if (priv->do_set_data_bittiming) {
> diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
> index 141b05a..5519f59 100644
> --- a/include/linux/can/dev.h
> +++ b/include/linux/can/dev.h
> @@ -47,6 +47,9 @@ struct can_priv {
> unsigned int data_bitrate_const_cnt;
> struct can_clock clock;
>
> + unsigned int max_bitrate;
> + bool is_bitrate_limited;
> +
> enum can_state state;
>
> /* CAN controller features - see include/uapi/linux/can/netlink.h */
> @@ -165,6 +168,8 @@ void can_put_echo_skb(struct sk_buff *skb, struct net_device *dev,
> unsigned int can_get_echo_skb(struct net_device *dev, unsigned int idx);
> void can_free_echo_skb(struct net_device *dev, unsigned int idx);
>
> +void of_can_transceiver(struct net_device *dev);
> +
> struct sk_buff *alloc_can_skb(struct net_device *dev, struct can_frame **cf);
> struct sk_buff *alloc_canfd_skb(struct net_device *dev,
> struct canfd_frame **cfd);
>
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 1/6] rtnetlink: use rcu_dereference_raw to silence rcu splat
From: Ido Schimmel @ 2017-08-10 15:38 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev
In-Reply-To: <20170810145302.30391-2-fw@strlen.de>
On Thu, Aug 10, 2017 at 04:52:57PM +0200, Florian Westphal wrote:
> Ido reports a rcu splat in __rtnl_register.
> The splat is correct; as rtnl_register doesn't grab any logs
> and doesn't use rcu locks either. It has always been like this.
> handler families are not registered in parallel so there are no
> races wrt. the kmalloc ordering.
>
> The only reason to use rcu_dereference in the first place was to
> avoid sparse from complaining about this.
>
> Thus this switches to _raw() to not have rcu checks here.
>
> The alternative is to add rtnl locking to register/unregister,
> however, I don't see a compelling reason to do so as this has been
> lockless for the past twenty years or so.
>
> Fixes: 6853dd4881 ("rtnetlink: protect handler table with rcu")
> Reported-by: Ido Schimmel <idosch@idosch.org>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Tested-by: Ido Schimmel <idosch@mellanox.com>
Thanks!
^ permalink raw reply
* Re: [PATCH net] geneve: maximum value of VNI cannot be used
From: Girish Moodalbail @ 2017-08-10 15:58 UTC (permalink / raw)
To: David Miller; +Cc: pshelar, netdev
In-Reply-To: <20170809.224130.1529052203716251519.davem@davemloft.net>
On 8/9/17 10:41 PM, David Miller wrote:
> From: Girish Moodalbail <girish.moodalbail@oracle.com>
> Date: Tue, 8 Aug 2017 17:26:24 -0700
>
>> Geneve's Virtual Network Identifier (VNI) is 24 bit long, so the range
>> of values for it would be from 0 to 16777215 (2^24 -1). However, one
>> cannot create a geneve device with VNI set to 16777215. This patch fixes
>> this issue.
>>
>> Signed-off-by: Girish Moodalbail <girish.moodalbail@oracle.com>
>
> I always worry that someone, somewhere, might be using this in some
> way and this will break things.
>
> But I'll apply this for now.
>
Thanks David. As per the output of 'ip link help geneve', 16777215 is a valid
value. However, due to incorrect check in the kernel that value was not supported.
$ ip link help geneve |egrep -A1 VNI
Usage: ... geneve id VNI
remote ADDR
^ permalink raw reply
* Re: [PATCH] hv_set_ifconfig.sh double check before setting ip
From: David Miller @ 2017-08-10 16:12 UTC (permalink / raw)
To: otubo; +Cc: netdev, linux-kernel, devel, sthemmin, haiyangz, kys
In-Reply-To: <0b0a89e2-250e-69d9-9b24-1cf49e9c1d26@redhat.com>
From: Eduardo Otubo <otubo@redhat.com>
Date: Thu, 10 Aug 2017 09:40:27 +0200
> On 08/09/2017 11:02 AM, Eduardo Otubo wrote:
>> On 08/09/2017 06:11 AM, David Miller wrote:
>>> From: Eduardo Otubo <otubo@redhat.com>
>>> Date: Tue, 8 Aug 2017 15:53:45 +0200
>>>
>>>> This patch fixes the behavior of the hv_set_ifconfig script when
>>>> setting
>>>> the interface ip. Sometimes the interface has already been configured
>>>> by
>>>> network daemon, in this case hv_set_ifconfig causes "RTNETLINK: file
>>>> exists error"; in order to avoid this error this patch makes sure
>>>> double
>>>> checks the interface before trying anything.
>>>>
>>>> Signed-off-by: Eduardo Otubo <otubo@redhat.com>
>>>
>>> And if the daemon sets the address after you test it but before
>>> you try to set it in the script, what happens?
>>>
>>> This is why I hate changes like this. They don't remove the problem,
>>> they make it smaller. And smaller in a bad way. Smaller makes the
>>> problem even more harder to diagnose when it happens.
>>>
>>> There is implicitly no synchonization between network configuration
>>> daemons and things people run by hand like this script.
>>>
>>> So, caveat emptor.
>>>
>>> I'm not applying this, sorry.
>
> But also, looking from a different point of view, the current upstream
> solution does not avoid the problems you mentioned. My fix at least
> avoids double configuration and RTNETLINK errors. So perhaps you could
> consider this as "a better version walking towards an ideal fix"?
I didn't say upstream avoids the problem.
In fact, that's the good thing. It doesn't try to do something it
cannot do without explicit pieces of synchronization infrastructure
between such tools.
^ permalink raw reply
* Re: [PATCH net-next] net: core: fix compile error inside flow_dissector due to new dsa callback
From: David Miller @ 2017-08-10 16:16 UTC (permalink / raw)
To: john; +Cc: jiri, edumazet, netdev, linux-kernel
In-Reply-To: <20170810080903.32231-1-john@phrozen.org>
From: John Crispin <john@phrozen.org>
Date: Thu, 10 Aug 2017 10:09:03 +0200
> The following error was introduced by
> commit 43e665287f93 ("net-next: dsa: fix flow dissection")
> due to a missing #if guard
>
> net/core/flow_dissector.c: In function '__skb_flow_dissect':
> net/core/flow_dissector.c:448:18: error: 'struct net_device' has no member named 'dsa_ptr'
> ops = skb->dev->dsa_ptr->tag_ops;
> ^
> make[3]: *** [net/core/flow_dissector.o] Error 1
>
> Signed-off-by: John Crispin <john@phrozen.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 3/6] rtnetlink: switch rtnl_link_get_slave_info_data_size to rcu
From: David Ahern @ 2017-08-10 16:17 UTC (permalink / raw)
To: Florian Westphal, netdev
In-Reply-To: <20170810145302.30391-4-fw@strlen.de>
On 8/10/17 8:52 AM, Florian Westphal wrote:
> David Ahern reports following splat:
> RTNL: assertion failed at net/core/dev.c (5717)
> netdev_master_upper_dev_get+0x5f/0x70
> if_nlmsg_size+0x158/0x240
> rtnl_calcit.isra.26+0xa3/0xf0
>
> rtnl_link_get_slave_info_data_size currently assumes RTNL protection, but
> there appears to be no hard requirement for this, so use rcu instead.
>
> At the time of this writing, there are three 'get_slave_size' callbacks
> (now invoked under rcu): bond_get_slave_size, vrf_get_slave_size and
> br_port_get_slave_size, all return constant only (i.e. they don't sleep).
>
> Fixes: 6853dd488119 ("rtnetlink: protect handler table with rcu")
> Reported-by: David Ahern <dsahern@gmail.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> ---
> net/core/rtnetlink.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
Acked-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCHv2 2/2] drivers: net: davinci_mdio: print bus frequency
From: Grygorii Strashko @ 2017-08-10 16:18 UTC (permalink / raw)
To: Max Uvarov, netdev; +Cc: linux-omap
In-Reply-To: <1502351267-23841-2-git-send-email-muvarov@gmail.com>
On 08/10/2017 02:47 AM, Max Uvarov wrote:
> Frequency can be adjusted in DT it make sense to
> print current used value on driver init.
>
> Signed-off-by: Max Uvarov <muvarov@gmail.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
> ---
> drivers/net/ethernet/ti/davinci_mdio.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
> index 611e7cc..3c33f45 100644
> --- a/drivers/net/ethernet/ti/davinci_mdio.c
> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
> @@ -159,8 +159,10 @@ static int davinci_mdio_reset(struct mii_bus *bus)
>
> /* dump hardware version info */
> ver = __raw_readl(&data->regs->version);
> - dev_info(data->dev, "davinci mdio revision %d.%d\n",
> - (ver >> 8) & 0xff, ver & 0xff);
> + dev_info(data->dev,
> + "davinci mdio revision %d.%d, bus freq %ld\n",
> + (ver >> 8) & 0xff, ver & 0xff,
> + data->pdata.bus_freq);
>
> if (data->skip_scan)
> goto done;
>
--
regards,
-grygorii
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] rtnetlink: allow selected handlers to run without rtnl
From: David Ahern @ 2017-08-10 16:23 UTC (permalink / raw)
To: Florian Westphal; +Cc: netdev
In-Reply-To: <20170810112939.GA20558@breakpoint.cc>
On 8/10/17 5:29 AM, Florian Westphal wrote:
> David Ahern <dsahern@gmail.com> wrote:
>
>> On 8/9/17 6:21 PM, David Miller wrote:
>>>
>>> Ok series applied, let's see where this goes :-)
>>>
>>
>> 1 hour in, 1 problem reported
>
> Its even worse. Would you rather see a revert?
no.
>
> I'm sure that you are aware that the widespread rtnl usage is a
> problem because it does hurt scalability. I still think its worth trying
> to disentangle this where possible.
agreed. Going to be pain along the way, but it needs to be done. Thanks
for taking the initiative on it.
^ permalink raw reply
* Re: [PATCHv2 1/2] drivers: net: davinci_mdio: remove busy loop on wait user access
From: Grygorii Strashko @ 2017-08-10 16:24 UTC (permalink / raw)
To: Max Uvarov, netdev; +Cc: linux-omap
In-Reply-To: <1502351267-23841-1-git-send-email-muvarov@gmail.com>
On 08/10/2017 02:47 AM, Max Uvarov wrote:
> Polling 14 mdio devices on single mdio bus eats 30% of 1Ghz cpu time
> due to busy loop in wait(). Add small delay to relax cpu.
>
> Signed-off-by: Max Uvarov <muvarov@gmail.com>
yep. cover letter is good to have.
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
> ---
> v2: fix spelling in commit description.
>
> drivers/net/ethernet/ti/davinci_mdio.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
> index 33df340..611e7cc 100644
> --- a/drivers/net/ethernet/ti/davinci_mdio.c
> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
> @@ -198,8 +198,10 @@ static inline int wait_for_user_access(struct davinci_mdio_data *data)
> return 0;
>
> reg = __raw_readl(®s->control);
> - if ((reg & CONTROL_IDLE) == 0)
> + if ((reg & CONTROL_IDLE) == 0) {
> + usleep_range(100, 200);
> continue;
> + }
>
> /*
> * An emac soft_reset may have clobbered the mdio controller's
>
--
regards,
-grygorii
^ 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