* Re: [PATCH net-next 4/8] sctp: add SCTP_ASCONF_SUPPORTED sockopt
From: Xin Long @ 2019-08-19 14:43 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: network dev, linux-sctp, Neil Horman, davem
In-Reply-To: <20190819143052.GC2870@localhost.localdomain>
On Mon, Aug 19, 2019 at 10:30 PM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> On Mon, Aug 19, 2019 at 10:02:46PM +0800, Xin Long wrote:
> > SCTP_ASCONF_SUPPORTED sockopt is used to set enpoint's asconf
> > flag. With this feature, each endpoint will have its own flag
> > for its future asoc's asconf_capable, instead of netns asconf
> > flag.
>
> Is this backed by a RFC? If yes, it should be noted in the patch
> description.
> Quickly searching, I found only FreeBSD references.
RFC doesn't define this sockopt clearly, unlike prsctp and reconfig,
not sure why.
but BSD supports it, so does some userland SCTP.
^ permalink raw reply
* Re: kernel BUG at include/linux/skbuff.h:LINE! (2)
From: Xin Long @ 2019-08-19 14:44 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, davem, LKML, linux-sctp, Marcelo Ricardo Leitner,
network dev, Neil Horman, syzkaller-bugs, Vlad Yasevich
In-Reply-To: <CACT4Y+aNTHtbw1upruHtfrLZnUyKkZHU5_3fndmVV6D_zzJJbQ@mail.gmail.com>
On Sun, Aug 18, 2019 at 10:13 PM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Sun, Aug 18, 2019 at 7:07 AM Xin Long <lucien.xin@gmail.com> wrote:
> >
> > On Sat, Aug 17, 2019 at 2:38 AM syzbot
> > <syzbot+eb349eeee854e389c36d@syzkaller.appspotmail.com> wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit: 459c5fb4 Merge branch 'mscc-PTP-support'
> > > git tree: net-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=13f2d33c600000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=d4cf1ffb87d590d7
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=eb349eeee854e389c36d
> > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=111849e2600000
> > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1442c25a600000
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+eb349eeee854e389c36d@syzkaller.appspotmail.com
> > >
> > > ------------[ cut here ]------------
> > > kernel BUG at include/linux/skbuff.h:2225!
> > > invalid opcode: 0000 [#1] PREEMPT SMP KASAN
> > > CPU: 0 PID: 9030 Comm: syz-executor649 Not tainted 5.3.0-rc3+ #134
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > Google 01/01/2011
> > > RIP: 0010:__skb_pull include/linux/skbuff.h:2225 [inline]
> > > RIP: 0010:__skb_pull include/linux/skbuff.h:2222 [inline]
> > > RIP: 0010:skb_pull_inline include/linux/skbuff.h:2231 [inline]
> > > RIP: 0010:skb_pull+0xea/0x110 net/core/skbuff.c:1902
> > > Code: 9d c8 00 00 00 49 89 dc 49 89 9d c8 00 00 00 e8 9c e5 dd fb 4c 89 e0
> > > 5b 41 5c 41 5d 41 5e 5d c3 45 31 e4 eb ea e8 86 e5 dd fb <0f> 0b e8 df 13
> > > 18 fc e9 44 ff ff ff e8 d5 13 18 fc eb 8a e8 ee 13
> > > RSP: 0018:ffff88808ac96e10 EFLAGS: 00010293
> > > RAX: ffff88809c546000 RBX: 0000000000000004 RCX: ffffffff8594a3a6
> > > RDX: 0000000000000000 RSI: ffffffff8594a3fa RDI: 0000000000000004
> > > RBP: ffff88808ac96e30 R08: ffff88809c546000 R09: fffffbfff14a8f4f
> > > R10: fffffbfff14a8f4e R11: ffffffff8a547a77 R12: 0000000095e28bcc
> > > R13: ffff88808ac97478 R14: 00000000ffff8880 R15: ffff88808ac97478
> > > FS: 0000555556549880(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
> > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > CR2: 0000000020000100 CR3: 0000000089c3c000 CR4: 00000000001406f0
> > > Call Trace:
> > > sctp_inq_pop+0x2f1/0xd80 net/sctp/inqueue.c:202
> > > sctp_endpoint_bh_rcv+0x184/0x8d0 net/sctp/endpointola.c:385
> > > sctp_inq_push+0x1e4/0x280 net/sctp/inqueue.c:80
> > > sctp_rcv+0x2807/0x3590 net/sctp/input.c:256
> > > sctp6_rcv+0x17/0x30 net/sctp/ipv6.c:1049
> > > ip6_protocol_deliver_rcu+0x2fe/0x1660 net/ipv6/ip6_input.c:397
> > > ip6_input_finish+0x84/0x170 net/ipv6/ip6_input.c:438
> > > NF_HOOK include/linux/netfilter.h:305 [inline]
> > > NF_HOOK include/linux/netfilter.h:299 [inline]
> > > ip6_input+0xe4/0x3f0 net/ipv6/ip6_input.c:447
> > > dst_input include/net/dst.h:442 [inline]
> > > ip6_sublist_rcv_finish+0x98/0x1e0 net/ipv6/ip6_input.c:84
> > Looks skb_list_del_init() should be called in ip6_sublist_rcv_finish,
> > as does in ip_sublist_rcv_finish().
>
> This was recently introduced, right? Only in net-next and linux-next.
> Otherwise, is it a remote DoS? If so and if it's present in any
> releases, may need a CVE.
I need to reproduce and confirm it, will let you know.
^ permalink raw reply
* Re: [PATCH net-next 4/8] sctp: add SCTP_ASCONF_SUPPORTED sockopt
From: Marcelo Ricardo Leitner @ 2019-08-19 14:46 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, Neil Horman, davem
In-Reply-To: <CADvbK_dT6p7z0YUcEKakGr-+x+a7je_jNnGHOAnVs5mxtrSN1g@mail.gmail.com>
On Mon, Aug 19, 2019 at 10:43:03PM +0800, Xin Long wrote:
> On Mon, Aug 19, 2019 at 10:30 PM Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> >
> > On Mon, Aug 19, 2019 at 10:02:46PM +0800, Xin Long wrote:
> > > SCTP_ASCONF_SUPPORTED sockopt is used to set enpoint's asconf
> > > flag. With this feature, each endpoint will have its own flag
> > > for its future asoc's asconf_capable, instead of netns asconf
> > > flag.
> >
> > Is this backed by a RFC? If yes, it should be noted in the patch
> > description.
> > Quickly searching, I found only FreeBSD references.
> RFC doesn't define this sockopt clearly, unlike prsctp and reconfig,
> not sure why.
> but BSD supports it, so does some userland SCTP.
Ok. Thanks.
^ permalink raw reply
* Re: [PATCH bpf-next v4 07/11] mlx5e: modify driver for handling offsets
From: Laatz, Kevin @ 2019-08-19 14:47 UTC (permalink / raw)
To: Maxim Mikityanskiy
Cc: netdev@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
bjorn.topel@intel.com, magnus.karlsson@intel.com,
jakub.kicinski@netronome.com, jonathan.lemon@gmail.com,
Saeed Mahameed, stephen@networkplumber.org,
bruce.richardson@intel.com, ciara.loftus@intel.com,
bpf@vger.kernel.org, intel-wired-lan@lists.osuosl.org
In-Reply-To: <390f80fc-3f8a-a9ed-6ac7-8a1a41621559@mellanox.com>
On 19/08/2019 15:36, Maxim Mikityanskiy wrote:
> On 2019-08-01 13:05, Maxim Mikityanskiy wrote:
>> On 2019-07-30 11:53, Kevin Laatz wrote:
>>> With the addition of the unaligned chunks option, we need to make sure we
>>> handle the offsets accordingly based on the mode we are currently running
>>> in. This patch modifies the driver to appropriately mask the address for
>>> each case.
>>>
>>> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
>> Please note that this patch doesn't actually add the support for the new
>> feature, because the validation checks in mlx5e_rx_get_linear_frag_sz
>> and mlx5e_validate_xsk_param need to be relaxed. Currently the frame
>> size of PAGE_SIZE is forced, and the fragment size is increased to
>> PAGE_SIZE in case of XDP (including XSK).
>>
>> After making the changes required to permit frame sizes smaller than
>> PAGE_SIZE, our Striding RQ feature will be used in a way we haven't used
>> it before, so we need to verify with the hardware team that this usage
>> is legitimate.
> After discussing it internally, we found a way to support unaligned XSK
> with Striding RQ, and the hardware is compatible with this way. I have
> performed some testing, and it looks working.
Great news! :-)
>
> Your patch only adds support for the new handle format to our driver,
> and I've made another patch that actually enables the new feature (makes
> mlx5e accept frame sizes different from PAGE_SIZE). It's currently on
> internal review.
Thanks for taking the time to prepare the patch!
>
> Please also don't forget to fix the s/_handle_/_adjust_/ typo.
I have fixed it in the next version (also currently on internal review).
Regards,
Kevin
>
>>> ---
>>> v3:
>>> - Use new helper function to handle offset
>>>
>>> v4:
>>> - fixed headroom addition to handle. Using xsk_umem_adjust_headroom()
>>> now.
>>> ---
>>> drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 8 ++++++--
>>> drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c | 3 ++-
>>> 2 files changed, 8 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
>>> b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
>>> index b0b982cf69bb..d5245893d2c8 100644
>>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
>>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
>>> @@ -122,6 +122,7 @@ bool mlx5e_xdp_handle(struct mlx5e_rq *rq, struct
>>> mlx5e_dma_info *di,
>>> void *va, u16 *rx_headroom, u32 *len, bool xsk)
>>> {
>>> struct bpf_prog *prog = READ_ONCE(rq->xdp_prog);
>>> + struct xdp_umem *umem = rq->umem;
>>> struct xdp_buff xdp;
>>> u32 act;
>>> int err;
>>> @@ -138,8 +139,11 @@ bool mlx5e_xdp_handle(struct mlx5e_rq *rq, struct
>>> mlx5e_dma_info *di,
>>> xdp.rxq = &rq->xdp_rxq;
>>> act = bpf_prog_run_xdp(prog, &xdp);
>>> - if (xsk)
>>> - xdp.handle += xdp.data - xdp.data_hard_start;
>>> + if (xsk) {
>>> + u64 off = xdp.data - xdp.data_hard_start;
>>> +
>>> + xdp.handle = xsk_umem_handle_offset(umem, xdp.handle, off);
>>> + }
>>> switch (act) {
>>> case XDP_PASS:
>>> *rx_headroom = xdp.data - xdp.data_hard_start;
>>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c
>>> b/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c
>>> index 6a55573ec8f2..7c49a66d28c9 100644
>>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c
>>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/rx.c
>>> @@ -24,7 +24,8 @@ int mlx5e_xsk_page_alloc_umem(struct mlx5e_rq *rq,
>>> if (!xsk_umem_peek_addr_rq(umem, &handle))
>>> return -ENOMEM;
>>> - dma_info->xsk.handle = handle + rq->buff.umem_headroom;
>>> + dma_info->xsk.handle = xsk_umem_adjust_offset(umem, handle,
>>> + rq->buff.umem_headroom);
>>> dma_info->xsk.data = xdp_umem_get_data(umem, dma_info->xsk.handle);
>>> /* No need to add headroom to the DMA address. In striding RQ
>>> case, we
>>>
^ permalink raw reply
* Re: [PATCH 00/11] kbuild: clean-ups and improvement of single targets
From: Masahiro Yamada @ 2019-08-19 14:52 UTC (permalink / raw)
To: Linux Kbuild mailing list
Cc: Christoph Hellwig, Sam Ravnborg, Alexei Starovoitov,
Boris Pismenny, Daniel Borkmann, David S. Miller, Igor Russkikh,
Jakub Kicinski, Leon Romanovsky, Martin KaFai Lau, Michal Marek,
Saeed Mahameed, Song Liu, Yonghong Song, bpf,
Linux Kernel Mailing List, linux-rdma, Networking, oss-drivers
In-Reply-To: <20190810155307.29322-1-yamada.masahiro@socionext.com>
On Sun, Aug 11, 2019 at 12:55 AM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
>
> 01/11-09/11 are trivial clean-ups.
>
> 10/11 makes the single targets work more correctly.
>
> 11/11 cleans up Makefiles that have been added
> to work aroud the single target issues.
>
>
>
> Masahiro Yamada (11):
> kbuild: move the Module.symvers check for external module build
> kbuild: refactor part-of-module more
> kbuild: fix modkern_aflags implementation
> kbuild: remove 'make /' support
> kbuild: remove meaningless 'targets' in ./Kbuild
> kbuild: do not descend to ./Kbuild when cleaning
> kbuild: unset variables in top Makefile instead of setting 0
> kbuild: unify vmlinux-dirs and module-dirs rules
> kbuild: unify clean-dirs rule for in-kernel and external module
> kbuild: make single targets work more correctly
> treewide: remove dummy Makefiles for single targets
Patch 01-09 applied.
10-11 have been superseded.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH v2] kbuild: re-implement detection of CONFIG options leaked to user-space
From: Masahiro Yamada @ 2019-08-19 14:55 UTC (permalink / raw)
To: Linux Kbuild mailing list
Cc: Christoph Hellwig, Arnd Bergmann, Sam Ravnborg,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, bpf, Linux Kernel Mailing List, Networking
In-Reply-To: <20190810170135.31183-1-yamada.masahiro@socionext.com>
On Sun, Aug 11, 2019 at 2:03 AM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> scripts/headers_check.pl can detect references to CONFIG options in
> exported headers, but it has been disabled for more than a decade.
>
> Reverting commit 7e3fa5614117 ("kbuild: drop check for CONFIG_ in
> headers_check") would emit the following warnings for headers_check
> on x86:
>
> usr/include/mtd/ubi-user.h:283: leaks CONFIG_MTD_UBI_BEB_LIMIT to userspace where it is not valid
> usr/include/linux/cm4000_cs.h:26: leaks CONFIG_COMPAT to userspace where it is not valid
> usr/include/linux/pkt_cls.h:301: leaks CONFIG_NET_CLS_ACT to userspace where it is not valid
> usr/include/linux/videodev2.h:2465: leaks CONFIG_VIDEO_ADV_DEBUG to userspace where it is not valid
> usr/include/linux/bpf.h:249: leaks CONFIG_EFFICIENT_UNALIGNED_ACCESS to userspace where it is not valid
> usr/include/linux/bpf.h:819: leaks CONFIG_CGROUP_NET_CLASSID to userspace where it is not valid
> usr/include/linux/bpf.h:1011: leaks CONFIG_IP_ROUTE_CLASSID to userspace where it is not valid
> usr/include/linux/bpf.h:1742: leaks CONFIG_BPF_KPROBE_OVERRIDE to userspace where it is not valid
> usr/include/linux/bpf.h:1747: leaks CONFIG_FUNCTION_ERROR_INJECTION to userspace where it is not valid
> usr/include/linux/bpf.h:1936: leaks CONFIG_XFRM to userspace where it is not valid
> usr/include/linux/bpf.h:2184: leaks CONFIG_BPF_LIRC_MODE2 to userspace where it is not valid
> usr/include/linux/bpf.h:2210: leaks CONFIG_BPF_LIRC_MODE2 to userspace where it is not valid
> usr/include/linux/bpf.h:2227: leaks CONFIG_SOCK_CGROUP_DATA to userspace where it is not valid
> usr/include/linux/bpf.h:2311: leaks CONFIG_NET to userspace where it is not valid
> usr/include/linux/bpf.h:2348: leaks CONFIG_NET to userspace where it is not valid
> usr/include/linux/bpf.h:2422: leaks CONFIG_BPF_LIRC_MODE2 to userspace where it is not valid
> usr/include/linux/bpf.h:2528: leaks CONFIG_NET to userspace where it is not valid
> usr/include/linux/pktcdvd.h:37: leaks CONFIG_CDROM_PKTCDVD_WCACHE to userspace where it is not valid
> usr/include/linux/hw_breakpoint.h:27: leaks CONFIG_HAVE_MIXED_BREAKPOINTS_REGS to userspace where it is not valid
> usr/include/linux/raw.h:17: leaks CONFIG_MAX_RAW_DEVS to userspace where it is not valid
> usr/include/linux/elfcore.h:62: leaks CONFIG_BINFMT_ELF_FDPIC to userspace where it is not valid
> usr/include/linux/eventpoll.h:82: leaks CONFIG_PM_SLEEP to userspace where it is not valid
> usr/include/linux/atmdev.h:104: leaks CONFIG_COMPAT to userspace where it is not valid
> usr/include/asm-generic/unistd.h:651: leaks CONFIG_MMU to userspace where it is not valid
> usr/include/asm-generic/bitsperlong.h:9: leaks CONFIG_64BIT to userspace where it is not valid
> usr/include/asm-generic/fcntl.h:119: leaks CONFIG_64BIT to userspace where it is not valid
> usr/include/asm/auxvec.h:14: leaks CONFIG_IA32_EMULATION to userspace where it is not valid
> usr/include/asm/e820.h:14: leaks CONFIG_NODES_SHIFT to userspace where it is not valid
> usr/include/asm/e820.h:39: leaks CONFIG_X86_PMEM_LEGACY to userspace where it is not valid
> usr/include/asm/e820.h:49: leaks CONFIG_INTEL_TXT to userspace where it is not valid
> usr/include/asm/mman.h:7: leaks CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS to userspace where it is not valid
>
> Most of these are false positives because scripts/headers_check.pl
> parses comment lines.
>
> It is also false negative. arch/x86/include/uapi/asm/auxvec.h contains
> CONFIG_IA32_EMULATION and CONFIG_X86_64, but the only former is reported.
>
> It would be possible to fix scripts/headers_check.pl, of course.
> However, we already have some duplicated checks between headers_check
> and CONFIG_UAPI_HEADER_TEST. At this moment of time, there are still
> dozens of headers excluded from the header test (usr/include/Makefile),
> but we might be able to remove headers_check eventually.
>
> I re-implemented it in scripts/headers_install.sh by using sed because
> the most of code in scripts/headers_install.sh is written in sed.
>
> This patch works like this:
>
> [1] Run scripts/unifdef first because we need to drop the code
> surrounded by #ifdef __KERNEL__ ... #endif
>
> [2] Remove all C style comments. The sed code is somewhat complicated
> since we need to deal with both single and multi line comments.
>
> Precisely speaking, a comment block is replaced with a space just
> in case.
>
> CONFIG_FOO/* this is a comment */CONFIG_BAR
>
> should be converted into:
>
> CONFIG_FOO CONFIG_BAR
>
> instead of:
>
> CONFIG_FOOCONFIG_BAR
>
> [3] Match CONFIG_... pattern. It correctly matches to all CONFIG
> options that appear in a single line.
>
> After this commit, this would detect the following warnings, all of
> which are real ones.
>
> warning: include/uapi/linux/pktcdvd.h: leak CONFIG_CDROM_PKTCDVD_WCACHE to user-space
> warning: include/uapi/linux/hw_breakpoint.h: leak CONFIG_HAVE_MIXED_BREAKPOINTS_REGS to user-space
> warning: include/uapi/linux/raw.h: leak CONFIG_MAX_RAW_DEVS to user-space
> warning: include/uapi/linux/elfcore.h: leak CONFIG_BINFMT_ELF_FDPIC to user-space
> warning: include/uapi/linux/eventpoll.h: leak CONFIG_PM_SLEEP to user-space
> warning: include/uapi/linux/atmdev.h: leak CONFIG_COMPAT to user-space
> warning: include/uapi/asm-generic/fcntl.h: leak CONFIG_64BIT to user-space
> warning: arch/x86/include/uapi/asm/auxvec.h: leak CONFIG_IA32_EMULATION to user-space
> warning: arch/x86/include/uapi/asm/auxvec.h: leak CONFIG_X86_64 to user-space
> warning: arch/x86/include/uapi/asm/mman.h: leak CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS to user-space
>
> However, it is not nice to show them right now. I created a list of
> existing leakages. They are not warned, but a new leakage will be
> blocked by the 0-day bot.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
I slightly fixed up this to avoid warnings for O= building,
and applied.
> Changes in v2:
> - Add a whitelist. The CONFIG leakages in this list are not warned.
> This patch can be applied now. A new leakage will be blocked.
> - Shorten the sed code slightly
>
> scripts/headers_install.sh | 63 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
>
> diff --git a/scripts/headers_install.sh b/scripts/headers_install.sh
> index bbaf29386995..770d239cc11e 100755
> --- a/scripts/headers_install.sh
> +++ b/scripts/headers_install.sh
> @@ -41,5 +41,68 @@ sed -E -e '
> scripts/unifdef -U__KERNEL__ -D__EXPORTED_HEADERS__ $TMPFILE > $OUTFILE
> [ $? -gt 1 ] && exit 1
>
> +# Remove /* ... */ style comments, and find CONFIG_ references in code
> +configs=$(sed -e '
> +:comment
> + s:/\*[^*][^*]*:/*:
> + s:/\*\*\**\([^/]\):/*\1:
> + t comment
> + s:/\*\*/: :
> + t comment
> + /\/\*/! b check
> + N
> + b comment
> +:print
> + P
> + D
> +:check
> + s:^\(CONFIG_[[:alnum:]_]*\):\1\n:
> + t print
> + s:^[[:alnum:]_][[:alnum:]_]*::
> + s:^[^[:alnum:]_][^[:alnum:]_]*::
> + t check
> + d
> +' $OUTFILE)
> +
> +# The entries in the following list are not warned.
> +# Please do not add a new entry. This list is only for existing ones.
> +# The list will be reduced gradually, and deleted eventually. (hopefully)
> +#
> +# The format is <file-name>:<CONFIG-option> in each line.
> +config_leak_no_warn="
> +arch/alpha/include/uapi/asm/setup.h:CONFIG_ALPHA_LEGACY_START_ADDRESS
> +arch/arc/include/uapi/asm/page.h:CONFIG_ARC_PAGE_SIZE_16K
> +arch/arc/include/uapi/asm/page.h:CONFIG_ARC_PAGE_SIZE_4K
> +arch/arc/include/uapi/asm/swab.h:CONFIG_ARC_HAS_SWAPE
> +arch/arm/include/uapi/asm/ptrace.h:CONFIG_CPU_ENDIAN_BE8
> +arch/hexagon/include/uapi/asm/ptrace.h:CONFIG_HEXAGON_ARCH_VERSION
> +arch/hexagon/include/uapi/asm/user.h:CONFIG_HEXAGON_ARCH_VERSION
> +arch/ia64/include/uapi/asm/cmpxchg.h:CONFIG_IA64_DEBUG_CMPXCHG
> +arch/m68k/include/uapi/asm/ptrace.h:CONFIG_COLDFIRE
> +arch/nios2/include/uapi/asm/swab.h:CONFIG_NIOS2_CI_SWAB_NO
> +arch/nios2/include/uapi/asm/swab.h:CONFIG_NIOS2_CI_SWAB_SUPPORT
> +arch/sh/include/uapi/asm/ptrace.h:CONFIG_CPU_SH5
> +arch/sh/include/uapi/asm/sigcontext.h:CONFIG_CPU_SH5
> +arch/sh/include/uapi/asm/stat.h:CONFIG_CPU_SH5
> +arch/x86/include/uapi/asm/auxvec.h:CONFIG_IA32_EMULATION
> +arch/x86/include/uapi/asm/auxvec.h:CONFIG_X86_64
> +arch/x86/include/uapi/asm/mman.h:CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
> +include/uapi/asm-generic/fcntl.h:CONFIG_64BIT
> +include/uapi/linux/atmdev.h:CONFIG_COMPAT
> +include/uapi/linux/elfcore.h:CONFIG_BINFMT_ELF_FDPIC
> +include/uapi/linux/eventpoll.h:CONFIG_PM_SLEEP
> +include/uapi/linux/hw_breakpoint.h:CONFIG_HAVE_MIXED_BREAKPOINTS_REGS
> +include/uapi/linux/pktcdvd.h:CONFIG_CDROM_PKTCDVD_WCACHE
> +include/uapi/linux/raw.h:CONFIG_MAX_RAW_DEVS
> +"
> +
> +for c in $configs
> +do
> + if echo "$config_leak_no_warn" | grep -q "^$INFILE:$c$"; then
> + continue
> + fi
> + echo "warning: $INFILE: leak $c to user-space" >&2
> +done
> +
> rm -f $TMPFILE
> trap - EXIT
> --
> 2.17.1
>
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH net-next 4/8] sctp: add SCTP_ASCONF_SUPPORTED sockopt
From: Marcelo Ricardo Leitner @ 2019-08-19 14:58 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, Neil Horman, davem
In-Reply-To: <f4fbfa28a7fd2ed85f0fc66ddcbd4249e6e7b487.1566223325.git.lucien.xin@gmail.com>
On Mon, Aug 19, 2019 at 10:02:46PM +0800, Xin Long wrote:
> +static int sctp_setsockopt_asconf_supported(struct sock *sk,
> + char __user *optval,
> + unsigned int optlen)
> +{
> + struct sctp_assoc_value params;
> + struct sctp_association *asoc;
> + struct sctp_endpoint *ep;
> + int retval = -EINVAL;
> +
> + if (optlen != sizeof(params))
> + goto out;
> +
> + if (copy_from_user(¶ms, optval, optlen)) {
> + retval = -EFAULT;
> + goto out;
> + }
> +
> + asoc = sctp_id2assoc(sk, params.assoc_id);
> + if (!asoc && params.assoc_id != SCTP_FUTURE_ASSOC &&
> + sctp_style(sk, UDP))
> + goto out;
> +
> + ep = sctp_sk(sk)->ep;
> + ep->asconf_enable = !!params.assoc_value;
Considering this will be negotiated on handshake, shouldn't it deny
changes to Established asocs? (Same for Auth)
> +
> + if (ep->asconf_enable && ep->auth_enable) {
> + sctp_auth_ep_add_chunkid(ep, SCTP_CID_ASCONF);
> + sctp_auth_ep_add_chunkid(ep, SCTP_CID_ASCONF_ACK);
> + }
> +
> + retval = 0;
> +
> +out:
> + return retval;
> +}
^ permalink raw reply
* RE: [PATCH net-next, 3/6] net/mlx5: Add wrappers for HyperV PCIe operations
From: Haiyang Zhang @ 2019-08-19 15:04 UTC (permalink / raw)
To: Eran Ben Elisha, Mark Bloch, sashal@kernel.org,
davem@davemloft.net, Saeed Mahameed, leon@kernel.org,
lorenzo.pieralisi@arm.com, bhelgaas@google.com,
linux-pci@vger.kernel.org, linux-hyperv@vger.kernel.org,
netdev@vger.kernel.org
Cc: KY Srinivasan, Stephen Hemminger, linux-kernel@vger.kernel.org
In-Reply-To: <f81d2a27-cedc-40ca-daf6-8f3053cc2d38@mellanox.com>
> -----Original Message-----
> From: Eran Ben Elisha <eranbe@mellanox.com>
> Sent: Thursday, August 15, 2019 7:35 AM
> To: Mark Bloch <markb@mellanox.com>; Haiyang Zhang
> <haiyangz@microsoft.com>; sashal@kernel.org; davem@davemloft.net;
> Saeed Mahameed <saeedm@mellanox.com>; leon@kernel.org;
> lorenzo.pieralisi@arm.com; bhelgaas@google.com; linux-
> pci@vger.kernel.org; linux-hyperv@vger.kernel.org; netdev@vger.kernel.org
> Cc: KY Srinivasan <kys@microsoft.com>; Stephen Hemminger
> <sthemmin@microsoft.com>; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net-next, 3/6] net/mlx5: Add wrappers for HyperV PCIe
> operations
>
>
>
> On 8/14/2019 11:41 PM, Mark Bloch wrote:
> >
> >
> > On 8/14/19 12:08 PM, Haiyang Zhang wrote:
> >> From: Eran Ben Elisha <eranbe@mellanox.com>
> >>
> >> Add wrapper functions for HyperV PCIe read / write /
> >> block_invalidate_register operations. This will be used as an
> >> infrastructure in the downstream patch for software communication.
> >>
> >> This will be enabled by default if CONFIG_PCI_HYPERV_MINI is set.
> >>
> >> Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
> >> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> >> ---
> >> drivers/net/ethernet/mellanox/mlx5/core/Makefile | 1 +
> >> drivers/net/ethernet/mellanox/mlx5/core/lib/hv.c | 64
> ++++++++++++++++++++++++
> >> drivers/net/ethernet/mellanox/mlx5/core/lib/hv.h | 22 ++++++++
> >> 3 files changed, 87 insertions(+)
> >> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/hv.c
> >> create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/hv.h
> >>
> >> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Makefile
> b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
> >> index 8b7edaa..a8950b1 100644
> >> --- a/drivers/net/ethernet/mellanox/mlx5/core/Makefile
> >> +++ b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
> >> @@ -45,6 +45,7 @@ mlx5_core-$(CONFIG_MLX5_ESWITCH) +=
> eswitch.o eswitch_offloads.o eswitch_offlo
> >> mlx5_core-$(CONFIG_MLX5_MPFS) += lib/mpfs.o
> >> mlx5_core-$(CONFIG_VXLAN) += lib/vxlan.o
> >> mlx5_core-$(CONFIG_PTP_1588_CLOCK) += lib/clock.o
> >> +mlx5_core-$(CONFIG_PCI_HYPERV_MINI) += lib/hv.o
> >>
> >> #
> >> # Ipoib netdev
> >> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/hv.c
> b/drivers/net/ethernet/mellanox/mlx5/core/lib/hv.c
> >> new file mode 100644
> >> index 0000000..cf08d02
> >> --- /dev/null
> >> +++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/hv.c
> >> @@ -0,0 +1,64 @@
> >> +// SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
> >> +// Copyright (c) 2018 Mellanox Technologies
> >> +
> >> +#include <linux/hyperv.h>
> >> +#include "mlx5_core.h"
> >> +#include "lib/hv.h"
> >> +
> >> +static int mlx5_hv_config_common(struct mlx5_core_dev *dev, void
> *buf, int len,
> >> + int offset, bool read)
> >> +{
> >> + int rc = -EOPNOTSUPP;
> >> + int bytes_returned;
> >> + int block_id;
> >> +
> >> + if (offset % HV_CONFIG_BLOCK_SIZE_MAX || len %
> HV_CONFIG_BLOCK_SIZE_MAX)
> >> + return -EINVAL;
> >> +
> >> + block_id = offset / HV_CONFIG_BLOCK_SIZE_MAX;
> >> +
> >> + rc = read ?
> >> + hyperv_read_cfg_blk(dev->pdev, buf,
> >> + HV_CONFIG_BLOCK_SIZE_MAX, block_id,
> >> + &bytes_returned) :
> >> + hyperv_write_cfg_blk(dev->pdev, buf,
> >> + HV_CONFIG_BLOCK_SIZE_MAX, block_id);
> >> +
> >> + /* Make sure len bytes were read successfully */
> >> + if (read)
> >> + rc |= !(len == bytes_returned);
> >> +
> >> + if (rc) {
> >> + mlx5_core_err(dev, "Failed to %s hv config, err = %d, len
> = %d, offset = %d\n",
> >> + read ? "read" : "write", rc, len,
> >> + offset);
> >> + return rc;
> >> + }
> >> +
> >> + return 0;
> >> +}
> >
> > This seems out of place why not expose this function as part of hyperv and
> mlx5
> > will just pass the pdev.
> >
> The HV driver works with block chunks. I found it less convenience to do
> so directly, so I add a small wrapper for mlx5 core.
>
> Haiyangz,
> Do you see a reason to export this callback style from the HYPERV level
> instead?
I don’t think the wrapper has to be in the hv interface.
One function for read, another for write, are pretty straight forward.
Users (other drivers) may use or wrap them in the way they like to.
Thanks,
- Haiyang
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: mdio: add support for passing a PTP system timestamp to the mii_bus driver
From: Andrew Lunn @ 2019-08-19 15:14 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Hubert Feurstein, netdev, lkml, Richard Cochran, Florian Fainelli,
Heiner Kallweit, David S. Miller
In-Reply-To: <CA+h21hpe1JRBAGX5GwAZopuG9D2oe-+G+7Y026vBLPhhX--YNQ@mail.gmail.com>
> > > How expensive is ptp_read_system_prets()? My original suggestion was
> > > to unconditionally call it here, and then let the driver overwrite it
> > > if it supports finer grained time stamping. MDIO is slow, so as long
> > > as ptp_read_system_prets() is not too expensive, i prefer KISS.
> > >
> > > Andrew
> >
> > While that works for the pre_ts, it doesn't work for the post_ts (the
> > MDIO bus core will unconditionally overwrite the system timestamp from
> > the driver).
> > Unless you're suggesting to keep the pre_ts unconditional and the
> > post_ts under the "if" condition, which is a bit odd.
> > According to my tests with a scope (measuring the width between SPI
> > transfers with and without the ptp_read_system_*ts calls), two calls
> > to ktime_get_real_ts64 amount to around 750 ns on a 1200 MHz Cortex A7
> > core, or around 90 clock cycles.
>
> 900 clock cycles, my bad.
That is quite a lot. I was just expecting it to read a free running
clock and maybe do some unit conversions. 900 cycles suggests it is
doing a lot more.
So please keep with the idea of the bus driver indicating if it
supports the time stamping. But please make it a generic bus->flags,
and bit 0 indicating time stamping. At some point in the future, it
would be useful to indicate if the bus supports c45, which would be
another use of flags.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: dsa: mv88e6xxx: extend PTP gettime function to read system clock
From: Vivien Didelot @ 2019-08-19 15:16 UTC (permalink / raw)
To: Andrew Lunn
Cc: Hubert Feurstein, netdev, linux-kernel, Richard Cochran,
Florian Fainelli, Vladimir Oltean, David S. Miller
In-Reply-To: <20190819132733.GE8981@lunn.ch>
On Mon, 19 Aug 2019 15:27:33 +0200, Andrew Lunn <andrew@lunn.ch> wrote:
> > @@ -45,7 +45,8 @@ static int mv88e6xxx_smi_direct_write(struct mv88e6xxx_chip *chip,
> > {
> > int ret;
> >
> > - ret = mdiobus_write_nested(chip->bus, dev, reg, data);
> > + ret = mdiobus_write_sts_nested(chip->bus, dev, reg, data,
> > + chip->ptp_sts);
> > if (ret < 0)
> > return ret;
> >
>
> Please also make a similar change to mv88e6xxx_smi_indirect_write().
> The last write in that function should be timestamped.
>
> Vivien, please could you think about these changes with respect to
> RMU. We probably want to skip the RMU in this case, so we get slow but
> uniform jitter, vs fast and unpredictable jitter from using the RMU.
The RMU will have its own mv88e6xxx_bus_ops.
^ permalink raw reply
* Re: [PATCH net-next 4/8] sctp: add SCTP_ASCONF_SUPPORTED sockopt
From: Xin Long @ 2019-08-19 15:19 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: network dev, linux-sctp, Neil Horman, davem
In-Reply-To: <20190819145843.GE2870@localhost.localdomain>
On Mon, Aug 19, 2019 at 10:58 PM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> On Mon, Aug 19, 2019 at 10:02:46PM +0800, Xin Long wrote:
> > +static int sctp_setsockopt_asconf_supported(struct sock *sk,
> > + char __user *optval,
> > + unsigned int optlen)
> > +{
> > + struct sctp_assoc_value params;
> > + struct sctp_association *asoc;
> > + struct sctp_endpoint *ep;
> > + int retval = -EINVAL;
> > +
> > + if (optlen != sizeof(params))
> > + goto out;
> > +
> > + if (copy_from_user(¶ms, optval, optlen)) {
> > + retval = -EFAULT;
> > + goto out;
> > + }
> > +
> > + asoc = sctp_id2assoc(sk, params.assoc_id);
> > + if (!asoc && params.assoc_id != SCTP_FUTURE_ASSOC &&
> > + sctp_style(sk, UDP))
> > + goto out;
> > +
> > + ep = sctp_sk(sk)->ep;
> > + ep->asconf_enable = !!params.assoc_value;
>
> Considering this will be negotiated on handshake, shouldn't it deny
> changes to Established asocs? (Same for Auth)
ep->asconf_enable is for 'furture' asocs, and furture
asoc->peer.asconf_capable will be negotiated according to
peer ep->asconf_enable (EXT chunk) and local ep->asconf_enable.
It won't affect the 'current'/Established asocs, and the Established
asocs have asoc->peer.asconf_capable, which can't be changed by sockopt.
>
> > +
> > + if (ep->asconf_enable && ep->auth_enable) {
> > + sctp_auth_ep_add_chunkid(ep, SCTP_CID_ASCONF);
> > + sctp_auth_ep_add_chunkid(ep, SCTP_CID_ASCONF_ACK);
> > + }
> > +
> > + retval = 0;
> > +
> > +out:
> > + return retval;
> > +}
^ permalink raw reply
* [PATCH v2 net-next 0/1] Add BASE-T1 PHY support
From: Christian Herber @ 2019-08-19 15:19 UTC (permalink / raw)
To: andrew@lunn.ch, f.fainelli@gmail.com, hkallweit1@gmail.com,
davem@davemloft.net
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Christian Herber
v1 patchset can be found here: https://lkml.org/lkml/2019/8/15/626
This patch adds basic support for BASE-T1 PHYs in the framework.
BASE-T1 PHYs main area of application are automotive and industrial.
BASE-T1 is standardized in IEEE 802.3, namely
- IEEE 802.3bw: 100BASE-T1
- IEEE 802.3bp 1000BASE-T1
- IEEE 802.3cg: 10BASE-T1L and 10BASE-T1S
There are no products which contain BASE-T1 and consumer type PHYs like
1000BASE-T. However, devices exist which combine 100BASE-T1 and
1000BASE-T1 PHYs with auto-negotiation.
The intention of this patch is to make use of the existing Clause 45
functions. BASE-T1 adds some additional registers e.g. for aneg control,
which follow a similar register layout as the existing devices. The
bits which are used in BASE-T1 specific registers are the same as in basic
registers, thus the existing functions can be resued, with get_aneg_ctrl()
selecting the correct register address.
The current version of ethtool has been prepared for 100/1000BASE-T1 and
works with this patch. 10BASE-T1 needs to be added to ethtool. The fixed-
speed and auto-negotiation functions are extended for 100/1000BASE-T1.
For 10BASE-T1S/L, only discovery of ability is added with this patchset.
Christian Herber (1):
net: phy: Added BASE-T1 PHY support to PHY Subsystem
drivers/net/phy/phy-c45.c | 106 +++++++++++++++++++++++++++++++----
drivers/net/phy/phy-core.c | 4 +-
drivers/net/phy/phy_device.c | 12 ++++
include/linux/phy.h | 1 +
include/uapi/linux/ethtool.h | 2 +
include/uapi/linux/mdio.h | 21 +++++++
6 files changed, 135 insertions(+), 11 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH v2 net-next 1/1] net: phy: Added BASE-T1 PHY support to PHY Subsystem
From: Christian Herber @ 2019-08-19 15:19 UTC (permalink / raw)
To: andrew@lunn.ch, f.fainelli@gmail.com, hkallweit1@gmail.com,
davem@davemloft.net
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Christian Herber
In-Reply-To: <20190819151940.27756-1-christian.herber@nxp.com>
BASE-T1 is a category of Ethernet PHYs.
They use a single copper pair for transmission.
This patch add basic support for this category of PHYs.
It coveres the discovery of abilities and basic configuration.
It includes setting fixed speed and enabling auto-negotiation.
BASE-T1 devices should always Clause-45 managed.
Therefore, this patch extends phy-c45.c.
While for some functions like auto-neogtiation different registers are
used, the layout of these registers is the same for the used fields.
Thus, much of the logic of basic Clause-45 devices can be reused.
Signed-off-by: Christian Herber <christian.herber@nxp.com>
---
Changes in v2:
- Added is_baset1_capable property to phydev
- Reordered functions to remove forward declarations
---
drivers/net/phy/phy-c45.c | 106 +++++++++++++++++++++++++++++++----
drivers/net/phy/phy-core.c | 4 +-
drivers/net/phy/phy_device.c | 12 ++++
include/linux/phy.h | 1 +
include/uapi/linux/ethtool.h | 2 +
include/uapi/linux/mdio.h | 21 +++++++
6 files changed, 135 insertions(+), 11 deletions(-)
diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
index b9d4145781ca..d673e1413fe6 100644
--- a/drivers/net/phy/phy-c45.c
+++ b/drivers/net/phy/phy-c45.c
@@ -8,13 +8,16 @@
#include <linux/mii.h>
#include <linux/phy.h>
+static u32 get_aneg_ctrl(struct phy_device *phydev);
+static u32 get_aneg_stat(struct phy_device *phydev);
+
/**
* genphy_c45_setup_forced - configures a forced speed
* @phydev: target phy_device struct
*/
int genphy_c45_pma_setup_forced(struct phy_device *phydev)
{
- int ctrl1, ctrl2, ret;
+ int ctrl1, ctrl2, base_t1_ctrl = 0, ret;
/* Half duplex is not supported */
if (phydev->duplex != DUPLEX_FULL)
@@ -28,6 +31,16 @@ int genphy_c45_pma_setup_forced(struct phy_device *phydev)
if (ctrl2 < 0)
return ctrl2;
+ if (phydev->is_baset1_capable) {
+ base_t1_ctrl = phy_read_mmd(phydev,
+ MDIO_MMD_PMAPMD,
+ MDIO_PMA_BASET1CTRL);
+ if (base_t1_ctrl < 0)
+ return base_t1_ctrl;
+
+ base_t1_ctrl &= ~(MDIO_PMA_BASET1CTRL_TYPE);
+ }
+
ctrl1 &= ~MDIO_CTRL1_SPEEDSEL;
/*
* PMA/PMD type selection is 1.7.5:0 not 1.7.3:0. See 45.2.1.6.1
@@ -41,12 +54,21 @@ int genphy_c45_pma_setup_forced(struct phy_device *phydev)
break;
case SPEED_100:
ctrl1 |= MDIO_PMA_CTRL1_SPEED100;
- ctrl2 |= MDIO_PMA_CTRL2_100BTX;
+ if (phydev->is_baset1_capable) {
+ ctrl2 |= MDIO_PMA_CTRL2_BT1;
+ base_t1_ctrl |= MDIO_PMA_BASET1CTRL_TYPE_100BT1;
+ } else {
+ ctrl2 |= MDIO_PMA_CTRL2_100BTX;
+ }
break;
case SPEED_1000:
ctrl1 |= MDIO_PMA_CTRL1_SPEED1000;
- /* Assume 1000base-T */
- ctrl2 |= MDIO_PMA_CTRL2_1000BT;
+ if (phydev->is_baset1_capable) {
+ ctrl2 |= MDIO_PMA_CTRL2_BT1;
+ base_t1_ctrl |= MDIO_PMA_BASET1CTRL_TYPE_1000BT1;
+ } else {
+ ctrl2 |= MDIO_PMA_CTRL2_1000BT;
+ }
break;
case SPEED_2500:
ctrl1 |= MDIO_CTRL1_SPEED2_5G;
@@ -75,10 +97,50 @@ int genphy_c45_pma_setup_forced(struct phy_device *phydev)
if (ret < 0)
return ret;
+ if (phydev->is_baset1_capable) {
+ ret = phy_write_mmd(phydev,
+ MDIO_MMD_PMAPMD,
+ MDIO_PMA_BASET1CTRL,
+ base_t1_ctrl);
+ if (ret < 0)
+ return ret;
+ }
return genphy_c45_an_disable_aneg(phydev);
}
EXPORT_SYMBOL_GPL(genphy_c45_pma_setup_forced);
+/**
+ * get_aneg_ctrl - Get the register address for auto-
+ * negotiation control register
+ * @phydev: target phy_device struct
+ *
+ */
+static u32 get_aneg_ctrl(struct phy_device *phydev)
+{
+ u32 ctrl = MDIO_CTRL1;
+
+ if (phydev->is_baset1_capable)
+ ctrl = MDIO_AN_BT1_CTRL;
+
+ return ctrl;
+}
+
+/**
+ * get_aneg_ctrl - Get the register address for auto-
+ * negotiation status register
+ * @phydev: target phy_device struct
+ *
+ */
+static u32 get_aneg_stat(struct phy_device *phydev)
+{
+ u32 stat = MDIO_STAT1;
+
+ if (phydev->is_baset1_capable)
+ stat = MDIO_AN_BT1_STAT;
+
+ return stat;
+}
+
/**
* genphy_c45_an_config_aneg - configure advertisement registers
* @phydev: target phy_device struct
@@ -135,8 +197,7 @@ EXPORT_SYMBOL_GPL(genphy_c45_an_config_aneg);
*/
int genphy_c45_an_disable_aneg(struct phy_device *phydev)
{
-
- return phy_clear_bits_mmd(phydev, MDIO_MMD_AN, MDIO_CTRL1,
+ return phy_clear_bits_mmd(phydev, MDIO_MMD_AN, get_aneg_ctrl(phydev),
MDIO_AN_CTRL1_ENABLE | MDIO_AN_CTRL1_RESTART);
}
EXPORT_SYMBOL_GPL(genphy_c45_an_disable_aneg);
@@ -151,7 +212,7 @@ EXPORT_SYMBOL_GPL(genphy_c45_an_disable_aneg);
*/
int genphy_c45_restart_aneg(struct phy_device *phydev)
{
- return phy_set_bits_mmd(phydev, MDIO_MMD_AN, MDIO_CTRL1,
+ return phy_set_bits_mmd(phydev, MDIO_MMD_AN, get_aneg_ctrl(phydev),
MDIO_AN_CTRL1_ENABLE | MDIO_AN_CTRL1_RESTART);
}
EXPORT_SYMBOL_GPL(genphy_c45_restart_aneg);
@@ -171,7 +232,7 @@ int genphy_c45_check_and_restart_aneg(struct phy_device *phydev, bool restart)
if (!restart) {
/* Configure and restart aneg if it wasn't set before */
- ret = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_CTRL1);
+ ret = phy_read_mmd(phydev, MDIO_MMD_AN, get_aneg_ctrl(phydev));
if (ret < 0)
return ret;
@@ -199,7 +260,7 @@ EXPORT_SYMBOL_GPL(genphy_c45_check_and_restart_aneg);
*/
int genphy_c45_aneg_done(struct phy_device *phydev)
{
- int val = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_STAT1);
+ int val = phy_read_mmd(phydev, MDIO_MMD_AN, get_aneg_stat(phydev));
return val < 0 ? val : val & MDIO_AN_STAT1_COMPLETE ? 1 : 0;
}
@@ -385,7 +446,9 @@ EXPORT_SYMBOL_GPL(genphy_c45_read_mdix);
* PMA Extended Abilities (1.11) register, indicating 1000BASET an 10G related
* modes. If bit 1.11.14 is set, then the list is also extended with the modes
* in the 2.5G/5G PMA Extended register (1.21), indicating if 2.5GBASET and
- * 5GBASET are supported.
+ * 5GBASET are supported. If bit 1.11.11 is set, then the list is also extended
+ * with the modes in the BASE-T1 PMA Extended register (1.18), indicating if
+ * 10/100/1000BASET-1 are supported.
*/
int genphy_c45_pma_read_abilities(struct phy_device *phydev)
{
@@ -470,6 +533,29 @@ int genphy_c45_pma_read_abilities(struct phy_device *phydev)
phydev->supported,
val & MDIO_PMA_NG_EXTABLE_5GBT);
}
+
+ if (val & MDIO_PMA_EXTABLE_BASET1) {
+ val = phy_read_mmd(phydev, MDIO_MMD_PMAPMD,
+ MDIO_PMA_BASET1_EXTABLE);
+ if (val < 0)
+ return val;
+
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_100baseT1_Full_BIT,
+ phydev->supported,
+ val & MDIO_PMA_BASET1_EXTABLE_100BT1);
+
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_1000baseT1_Full_BIT,
+ phydev->supported,
+ val & MDIO_PMA_BASET1_EXTABLE_1000BT1);
+
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_10baseT1L_Full_BIT,
+ phydev->supported,
+ val & MDIO_PMA_BASET1_EXTABLE_10BT1L);
+
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_10baseT1S_Full_BIT,
+ phydev->supported,
+ val & MDIO_PMA_BASET1_EXTABLE_10BT1S);
+ }
}
return 0;
diff --git a/drivers/net/phy/phy-core.c b/drivers/net/phy/phy-core.c
index 369903d9b6ec..b50576f7709a 100644
--- a/drivers/net/phy/phy-core.c
+++ b/drivers/net/phy/phy-core.c
@@ -8,7 +8,7 @@
const char *phy_speed_to_str(int speed)
{
- BUILD_BUG_ON_MSG(__ETHTOOL_LINK_MODE_MASK_NBITS != 69,
+ BUILD_BUG_ON_MSG(__ETHTOOL_LINK_MODE_MASK_NBITS != 71,
"Enum ethtool_link_mode_bit_indices and phylib are out of sync. "
"If a speed or mode has been added please update phy_speed_to_str "
"and the PHY settings array.\n");
@@ -140,6 +140,8 @@ static const struct phy_setting settings[] = {
/* 10M */
PHY_SETTING( 10, FULL, 10baseT_Full ),
PHY_SETTING( 10, HALF, 10baseT_Half ),
+ PHY_SETTING( 10, FULL, 10baseT1L_Full ),
+ PHY_SETTING( 10, FULL, 10baseT1S_Full ),
};
#undef PHY_SETTING
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index b039632de73a..b733a78b7dd5 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -2249,6 +2249,18 @@ static int phy_probe(struct device *dev)
phydev->supported))
phydev->is_gigabit_capable = 1;
+ if (linkmode_test_bit(ETHTOOL_LINK_MODE_1000baseT1_Full_BIT,
+ phydev->supported)) {
+ phydev->is_baset1_capable = 1;
+ phydev->is_gigabit_capable = 1;
+ }
+ if (linkmode_test_bit(ETHTOOL_LINK_MODE_100baseT1_Full_BIT,
+ phydev->supported))
+ phydev->is_baset1_capable = 1;
+ if (linkmode_test_bit(ETHTOOL_LINK_MODE_1000baseT1_Full_BIT,
+ phydev->supported))
+ phydev->is_baset1_capable = 1;
+
of_set_phy_supported(phydev);
phy_advertise_supported(phydev);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 5ac7d21375ac..3e815128175b 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -370,6 +370,7 @@ struct phy_device {
unsigned is_internal:1;
unsigned is_pseudo_fixed_link:1;
unsigned is_gigabit_capable:1;
+ unsigned is_baset1_capable:1;
unsigned has_fixups:1;
unsigned suspended:1;
unsigned sysfs_links:1;
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index dd06302aa93e..e429cc8da31a 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -1485,6 +1485,8 @@ enum ethtool_link_mode_bit_indices {
ETHTOOL_LINK_MODE_200000baseCR4_Full_BIT = 66,
ETHTOOL_LINK_MODE_100baseT1_Full_BIT = 67,
ETHTOOL_LINK_MODE_1000baseT1_Full_BIT = 68,
+ ETHTOOL_LINK_MODE_10baseT1L_Full_BIT = 69,
+ ETHTOOL_LINK_MODE_10baseT1S_Full_BIT = 70,
/* must be last entry */
__ETHTOOL_LINK_MODE_MASK_NBITS
diff --git a/include/uapi/linux/mdio.h b/include/uapi/linux/mdio.h
index 0a552061ff1c..6fd5ff632b8e 100644
--- a/include/uapi/linux/mdio.h
+++ b/include/uapi/linux/mdio.h
@@ -43,6 +43,7 @@
#define MDIO_PKGID1 14 /* Package identifier */
#define MDIO_PKGID2 15
#define MDIO_AN_ADVERTISE 16 /* AN advertising (base page) */
+#define MDIO_PMA_BASET1_EXTABLE 18 /* BASE-T1 PMA/PMD extended ability */
#define MDIO_AN_LPA 19 /* AN LP abilities (base page) */
#define MDIO_PCS_EEE_ABLE 20 /* EEE Capability register */
#define MDIO_PMA_NG_EXTABLE 21 /* 2.5G/5G PMA/PMD extended ability */
@@ -57,11 +58,16 @@
#define MDIO_PMA_10GBT_SNR 133 /* 10GBASE-T SNR margin, lane A.
* Lanes B-D are numbered 134-136. */
#define MDIO_PMA_10GBR_FECABLE 170 /* 10GBASE-R FEC ability */
+#define MDIO_PMA_BASET1CTRL 2100 /* BASE-T1 PMA/PMD control */
#define MDIO_PCS_10GBX_STAT1 24 /* 10GBASE-X PCS status 1 */
#define MDIO_PCS_10GBRT_STAT1 32 /* 10GBASE-R/-T PCS status 1 */
#define MDIO_PCS_10GBRT_STAT2 33 /* 10GBASE-R/-T PCS status 2 */
#define MDIO_AN_10GBT_CTRL 32 /* 10GBASE-T auto-negotiation control */
#define MDIO_AN_10GBT_STAT 33 /* 10GBASE-T auto-negotiation status */
+#define MDIO_AN_BT1_CTRL 512 /* BASE-T1 auto-negotiation control */
+#define MDIO_AN_BT1_STAT 513 /* BASE-T1 auto-negotiation status */
+#define MDIO_AN_10BT1_CTRL 526 /* 10BASE-T1 auto-negotiation control */
+#define MDIO_AN_10BT1_STAT 527 /* 10BASE-T1 auto-negotiation status */
/* LASI (Link Alarm Status Interrupt) registers, defined by XENPAK MSA. */
#define MDIO_PMA_LASI_RXCTRL 0x9000 /* RX_ALARM control */
@@ -151,6 +157,7 @@
#define MDIO_PMA_CTRL2_100BTX 0x000e /* 100BASE-TX type */
#define MDIO_PMA_CTRL2_10BT 0x000f /* 10BASE-T type */
#define MDIO_PMA_CTRL2_2_5GBT 0x0030 /* 2.5GBaseT type */
+#define MDIO_PMA_CTRL2_BT1 0x003D /* BASE-T1 type */
#define MDIO_PMA_CTRL2_5GBT 0x0031 /* 5GBaseT type */
#define MDIO_PCS_CTRL2_TYPE 0x0003 /* PCS type selection */
#define MDIO_PCS_CTRL2_10GBR 0x0000 /* 10GBASE-R type */
@@ -205,8 +212,16 @@
#define MDIO_PMA_EXTABLE_1000BKX 0x0040 /* 1000BASE-KX ability */
#define MDIO_PMA_EXTABLE_100BTX 0x0080 /* 100BASE-TX ability */
#define MDIO_PMA_EXTABLE_10BT 0x0100 /* 10BASE-T ability */
+#define MDIO_PMA_EXTABLE_BASET1 0x0800 /* BASE-T1 ability */
#define MDIO_PMA_EXTABLE_NBT 0x4000 /* 2.5/5GBASE-T ability */
+/* PMA BASE-T1 control register. */
+#define MDIO_PMA_BASET1CTRL_TYPE 0x000f /* PMA/PMD BASE-T1 type sel. */
+#define MDIO_PMA_BASET1CTRL_TYPE_100BT1 0x0000 /* 100BASE-T1 */
+#define MDIO_PMA_BASET1CTRL_TYPE_1000BT1 0x0001 /* 1000BASE-T1 */
+#define MDIO_PMA_BASET1CTRL_TYPE_10BT1L 0x0002 /* 10BASE-T1L */
+#define MDIO_PMA_BASET1CTRL_TYPE_10BT1S 0x0003 /* 10BASE-T1S */
+
/* PHY XGXS lane state register. */
#define MDIO_PHYXS_LNSTAT_SYNC0 0x0001
#define MDIO_PHYXS_LNSTAT_SYNC1 0x0002
@@ -281,6 +296,12 @@
#define MDIO_PMA_NG_EXTABLE_2_5GBT 0x0001 /* 2.5GBASET ability */
#define MDIO_PMA_NG_EXTABLE_5GBT 0x0002 /* 5GBASET ability */
+/* BASE-T1 Extended abilities register. */
+#define MDIO_PMA_BASET1_EXTABLE_100BT1 0x0001 /* 100BASE-T1 ability */
+#define MDIO_PMA_BASET1_EXTABLE_1000BT1 0x0002 /* 1000BASE-T1 ability */
+#define MDIO_PMA_BASET1_EXTABLE_10BT1L 0x0004 /* 10BASE-T1L ability */
+#define MDIO_PMA_BASET1_EXTABLE_10BT1S 0x0008 /* 10BASE-T1S ability */
+
/* LASI RX_ALARM control/status registers. */
#define MDIO_PMA_LASI_RX_PHYXSLFLT 0x0001 /* PHY XS RX local fault */
#define MDIO_PMA_LASI_RX_PCSLFLT 0x0008 /* PCS RX local fault */
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next 2/3] net: dsa: mv88e6xxx: extend PTP gettime function to read system clock
From: Andrew Lunn @ 2019-08-19 15:20 UTC (permalink / raw)
To: Vivien Didelot
Cc: Hubert Feurstein, netdev, linux-kernel, Richard Cochran,
Florian Fainelli, Vladimir Oltean, David S. Miller
In-Reply-To: <20190819111639.GB6123@t480s.localdomain>
On Mon, Aug 19, 2019 at 11:16:39AM -0400, Vivien Didelot wrote:
> On Mon, 19 Aug 2019 15:27:33 +0200, Andrew Lunn <andrew@lunn.ch> wrote:
> > > @@ -45,7 +45,8 @@ static int mv88e6xxx_smi_direct_write(struct mv88e6xxx_chip *chip,
> > > {
> > > int ret;
> > >
> > > - ret = mdiobus_write_nested(chip->bus, dev, reg, data);
> > > + ret = mdiobus_write_sts_nested(chip->bus, dev, reg, data,
> > > + chip->ptp_sts);
> > > if (ret < 0)
> > > return ret;
> > >
> >
> > Please also make a similar change to mv88e6xxx_smi_indirect_write().
> > The last write in that function should be timestamped.
> >
> > Vivien, please could you think about these changes with respect to
> > RMU. We probably want to skip the RMU in this case, so we get slow but
> > uniform jitter, vs fast and unpredictable jitter from using the RMU.
>
> The RMU will have its own mv88e6xxx_bus_ops.
Yes, that is what i was expecting. But for this operation, triggering
a PTP timestamp, we probably want it to fall back to MDIO, which is
much more deterministic.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 4/6] net: dsa: mv88e6xxx: do not change STP state on port disabling
From: Vivien Didelot @ 2019-08-19 15:27 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, marek.behun, davem, f.fainelli
In-Reply-To: <20190819134057.GF8981@lunn.ch>
Hi Andrew,
On Mon, 19 Aug 2019 15:40:57 +0200, Andrew Lunn <andrew@lunn.ch> wrote:
> On Sun, Aug 18, 2019 at 01:35:46PM -0400, Vivien Didelot wrote:
> > When disabling a port, that is not for the driver to decide what to
> > do with the STP state. This is already handled by the DSA layer.
>
> Hi Vivien
>
> Putting the port into STP disabled state is how you actually disable
> it, for the mv88e6xxx. So this is not really about STP, it is about
> powering off the port. Maybe a comment is needed, rather than removing
> the code?
This is not for the driver to decide, the stack already handles that.
Otherwise, calling dsa_port_disable on a bridged port would result in
mv88e6xxx forcing the STP state to Disabled while this is not expected.
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH 1/2] PTP: introduce new versions of IOCTLs
From: Richard Cochran @ 2019-08-19 15:43 UTC (permalink / raw)
To: Joe Perches; +Cc: Felipe Balbi, Christopher S Hall, netdev, linux-kernel
In-Reply-To: <83075553a61ede1de9cbf77b90a5acdeab5aacbf.camel@perches.com>
On Sun, Aug 18, 2019 at 03:07:18PM -0700, Joe Perches wrote:
> Also the original patch deletes 2 case entries for
> PTP_PIN_GETFUNC and PTP_PIN_SETFUNC and converts them to
> PTP_PIN_GETFUNC2 and PTP_PIN_SETFUNC2 but still uses tests
> for the deleted case label entries making part of the case
> code block unreachable.
>
> That's at least a defect:
>
> - case PTP_PIN_GETFUNC:
> + case PTP_PIN_GETFUNC2:
>
> and
>
> - case PTP_PIN_SETFUNC:
> + case PTP_PIN_SETFUNC2:
Good catch. Felipe, please fix that!
(Regarding Joe's memset suggestion, I'll leave that to your discretion.)
Thanks,
Richard
^ permalink raw reply
* Re: [RESEND][PATCH v3 bpf-next] btf: expose BTF info through sysfs
From: Ilya Leoshkevich @ 2019-08-19 15:56 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: bpf, Networking, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Kernel Team, Vasily Gorbik, Heiko Carstens
In-Reply-To: <20190812183947.130889-1-andriin@fb.com>
> Am 12.08.2019 um 20:39 schrieb Andrii Nakryiko <andriin@fb.com>:
>
> @@ -92,23 +92,34 @@ vmlinux_link()
> }
>
> # generate .BTF typeinfo from DWARF debuginfo
> +# ${1} - vmlinux image
> +# ${2} - file to dump raw BTF data into
> gen_btf()
> {
> - local pahole_ver;
> + local pahole_ver
> + local bin_arch
>
> if ! [ -x "$(command -v ${PAHOLE})" ]; then
> info "BTF" "${1}: pahole (${PAHOLE}) is not available"
> - return 0
> + return 1
> fi
>
> pahole_ver=$(${PAHOLE} --version | sed -E 's/v([0-9]+)\.([0-9]+)/\1\2/')
> if [ "${pahole_ver}" -lt "113" ]; then
> info "BTF" "${1}: pahole version $(${PAHOLE} --version) is too old, need at least v1.13"
> - return 0
> + return 1
> fi
>
> - info "BTF" ${1}
> + info "BTF" ${2}
> + vmlinux_link ${1}
> LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1}
> +
> + # dump .BTF section into raw binary file to link with final vmlinux
> + bin_arch=$(${OBJDUMP} -f ${1} | grep architecture | \
> + cut -d, -f1 | cut -d' ' -f2)
> + ${OBJCOPY} --dump-section .BTF=.btf.kernel.bin ${1} 2>/dev/null
> + ${OBJCOPY} -I binary -O ${CONFIG_OUTPUT_FORMAT} -B ${bin_arch} \
> + --rename-section .data=.BTF .btf.kernel.bin ${2}
> }
CONFIG_OUTPUT_FORMAT appears to be x86-only; enabling
CONFIG_DEBUG_INFO_BTF on s390 caused a build failure. I now have a quick
and dirty local patch, which adds CONFIG_OUTPUT_FORMAT to s390 and fixes
the issue for me, but I suspect that CONFIG_DEBUG_INFO_BTF might be
broken on other arches as well.
^ permalink raw reply
* Re: [PATCH net-next] netdevsim: Fix build error without CONFIG_INET
From: Ido Schimmel @ 2019-08-19 15:58 UTC (permalink / raw)
To: YueHaibing
Cc: davem, idosch, jiri, mcroce, linux-kernel, netdev, jakub.kicinski
In-Reply-To: <20190819120825.74460-1-yuehaibing@huawei.com>
On Mon, Aug 19, 2019 at 08:08:25PM +0800, YueHaibing wrote:
> If CONFIG_INET is not set, building fails:
>
> drivers/net/netdevsim/dev.o: In function `nsim_dev_trap_report_work':
> dev.c:(.text+0x67b): undefined reference to `ip_send_check'
>
> Add CONFIG_INET Kconfig dependency to fix this.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Fixes: da58f90f11f5 ("netdevsim: Add devlink-trap support")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Thanks for the patch.
> ---
> drivers/net/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 48e209e..7bb786e 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -505,7 +505,7 @@ source "drivers/net/hyperv/Kconfig"
>
> config NETDEVSIM
> tristate "Simulated networking device"
> - depends on DEBUG_FS
> + depends on INET && DEBUG_FS
> select NET_DEVLINK
> help
> This driver is a developer testing tool and software model that can
> --
> 2.7.4
>
>
^ permalink raw reply
* Re: [PATCH 1/2] PTP: introduce new versions of IOCTLs
From: Joe Perches @ 2019-08-19 15:58 UTC (permalink / raw)
To: Richard Cochran; +Cc: Felipe Balbi, Christopher S Hall, netdev, linux-kernel
In-Reply-To: <20190819154320.GB2883@localhost>
On Mon, 2019-08-19 at 08:43 -0700, Richard Cochran wrote:
> On Sun, Aug 18, 2019 at 03:07:18PM -0700, Joe Perches wrote:
> > Also the original patch deletes 2 case entries for
> > PTP_PIN_GETFUNC and PTP_PIN_SETFUNC and converts them to
> > PTP_PIN_GETFUNC2 and PTP_PIN_SETFUNC2 but still uses tests
> > for the deleted case label entries making part of the case
> > code block unreachable.
> >
> > That's at least a defect:
> >
> > - case PTP_PIN_GETFUNC:
> > + case PTP_PIN_GETFUNC2:
> >
> > and
> >
> > - case PTP_PIN_SETFUNC:
> > + case PTP_PIN_SETFUNC2:
>
> Good catch. Felipe, please fix that!
>
> (Regarding Joe's memset suggestion, I'll leave that to your discretion.)
Not just how declarations are done or memset.
Minimizing unnecessary stack consumption is generally good.
^ permalink raw reply
* Re: [PATCH v4 3/9] nvmem: core: add nvmem_device_find
From: Srinivas Kandagatla @ 2019-08-19 16:03 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Ralf Baechle, Paul Burton, James Hogan, Dmitry Torokhov,
Lee Jones, David S. Miller, Alessandro Zummo, Alexandre Belloni,
Greg Kroah-Hartman, Jiri Slaby, Evgeniy Polyakov, linux-mips,
linux-kernel, linux-input, netdev, linux-rtc, linux-serial
In-Reply-To: <20190816140942.GA15050@alpha.franken.de>
On 16/08/2019 15:09, Thomas Bogendoerfer wrote:
> On Wed, Aug 14, 2019 at 01:52:49PM +0100, Srinivas Kandagatla wrote:
>> On 14/08/2019 12:46, Thomas Bogendoerfer wrote:
>>> On Tue, 13 Aug 2019 10:40:34 +0100
>>> Srinivas Kandagatla <srinivas.kandagatla@linaro.org> wrote:
>>>> On 09/08/2019 11:32, Thomas Bogendoerfer wrote:
>>>>> nvmem_device_find provides a way to search for nvmem devices with
>>>>> the help of a match function simlair to bus_find_device.
>>>>>
>>>>> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
>>>>> ---
>>>>> drivers/nvmem/core.c | 62 ++++++++++++++++++++++--------------------
>>>>> include/linux/nvmem-consumer.h | 9 ++++++
>>>>> 2 files changed, 41 insertions(+), 30 deletions(-)
>>>>
>>>> Have you considered using nvmem_register_notifier() ?
>>>
>>> yes, that was the first idea. But then I realized I need to build up
>>> a private database of information already present in nvmem bus. So I
>>> looked for a way to retrieve it from there. Unfortunately I couldn't
>>> use bus_find_device directly, because nvmem_bus_type and struct nvmem_device
>>> is hidden. So I refactured the lookup code and added a more universal
>>> lookup function, which fits my needs and should be usable for more.
>> I see your point.
>>
>> overall the patch as it is look good, but recently we added more generic
>> lookups for DT node, looks like part of your patch is un-doing generic
>> device name lookup.
>>
>> DT node match lookup is in https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/log/?h=generic_lookup_helpers
>
> these patches are not in Linus tree, yet. I guess they will show up
> in 5.4. No idea how to deal with it right now, do you ?
All these patches are due to go in next merge window,
You should base your patch on top of linux-next.
thanks,
srini
>
>> Other missing bit is adding this api to documentation in
>> ./Documentation/driver-api/nvmem.rst
>
> ok, will do.
>
> Thomas.
>
^ permalink raw reply
* Re: r8169: Performance regression and latency instability
From: Juliana Rodrigueiro @ 2019-08-19 16:04 UTC (permalink / raw)
To: Heiner Kallweit, Holger Hoffstätte, Eric Dumazet, netdev
In-Reply-To: <8fa71d82-d309-df38-5924-2275db188b61@gmail.com>
Hi!
First of all: Thank you everyone for the input.
Here is some more info about my NIC. (Using the latest ethtool)
# ethtool -i eth0 ; ifconfig eth0
driver: r8169
version:
firmware-version: rtl8168h-2_0.0.2 02/26/15
expansion-rom-version:
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
eth0 Link encap:Ethernet HWaddr <hidden>
inet addr:<hidden> Bcast:<hidden> Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:27392501 errors:0 dropped:0 overruns:0 frame:0
TX packets:24647212 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:33702173568 (31.3 GiB) TX bytes:35865124147 (33.4 GiB)
On 8/16/19 9:12 PM, Heiner Kallweit wrote:
> Indeed, here we're talking about changes in linux-next, and Juliana's issue is
> with 4.19. However I'd appreciate if Juliana could test with linux-next and
> different combinations of the NETIF_F_xxx features.
I also tested the latest linux-next (20190819) and the results did not
improved for me, unfortunately. About the same as all the kernel
versions I tested from 4.17 onwards.
# netperf -v 2 -P 0 -H <netserver-ip>,4 -I 99,5 -t omni -l 1 -- -O
STDDEV_LATENCY -m 64K -d Send
627.99
Running linux-next I have the following defaults (shortened for simplicity):
# ethtool -k eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: on
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
... (all off from here)
There are quite a few possible combinations to go through. I executed my
test with SG, TSO, GSO, RX, TX individually disabled, but the results
were all the same or slightly worse.
Until I find the root cause, we will have to keep the "tcp: switch to
GSO being always on" patch reverted for production, which is not ideal.
Any other ideas how I could debug this issue?
Best regards,
Juliana.
^ permalink raw reply
* Re: [PATCH net-next 4/6] net: dsa: mv88e6xxx: do not change STP state on port disabling
From: Andrew Lunn @ 2019-08-19 16:10 UTC (permalink / raw)
To: Vivien Didelot; +Cc: netdev, marek.behun, davem, f.fainelli
In-Reply-To: <20190819112733.GD6123@t480s.localdomain>
On Mon, Aug 19, 2019 at 11:27:33AM -0400, Vivien Didelot wrote:
> Hi Andrew,
>
> On Mon, 19 Aug 2019 15:40:57 +0200, Andrew Lunn <andrew@lunn.ch> wrote:
> > On Sun, Aug 18, 2019 at 01:35:46PM -0400, Vivien Didelot wrote:
> > > When disabling a port, that is not for the driver to decide what to
> > > do with the STP state. This is already handled by the DSA layer.
> >
> > Hi Vivien
> >
> > Putting the port into STP disabled state is how you actually disable
> > it, for the mv88e6xxx. So this is not really about STP, it is about
> > powering off the port. Maybe a comment is needed, rather than removing
> > the code?
>
> This is not for the driver to decide, the stack already handles that.
> Otherwise, calling dsa_port_disable on a bridged port would result in
> mv88e6xxx forcing the STP state to Disabled while this is not expected.
Hi Vivien
Lets look at this from a different angle.
The chip powers up. The older generation, the ports are enabled by
default. For newer generations the NO_CPU strapping determines the
power up state of a port.
What we want is that unused ports get powered off. The previous change
in the set does this. It calls mv88e6xxx_port_disable for all unused
ports. How do we disable the port? For the mv88ex666, we set the port
state to disabled. "The switch port is disabled and it will not
receive or transmit and frames." For other switches, there might be
other control registers to play with, other than STP.
Are you saying the core already sets the STP to disabled, for ports
which are unused? I did not spot that in your previous patch?
Thanks
Andrew
^ permalink raw reply
* [PATCH] bpfilter/verifier: add include guard to tnum.h
From: Masahiro Yamada @ 2019-08-19 16:10 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, netdev, bpf
Cc: Masahiro Yamada, linux-kernel
Add a header include guard just in case.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
include/linux/tnum.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/linux/tnum.h b/include/linux/tnum.h
index c7dc2b5902c0..c17af77f3fae 100644
--- a/include/linux/tnum.h
+++ b/include/linux/tnum.h
@@ -5,6 +5,10 @@
* propagate the unknown bits such that the tnum result represents all the
* possible results for possible values of the operands.
*/
+
+#ifndef _LINUX_TNUM_H
+#define _LINUX_TNUM_H
+
#include <linux/types.h>
struct tnum {
@@ -81,3 +85,5 @@ bool tnum_in(struct tnum a, struct tnum b);
int tnum_strn(char *str, size_t size, struct tnum a);
/* Format a tnum as tristate binary expansion */
int tnum_sbin(char *str, size_t size, struct tnum a);
+
+#endif /* _LINUX_TNUM_H */
--
2.17.1
^ permalink raw reply related
* [net-next v2 00/14][pull request] 100GbE Intel Wired LAN Driver Updates 2019-08-19
From: Jeff Kirsher @ 2019-08-19 16:16 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann
This series contains updates to ice driver only.
Brett fixes the detection of a hung transmit ring by checking the
software based tail (next_to_use) to determine if there is pending work.
Updates the driver to assume that using more than one receive queue per
receive ring container is a rare case, so use unlikely() in the case
were we actually need to divide our budget for multiple queues. Fixed
an issue where the write back on ITR bit was not being set when
interrupts are disabled, which was causing only write backs when polling
only when a cache line is filled. Cleans up unnecessary wait times
during VF bring up and reset paths. Increased the mailbox size for
receive queues that are used to communicate with VFs to accommodate the
large number of VFs that the driver can support.
Akeem restructures the initialization flows for VFs, including how VFs
are configured and resources allocated to improve flows so that when we
clean up resources, we do not try to free resources that were never
allocated. Organizes code to ensure that VF specific code is located in
the SR-IOV specific file.
Paul fixes an issue when setting the pause parameter which was
incorrectly blocking users from changing receive or transmit pause
settings. Ensure register access for MSIX vector index is only done in
the PF space and not absolute device space.
Usha fixes a potential kernel hang in the DCB rebuild path when in CEE
mode, where the ETS recommended DCB configuration is not being set or
set correctly.
Mitch updates the driver to process all receive descriptors, regardless
of the size of the associated data.
Tony fixes and issue during the reset/rebuild path of a PF VSI where we
were assuming that the PF VSI was always to be enabled, which can
attempt to bring up a PF VSI on a downed interface which can lead to
various crashes.
Pawel fixes up variable definitions to match the type of data being
stored.
v2: Dropped patch 1 of the series to add ethtool support to query/add
channels on a VSI, while we re-qork the functionality to match the
ethtool expected behavior to report combined (Tx and Rx) numbers.
The following are changes since commit 20e79a0a2cfd15b6cfb18119f2e108396be56716:
net: hns: add phy_attached_info() to the hns driver
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 100GbE
Akeem G Abodunrin (2):
ice: Restructure VFs initialization flows
ice: Move VF resources definition to SR-IOV specific file
Brett Creeley (6):
ice: Use the software based tail when checking for hung Tx ring
ice: Assume that more than one Rx queue is rare in ice_napi_poll
ice: Set WB_ON_ITR when we don't re-enable interrupts
ice: Reduce wait times during VF bringup/reset
ice: Increase size of Mailbox receive queue for many VFs
ice: improve print for VF's when adding/deleting MAC filters
Mitch Williams (1):
ice: allow empty Rx descriptors
Paul Greenwalt (2):
ice: fix set pause param autoneg check
ice: update GLINT_DYN_CTL and GLINT_VECT2FUNC register access
Pawel Kaminski (1):
ice: Change type for queue counts
Tony Nguyen (1):
ice: Do not always bring up PF VSI in ice_ena_vsi()
Usha Ketineni (1):
ice: Fix kernel hang with DCB reset in CEE mode
drivers/net/ethernet/intel/ice/ice.h | 14 +-
drivers/net/ethernet/intel/ice/ice_dcb_lib.c | 149 +++++++++++-------
drivers/net/ethernet/intel/ice/ice_ethtool.c | 28 +++-
.../net/ethernet/intel/ice/ice_hw_autogen.h | 3 +
drivers/net/ethernet/intel/ice/ice_main.c | 12 +-
drivers/net/ethernet/intel/ice/ice_txrx.c | 84 +++++++++-
drivers/net/ethernet/intel/ice/ice_txrx.h | 13 ++
.../net/ethernet/intel/ice/ice_virtchnl_pf.c | 148 ++++++++++-------
.../net/ethernet/intel/ice/ice_virtchnl_pf.h | 20 ++-
9 files changed, 325 insertions(+), 146 deletions(-)
--
2.21.0
^ permalink raw reply
* [net-next v2 02/14] ice: Assume that more than one Rx queue is rare in ice_napi_poll
From: Jeff Kirsher @ 2019-08-19 16:16 UTC (permalink / raw)
To: davem; +Cc: Brett Creeley, netdev, nhorman, sassmann, Andrew Bowers,
Jeff Kirsher
In-Reply-To: <20190819161708.3763-1-jeffrey.t.kirsher@intel.com>
From: Brett Creeley <brett.creeley@intel.com>
Currently we divide budget by the number of Rx queues per Rx ring
container in ice_napi_poll even if there is only 1. This is an
unnecessary divide for the normal case of 1 Rx ring per Rx ring
container. Fix this by using an unlikely() call in the case where we
actually need to divide.
Also, we will always set budget_per_ring even if there are no Rx rings
in the Rx ring container so we don't need to initialize it to 0.
Signed-off-by: Brett Creeley <brett.creeley@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ice/ice_txrx.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.c b/drivers/net/ethernet/intel/ice/ice_txrx.c
index 9234fd203929..837d6ae2f33b 100644
--- a/drivers/net/ethernet/intel/ice/ice_txrx.c
+++ b/drivers/net/ethernet/intel/ice/ice_txrx.c
@@ -1414,8 +1414,8 @@ int ice_napi_poll(struct napi_struct *napi, int budget)
container_of(napi, struct ice_q_vector, napi);
struct ice_vsi *vsi = q_vector->vsi;
bool clean_complete = true;
- int budget_per_ring = 0;
struct ice_ring *ring;
+ int budget_per_ring;
int work_done = 0;
/* Since the actual Tx work is minimal, we can give the Tx a larger
@@ -1429,11 +1429,16 @@ int ice_napi_poll(struct napi_struct *napi, int budget)
if (budget <= 0)
return budget;
- /* We attempt to distribute budget to each Rx queue fairly, but don't
- * allow the budget to go below 1 because that would exit polling early.
- */
- if (q_vector->num_ring_rx)
+ /* normally we have 1 Rx ring per q_vector */
+ if (unlikely(q_vector->num_ring_rx > 1))
+ /* We attempt to distribute budget to each Rx queue fairly, but
+ * don't allow the budget to go below 1 because that would exit
+ * polling early.
+ */
budget_per_ring = max(budget / q_vector->num_ring_rx, 1);
+ else
+ /* Max of 1 Rx ring in this q_vector so give it the budget */
+ budget_per_ring = budget;
ice_for_each_ring(ring, q_vector->rx) {
int cleaned;
--
2.21.0
^ 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