summaryrefslogtreecommitdiffstats
path: root/Documentation
AgeCommit message (Collapse)Author
2020-10-07block/diskstats: more accurate approximation of io_ticks for slow disksKonstantin Khlebnikov
commit 2b8bd423614c595540eaadcfbc702afe8e155e50 upstream. Currently io_ticks is approximated by adding one at each start and end of requests if jiffies counter has changed. This works perfectly for requests shorter than a jiffy or if one of requests starts/ends at each jiffy. If disk executes just one request at a time and they are longer than two jiffies then only first and last jiffies will be accounted. Fix is simple: at the end of request add up into io_ticks jiffies passed since last update rather than just one jiffy. Example: common HDD executes random read 4k requests around 12ms. fio --name=test --filename=/dev/sdb --rw=randread --direct=1 --runtime=30 & iostat -x 10 sdb Note changes of iostat's "%util" 8,43% -> 99,99% before/after patch: Before: Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sdb 0,00 0,00 82,60 0,00 330,40 0,00 8,00 0,96 12,09 12,09 0,00 1,02 8,43 After: Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sdb 0,00 0,00 82,50 0,00 330,00 0,00 8,00 1,00 12,10 12,10 0,00 12,12 99,99 Now io_ticks does not loose time between start and end of requests, but for queue-depth > 1 some I/O time between adjacent starts might be lost. For load estimation "%util" is not as useful as average queue length, but it clearly shows how often disk queue is completely empty. Fixes: 5b18b5a73760 ("block: delete part_round_stats and switch to less precise counting") Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Reviewed-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> From: "Banerjee, Debabrata" <dbanerje@akamai.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-07gpio/aspeed-sgpio: enable access to all 80 input & output sgpiosJeremy Kerr
[ Upstream commit ac67b07e268d46eba675a60c37051bb3e59fd201 ] Currently, the aspeed-sgpio driver exposes up to 80 GPIO lines, corresponding to the 80 status bits available in hardware. Each of these lines can be configured as either an input or an output. However, each of these GPIOs is actually an input *and* an output; we actually have 80 inputs plus 80 outputs. This change expands the maximum number of GPIOs to 160; the lower half of this range are the input-only GPIOs, the upper half are the outputs. We fix the GPIO directions to correspond to this mapping. This also fixes a bug when setting GPIOs - we were reading from the input register, making it impossible to set more than one output GPIO. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Fixes: 7db47faae79b ("gpio: aspeed: Add SGPIO driver") Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01ata: make qc_prep return ata_completion_errorsJiri Slaby
commit 95364f36701e62dd50eee91e1303187fd1a9f567 upstream. In case a driver wants to return an error from qc_prep, return enum ata_completion_errors. sata_mv is one of those drivers -- see the next patch. Other drivers return the newly defined AC_ERR_OK. [v2] use enum ata_completion_errors and AC_ERR_OK. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Jens Axboe <axboe@kernel.dk> Cc: linux-ide@vger.kernel.org Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-01dt-bindings: sound: wm8994: Correct required supplies based on actual ↵Krzysztof Kozlowski
implementaion [ Upstream commit 8c149b7d75e53be47648742f40fc90d9fc6fa63a ] The required supplies in bindings were actually not matching implementation making the bindings incorrect and misleading. The Linux kernel driver requires all supplies to be present. Also for wlf,wm8994 uses just DBVDD-supply instead of DBVDDn-supply (n: <1,3>). Reported-by: Jonathan Bakker <xc-racer2@live.ca> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20200501133534.6706-1-krzk@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-09affs: fix basic permission bits to actually workMax Staudt
commit d3a84a8d0dde4e26bc084b36ffcbdc5932ac85e2 upstream. The basic permission bits (protection bits in AmigaOS) have been broken in Linux' AFFS - it would only set bits, but never delete them. Also, contrary to the documentation, the Archived bit was not handled. Let's fix this for good, and set the bits such that Linux and classic AmigaOS can coexist in the most peaceful manner. Also, update the documentation to represent the current state of things. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Max Staudt <max@enpas.org> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-09mmc: dt-bindings: Add resets/reset-names for Mediatek MMC bindingsWenbin Mei
commit 65557383191de46611dd3d6b639cbcfbade43c4a upstream. Add description for resets/reset-names. Cc: <stable@vger.kernel.org> # v5.4+ Fixes: 966580ad236e ("mmc: mediatek: add support for MT7622 SoC") Signed-off-by: Wenbin Mei <wenbin.mei@mediatek.com> Tested-by: Frank Wunderlich <frank-w@public-files.de> Link: https://lore.kernel.org/r/20200814014346.6496-2-wenbin.mei@mediatek.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-09-05dt-bindings: mmc: tegra: Add tmclk for Tegra210 and laterSowjanya Komatineni
commit f7f86e8ac0ad7cd6792a80137f5a550924966916 upstream. commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support") Tegra210 and later uses separate SDMMC_LEGACY_TM clock for data timeout. So, this patch adds "tmclk" to Tegra sdhci clock property in the device tree binding. Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support") Cc: stable <stable@vger.kernel.org> # 5.4 Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Link: https://lore.kernel.org/r/1598548861-32373-4-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-26kbuild: support LLVM=1 to switch the default tools to Clang/LLVMMasahiro Yamada
commit a0d1c951ef08ed24f35129267e3595d86f57f5d3 upstream. As Documentation/kbuild/llvm.rst implies, building the kernel with a full set of LLVM tools gets very verbose and unwieldy. Provide a single switch LLVM=1 to use Clang and LLVM tools instead of GCC and Binutils. You can pass it from the command line or as an environment variable. Please note LLVM=1 does not turn on the integrated assembler. You need to pass LLVM_IAS=1 to use it. When the upstream kernel is ready for the integrated assembler, I think we can make it default. We discussed what we need, and we agreed to go with a simple boolean flag that switches both target and host tools: https://lkml.org/lkml/2020/3/28/494 https://lkml.org/lkml/2020/4/3/43 Some items discussed, but not adopted: - LLVM_DIR When multiple versions of LLVM are installed, I just thought supporting LLVM_DIR=/path/to/my/llvm/bin/ might be useful. CC = $(LLVM_DIR)clang LD = $(LLVM_DIR)ld.lld ... However, we can handle this by modifying PATH. So, we decided to not do this. - LLVM_SUFFIX Some distributions (e.g. Debian) package specific versions of LLVM with naming conventions that use the version as a suffix. CC = clang$(LLVM_SUFFIX) LD = ld.lld(LLVM_SUFFIX) ... will allow a user to pass LLVM_SUFFIX=-11 to use clang-11 etc., but the suffixed versions in /usr/bin/ are symlinks to binaries in /usr/lib/llvm-#/bin/, so this can also be handled by PATH. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> # build Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-26kbuild: replace AS=clang with LLVM_IAS=1Masahiro Yamada
commit 7e20e47c70f810d678d02941fa3c671209c4ca97 upstream. The 'AS' variable is unused for building the kernel. Only the remaining usage is to turn on the integrated assembler. A boolean flag is a better fit for this purpose. AS=clang was added for experts. So, I replaced it with LLVM_IAS=1, breaking the backward compatibility. Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-26Documentation/llvm: fix the name of llvm-sizeFangrui Song
commit 0f44fbc162b737ff6251ae248184390ae2279fee upstream. The tool is called llvm-size, not llvm-objsize. Fixes: fcf1b6a35c16 ("Documentation/llvm: add documentation on building w/ Clang/LLVM") Signed-off-by: Fangrui Song <maskray@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-26Documentation/llvm: add documentation on building w/ Clang/LLVMNick Desaulniers
commit fcf1b6a35c16ac500fa908a4022238e5d666eabf upstream. added to kbuild documentation. Provides more official info on building kernels with Clang and LLVM than our wiki. Suggested-by: Kees Cook <keescook@chromium.org> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-21dt-bindings: iio: io-channel-mux: Fix compatible string in example codeChristian Eggers
commit add48ba425192c6e04ce70549129cacd01e2a09e upstream. The correct compatible string is "gpio-mux" (see bindings/mux/gpio-mux.txt). Cc: stable@vger.kernel.org # v4.13+ Reviewed-by: Peter Rosin <peda@axentia.se> Signed-off-by: Christian Eggers <ceggers@arri.de> Link: https://lore.kernel.org/r/20200727101605.24384-1-ceggers@arri.de Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-08-19iio: improve IIO_CONCENTRATION channel type descriptionTomasz Duszynski
[ Upstream commit df16c33a4028159d1ba8a7061c9fa950b58d1a61 ] IIO_CONCENTRATION together with INFO_RAW specifier is used for reporting raw concentrations of pollutants. Raw value should be meaningless before being properly scaled. Because of that description shouldn't mention raw value unit whatsoever. Fix this by rephrasing existing description so it follows conventions used throughout IIO ABI docs. Fixes: 8ff6b3bc94930 ("iio: chemical: Add IIO_CONCENTRATION channel type") Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com> Acked-by: Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-22doc: dt: bindings: usb: dwc3: Update entries for disabling SS instances in ↵Neil Armstrong
park mode [ Upstream commit 3d157c28d2289edf0439e8308e8de3a06acaaf0e ] This patch updates the documentation with the information related to the quirks that needs to be added for disabling all SuperSpeed XHCI instances in park mode. Cc: Dongjin Kim <tobetter@gmail.com> Cc: Jianxin Pan <jianxin.pan@amlogic.com> Cc: Thinh Nguyen <thinhn@synopsys.com> Cc: Jun Li <lijun.kernel@gmail.com> Reported-by: Tim <elatllat@gmail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-07-22dt-bindings: mailbox: zynqmp_ipi: fix unit addressKangmin Park
[ Upstream commit 35b9c0fdb9f666628ecda02b1fc44306933a2d97 ] Fix unit address to match the first address specified in the reg property of the node in example. Signed-off-by: Kangmin Park <l4stpr0gr4m@gmail.com> Link: https://lore.kernel.org/r/20200625135158.5861-1-l4stpr0gr4m@gmail.com Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-22dt-bindings: display: mediatek: control dpi pins mode to avoid leakageJitao Shi
[ Upstream commit b0ff9b590733079f7f9453e5976a9dd2630949e3 ] Add property "pinctrl-names" to swap pin mode between gpio and dpi mode. Set the dpi pins to gpio mode and output-low to avoid leakage current when dpi disabled. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-22x86/kvm/hyper-v: Explicitly align hcall param for kvm_hyperv_exitJon Doron
[ Upstream commit f7d31e65368aeef973fab788aa22c4f1d5a6af66 ] The problem the patch is trying to address is the fact that 'struct kvm_hyperv_exit' has different layout on when compiling in 32 and 64 bit modes. In 64-bit mode the default alignment boundary is 64 bits thus forcing extra gaps after 'type' and 'msr' but in 32-bit mode the boundary is at 32 bits thus no extra gaps. This is an issue as even when the kernel is 64 bit, the userspace using the interface can be both 32 and 64 bit but the same 32 bit userspace has to work with 32 bit kernel. The issue is fixed by forcing the 64 bit layout, this leads to ABI change for 32 bit builds and while we are obviously breaking '32 bit userspace with 32 bit kernel' case, we're fixing the '32 bit userspace with 64 bit kernel' one. As the interface has no (known) users and 32 bit KVM is rather baroque nowadays, this seems like a reasonable decision. Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Jon Doron <arilou@gmail.com> Message-Id: <20200424113746.3473563-2-arilou@gmail.com> Reviewed-by: Roman Kagan <rvkagan@yandex-team.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-17lib/lzo: fix ambiguous encoding bug in lzo-rleDave Rodgman
commit b5265c813ce4efbfa2e46fd27cdf9a7f44a35d2e upstream. In some rare cases, for input data over 32 KB, lzo-rle could encode two different inputs to the same compressed representation, so that decompression is then ambiguous (i.e. data may be corrupted - although zram is not affected because it operates over 4 KB pages). This modifies the compressor without changing the decompressor or the bitstream format, such that: - there is no change to how data produced by the old compressor is decompressed - an old decompressor will correctly decode data from the updated compressor - performance and compression ratio are not affected - we avoid introducing a new bitstream format In testing over 12.8M real-world files totalling 903 GB, three files were affected by this bug. I also constructed 37M semi-random 64 KB files totalling 2.27 TB, and saw no affected files. Finally I tested over files constructed to contain each of the ~1024 possible bad input sequences; for all of these cases, updated lzo-rle worked correctly. There is no significant impact to performance or compression ratio. Signed-off-by: Dave Rodgman <dave.rodgman@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Dave Rodgman <dave.rodgman@arm.com> Cc: Willy Tarreau <w@1wt.eu> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Cc: Markus F.X.J. Oberhumer <markus@oberhumer.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Nitin Gupta <ngupta@vflare.org> Cc: Chao Yu <yuchao0@huawei.com> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20200507100203.29785-1-dave.rodgman@arm.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-10x86/speculation: Add Ivy Bridge to affected listJosh Poimboeuf
commit 3798cc4d106e91382bfe016caa2edada27c2bb3f upstream Make the docs match the code. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-10x86/speculation: Add SRBDS vulnerability and mitigation documentationMark Gross
commit 7222a1b5b87417f22265c92deea76a6aecd0fb0f upstream Add documentation for the SRBDS vulnerability and its mitigation. [ bp: Massage. jpoimboe: sysfs table strings. ] Signed-off-by: Mark Gross <mgross@linux.intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Tony Luck <tony.luck@intel.com> Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-10x86/speculation: Add Special Register Buffer Data Sampling (SRBDS) mitigationMark Gross
commit 7e5b3c267d256822407a22fdce6afdf9cd13f9fb upstream SRBDS is an MDS-like speculative side channel that can leak bits from the random number generator (RNG) across cores and threads. New microcode serializes the processor access during the execution of RDRAND and RDSEED. This ensures that the shared buffer is overwritten before it is released for reuse. While it is present on all affected CPU models, the microcode mitigation is not needed on models that enumerate ARCH_CAPABILITIES[MDS_NO] in the cases where TSX is not supported or has been disabled with TSX_CTRL. The mitigation is activated by default on affected processors and it increases latency for RDRAND and RDSEED instructions. Among other effects this will reduce throughput from /dev/urandom. * Enable administrator to configure the mitigation off when desired using either mitigations=off or srbds=off. * Export vulnerability status via sysfs * Rename file-scoped macros to apply for non-whitelist table initializations. [ bp: Massage, - s/VULNBL_INTEL_STEPPING/VULNBL_INTEL_STEPPINGS/g, - do not read arch cap MSR a second time in tsx_fused_off() - just pass it in, - flip check in cpu_set_bug_bits() to save an indentation level, - reflow comments. jpoimboe: s/Mitigated/Mitigation/ in user-visible strings tglx: Dropped the fused off magic for now ] Signed-off-by: Mark Gross <mgross@linux.intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Tony Luck <tony.luck@intel.com> Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com> Tested-by: Neelima Krishnan <neelima.krishnan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-29USB: hub: Revert commit bd0e6c9614b9 ("usb: hub: try old enumeration scheme ↵Alan Stern
first for high speed devices") commit 3155f4f40811c5d7e3c686215051acf504e05565 upstream. Commit bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices") changed the way the hub driver enumerates high-speed devices. Instead of using the "new" enumeration scheme first and switching to the "old" scheme if that doesn't work, we start with the "old" scheme. In theory this is better because the "old" scheme is slightly faster -- it involves resetting the device only once instead of twice. However, for a long time Windows used only the "new" scheme. Zeng Tao said that Windows 8 and later use the "old" scheme for high-speed devices, but apparently there are some devices that don't like it. William Bader reports that the Ricoh webcam built into his Sony Vaio laptop not only doesn't enumerate under the "old" scheme, it gets hung up so badly that it won't then enumerate under the "new" scheme! Only a cold reset will fix it. Therefore we will revert the commit and go back to trying the "new" scheme first for high-speed devices. Reported-and-tested-by: William Bader <williambader@hotmail.com> Ref: https://bugzilla.kernel.org/show_bug.cgi?id=207219 Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Fixes: bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices") CC: Zeng Tao <prime.zeng@hisilicon.com> CC: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2004221611230.11262-100000@iolanthe.rowland.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-29arm64: errata: Hide CTR_EL0.DIC on systems affected by Neoverse-N1 #1542419James Morse
[ Upstream commit 05460849c3b51180d5ada3373d0449aea19075e4 ] Cores affected by Neoverse-N1 #1542419 could execute a stale instruction when a branch is updated to point to freshly generated instructions. To workaround this issue we need user-space to issue unnecessary icache maintenance that we can trap. Start by hiding CTR_EL0.DIC. Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23docs: Fix path to MTD command line partition parserJonathan Neuschäfer
commit fb2511247dc4061fd122d0195838278a4a0b7b59 upstream. cmdlinepart.c has been moved to drivers/mtd/parsers/. Fixes: a3f12a35c91d ("mtd: parsers: Move CMDLINE parser") Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23arm64: tegra: Fix Tegra194 PCIe compatible stringJon Hunter
[ Upstream commit f9f711efd441ad0d22874be49986d92121862335 ] If the kernel configuration option CONFIG_PCIE_DW_PLAT_HOST is enabled then this can cause the kernel to incorrectly probe the generic designware PCIe platform driver instead of the Tegra194 designware PCIe driver. This causes a boot failure on Tegra194 because the necessary configuration to access the hardware is not performed. The order in which the compatible strings are populated in Device-Tree is not relevant in this case, because the kernel will attempt to probe the device as soon as a driver is loaded and if the generic designware PCIe driver is loaded first, then this driver will be probed first. Therefore, to fix this problem, remove the "snps,dw-pcie" string from the compatible string as we never want this driver to be probe on Tegra194. Fixes: 2602c32f15e7 ("arm64: tegra: Add P2U and PCIe controller nodes to Tegra194 DT") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-17ALSA: hda/realtek - Remove now-unnecessary XPS 13 headphone noise fixupsThomas Hebb
commit f36938aa7440f46a0a365f1cfde5f5985af2bef3 upstream. patch_realtek.c has historically failed to properly configure the PC Beep Hidden Register for the ALC256 codec (among others). Depending on your kernel version, symptoms of this misconfiguration can range from chassis noise, picked up by a poorly-shielded PCBEEP trace, getting amplified and played on your internal speaker and/or headphones to loud feedback, which responds to the "Headphone Mic Boost" ALSA control, getting played through your headphones. For details of the problem, see the patch in this series titled "ALSA: hda/realtek - Set principled PC Beep configuration for ALC256", which fixes the configuration. These symptoms have been most noticed on the Dell XPS 13 9350 and 9360, popular laptops that use the ALC256. As a result, several model-specific fixups have been introduced to try and fix the problem, the most egregious of which locks the "Headphone Mic Boost" control as a hack to minimize noise from a feedback loop that shouldn't have been there in the first place. Now that the underlying issue has been fixed, remove all these fixups. Remaining fixups needed by the XPS 13 are all picked up by existing pin quirks. This change should, for the XPS 13 9350/9360 - Significantly increase volume and audio quality on headphones - Eliminate headphone popping on suspend/resume - Allow "Headphone Mic Boost" to be set again, making the headphone jack fully usable as a microphone jack too. Fixes: 8c69729b4439 ("ALSA: hda - Fix headphone noise after Dell XPS 13 resume back from S3") Fixes: 423cd785619a ("ALSA: hda - Fix headphone noise on Dell XPS 13 9360") Fixes: e4c9fd10eb21 ("ALSA: hda - Apply headphone noise quirk for another Dell XPS 13 variant") Fixes: 1099f48457d0 ("ALSA: hda/realtek: Reduce the Headphone static noise on XPS 9350/9360") Cc: stable@vger.kernel.org Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Link: https://lore.kernel.org/r/b649a00edfde150cf6eebbb4390e15e0c2deb39a.1585584498.git.tommyhebb@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-17ALSA: doc: Document PC Beep Hidden Register on Realtek ALC256Thomas Hebb
commit f128090491c3f5aacef91a863f8c52abf869c436 upstream. This codec (among others) has a hidden set of audio routes, apparently designed to allow PC Beep output without a mixer widget on the output path, which are controlled by an undocumented Realtek vendor register. The default configuration of these routes means that certain inputs aren't accessible, necessitating driver control of the register. However, Realtek has provided no documentation of the register, instead opting to fix issues by providing magic numbers, most of which have been at least somewhat erroneous. These magic numbers then get copied by others into model-specific fixups, leading to a fragmented and buggy set of configurations. To get out of this situation, I've reverse engineered the register by flipping bits and observing how the codec's behavior changes. This commit documents my findings. It does not change any code. Cc: stable@vger.kernel.org Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Link: https://lore.kernel.org/r/bd69dfdeaf40ff31c4b7b797c829bb320031739c.1585584498.git.tommyhebb@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-01dt-bindings: net: FMan erratum A050385Madalin Bucur
[ Upstream commit 26d5bb9e4c4b541c475751e015072eb2cbf70d15 ] FMAN DMA read or writes under heavy traffic load may cause FMAN internal resource leak; thus stopping further packet processing. The FMAN internal queue can overflow when FMAN splits single read or write transactions into multiple smaller transactions such that more than 17 AXI transactions are in flight from FMAN to interconnect. When the FMAN internal queue overflows, it can stall further packet processing. The issue can occur with any one of the following three conditions: 1. FMAN AXI transaction crosses 4K address boundary (Errata A010022) 2. FMAN DMA address for an AXI transaction is not 16 byte aligned, i.e. the last 4 bits of an address are non-zero 3. Scatter Gather (SG) frames have more than one SG buffer in the SG list and any one of the buffers, except the last buffer in the SG list has data size that is not a multiple of 16 bytes, i.e., other than 16, 32, 48, 64, etc. With any one of the above three conditions present, there is likelihood of stalled FMAN packet processing, especially under stress with multiple ports injecting line-rate traffic. To avoid situations that stall FMAN packet processing, all of the above three conditions must be avoided; therefore, configure the system with the following rules: 1. Frame buffers must not span a 4KB address boundary, unless the frame start address is 256 byte aligned 2. All FMAN DMA start addresses (for example, BMAN buffer address, FD[address] + FD[offset]) are 16B aligned 3. SG table and buffer addresses are 16B aligned and the size of SG buffers are multiple of 16 bytes, except for the last SG buffer that can be of any size. Additional workaround notes: - Address alignment of 64 bytes is recommended for maximally efficient system bus transactions (although 16 byte alignment is sufficient to avoid the stall condition) - To support frame sizes that are larger than 4K bytes, there are two options: 1. Large single buffer frames that span a 4KB page boundary can be converted into SG frames to avoid transaction splits at the 4KB boundary, 2. Align the large single buffer to 256B address boundaries, ensure that the frame address plus offset is 256B aligned. - If software generated SG frames have buffers that are unaligned and with random non-multiple of 16 byte lengths, before transmitting such frames via FMAN, frames will need to be copied into a new single buffer or multiple buffer SG frame that is compliant with the three rules listed above. Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-03-25modpost: move the namespace field in Module.symvers lastJessica Yu
commit 5190044c2965514a973184ca68ef5fad57a24670 upstream. In order to preserve backwards compatability with kmod tools, we have to move the namespace field in Module.symvers last, as the depmod -e -E option looks at the first three fields in Module.symvers to check symbol versions (and it's expected they stay in the original order of crc, symbol, module). In addition, update an ancient comment above read_dump() in modpost that suggested that the export type field in Module.symvers was optional. I suspect that there were historical reasons behind that comment that are no longer accurate. We have been unconditionally printing the export type since 2.6.18 (commit bd5cbcedf44), which is over a decade ago now. Fix up read_dump() to treat each field as non-optional. I suspect the original read_dump() code treated the export field as optional in order to support pre <= 2.6.18 Module.symvers (which did not have the export type field). Note that although symbol namespaces are optional, the field will not be omitted from Module.symvers if a symbol does not have a namespace. In this case, the field will simply be empty and the next delimiter or end of line will follow. Cc: stable@vger.kernel.org Fixes: cb9b55d21fe0 ("modpost: add support for symbol namespaces") Tested-by: Matthias Maennich <maennich@google.com> Reviewed-by: Matthias Maennich <maennich@google.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jessica Yu <jeyu@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-21ACPI: watchdog: Allow disabling WDAT at bootJean Delvare
[ Upstream commit 3f9e12e0df012c4a9a7fd7eb0d3ae69b459d6b2c ] In case the WDAT interface is broken, give the user an option to ignore it to let a native driver bind to the watchdog device instead. Signed-off-by: Jean Delvare <jdelvare@suse.de> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-03-18cifs_atomic_open(): fix double-put on late allocation failureAl Viro
commit d9a9f4849fe0c9d560851ab22a85a666cddfdd24 upstream. several iterations of ->atomic_open() calling conventions ago, we used to need fput() if ->atomic_open() failed at some point after successful finish_open(). Now (since 2016) it's not needed - struct file carries enough state to make fput() work regardless of the point in struct file lifecycle and discarding it on failure exits in open() got unified. Unfortunately, I'd missed the fact that we had an instance of ->atomic_open() (cifs one) that used to need that fput(), as well as the stale comment in finish_open() demanding such late failure handling. Trivially fixed... Fixes: fe9ec8291fca "do_last(): take fput() on error after opening to out:" Cc: stable@kernel.org # v4.7+ Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-05netfilter: nf_flowtable: fix documentationMatteo Croce
commit 78e06cf430934fc3768c342cbebdd1013dcd6fa7 upstream. In the flowtable documentation there is a missing semicolon, the command as is would give this error: nftables.conf:5:27-33: Error: syntax error, unexpected devices, expecting newline or semicolon hook ingress priority 0 devices = { br0, pppoe-data }; ^^^^^^^ nftables.conf:4:12-13: Error: invalid hook (null) flowtable ft { ^^ Fixes: 19b351f16fd9 ("netfilter: add flowtable documentation") Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-05kbuild: remove header compile testMasahiro Yamada
commit fcbb8461fd2376ba3782b5b8bd440c929b8e4980 upstream. There are both positive and negative options about this feature. At first, I thought it was a good idea, but actually Linus stated a negative opinion (https://lkml.org/lkml/2019/9/29/227). I admit it is ugly and annoying. The baseline I'd like to keep is the compile-test of uapi headers. (Otherwise, kernel developers have no way to ensure the correctness of the exported headers.) I will maintain a small build rule in usr/include/Makefile. Remove the other header test functionality. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> [ added to 5.4.y due to start of build warnings from backported patches because of this feature - gregkh] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-28mm: Avoid creating virtual address aliases in brk()/mmap()/mremap()Catalin Marinas
commit dcde237319e626d1ec3c9d8b7613032f0fd4663a upstream. Currently the arm64 kernel ignores the top address byte passed to brk(), mmap() and mremap(). When the user is not aware of the 56-bit address limit or relies on the kernel to return an error, untagging such pointers has the potential to create address aliases in user-space. Passing a tagged address to munmap(), madvise() is permitted since the tagged pointer is expected to be inside an existing mapping. The current behaviour breaks the existing glibc malloc() implementation which relies on brk() with an address beyond 56-bit to be rejected by the kernel. Remove untagging in the above functions by partially reverting commit ce18d171cb73 ("mm: untag user pointers in mmap/munmap/mremap/brk"). In addition, update the arm64 tagged-address-abi.rst document accordingly. Link: https://bugzilla.redhat.com/1797052 Fixes: ce18d171cb73 ("mm: untag user pointers in mmap/munmap/mremap/brk") Cc: <stable@vger.kernel.org> # 5.4.x- Cc: Florian Weimer <fweimer@redhat.com> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Reported-by: Victor Stinner <vstinner@redhat.com> Acked-by: Will Deacon <will@kernel.org> Acked-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-24fbdev: fix numbering of fbcon optionsPeter Rosin
[ Upstream commit fd933c00ebe220060e66fb136a7050a242456566 ] Three shall be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count... One! Two! Five! Fixes: efb985f6b265 ("[PATCH] fbcon: Console Rotation - Add framebuffer console documentation") Signed-off-by: Peter Rosin <peda@axentia.se> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Matthew Wilcox <willy@infradead.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190827110854.12574-2-peda@axentia.se Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-02-14dt-bindings: iio: adc: ad7606: Fix wrong maxItems valueBeniamin Bia
commit a6c4f77cb3b11f81077b53c4a38f21b92d41f21e upstream. This patch set the correct value for oversampling maxItems. In the original example, appears 3 items for oversampling while the maxItems is set to 1, this patch fixes those issues. Fixes: 416f882c3b40 ("dt-bindings: iio: adc: Migrate AD7606 documentation to yaml") Signed-off-by: Beniamin Bia <beniamin.bia@analog.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-05PM / devfreq: Add new name attribute for sysfsChanwoo Choi
commit 2fee1a7cc6b1ce6634bb0f025be2c94a58dfa34d upstream. The commit 4585fbcb5331 ("PM / devfreq: Modify the device name as devfreq(X) for sysfs") changed the node name to devfreq(x). After this commit, it is not possible to get the device name through /sys/class/devfreq/devfreq(X)/*. Add new name attribute in order to get device name. Cc: stable@vger.kernel.org Fixes: 4585fbcb5331 ("PM / devfreq: Modify the device name as devfreq(X) for sysfs") Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-26hwrng: omap3-rom - Fix missing clock by probing with device treeTony Lindgren
[ Upstream commit 0c0ef9ea6f3f0d5979dc7b094b0a184c1a94716b ] Commit 0ed266d7ae5e ("clk: ti: omap3: cleanup unnecessary clock aliases") removed old omap3 clock framework aliases but caused omap3-rom-rng to stop working with clock not found error. Based on discussions on the mailing list it was requested by Tero Kristo that it would be best to fix this issue by probing omap3-rom-rng using device tree to provide a proper clk property. The other option would be to add back the missing clock alias, but that does not help moving things forward with removing old legacy platform_data. Let's also add a proper device tree binding and keep it together with the fix. Cc: devicetree@vger.kernel.org Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Adam Ford <aford173@gmail.com> Cc: Pali Rohár <pali.rohar@gmail.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Sebastian Reichel <sre@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Fixes: 0ed266d7ae5e ("clk: ti: omap3: cleanup unnecessary clock aliases") Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-01-23dt-bindings: Add missing 'properties' keyword enclosing 'snps,tso'Rob Herring
commit dbce0b65046d1735d7054c54ec2387dba84ba258 upstream. DT property definitions must be under a 'properties' keyword. This was missing for 'snps,tso' in an if/then clause. A meta-schema fix will catch future errors like this. Fixes: 7db3545aef5f ("dt-bindings: net: stmmac: Convert the binding to a schemas") Cc: "David S. Miller" <davem@davemloft.net> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-17mei: fix modalias documentationAlexander Usyskin
commit 73668309215285366c433489de70d31362987be9 upstream. mei client bus added the client protocol version to the device alias, but ABI documentation was not updated. Fixes: b26864cad1c9 (mei: bus: add client protocol version to the device alias) Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Link: https://lore.kernel.org/r/20191008005735.12707-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-17dm: add dm-clone to the documentation indexDiego Calleja
commit 484e0d2b11e1fdd0d17702b282eb2ed56148385f upstream. Fixes: 7431b7835f554 ("dm: add clone target") Signed-off-by: Diego Calleja <diegocg@gmail.com> Signed-off-by: Nikos Tsironis <ntsironis@arrikto.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-17Documentation/ABI: Add missed attribute for mlxreg-io sysfs interfacesVadim Pasternak
commit f3efc406d67e6236b513c4302133b0c9be74fd99 upstream. Add missed "cpld4_version" attribute. Fixes: 52675da1d087 ("Documentation/ABI: Add new attribute for mlxreg-io sysfs interfaces") Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-17Documentation/ABI: Fix documentation inconsistency for mlxreg-io sysfs ↵Vadim Pasternak
interfaces commit f4094826779dcafe7087e80850513b923eeefdeb upstream. Fix attribute name from "jtag_enable", which described twice to "cpld3_version", which is expected to be instead of second appearance of "jtag_enable". Fixes: 2752e34442b5 ("Documentation/ABI: Add new attribute for mlxreg-io sysfs interfaces") Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-17ASoC: dt-bindings: mt8183: add missing updateTzung-Bi Shih
commit 7cf2804775f8a388411624b3e768e55d08711e9d upstream. Headset codec is optional. Add missing update to DT binding document. Fixes: a962a809e5e4 ("ASoC: mediatek: mt8183: make headset codec optional") Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20190920112320.166052-1-tzungbi@google.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-17dt-bindings: reset: Fix brcmstb-reset exampleFlorian Fainelli
commit 392a9f63058f2cdcec8363b849a25532ee40da9f upstream. The reset controller has a #reset-cells value of 1, so we should see a phandle plus a register identifier, fix the example. Fixes: 0807caf647dd ("dt-bindings: reset: Add document for Broadcom STB reset controller") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-17can: j1939: fix address claim code exampleMarc Kleine-Budde
commit 8ac9d71d601374222a230804e419cd40c4492e1c upstream. During development the define J1939_PGN_ADDRESS_REQUEST was renamed to J1939_PGN_REQUEST. It was forgotten to adjust the documentation accordingly. This patch fixes the name of the symbol. Reported-by: https://github.com/linux-can/can-utils/issues/159#issuecomment-556538798 Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Cc: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-17scsi: smartpqi: Update attribute name to `driver_version`Paul Menzel
commit a2bdd0c904da12b223c8d7218e98138d4e6d9f4f upstream. The file name in the documentation is currently incorrect, so fix it. Link: https://lore.kernel.org/r/fe264d62-0371-ea59-b66a-6d855290ce65@molgen.mpg.de Fixes: 6d90615f1346 ("scsi: smartpqi: add sysfs entries") Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-09dt-bindings: clock: renesas: rcar-usb2-clock-sel: Fix typo in exampleGeert Uytterhoeven
commit 830dbce7c76ea529decac7d23b808c1e7da3d891 upstream. The documented compatible value for R-Car H3 is "renesas,r8a7795-rcar-usb2-clock-sel", not "renesas,r8a77950-rcar-usb2-clock-sel". Fixes: 311accb64570db45 ("clk: renesas: rcar-usb2-clock-sel: Add R-Car USB 2.0 clock selector PHY") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191016145650.30003-1-geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-09ACPI: sysfs: Change ACPI_MASKABLE_GPE_MAX to 0x100Yunfeng Ye
commit a7583e72a5f22470d3e6fd3b6ba912892242339f upstream. The commit 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs") says: "Use a bitmap of size 0xFF instead of a u64 for the GPE mask so 256 GPEs can be masked" But the masking of GPE 0xFF it not supported and the check condition "gpe > ACPI_MASKABLE_GPE_MAX" is not valid because the type of gpe is u8. So modify the macro ACPI_MASKABLE_GPE_MAX to 0x100, and drop the "gpe > ACPI_MASKABLE_GPE_MAX" check. In addition, update the docs "Format" for acpi_mask_gpe parameter. Fixes: 0f27cff8597d ("ACPI: sysfs: Make ACPI GPE mask kernel parameter cover all GPEs") Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com> [ rjw: Use u16 as gpe data type in acpi_gpe_apply_masked_gpes() ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-04dt-bindings: Improve validation build error handlingRob Herring
[ Upstream commit 93512dad334deb444619505f1fbb761156f7471b ] Schema errors can cause make to exit before useful information is printed. This leaves developers wondering what's wrong. It can be overcome passing '-k' to make, but that's not an obvious solution. There's 2 scenarios where this happens. When using DT_SCHEMA_FILES to validate with a single schema, any error in the schema results in processed-schema.yaml being empty causing a make error. The result is the specific errors in the schema are never shown because processed-schema.yaml is the first target built. Simply making processed-schema.yaml last in extra-y ensures the full schema validation with detailed error messages happen first. The 2nd problem is while schema errors are ignored for processed-schema.yaml, full validation of the schema still runs in parallel and any schema validation errors will still stop the build when running validation of dts files. The fix is to not add the schema examples to extra-y in this case. This means 'dtbs_check' is no longer a superset of 'dt_binding_check'. Update the documentation to make this clear. Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit 1.2.3-korg (git 2.39.0) at 2024-04-28 01:45:35 +0000