* [patch net-next v3 0/2] selftests: netdevsim: add devlink paramstests
From: Jiri Pirko @ 2019-08-15 13:42 UTC (permalink / raw)
To: netdev; +Cc: davem, jakub.kicinski, mlxsw
From: Jiri Pirko <jiri@mellanox.com>
The first patch is just a helper addition as a dependency of the actual
test in patch number two.
Jiri Pirko (2):
selftests: net: push jq workaround into separate helper
selftests: netdevsim: add devlink params tests
.../drivers/net/netdevsim/devlink.sh | 62 ++++++++++++++++++-
tools/testing/selftests/net/forwarding/lib.sh | 19 ++++++
.../selftests/net/forwarding/tc_common.sh | 17 ++---
3 files changed, 84 insertions(+), 14 deletions(-)
--
2.21.0
^ permalink raw reply
* Re: [PATCH net-next] mcast: ensure L-L IPv6 packets are accepted by bridge
From: Patrick Ruddy @ 2019-08-15 13:36 UTC (permalink / raw)
To: Nikolay Aleksandrov, Linus Lüssing
Cc: bridge, Ido Schimmel, netdev, roopa
In-Reply-To: <d0be5038-e76f-d21b-a034-e450cbb3010e@cumulusnetworks.com>
On Wed, 2019-08-14 at 23:34 +0300, Nikolay Aleksandrov wrote:
> On 8/14/19 11:11 PM, Linus Lüssing wrote:
> > On Wed, Aug 14, 2019 at 05:40:58PM +0100, Patrick Ruddy wrote:
> > > The group is being joined by MLD at the L3 level but the packets are
> > > not being passed up to the l3 interface becasue there is a MLD querier
> > > on the network
> > >
> > > snippet from /proc/net/igmp6
> > > ...
> > > 40 sw1 ff0200000000000000000001ff008700 1 00000004 0
> > > 40 sw1 ff020000000000000000000000000002 1 00000004 0
> > > 40 sw1 ff020000000000000000000000000001 1 0000000C 0
> > > 40 sw1 ff010000000000000000000000000001 1 00000008 0
> > > 41 lo1 ff020000000000000000000000000001 1 0000000C 0
> > > 41 lo1 ff010000000000000000000000000001 1 00000008 0
> > > 42 sw1.1 ff020000000000000000000000000006 1 00000004 0
> > > 42 sw1.1 ff020000000000000000000000000005 1 00000004 0
> > > 42 sw1.1 ff0200000000000000000001ff000000 2 00000004 0
> > > 42 sw1.1 ff0200000000000000000001ff008700 1 00000004 0
> > > 42 sw1.1 ff0200000000000000000001ff000099 1 00000004 0
> > > 42 sw1.1 ff020000000000000000000000000002 1 00000004 0
> > > 42 sw1.1 ff020000000000000000000000000001 1 0000000C 0
> > > 42 sw1.1 ff010000000000000000000000000001 1 00000008 0
> > > ...
> > >
> > > the bridge is sw1 and the l3 intervace is sw1.1
> >
> > What kind of interface is sw1.1 exactly? Is it a VLAN or a VRF
> > interface? Something else?
> >
> +1
>
> > Could you also post the output of bridge mdb show?
> >
> > Regards, Linus
> >
> >
> > PS: Also please include the bridge mailinglist in the future.
> >
>
> Note that if you'd like to debug a host joined group currently bridge mdb show
> will not dump it and if the group is host-joined only it
> can even be empty. You can use my latest set (not applied yet):
> https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.ozlabs.org_project_netdev_list_-3Fseries-3D125169&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=au3D9TlUU6OvFpWOU9cuIHeNeV2fw-AOF1ZqCRqsILc&m=KsdarH0MAMMoKZ4PuvHrEC57uEluTGK-XSL4uUxu9MY&s=jyoK6VVmFh1KpKZirrtUYwq9nLy8fz-GigFFLjaLsoE&e=
>
> Alternatively you could monitor the mdb events, it will show up there even
> today without any changes (bridge monitor mdb) and you can check if it's
> getting deleted.
>
> Cheers,
> Nik
The sw1.1 interface is a .1q vlan
The output of "bridge monitor mdb" is empty
I can see the incoming query and the outging report on tshark:
29002 72654.887739 fe80::4041:1ff:fe00:101 → ff02::1 ICMPv6 94
Multicast Listener Query
29003 72655.502035 fe80::eac5:7aff:fe00:8700 → ff02::16 ICMPv6 194
Multicast Listener Report Message v2
debugging shows that bridge code sees the incoming query but not the
outgoing report.
Thanks for all the pointers - I will pursue what is happening.
-pr
^ permalink raw reply
* Re: [PATCH] tun: fix use-after-free when register netdev failed
From: Yang Yingliang @ 2019-08-15 12:55 UTC (permalink / raw)
To: Jason Wang, netdev; +Cc: xiyou.wangcong, davem
In-Reply-To: <f9dd102e-e3b4-6522-6094-63aa31b890ea@redhat.com>
On 2019/8/15 17:21, Jason Wang wrote:
>
> On 2019/8/15 下午4:18, Yang Yingliang wrote:
>> I got a UAF repport in tun driver when doing fuzzy test:
>>
>> [ 466.269490]
>> ==================================================================
>> [ 466.271792] BUG: KASAN: use-after-free in
>> tun_chr_read_iter+0x2ca/0x2d0
>> [ 466.271806] Read of size 8 at addr ffff888372139250 by task
>> tun-test/2699
>> [ 466.271810]
>> [ 466.271824] CPU: 1 PID: 2699 Comm: tun-test Not tainted
>> 5.3.0-rc1-00001-g5a9433db2614-dirty #427
>> [ 466.271833] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>> BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
>> [ 466.271838] Call Trace:
>> [ 466.271858] dump_stack+0xca/0x13e
>> [ 466.271871] ? tun_chr_read_iter+0x2ca/0x2d0
>> [ 466.271890] print_address_description+0x79/0x440
>> [ 466.271906] ? vprintk_func+0x5e/0xf0
>> [ 466.271920] ? tun_chr_read_iter+0x2ca/0x2d0
>> [ 466.271935] __kasan_report+0x15c/0x1df
>> [ 466.271958] ? tun_chr_read_iter+0x2ca/0x2d0
>> [ 466.271976] kasan_report+0xe/0x20
>> [ 466.271987] tun_chr_read_iter+0x2ca/0x2d0
>> [ 466.272013] do_iter_readv_writev+0x4b7/0x740
>> [ 466.272032] ? default_llseek+0x2d0/0x2d0
>> [ 466.272072] do_iter_read+0x1c5/0x5e0
>> [ 466.272110] vfs_readv+0x108/0x180
>> [ 466.299007] ? compat_rw_copy_check_uvector+0x440/0x440
>> [ 466.299020] ? fsnotify+0x888/0xd50
>> [ 466.299040] ? __fsnotify_parent+0xd0/0x350
>> [ 466.299064] ? fsnotify_first_mark+0x1e0/0x1e0
>> [ 466.304548] ? vfs_write+0x264/0x510
>> [ 466.304569] ? ksys_write+0x101/0x210
>> [ 466.304591] ? do_preadv+0x116/0x1a0
>> [ 466.304609] do_preadv+0x116/0x1a0
>> [ 466.309829] do_syscall_64+0xc8/0x600
>> [ 466.309849] entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> [ 466.309861] RIP: 0033:0x4560f9
>> [ 466.309875] Code: 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
>> 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24
>> 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64
>> 89 01 48
>> [ 466.309889] RSP: 002b:00007ffffa5166e8 EFLAGS: 00000206 ORIG_RAX:
>> 0000000000000127
>> [ 466.322992] RAX: ffffffffffffffda RBX: 0000000000400460 RCX:
>> 00000000004560f9
>> [ 466.322999] RDX: 0000000000000003 RSI: 00000000200008c0 RDI:
>> 0000000000000003
>> [ 466.323007] RBP: 00007ffffa516700 R08: 0000000000000004 R09:
>> 0000000000000000
>> [ 466.323014] R10: 0000000000000000 R11: 0000000000000206 R12:
>> 000000000040cb10
>> [ 466.323021] R13: 0000000000000000 R14: 00000000006d7018 R15:
>> 0000000000000000
>> [ 466.323057]
>> [ 466.323064] Allocated by task 2605:
>> [ 466.335165] save_stack+0x19/0x80
>> [ 466.336240] __kasan_kmalloc.constprop.8+0xa0/0xd0
>> [ 466.337755] kmem_cache_alloc+0xe8/0x320
>> [ 466.339050] getname_flags+0xca/0x560
>> [ 466.340229] user_path_at_empty+0x2c/0x50
>> [ 466.341508] vfs_statx+0xe6/0x190
>> [ 466.342619] __do_sys_newstat+0x81/0x100
>> [ 466.343908] do_syscall_64+0xc8/0x600
>> [ 466.345303] entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> [ 466.347034]
>> [ 466.347517] Freed by task 2605:
>> [ 466.348471] save_stack+0x19/0x80
>> [ 466.349476] __kasan_slab_free+0x12e/0x180
>> [ 466.350726] kmem_cache_free+0xc8/0x430
>> [ 466.351874] putname+0xe2/0x120
>> [ 466.352921] filename_lookup+0x257/0x3e0
>> [ 466.354319] vfs_statx+0xe6/0x190
>> [ 466.355498] __do_sys_newstat+0x81/0x100
>> [ 466.356889] do_syscall_64+0xc8/0x600
>> [ 466.358037] entry_SYSCALL_64_after_hwframe+0x49/0xbe
>> [ 466.359567]
>> [ 466.360050] The buggy address belongs to the object at
>> ffff888372139100
>> [ 466.360050] which belongs to the cache names_cache of size 4096
>> [ 466.363735] The buggy address is located 336 bytes inside of
>> [ 466.363735] 4096-byte region [ffff888372139100, ffff88837213a100)
>> [ 466.367179] The buggy address belongs to the page:
>> [ 466.368604] page:ffffea000dc84e00 refcount:1 mapcount:0
>> mapping:ffff8883df1b4f00 index:0x0 compound_mapcount: 0
>> [ 466.371582] flags: 0x2fffff80010200(slab|head)
>> [ 466.372910] raw: 002fffff80010200 dead000000000100
>> dead000000000122 ffff8883df1b4f00
>> [ 466.375209] raw: 0000000000000000 0000000000070007
>> 00000001ffffffff 0000000000000000
>> [ 466.377778] page dumped because: kasan: bad access detected
>> [ 466.379730]
>> [ 466.380288] Memory state around the buggy address:
>> [ 466.381844] ffff888372139100: fb fb fb fb fb fb fb fb fb fb fb fb
>> fb fb fb fb
>> [ 466.384009] ffff888372139180: fb fb fb fb fb fb fb fb fb fb fb fb
>> fb fb fb fb
>> [ 466.386131] >ffff888372139200: fb fb fb fb fb fb fb fb fb fb fb fb
>> fb fb fb fb
>> [ 466.388257] ^
>> [ 466.390234] ffff888372139280: fb fb fb fb fb fb fb fb fb fb fb fb
>> fb fb fb fb
>> [ 466.392512] ffff888372139300: fb fb fb fb fb fb fb fb fb fb fb fb
>> fb fb fb fb
>> [ 466.394667]
>> ==================================================================
>>
>> tun_chr_read_iter() accessed the memory which freed by free_netdev()
>> called by tun_set_iff():
>>
>> CPUA CPUB
>> tun_set_iff()
>> alloc_netdev_mqs()
>> tun_attach()
>> tun_chr_read_iter()
>> tun_get()
>> register_netdevice()
>> tun_detach_all()
>> synchronize_net()
>> tun_do_read()
>> tun_ring_recv()
>> schedule()
>> free_netdev()
>> tun_put() <-- UAF
>>
>> Set a new bit in tun->flag if register_netdevice() successed,
>> without this bit, tun_get() returns NULL to avoid using a
>> freed tun pointer.
>
>
> Good catch.
>
> Some comments inline.
>
>
>>
>> Fixes: eb0fb363f920 ("tuntap: attach queue 0 before registering
>> netdevice")
>> Reported-by: Hulk Robot <hulkci@huawei.com>
>> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
>> ---
>> drivers/net/tun.c | 10 ++++++++--
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index db16d7a13e00..cbd60c276c40 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -115,6 +115,7 @@ do { \
>> /* High bits in flags field are unused. */
>> #define TUN_VNET_LE 0x80000000
>> #define TUN_VNET_BE 0x40000000
>> +#define TUN_DEV_REGISTERED 0x20000000
>> #define TUN_FEATURES (IFF_NO_PI | IFF_ONE_QUEUE | IFF_VNET_HDR | \
>> IFF_MULTI_QUEUE | IFF_NAPI | IFF_NAPI_FRAGS)
>> @@ -719,8 +720,10 @@ static void __tun_detach(struct tun_file *tfile,
>> bool clean)
>> netif_carrier_off(tun->dev);
>> if (!(tun->flags & IFF_PERSIST) &&
>> - tun->dev->reg_state == NETREG_REGISTERED)
>> + tun->dev->reg_state == NETREG_REGISTERED) {
>> unregister_netdevice(tun->dev);
>> + tun->flags &= ~TUN_DEV_REGISTERED;
>> + }
>> }
>> if (tun)
>> xdp_rxq_info_unreg(&tfile->xdp_rxq);
>> @@ -884,8 +887,10 @@ static struct tun_struct *tun_get(struct
>> tun_file *tfile)
>> rcu_read_lock();
>> tun = rcu_dereference(tfile->tun);
>> - if (tun)
>> + if (tun && (tun->flags & TUN_DEV_REGISTERED))
>> dev_hold(tun->dev);
>> + else
>> + tun = NULL;
>> rcu_read_unlock();
>> return tun;
>> @@ -2836,6 +2841,7 @@ static int tun_set_iff(struct net *net, struct
>> file *file, struct ifreq *ifr)
>> err = register_netdevice(tun->dev);
>> if (err < 0)
>> goto err_detach;
>> + tun->flags |= TUN_DEV_REGISTERED;
>> }
>> netif_carrier_on(tun->dev);
>
>
> This looks just a duplicated of netdev->state? However it lacks
> sufficient synchronization like barriers or locks. How about:
It's not same, register_netdevice() will return error if
call_netdevice_notifiers() failed after dev->reg_state is set to
NETREG_REGISTERED.
>
> - call tun_set_real_num_queues() before register_netdevice() this can
> have the same result as what eb0fb363f920 did.
> - move tun_attach() after register_netdevice() this makes sure we
> won't publish tfile->tun until we are sure at least one refcnt is held
> by register_netdevice()?
Yes, I think this way is better, I will try this later.
>
> Thanks
>
>
> .
>
^ permalink raw reply
* Re: [PATCH 00/14] ARM: move lpc32xx and dove to multiplatform
From: Arnd Bergmann @ 2019-08-15 13:11 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: SoC Team, Linux ARM, Vladimir Zapolskiy, Sylvain Lemieux,
Gregory Clement, Linus Walleij, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, David S. Miller, Greg Kroah-Hartman,
Alan Stern, Guenter Roeck, open list:GPIO SUBSYSTEM, Networking,
linux-serial, USB list, LINUXWATCHDOG
In-Reply-To: <CAK8P3a1Lgbz9RwVaOgNq=--gwvEG70tUi67XwsswjgnXAX6EhA@mail.gmail.com>
On Thu, Aug 1, 2019 at 9:33 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Aug 1, 2019 at 12:53 AM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Wed, Jul 31, 2019 at 09:56:42PM +0200, Arnd Bergmann wrote:
> > > For dove, the patches are basically what I had proposed back in
> > > 2015 when all other ARMv6/ARMv7 machines became part of a single
> > > kernel build. I don't know what the state is mach-dove support is,
> > > compared to the DT based support in mach-mvebu for the same
> > > hardware. If they are functionally the same, we could also just
> > > remove mach-dove rather than applying my patches.
> >
> > Well, the good news is that I'm down to a small board support file
> > for the Dove Cubox now - but the bad news is, that there's still a
> > board support file necessary to support everything the Dove SoC has
> > to offer.
> >
> > Even for a DT based Dove Cubox, I'm still using mach-dove, but it
> > may be possible to drop most of mach-dove now. Without spending a
> > lot of time digging through it, it's impossible to really know.
>
> Ok, so we won't remove it then, but I'd like to merge my patches to
> at least get away from the special case of requiring a separate kernel
> image for it.
>
> Can you try if applying patches 12 and 14 from my series causes
> problems for you? (it may be easier to apply the entire set
> or pull from [1] to avoid rebase conflicts).
I applied patches 12 and 13 into the soc tree now. There are some
other pending multiplatform conversions (iop32x, ep93xx, lpc32xx,
omap1), but it looks like none of those will be complete for 5.4.
I now expect that we can get most of the preparation into 5.4,
and maybe move them all over together in 5.5 after some more
testing. If someone finds a problem with the one of the
preparation steps, that we can revert the individual patches
more easily.
Arnd
^ permalink raw reply
* Re: [PATCH net-next 2/2] r8169: use the generic EEE management functions
From: Heiner Kallweit @ 2019-08-15 13:02 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <20190815123558.GA31172@lunn.ch>
On 15.08.2019 14:35, Andrew Lunn wrote:
> On Thu, Aug 15, 2019 at 11:47:33AM +0200, Heiner Kallweit wrote:
>> Now that the Realtek PHY driver maps the vendor-specific EEE registers
>> to the standard MMD registers, we can remove all special handling and
>> use the generic functions phy_ethtool_get/set_eee.
>
> Hi Heiner
>
Hi Andrew,
> I think you should also add a call the phy_init_eee()?
>
I think it's not strictly needed. And few things regarding
phy_init_eee are not fully clear to me:
- When is it supposed to be called? Before each call to
phy_ethtool_set_eee? Or once in the drivers init path?
- The name is a little bit misleading as it's mainly a
validity check. An actual "init" is done only if
parameter clk_stop_enable is set.
- It returns -EPROTONOSUPPORT if at least one link partner
doesn't advertise EEE for current speed/duplex. To me this
seems to be too restrictive. Example:
We're at 1Gbps/full and link partner advertises EEE for
100Mbps only. Then phy_init_eee returns -EPROTONOSUPPORT.
This keeps me from controlling 100Mbps EEE advertisement.
> Andrew
>
Heiner
^ permalink raw reply
* Re: [PATCH] tun: fix use-after-free when register netdev failed
From: Yang Yingliang @ 2019-08-15 13:01 UTC (permalink / raw)
To: Eric Dumazet, netdev; +Cc: jasowang, xiyou.wangcong, davem, Yangyingliang
In-Reply-To: <a6f519cf-95ed-02de-d432-363610e4c332@gmail.com>
On 2019/8/15 17:35, Eric Dumazet wrote:
>
> On 8/15/19 10:18 AM, Yang Yingliang wrote:
>> I got a UAF repport in tun driver when doing fuzzy test:
>>
>>
>> [ 466.368604] page:ffffea000dc84e00 refcount:1 mapcount:0 mapping:ffff8883df1b4f00 index:0x0 compound_mapcount: 0
>> [ 466.371582] flags: 0x2fffff80010200(slab|head)
>> [ 466.372910] raw: 002fffff80010200 dead000000000100 dead000000000122 ffff8883df1b4f00
>> [ 466.375209] raw: 0000000000000000 0000000000070007 00000001ffffffff 0000000000000000
>> [ 466.377778] page dumped because: kasan: bad access detected
>> [ 466.379730]
>> [ 466.380288] Memory state around the buggy address:
>> [ 466.381844] ffff888372139100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> [ 466.384009] ffff888372139180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> [ 466.386131] >ffff888372139200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> [ 466.388257] ^
>> [ 466.390234] ffff888372139280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> [ 466.392512] ffff888372139300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> [ 466.394667] ==================================================================
>>
>> tun_chr_read_iter() accessed the memory which freed by free_netdev()
>> called by tun_set_iff():
>>
>> CPUA CPUB
>> tun_set_iff()
>> alloc_netdev_mqs()
>> tun_attach()
>> tun_chr_read_iter()
>> tun_get()
>> register_netdevice()
>> tun_detach_all()
>> synchronize_net()
>> tun_do_read()
>> tun_ring_recv()
>> schedule()
>> free_netdev()
>> tun_put() <-- UAF
> UAF on what exactly ? The dev_hold() should prevent the free_netdev().
register_netdevice() is failed, so the dev is freed directly in free_netdev
().
>
>> Set a new bit in tun->flag if register_netdevice() successed,
>> without this bit, tun_get() returns NULL to avoid using a
>> freed tun pointer.
>>
>> Fixes: eb0fb363f920 ("tuntap: attach queue 0 before registering netdevice")
>> Reported-by: Hulk Robot <hulkci@huawei.com>
>> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
>> ---
>> drivers/net/tun.c | 10 ++++++++--
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index db16d7a13e00..cbd60c276c40 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -115,6 +115,7 @@ do { \
>> /* High bits in flags field are unused. */
>> #define TUN_VNET_LE 0x80000000
>> #define TUN_VNET_BE 0x40000000
>> +#define TUN_DEV_REGISTERED 0x20000000
>>
>> #define TUN_FEATURES (IFF_NO_PI | IFF_ONE_QUEUE | IFF_VNET_HDR | \
>> IFF_MULTI_QUEUE | IFF_NAPI | IFF_NAPI_FRAGS)
>> @@ -719,8 +720,10 @@ static void __tun_detach(struct tun_file *tfile, bool clean)
>> netif_carrier_off(tun->dev);
>>
>> if (!(tun->flags & IFF_PERSIST) &&
>> - tun->dev->reg_state == NETREG_REGISTERED)
>> + tun->dev->reg_state == NETREG_REGISTERED) {
>> unregister_netdevice(tun->dev);
>> + tun->flags &= ~TUN_DEV_REGISTERED;
> Isn't this done too late ?
>
>> + }
>> }
>> if (tun)
>> xdp_rxq_info_unreg(&tfile->xdp_rxq);
>> @@ -884,8 +887,10 @@ static struct tun_struct *tun_get(struct tun_file *tfile)
>>
>> rcu_read_lock();
>> tun = rcu_dereference(tfile->tun);
>> - if (tun)
>> + if (tun && (tun->flags & TUN_DEV_REGISTERED))
>> dev_hold(tun->dev);
>> + else
>> + tun = NULL;
>> rcu_read_unlock();
>>
>> return tun;
>> @@ -2836,6 +2841,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
>> err = register_netdevice(tun->dev);
>> if (err < 0)
>> goto err_detach;
>> + tun->flags |= TUN_DEV_REGISTERED;
>> }
>>
>> netif_carrier_on(tun->dev);
>>
>
> So tun_get() will return NULL as long as tun_set_iff() (TUNSETIFF ioctl()) has not yet been called ?
>
> This could break some applications, since tun_get() is used from poll() and other syscalls.
I will try Wang's sugguestion later, if it's OK, I will drop this patch.
>
> .
>
^ permalink raw reply
* Re: [PATCH bpf-next 0/5] Add support for SKIP_BPF flag for AF_XDP sockets
From: Björn Töpel @ 2019-08-15 12:51 UTC (permalink / raw)
To: Sridhar Samudrala, magnus.karlsson, netdev, bpf, intel-wired-lan,
maciej.fijalkowski, tom.herbert
In-Reply-To: <1565840783-8269-1-git-send-email-sridhar.samudrala@intel.com>
On 2019-08-15 05:46, Sridhar Samudrala wrote:
> This patch series introduces XDP_SKIP_BPF flag that can be specified
> during the bind() call of an AF_XDP socket to skip calling the BPF
> program in the receive path and pass the buffer directly to the socket.
>
> When a single AF_XDP socket is associated with a queue and a HW
> filter is used to redirect the packets and the app is interested in
> receiving all the packets on that queue, we don't need an additional
> BPF program to do further filtering or lookup/redirect to a socket.
>
> Here are some performance numbers collected on
> - 2 socket 28 core Intel(R) Xeon(R) Platinum 8180 CPU @ 2.50GHz
> - Intel 40Gb Ethernet NIC (i40e)
>
> All tests use 2 cores and the results are in Mpps.
>
> turbo on (default)
> ---------------------------------------------
> no-skip-bpf skip-bpf
> ---------------------------------------------
> rxdrop zerocopy 21.9 38.5
> l2fwd zerocopy 17.0 20.5
> rxdrop copy 11.1 13.3
> l2fwd copy 1.9 2.0
>
> no turbo : echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
> ---------------------------------------------
> no-skip-bpf skip-bpf
> ---------------------------------------------
> rxdrop zerocopy 15.4 29.0
> l2fwd zerocopy 11.8 18.2
> rxdrop copy 8.2 10.5
> l2fwd copy 1.7 1.7
> ---------------------------------------------
>
This work is somewhat similar to the XDP_ATTACH work [1]. Avoiding the
retpoline in the XDP program call is a nice performance boost! I like
the numbers! :-) I also like the idea of adding a flag that just does
what most AF_XDP Rx users want -- just getting all packets of a
certain queue into the XDP sockets.
In addition to Toke's mail, I have some more concerns with the series:
* AFAIU the SKIP_BPF only works for zero-copy enabled sockets. IMO, it
should work for all modes (including XDP_SKB).
* In order to work, a user still needs an XDP program running. That's
clunky. I'd like the behavior that if no XDP program is attached,
and the option is set, the packets for a that queue end up in the
socket. If there's an XDP program attached, the program has
precedence.
* It requires changes in all drivers. Not nice, and scales badly. Try
making it generic (xdp_do_redirect/xdp_flush), so it Just Works for
all XDP capable drivers.
Thanks for working on this!
Björn
[1]
https://lore.kernel.org/netdev/20181207114431.18038-1-bjorn.topel@gmail.com/
> Sridhar Samudrala (5):
> xsk: Convert bool 'zc' field in struct xdp_umem to a u32 bitmap
> xsk: Introduce XDP_SKIP_BPF bind option
> i40e: Enable XDP_SKIP_BPF option for AF_XDP sockets
> ixgbe: Enable XDP_SKIP_BPF option for AF_XDP sockets
> xdpsock_user: Add skip_bpf option
>
> drivers/net/ethernet/intel/i40e/i40e_txrx.c | 22 +++++++++-
> drivers/net/ethernet/intel/i40e/i40e_xsk.c | 6 +++
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 20 ++++++++-
> drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 16 ++++++-
> include/net/xdp_sock.h | 21 ++++++++-
> include/uapi/linux/if_xdp.h | 1 +
> include/uapi/linux/xdp_diag.h | 1 +
> net/xdp/xdp_umem.c | 9 ++--
> net/xdp/xsk.c | 43 ++++++++++++++++---
> net/xdp/xsk_diag.c | 5 ++-
> samples/bpf/xdpsock_user.c | 8 ++++
> 11 files changed, 135 insertions(+), 17 deletions(-)
>
^ permalink raw reply
* Re: [v2, 4/4] ocelot: add VCAP IS2 rule to trap PTP Ethernet frames
From: Andrew Lunn @ 2019-08-15 12:45 UTC (permalink / raw)
To: Y.b. Lu
Cc: Allan W . Nielsen, netdev@vger.kernel.org, David S . Miller,
Alexandre Belloni, Microchip Linux Driver Support
In-Reply-To: <VI1PR0401MB2237B2ABB288FE12072C64D1F8AC0@VI1PR0401MB2237.eurprd04.prod.outlook.com>
> [Y.b. Lu] Actually I couldn’t find reasons why make some ports PTP
> unaware, if there is software stack for PTP aware...
Maybe because i have not yet done
apt-get install linuxptp
$EDITOR /etc/defaults/ptp4l
systemctl restart ptp4l
Just because it exists does not mean it is installed.
Andrew
^ permalink raw reply
* [PATCH net-next] page_pool: remove unnecessary variable init
From: Yunsheng Lin @ 2019-08-15 12:41 UTC (permalink / raw)
To: hawk, ilias.apalodimas, davem; +Cc: netdev, linux-kernel
Remove variable initializations in functions that
are followed by assignments before use
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
---
net/core/page_pool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index 3272dc7..31187ff 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -61,7 +61,7 @@ static int page_pool_init(struct page_pool *pool,
struct page_pool *page_pool_create(const struct page_pool_params *params)
{
struct page_pool *pool;
- int err = 0;
+ int err;
pool = kzalloc_node(sizeof(*pool), GFP_KERNEL, params->nid);
if (!pool)
--
2.8.1
^ permalink raw reply related
* RE: [PATCH 3/3] ocelot_ace: fix action of trap
From: Y.b. Lu @ 2019-08-15 12:39 UTC (permalink / raw)
To: Andrew Lunn, Allan W. Nielsen, Richard Cochran
Cc: netdev@vger.kernel.org, David S . Miller, Alexandre Belloni,
Microchip Linux Driver Support
In-Reply-To: <20190814135227.GC5265@lunn.ch>
Hi Andrew and Allan,
I add Richard in email for help and some suggestions.
And please see my comments inline.
Thanks.
Hi Richard,
We are discussing problem of PTP message trapping to CPU on switch. Hope for your suggestions since you are the expert.
Here are the two versions patch-set.
V2: https://patchwork.ozlabs.org/project/netdev/list/?series=124713&state=*
V1: https://patchwork.ozlabs.org/project/netdev/list/?series=124563&state=*
Thanks in advance :)
> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Wednesday, August 14, 2019 9:52 PM
> To: Allan W. Nielsen <allan.nielsen@microchip.com>
> Cc: Y.b. Lu <yangbo.lu@nxp.com>; netdev@vger.kernel.org; David S . Miller
> <davem@davemloft.net>; Alexandre Belloni <alexandre.belloni@bootlin.com>;
> Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
> Subject: Re: [PATCH 3/3] ocelot_ace: fix action of trap
>
> On Wed, Aug 14, 2019 at 10:57:12AM +0200, Allan W. Nielsen wrote:
> > Hi Y.b. and Andrew,
> >
> > The 08/14/2019 04:28, Y.b. Lu wrote:
> > > > > I'd like to trap all IEEE 1588 PTP Ethernet frames to CPU
> > > > > through etype
> > > > 0x88f7.
> > > >
> > > > Is this the correct way to handle PTP for this switch? For other
> > > > switches we don't need such traps. The switch itself identifies
> > > > PTP frames and forwards them to the CPU so it can process them.
> > > >
> > > > I'm just wondering if your general approach is wrong?
> > >
> > > [Y.b. Lu] PTP messages over Ethernet will use two multicast addresses.
> > > 01-80-C2-00-00-0E for peer delay messages.
> > Yes, and as you write, this is a BPDU which must not be forwarded (and
> > they are not).
> >
> > > 01-1B-19-00-00-00 for other messages.
> > Yes, this is a normal L2 multicast address, which by default are broadcastet.
> >
> > > But only 01-80-C2-00-00-0E could be handled by hardware filter for
> > > BPDU frames (01-80-C2-00-00-0x). For PTP messages handling,
> > > trapping them to CPU through VCAP IS2 is the suggested way by
> Ocelot/Felix.
>
> Hi Allan
>
> The typical userspace for this is linuxptp. It implements Boundary Clock (BC),
> Ordinary Clock (OC) and Transparent Clock (TC). On switches, it works great for
> L2 PTP. But it has architectural issues for L3 PTP when used with a bridge. I've
> no idea if Richard is fixing this.
[Y.b. Lu] Right.
For the 3 scenarios Allan listed, actually I think usually the first and the second wouldn't be used if user needs 1588 synchronization.
#1 scenario, since it's PTP unaware, asymmetric delay will be introduced and it couldn't ensure sync performance.
#2 scenario, this has too much limitation. The switch hardware could only be configured as two-step end-to-end transparent clock in hardware.
For other clock types, it requires CPU handling and ptp software. In addition, ptp software takes very few resources.
So the desired scenario for 1588 synchronization should be #3 scenario.
>
> > 3) It can be done via 'tc' using the trap action, but I do not know if this is
> > the desired way of doing it.
>
> No, it is not. It could be the way you the implement
> ptp_clock_info.enable() does the same as what TC could do, but TC itself is not
> used, it should all be internal to the driver. And you might also want to
> consider hiding such rules from TC, otherwise the user might remove them and
> things break.
[Y.b. Lu] ptp_clock_info.enable() ?
As I understand, PTP clock driver is only for ptp clock operations, not for networking.
I would have intended to send PTP trapping rule patch for discussion after Felix driver is ready on upstream.
Let me just send TRAP option fix-up patch in next version. Will rework and send PTP trapping rule patch once Felix driver is accepted by upstream.
But I'd like to gather suggestions on that.
Thanks a lot.
>
> Andrew
^ permalink raw reply
* Re: [PATCH net-next] net: phy: read MII_CTRL1000 in genphy_read_status only if needed
From: Andrew Lunn @ 2019-08-15 12:37 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <84cbdf69-70b4-3dd0-c34d-7db0a4f69653@gmail.com>
On Thu, Aug 15, 2019 at 01:15:19PM +0200, Heiner Kallweit wrote:
> Value of MII_CTRL1000 is needed only if LPA_1000MSFAIL is set.
> Therefore move reading this register.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/2] r8169: use the generic EEE management functions
From: Andrew Lunn @ 2019-08-15 12:35 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <c5a137b1-d9d3-070c-55a1-938d6b77bdbc@gmail.com>
On Thu, Aug 15, 2019 at 11:47:33AM +0200, Heiner Kallweit wrote:
> Now that the Realtek PHY driver maps the vendor-specific EEE registers
> to the standard MMD registers, we can remove all special handling and
> use the generic functions phy_ethtool_get/set_eee.
Hi Heiner
I think you should also add a call the phy_init_eee()?
Andrew
^ permalink raw reply
* Re: [PATCH 1/2] usb: serial: option: Add the BroadMobi BM818 card
From: Johan Hovold @ 2019-08-15 12:28 UTC (permalink / raw)
To: Bob Ham
Cc: Johan Hovold, Angus Ainslie (Purism), kernel, Bjørn Mork,
David S. Miller, Greg Kroah-Hartman, netdev, linux-usb,
linux-kernel
In-Reply-To: <57190963-22e2-cb89-bfd0-502f135237c3@puri.sm>
[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]
On Thu, Aug 15, 2019 at 01:19:19PM +0100, Bob Ham wrote:
> On 15/08/2019 12:49, Johan Hovold wrote:
> > On Mon, Aug 05, 2019 at 03:44:30PM +0100, Bob Ham wrote:
> >> On 05/08/2019 12:47, Johan Hovold wrote:
> >>> On Wed, Jul 24, 2019 at 07:52:26AM -0700, Angus Ainslie (Purism) wrote:
> >>>> From: Bob Ham <bob.ham@puri.sm>
> >>>>
> >>>> Add a VID:PID for the BroadModi BM818 M.2 card
> >>>
> >>> Would you mind posting the output of usb-devices (or lsusb -v) for this
> >>> device?
> >>
> >> T: Bus=01 Lev=03 Prnt=40 Port=03 Cnt=01 Dev#= 44 Spd=480 MxCh= 0
> >> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
> >> P: Vendor=2020 ProdID=2060 Rev=00.00
> >> S: Manufacturer=Qualcomm, Incorporated
> >> S: Product=Qualcomm CDMA Technologies MSM
> >> C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
> >> I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
> >> I: If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
> >> I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
> >> I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=(none)
> >> I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
> >
> > I amended the commit message with the above, switched to
> > USB_DEVICE_INTERFACE_CLASS(), fixed the comment and moved the entry
> > to the other 0x2020 entries before applying.
>
> Sorry I should probably have mentioned this before but Angus has been on
> vacation, hence the silence on the other matters. Regardless, thanks.
Ok, no worries.
Johan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH net-next] r8169: sync EEE handling for RTL8168h with vendor driver
From: Heiner Kallweit @ 2019-08-15 12:21 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller; +Cc: netdev@vger.kernel.org
Sync EEE init for RTL8168h with vendor driver and add two writes to
vendor-specific registers.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169_main.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index c9550b4f9..910944120 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -2216,6 +2216,16 @@ static void rtl8168g_config_eee_phy(struct rtl8169_private *tp)
phy_modify_paged(tp->phydev, 0x0a43, 0x11, 0, BIT(4));
}
+static void rtl8168h_config_eee_phy(struct rtl8169_private *tp)
+{
+ struct phy_device *phydev = tp->phydev;
+
+ rtl8168g_config_eee_phy(tp);
+
+ phy_modify_paged(phydev, 0xa4a, 0x11, 0x0000, 0x0200);
+ phy_modify_paged(phydev, 0xa42, 0x14, 0x0000, 0x0080);
+}
+
static void rtl8169s_hw_phy_config(struct rtl8169_private *tp)
{
static const struct phy_reg phy_reg_init[] = {
@@ -3283,7 +3293,7 @@ static void rtl8168h_1_hw_phy_config(struct rtl8169_private *tp)
phy_modify_paged(tp->phydev, 0x0a44, 0x11, BIT(7), 0);
rtl8168g_disable_aldps(tp);
- rtl8168g_config_eee_phy(tp);
+ rtl8168h_config_eee_phy(tp);
rtl_enable_eee(tp);
}
--
2.22.1
^ permalink raw reply related
* Re: [PATCH 1/2] usb: serial: option: Add the BroadMobi BM818 card
From: Bob Ham @ 2019-08-15 12:19 UTC (permalink / raw)
To: Johan Hovold
Cc: Angus Ainslie (Purism), kernel, Bjørn Mork, David S. Miller,
Greg Kroah-Hartman, netdev, linux-usb, linux-kernel
In-Reply-To: <20190815114941.GE32300@localhost>
[-- Attachment #1.1: Type: text/plain, Size: 1441 bytes --]
On 15/08/2019 12:49, Johan Hovold wrote:
> On Mon, Aug 05, 2019 at 03:44:30PM +0100, Bob Ham wrote:
>> On 05/08/2019 12:47, Johan Hovold wrote:
>>> On Wed, Jul 24, 2019 at 07:52:26AM -0700, Angus Ainslie (Purism) wrote:
>>>> From: Bob Ham <bob.ham@puri.sm>
>>>>
>>>> Add a VID:PID for the BroadModi BM818 M.2 card
>>>
>>> Would you mind posting the output of usb-devices (or lsusb -v) for this
>>> device?
>>
>> T: Bus=01 Lev=03 Prnt=40 Port=03 Cnt=01 Dev#= 44 Spd=480 MxCh= 0
>> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
>> P: Vendor=2020 ProdID=2060 Rev=00.00
>> S: Manufacturer=Qualcomm, Incorporated
>> S: Product=Qualcomm CDMA Technologies MSM
>> C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
>> I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
>> I: If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
>> I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
>> I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=(none)
>> I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
>
> I amended the commit message with the above, switched to
> USB_DEVICE_INTERFACE_CLASS(), fixed the comment and moved the entry
> to the other 0x2020 entries before applying.
Sorry I should probably have mentioned this before but Angus has been on
vacation, hence the silence on the other matters. Regardless, thanks.
Bob
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: Fyi
From: Karen Ngui @ 2019-08-15 11:23 UTC (permalink / raw)
To: netdev
Hello netdev@vger.kernel.org
I am Karen Ngui by name got your details based on recommendations
from LinkedIn 5 star marketers and its feels good to be part of
your professional network.
I sent you a proposal via email on the 10th of this month did
you get it ? Do reply to my message so I can elaborate more on my
proposal.
Thank You For Your Time.
^ permalink raw reply
* [PATCH bpf-next v2 0/3] xdpsock: allow mmap2 usage for 32bits
From: Ivan Khoronzhuk @ 2019-08-15 12:13 UTC (permalink / raw)
To: magnus.karlsson, bjorn.topel
Cc: davem, hawk, john.fastabend, jakub.kicinski, daniel, netdev, bpf,
xdp-newbies, linux-kernel, jlemon, yhs, andrii.nakryiko,
Ivan Khoronzhuk
This patchset contains several improvements for af_xdp socket umem
mappings for 32bit systems. Also, there is one more patch outside of
this series that on linux-next tree and related to mmap2 af_xdp umem
offsets: "mm: mmap: increase sockets maximum memory size pgoff for 32bits"
https://lkml.org/lkml/2019/8/12/549
Based on bpf-next/master
Prev: https://lkml.org/lkml/2019/8/13/437
v2..v1:
- replaced "libbpf: add asm/unistd.h to xsk to get __NR_mmap2" on
"libbpf: use LFS (_FILE_OFFSET_BITS) instead of direct mmap2
syscall"
- use vmap along with page_address to avoid overkill
- define mmap syscall trace5 for mmap if defined
Ivan Khoronzhuk (3):
libbpf: use LFS (_FILE_OFFSET_BITS) instead of direct mmap2 syscall
xdp: xdp_umem: replace kmap on vmap for umem map
samples: bpf: syscal_nrs: use mmap2 if defined
net/xdp/xdp_umem.c | 36 +++++++++++++++++++++++-----
samples/bpf/syscall_nrs.c | 6 +++++
samples/bpf/tracex5_kern.c | 13 ++++++++++
tools/lib/bpf/Makefile | 1 +
tools/lib/bpf/xsk.c | 49 +++++++++++---------------------------
5 files changed, 64 insertions(+), 41 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH bpf-next v2 1/3] libbpf: use LFS (_FILE_OFFSET_BITS) instead of direct mmap2 syscall
From: Ivan Khoronzhuk @ 2019-08-15 12:13 UTC (permalink / raw)
To: magnus.karlsson, bjorn.topel
Cc: davem, hawk, john.fastabend, jakub.kicinski, daniel, netdev, bpf,
xdp-newbies, linux-kernel, jlemon, yhs, andrii.nakryiko,
Ivan Khoronzhuk
In-Reply-To: <20190815121356.8848-1-ivan.khoronzhuk@linaro.org>
Drop __NR_mmap2 fork in flavor of LFS, that is _FILE_OFFSET_BITS=64
(glibc & bionic) / LARGEFILE64_SOURCE (for musl) decision. It allows
mmap() to use 64bit offset that is passed to mmap2 syscall. As result
pgoff is not truncated and no need to use direct access to mmap2 for
32 bits systems.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
tools/lib/bpf/Makefile | 1 +
tools/lib/bpf/xsk.c | 49 ++++++++++++------------------------------
2 files changed, 15 insertions(+), 35 deletions(-)
diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index 9312066a1ae3..844f6cd79c03 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -113,6 +113,7 @@ override CFLAGS += -Werror -Wall
override CFLAGS += -fPIC
override CFLAGS += $(INCLUDES)
override CFLAGS += -fvisibility=hidden
+override CFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
ifeq ($(VERBOSE),1)
Q =
diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
index 680e63066cf3..7392f428c07b 100644
--- a/tools/lib/bpf/xsk.c
+++ b/tools/lib/bpf/xsk.c
@@ -74,23 +74,6 @@ struct xsk_nl_info {
int fd;
};
-/* For 32-bit systems, we need to use mmap2 as the offsets are 64-bit.
- * Unfortunately, it is not part of glibc.
- */
-static inline void *xsk_mmap(void *addr, size_t length, int prot, int flags,
- int fd, __u64 offset)
-{
-#ifdef __NR_mmap2
- unsigned int page_shift = __builtin_ffs(getpagesize()) - 1;
- long ret = syscall(__NR_mmap2, addr, length, prot, flags, fd,
- (off_t)(offset >> page_shift));
-
- return (void *)ret;
-#else
- return mmap(addr, length, prot, flags, fd, offset);
-#endif
-}
-
int xsk_umem__fd(const struct xsk_umem *umem)
{
return umem ? umem->fd : -EINVAL;
@@ -210,10 +193,9 @@ int xsk_umem__create(struct xsk_umem **umem_ptr, void *umem_area, __u64 size,
goto out_socket;
}
- map = xsk_mmap(NULL, off.fr.desc +
- umem->config.fill_size * sizeof(__u64),
- PROT_READ | PROT_WRITE, MAP_SHARED | MAP_POPULATE,
- umem->fd, XDP_UMEM_PGOFF_FILL_RING);
+ map = mmap(NULL, off.fr.desc + umem->config.fill_size * sizeof(__u64),
+ PROT_READ | PROT_WRITE, MAP_SHARED | MAP_POPULATE, umem->fd,
+ XDP_UMEM_PGOFF_FILL_RING);
if (map == MAP_FAILED) {
err = -errno;
goto out_socket;
@@ -227,10 +209,9 @@ int xsk_umem__create(struct xsk_umem **umem_ptr, void *umem_area, __u64 size,
fill->ring = map + off.fr.desc;
fill->cached_cons = umem->config.fill_size;
- map = xsk_mmap(NULL,
- off.cr.desc + umem->config.comp_size * sizeof(__u64),
- PROT_READ | PROT_WRITE, MAP_SHARED | MAP_POPULATE,
- umem->fd, XDP_UMEM_PGOFF_COMPLETION_RING);
+ map = mmap(NULL, off.cr.desc + umem->config.comp_size * sizeof(__u64),
+ PROT_READ | PROT_WRITE, MAP_SHARED | MAP_POPULATE, umem->fd,
+ XDP_UMEM_PGOFF_COMPLETION_RING);
if (map == MAP_FAILED) {
err = -errno;
goto out_mmap;
@@ -550,11 +531,10 @@ int xsk_socket__create(struct xsk_socket **xsk_ptr, const char *ifname,
}
if (rx) {
- rx_map = xsk_mmap(NULL, off.rx.desc +
- xsk->config.rx_size * sizeof(struct xdp_desc),
- PROT_READ | PROT_WRITE,
- MAP_SHARED | MAP_POPULATE,
- xsk->fd, XDP_PGOFF_RX_RING);
+ rx_map = mmap(NULL, off.rx.desc +
+ xsk->config.rx_size * sizeof(struct xdp_desc),
+ PROT_READ | PROT_WRITE, MAP_SHARED | MAP_POPULATE,
+ xsk->fd, XDP_PGOFF_RX_RING);
if (rx_map == MAP_FAILED) {
err = -errno;
goto out_socket;
@@ -569,11 +549,10 @@ int xsk_socket__create(struct xsk_socket **xsk_ptr, const char *ifname,
xsk->rx = rx;
if (tx) {
- tx_map = xsk_mmap(NULL, off.tx.desc +
- xsk->config.tx_size * sizeof(struct xdp_desc),
- PROT_READ | PROT_WRITE,
- MAP_SHARED | MAP_POPULATE,
- xsk->fd, XDP_PGOFF_TX_RING);
+ tx_map = mmap(NULL, off.tx.desc +
+ xsk->config.tx_size * sizeof(struct xdp_desc),
+ PROT_READ | PROT_WRITE, MAP_SHARED | MAP_POPULATE,
+ xsk->fd, XDP_PGOFF_TX_RING);
if (tx_map == MAP_FAILED) {
err = -errno;
goto out_mmap_rx;
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 2/2] r8169: use the generic EEE management functions
From: Heiner Kallweit @ 2019-08-15 12:14 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <88a71ee7-a17d-ac9c-c998-d0ea35e5c566@gmail.com>
Now that the Realtek PHY driver maps the vendor-specific EEE registers
to the standard MMD registers, we can remove all special handling and
use the generic functions phy_ethtool_get/set_eee.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2.
- rebased
---
drivers/net/ethernet/realtek/r8169_main.c | 172 +++-------------------
1 file changed, 24 insertions(+), 148 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index 34d072f0c..c9550b4f9 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -733,6 +733,13 @@ static bool rtl_is_8168evl_up(struct rtl8169_private *tp)
tp->mac_version != RTL_GIGA_MAC_VER_39;
}
+static bool rtl_supports_eee(struct rtl8169_private *tp)
+{
+ return tp->mac_version >= RTL_GIGA_MAC_VER_34 &&
+ tp->mac_version != RTL_GIGA_MAC_VER_37 &&
+ tp->mac_version != RTL_GIGA_MAC_VER_39;
+}
+
struct rtl_cond {
bool (*check)(struct rtl8169_private *);
const char *msg;
@@ -1945,144 +1952,40 @@ static int rtl_set_coalesce(struct net_device *dev, struct ethtool_coalesce *ec)
return 0;
}
-static int rtl_get_eee_supp(struct rtl8169_private *tp)
-{
- struct phy_device *phydev = tp->phydev;
- int ret;
-
- switch (tp->mac_version) {
- case RTL_GIGA_MAC_VER_34:
- case RTL_GIGA_MAC_VER_35:
- case RTL_GIGA_MAC_VER_36:
- case RTL_GIGA_MAC_VER_38:
- ret = phy_read_mmd(phydev, MDIO_MMD_PCS, MDIO_PCS_EEE_ABLE);
- break;
- case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
- ret = phy_read_paged(phydev, 0x0a5c, 0x12);
- break;
- default:
- ret = -EPROTONOSUPPORT;
- break;
- }
-
- return ret;
-}
-
-static int rtl_get_eee_lpadv(struct rtl8169_private *tp)
-{
- struct phy_device *phydev = tp->phydev;
- int ret;
-
- switch (tp->mac_version) {
- case RTL_GIGA_MAC_VER_34:
- case RTL_GIGA_MAC_VER_35:
- case RTL_GIGA_MAC_VER_36:
- case RTL_GIGA_MAC_VER_38:
- ret = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_LPABLE);
- break;
- case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
- ret = phy_read_paged(phydev, 0x0a5d, 0x11);
- break;
- default:
- ret = -EPROTONOSUPPORT;
- break;
- }
-
- return ret;
-}
-
-static int rtl_get_eee_adv(struct rtl8169_private *tp)
-{
- struct phy_device *phydev = tp->phydev;
- int ret;
-
- switch (tp->mac_version) {
- case RTL_GIGA_MAC_VER_34:
- case RTL_GIGA_MAC_VER_35:
- case RTL_GIGA_MAC_VER_36:
- case RTL_GIGA_MAC_VER_38:
- ret = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV);
- break;
- case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
- ret = phy_read_paged(phydev, 0x0a5d, 0x10);
- break;
- default:
- ret = -EPROTONOSUPPORT;
- break;
- }
-
- return ret;
-}
-
-static int rtl_set_eee_adv(struct rtl8169_private *tp, int val)
-{
- struct phy_device *phydev = tp->phydev;
- int ret = 0;
-
- switch (tp->mac_version) {
- case RTL_GIGA_MAC_VER_34:
- case RTL_GIGA_MAC_VER_35:
- case RTL_GIGA_MAC_VER_36:
- case RTL_GIGA_MAC_VER_38:
- ret = phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
- break;
- case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
- phy_write_paged(phydev, 0x0a5d, 0x10, val);
- break;
- default:
- ret = -EPROTONOSUPPORT;
- break;
- }
-
- return ret;
-}
-
static int rtl8169_get_eee(struct net_device *dev, struct ethtool_eee *data)
{
struct rtl8169_private *tp = netdev_priv(dev);
struct device *d = tp_to_dev(tp);
int ret;
+ if (!rtl_supports_eee(tp))
+ return -EOPNOTSUPP;
+
pm_runtime_get_noresume(d);
if (!pm_runtime_active(d)) {
ret = -EOPNOTSUPP;
- goto out;
+ } else {
+ ret = phy_ethtool_get_eee(tp->phydev, data);
}
- /* Get Supported EEE */
- ret = rtl_get_eee_supp(tp);
- if (ret < 0)
- goto out;
- data->supported = mmd_eee_cap_to_ethtool_sup_t(ret);
-
- /* Get advertisement EEE */
- ret = rtl_get_eee_adv(tp);
- if (ret < 0)
- goto out;
- data->advertised = mmd_eee_adv_to_ethtool_adv_t(ret);
- data->eee_enabled = !!data->advertised;
-
- /* Get LP advertisement EEE */
- ret = rtl_get_eee_lpadv(tp);
- if (ret < 0)
- goto out;
- data->lp_advertised = mmd_eee_adv_to_ethtool_adv_t(ret);
- data->eee_active = !!(data->advertised & data->lp_advertised);
-out:
pm_runtime_put_noidle(d);
- return ret < 0 ? ret : 0;
+
+ return ret;
}
static int rtl8169_set_eee(struct net_device *dev, struct ethtool_eee *data)
{
struct rtl8169_private *tp = netdev_priv(dev);
struct device *d = tp_to_dev(tp);
- int old_adv, adv = 0, cap, ret;
+ int ret;
+
+ if (!rtl_supports_eee(tp))
+ return -EOPNOTSUPP;
pm_runtime_get_noresume(d);
- if (!dev->phydev || !pm_runtime_active(d)) {
+ if (!pm_runtime_active(d)) {
ret = -EOPNOTSUPP;
goto out;
}
@@ -2093,38 +1996,10 @@ static int rtl8169_set_eee(struct net_device *dev, struct ethtool_eee *data)
goto out;
}
- /* Get Supported EEE */
- ret = rtl_get_eee_supp(tp);
- if (ret < 0)
- goto out;
- cap = ret;
-
- ret = rtl_get_eee_adv(tp);
- if (ret < 0)
- goto out;
- old_adv = ret;
-
- if (data->eee_enabled) {
- adv = !data->advertised ? cap :
- ethtool_adv_to_mmd_eee_adv_t(data->advertised) & cap;
- /* Mask prohibited EEE modes */
- adv &= ~dev->phydev->eee_broken_modes;
- }
-
- if (old_adv != adv) {
- ret = rtl_set_eee_adv(tp, adv);
- if (ret < 0)
- goto out;
-
- /* Restart autonegotiation so the new modes get sent to the
- * link partner.
- */
- ret = phy_restart_aneg(dev->phydev);
- }
-
+ ret = phy_ethtool_set_eee(tp->phydev, data);
out:
pm_runtime_put_noidle(d);
- return ret < 0 ? ret : 0;
+ return ret;
}
static const struct ethtool_ops rtl8169_ethtool_ops = {
@@ -2151,10 +2026,11 @@ static const struct ethtool_ops rtl8169_ethtool_ops = {
static void rtl_enable_eee(struct rtl8169_private *tp)
{
- int supported = rtl_get_eee_supp(tp);
+ struct phy_device *phydev = tp->phydev;
+ int supported = phy_read_mmd(phydev, MDIO_MMD_PCS, MDIO_PCS_EEE_ABLE);
if (supported > 0)
- rtl_set_eee_adv(tp, supported);
+ phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV, supported);
}
static void rtl8169_get_mac_version(struct rtl8169_private *tp)
--
2.22.1
^ permalink raw reply related
* [PATCH bpf-next v2 3/3] samples: bpf: syscal_nrs: use mmap2 if defined
From: Ivan Khoronzhuk @ 2019-08-15 12:13 UTC (permalink / raw)
To: magnus.karlsson, bjorn.topel
Cc: davem, hawk, john.fastabend, jakub.kicinski, daniel, netdev, bpf,
xdp-newbies, linux-kernel, jlemon, yhs, andrii.nakryiko,
Ivan Khoronzhuk
In-Reply-To: <20190815121356.8848-1-ivan.khoronzhuk@linaro.org>
For arm32 xdp sockets mmap2 is preferred, so use it if it's defined.
Declaration of __NR_mmap can be skipped and it breaks build.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
samples/bpf/syscall_nrs.c | 6 ++++++
samples/bpf/tracex5_kern.c | 13 +++++++++++++
2 files changed, 19 insertions(+)
diff --git a/samples/bpf/syscall_nrs.c b/samples/bpf/syscall_nrs.c
index 516e255cbe8f..88f940052450 100644
--- a/samples/bpf/syscall_nrs.c
+++ b/samples/bpf/syscall_nrs.c
@@ -9,5 +9,11 @@ void syscall_defines(void)
COMMENT("Linux system call numbers.");
SYSNR(__NR_write);
SYSNR(__NR_read);
+#ifdef __NR_mmap2
+ SYSNR(__NR_mmap2);
+#endif
+#ifdef __NR_mmap
SYSNR(__NR_mmap);
+#endif
+
}
diff --git a/samples/bpf/tracex5_kern.c b/samples/bpf/tracex5_kern.c
index f57f4e1ea1ec..35cb0eed3be5 100644
--- a/samples/bpf/tracex5_kern.c
+++ b/samples/bpf/tracex5_kern.c
@@ -68,12 +68,25 @@ PROG(SYS__NR_read)(struct pt_regs *ctx)
return 0;
}
+#ifdef __NR_mmap2
+PROG(SYS__NR_mmap2)(struct pt_regs *ctx)
+{
+ char fmt[] = "mmap2\n";
+
+ bpf_trace_printk(fmt, sizeof(fmt));
+ return 0;
+}
+#endif
+
+#ifdef __NR_mmap
PROG(SYS__NR_mmap)(struct pt_regs *ctx)
{
char fmt[] = "mmap\n";
+
bpf_trace_printk(fmt, sizeof(fmt));
return 0;
}
+#endif
char _license[] SEC("license") = "GPL";
u32 _version SEC("version") = LINUX_VERSION_CODE;
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 1/2] net: phy: realtek: add support for EEE registers on integrated PHY's
From: Heiner Kallweit @ 2019-08-15 12:12 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <88a71ee7-a17d-ac9c-c998-d0ea35e5c566@gmail.com>
EEE-related registers on newer integrated PHY's have the standard
layout, but are accessible not via MMD but via vendor-specific
registers. Emulating the standard MMD registers allows to use the
generic functions for EEE control.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/realtek.c | 43 +++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index c49a1fb13..2635ad1ff 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -266,6 +266,45 @@ static int rtl8366rb_config_init(struct phy_device *phydev)
return ret;
}
+static int rtlgen_read_mmd(struct phy_device *phydev, int devnum, u16 regnum)
+{
+ int ret;
+
+ if (devnum == MDIO_MMD_PCS && regnum == MDIO_PCS_EEE_ABLE) {
+ rtl821x_write_page(phydev, 0xa5c);
+ ret = __phy_read(phydev, 0x12);
+ rtl821x_write_page(phydev, 0);
+ } else if (devnum == MDIO_MMD_AN && regnum == MDIO_AN_EEE_ADV) {
+ rtl821x_write_page(phydev, 0xa5d);
+ ret = __phy_read(phydev, 0x10);
+ rtl821x_write_page(phydev, 0);
+ } else if (devnum == MDIO_MMD_AN && regnum == MDIO_AN_EEE_LPABLE) {
+ rtl821x_write_page(phydev, 0xa5d);
+ ret = __phy_read(phydev, 0x11);
+ rtl821x_write_page(phydev, 0);
+ } else {
+ ret = -EOPNOTSUPP;
+ }
+
+ return ret;
+}
+
+static int rtlgen_write_mmd(struct phy_device *phydev, int devnum, u16 regnum,
+ u16 val)
+{
+ int ret;
+
+ if (devnum == MDIO_MMD_AN && regnum == MDIO_AN_EEE_ADV) {
+ rtl821x_write_page(phydev, 0xa5d);
+ ret = __phy_write(phydev, 0x10, val);
+ rtl821x_write_page(phydev, 0);
+ } else {
+ ret = -EOPNOTSUPP;
+ }
+
+ return ret;
+}
+
static int rtl8125_get_features(struct phy_device *phydev)
{
int val;
@@ -422,6 +461,8 @@ static struct phy_driver realtek_drvs[] = {
.resume = genphy_resume,
.read_page = rtl821x_read_page,
.write_page = rtl821x_write_page,
+ .read_mmd = rtlgen_read_mmd,
+ .write_mmd = rtlgen_write_mmd,
}, {
.name = "RTL8125 2.5Gbps internal",
.match_phy_device = rtl8125_match_phy_device,
@@ -432,6 +473,8 @@ static struct phy_driver realtek_drvs[] = {
.resume = genphy_resume,
.read_page = rtl821x_read_page,
.write_page = rtl821x_write_page,
+ .read_mmd = rtlgen_read_mmd,
+ .write_mmd = rtlgen_write_mmd,
}, {
PHY_ID_MATCH_EXACT(0x001cc961),
.name = "RTL8366RB Gigabit Ethernet",
--
2.22.1
^ permalink raw reply related
* [PATCH bpf-next v2 2/3] xdp: xdp_umem: replace kmap on vmap for umem map
From: Ivan Khoronzhuk @ 2019-08-15 12:13 UTC (permalink / raw)
To: magnus.karlsson, bjorn.topel
Cc: davem, hawk, john.fastabend, jakub.kicinski, daniel, netdev, bpf,
xdp-newbies, linux-kernel, jlemon, yhs, andrii.nakryiko,
Ivan Khoronzhuk
In-Reply-To: <20190815121356.8848-1-ivan.khoronzhuk@linaro.org>
For 64-bit there is no reason to use vmap/vunmap, so use page_address
as it was initially. For 32 bits, in some apps, like in samples
xdpsock_user.c when number of pgs in use is quite big, the kmap
memory can be not enough, despite on this, kmap looks like is
deprecated in such cases as it can block and should be used rather
for dynamic mm.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
net/xdp/xdp_umem.c | 36 ++++++++++++++++++++++++++++++------
1 file changed, 30 insertions(+), 6 deletions(-)
diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
index a0607969f8c0..d740c4f8810c 100644
--- a/net/xdp/xdp_umem.c
+++ b/net/xdp/xdp_umem.c
@@ -14,7 +14,7 @@
#include <linux/netdevice.h>
#include <linux/rtnetlink.h>
#include <linux/idr.h>
-#include <linux/highmem.h>
+#include <linux/vmalloc.h>
#include "xdp_umem.h"
#include "xsk_queue.h"
@@ -170,7 +170,30 @@ static void xdp_umem_unmap_pages(struct xdp_umem *umem)
unsigned int i;
for (i = 0; i < umem->npgs; i++)
- kunmap(umem->pgs[i]);
+ if (PageHighMem(umem->pgs[i]))
+ vunmap(umem->pages[i].addr);
+}
+
+static int xdp_umem_map_pages(struct xdp_umem *umem)
+{
+ unsigned int i;
+ void *addr;
+
+ for (i = 0; i < umem->npgs; i++) {
+ if (PageHighMem(umem->pgs[i]))
+ addr = vmap(&umem->pgs[i], 1, VM_MAP, PAGE_KERNEL);
+ else
+ addr = page_address(umem->pgs[i]);
+
+ if (!addr) {
+ xdp_umem_unmap_pages(umem);
+ return -ENOMEM;
+ }
+
+ umem->pages[i].addr = addr;
+ }
+
+ return 0;
}
static void xdp_umem_unpin_pages(struct xdp_umem *umem)
@@ -312,7 +335,7 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
u32 chunk_size = mr->chunk_size, headroom = mr->headroom;
unsigned int chunks, chunks_per_page;
u64 addr = mr->addr, size = mr->len;
- int size_chk, err, i;
+ int size_chk, err;
if (chunk_size < XDP_UMEM_MIN_CHUNK_SIZE || chunk_size > PAGE_SIZE) {
/* Strictly speaking we could support this, if:
@@ -378,10 +401,11 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
goto out_account;
}
- for (i = 0; i < umem->npgs; i++)
- umem->pages[i].addr = kmap(umem->pgs[i]);
+ err = xdp_umem_map_pages(umem);
+ if (!err)
+ return 0;
- return 0;
+ kfree(umem->pages);
out_account:
xdp_umem_unaccount_pages(umem);
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 0/2] net: phy: realtek: map vendor-specific EEE registers to standard MMD registers
From: Heiner Kallweit @ 2019-08-15 12:12 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
EEE-related registers on newer integrated PHY's have the standard
layout, but are accessible not via MMD but via vendor-specific
registers. Emulating the standard MMD registers allows to use the
generic functions for EEE control and to significantly simplify
the r8169 driver.
v2:
- rebase patch 2
Heiner Kallweit (2):
net: phy: realtek: add support for EEE registers on integrated PHY's
r8169: use the generic EEE management functions
drivers/net/ethernet/realtek/r8169_main.c | 172 +++-------------------
drivers/net/phy/realtek.c | 43 ++++++
2 files changed, 67 insertions(+), 148 deletions(-)
--
2.22.1
^ permalink raw reply
* RE: [v2, 4/4] ocelot: add VCAP IS2 rule to trap PTP Ethernet frames
From: Y.b. Lu @ 2019-08-15 12:08 UTC (permalink / raw)
To: Allan W . Nielsen
Cc: Andrew Lunn, netdev@vger.kernel.org, David S . Miller,
Alexandre Belloni, Microchip Linux Driver Support
In-Reply-To: <20190814091645.dwo7c36xan2ttln2@lx-anielsen.microsemi.net>
Hi Allan,
> -----Original Message-----
> From: Allan W . Nielsen <allan.nielsen@microchip.com>
> Sent: Wednesday, August 14, 2019 5:17 PM
> To: Y.b. Lu <yangbo.lu@nxp.com>
> Cc: Andrew Lunn <andrew@lunn.ch>; netdev@vger.kernel.org; David S . Miller
> <davem@davemloft.net>; Alexandre Belloni <alexandre.belloni@bootlin.com>;
> Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
> Subject: Re: [v2, 4/4] ocelot: add VCAP IS2 rule to trap PTP Ethernet frames
>
> The 08/14/2019 04:56, Y.b. Lu wrote:
> > > -----Original Message-----
> > > From: Allan W . Nielsen <allan.nielsen@microchip.com>
> > > Sent: Tuesday, August 13, 2019 2:25 PM
> > > To: Y.b. Lu <yangbo.lu@nxp.com>
> > > Cc: netdev@vger.kernel.org; David S . Miller <davem@davemloft.net>;
> > > Alexandre Belloni <alexandre.belloni@bootlin.com>; Microchip Linux
> > > Driver Support <UNGLinuxDriver@microchip.com>
> > > Subject: Re: [v2, 4/4] ocelot: add VCAP IS2 rule to trap PTP
> > > Ethernet frames
> > >
> > > The 08/13/2019 10:52, Yangbo Lu wrote:
> > > > All the PTP messages over Ethernet have etype 0x88f7 on them.
> > > > Use etype as the key to trap PTP messages.
> > > >
> > > > Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
[...]
> Can we continue this discussion in the other thread where I listed the 3
> scenarios?
[Y.b. Lu] Sure. Let's discuss in that thread.
https://patchwork.ozlabs.org/patch/1145627/
[...]
> > > What if do not want this on all ports?
> > [Y.b. Lu] Actually I don’t think there should be difference of handling PTP
> messages on each port.
> > You don’t need to run PTP protocol application on the specific port if you
> don’t want.
> What if you want some vlans or some ports to be PTP unaware, and other to
> be PTP aware.
[Y.b. Lu] Actually I couldn’t find reasons why make some ports PTP unaware, if there is software stack for PTP aware...
>
> > > If you do not have an application behind this implementing a
> > > boundary or transparent clock, then you are breaking PTP on the network.
> > [Y.b. Lu] You're right. But actually for PTP network, all PTP devices should run
> PTP protocol on it.
> > Of course, it's better to have a way to configure it as non-aware PTP switch.
> I think we agree.
>
> In my point of view, it is the PTP daemon who should configure frames to be
> trapped. Then the switch will be PTP unaware until the PTP daemon starts up
> and is ready to make it aware.
>
> If we put it in the init function, then it will be of PTP broken until the PTP
> daemon starts.
>
> /Allan
^ permalink raw reply
* [PATCH net-next 3/3] net: phy: remove genphy_config_init
From: Heiner Kallweit @ 2019-08-15 12:04 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller, Kevin Hilman,
Vivien Didelot
Cc: netdev@vger.kernel.org, open list:ARM/Amlogic Meson...
In-Reply-To: <95dfdb55-415c-c995-cba3-1902bdd46aec@gmail.com>
Now that all users have been removed we can remove genphy_config_init.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy_device.c | 51 ------------------------------------
include/linux/phy.h | 1 -
2 files changed, 52 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 7e7393f3c..d347ddcac 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1895,57 +1895,6 @@ int genphy_soft_reset(struct phy_device *phydev)
}
EXPORT_SYMBOL(genphy_soft_reset);
-int genphy_config_init(struct phy_device *phydev)
-{
- int val;
- __ETHTOOL_DECLARE_LINK_MODE_MASK(features) = { 0, };
-
- linkmode_set_bit_array(phy_basic_ports_array,
- ARRAY_SIZE(phy_basic_ports_array),
- features);
- linkmode_set_bit(ETHTOOL_LINK_MODE_Pause_BIT, features);
- linkmode_set_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, features);
-
- /* Do we support autonegotiation? */
- val = phy_read(phydev, MII_BMSR);
- if (val < 0)
- return val;
-
- if (val & BMSR_ANEGCAPABLE)
- linkmode_set_bit(ETHTOOL_LINK_MODE_Autoneg_BIT, features);
-
- if (val & BMSR_100FULL)
- linkmode_set_bit(ETHTOOL_LINK_MODE_100baseT_Full_BIT, features);
- if (val & BMSR_100HALF)
- linkmode_set_bit(ETHTOOL_LINK_MODE_100baseT_Half_BIT, features);
- if (val & BMSR_10FULL)
- linkmode_set_bit(ETHTOOL_LINK_MODE_10baseT_Full_BIT, features);
- if (val & BMSR_10HALF)
- linkmode_set_bit(ETHTOOL_LINK_MODE_10baseT_Half_BIT, features);
-
- if (val & BMSR_ESTATEN) {
- val = phy_read(phydev, MII_ESTATUS);
- if (val < 0)
- return val;
-
- if (val & ESTATUS_1000_TFULL)
- linkmode_set_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
- features);
- if (val & ESTATUS_1000_THALF)
- linkmode_set_bit(ETHTOOL_LINK_MODE_1000baseT_Half_BIT,
- features);
- if (val & ESTATUS_1000_XFULL)
- linkmode_set_bit(ETHTOOL_LINK_MODE_1000baseX_Full_BIT,
- features);
- }
-
- linkmode_and(phydev->supported, phydev->supported, features);
- linkmode_and(phydev->advertising, phydev->advertising, features);
-
- return 0;
-}
-EXPORT_SYMBOL(genphy_config_init);
-
/**
* genphy_read_abilities - read PHY abilities from Clause 22 registers
* @phydev: target phy_device struct
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 5ac7d2137..d26779f1f 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1069,7 +1069,6 @@ void phy_attached_print(struct phy_device *phydev, const char *fmt, ...)
void phy_attached_info(struct phy_device *phydev);
/* Clause 22 PHY */
-int genphy_config_init(struct phy_device *phydev);
int genphy_read_abilities(struct phy_device *phydev);
int genphy_setup_forced(struct phy_device *phydev);
int genphy_restart_aneg(struct phy_device *phydev);
--
2.22.1
^ 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