* Re: [PATCH 00/12] Ethernet: Add and use ether_<type>_addr globals
From: Felix Fietkau @ 2018-04-05 14:05 UTC (permalink / raw)
To: Joe Perches, netdev, linux-wireless, b43-dev, bridge,
netfilter-devel, coreteam
Cc: linux-kernel, brcm80211-dev-list.pdl, brcm80211-dev-list
In-Reply-To: <1522936292.11185.15.camel@perches.com>
On 2018-04-05 15:51, Joe Perches wrote:
>> You have to factor in
>> not just the .text size, but the fact that referencing an exported
>> symbol needs a .reloc entry as well, which also eats up some space (at
>> least when the code is being built as module).
>
> Thanks, the modules I built got smaller.
Please post some numbers to show this. By the way, on other
architectures the numbers will probably be different, especially on
ARM/MIPS.
>> In my opinion, your series probably causes more bloat in common
>> configurations instead of reducing it.
>>
>> You're also touching several places that could easily use
>> eth_broadcast_addr and eth_zero_addr. I think making those changes would
>> be more productive than what you did in this series.
>
> Doubtful. AFAIK: possible unaligned addresses.
Those two are just memset calls, alignment does not matter.
- Felix
^ permalink raw reply
* RE: [PATCH] net: phy: marvell: Enable interrupt function on LED2 pin
From: Bhadram Varka @ 2018-04-05 14:00 UTC (permalink / raw)
To: Esben Haabendal
Cc: Esben Haabendal, Rasmus Villemoes, Andrew Lunn, Florian Fainelli,
open list, netdev@vger.kernel.org
In-Reply-To: <20180405133504.12257-1-esben.haabendal@gmail.com>
Hi Esben,
-----Original Message-----
From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On Behalf Of Esben Haabendal
Sent: Thursday, April 05, 2018 7:05 PM
To: netdev@vger.kernel.org
Cc: Esben Haabendal <eha@deif.com>; Rasmus Villemoes <rasmus.villemoes@prevas.dk>; Andrew Lunn <andrew@lunn.ch>; Florian Fainelli <f.fainelli@gmail.com>; open list <linux-kernel@vger.kernel.org>
Subject: [PATCH] net: phy: marvell: Enable interrupt function on LED2 pin
From: Esben Haabendal <eha@deif.com>
The LED2[2]/INTn pin on Marvell 88E1318S as well as 88E1510/12/14/18 needs to be configured to be usable as interrupt not only when WOL is enabled, but whenever we rely on interrupts from the PHY.
Signed-off-by: Esben Haabendal <eha@deif.com>
Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
drivers/net/phy/marvell.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c index 0e0978d8a0eb..f03a510f1247 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -457,6 +457,21 @@ static int marvell_of_reg_init(struct phy_device *phydev) } #endif /* CONFIG_OF_MDIO */
+static int m88e1318_config_intr(struct phy_device *phydev) {
+ int err;
+
+ err = marvell_config_intr(phydev);
+ if (err)
+ return err;
+
+ /* Setup LED[2] as interrupt pin (active low) */
+ return phy_modify(phydev, MII_88E1318S_PHY_LED_TCR,
+ MII_88E1318S_PHY_LED_TCR_FORCE_INT,
+ MII_88E1318S_PHY_LED_TCR_INTn_ENABLE |
+ MII_88E1318S_PHY_LED_TCR_INT_ACTIVE_LOW);
Can we move this part of the code to m88e1121_config_init() ?
Every time whether we disable or enable the interrupts this part of code will execute.
Thanks!
^ permalink raw reply
* Re: [PATCH 00/12] Ethernet: Add and use ether_<type>_addr globals
From: Joe Perches @ 2018-04-05 13:51 UTC (permalink / raw)
To: Felix Fietkau, netdev, linux-wireless, b43-dev, bridge,
netfilter-devel, coreteam
Cc: linux-kernel, brcm80211-dev-list.pdl, brcm80211-dev-list
In-Reply-To: <e0ab9616-64fa-cdbc-7a77-7e25d70c1a52@nbd.name>
On Thu, 2018-04-05 at 15:27 +0200, Felix Fietkau wrote:
> On 2018-03-31 09:05, Joe Perches wrote:
> > There are many local static and non-static arrays that are used for
> > Ethernet broadcast address output or comparison.
> >
> > Centralize the array into a single separate file and remove the local
> > arrays.
>
> I suspect that for many targets and configurations, the local arrays
> might actually be smaller than exporting a global.
I tried x86-64 allnoconfig and defconfig.
Those both did not increase vmlinux size.
The defconfig actually got smaller, but that might have been
some object alignment oddity.
> You have to factor in
> not just the .text size, but the fact that referencing an exported
> symbol needs a .reloc entry as well, which also eats up some space (at
> least when the code is being built as module).
Thanks, the modules I built got smaller.
> In my opinion, your series probably causes more bloat in common
> configurations instead of reducing it.
>
> You're also touching several places that could easily use
> eth_broadcast_addr and eth_zero_addr. I think making those changes would
> be more productive than what you did in this series.
Doubtful. AFAIK: possible unaligned addresses.
^ permalink raw reply
* [PATCH net 6/6] vti6: better validate user provided tunnel names
From: Eric Dumazet @ 2018-04-05 13:39 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Steffen Klassert, Eric Dumazet, Eric Dumazet
In-Reply-To: <20180405133931.207634-1-edumazet@google.com>
Use valid_name() to make sure user does not provide illegal
device name.
Fixes: ed1efb2aefbb ("ipv6: Add support for IPsec virtual tunnel interfaces")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv6/ip6_vti.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index 6ebb2e8777f42054ca5ee8338aa560f5501d8262..c214ffec02f06f6dccfb9769fc8640e5e56da618 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -212,10 +212,13 @@ static struct ip6_tnl *vti6_tnl_create(struct net *net, struct __ip6_tnl_parm *p
char name[IFNAMSIZ];
int err;
- if (p->name[0])
+ if (p->name[0]) {
+ if (!dev_valid_name(p->name))
+ goto failed;
strlcpy(name, p->name, IFNAMSIZ);
- else
+ } else {
sprintf(name, "ip6_vti%%d");
+ }
dev = alloc_netdev(sizeof(*t), name, NET_NAME_UNKNOWN, vti6_dev_setup);
if (!dev)
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply related
* [PATCH net 5/6] ip6_tunnel: better validate user provided tunnel names
From: Eric Dumazet @ 2018-04-05 13:39 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Steffen Klassert, Eric Dumazet, Eric Dumazet
In-Reply-To: <20180405133931.207634-1-edumazet@google.com>
Use valid_name() to make sure user does not provide illegal
device name.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv6/ip6_tunnel.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index df4c29f7d59f030729b1158b809a10f4115d4bbf..da66aaac51cecbf933827c8842e61a8cbb4d274f 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -297,13 +297,16 @@ static struct ip6_tnl *ip6_tnl_create(struct net *net, struct __ip6_tnl_parm *p)
struct net_device *dev;
struct ip6_tnl *t;
char name[IFNAMSIZ];
- int err = -ENOMEM;
+ int err = -E2BIG;
- if (p->name[0])
+ if (p->name[0]) {
+ if (!dev_valid_name(p->name))
+ goto failed;
strlcpy(name, p->name, IFNAMSIZ);
- else
+ } else {
sprintf(name, "ip6tnl%%d");
-
+ }
+ err = -ENOMEM;
dev = alloc_netdev(sizeof(*t), name, NET_NAME_UNKNOWN,
ip6_tnl_dev_setup);
if (!dev)
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply related
* [PATCH net 4/6] ip6_gre: better validate user provided tunnel names
From: Eric Dumazet @ 2018-04-05 13:39 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Steffen Klassert, Eric Dumazet, Eric Dumazet
In-Reply-To: <20180405133931.207634-1-edumazet@google.com>
Use dev_valid_name() to make sure user does not provide illegal
device name.
syzbot caught the following bug :
BUG: KASAN: stack-out-of-bounds in strlcpy include/linux/string.h:300 [inline]
BUG: KASAN: stack-out-of-bounds in ip6gre_tunnel_locate+0x334/0x860 net/ipv6/ip6_gre.c:339
Write of size 20 at addr ffff8801afb9f7b8 by task syzkaller851048/4466
CPU: 1 PID: 4466 Comm: syzkaller851048 Not tainted 4.16.0+ #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x1b9/0x29f lib/dump_stack.c:53
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0xac/0x2f5 mm/kasan/report.c:412
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
memcpy+0x37/0x50 mm/kasan/kasan.c:303
strlcpy include/linux/string.h:300 [inline]
ip6gre_tunnel_locate+0x334/0x860 net/ipv6/ip6_gre.c:339
ip6gre_tunnel_ioctl+0x69d/0x12e0 net/ipv6/ip6_gre.c:1195
dev_ifsioc+0x43e/0xb90 net/core/dev_ioctl.c:334
dev_ioctl+0x69a/0xcc0 net/core/dev_ioctl.c:525
sock_ioctl+0x47e/0x680 net/socket.c:1015
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:500 [inline]
do_vfs_ioctl+0x1cf/0x1650 fs/ioctl.c:684
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
SYSC_ioctl fs/ioctl.c:708 [inline]
SyS_ioctl+0x24/0x30 fs/ioctl.c:706
do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
---
net/ipv6/ip6_gre.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index f8a103bdbd603be103bf6c18ed6a55703aab18df..69727bc168cb027009dac95431e40b71291697da 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -335,11 +335,13 @@ static struct ip6_tnl *ip6gre_tunnel_locate(struct net *net,
if (t || !create)
return t;
- if (parms->name[0])
+ if (parms->name[0]) {
+ if (!dev_valid_name(parms->name))
+ return NULL;
strlcpy(name, parms->name, IFNAMSIZ);
- else
+ } else {
strcpy(name, "ip6gre%d");
-
+ }
dev = alloc_netdev(sizeof(*t), name, NET_NAME_UNKNOWN,
ip6gre_tunnel_setup);
if (!dev)
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply related
* [PATCH net 3/6] ipv6: sit: better validate user provided tunnel names
From: Eric Dumazet @ 2018-04-05 13:39 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Steffen Klassert, Eric Dumazet, Eric Dumazet
In-Reply-To: <20180405133931.207634-1-edumazet@google.com>
Use dev_valid_name() to make sure user does not provide illegal
device name.
syzbot caught the following bug :
BUG: KASAN: stack-out-of-bounds in strlcpy include/linux/string.h:300 [inline]
BUG: KASAN: stack-out-of-bounds in ipip6_tunnel_locate+0x63b/0xaa0 net/ipv6/sit.c:254
Write of size 33 at addr ffff8801b64076d8 by task syzkaller932654/4453
CPU: 0 PID: 4453 Comm: syzkaller932654 Not tainted 4.16.0+ #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x1b9/0x29f lib/dump_stack.c:53
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0xac/0x2f5 mm/kasan/report.c:412
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
memcpy+0x37/0x50 mm/kasan/kasan.c:303
strlcpy include/linux/string.h:300 [inline]
ipip6_tunnel_locate+0x63b/0xaa0 net/ipv6/sit.c:254
ipip6_tunnel_ioctl+0xe71/0x241b net/ipv6/sit.c:1221
dev_ifsioc+0x43e/0xb90 net/core/dev_ioctl.c:334
dev_ioctl+0x69a/0xcc0 net/core/dev_ioctl.c:525
sock_ioctl+0x47e/0x680 net/socket.c:1015
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:500 [inline]
do_vfs_ioctl+0x1cf/0x1650 fs/ioctl.c:684
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
SYSC_ioctl fs/ioctl.c:708 [inline]
SyS_ioctl+0x24/0x30 fs/ioctl.c:706
do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
---
net/ipv6/sit.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 1522bcfd253fcc0a01a4daa0ebcfb8bf154ab5dc..2afce37a71776f5ebd44d20e2d064909cb91f8dd 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -250,11 +250,13 @@ static struct ip_tunnel *ipip6_tunnel_locate(struct net *net,
if (!create)
goto failed;
- if (parms->name[0])
+ if (parms->name[0]) {
+ if (!dev_valid_name(parms->name))
+ goto failed;
strlcpy(name, parms->name, IFNAMSIZ);
- else
+ } else {
strcpy(name, "sit%d");
-
+ }
dev = alloc_netdev(sizeof(*t), name, NET_NAME_UNKNOWN,
ipip6_tunnel_setup);
if (!dev)
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply related
* [PATCH net 2/6] ip_tunnel: better validate user provided tunnel names
From: Eric Dumazet @ 2018-04-05 13:39 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Steffen Klassert, Eric Dumazet, Eric Dumazet
In-Reply-To: <20180405133931.207634-1-edumazet@google.com>
Use dev_valid_name() to make sure user does not provide illegal
device name.
syzbot caught the following bug :
BUG: KASAN: stack-out-of-bounds in strlcpy include/linux/string.h:300 [inline]
BUG: KASAN: stack-out-of-bounds in __ip_tunnel_create+0xca/0x6b0 net/ipv4/ip_tunnel.c:257
Write of size 20 at addr ffff8801ac79f810 by task syzkaller268107/4482
CPU: 0 PID: 4482 Comm: syzkaller268107 Not tainted 4.16.0+ #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x1b9/0x29f lib/dump_stack.c:53
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0xac/0x2f5 mm/kasan/report.c:412
check_memory_region_inline mm/kasan/kasan.c:260 [inline]
check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
memcpy+0x37/0x50 mm/kasan/kasan.c:303
strlcpy include/linux/string.h:300 [inline]
__ip_tunnel_create+0xca/0x6b0 net/ipv4/ip_tunnel.c:257
ip_tunnel_create net/ipv4/ip_tunnel.c:352 [inline]
ip_tunnel_ioctl+0x818/0xd40 net/ipv4/ip_tunnel.c:861
ipip_tunnel_ioctl+0x1c5/0x420 net/ipv4/ipip.c:350
dev_ifsioc+0x43e/0xb90 net/core/dev_ioctl.c:334
dev_ioctl+0x69a/0xcc0 net/core/dev_ioctl.c:525
sock_ioctl+0x47e/0x680 net/socket.c:1015
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:500 [inline]
do_vfs_ioctl+0x1cf/0x1650 fs/ioctl.c:684
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:701
SYSC_ioctl fs/ioctl.c:708 [inline]
SyS_ioctl+0x24/0x30 fs/ioctl.c:706
do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x42/0xb7
Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
---
net/ipv4/ip_tunnel.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index de6d94482fe7ef6be52eeea3291849cfb9d961f9..6b0e362cc99b5d3510ea7aa8db68dcb5c8eb675c 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -253,13 +253,14 @@ static struct net_device *__ip_tunnel_create(struct net *net,
struct net_device *dev;
char name[IFNAMSIZ];
- if (parms->name[0])
+ err = -E2BIG;
+ if (parms->name[0]) {
+ if (!dev_valid_name(parms->name))
+ goto failed;
strlcpy(name, parms->name, IFNAMSIZ);
- else {
- if (strlen(ops->kind) > (IFNAMSIZ - 3)) {
- err = -E2BIG;
+ } else {
+ if (strlen(ops->kind) > (IFNAMSIZ - 3))
goto failed;
- }
strlcpy(name, ops->kind, IFNAMSIZ);
strncat(name, "%d", 2);
}
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply related
* [PATCH net 1/6] net: fool proof dev_valid_name()
From: Eric Dumazet @ 2018-04-05 13:39 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Steffen Klassert, Eric Dumazet, Eric Dumazet
In-Reply-To: <20180405133931.207634-1-edumazet@google.com>
We want to use dev_valid_name() to validate tunnel names,
so better use strnlen(name, IFNAMSIZ) than strlen(name) to make
sure to not upset KASAN.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 9b04a9fd1dfd0e065a7fe798dd840a07f0e0a4df..969462ebb296250fe5f3b7c4621e9ba9720a2dbe 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1027,7 +1027,7 @@ bool dev_valid_name(const char *name)
{
if (*name == '\0')
return false;
- if (strlen(name) >= IFNAMSIZ)
+ if (strnlen(name, IFNAMSIZ) == IFNAMSIZ)
return false;
if (!strcmp(name, ".") || !strcmp(name, ".."))
return false;
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply related
* [PATCH net 0/6] net: better validate user provided tunnel names
From: Eric Dumazet @ 2018-04-05 13:39 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Steffen Klassert, Eric Dumazet, Eric Dumazet
This series changes dev_valid_name() to not attempt reading
a possibly too long user-provided device name, then use
this helper in five different tunnel providers.
Eric Dumazet (6):
net: fool proof dev_valid_name()
ip_tunnel: better validate user provided tunnel names
ipv6: sit: better validate user provided tunnel names
ip6_gre: better validate user provided tunnel names
ip6_tunnel: better validate user provided tunnel names
vti6: better validate user provided tunnel names
net/core/dev.c | 2 +-
net/ipv4/ip_tunnel.c | 11 ++++++-----
net/ipv6/ip6_gre.c | 8 +++++---
net/ipv6/ip6_tunnel.c | 11 +++++++----
net/ipv6/ip6_vti.c | 7 +++++--
net/ipv6/sit.c | 8 +++++---
6 files changed, 29 insertions(+), 18 deletions(-)
--
2.17.0.484.g0c8726318c-goog
^ permalink raw reply
* [PATCH] net: phy: marvell: Enable interrupt function on LED2 pin
From: Esben Haabendal @ 2018-04-05 13:35 UTC (permalink / raw)
To: netdev
Cc: Esben Haabendal, Rasmus Villemoes, Andrew Lunn, Florian Fainelli,
open list
From: Esben Haabendal <eha@deif.com>
The LED2[2]/INTn pin on Marvell 88E1318S as well as 88E1510/12/14/18 needs
to be configured to be usable as interrupt not only when WOL is enabled,
but whenever we rely on interrupts from the PHY.
Signed-off-by: Esben Haabendal <eha@deif.com>
Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
drivers/net/phy/marvell.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 0e0978d8a0eb..f03a510f1247 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -457,6 +457,21 @@ static int marvell_of_reg_init(struct phy_device *phydev)
}
#endif /* CONFIG_OF_MDIO */
+static int m88e1318_config_intr(struct phy_device *phydev)
+{
+ int err;
+
+ err = marvell_config_intr(phydev);
+ if (err)
+ return err;
+
+ /* Setup LED[2] as interrupt pin (active low) */
+ return phy_modify(phydev, MII_88E1318S_PHY_LED_TCR,
+ MII_88E1318S_PHY_LED_TCR_FORCE_INT,
+ MII_88E1318S_PHY_LED_TCR_INTn_ENABLE |
+ MII_88E1318S_PHY_LED_TCR_INT_ACTIVE_LOW);
+}
+
static int m88e1121_config_aneg_rgmii_delays(struct phy_device *phydev)
{
int mscr;
@@ -2090,7 +2105,7 @@ static struct phy_driver marvell_drivers[] = {
.config_aneg = &m88e1318_config_aneg,
.read_status = &marvell_read_status,
.ack_interrupt = &marvell_ack_interrupt,
- .config_intr = &marvell_config_intr,
+ .config_intr = &m88e1318_config_intr,
.did_interrupt = &m88e1121_did_interrupt,
.get_wol = &m88e1318_get_wol,
.set_wol = &m88e1318_set_wol,
@@ -2189,7 +2204,7 @@ static struct phy_driver marvell_drivers[] = {
.config_aneg = &m88e1510_config_aneg,
.read_status = &marvell_read_status,
.ack_interrupt = &marvell_ack_interrupt,
- .config_intr = &marvell_config_intr,
+ .config_intr = &m88e1318_config_intr,
.did_interrupt = &m88e1121_did_interrupt,
.get_wol = &m88e1318_get_wol,
.set_wol = &m88e1318_set_wol,
--
2.16.3
^ permalink raw reply related
* Re: [PATCH 00/12] Ethernet: Add and use ether_<type>_addr globals
From: Felix Fietkau @ 2018-04-05 13:27 UTC (permalink / raw)
To: Joe Perches, netdev, linux-wireless, b43-dev, bridge,
netfilter-devel, coreteam
Cc: brcm80211-dev-list.pdl, linux-kernel, brcm80211-dev-list
In-Reply-To: <cover.1522479607.git.joe@perches.com>
On 2018-03-31 09:05, Joe Perches wrote:
> There are many local static and non-static arrays that are used for
> Ethernet broadcast address output or comparison.
>
> Centralize the array into a single separate file and remove the local
> arrays.
I suspect that for many targets and configurations, the local arrays
might actually be smaller than exporting a global. You have to factor in
not just the .text size, but the fact that referencing an exported
symbol needs a .reloc entry as well, which also eats up some space (at
least when the code is being built as module).
In my opinion, your series probably causes more bloat in common
configurations instead of reducing it.
You're also touching several places that could easily use
eth_broadcast_addr and eth_zero_addr. I think making those changes would
be more productive than what you did in this series.
- Felix
^ permalink raw reply
* net_dim() may use uninitialized data
From: Geert Uytterhoeven @ 2018-04-05 13:13 UTC (permalink / raw)
To: Tal Gilboa; +Cc: netdev, Linux Kernel Mailing List
Hi Tal,
With gcc-4.1.2:
drivers/net/ethernet/broadcom/bcmsysport.c: In function ‘bcm_sysport_poll’:
include/linux/net_dim.h:354: warning: ‘curr_stats.ppms’ may be
used uninitialized in this function
include/linux/net_dim.h:354: warning: ‘curr_stats.bpms’ may be
used uninitialized in this function
include/linux/net_dim.h:354: warning: ‘curr_stats.epms’ may be
used uninitialized in this function
Indeed, ...
| static inline void net_dim_calc_stats(struct net_dim_sample *start,
| struct net_dim_sample *end,
| struct net_dim_stats *curr_stats)
| {
| /* u32 holds up to 71 minutes, should be enough */
| u32 delta_us = ktime_us_delta(end->time, start->time);
| u32 npkts = BIT_GAP(BITS_PER_TYPE(u32), end->pkt_ctr, start->pkt_ctr);
| u32 nbytes = BIT_GAP(BITS_PER_TYPE(u32), end->byte_ctr,
| start->byte_ctr);
|
| if (!delta_us)
| return;
... if delta_us is zero, none of the below will be initialized ...
| curr_stats->ppms = DIV_ROUND_UP(npkts * USEC_PER_MSEC, delta_us);
| curr_stats->bpms = DIV_ROUND_UP(nbytes * USEC_PER_MSEC, delta_us);
| curr_stats->epms = DIV_ROUND_UP(NET_DIM_NEVENTS * USEC_PER_MSEC,
| delta_us);
| }
|
| static inline void net_dim(struct net_dim *dim,
| struct net_dim_sample end_sample)
| {
| struct net_dim_stats curr_stats;
| u16 nevents;
|
| switch (dim->state) {
| case NET_DIM_MEASURE_IN_PROGRESS:
| nevents = BIT_GAP(BITS_PER_TYPE(u16),
| end_sample.event_ctr,
| dim->start_sample.event_ctr);
| if (nevents < NET_DIM_NEVENTS)
| break;
| net_dim_calc_stats(&dim->start_sample, &end_sample,
| &curr_stats);
... in the output parameter curr_stats ...
| if (net_dim_decision(&curr_stats, dim)) {
... and net_dim_decision will make some funky decisions based on
uninitialized data.
What are the proper values to initialize curr_stats with?
Alternatively, perhaps the call to net_dim_decision() should be made
dependent on delta_us being non-zero?
| dim->state = NET_DIM_APPLY_NEW_PROFILE;
| schedule_work(&dim->work);
| break;
| }
| /* fall through */
| case NET_DIM_START_MEASURE:
| dim->state = NET_DIM_MEASURE_IN_PROGRESS;
| break;
| case NET_DIM_APPLY_NEW_PROFILE:
| break;
| }
| }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac
From: Kalle Valo @ 2018-04-05 13:10 UTC (permalink / raw)
To: Ulf Hansson
Cc: Arend van Spriel, Florian Fainelli, Alexey Roslyakov, Andrew Lunn,
Rob Herring, Mark Rutland, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, netdev, linux-wireless, devicetree,
Linux Kernel Mailing List, brcm80211-dev-list.pdl,
brcm80211-dev-list
In-Reply-To: <CAPDyKFr2GVB0+UUpT3GgGBT17TMcrky6X4L_pw+ztTL6ejbCwQ@mail.gmail.com>
Ulf Hansson <ulf.hansson@linaro.org> writes:
> On 20 March 2018 at 10:55, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Arend van Spriel <arend.vanspriel@broadcom.com> writes:
>>
>>>>> If I get it right, you mean something like this:
>>>>>
>>>>> mmc3: mmc@1c12000 {
>>>>> ...
>>>>> broken-sg-support;
>>>>> sd-head-align = 4;
>>>>> sd-sgentry-align = 512;
>>>>>
>>>>> brcmf: wifi@1 {
>>>>> ...
>>>>> };
>>>>> };
>>>>>
>>>>> Where dt: bindings documentation for these entries should reside?
>>>>> In generic MMC bindings? Well, this is the very special case and
>>>>> mmc-linux maintainer will unlikely to accept these changes.
>>>>> Also, extra kernel code modification might be required. It could make
>>>>> quite trivial change much more complex.
>>>>
>>>> If the MMC maintainers are not copied on this patch series, it will
>>>> likely be hard for them to identify this patch series and chime in...
>>>
>>> The main question is whether this is indeed a "very special case" as
>>> Alexey claims it to be or that it is likely to be applicable to other
>>> device and host combinations as you are suggesting.
>>>
>>> If these properties are imposed by the host or host controller it
>>> would make sense to have these in the mmc bindings.
>>
>> BTW, last year we were discussing something similar (I mean related to
>> alignment requirements) with ath10k SDIO patches and at the time the
>> patch submitter was proposing to have a bounce buffer in ath10k to
>> workaround that. I don't remember the details anymore, they are on the
>> ath10k mailing list archive if anyone is curious to know, but I would
>> not be surprised if they are similar as here. So there might be a need
>> to solve this in a generic way (but not sure of course as I haven't
>> checked the details).
>
> I re-call something about these as well, here are the patches. Perhaps
> I should pick some of them up...
>
> https://patchwork.kernel.org/patch/10123137/
> https://patchwork.kernel.org/patch/10123139/
> https://patchwork.kernel.org/patch/10123141/
> https://patchwork.kernel.org/patch/10123143/
Actually I was talking about a different patch, found it now:
ath10k_sdio: DMA bounce buffers for read write
https://patchwork.kernel.org/patch/9979543/
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH net-next] netns: filter uevents correctly
From: Kirill Tkhai @ 2018-04-05 13:01 UTC (permalink / raw)
To: Christian Brauner, ebiederm, davem, gregkh, netdev, linux-kernel
Cc: avagin, serge
In-Reply-To: <20180404194857.29375-1-christian.brauner@ubuntu.com>
On 04.04.2018 22:48, Christian Brauner wrote:
> commit 07e98962fa77 ("kobject: Send hotplug events in all network namespaces")
>
> enabled sending hotplug events into all network namespaces back in 2010.
> Over time the set of uevents that get sent into all network namespaces has
> shrunk. We have now reached the point where hotplug events for all devices
> that carry a namespace tag are filtered according to that namespace.
>
> Specifically, they are filtered whenever the namespace tag of the kobject
> does not match the namespace tag of the netlink socket. One example are
> network devices. Uevents for network devices only show up in the network
> namespaces these devices are moved to or created in.
>
> However, any uevent for a kobject that does not have a namespace tag
> associated with it will not be filtered and we will *try* to broadcast it
> into all network namespaces.
>
> The original patchset was written in 2010 before user namespaces were a
> thing. With the introduction of user namespaces sending out uevents became
> partially isolated as they were filtered by user namespaces:
>
> net/netlink/af_netlink.c:do_one_broadcast()
>
> if (!net_eq(sock_net(sk), p->net)) {
> if (!(nlk->flags & NETLINK_F_LISTEN_ALL_NSID))
> return;
>
> if (!peernet_has_id(sock_net(sk), p->net))
> return;
>
> if (!file_ns_capable(sk->sk_socket->file, p->net->user_ns,
> CAP_NET_BROADCAST))
> j return;
> }
>
> The file_ns_capable() check will check whether the caller had
> CAP_NET_BROADCAST at the time of opening the netlink socket in the user
> namespace of interest. This check is fine in general but seems insufficient
> to me when paired with uevents. The reason is that devices always belong to
> the initial user namespace so uevents for kobjects that do not carry a
> namespace tag should never be sent into another user namespace. This has
> been the intention all along. But there's one case where this breaks,
> namely if a new user namespace is created by root on the host and an
> identity mapping is established between root on the host and root in the
> new user namespace. Here's a reproducer:
>
> sudo unshare -U --map-root
> udevadm monitor -k
> # Now change to initial user namespace and e.g. do
> modprobe kvm
> # or
> rmmod kvm
>
> will allow the non-initial user namespace to retrieve all uevents from the
> host. This seems very anecdotal given that in the general case user
> namespaces do not see any uevents and also can't really do anything useful
> with them.
>
> Additionally, it is now possible to send uevents from userspace. As such we
> can let a sufficiently privileged (CAP_SYS_ADMIN in the owning user
> namespace of the network namespace of the netlink socket) userspace process
> make a decision what uevents should be sent.
>
> This makes me think that we should simply ensure that uevents for kobjects
> that do not carry a namespace tag are *always* filtered by user namespace
> in kobj_bcast_filter(). Specifically:
> - If the owning user namespace of the uevent socket is not init_user_ns the
> event will always be filtered.
> - If the network namespace the uevent socket belongs to was created in the
> initial user namespace but was opened from a non-initial user namespace
> the event will be filtered as well.
> Put another way, uevents for kobjects not carrying a namespace tag are now
> always only sent to the initial user namespace. The regression potential
> for this is near to non-existent since user namespaces can't really do
> anything with interesting devices.
>
> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
> ---
> lib/kobject_uevent.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
> index 15ea216a67ce..cb98cddb6e3b 100644
> --- a/lib/kobject_uevent.c
> +++ b/lib/kobject_uevent.c
> @@ -251,7 +251,15 @@ static int kobj_bcast_filter(struct sock *dsk, struct sk_buff *skb, void *data)
> return sock_ns != ns;
> }
>
> - return 0;
> + /*
> + * The kobject does not carry a namespace tag so filter by user
> + * namespace below.
> + */
> + if (sock_net(dsk)->user_ns != &init_user_ns)
> + return 1;
> +
> + /* Check if socket was opened from non-initial user namespace. */
> + return sk_user_ns(dsk) != &init_user_ns;
> }
> #endif
So, this prohibits to listen events of all devices except network-related
in containers? If it's so, I don't think it's a good solution. Uevents is not
net-devices-only related interface and it's used for all devices in system.
People may want to delegate block devices to nested user_ns, for example.
Better we should think about something like "generic device <-> user_ns" connection,
and to filter events by this user_ns.
Thanks,
Kirill
^ permalink raw reply
* Re: [PATCH 06/12] wireless: Convert simple uses of a static const Ethernet broadcast address
From: Kalle Valo @ 2018-04-05 12:48 UTC (permalink / raw)
To: Joe Perches
Cc: Christian Lamparter, Amitkumar Karwar, Nishant Sarmukadam,
Ganapathi Bhat, Xinming Hu, Ping-Ke Shih, Jussi Kivilinna,
linux-wireless, netdev, linux-kernel, b43-dev
In-Reply-To: <87po3desix.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Joe Perches <joe@perches.com> writes:
>
>> Use the new ether_broadcast_addr global instead to save some object code.
>>
>> Signed-off-by: Joe Perches <joe@perches.com>
>> ---
>> drivers/net/wireless/admtek/adm8211.c | 3 +--
>> drivers/net/wireless/ath/carl9170/mac.c | 4 +---
>> drivers/net/wireless/broadcom/b43/main.c | 3 +--
>> drivers/net/wireless/marvell/mwifiex/cfg80211.c | 3 +--
>> drivers/net/wireless/realtek/rtlwifi/core.c | 5 ++---
>> drivers/net/wireless/rndis_wlan.c | 6 +-----
>> drivers/net/wireless/ti/wl1251/main.c | 5 +----
>> drivers/net/wireless/ti/wlcore/main.c | 5 +----
>> 8 files changed, 9 insertions(+), 25 deletions(-)
>
> It would be really helpful if you could CLEARLY document in the patches
> (or in the cover letter but then you need to cc all parties) to what
> tree the patches are meant for. Otherwise I, and other maintainers as
> well, need to waste time trying to guess what's your plan.
Forgot to mention that for me the best approach is to have the tree name
in subject, just like Dave and Linus both recommend:
[PATCH 06/12 wireless-drivers-next] wireless: Convert simple uses of a static const Ethernet broadcast address
This way I can immeaditely see from patchwork to which tree the patch
should go which helps tremendously. And if the tree name is too long you
can always shorten it to w-d and w-d-next.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
From: Andrew Lunn @ 2018-04-05 12:48 UTC (permalink / raw)
To: Laurentiu Tudor
Cc: Stuart Yoder, Arnd Bergmann, Ioana Ciornei, gregkh,
Linux Kernel Mailing List, Ruxandra Ioana Ciocoi Radulescu,
Razvan Stefanescu, Roy Pledge, Networking
In-Reply-To: <5AC61393.7090509@nxp.com>
> > Hi Laurentiu
> >
> > So i can use switchdev without it? I can modprobe the switchdev
> > driver, all the physical interfaces will appear, and i can use ip addr
> > add etc. I do not need to use a user space tool at all in order to use
> > the network functionality?
>
> Absolutely!
Great.
Then the easiest way forwards is to simply drop the IOCTL code for the
moment. Get the basic support for the hardware into the kernel
first. Then come back later to look at dynamic behaviour which needs
some form of configuration.
> In normal use cases the system designer, depending on the requirements,
> configures the various devices that it desires through a firmware
> configuration (think something like a device tree). The devices
> configured are presented on the mc-bus and probed normally by the
> kernel. The standard networking linux tools can be used as expected.
So what you should probably do is start a discussion on what this
device tree binding looks like. But you need to be careful even
here. Device tree describes the hardware, not how you configure the
hardware. So maybe DT does not actually fit.
Andrew
^ permalink raw reply
* Re: [PATCH 06/12] wireless: Convert simple uses of a static const Ethernet broadcast address
From: Kalle Valo @ 2018-04-05 12:39 UTC (permalink / raw)
To: Joe Perches
Cc: Christian Lamparter, Amitkumar Karwar, Nishant Sarmukadam,
Ganapathi Bhat, Xinming Hu, Ping-Ke Shih, Jussi Kivilinna,
linux-wireless, netdev, linux-kernel, b43-dev
In-Reply-To: <79196f134a513d50968e8e208a0e56b3c0236ee3.1522479607.git.joe@perches.com>
Joe Perches <joe@perches.com> writes:
> Use the new ether_broadcast_addr global instead to save some object code.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/net/wireless/admtek/adm8211.c | 3 +--
> drivers/net/wireless/ath/carl9170/mac.c | 4 +---
> drivers/net/wireless/broadcom/b43/main.c | 3 +--
> drivers/net/wireless/marvell/mwifiex/cfg80211.c | 3 +--
> drivers/net/wireless/realtek/rtlwifi/core.c | 5 ++---
> drivers/net/wireless/rndis_wlan.c | 6 +-----
> drivers/net/wireless/ti/wl1251/main.c | 5 +----
> drivers/net/wireless/ti/wlcore/main.c | 5 +----
> 8 files changed, 9 insertions(+), 25 deletions(-)
It would be really helpful if you could CLEARLY document in the patches
(or in the cover letter but then you need to cc all parties) to what
tree the patches are meant for. Otherwise I, and other maintainers as
well, need to waste time trying to guess what's your plan.
I will now drop the four wireless patches from my queue. So if you want
to me to take them please resubmit.
--
Kalle Valo
^ permalink raw reply
* Re: [v2] net: thunderx: nicvf_main: Fix potential NULL pointer dereferences
From: Vadim Lomovtsev @ 2018-04-05 12:38 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Eric Dumazet, Sunil Goutham, Robert Richter, linux-arm-kernel,
netdev, linux-kernel
In-Reply-To: <20180403220423.GA718@embeddedor.com>
Hi guys,
Please give me couple days to workout solution for this.
I'll post patch for this as soon as I done with my testing.
WBR,
Vadim
On Tue, Apr 03, 2018 at 05:04:23PM -0500, Gustavo A. R. Silva wrote:
> Add null check on kmalloc() return value in order to prevent
> a null pointer dereference.
>
> Addresses-Coverity-ID: 1467429 ("Dereference null return value")
> Fixes: 37c3347eb247 ("net: thunderx: add ndo_set_rx_mode callback implementation for VF")
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> Changes in v2:
> - Add a null check on a second kmalloc a few lines below. Thanks to
> Eric Dumazet for pointing this out.
>
> drivers/net/ethernet/cavium/thunder/nicvf_main.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> index 1e9a31f..f7b5ca5 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> @@ -1999,10 +1999,14 @@ static void nicvf_set_rx_mode(struct net_device *netdev)
> struct xcast_addr *xaddr;
>
> mc_list = kmalloc(sizeof(*mc_list), GFP_ATOMIC);
> + if (unlikely(!mc_list))
> + return;
> INIT_LIST_HEAD(&mc_list->list);
> netdev_hw_addr_list_for_each(ha, &netdev->mc) {
> xaddr = kmalloc(sizeof(*xaddr),
> GFP_ATOMIC);
> + if (unlikely(!xaddr))
> + return;
> xaddr->addr =
> ether_addr_to_u64(ha->addr);
> list_add_tail(&xaddr->list,
^ permalink raw reply
* Re: [PATCH ethtool] ethtool: Add register dump support for MICROCHIP LAN78xx
From: Andrew Lunn @ 2018-04-05 12:37 UTC (permalink / raw)
To: Raghuram Chary J; +Cc: davem, netdev, unglinuxdriver, woojung.huh
In-Reply-To: <20180405061128.5479-1-raghuramchary.jallipalli@microchip.com>
On Thu, Apr 05, 2018 at 11:41:28AM +0530, Raghuram Chary J wrote:
Hi Raghuram
> + fprintf(stdout, "PHY Registers:\n");
> + fprintf(stdout, "--------------\n");
> + fprintf(stdout, "Mode Control = 0x%04X\n", *lan78xx_reg++);
> + fprintf(stdout, "Mode Status = 0x%04X\n", *lan78xx_reg++);
> + fprintf(stdout, "Device identifier1 = 0x%04X\n", *lan78xx_reg++);
> + fprintf(stdout, "Device identifier2 = 0x%04X\n", *lan78xx_reg++);
> + fprintf(stdout, "Auto-Neg Advertisement = 0x%04X\n",
> + *lan78xx_reg++);
> + fprintf(stdout, "Auto-Neg Link Partner Ability = 0x%04X\n",
> + *lan78xx_reg++);
> + fprintf(stdout, "Auto-Neg Expansion = 0x%04X\n", *lan78xx_reg++);
> + fprintf(stdout, "Auto-Neg Next Page TX = 0x%04X\n", *lan78xx_reg++);
> + fprintf(stdout, "Auto-Neg Link Partner Next Page RX = 0x%04X\n",
> + *lan78xx_reg++);
> + fprintf(stdout, "1000BASE-T Control = 0x%04X\n", *lan78xx_reg++);
> + fprintf(stdout, "1000BASE-T Status = 0x%04X\n", *lan78xx_reg++);
> + fprintf(stdout, "Reserved = 0x%04X\n", *lan78xx_reg++);
> + fprintf(stdout, "Reserved = 0x%04X\n", *lan78xx_reg++);
> + fprintf(stdout, "MMD Access Control = 0x%04X\n", *lan78xx_reg++);
> + fprintf(stdout, "MMD Access Address/Data = 0x%04X\n", *lan78xx_reg++);
Do the above registers conform to the normal MII definitions? Have you
looked at the code in netsemi.c? Maybe a generic helper can be defined
which dumps standard PHY registers?
Andrew
^ permalink raw reply
* Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
From: gregkh @ 2018-04-05 12:30 UTC (permalink / raw)
To: Laurentiu Tudor
Cc: Andrew Lunn, Stuart Yoder, Arnd Bergmann, Ioana Ciornei,
Linux Kernel Mailing List, Ruxandra Ioana Ciocoi Radulescu,
Razvan Stefanescu, Roy Pledge, Networking
In-Reply-To: <5AC5FAA8.80409@nxp.com>
On Thu, Apr 05, 2018 at 10:30:01AM +0000, Laurentiu Tudor wrote:
> Hello,
>
> My 2c below.
>
> On 04/04/2018 03:42 PM, Andrew Lunn wrote:
> >> I hear you. It is more complicated this way...having all these individual
> >> objects vs just a single "bundle" of them that represents a NIC. But, that's
> >> the way the DPAA2 hardware is, and we're implementing kernel support for
> >> the hardware as it is.
> >
> > Hi Stuart
> >
> > I see we are not making any progress here.
> >
> > So what i suggest is you post the kernel code and configuration tool
> > concept to netdev for a full review. You want reviews from David
> > Miller, Jiri Pirko, Jakub Kicinski, David Ahern, etc.
> >
>
> I think that the discussion steered too much towards networking related
> topics, while this ioctl doesn't have much to do with networking.
> It's just an ioctl for our mc-bus bus driver that is used to manage the
> devices on this bus through userspace tools.
> In addition, I'd drop any mention of our reference user space app
> (restool) to emphasize that this ioctl is not added just for a
> particular user space app. I think Stuart also mentioned this.
I'm not going to take a "generic device configuration ioctl" patch
unless it is documented to all exactly what it does, and why it is
there.
thanks,
greg k-h
^ permalink raw reply
* Re: marvell switch
From: Andrew Lunn @ 2018-04-05 12:22 UTC (permalink / raw)
To: Ran Shalit; +Cc: netdev
In-Reply-To: <CAJ2oMh+binZ1QhEUfnHxU5TVfhCT1FPuiWCyAwyxxzcxEUn5Gg@mail.gmail.com>
On Thu, Apr 05, 2018 at 05:47:24AM +0300, Ran Shalit wrote:
> Hello,
>
> I am trying to use marvell switch in linux,
> Is it that the kernel drivers from marvell switch are used just to
> enable all ports, or do they also provide APIs to userspace to enable
> specific ports only.
> I have not find examples or wiki for marvell switch, so I am not too
> sure as what are the drivers meant for.
Hi Ran
The Marvell driver makes each port act like a normal Linux network
interface. So if you want to enable a port, do
ip link set lan0 up
Want to add an ip address to a port
ip addr add 10.42.42.42/24 dev lan0
Want to bridge two ports
ip link add name br0 type bridge
ip link set dev br0 up
ip link set dev lan0 master br0
ip link set dev lan1 master br0
Just treat them as normal interfaces.
Andrew
^ permalink raw reply
* Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
From: Laurentiu Tudor @ 2018-04-05 12:16 UTC (permalink / raw)
To: Andrew Lunn
Cc: Stuart Yoder, Arnd Bergmann, Ioana Ciornei, gregkh,
Linux Kernel Mailing List, Ruxandra Ioana Ciocoi Radulescu,
Razvan Stefanescu, Roy Pledge, Networking
In-Reply-To: <20180405114736.GA12178@lunn.ch>
On 04/05/2018 02:47 PM, Andrew Lunn wrote:
> On Thu, Apr 05, 2018 at 10:30:01AM +0000, Laurentiu Tudor wrote:
>> Hello,
>>
>> My 2c below.
>>
>> On 04/04/2018 03:42 PM, Andrew Lunn wrote:
>>>> I hear you. It is more complicated this way...having all these individual
>>>> objects vs just a single "bundle" of them that represents a NIC. But, that's
>>>> the way the DPAA2 hardware is, and we're implementing kernel support for
>>>> the hardware as it is.
>>>
>>> Hi Stuart
>>>
>>> I see we are not making any progress here.
>>>
>>> So what i suggest is you post the kernel code and configuration tool
>>> concept to netdev for a full review. You want reviews from David
>>> Miller, Jiri Pirko, Jakub Kicinski, David Ahern, etc.
>>>
>>
>> I think that the discussion steered too much towards networking related
>> topics, while this ioctl doesn't have much to do with networking.
>
> Hi Laurentiu
>
> So i can use switchdev without it? I can modprobe the switchdev
> driver, all the physical interfaces will appear, and i can use ip addr
> add etc. I do not need to use a user space tool at all in order to use
> the network functionality?
Absolutely!
In normal use cases the system designer, depending on the requirements,
configures the various devices that it desires through a firmware
configuration (think something like a device tree). The devices
configured are presented on the mc-bus and probed normally by the
kernel. The standard networking linux tools can be used as expected.
The ioctl is necessary only for more advanced use cases that are
supported by this bus. Think "more dynamic" scenarios that involve
linking & unlinking various devices at runtime, maybe some
virtualization scenarios. Unfortunately I'm not the architect type of
guy so I don't have more specific examples to better illustrate ...
---
Best Regards, Laurentiu
^ permalink raw reply
* Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
From: Andrew Lunn @ 2018-04-05 11:47 UTC (permalink / raw)
To: Laurentiu Tudor
Cc: Stuart Yoder, Arnd Bergmann, Ioana Ciornei, gregkh,
Linux Kernel Mailing List, Ruxandra Ioana Ciocoi Radulescu,
Razvan Stefanescu, Roy Pledge, Networking
In-Reply-To: <5AC5FAA8.80409@nxp.com>
On Thu, Apr 05, 2018 at 10:30:01AM +0000, Laurentiu Tudor wrote:
> Hello,
>
> My 2c below.
>
> On 04/04/2018 03:42 PM, Andrew Lunn wrote:
> >> I hear you. It is more complicated this way...having all these individual
> >> objects vs just a single "bundle" of them that represents a NIC. But, that's
> >> the way the DPAA2 hardware is, and we're implementing kernel support for
> >> the hardware as it is.
> >
> > Hi Stuart
> >
> > I see we are not making any progress here.
> >
> > So what i suggest is you post the kernel code and configuration tool
> > concept to netdev for a full review. You want reviews from David
> > Miller, Jiri Pirko, Jakub Kicinski, David Ahern, etc.
> >
>
> I think that the discussion steered too much towards networking related
> topics, while this ioctl doesn't have much to do with networking.
Hi Laurentiu
So i can use switchdev without it? I can modprobe the switchdev
driver, all the physical interfaces will appear, and i can use ip addr
add etc. I do not need to use a user space tool at all in order to use
the network functionality?
Andrew
^ permalink raw reply
* [PATCH 2/2] net: phy: dp83640: Read strapped configuration settings
From: esben.haabendal @ 2018-04-05 11:44 UTC (permalink / raw)
To: Richard Cochran, Andrew Lunn, Florian Fainelli,
open list:PTP HARDWARE CLOCK SUPPORT, open list
Cc: Esben Haabendal, Rasmus Villemoes
In-Reply-To: <20180405114424.8519-1-esben.haabendal@gmail.com>
From: Esben Haabendal <eha@deif.com>
Read configration settings, to allow automatic forced speed/duplex setup
by hardware strapping.
Signed-off-by: Esben Haabendal <eha@deif.com>
Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
drivers/net/phy/dp83640.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index 654f42d00092..01e21b4998ad 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -1134,6 +1134,10 @@ static int dp83640_probe(struct phy_device *phydev)
if (!dp83640)
goto no_memory;
+ err = genphy_read_config(phydev);
+ if (err)
+ goto no_config;
+
dp83640->phydev = phydev;
INIT_DELAYED_WORK(&dp83640->ts_work, rx_timestamp_work);
@@ -1166,6 +1170,7 @@ static int dp83640_probe(struct phy_device *phydev)
no_register:
clock->chosen = NULL;
+no_config:
kfree(dp83640);
no_memory:
dp83640_clock_put(clock);
--
2.16.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox