summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
4 daysfs_context: drop the unused lsm_flags memberOndrej Mosnacek1-1/+0
[ Upstream commit 4e04143c869c5b6d499fbd5083caa860d5c942c3 ] This isn't ever used by VFS now, and it couldn't even work. Any FS that uses the SECURITY_LSM_NATIVE_LABELS flag needs to also process the value returned back from the LSM, so it needs to do its security_sb_set_mnt_opts() call on its own anyway. Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org> Stable-dep-of: 8675c69816e4 ("NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags") Signed-off-by: Sasha Levin <sashal@kernel.org>
4 daysdt-bindings: PCI: amlogic: Fix the register name of the DBI regionManivannan Sadhasivam1-3/+3
[ Upstream commit 4813dea9e272ba0a57c50b8d51d440dd8e3ccdd7 ] Binding incorrectly specifies the 'DBI' region as 'ELBI'. DBI is a must have region for DWC controllers as it has the Root Port and controller specific registers, while ELBI has optional registers. Hence, fix the binding. Though this is an ABI break, this change is needed to accurately describe the PCI memory map. Fixes: 7cd210391101 ("dt-bindings: PCI: meson: add DT bindings for Amlogic Meson PCIe controller") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251101-pci-meson-fix-v1-1-c50dcc56ed6a@oss.qualcomm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
4 daysdt-bindings: PCI: convert amlogic,meson-pcie.txt to dt-schemaNeil Armstrong2-70/+134
[ Upstream commit b80b848bdf56bd402b7a91aea5b77cec93dfe4c2 ] Convert the Amlogic Meson AXG DWC PCIe SoC controller bindings to dt-schema. Link: https://lore.kernel.org/r/20221117-b4-amlogic-bindings-convert-v4-5-34e623dbf789@linaro.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Stable-dep-of: 4813dea9e272 ("dt-bindings: PCI: amlogic: Fix the register name of the DBI region") Signed-off-by: Sasha Levin <sashal@kernel.org>
4 daysDocumentation: process: Also mention Sasha Levin as stable tree maintainerBagas Sanjaya1-2/+4
commit ba2457109d5b47a90fe565b39524f7225fc23e60 upstream. Sasha has also maintaining stable branch in conjunction with Greg since cb5d21946d2a2f ("MAINTAINERS: Add Sasha as a stable branch maintainer"). Mention him in 2.Process.rst. Cc: stable@vger.kernel.org Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20251022034336.22839-1-bagasdotme@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-07dt-bindings: pinctrl: toshiba,visconti: Fix number of items in groupsKrzysztof Kozlowski1-12/+14
[ Upstream commit 316e361b5d2cdeb8d778983794a1c6eadcb26814 ] The "groups" property can hold multiple entries (e.g. toshiba/tmpv7708-rm-mbrc.dts file), so allow that by dropping incorrect type (pinmux-node.yaml schema already defines that as string-array) and adding constraints for items. This fixes dtbs_check warnings like: toshiba/tmpv7708-rm-mbrc.dtb: pinctrl@24190000 (toshiba,tmpv7708-pinctrl): pwm-pins:groups: ['pwm0_gpio16_grp', 'pwm1_gpio17_grp', 'pwm2_gpio18_grp', 'pwm3_gpio19_grp'] is too long Fixes: 1825c1fe0057 ("pinctrl: Add DT bindings for Toshiba Visconti TMPV7700 SoC") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> [ adjusted $ref context ] Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-07Makefile.compiler: replace cc-ifversion with compiler-specific macrosNick Desaulniers1-12/+17
commit 88b61e3bff93f99712718db785b4aa0c1165f35c upstream. cc-ifversion is GCC specific. Replace it with compiler specific variants. Update the users of cc-ifversion to use these new macros. Link: https://github.com/ClangBuiltLinux/linux/issues/350 Link: https://lore.kernel.org/llvm/CAGG=3QWSAUakO42kubrCap8fp-gm1ERJJAYXTnP1iHk_wrH=BQ@mail.gmail.com/ Suggested-by: Bill Wendling <morbo@google.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> [nathan: Backport to 5.15 and eliminate instances of cc-ifversion that did not exist upstream when this change was original created] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-07Revert "docs/process/howto: Replace C89 with C11"Matthieu Baerts (NGI0)6-6/+6
This reverts commit dc52117cd797f71f9686fa0cec91509eb7a9623d which is commit 2f3f53d62307262f0086804ea7cea99b0e085450 upstream. In this kernel version, C89 is still the default ISO standard. The reverted commit was fixing commit e8c07082a810 ("Kbuild: move to -std=gnu11"), introduced in v5.18, and not backported to older versions. It was then not supported to be backported to v5.15. It can then safely be reverted. Fixes: 2f3f53d62307 ("docs/process/howto: Replace C89 with C11") Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Cc: Akira Yokosawa <akiyks@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Federico Vaga <federico.vaga@vaga.pv.it> Cc: Alex Shi <alexs@kernel.org> Cc: Hu Haowen <src.res@email.cn> Cc: Tsugikazu Shibata <shibata@linuxfoundation.org> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-07xhci: dbc: Allow users to modify DbC poll interval via sysfsUday M Bhat1-0/+10
[ Upstream commit de3edd47a18fe05a560847cc3165871474e08196 ] xhci DbC driver polls the host controller for DbC events at a reduced rate when DbC is enabled but there are no active data transfers. Allow users to modify this reduced poll interval via dbc_poll_interval_ms sysfs entry. Unit is milliseconds and accepted range is 0 to 5000. Max interval of 5000 ms is selected as it matches the common 5 second timeout used in usb stack. Default value is 64 milliseconds. A long interval is useful when users know there won't be any activity on systems connected via DbC for long periods, and want to avoid battery drainage due to unnecessary CPU usage. Example being Android Debugger (ADB) usage over DbC on ChromeOS systems running Android Runtime. [minor changes and rewording -Mathias] Co-developed-by: Samuel Jacob <samjaco@google.com> Signed-off-by: Samuel Jacob <samjaco@google.com> Signed-off-by: Uday M Bhat <uday.m.bhat@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240626124835.1023046-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: f3d12ec847b9 ("xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-07xhci: dbc: Provide sysfs option to configure dbc descriptorsMathias Nyman1-0/+52
[ Upstream commit edf1664f3249a091a2b91182fc087b3253b0b4c2 ] When DbC is enabled the first port on the xHC host acts as a usb device. xHC provides the descriptors automatically when the DbC device is enumerated. Most of the values are hardcoded, but some fields such as idProduct, idVendor, bcdDevice and bInterfaceProtocol can be modified. Add sysfs entries that allow userspace to change these. User can only change them before dbc is enabled, i.e. before writing "enable" to dbc sysfs file as we don't want these values to change while device is connected, or during enumeration. Add documentation for these entries in Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20230317154715.535523-9-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: f3d12ec847b9 ("xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-07dt-bindings: usb: dwc3-imx8mp: dma-range is required only for imx8mpXu Yang1-1/+9
[ Upstream commit 268eb6fb908bc82ce479e4dba9a2cad11f536c9c ] Only i.MX8MP need dma-range property to let USB controller work properly. Remove dma-range from required list and add limitation for imx8mp. Fixes: d2a704e29711 ("dt-bindings: usb: dwc3-imx8mp: add imx8mp dwc3 glue bindings") Cc: stable <stable@kernel.org> Reviewed-by: Jun Li <jun.li@nxp.com> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-29arm64: errata: Apply workarounds for Neoverse-V3AEMark Rutland1-0/+2
commit 0c33aa1804d101c11ba1992504f17a42233f0e11 upstream. Neoverse-V3AE is also affected by erratum #3312417, as described in its Software Developer Errata Notice (SDEN) document: Neoverse V3AE (MP172) SDEN v9.0, erratum 3312417 https://developer.arm.com/documentation/SDEN-2615521/9-0/ Enable the workaround for Neoverse-V3AE, and document this. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Will Deacon <will@kernel.org> [ Ryan: Trivial backport ] Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-29doc: fix seg6_flowlabel pathNicolas Dichtel1-0/+3
[ Upstream commit 0b4b77eff5f8cd9be062783a1c1e198d46d0a753 ] This sysctl is not per interface; it's global per netns. Fixes: 292ecd9f5a94 ("doc: move seg6_flowlabel to seg6-sysctl.rst") Reported-by: Philippe Guibert <philippe.guibert@6wind.com> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-19fs: Add 'initramfs_options' to set initramfs mount optionsLichen Liu1-0/+3
[ Upstream commit 278033a225e13ec21900f0a92b8351658f5377f2 ] When CONFIG_TMPFS is enabled, the initial root filesystem is a tmpfs. By default, a tmpfs mount is limited to using 50% of the available RAM for its content. This can be problematic in memory-constrained environments, particularly during a kdump capture. In a kdump scenario, the capture kernel boots with a limited amount of memory specified by the 'crashkernel' parameter. If the initramfs is large, it may fail to unpack into the tmpfs rootfs due to insufficient space. This is because to get X MB of usable space in tmpfs, 2*X MB of memory must be available for the mount. This leads to an OOM failure during the early boot process, preventing a successful crash dump. This patch introduces a new kernel command-line parameter, initramfs_options, which allows passing specific mount options directly to the rootfs when it is first mounted. This gives users control over the rootfs behavior. For example, a user can now specify initramfs_options=size=75% to allow the tmpfs to use up to 75% of the available memory. This can significantly reduce the memory pressure for kdump. Consider a practical example: To unpack a 48MB initramfs, the tmpfs needs 48MB of usable space. With the default 50% limit, this requires a memory pool of 96MB to be available for the tmpfs mount. The total memory requirement is therefore approximately: 16MB (vmlinuz) + 48MB (loaded initramfs) + 48MB (unpacked kernel) + 96MB (for tmpfs) + 12MB (runtime overhead) ≈ 220MB. By using initramfs_options=size=75%, the memory pool required for the 48MB tmpfs is reduced to 48MB / 0.75 = 64MB. This reduces the total memory requirement by 32MB (96MB - 64MB), allowing the kdump to succeed with a smaller crashkernel size, such as 192MB. An alternative approach of reusing the existing rootflags parameter was considered. However, a new, dedicated initramfs_options parameter was chosen to avoid altering the current behavior of rootflags (which applies to the final root filesystem) and to prevent any potential regressions. Also add documentation for the new kernel parameter "initramfs_options" This approach is inspired by prior discussions and patches on the topic. Ref: https://www.lightofdawn.org/blog/?viewDetailed=00128 Ref: https://landley.net/notes-2015.html#01-01-2015 Ref: https://lkml.org/lkml/2021/6/29/783 Ref: https://www.kernel.org/doc/html/latest/filesystems/ramfs-rootfs-initramfs.html#what-is-rootfs Signed-off-by: Lichen Liu <lichliu@redhat.com> Link: https://lore.kernel.org/20250815121459.3391223-1-lichliu@redhat.com Tested-by: Rob Landley <rob@landley.net> Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-19drm/vmwgfx: Copy DRM hash-table code into driverThomas Zimmermann1-0/+11
[ Upstream commit 2985c96485b7ef4e015d13dc3081fb0479260951 ] Besides some legacy code, vmwgfx is the only user of DRM's hash- table implementation. Copy the code into the driver, so that the core code can be retired. No functional changes. However, the real solution for vmwgfx is to use Linux' generic hash-table functions. v2: * add TODO item for updating vmwgfx (Sam) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211129094841.22499-3-tzimmermann@suse.de Stable-dep-of: dfe1323ab3c8 ("drm/vmwgfx: Fix Use-after-free in validation") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-19Documentation: trace: historgram-design: Separate sched_waking histogram ↵Bagas Sanjaya1-1/+3
section heading and the following diagram [ Upstream commit 8c716e87ea33519920811338100d6d8a7fb32456 ] Section heading for sched_waking histogram is shown as normal paragraph instead due to codeblock marker for the following diagram being in the same line as the section underline. Separate them. Fixes: daceabf1b494 ("tracing/doc: Fix ascii-art in histogram-design.rst") Reviewed-by: Tom Zanussi <zanussi@kernel.org> Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20250916054202.582074-5-bagasdotme@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-02dt-bindings: serial: brcm,bcm7271-uart: Constrain clocksKrzysztof Kozlowski1-1/+1
commit ee047e1d85d73496541c54bd4f432c9464e13e65 upstream. Lists should have fixed constraints, because binding must be specific in respect to hardware, thus add missing constraints to number of clocks. Cc: stable <stable@kernel.org> Fixes: 88a499cd70d4 ("dt-bindings: Add support for the Broadcom UART driver") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250812121630.67072-2-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-11x86/vmscape: Enable the mitigationPawan Gupta2-0/+12
commit 556c1ad666ad90c50ec8fccb930dd5046cfbecfb upstream. Enable the previously added mitigation for VMscape. Add the cmdline vmscape={off|ibpb|force} and sysfs reporting. Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Amit Shah <amit.shah@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-11Documentation/hw-vuln: Add VMSCAPE documentationPawan Gupta2-0/+111
commit 9969779d0803f5dcd4460ae7aca2bc3fd91bff12 upstream. VMSCAPE is a vulnerability that may allow a guest to influence the branch prediction in host userspace, particularly affecting hypervisors like QEMU. Add the documentation. Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Amit Shah <amit.shah@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28asm-generic: Add memory barrier dma_mb()Kefeng Wang1-5/+6
[ Upstream commit ed59dfd9509d172e4920994ed9cbebf93b0050cc ] The memory barrier dma_mb() is introduced by commit a76a37777f2c ("iommu/arm-smmu-v3: Ensure queue is read after updating prod pointer"), which is used to ensure that prior (both reads and writes) accesses to memory by a CPU are ordered w.r.t. a subsequent MMIO write. Reviewed-by: Arnd Bergmann <arnd@arndb.de> # for asm-generic Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: Marco Elver <elver@google.com> Link: https://lore.kernel.org/r/20220523113126.171714-2-wangkefeng.wang@huawei.com Signed-off-by: Will Deacon <will@kernel.org> Stable-dep-of: aa6956150f82 ("wifi: ath11k: fix dest ring-buffer corruption when ring is full") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28mptcp: disable add_addr retransmission when timeout is 0Geliang Tang1-0/+2
[ Upstream commit f5ce0714623cffd00bf2a83e890d09c609b7f50a ] When add_addr_timeout was set to 0, this caused the ADD_ADDR to be retransmitted immediately, which looks like a buggy behaviour. Instead, interpret 0 as "no retransmissions needed". The documentation is updated to explicitly state that setting the timeout to 0 disables retransmission. Fixes: 93f323b9cccc ("mptcp: add a new sysctl add_addr_timeout") Cc: stable@vger.kernel.org Suggested-by: Matthieu Baerts <matttbe@kernel.org> Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250815-net-mptcp-misc-fixes-6-17-rc2-v1-5-521fe9957892@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> [ pm.c => pm_netlink.c , drop mptcp_pm_alloc_anno_list hunk ] Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28Documentation: ACPI: Fix parent device referencesAndy Shevchenko1-4/+4
commit e65cb011349e653ded541dddd6469c2ca813edcf upstream. The _CRS resources in many cases want to have ResourceSource field to be a type of ACPI String. This means that to compile properly we need to enclosure the name path into double quotes. This will in practice defer the interpretation to a run-time stage, However, this may be interpreted differently on different OSes and ACPI interpreter implementations. In particular ACPICA might not correctly recognize the leading '^' (caret) character and will not resolve the relative name path properly. On top of that, this piece may be used in SSDTs which are loaded after the DSDT and on itself may also not resolve relative name paths outside of their own scopes. With this all said, fix documentation to use fully-qualified name paths always to avoid any misinterpretations, which is proven to work. Fixes: 8eb5c87a92c0 ("i2c: add ACPI support for I2C mux ports") Reported-by: Yevhen Kondrashyn <e.kondrashyn@gmail.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20250710170225.961303-1-andriy.shevchenko@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28f2fs: doc: fix wrong quota mount option descriptionChao Yu1-3/+3
[ Upstream commit 81b6ecca2f15922e8d653dc037df5871e754be6e ] We should use "{usr,grp,prj}jquota=" to disable journaled quota, rather than using off{usr,grp,prj}jquota. Fixes: 4b2414d04e99 ("f2fs: support journalled quota") Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-07-10x86/bugs: Add a Transient Scheduler Attacks mitigationBorislav Petkov (AMD)2-0/+14
commit d8010d4ba43e9f790925375a7de100604a5e2dba upstream. Add the required features detection glue to bugs.c et all in order to support the TSA mitigation. Co-developed-by: Kim Phillips <kim.phillips@amd.com> Signed-off-by: Kim Phillips <kim.phillips@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-10x86/bugs: Rename MDS machinery to something more genericBorislav Petkov (AMD)1-3/+1
Commit f9af88a3d384c8b55beb5dc5483e5da0135fadbd upstream. It will be used by other x86 mitigations. No functional changes. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-10scsi: ufs: core: Fix spelling of a sysfs attribute nameBart Van Assche1-1/+1
[ Upstream commit 021f243627ead17eb6500170256d3d9be787dad8 ] Change "resourse" into "resource" in the name of a sysfs attribute. Fixes: d829fc8a1058 ("scsi: ufs: sysfs: unit descriptor") Signed-off-by: Bart Van Assche <bvanassche@acm.org> Link: https://lore.kernel.org/r/20250624181658.336035-1-bvanassche@acm.org Reviewed-by: Avri Altman <avri.altman@sandisk.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-07-10dt-bindings: serial: 8250: Make clocks and clock-frequency exclusiveYao Zi1-1/+1
commit 09812134071b3941fb81def30b61ed36d3a5dfb5 upstream. The 8250 binding before converting to json-schema states, - clock-frequency : the input clock frequency for the UART or - clocks phandle to refer to the clk used as per Documentation/devicetree for clock-related properties, where "or" indicates these properties shouldn't exist at the same time. Additionally, the behavior of Linux's driver is strange when both clocks and clock-frequency are specified: it ignores clocks and obtains the frequency from clock-frequency, left the specified clocks unclaimed. It may even be disabled, which is undesired most of the time. But "anyOf" doesn't prevent these two properties from coexisting, as it considers the object valid as long as there's at LEAST one match. Let's switch to "oneOf" and disallows the other property if one exists, precisely matching the original binding and avoiding future confusion on the driver's behavior. Fixes: e69f5dc623f9 ("dt-bindings: serial: Convert 8250 to json-schema") Cc: stable <stable@kernel.org> Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250623093445.62327-1-ziyao@disroot.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-27arm64: spectre: increase parameters that can be used to turn off bhb ↵Liu Song1-0/+5
mitigation individually [ Upstream commit 877ace9eab7de032f954533afd5d1ecd0cf62eaf ] In our environment, it was found that the mitigation BHB has a great impact on the benchmark performance. For example, in the lmbench test, the "process fork && exit" test performance drops by 20%. So it is necessary to have the ability to turn off the mitigation individually through cmdline, thus avoiding having to compile the kernel by adjusting the config. Signed-off-by: Liu Song <liusong@linux.alibaba.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/1661514050-22263-1-git-send-email-liusong@linux.alibaba.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Pu Lehui <pulehui@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-27Revert "x86/bugs: Make spectre user default depend on MITIGATION_SPECTRE_V2" ↵Breno Leitao1-2/+0
on v6.6 and older This reverts commit 4fc2d289b3cc4cf23ccabe59cf936d1dc49aeda8 which is commit 98fdaeb296f51ef08e727a7cc72e5b5c864c4f4d upstream. commit 7adb96687ce8 ("x86/bugs: Make spectre user default depend on MITIGATION_SPECTRE_V2") depends on commit 72c70f480a70 ("x86/bugs: Add a separate config for Spectre V2"), which introduced MITIGATION_SPECTRE_V2. commit 72c70f480a70 ("x86/bugs: Add a separate config for Spectre V2") never landed in stable tree, thus, stable tree doesn't have MITIGATION_SPECTRE_V2, that said, commit 7adb96687ce8 ("x86/bugs: Make spectre user default depend on MITIGATION_SPECTRE_V2") has no value if the dependecy was not applied. Revert commit 7adb96687ce8 ("x86/bugs: Make spectre user default depend on MITIGATION_SPECTRE_V2") in stable kernel which landed in in 5.4.294, 5.10.238, 5.15.185, 6.1.141 and 6.6.93 stable versions. Cc: David.Kaplan@amd.com Cc: peterz@infradead.org Cc: pawan.kumar.gupta@linux.intel.com Cc: mingo@kernel.org Cc: brad.spengler@opensrcsec.com Cc: stable@vger.kernel.org # 6.6 6.1 5.15 5.10 5.4 Reported-by: Brad Spengler <brad.spengler@opensrcsec.com> Reported-by: Salvatore Bonaccorso <carnil@debian.org> Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-04x86/bugs: Make spectre user default depend on MITIGATION_SPECTRE_V2Breno Leitao1-0/+2
[ Upstream commit 98fdaeb296f51ef08e727a7cc72e5b5c864c4f4d ] Change the default value of spectre v2 in user mode to respect the CONFIG_MITIGATION_SPECTRE_V2 config option. Currently, user mode spectre v2 is set to auto (SPECTRE_V2_USER_CMD_AUTO) by default, even if CONFIG_MITIGATION_SPECTRE_V2 is disabled. Set the spectre_v2 value to auto (SPECTRE_V2_USER_CMD_AUTO) if the Spectre v2 config (CONFIG_MITIGATION_SPECTRE_V2) is enabled, otherwise set the value to none (SPECTRE_V2_USER_CMD_NONE). Important to say the command line argument "spectre_v2_user" overwrites the default value in both cases. When CONFIG_MITIGATION_SPECTRE_V2 is not set, users have the flexibility to opt-in for specific mitigations independently. In this scenario, setting spectre_v2= will not enable spectre_v2_user=, and command line options spectre_v2_user and spectre_v2 are independent when CONFIG_MITIGATION_SPECTRE_V2=n. Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: David Kaplan <David.Kaplan@amd.com> Link: https://lore.kernel.org/r/20241031-x86_bugs_last_v2-v2-2-b7ff1dab840e@debian.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-22x86/its: Add "vmexit" option to skip mitigation on some CPUsPawan Gupta1-0/+2
commit 2665281a07e19550944e8354a2024635a7b2714a upstream. Ice Lake generation CPUs are not affected by guest/host isolation part of ITS. If a user is only concerned about KVM guests, they can now choose a new cmdline option "vmexit" that will not deploy the ITS mitigation when CPU is not affected by guest/host isolation. This saves the performance overhead of ITS mitigation on Ice Lake gen CPUs. When "vmexit" option selected, if the CPU is affected by ITS guest/host isolation, the default ITS mitigation is deployed. Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-22x86/its: Enable Indirect Target Selection mitigationPawan Gupta2-0/+14
commit f4818881c47fd91fcb6d62373c57c7844e3de1c0 upstream. Indirect Target Selection (ITS) is a bug in some pre-ADL Intel CPUs with eIBRS. It affects prediction of indirect branch and RETs in the lower half of cacheline. Due to ITS such branches may get wrongly predicted to a target of (direct or indirect) branch that is located in the upper half of the cacheline. Scope of impact =============== Guest/host isolation -------------------- When eIBRS is used for guest/host isolation, the indirect branches in the VMM may still be predicted with targets corresponding to branches in the guest. Intra-mode ---------- cBPF or other native gadgets can be used for intra-mode training and disclosure using ITS. User/kernel isolation --------------------- When eIBRS is enabled user/kernel isolation is not impacted. Indirect Branch Prediction Barrier (IBPB) ----------------------------------------- After an IBPB, indirect branches may be predicted with targets corresponding to direct branches which were executed prior to IBPB. This is mitigated by a microcode update. Add cmdline parameter indirect_target_selection=off|on|force to control the mitigation to relocate the affected branches to an ITS-safe thunk i.e. located in the upper half of cacheline. Also add the sysfs reporting. When retpoline mitigation is deployed, ITS safe-thunks are not needed, because retpoline sequence is already ITS-safe. Similarly, when call depth tracking (CDT) mitigation is deployed (retbleed=stuff), ITS safe return thunk is not used, as CDT prevents RSB-underflow. To not overcomplicate things, ITS mitigation is not supported with spectre-v2 lfence;jmp mitigation. Moreover, it is less practical to deploy lfence;jmp mitigation on ITS affected parts anyways. Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-22Documentation: x86/bugs/its: Add ITS documentationPawan Gupta2-0/+157
commit 1ac116ce6468670eeda39345a5585df308243dca upstream. Add the admin-guide for Indirect Target Selection (ITS). Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-02scsi: libsas: Delete lldd_clear_aca callbackJohn Garry1-2/+0
[ Upstream commit 25882c82f850e3e972a973e0af310b3e58de38fd ] This callback is never called, so remove support. Link: https://lore.kernel.org/r/1645112566-115804-4-git-send-email-john.garry@huawei.com Tested-by: Yihang Li <liyihang6@hisilicon.com> Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Jack Wang <jinpu.wang@ionos.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Stable-dep-of: 8aa580cd9284 ("scsi: hisi_sas: Enable force phy when SATA disk directly connected") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-04-10sched/isolation: Prevent boot crash when the boot CPU is nohz_fullOleg Nesterov1-5/+2
Documentation/timers/no_hz.rst states that the "nohz_full=" mask must not include the boot CPU, which is no longer true after: 08ae95f4fd3b ("nohz_full: Allow the boot CPU to be nohz_full"). However after: aae17ebb53cd ("workqueue: Avoid using isolated cpus' timers on queue_delayed_work") the kernel will crash at boot time in this case; housekeeping_any_cpu() returns an invalid CPU number until smp_init() brings the first housekeeping CPU up. Change housekeeping_any_cpu() to check the result of cpumask_any_and() and return smp_processor_id() in this case. This is just the simple and backportable workaround which fixes the symptom, but smp_processor_id() at boot time should be safe at least for type == HK_TYPE_TIMER, this more or less matches the tick_do_timer_boot_cpu logic. There is no worry about cpu_down(); tick_nohz_cpu_down() will not allow to offline tick_do_timer_cpu (the 1st online housekeeping CPU). [ Apply only documentation changes as commit which causes boot crash when boot CPU is nohz_full is not backported to stable kernels - Krishanth ] Reported-by: Chris von Recklinghausen <crecklin@redhat.com> Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Phil Auld <pauld@redhat.com> Acked-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/r/20240411143905.GA19288@redhat.com Closes: https://lore.kernel.org/all/20240402105847.GA24832@redhat.com/ Signed-off-by: Krishanth Jagaduri <Krishanth.Jagaduri@sony.com> [ strip out upstream commit and Fixes: so tools don't get confused that this commit actually does anything real - gregkh] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-13kfence: allow use of a deferrable timerMarco Elver1-0/+12
[ Upstream commit 737b6a10ac19e41877aa1911bf6b361a72a88ad9 ] Allow the use of a deferrable timer, which does not force CPU wake-ups when the system is idle. A consequence is that the sample interval becomes very unpredictable, to the point that it is not guaranteed that the KFENCE KUnit test still passes. Nevertheless, on power-constrained systems this may be preferable, so let's give the user the option should they accept the above trade-off. Link: https://lkml.kernel.org/r/20220308141415.3168078-1-elver@google.com Signed-off-by: Marco Elver <elver@google.com> Reviewed-by: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Stable-dep-of: e64f81946adf ("kfence: skip __GFP_THISNODE allocations on NUMA systems") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-13kconfig: add warn-unknown-symbols sanity checkSergey Senozhatsky1-0/+9
[ Upstream commit 7cd343008b967423b06af8f6d3236749c67d12e8 ] Introduce KCONFIG_WARN_UNKNOWN_SYMBOLS environment variable, which makes Kconfig warn about unknown config symbols. This is especially useful for continuous kernel uprevs when some symbols can be either removed or renamed between kernel releases (which can go unnoticed otherwise). By default KCONFIG_WARN_UNKNOWN_SYMBOLS generates warnings, which are non-terminal. There is an additional environment variable KCONFIG_WERROR that overrides this behaviour and turns warnings into errors. Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Stable-dep-of: a409fc1463d6 ("kconfig: fix memory leak in sym_warn_unmet_dep()") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-13dt-bindings: mfd: bd71815: Fix rsense and typosMatti Vaittinen1-10/+10
[ Upstream commit 6856edf7ead8c54803216a38a7b227bcb3dadff7 ] The sense resistor used for measuring currents is typically some tens of milli Ohms. It has accidentally been documented to be tens of mega Ohms. Fix the size of this resistor and a few copy-paste errors while at it. Drop the unsuitable 'rohm,charger-sense-resistor-ohms' property (which can't represent resistors smaller than one Ohm), and introduce a new 'rohm,charger-sense-resistor-micro-ohms' property with appropriate minimum, maximum and default values instead. Fixes: 4238dc1e6490 ("dt_bindings: mfd: Add ROHM BD71815 PMIC") Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/0efd8e9de0ae8d62ee4c6b78cc565b04007a245d.1731430700.git.mazziesaccount@gmail.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-13regulator: dt-bindings: mt6315: Drop regulator-compatible propertyChen-Yu Tsai1-6/+0
[ Upstream commit 08242719a8af603db54a2a79234a8fe600680105 ] The "regulator-compatible" property has been deprecated since 2012 in commit 13511def87b9 ("regulator: deprecate regulator-compatible DT property"), which is so old it's not even mentioned in the converted regulator bindings YAML file. It should not have been used for new submissions such as the MT6315. Drop the property from the MT6315 regulator binding and its examples. Fixes: 977fb5b58469 ("regulator: document binding for MT6315 regulator") Fixes: 6d435a94ba5b ("regulator: mt6315: Enforce regulator-compatible, not name") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20241211052427.4178367-2-wenst@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-13dt-bindings: leds: class-multicolor: Fix path to color definitionsGeert Uytterhoeven1-1/+1
[ Upstream commit 609bc99a4452ffbce82d10f024a85d911c42e6cd ] The LED color definitions have always been in include/dt-bindings/leds/common.h in upstream. Fixes: 5c7f8ffe741daae7 ("dt: bindings: Add multicolor class dt bindings documention") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/a3c7ea92e90b77032f2e480d46418b087709286d.1731588129.git.geert+renesas@glider.be Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-13dt-bindings: leds: class-multicolor: reference class directly in multi-led nodeKrzysztof Kozlowski5-19/+24
[ Upstream commit de40c8496ead3e25d1e989999eed0c3ecee8fc96 ] The leds/common.yaml is referenced directly in each LED node, which leads to people doing the same with leds/leds-class-multicolor.yaml. This is not correct because leds-class-multicolor.yaml defined multi-led property and its children. Some schemas implemented this incorrect. Rework this to match same behavior common.yaml, so expect the multi-led node to reference the leds-class-multicolor.yaml. Fixing allows to add unevaluatedProperties:false. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Pavel Machek <pavel@ucw.cz> Stable-dep-of: 609bc99a4452 ("dt-bindings: leds: class-multicolor: Fix path to color definitions") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-13dt-bindings: leds: Add multicolor PWM LED bindingsSven Schwermer1-0/+79
[ Upstream commit ac123741b8f52311af118f8a052b1cbbed041291 ] This allows to group multiple PWM-connected monochrome LEDs into multicolor LEDs, e.g. RGB LEDs. Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Pavel Machek <pavel@ucw.cz> Stable-dep-of: 609bc99a4452 ("dt-bindings: leds: class-multicolor: Fix path to color definitions") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-13dt-bindings: leds: Optional multi-led unit addressSven Schwermer1-1/+1
[ Upstream commit 21c0d13e3dd64581bab0ef4b4d0fea7752cc236b ] The unit address does not make sense in all cases the multi-led node is used, e.g. for the upcoming PWM multi-color LED driver. Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Pavel Machek <pavel@ucw.cz> Stable-dep-of: 609bc99a4452 ("dt-bindings: leds: class-multicolor: Fix path to color definitions") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-13dt-bindings: leds: Add Qualcomm Light Pulse Generator bindingBjorn Andersson1-0/+173
[ Upstream commit a8e53db46f19f67be6a26488aafb7d10c78e33bd ] This adds the binding document describing the three hardware blocks related to the Light Pulse Generator found in a wide range of Qualcomm PMICs. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by: Pavel Machek <pavel@ucw.cz> Stable-dep-of: 609bc99a4452 ("dt-bindings: leds: class-multicolor: Fix path to color definitions") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-13dt-bindings: Another pass removing cases of 'allOf' containing a '$ref'Rob Herring20-69/+36
[ Upstream commit dca669354e6ff494222dfc461bed1087264f3755 ] Another pass at removing unnecessary use of 'allOf' with a '$ref'. json-schema versions draft7 and earlier have a weird behavior in that any keywords combined with a '$ref' are ignored (silently). The correct form was to put a '$ref' under an 'allOf'. This behavior is now changed in the 2019-09 json-schema spec and '$ref' can be mixed with other keywords. Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Guenter Roeck <groeck@chromium.org> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Sebastian Reichel <sre@kernel.org> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Mark Brown <broonie@kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-By: Vinod Koul <vkoul@kernel.org> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Marek Behún <kabel@kernel.org> Acked-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220228213802.1639658-1-robh@kernel.org Stable-dep-of: 609bc99a4452 ("dt-bindings: leds: class-multicolor: Fix path to color definitions") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-13spi: dt-bindings: add schema listing peripheral-specific propertiesPratyush Yadav2-67/+89
[ Upstream commit 8762b07c95c18fbbe1c6b3eb1e8e686091c346b5 ] 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> Stable-dep-of: 609bc99a4452 ("dt-bindings: leds: class-multicolor: Fix path to color definitions") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-03-13dt-bindings: mmc: controller: clarify the address-cells descriptionNeil Armstrong1-1/+1
[ Upstream commit b2b8e93ec00b8110cb37cbde5400d5abfdaed6a7 ] The term "slot ID" has nothing to do with the SDIO function number which is specified in the reg property of the subnodes, rephrase the description to be more accurate. Fixes: f9b7989859dd ("dt-bindings: mmc: Add YAML schemas for the generic MMC options") Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Acked-by: Rob Herring (Arm) <robh@kernel.org> Message-ID: <20241128-topic-amlogic-arm32-upstream-bindings-fixes-convert-meson-mx-sdio-v4-1-11d9f9200a59@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-01-09dt-bindings: display: adi,adv7533: Drop single lane supportBiju Das1-1/+1
commit ee8f9ed57a397605434caeef351bafa3ec4dfdd4 upstream. As per [1] and [2], ADV7535/7533 supports only 2-, 3-, or 4-lane. Drop unsupported 1-lane from bindings. [1] https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7535.pdf [2] https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7533.pdf Fixes: 1e4d58cd7f88 ("drm/bridge: adv7533: Create a MIPI DSI device") Cc: stable@vger.kernel.org Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241119192040.152657-3-biju.das.jz@bp.renesas.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-19Documentation: PM: Clarify pm_runtime_resume_and_get() return valuePaul Barker1-1/+3
[ Upstream commit ccb84dc8f4a02e7d30ffd388522996546b4d00e1 ] Update the documentation to match the behaviour of the code. pm_runtime_resume_and_get() always returns 0 on success, even if __pm_runtime_resume() returns 1. Fixes: 2c412337cfe6 ("PM: runtime: Add documentation for pm_runtime_resume_and_get()") Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com> Link: https://patch.msgid.link/20241203143729.478-1-paul.barker.ct@bp.renesas.com [ rjw: Subject and changelog edits, adjusted new comment formatting ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-14PCI: Add 'reset_subordinate' to reset hierarchy below bridgeKeith Busch1-0/+11
[ Upstream commit 2fa046449a82a7d0f6d9721dd83e348816038444 ] The "bus" and "cxl_bus" reset methods reset a device by asserting Secondary Bus Reset on the bridge leading to the device. These only work if the device is the only device below the bridge. Add a sysfs 'reset_subordinate' attribute on bridges that can assert Secondary Bus Reset regardless of how many devices are below the bridge. This resets all the devices below a bridge in a single command, including the locking and config space save/restore that reset methods normally do. This may be the only way to reset devices that don't support other reset methods (ACPI, FLR, PM reset, etc). Link: https://lore.kernel.org/r/20241025222755.3756162-1-kbusch@meta.com Signed-off-by: Keith Busch <kbusch@kernel.org> [bhelgaas: commit log, add capable(CAP_SYS_ADMIN) check] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-14dt-bindings: serial: rs485: Fix rs485-rts-delay propertyMichal Simek1-10/+9
[ Upstream commit 12b3642b6c242061d3ba84e6e3050c3141ded14c ] Code expects array only with 2 items which should be checked. But also item checking is not working as it should likely because of incorrect items description. Fixes: d50f974c4f7f ("dt-bindings: serial: Convert rs485 bindings to json-schema") Signed-off-by: Michal Simek <michal.simek@amd.com> Cc: stable@vger.kernel.org Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/820c639b9e22fe037730ed44d1b044cdb6d28b75.1726480384.git.michal.simek@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-01-23 21:04:35 +0300