* Re: [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Chen-Yu Tsai @ 2018-05-14 4:59 UTC (permalink / raw)
To: Andrew Lunn
Cc: devicetree, Maxime Ripard, netdev, Rob Herring, Corentin Labbe,
Giuseppe Cavallaro, linux-arm-kernel, Icenowy Zheng
In-Reply-To: <20180513202938.GH12738@lunn.ch>
On Sun, May 13, 2018 at 1:29 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Sun, May 13, 2018 at 01:11:08PM -0700, Chen-Yu Tsai wrote:
>> On Sun, May 13, 2018 at 1:05 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> >> > Hi Chen-Yu
>> >> >
>> >> > Are these delays the MAC applies? Not the PHY. It would be good to
>> >> > make it clear here these are MAC imposed delays.
>> >>
>> >> Yes these are applied on the MAC side. Being described in the device
>> >> tree bindings for the MAC, I thought this was implied to be the case?
>> >> Are there known exceptions?
>> >
>> > There is frequent confusion with this. Most of the time, the PHY does
>> > the delay, not the MAC, based on the phy-mode. So the MAC doing it is
>> > an exception in itself.
>> >
>> > Do you actually need these delays for the board you adding support
>> > for? Does the PHY not support adding the needed delays? If you don't
>> > need the delays, i would not even implement them.
>>
>> Yes this is already used on the Bananapi M3. This patch merely reformats
>> the description and adds a note saying this only applies to RGMII mode.
>
> Yes, the current code is needed for the Bananapi M3. But you have
> another patch which extends the code to support a smaller range. Do
> you have a board which actually needs this? If not, i would not add
> that new code.
IIRC the delay on the PHY side is either 2ns or none. The delay on the
MAC side here is an order smaller, likely fine tuning to cope with board
design deficiencies.
Currently no other board requires this, but this is already part of the
binding. The new stuff limits the range for a specific SoC, simply because
that is the range supported by the control register. Not implementing, i.e.
supporting the whole range from the property, which might get truncated,
doesn't make much sense to me.
Regards
ChenYu
^ permalink raw reply
* Re: [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Icenowy Zheng @ 2018-05-14 5:18 UTC (permalink / raw)
To: linux-arm-kernel, Chen-Yu Tsai, Andrew Lunn
Cc: devicetree, Maxime Ripard, netdev, Rob Herring, Corentin Labbe,
Giuseppe Cavallaro, linux-arm-kernel
In-Reply-To: <CAGb2v66F_Ho2OZdrF3p6xe9mQ=zJZ_KjE9MnW1VmWs9jw65eEg@mail.gmail.com>
于 2018年5月14日 GMT+08:00 下午12:59:22, Chen-Yu Tsai <wens@csie.org> 写到:
>On Sun, May 13, 2018 at 1:29 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> On Sun, May 13, 2018 at 01:11:08PM -0700, Chen-Yu Tsai wrote:
>>> On Sun, May 13, 2018 at 1:05 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>> >> > Hi Chen-Yu
>>> >> >
>>> >> > Are these delays the MAC applies? Not the PHY. It would be good
>to
>>> >> > make it clear here these are MAC imposed delays.
>>> >>
>>> >> Yes these are applied on the MAC side. Being described in the
>device
>>> >> tree bindings for the MAC, I thought this was implied to be the
>case?
>>> >> Are there known exceptions?
>>> >
>>> > There is frequent confusion with this. Most of the time, the PHY
>does
>>> > the delay, not the MAC, based on the phy-mode. So the MAC doing it
>is
>>> > an exception in itself.
>>> >
>>> > Do you actually need these delays for the board you adding support
>>> > for? Does the PHY not support adding the needed delays? If you
>don't
>>> > need the delays, i would not even implement them.
>>>
>>> Yes this is already used on the Bananapi M3. This patch merely
>reformats
>>> the description and adds a note saying this only applies to RGMII
>mode.
>>
>> Yes, the current code is needed for the Bananapi M3. But you have
>> another patch which extends the code to support a smaller range. Do
>> you have a board which actually needs this? If not, i would not add
>> that new code.
>
>IIRC the delay on the PHY side is either 2ns or none. The delay on the
>MAC side here is an order smaller, likely fine tuning to cope with
>board
>design deficiencies.
And the weird thing is that the delay fails to work on some batches
of RTL8211E, notably many cases are shown on Pine A64+
board.
P.S. The delay is intended to be set via wires on PCB, other than
by software. Although Realtek provided some magic numbers
to Pine64, in order to fix the network problem due to PHY
delay failure.
>
>Currently no other board requires this, but this is already part of the
>binding. The new stuff limits the range for a specific SoC, simply
>because
>that is the range supported by the control register. Not implementing,
>i.e.
>supporting the whole range from the property, which might get
>truncated,
>doesn't make much sense to me.
>
>Regards
>ChenYu
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: general protection fault in rds_ib_get_mr
From: santosh.shilimkar @ 2018-05-14 5:46 UTC (permalink / raw)
To: Eric Biggers, linux-rdma, rds-devel
Cc: syzbot, davem, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <20180513211058.GE677@sol.localdomain>
On 5/13/18 2:10 PM, Eric Biggers wrote:
> On Wed, Mar 21, 2018 at 09:00:01AM -0700, syzbot wrote:
[...]
> Still reproducible on Linus' tree (commit 66e1c94db3cd4) and linux-next
> (next-20180511). Here's a simplified reproducer:
>
Thanks for the test case !!
Regards,
Santosh
^ permalink raw reply
* Re: KASAN: use-after-free Read in remove_wait_queue (2)
From: Eric Biggers @ 2018-05-14 6:11 UTC (permalink / raw)
To: linux-ppp, Paul Mackerras
Cc: netdev, linux-kernel, syzkaller-bugs, syzbot, viro
In-Reply-To: <f403043d0f18f879cc056648a875@google.com>
[+ppp list and maintainer]
On Wed, Feb 28, 2018 at 08:59:02AM -0800, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> f3afe530d644488a074291da04a69a296ab63046 (Tue Feb 27 22:02:39 2018 +0000)
> Merge branch 'fixes-v4.16-rc4' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
>
> So far this crash happened 3 times on upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+16363c99d4134717c05b@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> audit: type=1400 audit(1519800493.311:7): avc: denied { map } for
> pid=4238 comm="syzkaller305740" path="/root/syzkaller305740266" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> ==================================================================
> BUG: KASAN: use-after-free in __lock_acquire+0x3d4d/0x3e00
> kernel/locking/lockdep.c:3310
> Read of size 8 at addr ffff8801afa039c0 by task syzkaller305740/4238
>
> CPU: 1 PID: 4238 Comm: syzkaller305740 Not tainted 4.16.0-rc3+ #332
> 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+0x194/0x24d lib/dump_stack.c:53
> print_address_description+0x73/0x250 mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report+0x23b/0x360 mm/kasan/report.c:412
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> __lock_acquire+0x3d4d/0x3e00 kernel/locking/lockdep.c:3310
> lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3920
> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> _raw_spin_lock_irqsave+0x96/0xc0 kernel/locking/spinlock.c:152
> remove_wait_queue+0x81/0x350 kernel/sched/wait.c:50
> ep_remove_wait_queue fs/eventpoll.c:596 [inline]
> ep_unregister_pollwait.isra.7+0x18c/0x590 fs/eventpoll.c:614
> ep_free+0x13f/0x320 fs/eventpoll.c:832
> ep_eventpoll_release+0x44/0x60 fs/eventpoll.c:864
> __fput+0x327/0x7e0 fs/file_table.c:209
> ____fput+0x15/0x20 fs/file_table.c:243
> task_work_run+0x199/0x270 kernel/task_work.c:113
> exit_task_work include/linux/task_work.h:22 [inline]
> do_exit+0x9bb/0x1ad0 kernel/exit.c:865
> do_group_exit+0x149/0x400 kernel/exit.c:968
> SYSC_exit_group kernel/exit.c:979 [inline]
> SyS_exit_group+0x1d/0x20 kernel/exit.c:977
> do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x42/0xb7
> RIP: 0033:0x43e958
> RSP: 002b:00007ffe63a11468 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000000000043e958
> RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
> RBP: 00000000004be300 R08: 00000000000000e7 R09: ffffffffffffffd0
> R10: 00000000004002c8 R11: 0000000000000246 R12: 0000000000000001
> R13: 00000000006cc160 R14: 0000000000000000 R15: 0000000000000000
>
> Allocated by task 4238:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> set_track mm/kasan/kasan.c:459 [inline]
> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
> __do_kmalloc_node mm/slab.c:3669 [inline]
> __kmalloc_node+0x47/0x70 mm/slab.c:3676
> kmalloc_node include/linux/slab.h:554 [inline]
> kvmalloc_node+0x99/0xd0 mm/util.c:419
> kvmalloc include/linux/mm.h:541 [inline]
> kvzalloc include/linux/mm.h:549 [inline]
> alloc_netdev_mqs+0x16d/0xfb0 net/core/dev.c:8299
> ppp_create_interface drivers/net/ppp/ppp_generic.c:3018 [inline]
> ppp_unattached_ioctl drivers/net/ppp/ppp_generic.c:866 [inline]
> ppp_ioctl+0x1715/0x2a50 drivers/net/ppp/ppp_generic.c:602
> vfs_ioctl fs/ioctl.c:46 [inline]
> do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
> SYSC_ioctl fs/ioctl.c:701 [inline]
> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
> do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x42/0xb7
>
> Freed by task 4238:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> set_track mm/kasan/kasan.c:459 [inline]
> __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
> __cache_free mm/slab.c:3485 [inline]
> kfree+0xd9/0x260 mm/slab.c:3800
> kvfree+0x36/0x60 mm/util.c:438
> netdev_freemem+0x4c/0x60 net/core/dev.c:8253
> netdev_release+0x10a/0x160 net/core/net-sysfs.c:1502
> device_release+0x7c/0x210 drivers/base/core.c:814
> kobject_cleanup lib/kobject.c:646 [inline]
> kobject_release lib/kobject.c:675 [inline]
> kref_put include/linux/kref.h:70 [inline]
> kobject_put+0x14c/0x250 lib/kobject.c:692
> put_device+0x20/0x30 drivers/base/core.c:1931
> free_netdev+0x2f5/0x400 net/core/dev.c:8410
> ppp_destroy_interface+0x2bc/0x390 drivers/net/ppp/ppp_generic.c:3100
> ppp_release+0x12b/0x1a0 drivers/net/ppp/ppp_generic.c:415
> ppp_ioctl+0x3b1/0x2a50 drivers/net/ppp/ppp_generic.c:628
> vfs_ioctl fs/ioctl.c:46 [inline]
> do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
> SYSC_ioctl fs/ioctl.c:701 [inline]
> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
> do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
> entry_SYSCALL_64_after_hwframe+0x42/0xb7
>
> The buggy address belongs to the object at ffff8801afa02e40
> which belongs to the cache kmalloc-4096 of size 4096
> The buggy address is located 2944 bytes inside of
> 4096-byte region [ffff8801afa02e40, ffff8801afa03e40)
> The buggy address belongs to the page:
> page:ffffea0006be8080 count:1 mapcount:0 mapping:ffff8801afa02e40 index:0x0
> compound_mapcount: 0
> flags: 0x2fffc0000008100(slab|head)
> raw: 02fffc0000008100 ffff8801afa02e40 0000000000000000 0000000100000001
> raw: ffffea0006bee220 ffffea0006bee7a0 ffff8801dac00dc0 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801afa03880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801afa03900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ffff8801afa03980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff8801afa03a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801afa03a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.
This is a bug in ppp_generic.c; it still happens on Linus' tree and it's easily
reproducible, see program below. The bug is that the PPPIOCDETACH ioctl doesn't
consider that the file can still be attached to epoll instances even when
->f_count == 1. Also, the reproducer doesn't test this but I think ppp_poll(),
ppp_read(), and ppp_write() can all race with PPPIOCDETACH, causing
use-after-frees as well. Any chance that PPPIOCDETACH can simply be removed,
given that it's apparently been "deprecated" for 16 years? Does anyone use it?
#include <fcntl.h>
#include <linux/ppp-ioctl.h>
#include <sys/epoll.h>
#include <sys/ioctl.h>
int main()
{
int pppfd, epfd, unit = 0;
struct epoll_event event = { 0 };
pppfd = open("/dev/ppp", O_RDONLY);
ioctl(pppfd, PPPIOCNEWUNIT, &unit);
epfd = epoll_create(0x2000);
epoll_ctl(epfd, EPOLL_CTL_ADD, pppfd, &event);
ioctl(pppfd, PPPIOCDETACH, &unit);
}
- Eric
^ permalink raw reply
* Re: [PATCH v2] net/mlx4_core: Fix error handling in mlx4_init_port_info.
From: Leon Romanovsky @ 2018-05-14 6:21 UTC (permalink / raw)
To: Tarick Bedeir; +Cc: tariqt, gthelen, netdev, linux-rdma, linux-kernel
In-Reply-To: <20180513233845.135290-1-tarick@google.com>
[-- Attachment #1: Type: text/plain, Size: 709 bytes --]
On Sun, May 13, 2018 at 04:38:45PM -0700, Tarick Bedeir wrote:
> Avoid exiting the function with a lingering sysfs file (if the first
> call to device_create_file() fails while the second succeeds), and avoid
> calling devlink_port_unregister() twice.
>
> In other words, either mlx4_init_port_info() succeeds and returns zero, or
> it fails, returns non-zero, and requires no cleanup.
>
> Fixes: 096335b3f983 ("mlx4_core: Allow dynamic MTU configuration for IB
> ports")
Please don't break "Fixes" lines, it complicates "grep".
IMHO, general cleanup exit point is needed in this function (goto ...),
but your fix is good enough too. Thanks for doing it.
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH net-next] mlxsw: spectrum_span: Support LAG under mirror-to-gretap
From: Ido Schimmel @ 2018-05-14 6:40 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, petrm, mlxsw, Ido Schimmel
From: Petr Machata <petrm@mellanox.com>
When resolving a path that the packet will take after being encapsulated
in mirror-to-gretap scenarios, one of the devices en route could be a
LAG. In that case, mirror to first up slave that corresponds to a front
panel port.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
index e5f4f7620ab7..da3f7f527360 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
@@ -245,6 +245,19 @@ mlxsw_sp_span_entry_vlan(const struct net_device *vlan_dev,
return vlan_dev_real_dev(vlan_dev);
}
+static struct net_device *
+mlxsw_sp_span_entry_lag(struct net_device *lag_dev)
+{
+ struct net_device *dev;
+ struct list_head *iter;
+
+ netdev_for_each_lower_dev(lag_dev, dev, iter)
+ if ((dev->flags & IFF_UP) && mlxsw_sp_port_dev_check(dev))
+ return dev;
+
+ return NULL;
+}
+
static __maybe_unused int
mlxsw_sp_span_entry_tunnel_parms_common(struct net_device *edev,
union mlxsw_sp_l3addr saddr,
@@ -278,6 +291,14 @@ mlxsw_sp_span_entry_tunnel_parms_common(struct net_device *edev,
edev = mlxsw_sp_span_entry_vlan(edev, &vid);
}
+ if (netif_is_lag_master(edev)) {
+ if (!(edev->flags & IFF_UP))
+ goto unoffloadable;
+ edev = mlxsw_sp_span_entry_lag(edev);
+ if (!edev)
+ goto unoffloadable;
+ }
+
if (!mlxsw_sp_port_dev_check(edev))
goto unoffloadable;
--
2.14.3
^ permalink raw reply related
* Re: [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Maxime Ripard @ 2018-05-14 7:21 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Andrew Lunn, Giuseppe Cavallaro, linux-arm-kernel, devicetree,
netdev, Corentin Labbe, Icenowy Zheng, Rob Herring
In-Reply-To: <CAGb2v66F_Ho2OZdrF3p6xe9mQ=zJZ_KjE9MnW1VmWs9jw65eEg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2333 bytes --]
On Sun, May 13, 2018 at 09:59:22PM -0700, Chen-Yu Tsai wrote:
> On Sun, May 13, 2018 at 1:29 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > On Sun, May 13, 2018 at 01:11:08PM -0700, Chen-Yu Tsai wrote:
> >> On Sun, May 13, 2018 at 1:05 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> >> >> > Hi Chen-Yu
> >> >> >
> >> >> > Are these delays the MAC applies? Not the PHY. It would be good to
> >> >> > make it clear here these are MAC imposed delays.
> >> >>
> >> >> Yes these are applied on the MAC side. Being described in the device
> >> >> tree bindings for the MAC, I thought this was implied to be the case?
> >> >> Are there known exceptions?
> >> >
> >> > There is frequent confusion with this. Most of the time, the PHY does
> >> > the delay, not the MAC, based on the phy-mode. So the MAC doing it is
> >> > an exception in itself.
> >> >
> >> > Do you actually need these delays for the board you adding support
> >> > for? Does the PHY not support adding the needed delays? If you don't
> >> > need the delays, i would not even implement them.
> >>
> >> Yes this is already used on the Bananapi M3. This patch merely reformats
> >> the description and adds a note saying this only applies to RGMII mode.
> >
> > Yes, the current code is needed for the Bananapi M3. But you have
> > another patch which extends the code to support a smaller range. Do
> > you have a board which actually needs this? If not, i would not add
> > that new code.
>
> IIRC the delay on the PHY side is either 2ns or none. The delay on the
> MAC side here is an order smaller, likely fine tuning to cope with board
> design deficiencies.
>
> Currently no other board requires this, but this is already part of the
> binding. The new stuff limits the range for a specific SoC, simply because
> that is the range supported by the control register. Not implementing, i.e.
> supporting the whole range from the property, which might get truncated,
> doesn't make much sense to me.
With that driver we don't, but the previous design had the same
feature and it was used on more boards. It was simply initialized
statically in U-Boot, and not in Linux through the DT like it is done
here.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] ipvlan: flush arp table when mac address changed
From: Paolo Abeni @ 2018-05-14 7:39 UTC (permalink / raw)
To: liuqifa, davem, dsahern, maheshb, weiyongjun1, maowenan,
dingtianhong
Cc: netdev, linux-kernel
In-Reply-To: <20180512110037.9116-1-liuqifa@huawei.com>
Hi,
On Sat, 2018-05-12 at 19:00 +0800, liuqifa@huawei.com wrote:
> From: Keefe Liu <liuqifa@huawei.com>
>
> When master device's mac has been changed, the
> commit <32c10bbfe914> "ipvlan: always use the current L2
> addr of the master" makes the IPVlan devices's mac changed
> also, but it doesn't flush the IPVlan's arp table.
>
> Signed-off-by: Keefe Liu <liuqifa@huawei.com>
> ---
> drivers/net/ipvlan/ipvlan_main.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c
> index 450eec2..a1edfe1 100644
> --- a/drivers/net/ipvlan/ipvlan_main.c
> +++ b/drivers/net/ipvlan/ipvlan_main.c
> @@ -7,6 +7,8 @@
> *
> */
>
> +#include <net/neighbour.h>
> +#include <net/arp.h>
> #include "ipvlan.h"
>
> static unsigned int ipvlan_netid __read_mostly;
> @@ -792,8 +794,10 @@ static int ipvlan_device_event(struct notifier_block *unused,
> break;
>
> case NETDEV_CHANGEADDR:
> - list_for_each_entry(ipvlan, &port->ipvlans, pnode)
> + list_for_each_entry(ipvlan, &port->ipvlans, pnode) {
> ether_addr_copy(ipvlan->dev->dev_addr, dev->dev_addr);
> + neigh_changeaddr(&arp_tbl, ipvlan->dev);
> + }
Why don't using:
call_netdevice_notifiers(NETDEV_CHANGEADDR, ipvlan->dev);
instead?
that is what other stacked device - bridge and vlans - are currently
doing in the same scenario.
Thanks,
Paolo
^ permalink raw reply
* Re: [kbuild-all] [PATCH net-next 2/2] sctp: add sctp_make_op_error_limited and reuse inner functions
From: Ye Xiaolong @ 2018-05-14 7:40 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: kbuild test robot, Xin Long, Neil Horman, netdev, Vlad Yasevich,
linux-sctp, kbuild-all
In-Reply-To: <20180430023421.GA4977@localhost.localdomain>
Sorry for the late response.
On 04/29, Marcelo Ricardo Leitner wrote:
>On Mon, Apr 30, 2018 at 10:14:06AM +0800, kbuild test robot wrote:
>> Hi Marcelo,
>>
>> Thank you for the patch! Yet something to improve:
>>
>> [auto build test ERROR on net-next/master]
>>
>> url: https://github.com/0day-ci/linux/commits/Marcelo-Ricardo-Leitner/sctp-allow-sctp_init_cause-to-return-errors/20180430-073613
>
>This URL doesn't work, 404.
Our fault, 0day service failed to push related changes to github recently, we're
fixing it.
>
>> config: x86_64-randconfig-x006-201817 (attached as .config)
>> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
>> reproduce:
>> # save the attached .config to linux build tree
>> make ARCH=x86_64
>>
>> All errors (new ones prefixed by >>):
>>
>> net//sctp/sm_make_chunk.c: In function 'sctp_make_op_error_limited':
>> >> net//sctp/sm_make_chunk.c:1260:9: error: implicit declaration of function 'sctp_mtu_payload'; did you mean 'sctp_do_peeloff'? [-Werror=implicit-function-declaration]
>> size = sctp_mtu_payload(sp, size, sizeof(struct sctp_errhdr));
>> ^~~~~~~~~~~~~~~~
>> sctp_do_peeloff
>> cc1: some warnings being treated as errors
>
>Seems the test didn't pick up the MTU refactor patchset yet.
Do you mean your patchset require MTU refactor patchset as prerequisites?
Thanks,
Xiaolong
>
>$ grep sctp/sctp -- net/sctp/sm_make_chunk.c
>#include <net/sctp/sctp.h>
>
>$ git grep sctp_mtu_payload -- include/
>include/net/sctp/sctp.h:static inline __u32 sctp_mtu_payload(const
>struct sctp_sock *sp,
>
>it should be reachable.
>
> Marcelo
>_______________________________________________
>kbuild-all mailing list
>kbuild-all@lists.01.org
>https://lists.01.org/mailman/listinfo/kbuild-all
^ permalink raw reply
* Re: [PATCH] net: mvpp2: fix mvpp2_tx()'s return type
From: Antoine Tenart @ 2018-05-14 7:52 UTC (permalink / raw)
To: Luc Van Oostenryck
Cc: linux-kernel, David S. Miller, Antoine Tenart, Thomas Petazzoni,
Maxime Chevallier, Yan Markman, Stefan Chulski, Miquel Raynal,
Marcin Wojtas, netdev
In-Reply-To: <20180424131656.4054-1-luc.vanoostenryck@gmail.com>
Hi Luc,
On Tue, Apr 24, 2018 at 03:16:53PM +0200, Luc Van Oostenryck wrote:
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, but the implementation in this
> driver returns an 'int'.
>
> Fix this by returning 'netdev_tx_t' in this driver too.
>
> Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
I don't think this has been applied yet, so,
Acked-by: Antoine Tenart <antoine.tenart@bootlin.com>
Thanks!
Antoine
> ---
> drivers/net/ethernet/marvell/mvpp2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
> index 54a038943..355910345 100644
> --- a/drivers/net/ethernet/marvell/mvpp2.c
> +++ b/drivers/net/ethernet/marvell/mvpp2.c
> @@ -6926,7 +6926,7 @@ static int mvpp2_tx_tso(struct sk_buff *skb, struct net_device *dev,
> }
>
> /* Main tx processing */
> -static int mvpp2_tx(struct sk_buff *skb, struct net_device *dev)
> +static netdev_tx_t mvpp2_tx(struct sk_buff *skb, struct net_device *dev)
> {
> struct mvpp2_port *port = netdev_priv(dev);
> struct mvpp2_tx_queue *txq, *aggr_txq;
> --
> 2.17.0
>
--
Antoine Ténart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH net-next] cxgb4: do not fail vf instatiation in slave mode
From: Ganesh Goudar @ 2018-05-14 7:54 UTC (permalink / raw)
To: netdev, davem
Cc: nirranjan, indranil, venkatesh, Arjun Vynipadath, Casey Leedom,
Ganesh Goudar
From: Arjun Vynipadath <arjun@chelsio.com>
We no longer require a check for cxgb4 to be MASTER
when configuring SRIOV, It was required when we had
module parameter to instantiate vf.
Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index c54fd18..4ca828c 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -5276,13 +5276,9 @@ static int cxgb4_iov_configure(struct pci_dev *pdev, int num_vfs)
u32 pcie_fw;
pcie_fw = readl(adap->regs + PCIE_FW_A);
- /* Check if cxgb4 is the MASTER and fw is initialized */
- if (num_vfs &&
- (!(pcie_fw & PCIE_FW_INIT_F) ||
- !(pcie_fw & PCIE_FW_MASTER_VLD_F) ||
- PCIE_FW_MASTER_G(pcie_fw) != CXGB4_UNIFIED_PF)) {
- dev_warn(&pdev->dev,
- "cxgb4 driver needs to be MASTER to support SRIOV\n");
+ /* Check if fw is initialized */
+ if (!(pcie_fw & PCIE_FW_INIT_F)) {
+ dev_warn(&pdev->dev, "Device not initialized\n");
return -EOPNOTSUPP;
}
--
2.1.0
^ permalink raw reply related
* [PATCH net-next 1/2] cxgb4: Add support for FW_ETH_TX_PKT_VM_WR
From: Ganesh Goudar @ 2018-05-14 7:55 UTC (permalink / raw)
To: netdev, davem
Cc: nirranjan, indranil, venkatesh, Arjun Vynipadath, Casey Leedom,
Ganesh Goudar
From: Arjun Vynipadath <arjun@chelsio.com>
The present TX workrequest(FW_ETH_TX_PKT_WR) cant be used for
host->vf communication, since it doesn't loopback the outgoing
packets to virtual interfaces on the same port. This can be done using
FW_ETH_TX_PKT_VM_WR.
This fix depends on ethtool_flags to determine what WR to use for
TX path. Support for setting this flags by user is added in next commit.
Based on the original work by : Casey Leedom <leedom@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 13 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/sge.c | 367 ++++++++++++++++++++++++
3 files changed, 381 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 688f954..d2a7777 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -517,6 +517,15 @@ enum {
MAX_INGQ = MAX_ETH_QSETS + INGQ_EXTRAS,
};
+enum {
+ PRIV_FLAG_PORT_TX_VM_BIT,
+};
+
+#define PRIV_FLAG_PORT_TX_VM BIT(PRIV_FLAG_PORT_TX_VM_BIT)
+
+#define PRIV_FLAGS_ADAP 0
+#define PRIV_FLAGS_PORT PRIV_FLAG_PORT_TX_VM
+
struct adapter;
struct sge_rspq;
@@ -553,6 +562,7 @@ struct port_info {
struct hwtstamp_config tstamp_config;
bool ptp_enable;
struct sched_table *sched_tbl;
+ u32 eth_flags;
};
struct dentry;
@@ -863,6 +873,7 @@ struct adapter {
unsigned int flags;
unsigned int adap_idx;
enum chip_type chip;
+ unsigned int eth_flags;
int msg_enable;
__be16 vxlan_port;
@@ -1324,6 +1335,8 @@ void t4_free_sge_resources(struct adapter *adap);
void t4_free_ofld_rxqs(struct adapter *adap, int n, struct sge_ofld_rxq *q);
irq_handler_t t4_intr_handler(struct adapter *adap);
netdev_tx_t t4_eth_xmit(struct sk_buff *skb, struct net_device *dev);
+netdev_tx_t t4vf_eth_xmit(struct sk_buff *skb, struct net_device *dev);
+netdev_tx_t t4_start_xmit(struct sk_buff *skb, struct net_device *dev);
int t4_ethrx_handler(struct sge_rspq *q, const __be64 *rsp,
const struct pkt_gl *gl);
int t4_mgmt_tx(struct adapter *adap, struct sk_buff *skb);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index c54fd18..b329bd1 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -3211,7 +3211,7 @@ static netdev_features_t cxgb_fix_features(struct net_device *dev,
static const struct net_device_ops cxgb4_netdev_ops = {
.ndo_open = cxgb_open,
.ndo_stop = cxgb_close,
- .ndo_start_xmit = t4_eth_xmit,
+ .ndo_start_xmit = t4_start_xmit,
.ndo_select_queue = cxgb_select_queue,
.ndo_get_stats64 = cxgb_get_stats,
.ndo_set_rx_mode = cxgb_set_rxmode,
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index 0f87e97..b914a5e 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -1549,6 +1549,373 @@ out_free: dev_kfree_skb_any(skb);
return NETDEV_TX_OK;
}
+/* Constants ... */
+enum {
+ /* Egress Queue sizes, producer and consumer indices are all in units
+ * of Egress Context Units bytes. Note that as far as the hardware is
+ * concerned, the free list is an Egress Queue (the host produces free
+ * buffers which the hardware consumes) and free list entries are
+ * 64-bit PCI DMA addresses.
+ */
+ EQ_UNIT = SGE_EQ_IDXSIZE,
+ FL_PER_EQ_UNIT = EQ_UNIT / sizeof(__be64),
+ TXD_PER_EQ_UNIT = EQ_UNIT / sizeof(__be64),
+
+ T4VF_ETHTXQ_MAX_HDR = (sizeof(struct fw_eth_tx_pkt_vm_wr) +
+ sizeof(struct cpl_tx_pkt_lso_core) +
+ sizeof(struct cpl_tx_pkt_core)) / sizeof(__be64),
+};
+
+/**
+ * t4vf_is_eth_imm - can an Ethernet packet be sent as immediate data?
+ * @skb: the packet
+ *
+ * Returns whether an Ethernet packet is small enough to fit completely as
+ * immediate data.
+ */
+static inline int t4vf_is_eth_imm(const struct sk_buff *skb)
+{
+ /* The VF Driver uses the FW_ETH_TX_PKT_VM_WR firmware Work Request
+ * which does not accommodate immediate data. We could dike out all
+ * of the support code for immediate data but that would tie our hands
+ * too much if we ever want to enhace the firmware. It would also
+ * create more differences between the PF and VF Drivers.
+ */
+ return false;
+}
+
+/**
+ * t4vf_calc_tx_flits - calculate the number of flits for a packet TX WR
+ * @skb: the packet
+ *
+ * Returns the number of flits needed for a TX Work Request for the
+ * given Ethernet packet, including the needed WR and CPL headers.
+ */
+static inline unsigned int t4vf_calc_tx_flits(const struct sk_buff *skb)
+{
+ unsigned int flits;
+
+ /* If the skb is small enough, we can pump it out as a work request
+ * with only immediate data. In that case we just have to have the
+ * TX Packet header plus the skb data in the Work Request.
+ */
+ if (t4vf_is_eth_imm(skb))
+ return DIV_ROUND_UP(skb->len + sizeof(struct cpl_tx_pkt),
+ sizeof(__be64));
+
+ /* Otherwise, we're going to have to construct a Scatter gather list
+ * of the skb body and fragments. We also include the flits necessary
+ * for the TX Packet Work Request and CPL. We always have a firmware
+ * Write Header (incorporated as part of the cpl_tx_pkt_lso and
+ * cpl_tx_pkt structures), followed by either a TX Packet Write CPL
+ * message or, if we're doing a Large Send Offload, an LSO CPL message
+ * with an embedded TX Packet Write CPL message.
+ */
+ flits = sgl_len(skb_shinfo(skb)->nr_frags + 1);
+ if (skb_shinfo(skb)->gso_size)
+ flits += (sizeof(struct fw_eth_tx_pkt_vm_wr) +
+ sizeof(struct cpl_tx_pkt_lso_core) +
+ sizeof(struct cpl_tx_pkt_core)) / sizeof(__be64);
+ else
+ flits += (sizeof(struct fw_eth_tx_pkt_vm_wr) +
+ sizeof(struct cpl_tx_pkt_core)) / sizeof(__be64);
+ return flits;
+}
+
+/**
+ * t4vf_eth_xmit - add a packet to an Ethernet TX queue
+ * @skb: the packet
+ * @dev: the egress net device
+ *
+ * Add a packet to an SGE Ethernet TX queue. Runs with softirqs disabled.
+ */
+netdev_tx_t t4vf_eth_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+ u32 wr_mid;
+ u64 cntrl, *end;
+ int qidx, credits, max_pkt_len;
+ unsigned int flits, ndesc;
+ struct adapter *adapter;
+ struct sge_eth_txq *txq;
+ const struct port_info *pi;
+ struct fw_eth_tx_pkt_vm_wr *wr;
+ struct cpl_tx_pkt_core *cpl;
+ const struct skb_shared_info *ssi;
+ dma_addr_t addr[MAX_SKB_FRAGS + 1];
+ const size_t fw_hdr_copy_len = (sizeof(wr->ethmacdst) +
+ sizeof(wr->ethmacsrc) +
+ sizeof(wr->ethtype) +
+ sizeof(wr->vlantci));
+
+ /* The chip minimum packet length is 10 octets but the firmware
+ * command that we are using requires that we copy the Ethernet header
+ * (including the VLAN tag) into the header so we reject anything
+ * smaller than that ...
+ */
+ if (unlikely(skb->len < fw_hdr_copy_len))
+ goto out_free;
+
+ /* Discard the packet if the length is greater than mtu */
+ max_pkt_len = ETH_HLEN + dev->mtu;
+ if (skb_vlan_tag_present(skb))
+ max_pkt_len += VLAN_HLEN;
+ if (!skb_shinfo(skb)->gso_size && (unlikely(skb->len > max_pkt_len)))
+ goto out_free;
+
+ /* Figure out which TX Queue we're going to use. */
+ pi = netdev_priv(dev);
+ adapter = pi->adapter;
+ qidx = skb_get_queue_mapping(skb);
+ WARN_ON(qidx >= pi->nqsets);
+ txq = &adapter->sge.ethtxq[pi->first_qset + qidx];
+
+ /* Take this opportunity to reclaim any TX Descriptors whose DMA
+ * transfers have completed.
+ */
+ cxgb4_reclaim_completed_tx(adapter, &txq->q, true);
+
+ /* Calculate the number of flits and TX Descriptors we're going to
+ * need along with how many TX Descriptors will be left over after
+ * we inject our Work Request.
+ */
+ flits = t4vf_calc_tx_flits(skb);
+ ndesc = flits_to_desc(flits);
+ credits = txq_avail(&txq->q) - ndesc;
+
+ if (unlikely(credits < 0)) {
+ /* Not enough room for this packet's Work Request. Stop the
+ * TX Queue and return a "busy" condition. The queue will get
+ * started later on when the firmware informs us that space
+ * has opened up.
+ */
+ eth_txq_stop(txq);
+ dev_err(adapter->pdev_dev,
+ "%s: TX ring %u full while queue awake!\n",
+ dev->name, qidx);
+ return NETDEV_TX_BUSY;
+ }
+
+ if (!t4vf_is_eth_imm(skb) &&
+ unlikely(cxgb4_map_skb(adapter->pdev_dev, skb, addr) < 0)) {
+ /* We need to map the skb into PCI DMA space (because it can't
+ * be in-lined directly into the Work Request) and the mapping
+ * operation failed. Record the error and drop the packet.
+ */
+ txq->mapping_err++;
+ goto out_free;
+ }
+
+ wr_mid = FW_WR_LEN16_V(DIV_ROUND_UP(flits, 2));
+ if (unlikely(credits < ETHTXQ_STOP_THRES)) {
+ /* After we're done injecting the Work Request for this
+ * packet, we'll be below our "stop threshold" so stop the TX
+ * Queue now and schedule a request for an SGE Egress Queue
+ * Update message. The queue will get started later on when
+ * the firmware processes this Work Request and sends us an
+ * Egress Queue Status Update message indicating that space
+ * has opened up.
+ */
+ eth_txq_stop(txq);
+ wr_mid |= FW_WR_EQUEQ_F | FW_WR_EQUIQ_F;
+ }
+
+ /* Start filling in our Work Request. Note that we do _not_ handle
+ * the WR Header wrapping around the TX Descriptor Ring. If our
+ * maximum header size ever exceeds one TX Descriptor, we'll need to
+ * do something else here.
+ */
+ WARN_ON(DIV_ROUND_UP(T4VF_ETHTXQ_MAX_HDR, TXD_PER_EQ_UNIT) > 1);
+ wr = (void *)&txq->q.desc[txq->q.pidx];
+ wr->equiq_to_len16 = cpu_to_be32(wr_mid);
+ wr->r3[0] = cpu_to_be32(0);
+ wr->r3[1] = cpu_to_be32(0);
+ skb_copy_from_linear_data(skb, (void *)wr->ethmacdst, fw_hdr_copy_len);
+ end = (u64 *)wr + flits;
+
+ /* If this is a Large Send Offload packet we'll put in an LSO CPL
+ * message with an encapsulated TX Packet CPL message. Otherwise we
+ * just use a TX Packet CPL message.
+ */
+ ssi = skb_shinfo(skb);
+ if (ssi->gso_size) {
+ struct cpl_tx_pkt_lso_core *lso = (void *)(wr + 1);
+ bool v6 = (ssi->gso_type & SKB_GSO_TCPV6) != 0;
+ int l3hdr_len = skb_network_header_len(skb);
+ int eth_xtra_len = skb_network_offset(skb) - ETH_HLEN;
+
+ wr->op_immdlen =
+ cpu_to_be32(FW_WR_OP_V(FW_ETH_TX_PKT_VM_WR) |
+ FW_WR_IMMDLEN_V(sizeof(*lso) +
+ sizeof(*cpl)));
+ /* Fill in the LSO CPL message. */
+ lso->lso_ctrl =
+ cpu_to_be32(LSO_OPCODE_V(CPL_TX_PKT_LSO) |
+ LSO_FIRST_SLICE_F |
+ LSO_LAST_SLICE_F |
+ LSO_IPV6_V(v6) |
+ LSO_ETHHDR_LEN_V(eth_xtra_len / 4) |
+ LSO_IPHDR_LEN_V(l3hdr_len / 4) |
+ LSO_TCPHDR_LEN_V(tcp_hdr(skb)->doff));
+ lso->ipid_ofst = cpu_to_be16(0);
+ lso->mss = cpu_to_be16(ssi->gso_size);
+ lso->seqno_offset = cpu_to_be32(0);
+ if (is_t4(adapter->params.chip))
+ lso->len = cpu_to_be32(skb->len);
+ else
+ lso->len = cpu_to_be32(LSO_T5_XFER_SIZE_V(skb->len));
+
+ /* Set up TX Packet CPL pointer, control word and perform
+ * accounting.
+ */
+ cpl = (void *)(lso + 1);
+
+ if (CHELSIO_CHIP_VERSION(adapter->params.chip) <= CHELSIO_T5)
+ cntrl = TXPKT_ETHHDR_LEN_V(eth_xtra_len);
+ else
+ cntrl = T6_TXPKT_ETHHDR_LEN_V(eth_xtra_len);
+
+ cntrl |= TXPKT_CSUM_TYPE_V(v6 ?
+ TX_CSUM_TCPIP6 : TX_CSUM_TCPIP) |
+ TXPKT_IPHDR_LEN_V(l3hdr_len);
+ txq->tso++;
+ txq->tx_cso += ssi->gso_segs;
+ } else {
+ int len;
+
+ len = (t4vf_is_eth_imm(skb)
+ ? skb->len + sizeof(*cpl)
+ : sizeof(*cpl));
+ wr->op_immdlen =
+ cpu_to_be32(FW_WR_OP_V(FW_ETH_TX_PKT_VM_WR) |
+ FW_WR_IMMDLEN_V(len));
+
+ /* Set up TX Packet CPL pointer, control word and perform
+ * accounting.
+ */
+ cpl = (void *)(wr + 1);
+ if (skb->ip_summed == CHECKSUM_PARTIAL) {
+ cntrl = hwcsum(adapter->params.chip, skb) |
+ TXPKT_IPCSUM_DIS_F;
+ txq->tx_cso++;
+ } else {
+ cntrl = TXPKT_L4CSUM_DIS_F | TXPKT_IPCSUM_DIS_F;
+ }
+ }
+
+ /* If there's a VLAN tag present, add that to the list of things to
+ * do in this Work Request.
+ */
+ if (skb_vlan_tag_present(skb)) {
+ txq->vlan_ins++;
+ cntrl |= TXPKT_VLAN_VLD_F | TXPKT_VLAN_V(skb_vlan_tag_get(skb));
+ }
+
+ /* Fill in the TX Packet CPL message header. */
+ cpl->ctrl0 = cpu_to_be32(TXPKT_OPCODE_V(CPL_TX_PKT_XT) |
+ TXPKT_INTF_V(pi->port_id) |
+ TXPKT_PF_V(0));
+ cpl->pack = cpu_to_be16(0);
+ cpl->len = cpu_to_be16(skb->len);
+ cpl->ctrl1 = cpu_to_be64(cntrl);
+
+ /* Fill in the body of the TX Packet CPL message with either in-lined
+ * data or a Scatter/Gather List.
+ */
+ if (t4vf_is_eth_imm(skb)) {
+ /* In-line the packet's data and free the skb since we don't
+ * need it any longer.
+ */
+ cxgb4_inline_tx_skb(skb, &txq->q, cpl + 1);
+ dev_consume_skb_any(skb);
+ } else {
+ /* Write the skb's Scatter/Gather list into the TX Packet CPL
+ * message and retain a pointer to the skb so we can free it
+ * later when its DMA completes. (We store the skb pointer
+ * in the Software Descriptor corresponding to the last TX
+ * Descriptor used by the Work Request.)
+ *
+ * The retained skb will be freed when the corresponding TX
+ * Descriptors are reclaimed after their DMAs complete.
+ * However, this could take quite a while since, in general,
+ * the hardware is set up to be lazy about sending DMA
+ * completion notifications to us and we mostly perform TX
+ * reclaims in the transmit routine.
+ *
+ * This is good for performamce but means that we rely on new
+ * TX packets arriving to run the destructors of completed
+ * packets, which open up space in their sockets' send queues.
+ * Sometimes we do not get such new packets causing TX to
+ * stall. A single UDP transmitter is a good example of this
+ * situation. We have a clean up timer that periodically
+ * reclaims completed packets but it doesn't run often enough
+ * (nor do we want it to) to prevent lengthy stalls. A
+ * solution to this problem is to run the destructor early,
+ * after the packet is queued but before it's DMAd. A con is
+ * that we lie to socket memory accounting, but the amount of
+ * extra memory is reasonable (limited by the number of TX
+ * descriptors), the packets do actually get freed quickly by
+ * new packets almost always, and for protocols like TCP that
+ * wait for acks to really free up the data the extra memory
+ * is even less. On the positive side we run the destructors
+ * on the sending CPU rather than on a potentially different
+ * completing CPU, usually a good thing.
+ *
+ * Run the destructor before telling the DMA engine about the
+ * packet to make sure it doesn't complete and get freed
+ * prematurely.
+ */
+ struct ulptx_sgl *sgl = (struct ulptx_sgl *)(cpl + 1);
+ struct sge_txq *tq = &txq->q;
+ int last_desc;
+
+ /* If the Work Request header was an exact multiple of our TX
+ * Descriptor length, then it's possible that the starting SGL
+ * pointer lines up exactly with the end of our TX Descriptor
+ * ring. If that's the case, wrap around to the beginning
+ * here ...
+ */
+ if (unlikely((void *)sgl == (void *)tq->stat)) {
+ sgl = (void *)tq->desc;
+ end = (void *)((void *)tq->desc +
+ ((void *)end - (void *)tq->stat));
+ }
+
+ cxgb4_write_sgl(skb, tq, sgl, end, 0, addr);
+ skb_orphan(skb);
+
+ last_desc = tq->pidx + ndesc - 1;
+ if (last_desc >= tq->size)
+ last_desc -= tq->size;
+ tq->sdesc[last_desc].skb = skb;
+ tq->sdesc[last_desc].sgl = sgl;
+ }
+
+ /* Advance our internal TX Queue state, tell the hardware about
+ * the new TX descriptors and return success.
+ */
+ txq_advance(&txq->q, ndesc);
+
+ cxgb4_ring_tx_db(adapter, &txq->q, ndesc);
+ return NETDEV_TX_OK;
+
+out_free:
+ /* An error of some sort happened. Free the TX skb and tell the
+ * OS that we've "dealt" with the packet ...
+ */
+ dev_kfree_skb_any(skb);
+ return NETDEV_TX_OK;
+}
+
+netdev_tx_t t4_start_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+ struct port_info *pi = netdev_priv(dev);
+
+ if (unlikely(pi->eth_flags & PRIV_FLAG_PORT_TX_VM))
+ return t4vf_eth_xmit(skb, dev);
+
+ return t4_eth_xmit(skb, dev);
+}
+
/**
* reclaim_completed_tx_imm - reclaim completed control-queue Tx descs
* @q: the SGE control Tx queue
--
2.1.0
^ permalink raw reply related
* [PATCH net-next 2/2] cxgb4: Support ethtool private flags
From: Ganesh Goudar @ 2018-05-14 7:55 UTC (permalink / raw)
To: netdev, davem
Cc: nirranjan, indranil, venkatesh, Arjun Vynipadath, Casey Leedom,
Ganesh Goudar
From: Arjun Vynipadath <arjun@chelsio.com>
This is used to change TX workrequests, which helps in
host->vf communication.
Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_ethtool.c | 42 ++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ethtool.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ethtool.c
index 59d04d7..1d979a6 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ethtool.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_ethtool.c
@@ -177,6 +177,10 @@ static char loopback_stats_strings[][ETH_GSTRING_LEN] = {
"bg3_frames_trunc ",
};
+static const char cxgb4_priv_flags_strings[][ETH_GSTRING_LEN] = {
+ [PRIV_FLAG_PORT_TX_VM_BIT] = "port_tx_vm_wr",
+};
+
static int get_sset_count(struct net_device *dev, int sset)
{
switch (sset) {
@@ -185,6 +189,8 @@ static int get_sset_count(struct net_device *dev, int sset)
ARRAY_SIZE(adapter_stats_strings) +
ARRAY_SIZE(channel_stats_strings) +
ARRAY_SIZE(loopback_stats_strings);
+ case ETH_SS_PRIV_FLAGS:
+ return ARRAY_SIZE(cxgb4_priv_flags_strings);
default:
return -EOPNOTSUPP;
}
@@ -235,6 +241,7 @@ static void get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
FW_HDR_FW_VER_MINOR_G(exprom_vers),
FW_HDR_FW_VER_MICRO_G(exprom_vers),
FW_HDR_FW_VER_BUILD_G(exprom_vers));
+ info->n_priv_flags = ARRAY_SIZE(cxgb4_priv_flags_strings);
}
static void get_strings(struct net_device *dev, u32 stringset, u8 *data)
@@ -250,6 +257,9 @@ static void get_strings(struct net_device *dev, u32 stringset, u8 *data)
data += sizeof(channel_stats_strings);
memcpy(data, loopback_stats_strings,
sizeof(loopback_stats_strings));
+ } else if (stringset == ETH_SS_PRIV_FLAGS) {
+ memcpy(data, cxgb4_priv_flags_strings,
+ sizeof(cxgb4_priv_flags_strings));
}
}
@@ -1503,6 +1513,36 @@ static int cxgb4_get_module_eeprom(struct net_device *dev,
offset, len, &data[eprom->len - len]);
}
+static u32 cxgb4_get_priv_flags(struct net_device *netdev)
+{
+ struct port_info *pi = netdev_priv(netdev);
+ struct adapter *adapter = pi->adapter;
+
+ return (adapter->eth_flags | pi->eth_flags);
+}
+
+/**
+ * set_flags - set/unset specified flags if passed in new_flags
+ * @cur_flags: pointer to current flags
+ * @new_flags: new incoming flags
+ * @flags: set of flags to set/unset
+ */
+static inline void set_flags(u32 *cur_flags, u32 new_flags, u32 flags)
+{
+ *cur_flags = (*cur_flags & ~flags) | (new_flags & flags);
+}
+
+static int cxgb4_set_priv_flags(struct net_device *netdev, u32 flags)
+{
+ struct port_info *pi = netdev_priv(netdev);
+ struct adapter *adapter = pi->adapter;
+
+ set_flags(&adapter->eth_flags, flags, PRIV_FLAGS_ADAP);
+ set_flags(&pi->eth_flags, flags, PRIV_FLAGS_PORT);
+
+ return 0;
+}
+
static const struct ethtool_ops cxgb_ethtool_ops = {
.get_link_ksettings = get_link_ksettings,
.set_link_ksettings = set_link_ksettings,
@@ -1539,6 +1579,8 @@ static const struct ethtool_ops cxgb_ethtool_ops = {
.get_dump_data = get_dump_data,
.get_module_info = cxgb4_get_module_info,
.get_module_eeprom = cxgb4_get_module_eeprom,
+ .get_priv_flags = cxgb4_get_priv_flags,
+ .set_priv_flags = cxgb4_set_priv_flags,
};
void cxgb4_set_ethtool_ops(struct net_device *netdev)
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net-next v2 15/15] arm64: dts: allwinner: a64: add SRAM controller device tree node
From: Maxime Ripard @ 2018-05-14 8:03 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Icenowy Zheng, linux-arm-kernel, Mark Rutland, devicetree,
Stephen Boyd, netdev, Michael Turquette, Rob Herring,
Corentin Labbe, Mark Brown, Giuseppe Cavallaro, linux-clk
In-Reply-To: <CAGb2v64xTNqQQSppw2NZoLn+ViQNQLytn1EukLqw+HJzf1=5ig@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3965 bytes --]
1;5201;0c
On Sun, May 13, 2018 at 12:37:49PM -0700, Chen-Yu Tsai wrote:
> On Wed, May 2, 2018 at 4:54 AM, Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > On Wed, May 02, 2018 at 06:19:51PM +0800, Icenowy Zheng wrote:
> >>
> >>
> >> 于 2018年5月2日 GMT+08:00 下午5:53:21, Chen-Yu Tsai <wens@csie.org> 写到:
> >> >On Wed, May 2, 2018 at 5:51 PM, Maxime Ripard
> >> ><maxime.ripard@bootlin.com> wrote:
> >> >> Hi,
> >> >>
> >> >> On Wed, May 02, 2018 at 12:12:27AM +0800, Chen-Yu Tsai wrote:
> >> >>> From: Icenowy Zheng <icenowy@aosc.io>
> >> >>>
> >> >>> Allwinner A64 has a SRAM controller, and in the device tree
> >> >currently
> >> >>> we have a syscon node to enable EMAC driver to access the EMAC clock
> >> >>> register. As SRAM controller driver can now export regmap for this
> >> >>> register, replace the syscon node to the SRAM controller device
> >> >node,
> >> >>> and let EMAC driver to acquire its EMAC clock regmap.
> >> >>>
> >> >>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> >> >>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >> >>> ---
> >> >>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 23
> >> >+++++++++++++++----
> >> >>> 1 file changed, 19 insertions(+), 4 deletions(-)
> >> >>>
> >> >>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >>> index 1b2ef28c42bd..1c37659d9d41 100644
> >> >>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> >> >>> @@ -168,10 +168,25 @@
> >> >>> #size-cells = <1>;
> >> >>> ranges;
> >> >>>
> >> >>> - syscon: syscon@1c00000 {
> >> >>> - compatible =
> >> >"allwinner,sun50i-a64-system-controller",
> >> >>> - "syscon";
> >> >>> + sram_controller: sram-controller@1c00000 {
> >> >>> + compatible =
> >> >"allwinner,sun50i-a64-sram-controller";
> >> >>
> >> >> I don't think there's anything preventing us from keeping the
> >> >> -system-controller compatible. It's what was in the DT before, and
> >> >> it's how it's called in the datasheet.
> >> >
> >> >I actually meant to ask you about this. The -system-controller
> >> >compatible matches the datasheet better. Maybe we should just
> >> >switch to that one?
> >>
> >> No, if we do the switch the system-controller compatible,
> >> the device will be probed on the same memory region with
> >> a syscon on old DTs.
> >
> > The device hasn't magically changed either. Maybe we just need to add
> > a check to make sure we don't have the syscon compatible in the SRAM
> > driver probe so that the double driver issue doesn't happen?
>
> The syscon interface (which is not even a full blown device driver)
> only looks at the "syscon" compatible. Either way we're removing that
> part from the device tree so things should be ok for new device trees.
> As Maxime mentioned we can do a check for the syscon compatible and
> either give a warning to the user asking them to update their device
> tree, or not register our custom regmap, or not probe the SRAM driver.
> Personally I prefer the first option. The system controller block is
> probed before any syscon users, so we should be fine, given the dwmac
> driver goes the custom regmap path first.
>
> BTW, I still might end up changing the compatible. The manual uses
> "system control", not "system controller", which I think makes sense,
> since it is just a bunch of register files, kind of like the GRF
> (General Register Files) block found in Rockchip SoCs [1], and not an
> actual "controller".
I'm not really fond of that, but we should at least make it consistent
on the other patches Paul sent then.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] net: phy: sfp: handle cases where neither BR,min nor BR,max is given
From: Antoine Tenart @ 2018-05-14 8:11 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Antoine Tenart, davem, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, gregory.clement, miquel.raynal, nadavh,
stefanc, ymarkman, mw
In-Reply-To: <20180508123026.GJ16141@n2100.armlinux.org.uk>
Hi Russell,
On Tue, May 08, 2018 at 01:30:26PM +0100, Russell King - ARM Linux wrote:
>
> The electronic engineer in me says that using zero isn't really valid
> because there are coupling capacitors in the SFP module that block DC.
> These blocking capacitors are required by the SFP+ specs to have a high
> pass pole of between 20kHz and 100kHz - in other words, frequencies
> below this are attenuated by the coupling capacitors. The relationship
> between this and the bit rate will be a function of the encoding, so we
> can't come to a definitive figure without some math (and I want to be
> lazy about that!)
>
> Practically, we're talking about SerDes Ethernet, where the bit rate is
> no lower than 100Mbps [*], which will always have a frequency well above
> this cut-off. So, I don't have any problem with your approach to
> setting the minimum to zero. Therefore,
>
> Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Thanks for looking into it!
Antoine
--
Antoine Ténart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* (unknown),
From: системы администратор @ 2018-05-14 6:33 UTC (permalink / raw)
пользователь веб-почты
Обратите внимание, что 95% ваших писем, полученных после обновления сервера веб-почты в последнее время в нашей базе данных, были отложены. Регулярно получать и отправлять свои сообщения. Техническая команда нашей веб-почты обновит вашу учетную запись в течение 3 рабочих дней. Если вы этого не сделаете, ваша учетная запись будет временно приостановлена нашими службами. Чтобы повторно подтвердить свой почтовый ящик, пришлите следующую информацию:
обычный:
Имя пользователя:
пароль:
Подтвердите Пароль:
Предупреждение!! Если это не позволит обновлять учетные записи в
течение двух дней после получения электронной почты, они будут
постоянно потерять учетные записи владельцев учетных записей
веб-почты.
Спасибо за ваше сотрудничество!
Copyright © 2017-2018 Служба технической поддержки WebMail, Inc.
^ permalink raw reply
* [PATCH] net: phy: micrel: workaround for errata #2 for KSZ9031
From: Marco Felsch @ 2018-05-14 8:22 UTC (permalink / raw)
To: robh+dt, mark.rutland, andrew, f.fainelli
Cc: netdev, devicetree, kernel, Markus Niebel
From: Markus Niebel <Markus.Niebel@tqs.de>
handle errata #2 for KSZ9031: force 1000Base-T master
Attention: enabling the workaround will cause no link to
other GIGE master.
Signed-off-by: Markus Niebel <Markus.Niebel@tqs.de>
[m.felsch@pengutronix.de: move dt binding to the KSZ9031 entry]
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
.../devicetree/bindings/net/micrel-ksz90x1.txt | 3 +++
drivers/net/phy/micrel.c | 18 ++++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
index 42a248301615..e2465fbbbcef 100644
--- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
+++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
@@ -57,6 +57,9 @@ KSZ9031:
- txd2-skew-ps : Skew control of TX data 2 pad
- txd3-skew-ps : Skew control of TX data 3 pad
+ - force-master: Boolean, force phy to master mode. This is a
+ workaround at least for KSZ9031 errata #2.
+
Examples:
mdio {
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index f41b224a9cdb..3e4243e4f7a7 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -528,6 +528,8 @@ static int ksz9031_enable_edpd(struct phy_device *phydev)
static int ksz9031_config_init(struct phy_device *phydev)
{
+ int rc;
+ u16 val;
const struct device *dev = &phydev->mdio.dev;
const struct device_node *of_node = dev->of_node;
static const char *clk_skews[2] = {"rxc-skew-ps", "txc-skew-ps"};
@@ -573,6 +575,22 @@ static int ksz9031_config_init(struct phy_device *phydev)
ksz9031_of_load_skew_values(phydev, of_node,
MII_KSZ9031RN_TX_DATA_PAD_SKEW, 4,
tx_data_skews, 4);
+
+ /* force master mode -> errata #2
+ * attention: Master <-> Master will not work
+ */
+ if (of_property_read_bool(of_node, "force-master")) {
+ rc = phy_read(phydev, MII_CTRL1000);
+ if (rc >= 0) {
+ val = (u16)rc;
+ /* enable master mode, config &
+ * prefer master
+ */
+ val |= (CTL1000_ENABLE_MASTER |
+ CTL1000_AS_MASTER);
+ phy_write(phydev, MII_CTRL1000, val);
+ }
+ }
}
return ksz9031_center_flp_timing(phydev);
--
2.17.0
^ permalink raw reply related
* Re: [PATCH bpf-next] samples/bpf: xdp_monitor, accept short options
From: Prashant Bhole @ 2018-05-14 8:28 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Daniel Borkmann, Alexei Starovoitov, David S . Miller, netdev
In-Reply-To: <20180511183125.6b4f92e2@redhat.com>
On 5/12/2018 1:31 AM, Jesper Dangaard Brouer wrote:
> On Fri, 11 May 2018 10:37:51 +0900
> Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> wrote:
>
>> updated optstring accept short options
>>
>> Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
>> ---
>> samples/bpf/xdp_monitor_user.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/samples/bpf/xdp_monitor_user.c b/samples/bpf/xdp_monitor_user.c
>> index 894bc64c2cac..668511c77aaf 100644
>> --- a/samples/bpf/xdp_monitor_user.c
>> +++ b/samples/bpf/xdp_monitor_user.c
>> @@ -594,7 +594,7 @@ int main(int argc, char **argv)
>> snprintf(bpf_obj_file, sizeof(bpf_obj_file), "%s_kern.o", argv[0]);
>>
>> /* Parse commands line args */
>> - while ((opt = getopt_long(argc, argv, "h",
>> + while ((opt = getopt_long(argc, argv, "hDSs:",
>> long_options, &longindex)) != -1) {
>> switch (opt) {
>> case 'D':
>
> It was actually on purpose that I didn't add the short options,
> in-order to force people use those "self-documenting" long-options when
> they show the usage on public mailing lists or in blog-posts.
Got it.
>
> If you want these short options, you also have to correct the "usage"
> function that state these are "internal" short-options.
I am submitting v2 with "usage" updated, because with usability point of
view it is nice to have short options. Thanks.
-Prashant
>
> Notice the long options parsing done by getopt_long() allow you to only
> specify part of the string. Al-through, I can see --s is ambiguous.
>
> $ sudo ./xdp_monitor --s
> ./xdp_monitor: option '--s' is ambiguous; possibilities: '--stats' '--sec'
^ permalink raw reply
* [PATCH bpf-next v2] samples/bpf: xdp_monitor, accept short options
From: Prashant Bhole @ 2018-05-14 8:29 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov
Cc: Prashant Bhole, Jesper Dangaard Brouer, David S . Miller, netdev
Updated optstring parameter for getopt_long() to accept short options.
Also updated usage() function.
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
---
samples/bpf/xdp_monitor_user.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/samples/bpf/xdp_monitor_user.c b/samples/bpf/xdp_monitor_user.c
index 894bc64c2cac..05ad3f590c91 100644
--- a/samples/bpf/xdp_monitor_user.c
+++ b/samples/bpf/xdp_monitor_user.c
@@ -58,7 +58,7 @@ static void usage(char *argv[])
printf(" flag (internal value:%d)",
*long_options[i].flag);
else
- printf("(internal short-option: -%c)",
+ printf("short-option: -%c",
long_options[i].val);
printf("\n");
}
@@ -594,7 +594,7 @@ int main(int argc, char **argv)
snprintf(bpf_obj_file, sizeof(bpf_obj_file), "%s_kern.o", argv[0]);
/* Parse commands line args */
- while ((opt = getopt_long(argc, argv, "h",
+ while ((opt = getopt_long(argc, argv, "hDSs:",
long_options, &longindex)) != -1) {
switch (opt) {
case 'D':
--
2.13.6
^ permalink raw reply related
* Re: [PATCH net-next v2 06/13] phy: add 2.5G SGMII mode to the phy_mode enum
From: Antoine Tenart @ 2018-05-14 8:37 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Antoine Tenart, davem, kishon, gregory.clement, andrew, jason,
sebastian.hesselbarth, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux-arm-kernel
In-Reply-To: <20180508123408.GK16141@n2100.armlinux.org.uk>
Hi Russell,
On Tue, May 08, 2018 at 01:34:08PM +0100, Russell King - ARM Linux wrote:
> On Fri, May 04, 2018 at 03:56:36PM +0200, Antoine Tenart wrote:
> > This patch adds one more generic PHY mode to the phy_mode enum, to allow
> > configuring generic PHYs to the 2.5G SGMII mode by using the set_mode
> > callback.
> >
> > Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
> > Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
>
> Would it be possible to get the 2.5G SGMII comphy support merged
> ahead of the rest of this series please - I don't think there's been
> any objections to it, and having it in mainline would then mean I can
> drop the Marvell Comphy code from my tree and transition to the bootlin
> Comphy code instead.
>
> Of course, the perfect solution would be to get the whole series merged,
> but I'm just thinking about the situation where we're still discussing
> points when the next merge window opens.
That would be great, and there are no dependency issue if patches 6 and
7 are taken ahead.
Kishon: since there are no objection to these two phy patches, could you
take them?
Thanks!
Antoine
--
Antoine Ténart, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net] xfrm6: avoid potential infinite loop in _decode_session6()
From: Steffen Klassert @ 2018-05-14 8:41 UTC (permalink / raw)
To: David Miller; +Cc: edumazet, netdev, eric.dumazet, nicolas.dichtel
In-Reply-To: <20180513.202349.1985276646648462963.davem@davemloft.net>
On Sun, May 13, 2018 at 08:23:49PM -0400, David Miller wrote:
> From: Eric Dumazet <edumazet@google.com>
> Date: Sat, 12 May 2018 02:49:30 -0700
>
> > syzbot found a way to trigger an infinitie loop by overflowing
> > @offset variable that has been forced to use u16 for some very
> > obscure reason in the past.
> >
> > We probably want to look at NEXTHDR_FRAGMENT handling which looks
> > wrong, in a separate patch.
> >
> > In net-next, we shall try to use skb_header_pointer() instead of
> > pskb_may_pull().
> ...
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Cc: Steffen Klassert <steffen.klassert@secunet.com>
> > Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> > Reported-by: syzbot+0053c8...@syzkaller.appspotmail.com
>
> Steffen, I am assuming you will pick this up.
Yes, now applied to the ipsec tree.
Thanks a lot Eric!
^ permalink raw reply
* 答复: [PATCH] ipvlan: flush arp table when mac address changed
From: liuqifa @ 2018-05-14 8:49 UTC (permalink / raw)
To: Paolo Abeni, davem@davemloft.net, dsahern@gmail.com,
maheshb@google.com, weiyongjun (A), maowenan, Dingtianhong
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1526283581.4411.2.camel@redhat.com>
Hi,
>
> Hi,
>
> On Sat, 2018-05-12 at 19:00 +0800, liuqifa@huawei.com wrote:
> > From: Keefe Liu <liuqifa@huawei.com>
> >
> > When master device's mac has been changed, the commit <32c10bbfe914>
> > "ipvlan: always use the current L2 addr of the master" makes the
> > IPVlan devices's mac changed also, but it doesn't flush the IPVlan's
> > arp table.
> >
> > Signed-off-by: Keefe Liu <liuqifa@huawei.com>
> > ---
> > drivers/net/ipvlan/ipvlan_main.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ipvlan/ipvlan_main.c
> > b/drivers/net/ipvlan/ipvlan_main.c
> > index 450eec2..a1edfe1 100644
> > --- a/drivers/net/ipvlan/ipvlan_main.c
> > +++ b/drivers/net/ipvlan/ipvlan_main.c
> > @@ -7,6 +7,8 @@
> > *
> > */
> >
> > +#include <net/neighbour.h>
> > +#include <net/arp.h>
> > #include "ipvlan.h"
> >
> > static unsigned int ipvlan_netid __read_mostly; @@ -792,8 +794,10 @@
> > static int ipvlan_device_event(struct notifier_block *unused,
> > break;
> >
> > case NETDEV_CHANGEADDR:
> > - list_for_each_entry(ipvlan, &port->ipvlans, pnode)
> > + list_for_each_entry(ipvlan, &port->ipvlans, pnode) {
> > ether_addr_copy(ipvlan->dev->dev_addr, dev-
> >dev_addr);
> > + neigh_changeaddr(&arp_tbl, ipvlan->dev);
> > + }
>
> Why don't using:
>
> call_netdevice_notifiers(NETDEV_CHANGEADDR, ipvlan->dev);
>
> instead?
>
> that is what other stacked device - bridge and vlans - are currently doing in
> the same scenario.
>
> Thanks,
>
> Paolo
>
Yes, I agre with you, this is a better solution.
Thanks
Keefe
^ permalink raw reply
* Re: [PATCH] net: phy: micrel: workaround for errata #2 for KSZ9031
From: Uwe Kleine-König @ 2018-05-14 9:05 UTC (permalink / raw)
To: Marco Felsch
Cc: robh+dt, mark.rutland, andrew, f.fainelli, netdev, Markus Niebel,
kernel, devicetree
In-Reply-To: <20180514082218.29158-1-m.felsch@pengutronix.de>
Hello,
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> index f41b224a9cdb..3e4243e4f7a7 100644
> --- a/drivers/net/phy/micrel.c
> +++ b/drivers/net/phy/micrel.c
> @@ -528,6 +528,8 @@ static int ksz9031_enable_edpd(struct phy_device *phydev)
>
> static int ksz9031_config_init(struct phy_device *phydev)
> {
> + int rc;
> + u16 val;
These could be declared in more local scope.
> const struct device *dev = &phydev->mdio.dev;
> const struct device_node *of_node = dev->of_node;
> static const char *clk_skews[2] = {"rxc-skew-ps", "txc-skew-ps"};
> @@ -573,6 +575,22 @@ static int ksz9031_config_init(struct phy_device *phydev)
> ksz9031_of_load_skew_values(phydev, of_node,
> MII_KSZ9031RN_TX_DATA_PAD_SKEW, 4,
> tx_data_skews, 4);
> +
> + /* force master mode -> errata #2
> + * attention: Master <-> Master will not work
> + */
> + if (of_property_read_bool(of_node, "force-master")) {
> + rc = phy_read(phydev, MII_CTRL1000);
> + if (rc >= 0) {
> + val = (u16)rc;
> + /* enable master mode, config &
> + * prefer master
> + */
> + val |= (CTL1000_ENABLE_MASTER |
> + CTL1000_AS_MASTER);
> + phy_write(phydev, MII_CTRL1000, val);
There is no need for two variables, just use a single int variable that
on all Linux archs can hold the whole domain of u16 should be fine.
> + }
> + }
Maybe issue a warning if reading MII_CTRL1000 failed?
> }
>
> return ksz9031_center_flp_timing(phydev);
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH net-next v9 1/7] sched: Add Common Applications Kept Enhanced (cake) qdisc
From: Toke Høiland-Jørgensen @ 2018-05-14 9:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, cake
In-Reply-To: <20180513.200948.1658763899383204062.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Toke Høiland-Jørgensen <toke@toke.dk>
> Date: Tue, 08 May 2018 16:34:19 +0200
>
>> +struct cake_flow {
>> + /* this stuff is all needed per-flow at dequeue time */
>> + struct sk_buff *head;
>> + struct sk_buff *tail;
>
> Please do not invent your own SKB list handling mechanism.
We didn't invent it, we inherited it from fq_codel. I was actually about
to fix that, but then I noticed it was still around in fq_codel, and so
let it be. I can certainly fix it anyway, but, erm, why is it acceptable
in fq_codel but not in cake? struct sk_buff_head is not that new, is it?
>> +static void cake_heapify(struct cake_sched_data *q, u16 i)
>> +{
>> + static const u32 a = CAKE_MAX_TINS * CAKE_QUEUES;
>> + u32 m = i;
>> + u32 mb = cake_heap_get_backlog(q, m);
>
> Please order local variables from longest to shortest line.
>
> The entire submissions has this problem all over the place, please
> correct it patch-series wide.
Right-oh, one plantation of reverse christmas trees coming right up :)
-Toke
^ permalink raw reply
* Re: [PATCH v2] net/mlx4_core: Fix error handling in mlx4_init_port_info.
From: Tariq Toukan @ 2018-05-14 9:08 UTC (permalink / raw)
To: Tarick Bedeir, tariqt, gthelen, netdev, linux-rdma, linux-kernel,
David Miller
In-Reply-To: <20180513233845.135290-1-tarick@google.com>
On 14/05/2018 2:38 AM, Tarick Bedeir wrote:
> Avoid exiting the function with a lingering sysfs file (if the first
> call to device_create_file() fails while the second succeeds), and avoid
> calling devlink_port_unregister() twice.
>
> In other words, either mlx4_init_port_info() succeeds and returns zero, or
> it fails, returns non-zero, and requires no cleanup.
>
> Fixes: 096335b3f983 ("mlx4_core: Allow dynamic MTU configuration for IB
> ports")
> Signed-off-by: Tarick Bedeir <tarick@google.com>
> ---
> v1 -> v2: Added "Fixes" tag.
> ---
> drivers/net/ethernet/mellanox/mlx4/main.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
> index 4d84cab77105..e8a3a45d0b53 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/main.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/main.c
> @@ -3007,6 +3007,7 @@ static int mlx4_init_port_info(struct mlx4_dev *dev, int port)
> mlx4_err(dev, "Failed to create file for port %d\n", port);
> devlink_port_unregister(&info->devlink_port);
> info->port = -1;
> + return err;
> }
>
> sprintf(info->dev_mtu_name, "mlx4_port%d_mtu", port);
> @@ -3028,9 +3029,10 @@ static int mlx4_init_port_info(struct mlx4_dev *dev, int port)
> &info->port_attr);
> devlink_port_unregister(&info->devlink_port);
> info->port = -1;
> + return err;
> }
>
> - return err;
> + return 0;
> }
>
> static void mlx4_cleanup_port_info(struct mlx4_port_info *info)
>
Thanks for you patch.
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Dave, please queue for -stable.
Best,
Tariq
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox