* [iproute PATCH v2 0/4] A bunch of fixes regarding colored output
From: Phil Sutter @ 2018-08-15 16:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Till Maas, David Ahern
This series contains fixes for conditionally colored output in patches 1
and 2. Patch 3 merges the common conditionals from ip, tc and bridge
tools. Patch 4 then adds a further restriction to colored output to
prevent garbled output when redirecting into a file.
Changes since v1:
- Adjusted last patch according to feedback. Details given in changelog
of that patch.
Phil Sutter (4):
tc: Fix typo in check for colored output
bridge: Fix check for colored output
Merge common code for conditionally colored output
lib: Enable colored output only for TTYs
bridge/bridge.c | 5 ++---
include/color.h | 1 +
ip/ip.c | 3 +--
lib/color.c | 13 +++++++++++++
man/man8/bridge.8 | 5 ++++-
man/man8/ip.8 | 5 ++++-
man/man8/tc.8 | 5 ++++-
tc/tc.c | 3 +--
8 files changed, 30 insertions(+), 10 deletions(-)
--
2.18.0
^ permalink raw reply
* Re: [iproute PATCH v2 4/4] lib: Enable colored output only for TTYs
From: David Ahern @ 2018-08-15 16:24 UTC (permalink / raw)
To: Phil Sutter, Stephen Hemminger; +Cc: netdev, Till Maas
In-Reply-To: <20180815162127.21477-5-phil@nwl.cc>
On 8/15/18 10:21 AM, Phil Sutter wrote:
> Add an additional prerequisite to check_enable_color() to make sure
> stdout actually points to an open TTY device. Otherwise calls like
>
> | ip -color a s >/tmp/foo
>
> will print color escape sequences into that file. Allow to override this
> check by specifying '-color' flag more than once.
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
> Changes since v1:
> - Allow to override isatty() check by specifying '-color' flag more than
> once.
That adds overhead to my workflow where I almost always have to pipe the
output of ip to a pager.
^ permalink raw reply
* Re: [iproute PATCH v2 4/4] lib: Enable colored output only for TTYs
From: Phil Sutter @ 2018-08-15 16:39 UTC (permalink / raw)
To: David Ahern; +Cc: Stephen Hemminger, netdev, Till Maas
In-Reply-To: <06633975-40ae-f3d6-b5a9-8a947752e400@gmail.com>
On Wed, Aug 15, 2018 at 10:24:31AM -0600, David Ahern wrote:
> On 8/15/18 10:21 AM, Phil Sutter wrote:
> > Add an additional prerequisite to check_enable_color() to make sure
> > stdout actually points to an open TTY device. Otherwise calls like
> >
> > | ip -color a s >/tmp/foo
> >
> > will print color escape sequences into that file. Allow to override this
> > check by specifying '-color' flag more than once.
> >
> > Signed-off-by: Phil Sutter <phil@nwl.cc>
> > ---
> > Changes since v1:
> > - Allow to override isatty() check by specifying '-color' flag more than
> > once.
>
> That adds overhead to my workflow where I almost always have to pipe the
> output of ip to a pager.
alias ip='ip -color -color'
Another alternative may be to introduce -autocolor flag. Establishing
the same syntax as used by 'ls' is not as trivial due to the simple
commandline parsing used in 'ip'.
Cheers, Phil
^ permalink raw reply
* Re: samples don't build on v4.18
From: Jakub Kicinski @ 2018-08-15 19:34 UTC (permalink / raw)
To: Joel Fernandes
Cc: LKML, wangnan0, open list:BPF (Safe dynamic programs and tools),
Alexei Starovoitov, acme, Chenbo Feng
In-Reply-To: <20180815030132.GA204101@joelaf.mtv.corp.google.com>
On Tue, 14 Aug 2018 20:01:32 -0700, Joel Fernandes wrote:
> On Tue, Aug 14, 2018 at 06:22:21PM -0700, Joel Fernandes wrote:
> > Forgot to add the patch author, doing so now. thanks
> >
> > On Tue, Aug 14, 2018 at 6:20 PM, Joel Fernandes <joelaf@google.com> wrote:
> > >
> > > Hi,
> > > When building BPF samples on v4.18, I get the following errors:
> > >
> > > $ cd samples/bpf/
> > > $ make
> > >
> > > Auto-detecting system features:
> > > ... libelf: [ OFF ]
> > > ... bpf: [ OFF ]
> > >
> > > No libelf found
> > > Makefile:213: recipe for target 'elfdep' failed
> > > -----------
> > >
> > > I bissected it down to commit 5f9380572b4bb24f60cd492b1
> > >
> > > Author: Jakub Kicinski <jakub.kicinski@netronome.com>
> > > Date: Thu May 10 10:24:39 2018 -0700
> > >
> > > samples: bpf: compile and link against full libbpf
> > > ---------
> > >
> > > Checking out a kernel before this commit makes the samples build. Also I do
> > > have libelf on my system.
> > >
> > > Any thoughts on this issue?
>
> There is some weirdness going on with my kernel tree. If I do a fresh clone
> of v4.18 and build samples, everything works.
>
> However if I take my existing checkout, do a:
> git clean -f -d
> make mrproper
>
> Then I try to build the samples, I get the "No libelf found".
>
> Obviously the existing checked out kernel tree is in some weird state that I
> am not yet able to fix. But atleast if I blow the whole tree and clone again,
> I'm able to build...
>
> Is this related to the intermittent "No libelf found" issues that were
> recently discussed?
Can't reproduce, could you provide all exact commands you run to see
this, including the initial clone?
12:32 linux$ git clean -f -d
12:32 linux$ make mrproper
CLEAN .
CLEAN arch/x86/tools
CLEAN .tmp_versions
CLEAN scripts/basic
CLEAN scripts/kconfig
CLEAN scripts/mod
CLEAN scripts
CLEAN include/config usr/include include/generated arch/x86/include/generated
CLEAN .config .config.old
12:32 linux$ make defconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
YACC scripts/kconfig/zconf.tab.c
LEX scripts/kconfig/zconf.lex.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
*** Default configuration is based on 'x86_64_defconfig'
#
# configuration written to .config
#
12:32 linux$ make headers_install
UPD include/generated/uapi/linux/version.h
WRAP arch/x86/include/generated/uapi/asm/bpf_perf_event.h
WRAP arch/x86/include/generated/uapi/asm/poll.h
SYSTBL arch/x86/include/generated/asm/syscalls_32.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_32.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_64.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_x32.h
HOSTCC arch/x86/tools/relocs_32.o
HOSTCC arch/x86/tools/relocs_64.o
HOSTCC arch/x86/tools/relocs_common.o
HOSTLD arch/x86/tools/relocs
HOSTCC scripts/unifdef
INSTALL usr/include/asm-generic/ (37 files)
INSTALL usr/include/drm/ (26 files)
INSTALL usr/include/linux/ (497 files)
INSTALL usr/include/linux/android/ (1 file)
INSTALL usr/include/linux/byteorder/ (2 files)
INSTALL usr/include/linux/caif/ (2 files)
INSTALL usr/include/linux/can/ (6 files)
INSTALL usr/include/linux/cifs/ (1 file)
INSTALL usr/include/linux/dvb/ (8 files)
INSTALL usr/include/linux/genwqe/ (1 file)
INSTALL usr/include/linux/hdlc/ (1 file)
INSTALL usr/include/linux/hsi/ (2 files)
INSTALL usr/include/linux/iio/ (2 files)
INSTALL usr/include/linux/isdn/ (1 file)
INSTALL usr/include/linux/mmc/ (1 file)
INSTALL usr/include/linux/netfilter/ (88 files)
INSTALL usr/include/linux/netfilter/ipset/ (4 files)
INSTALL usr/include/linux/netfilter_arp/ (2 files)
INSTALL usr/include/linux/netfilter_bridge/ (17 files)
INSTALL usr/include/linux/netfilter_ipv4/ (9 files)
INSTALL usr/include/linux/netfilter_ipv6/ (13 files)
INSTALL usr/include/linux/nfsd/ (5 files)
INSTALL usr/include/linux/raid/ (2 files)
INSTALL usr/include/linux/sched/ (1 file)
INSTALL usr/include/linux/spi/ (1 file)
INSTALL usr/include/linux/sunrpc/ (1 file)
INSTALL usr/include/linux/tc_act/ (15 files)
INSTALL usr/include/linux/tc_ematch/ (5 files)
INSTALL usr/include/linux/usb/ (12 files)
INSTALL usr/include/linux/wimax/ (1 file)
INSTALL usr/include/misc/ (2 files)
INSTALL usr/include/mtd/ (5 files)
INSTALL usr/include/rdma/ (25 files)
INSTALL usr/include/rdma/hfi/ (2 files)
INSTALL usr/include/scsi/ (4 files)
INSTALL usr/include/scsi/fc/ (4 files)
INSTALL usr/include/sound/ (16 files)
INSTALL usr/include/video/ (3 files)
INSTALL usr/include/xen/ (4 files)
INSTALL usr/include/asm/ (62 files)
12:32 linux$ cd samples/bpf/
12:32 bpf$ make LLC=llc-6.0 LLVM_OBJCOPY=llvm-objcopy-6.0 CLANG=clang-6.0
make -C ../../ /tmp/linux/samples/bpf/ BPF_SAMPLES_PATH=/tmp/linux/samples/bpf
make[1]: Entering directory '/tmp/linux'
scripts/kconfig/conf --syncconfig Kconfig
SYSHDR arch/x86/include/generated/asm/unistd_32_ia32.h
SYSHDR arch/x86/include/generated/asm/unistd_64_x32.h
SYSTBL arch/x86/include/generated/asm/syscalls_64.h
UPD include/config/kernel.release
WRAP arch/x86/include/generated/asm/dma-contiguous.h
WRAP arch/x86/include/generated/asm/early_ioremap.h
WRAP arch/x86/include/generated/asm/mcs_spinlock.h
WRAP arch/x86/include/generated/asm/mm-arch-hooks.h
UPD include/generated/utsrelease.h
CC kernel/bounds.s
UPD include/generated/bounds.h
UPD include/generated/timeconst.h
CC arch/x86/kernel/asm-offsets.s
UPD include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
DESCEND objtool
HOSTCC /tmp/linux/tools/objtool/fixdep.o
HOSTLD /tmp/linux/tools/objtool/fixdep-in.o
LINK /tmp/linux/tools/objtool/fixdep
CC /tmp/linux/tools/objtool/exec-cmd.o
CC /tmp/linux/tools/objtool/help.o
CC /tmp/linux/tools/objtool/pager.o
CC /tmp/linux/tools/objtool/parse-options.o
CC /tmp/linux/tools/objtool/run-command.o
CC /tmp/linux/tools/objtool/sigchain.o
CC /tmp/linux/tools/objtool/subcmd-config.o
LD /tmp/linux/tools/objtool/libsubcmd-in.o
AR /tmp/linux/tools/objtool/libsubcmd.a
CC /tmp/linux/tools/objtool/arch/x86/decode.o
LD /tmp/linux/tools/objtool/arch/x86/objtool-in.o
CC /tmp/linux/tools/objtool/builtin-check.o
CC /tmp/linux/tools/objtool/builtin-orc.o
CC /tmp/linux/tools/objtool/check.o
CC /tmp/linux/tools/objtool/orc_gen.o
CC /tmp/linux/tools/objtool/orc_dump.o
CC /tmp/linux/tools/objtool/elf.o
CC /tmp/linux/tools/objtool/special.o
CC /tmp/linux/tools/objtool/objtool.o
CC /tmp/linux/tools/objtool/libstring.o
CC /tmp/linux/tools/objtool/str_error_r.o
LD /tmp/linux/tools/objtool/objtool-in.o
LINK /tmp/linux/tools/objtool/objtool
CC scripts/mod/empty.o
HOSTCC scripts/mod/mk_elfconfig
MKELF scripts/mod/elfconfig.h
HOSTCC scripts/mod/modpost.o
CC scripts/mod/devicetable-offsets.s
UPD scripts/mod/devicetable-offsets.h
HOSTCC scripts/mod/file2alias.o
HOSTCC scripts/mod/sumversion.o
HOSTLD scripts/mod/modpost
HOSTCC scripts/selinux/genheaders/genheaders
HOSTCC scripts/selinux/mdp/mdp
HOSTCC scripts/kallsyms
HOSTCC scripts/pnmtologo
HOSTCC scripts/conmakehash
HOSTCC scripts/sortextable
HOSTCC scripts/asn1_compiler
HOSTCC scripts/extract-cert
make -C /tmp/linux/samples/bpf/../../tools/lib/bpf/ RM='rm -rf' LDFLAGS= srctree=/tmp/linux/samples/bpf/../../ O=
HOSTCC fixdep.o
HOSTLD fixdep-in.o
LINK fixdep
CC libbpf.o
CC bpf.o
CC nlattr.o
CC btf.o
LD libbpf-in.o
LINK libbpf.a
LINK libbpf.so
HOSTCC /tmp/linux/samples/bpf/test_lru_dist
HOSTCC /tmp/linux/samples/bpf/sock_example
HOSTCC /tmp/linux/samples/bpf/bpf_load.o
HOSTCC /tmp/linux/samples/bpf/fds_example.o
HOSTLD /tmp/linux/samples/bpf/fds_example
HOSTCC /tmp/linux/samples/bpf/sockex1_user.o
HOSTLD /tmp/linux/samples/bpf/sockex1
HOSTCC /tmp/linux/samples/bpf/sockex2_user.o
HOSTLD /tmp/linux/samples/bpf/sockex2
HOSTCC /tmp/linux/samples/bpf/sockex3_user.o
HOSTLD /tmp/linux/samples/bpf/sockex3
HOSTCC /tmp/linux/samples/bpf/tracex1_user.o
HOSTLD /tmp/linux/samples/bpf/tracex1
HOSTCC /tmp/linux/samples/bpf/tracex2_user.o
HOSTLD /tmp/linux/samples/bpf/tracex2
HOSTCC /tmp/linux/samples/bpf/tracex3_user.o
HOSTLD /tmp/linux/samples/bpf/tracex3
HOSTCC /tmp/linux/samples/bpf/tracex4_user.o
HOSTLD /tmp/linux/samples/bpf/tracex4
HOSTCC /tmp/linux/samples/bpf/tracex5_user.o
HOSTLD /tmp/linux/samples/bpf/tracex5
HOSTCC /tmp/linux/samples/bpf/tracex6_user.o
HOSTLD /tmp/linux/samples/bpf/tracex6
HOSTCC /tmp/linux/samples/bpf/tracex7_user.o
HOSTLD /tmp/linux/samples/bpf/tracex7
HOSTCC /tmp/linux/samples/bpf/test_probe_write_user_user.o
HOSTLD /tmp/linux/samples/bpf/test_probe_write_user
HOSTCC /tmp/linux/samples/bpf/trace_output_user.o
HOSTCC /tmp/linux/samples/bpf/../../tools/testing/selftests/bpf/trace_helpers.o
HOSTLD /tmp/linux/samples/bpf/trace_output
HOSTCC /tmp/linux/samples/bpf/lathist_user.o
HOSTLD /tmp/linux/samples/bpf/lathist
HOSTCC /tmp/linux/samples/bpf/offwaketime_user.o
HOSTLD /tmp/linux/samples/bpf/offwaketime
HOSTCC /tmp/linux/samples/bpf/spintest_user.o
HOSTLD /tmp/linux/samples/bpf/spintest
HOSTCC /tmp/linux/samples/bpf/map_perf_test_user.o
HOSTLD /tmp/linux/samples/bpf/map_perf_test
HOSTCC /tmp/linux/samples/bpf/test_overhead_user.o
HOSTLD /tmp/linux/samples/bpf/test_overhead
HOSTCC /tmp/linux/samples/bpf/test_cgrp2_array_pin.o
HOSTLD /tmp/linux/samples/bpf/test_cgrp2_array_pin
HOSTCC /tmp/linux/samples/bpf/test_cgrp2_attach.o
HOSTLD /tmp/linux/samples/bpf/test_cgrp2_attach
HOSTCC /tmp/linux/samples/bpf/test_cgrp2_attach2.o
HOSTCC /tmp/linux/samples/bpf/../../tools/testing/selftests/bpf/cgroup_helpers.o
HOSTLD /tmp/linux/samples/bpf/test_cgrp2_attach2
HOSTCC /tmp/linux/samples/bpf/test_cgrp2_sock.o
HOSTLD /tmp/linux/samples/bpf/test_cgrp2_sock
HOSTCC /tmp/linux/samples/bpf/test_cgrp2_sock2.o
HOSTLD /tmp/linux/samples/bpf/test_cgrp2_sock2
HOSTCC /tmp/linux/samples/bpf/xdp1_user.o
HOSTLD /tmp/linux/samples/bpf/xdp1
HOSTLD /tmp/linux/samples/bpf/xdp2
HOSTCC /tmp/linux/samples/bpf/xdp_router_ipv4_user.o
HOSTLD /tmp/linux/samples/bpf/xdp_router_ipv4
HOSTCC /tmp/linux/samples/bpf/test_current_task_under_cgroup_user.o
HOSTLD /tmp/linux/samples/bpf/test_current_task_under_cgroup
HOSTCC /tmp/linux/samples/bpf/trace_event_user.o
HOSTLD /tmp/linux/samples/bpf/trace_event
HOSTCC /tmp/linux/samples/bpf/sampleip_user.o
HOSTLD /tmp/linux/samples/bpf/sampleip
HOSTCC /tmp/linux/samples/bpf/tc_l2_redirect_user.o
HOSTLD /tmp/linux/samples/bpf/tc_l2_redirect
HOSTCC /tmp/linux/samples/bpf/lwt_len_hist_user.o
HOSTLD /tmp/linux/samples/bpf/lwt_len_hist
HOSTCC /tmp/linux/samples/bpf/xdp_tx_iptunnel_user.o
HOSTLD /tmp/linux/samples/bpf/xdp_tx_iptunnel
HOSTCC /tmp/linux/samples/bpf/test_map_in_map_user.o
HOSTLD /tmp/linux/samples/bpf/test_map_in_map
HOSTCC /tmp/linux/samples/bpf/cookie_uid_helper_example.o
HOSTLD /tmp/linux/samples/bpf/per_socket_stats_example
HOSTCC /tmp/linux/samples/bpf/load_sock_ops.o
HOSTLD /tmp/linux/samples/bpf/load_sock_ops
HOSTCC /tmp/linux/samples/bpf/xdp_redirect_user.o
HOSTLD /tmp/linux/samples/bpf/xdp_redirect
HOSTCC /tmp/linux/samples/bpf/xdp_redirect_map_user.o
HOSTLD /tmp/linux/samples/bpf/xdp_redirect_map
HOSTCC /tmp/linux/samples/bpf/xdp_redirect_cpu_user.o
HOSTLD /tmp/linux/samples/bpf/xdp_redirect_cpu
HOSTCC /tmp/linux/samples/bpf/xdp_monitor_user.o
HOSTLD /tmp/linux/samples/bpf/xdp_monitor
HOSTCC /tmp/linux/samples/bpf/xdp_rxq_info_user.o
HOSTLD /tmp/linux/samples/bpf/xdp_rxq_info
HOSTCC /tmp/linux/samples/bpf/syscall_tp_user.o
HOSTLD /tmp/linux/samples/bpf/syscall_tp
HOSTCC /tmp/linux/samples/bpf/cpustat_user.o
HOSTLD /tmp/linux/samples/bpf/cpustat
HOSTCC /tmp/linux/samples/bpf/xdp_adjust_tail_user.o
HOSTLD /tmp/linux/samples/bpf/xdp_adjust_tail
HOSTCC /tmp/linux/samples/bpf/xdpsock_user.o
HOSTLD /tmp/linux/samples/bpf/xdpsock
HOSTCC /tmp/linux/samples/bpf/xdp_fwd_user.o
HOSTLD /tmp/linux/samples/bpf/xdp_fwd
HOSTCC /tmp/linux/samples/bpf/task_fd_query_user.o
HOSTLD /tmp/linux/samples/bpf/task_fd_query
CC /tmp/linux/samples/bpf/syscall_nrs.s
CLANG-bpf /tmp/linux/samples/bpf/sockex1_kern.o
CLANG-bpf /tmp/linux/samples/bpf/sockex2_kern.o
CLANG-bpf /tmp/linux/samples/bpf/sockex3_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tracex1_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tracex2_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tracex3_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tracex4_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tracex5_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tracex6_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tracex7_kern.o
CLANG-bpf /tmp/linux/samples/bpf/sock_flags_kern.o
CLANG-bpf /tmp/linux/samples/bpf/test_probe_write_user_kern.o
CLANG-bpf /tmp/linux/samples/bpf/trace_output_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tcbpf1_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tc_l2_redirect_kern.o
CLANG-bpf /tmp/linux/samples/bpf/lathist_kern.o
CLANG-bpf /tmp/linux/samples/bpf/offwaketime_kern.o
CLANG-bpf /tmp/linux/samples/bpf/spintest_kern.o
CLANG-bpf /tmp/linux/samples/bpf/map_perf_test_kern.o
CLANG-bpf /tmp/linux/samples/bpf/test_overhead_tp_kern.o
CLANG-bpf /tmp/linux/samples/bpf/test_overhead_raw_tp_kern.o
CLANG-bpf /tmp/linux/samples/bpf/test_overhead_kprobe_kern.o
CLANG-bpf /tmp/linux/samples/bpf/parse_varlen.o
CLANG-bpf /tmp/linux/samples/bpf/parse_simple.o
CLANG-bpf /tmp/linux/samples/bpf/parse_ldabs.o
CLANG-bpf /tmp/linux/samples/bpf/test_cgrp2_tc_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp1_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp2_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp_router_ipv4_kern.o
CLANG-bpf /tmp/linux/samples/bpf/test_current_task_under_cgroup_kern.o
CLANG-bpf /tmp/linux/samples/bpf/trace_event_kern.o
CLANG-bpf /tmp/linux/samples/bpf/sampleip_kern.o
CLANG-bpf /tmp/linux/samples/bpf/lwt_len_hist_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp_tx_iptunnel_kern.o
CLANG-bpf /tmp/linux/samples/bpf/test_map_in_map_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tcp_synrto_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tcp_rwnd_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tcp_bufs_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tcp_cong_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tcp_iw_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tcp_clamp_kern.o
CLANG-bpf /tmp/linux/samples/bpf/tcp_basertt_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp_redirect_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp_redirect_map_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp_redirect_cpu_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp_monitor_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp_rxq_info_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp2skb_meta_kern.o
CLANG-bpf /tmp/linux/samples/bpf/syscall_tp_kern.o
CLANG-bpf /tmp/linux/samples/bpf/cpustat_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp_adjust_tail_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdpsock_kern.o
CLANG-bpf /tmp/linux/samples/bpf/xdp_fwd_kern.o
CLANG-bpf /tmp/linux/samples/bpf/task_fd_query_kern.o
make[1]: Leaving directory '/tmp/linux'
^ permalink raw reply
* Re: [iproute PATCH v2 4/4] lib: Enable colored output only for TTYs
From: David Ahern @ 2018-08-15 16:43 UTC (permalink / raw)
To: Phil Sutter, Stephen Hemminger, netdev, Till Maas
In-Reply-To: <20180815163944.GT32448@orbyte.nwl.cc>
On 8/15/18 10:39 AM, Phil Sutter wrote:
> On Wed, Aug 15, 2018 at 10:24:31AM -0600, David Ahern wrote:
>> On 8/15/18 10:21 AM, Phil Sutter wrote:
>>> Add an additional prerequisite to check_enable_color() to make sure
>>> stdout actually points to an open TTY device. Otherwise calls like
>>>
>>> | ip -color a s >/tmp/foo
>>>
>>> will print color escape sequences into that file. Allow to override this
>>> check by specifying '-color' flag more than once.
>>>
>>> Signed-off-by: Phil Sutter <phil@nwl.cc>
>>> ---
>>> Changes since v1:
>>> - Allow to override isatty() check by specifying '-color' flag more than
>>> once.
>>
>> That adds overhead to my workflow where I almost always have to pipe the
>> output of ip to a pager.
>
> alias ip='ip -color -color'
no. Don't impact existing users.
>
> Another alternative may be to introduce -autocolor flag. Establishing
> the same syntax as used by 'ls' is not as trivial due to the simple
> commandline parsing used in 'ip'.
I disagree with ignoring or overriding an argument a user passes in. You
are guessing what is the correct output and you are guessing wrong.
There is nothing wrong with piping output to a file and the viewing that
file through 'less -R'.
If a user does not want the color codes in the file, then that user can
drop the -color arg. iproute2 commands should not be guessing.
^ permalink raw reply
* Re: [iproute PATCH v2 4/4] lib: Enable colored output only for TTYs
From: Phil Sutter @ 2018-08-15 16:51 UTC (permalink / raw)
To: David Ahern; +Cc: Stephen Hemminger, netdev, Till Maas
In-Reply-To: <0ce24184-cf62-5623-5a7c-b1b32ab8b1c3@gmail.com>
On Wed, Aug 15, 2018 at 10:43:25AM -0600, David Ahern wrote:
> On 8/15/18 10:39 AM, Phil Sutter wrote:
> > On Wed, Aug 15, 2018 at 10:24:31AM -0600, David Ahern wrote:
> >> On 8/15/18 10:21 AM, Phil Sutter wrote:
> >>> Add an additional prerequisite to check_enable_color() to make sure
> >>> stdout actually points to an open TTY device. Otherwise calls like
> >>>
> >>> | ip -color a s >/tmp/foo
> >>>
> >>> will print color escape sequences into that file. Allow to override this
> >>> check by specifying '-color' flag more than once.
> >>>
> >>> Signed-off-by: Phil Sutter <phil@nwl.cc>
> >>> ---
> >>> Changes since v1:
> >>> - Allow to override isatty() check by specifying '-color' flag more than
> >>> once.
> >>
> >> That adds overhead to my workflow where I almost always have to pipe the
> >> output of ip to a pager.
> >
> > alias ip='ip -color -color'
>
> no. Don't impact existing users.
That's a possible fix for *your* workflow. If applied to the shell
handling that workflow, it won't impact existing users.
> > Another alternative may be to introduce -autocolor flag. Establishing
> > the same syntax as used by 'ls' is not as trivial due to the simple
> > commandline parsing used in 'ip'.
>
> I disagree with ignoring or overriding an argument a user passes in. You
> are guessing what is the correct output and you are guessing wrong.
> There is nothing wrong with piping output to a file and the viewing that
> file through 'less -R'.
>
> If a user does not want the color codes in the file, then that user can
> drop the -color arg. iproute2 commands should not be guessing.
OK, I got it. Should I respin the fixes or will you apply the series
partially?
Thanks, Phil
^ permalink raw reply
* Re: [PATCH net-next][RFC] net/tls: Add support for async decryption of tls records
From: Dave Watson @ 2018-08-15 16:55 UTC (permalink / raw)
To: Vakul Garg; +Cc: netdev, borisp, aviadye, davem
In-Reply-To: <20180814141758.4930-1-vakul.garg@nxp.com>
On 08/14/18 07:47 PM, Vakul Garg wrote:
> Incoming TLS records which are directly decrypted into user space
> application buffer i.e. records which are decrypted in zero-copy mode
> are submitted for async decryption. When the decryption cryptoapi
> returns -EINPROGRESS, the next tls record is parsed and then submitted
> for decryption. The references to records which has been sent for async
> decryption are dropped. This happens in a loop for all the records that
> can be decrypted in zero-copy mode. For records for which decryption is
> not possible in zero-copy mode, asynchronous decryption is not used and
> we wait for decryption crypto api to complete.
>
> For crypto requests executing in async fashion, the memory for
> aead_request, sglists and skb etc is freed from the decryption
> completion handler. The decryption completion handler wakesup the
> sleeping user context. This happens when the user context is done
> enqueueing all the crypto requests and is waiting for all the async
> operations to finish. Since the splice() operation does not use
> zero-copy decryption, async remains disabled for splice().
I found it a little hard to understand what you are trying to do based
on the commit message. Reading the code, it looks like if the recv()
spans multiple TLS records, we will start decryption on all of them,
and only wait right before recv() returns, yes? This approach sounds
great to me.
Three of the selftests are failing for me:
[ FAIL ] tls.recv_partial
[ FAIL ] tls.recv_peek
[ FAIL ] tls.recv_peek_multiple
^ permalink raw reply
* Re: [iproute PATCH v2 4/4] lib: Enable colored output only for TTYs
From: David Ahern @ 2018-08-15 16:57 UTC (permalink / raw)
To: Phil Sutter, Stephen Hemminger, netdev, Till Maas
In-Reply-To: <20180815165115.GU32448@orbyte.nwl.cc>
On 8/15/18 10:51 AM, Phil Sutter wrote:
> Should I respin the fixes or will you apply the series
> partially?
Stephen has released 4.18 but not merged -next to master yet, so I
applied the first 3 to -next.
^ permalink raw reply
* Re: [PATCH v1 2/3] zinc: Introduce minimal cryptography library
From: Eric Biggers @ 2018-08-15 19:57 UTC (permalink / raw)
To: D. J. Bernstein
Cc: Jason A. Donenfeld, Eric Biggers, Linux Crypto Mailing List, LKML,
Netdev, David Miller, Andrew Lutomirski, Greg Kroah-Hartman,
Samuel Neves, Tanja Lange, Jean-Philippe Aumasson,
Karthikeyan Bhargavan
In-Reply-To: <20180815162819.22765.qmail@cr.yp.to>
On Wed, Aug 15, 2018 at 04:28:19PM -0000, D. J. Bernstein wrote:
> Eric Biggers writes:
> > I've also written a scalar ChaCha20 implementation (no NEON instructions!) that
> > is 12.2 cpb on one block at a time on Cortex-A7, taking advantage of the free
> > rotates; that would be useful for the single permutation used to compute
> > XChaCha's subkey, and also for the ends of messages.
>
> This is also how ends of messages are handled in the 2012 implementation
> crypto_stream/salsa20/armneon6 (see "mainloop1") inside the SUPERCOP
> benchmarking framework:
>
> https://bench.cr.yp.to/supercop.html
>
> This code is marginally different from Eric's new code because the
> occasional loads and stores are scheduled for the Cortex-A8 rather than
> the Cortex-A7, and because it's Salsa20 rather than ChaCha20.
>
> The bigger picture is that there are 63 implementations of Salsa20 and
> ChaCha20 in SUPERCOP from 10 authors showing various implementation
> techniques, including all the techniques that have been mentioned in
> this thread; and centralized benchmarks on (e.g.)
>
> https://bench.cr.yp.to/results-stream.html#amd64-kizomba
> https://bench.cr.yp.to/web-impl/amd64-kizomba-crypto_stream-salsa20.html
>
> showing what's fastest on various platforms, using well-developed
> benchmarking tools that produce repeatable, meaningful measurements.
> There are also various papers explaining the main techniques.
>
> Of course it's possible that new code will do better, especially on
> platforms with different performance characteristics from the platforms
> previously targeted. Contributing new implementations to SUPERCOP is
> easy---which is why SUPERCOP already has thousands of implementations of
> hundreds of cryptographic functions---and is a more effective way to
> advertise speedups than adding code merely to (e.g.) the Linux kernel.
> Infrastructure is centralized in SUPERCOP to minimize per-implementation
> work. There's no risk of being rejected on the basis of cryptographic
> concerns (MD5, Speck, and RSA-512 are included in the benchmarks) or
> code-style concerns. Users can then decide which implementations best
> meet their requirements.
>
> "Do better" seems to be what's happened for the Cortex-A7. The best
> SUPERCOP speeds (from code targeting the Cortex-A8 etc.) are 13.42
> cycles/byte for 4096 bytes for ChaCha20; 12.2, 11.9, and 11.3 sound
> noticeably better. The Cortex-A7 is an interesting case because it's
> simultaneously (1) widely deployed---more than a billion units sold---
> but (2) poorly documented. If you want to know, e.g., which instructions
> can dual-issue with loads/FPU moves/..., then you won't be able to find
> anything from ARM giving the answer. I've started building an automated
> tool to compute the full CPU pipeline structure from benchmarks, but
> this isn't ready yet.
>
Hi Dan, are you saying I should contribute my scalar ChaCha implementation,
and/or the Linux kernel's ChaCha NEON implementation, to SUPERCOP? Just a few
comments: there doesn't appear to be an official git repository for SUPERCOP,
nor is there any mention of how to send patches, nor is there any COPYING or
LICENSE file, nor even a README file. So, while I'm interested, from my
perspective SUPERCOP doesn't seem friendly to contributions. You'd probably
attract more contributors if you followed established open source conventions.
Another issue is that the ChaCha code in SUPERCOP is duplicated for each number
of rounds: 8, 12, and 20. So if anyone adds a new ChaCha implementation, they'd
apparently have to add 3 copies of it, which isn't very maintainable.
There are actually only two ARM NEON implementations of ChaCha20 in SUPERCOP:
(1) the one in crypto_stream/chacha20/moon/neon/32/chacha.S which looks like an
'objdump' output as it has no comments or anything that would make it readable
like macros and register aliases; and (2) the one in
crypto_stream/chacha20/dolbeau/arm-neon/, which uses a method similar to the
Linux implementation but it uses GCC intrinsics, so its performance will heavily
depend on how the compiler assigns and spills registers, which can vary greatly
depending on the compiler version and options.
I understand that Salsa20 is similar to ChaCha, and that ideas from Salsa20
implementations often apply to ChaCha too. But it's not always obvious what
carries over and what doesn't; the rotation amounts can matter a lot, for
example, as different rotations can be implemented in different ways. Nor is it
always obvious which ideas from SSE2 or AVX2 implementations (for example) carry
over to NEON implementations, as these instruction sets are different enough
that each has its own unique quirks and optimizations.
Previously I also found that OpenSSL's ARM NEON implementation of Poly1305 is
much faster than the implementations in SUPERCOP, as well as more
understandable. (I don't know the 'qhasm' language, for example.) So from my
perspective, I've had more luck with OpenSSL than SUPERCOP when looking for fast
implementations of crypto algorithms. Have you considered adding the OpenSSL
implementations to SUPERCOP?
In the end though, both Linux and OpenSSL don't need every implementation under
the sun, but rather a small number of implementations that provide "good"
performance on nearly all CPUs, while not necessarily being optimal on every CPU
out there. I.e., some tradeoffs are necessary and acceptable. So for
ChaCha{12,20} on ARM we should choose which 2-3 implementations are most
valuable to have and make them as generally well optimized as possible. Based
on the research I've seen and done, I think they're likely to be:
- a 1x_scalar implementation
- a 3x_NEON+1x_scalar implementation like OpenSSL's
- a 4x_NEON implementation like Linux's current one
Currently my main argument is just that having the 3x_NEON+1x_scalar method be
the only NEON implementation is probably insufficient, as there are important
CPUs where the 4x_NEON method is significantly faster.
Thanks,
Eric
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: ravb: Add support for r8a774a1 SoC
From: Rob Herring @ 2018-08-15 20:18 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Mark Rutland, Fabrizio Castro, Sergei Shtylyov, David S. Miller,
Geert Uytterhoeven, Simon Horman, Biju Das, Yoshihiro Shimoda,
netdev, linux-renesas-soc, devicetree, linux-kernel, Simon Horman,
Chris Paterson
In-Reply-To: <1534250017-15725-1-git-send-email-fabrizio.castro@bp.renesas.com>
On Tue, 14 Aug 2018 13:33:37 +0100, Fabrizio Castro wrote:
> Document RZ/G2M (R8A774A1) SoC bindings.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/net/renesas,ravb.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* RE: [PATCH net-next][RFC] net/tls: Add support for async decryption of tls records
From: Vakul Garg @ 2018-08-15 17:29 UTC (permalink / raw)
To: Dave Watson
Cc: netdev@vger.kernel.org, borisp@mellanox.com, aviadye@mellanox.com,
davem@davemloft.net
In-Reply-To: <20180815164548.ikdrxliwtmqdgt3c@davejwatson-mba.local>
> -----Original Message-----
> From: Dave Watson [mailto:davejwatson@fb.com]
> Sent: Wednesday, August 15, 2018 10:26 PM
> To: Vakul Garg <vakul.garg@nxp.com>
> Cc: netdev@vger.kernel.org; borisp@mellanox.com;
> aviadye@mellanox.com; davem@davemloft.net
> Subject: Re: [PATCH net-next][RFC] net/tls: Add support for async decryption
> of tls records
>
> On 08/14/18 07:47 PM, Vakul Garg wrote:
> > Incoming TLS records which are directly decrypted into user space
> > application buffer i.e. records which are decrypted in zero-copy mode
> > are submitted for async decryption. When the decryption cryptoapi
> > returns -EINPROGRESS, the next tls record is parsed and then submitted
> > for decryption. The references to records which has been sent for
> > async decryption are dropped. This happens in a loop for all the
> > records that can be decrypted in zero-copy mode. For records for which
> > decryption is not possible in zero-copy mode, asynchronous decryption
> > is not used and we wait for decryption crypto api to complete.
> >
> > For crypto requests executing in async fashion, the memory for
> > aead_request, sglists and skb etc is freed from the decryption
> > completion handler. The decryption completion handler wakesup the
> > sleeping user context. This happens when the user context is done
> > enqueueing all the crypto requests and is waiting for all the async
> > operations to finish. Since the splice() operation does not use
> > zero-copy decryption, async remains disabled for splice().
>
> I found it a little hard to understand what you are trying to do based on the
> commit message.
Ok, I will rewrite it.
> Reading the code, it looks like if the recv() spans multiple
> TLS records, we will start decryption on all of them, and only wait right
> before recv() returns, yes? This approach sounds great to me.
>
Yes, that's the idea. I am firing as many decryption jobs as possible till I run
out of user application provided buffer space.
> Three of the selftests are failing for me:
>
> [ FAIL ] tls.recv_partial
> [ FAIL ] tls.recv_peek
> [ FAIL ] tls.recv_peek_multiple
Will look into it.
Thanks for spending time in review my patch.
The patch is showing good performance benefits.
^ permalink raw reply
* [PATCH net-next] Documentation: networking: ti-cpsw: correct cbs parameters for Eth1 100Mb
From: Ivan Khoronzhuk @ 2018-08-15 20:29 UTC (permalink / raw)
To: grygorii.strashko, davem
Cc: corbet, netdev, linux-doc, linux-kernel, Ivan Khoronzhuk
If set cbs parameters calculated for 1000Mb, but use on 100Mb port
w/o h/w offload (for cpsw offload it doesn't matter), it works
incorrectly. According to the example and testing board, second port
is 100Mb interface. Correct them on recalculated for 100Mb interface.
It allows to use the same command for CBS software implementation for
board in example.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
Based on net-next/master
Documentation/networking/ti-cpsw.txt | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/networking/ti-cpsw.txt b/Documentation/networking/ti-cpsw.txt
index 67039205bd69..d4d4c0751a09 100644
--- a/Documentation/networking/ti-cpsw.txt
+++ b/Documentation/networking/ti-cpsw.txt
@@ -469,17 +469,18 @@ $ tc -g class show dev eth1
14)
// Set rate for class A - 31 Mbit (tc0, txq2) using CBS Qdisc for Eth1
-// here only idle slope is important, others ignored
+// here only idle slope is important, others ignored, but calculated
+// for interface speed - 100Mb for eth1 port.
// Set it +1 Mb for reserve (important!)
-$ tc qdisc add dev eth1 parent 100:3 cbs locredit -1453 \
-hicredit 47 sendslope -969000 idleslope 31000 offload 1
+$ tc qdisc add dev eth1 parent 100:3 cbs locredit -1035 \
+hicredit 465 sendslope -69000 idleslope 31000 offload 1
net eth1: set FIFO3 bw = 31
15)
// Set rate for class B - 11 Mbit (tc1, txq3) using CBS Qdisc for Eth1
// Set it +1 Mb for reserve (important!)
-$ tc qdisc add dev eth1 parent 100:4 cbs locredit -1483 \
-hicredit 34 sendslope -989000 idleslope 11000 offload 1
+$ tc qdisc add dev eth1 parent 100:4 cbs locredit -1335 \
+hicredit 405 sendslope -89000 idleslope 11000 offload 1
net eth1: set FIFO2 bw = 11
16)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] net: lan743x_ptp: convert to ktime_get_clocktai_ts64
From: Arnd Bergmann @ 2018-08-15 20:33 UTC (permalink / raw)
To: Bryan.Whitehead
Cc: UNGLinuxDriver, David Miller, YueHaibing, Networking,
Linux Kernel Mailing List
In-Reply-To: <90A7E81AE28BAE4CBDDB3B35F187D2644073E9C4@CHN-SV-EXMX02.mchp-main.com>
On Wed, Aug 15, 2018 at 8:03 PM <Bryan.Whitehead@microchip.com> wrote:
>
> >
> > Question: this is the only ptp driver that sets the hardware time to the
> > current system time in TAI. Why does it do that?
>
> This is done when the driver starts up after reset. Otherwise the clock is off by 48 years.
> It seemed to me that the system time was the most appropriate clock to sync to.
> If my reasoning is incorrect, please enlighten me.
I've never worked with PTP, but my understanding from looking at the other
drivers is that the time normally gets set either from another host through the
PTP protocol, or using clock_settime() from user space with the current time.
Arnd
^ permalink raw reply
* RE: [PATCH] net: lan743x_ptp: convert to ktime_get_clocktai_ts64
From: Bryan.Whitehead @ 2018-08-15 20:41 UTC (permalink / raw)
To: arnd; +Cc: UNGLinuxDriver, davem, yuehaibing, netdev, linux-kernel
In-Reply-To: <CAK8P3a0f38ev5E4Zvg_3BS+1UN2NzYSw+dyRHXDwLCWgREXJ6g@mail.gmail.com>
> > > Question: this is the only ptp driver that sets the hardware time to
> > > the current system time in TAI. Why does it do that?
> >
> > This is done when the driver starts up after reset. Otherwise the clock is off
> by 48 years.
> > It seemed to me that the system time was the most appropriate clock to
> sync to.
> > If my reasoning is incorrect, please enlighten me.
>
> I've never worked with PTP, but my understanding from looking at the other
> drivers is that the time normally gets set either from another host through
> the PTP protocol, or using clock_settime() from user space with the current
> time.
Those methods will still work. But if it's not set by those methods, I thought the clock should at least be set once on driver startup to align with the system clock. After that, other methods are free to reset it again.
Bryan
^ permalink raw reply
* Re: [PATCH] net: lan743x_ptp: convert to ktime_get_clocktai_ts64
From: Arnd Bergmann @ 2018-08-15 20:44 UTC (permalink / raw)
To: Bryan.Whitehead
Cc: UNGLinuxDriver, David Miller, YueHaibing, Networking,
Linux Kernel Mailing List, Richard Cochran
In-Reply-To: <90A7E81AE28BAE4CBDDB3B35F187D2644073EA26@CHN-SV-EXMX02.mchp-main.com>
On Wed, Aug 15, 2018 at 10:41 PM <Bryan.Whitehead@microchip.com> wrote:
>
> > > > Question: this is the only ptp driver that sets the hardware time to
> > > > the current system time in TAI. Why does it do that?
> > >
> > > This is done when the driver starts up after reset. Otherwise the clock is off
> > by 48 years.
> > > It seemed to me that the system time was the most appropriate clock to
> > sync to.
> > > If my reasoning is incorrect, please enlighten me.
> >
> > I've never worked with PTP, but my understanding from looking at the other
> > drivers is that the time normally gets set either from another host through
> > the PTP protocol, or using clock_settime() from user space with the current
> > time.
>
> Those methods will still work. But if it's not set by those methods, I thought the
> clock should at least be set once on driver startup to align with the system clock.
> After that, other methods are free to reset it again.
(adding Richard Cochran to Cc for more insight here)
I would argue that it's more important that the driver behaves like all other
PTP implementations. If we want the behavior to be that the initial PTP time is
set to the ktime_get_clocktai_ts64() value, then this should be done by the
PTP core rather than the device driver. If there is a good reason that the
other drivers don't do it like this, then I would assume the same reason applies
to lan743x.
Arnd
^ permalink raw reply
* Re: [RFC PATCH v1 1/3] dt-bindings: net: Add 'mac-address-lookup' property
From: Rob Herring @ 2018-08-15 20:45 UTC (permalink / raw)
To: Brian Norris
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Andrew Lunn,
Florian Fainelli, Dmitry Torokhov, Guenter Roeck, netdev,
devicetree, linux-kernel, Julius Werner, Stephen Boyd,
Brian Norris
In-Reply-To: <20180814223758.117433-2-briannorris@chromium.org>
On Tue, Aug 14, 2018 at 03:37:56PM -0700, Brian Norris wrote:
> Some firmwares present data tables that can be parsed to retrieve
> device-specific details, like MAC addresses. While in some cases, one
> could teach the firmware to understand the device tree format and insert
> a 'mac-address'/'local-mac-address' property into the FDT on its own,
> this method can be brittle (e.g., involving memorizing expected FDT
> structure), and it's not strictly necessary -- especially when parsers
> for such firmware formats are already needed in the OS for other
> reasons.
If you have an 'ethernetN' alias then you don't need to know the
structure. IIRC, that is what u-boot does.
>
> One such format: the Vital Product Data (VPD) [1] used by Coreboot. It
> supports a table of key/value pairs, and some systems keep MAC addresses
> there in a well-known format. Allow a device tree to specify
> (1) that the MAC address for a given device is stored in the VPD table
> and
> (2) what key should be used to retrieve the MAC address for said
> device (e.g., "ethernet_mac0" or "wifi_mac1").
>
> [1] Ref:
> https://chromium.googlesource.com/chromiumos/platform/vpd/+/master/README.md
> TL;DR: VPD consists of a TLV-like table, with key/value pairs of
> strings. This is often stored persistently on the boot flash and
> presented via in-memory Coreboot tables, for the operating system to
> read.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> Documentation/devicetree/bindings/net/ethernet.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/ethernet.txt b/Documentation/devicetree/bindings/net/ethernet.txt
> index cfc376bc977a..d3fd1da18bf4 100644
> --- a/Documentation/devicetree/bindings/net/ethernet.txt
> +++ b/Documentation/devicetree/bindings/net/ethernet.txt
> @@ -4,6 +4,18 @@ NOTE: All 'phy*' properties documented below are Ethernet specific. For the
> generic PHY 'phys' property, see
> Documentation/devicetree/bindings/phy/phy-bindings.txt.
>
> +- mac-address-lookup: string, indicating a method by which a MAC address may be
> + discovered for this device. Methods may be parameterized by some value, such
> + that the method can determine the device's MAC address using that parameter.
> + For example, a firmware might store MAC addresses in a table, keyed by some
> + predetermined string, and baked in read-only flash. A lookup method "foo"
> + with a parameter "bar" should be written "foo:bar".
> + Supported values for method:
> + "google-vpd" - Google's Vital Product Data (VPD), as used in the Coreboot
> + project. Documentation for VPD can be found at:
> + https://chromium.googlesource.com/chromiumos/platform/vpd/+/master/README.md
> + Example:
> + mac-address-lookup = "google-vpd:ethernet_mac0"
This doesn't strike me as a very DT style way of describing this. I
would expect something like a phandle to the VPD and an identifier.
Also, an already common way besides local-mac-address is using nvmem
binding which wouldn't use this and perhaps could be used here? This
feels very much Google specific, not common (and maybe that is fine).
Rob
^ permalink raw reply
* RE: [PATCH] net: lan743x_ptp: convert to ktime_get_clocktai_ts64
From: Bryan.Whitehead @ 2018-08-15 20:50 UTC (permalink / raw)
To: arnd
Cc: UNGLinuxDriver, davem, yuehaibing, netdev, linux-kernel,
richardcochran
In-Reply-To: <CAK8P3a3guebtDLNhbQwNmA2nq=raKiP8ztGRpb03r0XD8h+ZNA@mail.gmail.com>
> > > > > Question: this is the only ptp driver that sets the hardware
> > > > > time to the current system time in TAI. Why does it do that?
> > > >
> > > > This is done when the driver starts up after reset. Otherwise the
> > > > clock is off
> > > by 48 years.
> > > > It seemed to me that the system time was the most appropriate
> > > > clock to
> > > sync to.
> > > > If my reasoning is incorrect, please enlighten me.
> > >
> > > I've never worked with PTP, but my understanding from looking at the
> > > other drivers is that the time normally gets set either from another
> > > host through the PTP protocol, or using clock_settime() from user
> > > space with the current time.
> >
> > Those methods will still work. But if it's not set by those methods, I
> > thought the clock should at least be set once on driver startup to align with
> the system clock.
> > After that, other methods are free to reset it again.
>
> (adding Richard Cochran to Cc for more insight here)
>
> I would argue that it's more important that the driver behaves like all other
> PTP implementations. If we want the behavior to be that the initial PTP time
> is set to the ktime_get_clocktai_ts64() value, then this should be done by the
> PTP core rather than the device driver. If there is a good reason that the
> other drivers don't do it like this, then I would assume the same reason
> applies to lan743x.
>
Sounds reasonable to me. I will yield to Richard's insight.
But it would be nice if requirements like these were documented.
^ permalink raw reply
* Re: [iproute PATCH v2 4/4] lib: Enable colored output only for TTYs
From: Phil Sutter @ 2018-08-15 17:58 UTC (permalink / raw)
To: David Ahern; +Cc: Stephen Hemminger, netdev, Till Maas
In-Reply-To: <e07d82fc-e78d-4100-49a1-3da6fdbd9e92@gmail.com>
On Wed, Aug 15, 2018 at 10:57:13AM -0600, David Ahern wrote:
> On 8/15/18 10:51 AM, Phil Sutter wrote:
> > Should I respin the fixes or will you apply the series
> > partially?
>
> Stephen has released 4.18 but not merged -next to master yet, so I
> applied the first 3 to -next.
OK, thanks!
Cheers, Phil
^ permalink raw reply
* Re: serdev: How to attach serdev devices to USB based tty devices?
From: Sebastian Reichel @ 2018-08-15 18:21 UTC (permalink / raw)
To: Andreas Färber, Johan Hovold
Cc: Rob Herring, linux-serial@vger.kernel.org, linux-usb, Linux-MIPS,
Xue Liu, Ben Whitten, devicetree, netdev@vger.kernel.org,
Oliver Neukum, Alexander Graf, LoRa_Community_Support@semtech.com,
Jian-Hong Pan, Stefan Rehm, linux-arm-kernel@lists.infradead.org
In-Reply-To: <3639955d-5990-1c82-7158-ac07b33c41f2@suse.de>
[-- Attachment #1: Type: text/plain, Size: 5346 bytes --]
Hi,
+cc Johan Hovold <johan@kernel.org>
Johan told me, that he is working on this at ELCE 2017. Also he is
the subsystem maintainer of the USB serial subsystem.
-- Sebastian
On Tue, Aug 14, 2018 at 04:28:20AM +0200, Andreas Färber wrote:
> Hi Rob et al.,
>
> For my LoRa network driver project [1] I have found your serdev
> framework to be a valuable help for dealing with hardware modules
> exposing some textual or binary UART interface.
>
> In particular on arm(64) and mips this allows to define an unlimited
> number of serdev drivers [2] that are associated via their Device Tree
> compatible string and can optionally be configured via DT properties.
>
> And in theory it seems serdev has also grown support for ACPI.
>
> Now, a growing number of vendors are placing such modules on a USB stick
> for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
> cards using their USB pins. While I do not yet have access to such a
> device myself, it is my understanding that devices with USB-UART bridge
> chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
> MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
> will show up as /dev/ttyACMx.
> On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
> information to on-board devices such as MAC address to Ethernet chipset,
> but that does not seem all that useful for passing a serdev child node
> to hot-plugged devices at unpredictable hub/port location (where it
> should not interfere with regular USB-UART cables for debugging), nor
> would it help ACPI based platforms such as x86_64.
>
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.
>
> The obvious solution would of course be if hardware vendors could revise
> their designs to configure FTDI/etc. chips uniquely. I hear that that
> may involve exchanging the chipset, increasing costs, and may impact
> existing drivers. Wouldn't help for devices out there today either.
>
> For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
> so it would seem possible to allocate their own product IDs for SX1301
> and SX1308 respectively to replace the generic STMicroelectronics IDs,
> which the various vendors could offer as firmware updates.
>
> All outside my control though.
>
> Oliver therefore suggested to not mess with USB drivers and instead use
> a line discipline (ldisc). It seems that for example the userspace tool
> slattach takes a tty device and performs an ioctl to switch the generic
> tty device into a special N_SLIP protocol mode, implemented in [4].
>
> However, the existing number of such ldisc modes appears to be below 30,
> with hardly any vendor-specific implementation, so polluting its number
> space seems undesirable? And in some cases I would like to use the same
> protocol implementation over direct UART and over USB, so would like to
> avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.
>
> Long story short, has there been any thinking about a userspace
> interface to attach a given serdev driver to a tty device?
>
> Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
> a DT fragment (!= DT Overlay) with a given USB device dynamically, to
> attach a serdev node with sub-nodes?
>
> Any other ideas how to cleanly solve this?
>
> In some cases we're talking about a "simple" AT-like command interface;
> the picoGW implements a semi-generic USB-SPI bridge that may host a
> choice of 2+ chipsets, which in turn has two further sub-devices with 3+
> chipset choices (theoretically clk output and rx/tx options etc.) each.
> (For the latter I'm thinking we'll need a serdev driver exposing a
> regmap_bus and then implement regmap_bus based versions of the SPI
> drivers like Ben and I refactored SX1257 in [2] last weekend.)
>
> Thanks,
> Andreas
>
> [1] https://patchwork.ozlabs.org/cover/937545/
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next
> [3]
> https://github.com/Lora-net/picoGW_mcu/blob/master/src/usb_cdc/Src/usbd_desc.cpp#L59
> [4]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/slip/slip.c#n1281
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: virtio_net failover and initramfs (was: Re: [PATCH net-next v11 2/5] netvsc: refactor notifier/event handling code to use the failover framework)
From: Samudrala, Sridhar @ 2018-08-15 19:05 UTC (permalink / raw)
To: Siwei Liu, Jiri Pirko, initramfs
Cc: Michael S. Tsirkin, Netdev, vijay.balakrishna, si-wei liu,
liran.alon
In-Reply-To: <CADGSJ22433hWW8O6j__TDX+P-Rwx+YoYR=NzU5ueCPFT2wzUDw@mail.gmail.com>
On 8/14/2018 5:03 PM, Siwei Liu wrote:
> Are we sure all userspace apps skip and ignore slave interfaces by
> just looking at "IFLA_MASTER" attribute?
>
> When STANDBY is enabled on virtio-net, a failover master interface
> will appear, which automatically enslaves the virtio device. But it is
> found out that iSCSI (or any network boot) cannot boot strap over the
> new failover interface together with a standby virtio (without any VF
> or PT device in place).
>
> Dracut (initramfs) ends up with timeout and dropping into emergency shell:
>
> [ 228.170425] dracut-initqueue[377]: Warning: dracut-initqueue
> timeout - starting timeout scripts
> [ 228.171788] dracut-initqueue[377]: Warning: Could not boot.
> Starting Dracut Emergency Shell...
> Generating "/run/initramfs/rdsosreport.txt"
> Entering emergency mode. Exit the shell to continue.
> Type "journalctl" to view system logs.
> You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
> after mounting them and attach it to a bug report.
> dracut:/# ip l sh
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> mode DEFAULT group default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
> state UP mode DEFAULT group default qlen 1000
> link/ether 9a:46:22:ae:33:54 brd ff:ff:ff:ff:ff:ff\
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> master eth0 state UP mode DEFAULT group default qlen 1000
> link/ether 9a:46:22:ae:33:54 brd ff:ff:ff:ff:ff:ff
> dracut:/#
>
> If changing dracut code to ignore eth1 (with IFLA_MASTER attr),
> network boot starts to work.
Does dracut by default tries to use all the interfaces that are UP?
>
> The reason is that dracut has its own means to differentiate virtual
> interfaces for network boot: it does not look at IFLA_MASTER and
> ignores slave interfaces. Instead, users have to provide explicit
> option e.g. bond=eth0,eth1 in the boot line, then dracut would know
> the config and ignore the slave interfaces.
Isn't it possible to specify the interface that should be used for network boot?
>
> However, with automatic creation of failover interface that assumption
> is no longer true. Can we change dracut to ignore all slave interface
> by checking IFLA_MASTER? I don't think so. It has a large impact to
> existing configs.
What is the issue with checking for IFLA_MASTER? I guess this is used with
team/bonding setups.
>
> What's a feasible solution then? Check the driver name for failover as well?
>
> Thanks,
> -Siwei
>
>
>
> On Tue, May 22, 2018 at 10:38 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Tue, May 22, 2018 at 06:52:21PM CEST, mst@redhat.com wrote:
>>> On Tue, May 22, 2018 at 05:45:01PM +0200, Jiri Pirko wrote:
>>>> Tue, May 22, 2018 at 05:32:30PM CEST, mst@redhat.com wrote:
>>>>> On Tue, May 22, 2018 at 05:13:43PM +0200, Jiri Pirko wrote:
>>>>>> Tue, May 22, 2018 at 03:39:33PM CEST, mst@redhat.com wrote:
>>>>>>> On Tue, May 22, 2018 at 03:26:26PM +0200, Jiri Pirko wrote:
>>>>>>>> Tue, May 22, 2018 at 03:17:37PM CEST, mst@redhat.com wrote:
>>>>>>>>> On Tue, May 22, 2018 at 03:14:22PM +0200, Jiri Pirko wrote:
>>>>>>>>>> Tue, May 22, 2018 at 03:12:40PM CEST, mst@redhat.com wrote:
>>>>>>>>>>> On Tue, May 22, 2018 at 11:08:53AM +0200, Jiri Pirko wrote:
>>>>>>>>>>>> Tue, May 22, 2018 at 11:06:37AM CEST, jiri@resnulli.us wrote:
>>>>>>>>>>>>> Tue, May 22, 2018 at 04:06:18AM CEST, sridhar.samudrala@intel.com wrote:
>>>>>>>>>>>>>> Use the registration/notification framework supported by the generic
>>>>>>>>>>>>>> failover infrastructure.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>>>>>>>>>>>>> In previous patchset versions, the common code did
>>>>>>>>>>>>> netdev_rx_handler_register() and netdev_upper_dev_link() etc
>>>>>>>>>>>>> (netvsc_vf_join()). Now, this is still done in netvsc. Why?
>>>>>>>>>>>>>
>>>>>>>>>>>>> This should be part of the common "failover" code.
>>>>>>>>>>>>>
>>>>>>>>>>>> Also note that in the current patchset you use IFF_FAILOVER flag for
>>>>>>>>>>>> master, yet for the slave you use IFF_SLAVE. That is wrong.
>>>>>>>>>>>> IFF_FAILOVER_SLAVE should be used.
>>>>>>>>>>> Or drop IFF_FAILOVER_SLAVE and set both IFF_FAILOVER and IFF_SLAVE?
>>>>>>>>>> No. IFF_SLAVE is for bonding.
>>>>>>>>> What breaks if we reuse it for failover?
>>>>>>>> This is exposed to userspace. IFF_SLAVE is expected for bonding slaves.
>>>>>>>> And failover slave is not a bonding slave.
>>>>>>> That does not really answer the question. I'd claim it's sufficiently
>>>>>>> like a bond slave for IFF_SLAVE to make sense.
>>>>>>>
>>>>>>> In fact you will find that netvsc already sets IFF_SLAVE, and so
>>>>>> netvsc does the whole failover thing in a wrong way. This patchset is
>>>>>> trying to fix it.
>>>>> Maybe, but we don't need gratuitous changes either, especially if they
>>>>> break userspace.
>>>> What do you mean by the "break"? It was a mistake to reuse IFF_SLAVE at
>>>> the first place, lets fix it. If some userspace depends on that flag, it
>>>> is broken anyway.
>>>>
>>>>
>>>>>>> does e.g. the eql driver.
>>>>>>>
>>>>>>> The advantage of using IFF_SLAVE is that userspace knows to skip it. If
>>>>>> The userspace should know how to skip other types of slaves - team,
>>>>>> bridge, ovs, etc.
>>>>>> The "master link" should be the one to look at.
>>>>>>
>>>>> How should existing userspace know which ones to skip and which one is
>>>>> the master? Right now userspace seems to assume whatever does not have
>>>>> IFF_SLAVE should be looked at. Are you saying that's not the right thing
>>>> Why do you say so? What do you mean by "looked at"? Certainly not.
>>>> IFLA_MASTER is the attribute that should be looked at, nothing else.
>>>>
>>>>
>>>>> to do and userspace should be fixed? What should userspace do in
>>>>> your opinion that will be forward compatible with future kernels?
>>>>>
>>>>>>> we don't set IFF_SLAVE existing userspace tries to use the lowerdev.
>>>>>> Each master type has a IFF_ master flag and IFF_ slave flag.
>>>>> Could you give some examples please?
>>>> enum netdev_priv_flags {
>>>> IFF_EBRIDGE = 1<<1,
>>>> IFF_BRIDGE_PORT = 1<<9,
>>>> IFF_OPENVSWITCH = 1<<20,
>>>> IFF_OVS_DATAPATH = 1<<10,
>>>> IFF_L3MDEV_MASTER = 1<<18,
>>>> IFF_L3MDEV_SLAVE = 1<<21,
>>>> IFF_TEAM = 1<<22,
>>>> IFF_TEAM_PORT = 1<<13,
>>>> };
>>> That's not in uapi, is it? the comment above that says:
>> Correct.
>>
>>
>>> These flags are invisible to userspace
>>>
>>>
>>>
>>>>>> In private
>>>>>> flag. I don't see no reason to break this pattern here.
>>>>> Other masters are setup from userspace, this one is set up automatically
>>>>> by kernel. So the bar is higher, we need an interface that existing
>>>>> userspace knows about. We can't just say "oh if userspace set this up
>>>>> it should know to skip lowerdevs".
>>>>>
>>>>> Otherwise multiple interfaces with same mac tend to confuse userspace.
>>>> No difference, really.
>>>> Regardless who does the setup, and independent userspace deamon should
>>>> react accordingly.
>>> If the deamon does the setup itself, it's reasonable to require that it
>>> learns about new flags each time we add a new driver. If it doesn't,
>>> then I think it's less reasonable.
>> No need. The "IFLA_MASTER" attr is always there to be looked at. That is
>> enough.
^ permalink raw reply
* Re: [RFC PATCH v1 0/3] device property: Support MAC address in VPD
From: Stephen Boyd @ 2018-08-15 22:07 UTC (permalink / raw)
To: Brian Norris, Florian Fainelli
Cc: Rob Herring, Greg Kroah-Hartman, Rafael J. Wysocki, Andrew Lunn,
Dmitry Torokhov, Guenter Roeck, netdev, devicetree, linux-kernel,
Julius Werner, Brian Norris, Srinivas Kandagatla
In-Reply-To: <20180815014436.GA17200@ban.mtv.corp.google.com>
Quoting Brian Norris (2018-08-14 18:44:36)
> Hi,
>
> On Tue, Aug 14, 2018 at 05:52:49PM -0700, Florian Fainelli wrote:
> > On 08/14/2018 05:22 PM, Brian Norris wrote:
>
> > >> Also, aliases in DT are meant to provide some stability.
> > >
> > > How, specifically? I don't see any relevant binding description for
> > > aliases under Documentation/devicetree/bindings/net/.
> >
> > Indeed they are not, likewise, we should probably update devicetree-spec
> > to come up with standard names that of_alias_get_id() already consumes.
>
> A quick grep shows we already have divergence: both "eth" and "ethernet"
> are in use.
>
> But anyway, would the idea be that you just put 'ethernet{0,1,...}' and
> 'wifi{0,1,...}' aliases in the /chosen node, then require boot firmware
> to insert any {ethernet,wifi}_mac{0,1,...} into the paths represented by
> the corresponding aliases? I suppose that would reduce the problems with
> (1), but it still doesn't really help with (2).
Yes. Aliases are the way to do this. It obviates much of this discussion
about finding things in DT by directly pointing to the node the
bootloader wants to go modify.
> > >
> > > And finally, this may be surmountable, but the existing APIs seem very
> > > device tree centric. We use this same format on ACPI systems, and the
> > > current series would theoretically work on both [1]. I'd have to rewrite
> > > the current (OF-only) helpers to get equivalent support...
Where does it go on ACPI systems? Does the firmware stick it into some
ACPI table by reading from VPD?
^ permalink raw reply
* [PATCH] isdn: Disable IIOCDBGVAR
From: Kees Cook @ 2018-08-15 19:14 UTC (permalink / raw)
To: David S. Miller; +Cc: Al Viro, Karsten Keil, linux-kernel, netdev
It was possible to directly leak the kernel address where the isdn_dev
structure pointer was stored. This is a kernel ASLR bypass for anyone
with access to the ioctl. The code had been present since the beginning
of git history, though this shouldn't ever be needed for normal operation,
therefore remove it.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Karsten Keil <isdn@linux-pingi.de>
Signed-off-by: Kees Cook <keescook@chromium.org>
---
netdev doesn't like explict stable markings, so I'll just ask here that it
get included in -stable please. :)
---
drivers/isdn/i4l/isdn_common.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/isdn/i4l/isdn_common.c b/drivers/isdn/i4l/isdn_common.c
index 7a501dbe7123..6a5b3f00f9ad 100644
--- a/drivers/isdn/i4l/isdn_common.c
+++ b/drivers/isdn/i4l/isdn_common.c
@@ -1640,13 +1640,7 @@ isdn_ioctl(struct file *file, uint cmd, ulong arg)
} else
return -EINVAL;
case IIOCDBGVAR:
- if (arg) {
- if (copy_to_user(argp, &dev, sizeof(ulong)))
- return -EFAULT;
- return 0;
- } else
- return -EINVAL;
- break;
+ return -EINVAL;
default:
if ((cmd & IIOCDRVCTL) == IIOCDRVCTL)
cmd = ((cmd >> _IOC_NRSHIFT) & _IOC_NRMASK) & ISDN_DRVIOCTL_MASK;
--
2.17.1
--
Kees Cook
Pixel Security
^ permalink raw reply related
* Re: [RFC PATCH v1 0/3] device property: Support MAC address in VPD
From: Rob Herring @ 2018-08-15 22:16 UTC (permalink / raw)
To: Brian Norris
Cc: Florian Fainelli, Greg Kroah-Hartman, Rafael J. Wysocki,
Andrew Lunn, Dmitry Torokhov, Guenter Roeck, netdev, devicetree,
linux-kernel, Julius Werner, Stephen Boyd, Brian Norris,
Srinivas Kandagatla
In-Reply-To: <20180815014436.GA17200@ban.mtv.corp.google.com>
On Tue, Aug 14, 2018 at 06:44:36PM -0700, Brian Norris wrote:
> Hi,
I should have read the rest of this thread first...
>
> On Tue, Aug 14, 2018 at 05:52:49PM -0700, Florian Fainelli wrote:
> > On 08/14/2018 05:22 PM, Brian Norris wrote:
> > > * in any of the above (and in any other case of lack of clarity), one
> > > can make slightly different choices when, e.g., submitting a device
> > > tree upstream vs. a downstream tree. While we may try our hardest to
> > > document and stick to documented bindings, I personally can't
> > > guarantee that one of these choices will be made differently during
> > > review, possibly breaking any firmware that made assumptions based on
> > > those choices. So I might end up with a firmware that satisfies
> > > documented bindings and works with a downstream device tree, but
> > > doesn't work with a device tree that gets submitted upstream.
> >
> > Sure, this is kind of a self inflicted problem but agreed this does exist.
>
> You can say "self-inflicted", but of all the things that need to go
> upstream, the DTS files themselves are the least integral. I mean, why
> else do we ever pretend to have anything close to an ABI for device
> tree bindings?
That sounds like an inadequately documented binding.
>
> > >> Also, aliases in DT are meant to provide some stability.
> > >
> > > How, specifically? I don't see any relevant binding description for
> > > aliases under Documentation/devicetree/bindings/net/.
> >
> > Indeed they are not, likewise, we should probably update devicetree-spec
> > to come up with standard names that of_alias_get_id() already consumes.
>
> A quick grep shows we already have divergence: both "eth" and "ethernet"
> are in use.
Uggg, it would be nice to clean that up.
There's several aliases I'd like to get rid of (some platforms went a
little crazy with them) and I'd like to start requiring alias names to
be documented. I created an issue for the spec. Patches welcomeTM. :)
> But anyway, would the idea be that you just put 'ethernet{0,1,...}' and
> 'wifi{0,1,...}' aliases in the /chosen node, then require boot firmware
> to insert any {ethernet,wifi}_mac{0,1,...} into the paths represented by
> the corresponding aliases?
In the /aliases node, but yes.
> I suppose that would reduce the problems with
> (1), but it still doesn't really help with (2).
>
> In some circles, the gold standard of boot firmware is to be as thin as
> possible, doing only what's needed to get a kernel up and running, and
> this function seems wholly unrelated to the firmware's core
> functionality. I mean, the kernel already knows how to parse VPD, so why
> can't it learn to find the right field?
>
> > >>> (2) Other than this device-tree shim requirement, system firmware may
> > >>> have no reason to understand anything about network devices.
> > >>>
> > >>> So instead, I'm looking for a way to have a device node describe where
> > >>> to find its MAC address, rather than having the device node contain the
> > >>> MAC address directly. Then system firmware doesn't have to manage
> > >>> anything.
> > >>>
> > >>> In particular, I add support for the Google Vital Product Data (VPD)
> > >>> format, used within the Coreboot project. The format is described here:
> > >>>
> > >>> https://chromium.googlesource.com/chromiumos/platform/vpd/+/master/README.md
> > >>>
> > >>> TL;DR: VPD consists of a TLV-like table, with key/value pairs of
> > >>> strings. This is often stored persistently on the boot flash and
> > >>> presented via in-memory Coreboot tables, for the operating system to
> > >>> read.
> > >>>
> > >>> We already have a VPD driver that parses this table and presents it to
> > >>> user space. This series extends that driver to allow in-kernel lookups
> > >>> of MAC address entries.
> > >>
> > >> A possible alternative approach is to have the VPD driver become a NVMEM
> > >> producer to expose the VPD keys, did you look into that and possibly
> > >> found that it was not a good model? The downside to that approach though
> > >> is that you might have to have a phandle for the VPD provider in the
> > >> Device Tree, but AFAICS this should solve your needs?
> > >
> > > I did notice some NVMEM work. The MTD links you point at shouldn't be
> > > relevant, since this table is already present in RAM. But I suppose I
> > > could shoehorn the memory table into being a fake NVMEM...
> > >
> > > And then, how would you recommend doing the parameterization I note
> > > here? Is the expectation that I define a new cell for every single type?
> > > Each cell might have a different binary format, so I'd have to describe:
> > > (a) that they contain MAC addresses (so the "reader" knows to translate
> > > the ASCII strings into equivalent binary representation) and
> >
> > I see, in your current patch series that knowledge is pushed to both the
> > VPD producer and the specific object lookup function, so this scales better.
>
> Yeah, one of the advantages is that my API is specialized to exactly one
> data type ;) With the nvmem API, the data format isn't really specified,
> so you gotta hope that either the NVMEM stores MAC addresses as 6 bytes
> of binary data, or else that the NVMEM driver figures out how to do any
> translation for you implicitly.
>
> If I understand the NVMEM subsystem correctly, that is.
>
> > > (b) which key matches (it's not just "mac_address=xxxxx"; there may be
> > > many MAC addresses, with keys "ether_mac0", "ether_mac1",
> > > "wifi_mac0")
> >
> > The key to lookup is definitively node specific, it is just unfortunate
> > that there is not a better way to infer which key to lookup for (as
> > opposed to just having to specify it directly) based on the Device Tree
> > topology. By that I mean, if you have a "mac-address-lookup" property
> > associated with Wi-Fi adapter #1 (with numbering starting at 0), then
> > this automatically means looking up for "wifi_mac1", etc.
>
> Would that really be a virtue, though? Keys can really be anything (in
> VPD, or in any other hypothetical MAC address store), and it seems nice
> to avoid entangling them with device tree specifics too much. And how
> does one figure out what's Device 0 anyway? Based on the FDT layout? I
> don't actually know what order 'dtc' puts my nodes in.
>
> > > Part (a) especially doesn't really sound like the typical NVMEM, which
> > > seems to pretend it provides raw access to these memory regions.
> > >
> > > Additionally, VPD is not stored at a fixed address, nor are any
> > > particular entries within it (it uses TLV), so it seems like there are
> > > plenty of other bits of the nvmem.txt documentation I'd have to violate
> > > to get there, such as the definition of 'reg':
> > >
> > > reg: specifies the offset in byte within the storage device.
> > >
> > > And finally, this may be surmountable, but the existing APIs seem very
> > > device tree centric. We use this same format on ACPI systems, and the
> > > current series would theoretically work on both [1]. I'd have to rewrite
> > > the current (OF-only) helpers to get equivalent support...
> >
> > All fair points, never mind NVMEM, I was just too keen on thinking this
> > would be finally the way to make the consumers and producers of such
> > information into a single API, but your proposal appears valid too.
>
> I don't want to throw out any notion of unification from the start, but
> I don't immediately see how one would do that reasonably. I'm still open
> to education though, and I'm definitely not wedded to my specific
> proposal.
Seems to me that nvmem needs to be extended to allow providers to
retrieve and interpret data. Not everything is at some fixed offset and
size. Something like this is valid dts:
nvmem = <&phandle> "a-string";
But that's pretty uncommon (I can't think of a binding that actually
uses that). Perhaps the provider has an array of keys defined and the
consumer just provides the index.
Or we could do '<key>-nvmem = <&phandle>', but parsing that is a bit
more complicated.
Rob
^ permalink raw reply
* Re: [iproute PATCH v2 4/4] lib: Enable colored output only for TTYs
From: Stephen Hemminger @ 2018-08-15 19:30 UTC (permalink / raw)
To: Phil Sutter; +Cc: David Ahern, netdev, Till Maas
In-Reply-To: <20180815165115.GU32448@orbyte.nwl.cc>
On Wed, 15 Aug 2018 18:51:15 +0200
Phil Sutter <phil@nwl.cc> wrote:
> On Wed, Aug 15, 2018 at 10:43:25AM -0600, David Ahern wrote:
> > On 8/15/18 10:39 AM, Phil Sutter wrote:
> > > On Wed, Aug 15, 2018 at 10:24:31AM -0600, David Ahern wrote:
> > >> On 8/15/18 10:21 AM, Phil Sutter wrote:
> > >>> Add an additional prerequisite to check_enable_color() to make sure
> > >>> stdout actually points to an open TTY device. Otherwise calls like
> > >>>
> > >>> | ip -color a s >/tmp/foo
> > >>>
> > >>> will print color escape sequences into that file. Allow to override this
> > >>> check by specifying '-color' flag more than once.
> > >>>
> > >>> Signed-off-by: Phil Sutter <phil@nwl.cc>
> > >>> ---
> > >>> Changes since v1:
> > >>> - Allow to override isatty() check by specifying '-color' flag more than
> > >>> once.
> > >>
> > >> That adds overhead to my workflow where I almost always have to pipe the
> > >> output of ip to a pager.
> > >
> > > alias ip='ip -color -color'
> >
> > no. Don't impact existing users.
>
> That's a possible fix for *your* workflow. If applied to the shell
> handling that workflow, it won't impact existing users.
>
> > > Another alternative may be to introduce -autocolor flag. Establishing
> > > the same syntax as used by 'ls' is not as trivial due to the simple
> > > commandline parsing used in 'ip'.
> >
> > I disagree with ignoring or overriding an argument a user passes in. You
> > are guessing what is the correct output and you are guessing wrong.
> > There is nothing wrong with piping output to a file and the viewing that
> > file through 'less -R'.
> >
> > If a user does not want the color codes in the file, then that user can
> > drop the -color arg. iproute2 commands should not be guessing.
>
> OK, I got it. Should I respin the fixes or will you apply the series
> partially?
>
> Thanks, Phil
Please follow the color conventions of grep and ls to have
consistent user experience.
-c == --color=always
and add never and auto.
^ permalink raw reply
* Re: serdev: How to attach serdev devices to USB based tty devices?
From: Rob Herring @ 2018-08-15 19:53 UTC (permalink / raw)
To: Andreas Färber
Cc: open list:SERIAL DRIVERS, Linux USB List,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Linux-MIPS, rehm, Xue Liu, LoRa_Community_Support, oneukum,
Alexander Graf, Ben Whitten, devicetree, starnight, netdev,
Johan Hovold
In-Reply-To: <3639955d-5990-1c82-7158-ac07b33c41f2@suse.de>
On Mon, Aug 13, 2018 at 8:28 PM Andreas Färber <afaerber@suse.de> wrote:
>
> Hi Rob et al.,
>
> For my LoRa network driver project [1] I have found your serdev
> framework to be a valuable help for dealing with hardware modules
> exposing some textual or binary UART interface.
>
> In particular on arm(64) and mips this allows to define an unlimited
> number of serdev drivers [2] that are associated via their Device Tree
> compatible string and can optionally be configured via DT properties.
>
> And in theory it seems serdev has also grown support for ACPI.
>
> Now, a growing number of vendors are placing such modules on a USB stick
> for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
> cards using their USB pins. While I do not yet have access to such a
> device myself, it is my understanding that devices with USB-UART bridge
> chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
> MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
> will show up as /dev/ttyACMx.
> On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
> information to on-board devices such as MAC address to Ethernet chipset,
> but that does not seem all that useful for passing a serdev child node
> to hot-plugged devices at unpredictable hub/port location (where it
> should not interfere with regular USB-UART cables for debugging), nor
> would it help ACPI based platforms such as x86_64.
>
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.
>
> The obvious solution would of course be if hardware vendors could revise
> their designs to configure FTDI/etc. chips uniquely. I hear that that
> may involve exchanging the chipset, increasing costs, and may impact
> existing drivers. Wouldn't help for devices out there today either.
>
> For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
> so it would seem possible to allocate their own product IDs for SX1301
> and SX1308 respectively to replace the generic STMicroelectronics IDs,
> which the various vendors could offer as firmware updates.
>
> All outside my control though.
>
> Oliver therefore suggested to not mess with USB drivers and instead use
> a line discipline (ldisc). It seems that for example the userspace tool
> slattach takes a tty device and performs an ioctl to switch the generic
> tty device into a special N_SLIP protocol mode, implemented in [4].
>
> However, the existing number of such ldisc modes appears to be below 30,
> with hardly any vendor-specific implementation, so polluting its number
> space seems undesirable? And in some cases I would like to use the same
> protocol implementation over direct UART and over USB, so would like to
> avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.
>
> Long story short, has there been any thinking about a userspace
> interface to attach a given serdev driver to a tty device?
There was this[1] posted.
The main problem is the only way we know to instantiate a serdev ctrlr
is if there's a slave device described. I did make a series[2] that
makes serdev and tty device co-exist. Then you can more easily
manually attach a device. The problems are you get mismatches in
opens/closes in the tty layer and what should the behavior be if
userspace is trying to access the same port via both the tty and
serdev. After breaking things last time I touched tty open and close,
I'm hesitant to do that again. :)
> Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
> a DT fragment (!= DT Overlay) with a given USB device dynamically, to
> attach a serdev node with sub-nodes?
There's been some discussions but no real progress. I think we need to
be able to support multiple DT roots and then assign/apply DTs to
arbitrary devices. That's first going to require that of_root is not
exposed outside of drivers/of/ and then there could be some issues
with assuming root==NULL is the base of the single DT. Beyond that, I
haven't given it too much thought.
An alternative is we create DT nodes for all devices which don't have
them (or only certain buses) and then we can apply overlays. This is
kind of headed down the path of doing an OpenFirmware implementation
which would enumerate all the devices and pass that DT to the OS.
Rob
[1] https://www.spinics.net/lists/linux-serial/msg30732.html
[2] https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/log/?h=serdev-ldisc-v2
^ 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