This patch updates the dt-bindings for lan966x switch.
It adds the properties 'additionalProperties' and
'unevaluatedProperties' for ethernet-ports and ports nodes. In this way
it is not possible to add more properties to these nodes.
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Clean and improve port definition for qca8k documentation by referencing
the dsa generic port definition and adding the additional specific port
definition.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some switch may require to add additional binding to the node port.
Move DSA generic port definition to a dedicated yaml to permit this.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
LLVM versions prior to 11.0.0 have a harder time with dead code
elimination, which can cause issues with commonly used expressions such
as BUILD_BUG_ON and the bitmask functions/macros in bitfield.h (see the
first two issues links below).
Whenever there is an issue within LLVM that has been resolved in a later
release, the only course of action is to gate the problematic
configuration or source code on the toolchain verson or raise the
minimum supported version of LLVM for building the kernel, as LLVM has a
limited support lifetime compared to GCC. GCC major releases will
typically see a few point releases across a two year period on average
whereas LLVM major releases are only supported until the next major
release and will only see one or two point releases within that
timeframe. For example, GCC 8.1 was released in May 2018 and GCC 8.5 was
released in May 2021, whereas LLVM 12.0.0 was released in April 2021 and
its only point release, 12.0.1, was released in July 2021, giving a
minimal window for fixes to be backported.
To resolve these build errors around improper dead code elimination,
raise the minimum supported version of LLVM for building the kernel to
11.0.0. Doing so is a more proper solution than mucking around with core
kernel macros that have always worked with GCC or disabling drivers for
using these macros in a proper manner. This type of issue may continue
to crop up and require patching, which creates more debt for bumping the
minimum supported version in the future.
This should have a minimal impact to distributions. Using a script to
pull several different Docker images and check the output of
'clang --version':
archlinux:latest: clang version 13.0.0
debian:oldoldstable-slim: clang version 3.8.1-24 (tags/RELEASE_381/final)
debian:oldstable-slim: clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final)
debian:stable-slim: Debian clang version 11.0.1-2
debian:testing-slim: Debian clang version 11.1.0-4
debian:unstable-slim: Debian clang version 11.1.0-4
fedora:34: clang version 12.0.1 (Fedora 12.0.1-1.fc34)
fedora:latest: clang version 13.0.0 (Fedora 13.0.0-3.fc35)
fedora:rawhide: clang version 13.0.0 (Fedora 13.0.0-5.fc36)
opensuse/leap:15.2: clang version 9.0.1
opensuse/leap:latest: clang version 11.0.1
opensuse/tumbleweed:latest: clang version 13.0.0
ubuntu:bionic: clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
ubuntu:latest: clang version 10.0.0-4ubuntu1
ubuntu:hirsute: Ubuntu clang version 12.0.0-3ubuntu1~21.04.2
ubuntu:rolling: Ubuntu clang version 13.0.0-2
ubuntu:devel: Ubuntu clang version 13.0.0-9
In every case, the distribution's version of clang is either older than
the current minimum supported version of LLVM 10.0.1 or equal to or
greater than the proposed 11.0.0 so nothing should change.
Another benefit of this change is LLVM=1 works better with arm64 and
x86_64 since commit f12b034afe ("scripts/Makefile.clang: default to
LLVM_IAS=1") enabled the integrated assembler by default, which only
works well with clang 11+ (clang-10 required it to be disabled to
successfully build a kernel).
Link: https://github.com/ClangBuiltLinux/linux/issues/1293
Link: https://github.com/ClangBuiltLinux/linux/issues/1506
Link: https://github.com/ClangBuiltLinux/linux/issues/1511
Link: fa496ce3c6
Link: https://groups.google.com/g/clang-built-linux/c/mPQb9_ZWW0s/m/W7o6S-QTBAAJ
Link: https://github.com/ClangBuiltLinux/misc-scripts
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Both are already used by HW and drivers inside Linux.
Fix warnings as:
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var2.dt.yaml: ethernet@0,2: fixed-link:speed:0:0: 2500 is not one of [10, 100, 1000]
From schema: Documentation/devicetree/bindings/net/ethernet-controller.yaml
Signed-off-by: David Heidelberg <david@ixit.cz>
Link: https://lore.kernel.org/r/20211124202046.81136-1-david@ixit.cz
Signed-off-by: Rob Herring <robh@kernel.org>
Few Texas Instruments DC-DC converters on PMBus like TPS544B20 do not
have bindings and are used only as hardware monitoring sensor. These
devices are actually not trivial and can receive basic configuration
(e.g. power up mode, CNTL pin polarity, expected input voltage), however
devicetree support for configuration was never added.
Therefore in current state the devices are used only in read-only mode
and have trivial bindings, so document them to have basic dtschema
tests.
Cc: Vincent Pelletier <plr.vincent@gmail.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20211116110207.68494-1-krzysztof.kozlowski@canonical.com
Signed-off-by: Rob Herring <robh@kernel.org>
As the definition of struct cpufreq_freqs has changed, update core.rst
with the new first member of struct cpufreq_freqs.
Signed-off-by: Tang Yizhou <tangyizhou@huawei.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The TI K3 J721S2 SoCs have two TMS320C71x DSP subsystems, and does not
have any TMS320C66x DSP subsystems. The C71x DSP subsystem in J721S2
SoCs is a similar to the C71x DSP on J721e with some minor core IP updates.
Compatible info is updated for intuitvely matching to the new J721S2
SoCs.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211122122726.8532-3-hnagalla@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
The TI K3 J721S2 SoCs have three dual-core Arm R5F clusters/subsystems,
with 2 R5F cores each, one in MCU voltage domain and the other two in
MAIN voltage domain.
These clusters are similar to J7200 R5F clusters. Compatible info is
updated for intuitively matching to the new J721S2 SoCs.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211122122726.8532-2-hnagalla@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
The spi-peripheral-props.yaml schema contains peripheral-specific
properties for SPI controllers that should be present in the peripheral
node. Add a reference to that so its constraints are followed.
additionalProperties: false cannot be used since it marks the controller
properties as unknown. Use unevaluatedProperties: false instead. This
has the side effect of allowing extra properties that are not specified
in the schema. The alternative is to list all the controller properties
in this schema but that would mean every peripheral binding would have
to repeat the same set of properties for each controller.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211109181911.2251-4-p.yadav@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The spi-peripheral-props.yaml schema contains peripheral-specific
properties for SPI controllers that should be present in the peripheral
node. Move peripheral-specific properties to a separate file and refer
to it in spi-peripheral-props.yaml.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211109181911.2251-3-p.yadav@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Many SPI controllers need to add properties to peripheral devices. This
could be the delay in clock or data lines, etc. These properties are
controller specific but need to be defined in the peripheral node
because they are per-peripheral and there can be multiple peripherals
attached to a controller.
If these properties are not added to the peripheral binding, then the
dtbs check emits a warning. But these properties do not make much sense
in the peripheral binding because they are controller-specific and they
will just pollute every peripheral binding. So this binding is added to
collect all such properties from all such controllers. Peripheral
bindings should simply refer to this binding and they should be rid of
the warnings.
There are some limitations with this approach. Firstly, there is no way
to specify required properties. The schema contains properties for all
controllers and there is no way to know which controller is being used.
Secondly, there is no way to restrict additional properties. Since this
schema will be used with an allOf operator, additionalProperties needs
to be true. In addition, the peripheral schema will have to set
unevaluatedProperties: false.
Despite these limitations, this appears to be the best solution to this
problem that doesn't involve modifying existing tools or schema specs.
Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211109181911.2251-2-p.yadav@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
To improve human readability and enable automatic validation, the tuples
in "interrupts" properties should be grouped using angle brackets.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
All of the uses of CONFIG_RCU_FAST_NO_HZ=y that I have seen involve
systems with RCU callbacks offloaded. In this situation, all that this
Kconfig option does is slow down idle entry/exit with an additional
allways-taken early exit. If this is the only use case, then this
Kconfig option nothing but an attractive nuisance that needs to go away.
This commit therefore removes the RCU_FAST_NO_HZ Kconfig option.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
On Ubuntu Focal, strings in some of SVG files under
Documentation/RCU/Design can not be rendered properly when
converted to PDF.
Ubuntu releases since Focal and Debian bullseye have trouble
with "Symbol" font-family in SVG files.
As those strings are mostly API names such as "READ_ONCE()",
"WRITE_ONCE(), "rcu_read_lock()", and so on, using a generic
monospace font-family should be a good alternative.
Substitute the font-family name by a simple sed pattern:
's/Symbol/monospace/g'
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
The reader-writer-lock analogy is a useful way to think about RCU, but
it is not always applicable. It is useful to have other analogies to
work with, and particularly to emphasise that no single analogy is
perfect.
This patch add a "RCU as reference count" to the "what is RCU" document.
See https://lwn.net/Articles/872559/
[ paulmck: Apply Akira Yokosawa feedback. ]
Reviewed-by: Akira Yokosawa <akiyks@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
This document advises building with both CONFIG_NO_HZ=y and
CONFIG_RCU_FAST_NO_HZ=y. However, CONFIG_NO_HZ=y offloads callbacks from
all nohz_full CPUs, and CPUs with offloaded callbacks do not benefit from
CONFIG_RCU_FAST_NO_HZ=y. Quite the opposite: CONFIG_RCU_FAST_NO_HZ=y
simply adds a bit of idle entry/exit overhead.
This commit therefore changes that advice to only CONFIG_NO_HZ=y.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
With the previous patch, there is an extra watchdog read in each retry.
Now the total number of clocksource reads is increased to 4 per iteration.
In order to avoid increasing the clock skew check overhead, the default
maximum number of retries is reduced from 3 to 2 to maintain the same 12
clocksource reads in the worst case.
Suggested-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Waiman Long <longman@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
filter.rst starts out documenting the classic BPF and then spills into
introducing and documentating eBPF. Move the eBPF documentation into
rwo new files under Documentation/bpf/ for the instruction set and
the verifier and link to the BPF documentation from filter.rst.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Song Liu <songliubraving@fb.com>
Link: https://lore.kernel.org/bpf/20211119163215.971383-6-hch@lst.de
The initial implementation of migrate_disable() for mainline was a
wrapper around preempt_disable(). RT kernels substituted this with
a real migrate disable implementation.
Later on mainline gained true migrate disable support, but the
documentation was not updated.
Update the documentation, remove the claims about migrate_disable()
mapping to preempt_disable() on non-PREEMPT_RT kernels.
Fixes: 74d862b682 ("sched: Make migrate_disable/enable() independent of RT")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20211127163200.10466-2-bigeasy@linutronix.de
Currently, we use hard code number to verify if we are in the
arp_interval timeslice. But some user may want to reduce/extend
the verify timeslice. With the similar team option 'missed_max'
the uers could change that number based on their own environment.
Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
V4L2_PIX_FMT_HM12 was redefined to V4L2_PIX_FMT_NV12_16L16, so use the
new name in libv4l-introduction.rst.
This fixes this warning:
libv4l-introduction.rst:27: WARNING: undefined label: v4l2-pix-fmt-hm12
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
CAPTURE buffers might be read by the hardware after they are dequeued,
which goes against the general idea that userspace has full control over
dequeued buffers. Explain why and document the restrictions that this
implies for userspace.
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
