summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)Author
2025-05-12docs/mm/damon/design: fix spelling mistakeThushara.M.S
The word accuracy was misspelled as "accruracy". Signed-off-by: Thushara.M.S <thusharms@gmail.com> Reviewed-by: SeongJae Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-12Documentation: KHO: add memblock bindingsMike Rapoport (Microsoft)
We introduced KHO into Linux: A framework that allows Linux to pass metadata and memory across kexec from Linux to Linux. KHO reuses fdt as file format and shares a lot of the same properties of firmware-to- Linux boot formats: It needs a stable, documented ABI that allows for forward and backward compatibility as well as versioning. As first user of KHO, we introduced memblock which can now preserve memory ranges reserved with reserve_mem command line options contents across kexec, so you can use the post-kexec kernel to read traces from the pre-kexec kernel. This patch adds memblock schemas similar to "device" device tree ones to a new kho bindings directory. This allows us to force contributors to document the data that moves across KHO kexecs and catch breaking change during review. Link: https://lkml.kernel.org/r/20250509074635.3187114-18-changyuanl@google.com Co-developed-by: Alexander Graf <graf@amazon.com> Signed-off-by: Alexander Graf <graf@amazon.com> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Changyuan Lyu <changyuanl@google.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Anthony Yznaga <anthony.yznaga@oracle.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Ashish Kalra <ashish.kalra@amd.com> Cc: Ben Herrenschmidt <benh@kernel.crashing.org> Cc: Borislav Betkov <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Eric Biederman <ebiederm@xmission.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Gowans <jgowans@amazon.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Marc Rutland <mark.rutland@arm.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Pasha Tatashin <pasha.tatashin@soleen.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Pratyush Yadav <ptyadav@amazon.de> Cc: Rob Herring <robh@kernel.org> Cc: Saravana Kannan <saravanak@google.com> Cc: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Thomas Gleinxer <tglx@linutronix.de> Cc: Thomas Lendacky <thomas.lendacky@amd.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-12Documentation: add documentation for KHOAlexander Graf
With KHO in place, let's add documentation that describes what it is and how to use it. Link: https://lkml.kernel.org/r/20250509074635.3187114-17-changyuanl@google.com Signed-off-by: Alexander Graf <graf@amazon.com> Co-developed-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Co-developed-by: Changyuan Lyu <changyuanl@google.com> Signed-off-by: Changyuan Lyu <changyuanl@google.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Anthony Yznaga <anthony.yznaga@oracle.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Ashish Kalra <ashish.kalra@amd.com> Cc: Ben Herrenschmidt <benh@kernel.crashing.org> Cc: Borislav Betkov <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Eric Biederman <ebiederm@xmission.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Gowans <jgowans@amazon.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Marc Rutland <mark.rutland@arm.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Pasha Tatashin <pasha.tatashin@soleen.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Pratyush Yadav <ptyadav@amazon.de> Cc: Rob Herring <robh@kernel.org> Cc: Saravana Kannan <saravanak@google.com> Cc: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Thomas Gleinxer <tglx@linutronix.de> Cc: Thomas Lendacky <thomas.lendacky@amd.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-12mm: add max swappiness arg to lru_gen for anonymous memory onlyZhongkun He
The MGLRU already supports reclaiming only from anonymous memory via the /sys/kernel/debug/lru_gen interface. Now, memory.reclaim also supports the swappiness=max parameter to enable reclaiming solely from anonymous memory. To unify the semantics of proactive reclaiming from anonymous folios, the max parameter is introduced. [hezhongkun.hzk@bytedance.com: use strcmp instead of strncmp, if swappiness is not set, use the default value] Link: https://lkml.kernel.org/r/20250507071057.3184240-1-hezhongkun.hzk@bytedance.com [akpm@linux-foundation.org: tweak coding style] Link: https://lkml.kernel.org/r/65181f7745d657d664d833c26d8a94cae40538b9.1745225696.git.hezhongkun.hzk@bytedance.com Signed-off-by: Zhongkun He <hezhongkun.hzk@bytedance.com> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Yosry Ahmed <yosry.ahmed@linux.dev> Cc: Yu Zhao <yuzhao@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-12mm: add swappiness=max arg to memory.reclaim for only anon reclaimZhongkun He
Patch series "add max arg to swappiness in memory.reclaim and lru_gen", v4. This patchset adds max arg to swappiness in memory.reclaim and lru_gen for anon only proactive memory reclaim. With commit <68cd9050d871> ("mm: add swappiness= arg to memory.reclaim") we can submit an additional swappiness=<val> argument to memory.reclaim. It is very useful because we can dynamically adjust the reclamation ratio based on the anonymous folios and file folios of each cgroup. For example,when swappiness is set to 0, we only reclaim from file folios. But we can not relciam memory just from anon folios. This patchset introduces a new macro, SWAPPINESS_ANON_ONLY, defined as MAX_SWAPPINESS + 1, represent the max arg semantics. It specifically indicates that reclamation should occur only from anonymous pages. Patch 1 adds swappiness=max arg to memory.reclaim suggested-by: Yosry Ahmed Patch 2 add more comments for cache_trim_mode from Johannes Weiner in [1]. Patch 3 add max arg to lru_gen for proactive memory reclaim in MGLRU. The MGLRU already supports reclaiming exclusively from anonymous pages. This patch formalizes that behavior by introducing a max parameter to represent the corresponding semantics. Patch 4 using SWAPPINESS_ANON_ONLY in MGLRU Using SWAPPINESS_ANON_ONLY instead of MAX_SWAPPINESS + 1 to indicate reclaiming only from anonymous pages makes the code more readable and explicit Here is the previous discussion: https://lore.kernel.org/all/20250314033350.1156370-1-hezhongkun.hzk@bytedance.com/ https://lore.kernel.org/all/20250312094337.2296278-1-hezhongkun.hzk@bytedance.com/ https://lore.kernel.org/all/20250318135330.3358345-1-hezhongkun.hzk@bytedance.com/ This patch (of 4): With commit <68cd9050d871> ("mm: add swappiness= arg to memory.reclaim") we can submit an additional swappiness=<val> argument to memory.reclaim. It is very useful because we can dynamically adjust the reclamation ratio based on the anonymous folios and file folios of each cgroup. For example,when swappiness is set to 0, we only reclaim from file folios. However,we have also encountered a new issue: when swappiness is set to the MAX_SWAPPINESS, it may still only reclaim file folios. So, we hope to add a new arg 'swappiness=max' in memory.reclaim where proactive memory reclaim only reclaims from anonymous folios when swappiness is set to max. The swappiness semantics from a user perspective remain unchanged. For example, something like this: echo "2M swappiness=max" > /sys/fs/cgroup/memory.reclaim will perform reclaim on the rootcg with a swappiness setting of 'max' (a new mode) regardless of the file folios. Users have a more comprehensive view of the application's memory distribution because there are many metrics available. For example, if we find that a certain cgroup has a large number of inactive anon folios, we can reclaim only those and skip file folios, because with the zram/zswap, the IO tradeoff that cache_trim_mode or other file first logic is making doesn't hold - file refaults will cause IO, whereas anon decompression will not. With this patch, the swappiness argument of memory.reclaim has a new mode 'max', means reclaiming just from anonymous folios both in traditional LRU and MGLRU. Link: https://lkml.kernel.org/r/cover.1745225696.git.hezhongkun.hzk@bytedance.com Link: https://lore.kernel.org/all/20250314141833.GA1316033@cmpxchg.org/ [1] Link: https://lkml.kernel.org/r/519e12b9b1f8c31a01e228c8b4b91a2419684f77.1745225696.git.hezhongkun.hzk@bytedance.com Signed-off-by: Zhongkun He <hezhongkun.hzk@bytedance.com> Suggested-by: Yosry Ahmed <yosry.ahmed@linux.dev> Acked-by: Muchun Song <muchun.song@linux.dev> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Yu Zhao <yuzhao@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-12memcg-introduce-non-blocking-limit-setting-option-v3Shakeel Butt
add more explanation in doc and commit message on O_NONBLOCK side-effects (Johannes) Link: https://lkml.kernel.org/r/20250506232833.3109790-1-shakeel.butt@linux.dev Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev> Acked-by: Roman Gushchin <roman.gushchin@linux.dev> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Greg Thelen <gthelen@google.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Michal Koutný <mkoutny@suse.com> Cc: Muchun Song <muchun.song@linux.dev> Cc: Tejun Heo <tj@kernel.org> Cc: Yosry Ahmed <yosry.ahmed@linux.dev> Cc: Christian Brauner <brauner@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-12memcg: introduce non-blocking limit setting optionShakeel Butt
Setting the max and high limits can trigger synchronous reclaim and/or oom-kill if the usage is higher than the given limit. This behavior is fine for newly created cgroups but it can cause issues for the node controller while setting limits for existing cgroups. In our production multi-tenant and overcommitted environment, we are seeing priority inversion when the node controller dynamically adjusts the limits of running jobs of different priorities. Based on the system situation, the node controller may reduce the limits of lower priority jobs and increase the limits of higher priority jobs. However we are seeing node controller getting stuck for long period of time while reclaiming from lower priority jobs while setting their limits and also spends a lot of its own CPU. One of the workaround we are trying is to fork a new process which sets the limit of the lower priority job along with setting an alarm to get itself killed if it get stuck in the reclaim for lower priority job. However we are finding it very unreliable and costly. Either we need a good enough time buffer for the alarm to be delivered after setting limit and potentialy spend a lot of CPU in the reclaim or be unreliable in setting the limit for much shorter but cheaper (less reclaim) alarms. Let's introduce new limit setting option which does not trigger reclaim and/or oom-kill and let the processes in the target cgroup to trigger reclaim and/or throttling and/or oom-kill in their next charge request. This will make the node controller on multi-tenant overcommitted environment much more reliable. Explanation from Johannes on side-effects of O_NONBLOCK limit change: It's usually the allocating tasks inside the group bearing the cost of limit enforcement and reclaim. This allows a (privileged) updater from outside the group to keep that cost in there - instead of having to help, from a context that doesn't necessarily make sense. I suppose the tradeoff with that - and the reason why this was doing sync reclaim in the first place - is that, if the group is idle and not trying to allocate more, it can take indefinitely for the new limit to actually be met. It should be okay in most scenarios in practice. As the capacity is reallocated from group A to B, B will exert pressure on A once it tries to claim it and thereby shrink it down. If A is idle, that shouldn't be hard. If A is running, it's likely to fault/allocate soon-ish and then join the effort. It does leave a (malicious) corner case where A is just busy-hitting its memory to interfere with the clawback. This is comparable to reclaiming memory.low overage from the outside, though, which is an acceptable risk. Users of O_NONBLOCK just need to be aware. Link: https://lkml.kernel.org/r/20250419183545.1982187-1-shakeel.butt@linux.dev Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev> Acked-by: Roman Gushchin <roman.gushchin@linux.dev> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Michal Hocko <mhocko@suse.com> Cc: Greg Thelen <gthelen@google.com> Cc: Michal Koutný <mkoutny@suse.com> Cc: Muchun Song <muchun.song@linux.dev> Cc: Tejun Heo <tj@kernel.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Yosry Ahmed <yosry.ahmed@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-12vmscan,cgroup: apply mems_effective to reclaimGregory Price
It is possible for a reclaimer to cause demotions of an lruvec belonging to a cgroup with cpuset.mems set to exclude some nodes. Attempt to apply this limitation based on the lruvec's memcg and prevent demotion. Notably, this may still allow demotion of shared libraries or any memory first instantiated in another cgroup. This means cpusets still cannot cannot guarantee complete isolation when demotion is enabled, and the docs have been updated to reflect this. This is useful for isolating workloads on a multi-tenant system from certain classes of memory more consistently - with the noted exceptions. Note on locking: The cgroup_get_e_css reference protects the css->effective_mems, and calls of this interface would be subject to the same race conditions associated with a non-atomic access to cs->effective_mems. So while this interface cannot make strong guarantees of correctness, it can therefore avoid taking a global or rcu_read_lock for performance. Link: https://lkml.kernel.org/r/20250424202806.52632-3-gourry@gourry.net Signed-off-by: Gregory Price <gourry@gourry.net> Suggested-by: Shakeel Butt <shakeel.butt@linux.dev> Suggested-by: Waiman Long <longman@redhat.com> Acked-by: Tejun Heo <tj@kernel.org> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev> Reviewed-by: Waiman Long <longman@redhat.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Michal Koutný <mkoutny@suse.com> Cc: Muchun Song <muchun.song@linux.dev> Cc: Roman Gushchin <roman.gushchin@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-12Update Christoph's Email address and make it consistentChristoph Lameter (Ampere)
Use cl@gentwo.org throughout and remove the old email addresses. Link: https://lkml.kernel.org/r/8b962f57-4d98-cbb0-cd82-b6ba456733e8@gentwo.org Signed-off-by: Christoph Lameter <cl@gentwo.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-12Docs/ABI/damon: document nid fileSeongJae Park
Add a description of 'nid' file, which is optionally used for specific DAMOS quota goal metrics such as node_mem_{used,free}_bp on the DAMON sysfs ABI document. Link: https://lkml.kernel.org/r/20250420194030.75838-7-sj@kernel.org Signed-off-by: SeongJae Park <sj@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Yunjeong Mun <yunjeong.mun@sk.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-12Docs/admin-guide/mm/damon/usage: document 'nid' fileSeongJae Park
Add description of 'nid' file, which is optionally used for specific DAMOS quota goal metrics such as node_mem_{used,free}_bp on DAMON usage document. Link: https://lkml.kernel.org/r/20250420194030.75838-6-sj@kernel.org Signed-off-by: SeongJae Park <sj@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Yunjeong Mun <yunjeong.mun@sk.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-12Docs/mm/damon/design: document node_mem_{used,free}_bpSeongJae Park
Add description of DAMOS quota goal metrics for NUMA node utilization on the DAMON deesign document. Link: https://lkml.kernel.org/r/20250420194030.75838-5-sj@kernel.org Signed-off-by: SeongJae Park <sj@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Yunjeong Mun <yunjeong.mun@sk.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-13Merge 6.15-rc6 into usb-nextGreg Kroah-Hartman
We need the USB fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-12Merge branch 'for-6.16/tsm-mr' into tsm-nextDan Williams
Merge measurement-register infrastructure for v6.16. Resolve conflicts with the establishment of drivers/virt/coco/guest/ for cross-vendor common TSM functionality. Address a mis-merge with a fixup from Lukas: Link: http://lore.kernel.org/20250509134031.70559-1-lukas.bulwahn@redhat.com
2025-05-12scsi: docs: Clean up some style in scsi_mid_low_apiRandy Dunlap
Capitalize Linux but not "kernel." Spell out Linux instead of using "lk". Hyphenate "system-wide." Hyphenate "32-bit". End a sentence with a period (full stop). Change "double linked" to "doubly linked" list. Use SCSI or scsi but not Scsi. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20250502015136.683691-1-rdunlap@infradead.org Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2025-05-12dt-bindings: vertexcom-mse102x: Fix IRQ type in exampleStefan Wahren
According to the MSE102x documentation the trigger type is a high level. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20250509120435.43646-2-wahrenst@gmx.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-12dt-bindings: net: renesas-gbeth: Add support for RZ/V2N (R9A09G056) SoCLad Prabhakar
Document support for the GBETH IP found on the Renesas RZ/V2N (R9A09G056) SoC. The GBETH controller on the RZ/V2N SoC is functionally identical to the one found on the RZ/V2H(P) (R9A09G057) SoC, so `renesas,rzv2h-gbeth` will be used as a fallback compatible. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20250507173551.100280-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-12hwmon: Add KEBA fan controller supportGerhard Engleder
The KEBA fan controller is found in the system FPGA of KEBA PLC devices. It detects if the fan is removed or blocked. For fans with tacho signal the monitoring of the speed of the fan is supported. It also supports to regulate the speed of fans with PWM input. The auxiliary device for this driver is instantiated by the cp500 misc driver. Signed-off-by: Gerhard Engleder <eg@keba.com> Link: https://lore.kernel.org/r/20250425194823.54664-1-gerhard@engleder-embedded.com [groeck: Added various missing "break;" statements] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-05-12dt-bindings: cache: qcom,llcc: Document SM8750 LLCC blockMelody Olvera
Add documentation for the SM8750 LLCC. Signed-off-by: Melody Olvera <melody.olvera@oss.qualcomm.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250512-sm8750_llcc_master-v5-1-d78dca6282a5@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-12hwmon: pmbus: mpq8785: Add support for MPM3695 familyPawel Dembicki
Add support for the Monolithic Power Systems MPM3695 family. It contains four devices with suffixes: -10, -20, -25 and -100. The device is PMBus compliant and shares characteristics with the MPM82504. MPM3695-25 has different VOLTAGE_SCALE_LOOP register size [11:0] and therefore needs to have a separate compatible entry. Tested with device tree based matching (MPM3695-10). Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com> Link: https://lore.kernel.org/r/20250511035701.2607947-6-paweldembicki@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-05-12hwmon: pmbus: mpq8785: Add support for MPM82504Pawel Dembicki
Add support for the Monolithic Power Systems MPM82504 digital voltage regulator. MPM82504 uses PMBus direct format for voltage output. Tested with device tree based matching. Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com> Link: https://lore.kernel.org/r/20250511035701.2607947-5-paweldembicki@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-05-12dt-bindings: hwmon: Add bindings for mpq8785 driverPawel Dembicki
Add device tree bindings for Monolithic Power Systems MPQ8785, MPM82504 and MPM3695 PMBus-compliant voltage regulators. These bindings also documents the optional "mps,vout-fb-divider-ratio-permille" property. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250511035701.2607947-2-paweldembicki@gmail.com Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-05-12hwmon: (ina238) Add support for SQ52206Wenliang Yan
Add support for SQ52206 to the Ina238 driver. Add registers, increase compatibility, add compatibility programs for multiple chips. Signed-off-by: Wenliang Yan <wenliang202407@163.com> Link: https://lore.kernel.org/r/20250506053741.4837-3-wenliang202407@163.com [groeck: Fixed checkpatch issues (alignment, {} placing)] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-05-12dt-bindings: Add SQ52206 to ina2xx devicetree bindingsWenliang Yan
Add the sq52206 compatible to the ina2xx.yaml Signed-off-by: Wenliang Yan <wenliang202407@163.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250506053741.4837-5-wenliang202407@163.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-05-12dt-bindings: display/msm: hdmi: Fix constraints on additional 'port' propertiesRob Herring (Arm)
The MSM HDMI port nodes are missing any restrictions on additional properties. The $ref should be to "/properties/port" rather than "/$defs/port-base" as there are not additional properties in the nodes to define. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/652299/ Link: https://lore.kernel.org/r/20250507215912.2748964-1-robh@kernel.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-05-12dt-bindings: display/msm/hdmi: drop obsolete GPIOs from schemaDmitry Baryshkov
The commit 68e674b13b17 ("drm/msm/hdmi: drop unused GPIO support") dropped support for obsolete qcom,hdmi-tx-mux-* gpios. They were not used by any of the upstream platforms. Drop them from the bindings too. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/651708/ Link: https://lore.kernel.org/r/20250505-fd-hdmi-hpd-v5-1-48541f76318c@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-05-12dt-bindings: allwinner: add H616 DE33 clock bindingRyan Walklin
The Allwinner H616 and variants have a new display engine revision (DE33). Add a clock binding for the DE33. Signed-off-by: Ryan Walklin <ryan@testtoast.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Link: https://patch.msgid.link/20250511104042.24249-7-ryan@testtoast.com Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-05-12dt-bindings: cache: add specific RZ/Five compatible to ax45mpConor Dooley
When the binding was originally written, it was assumed that all ax45mp-caches had the same properties etc. This has turned out to be incorrect, as the QiLai SoC has a different number of cache-sets. Add a specific compatible for the RZ/Five for property enforcement and in case there turns out to be additional differences between these implementations of the cache controller. Acked-by: Ben Zong-You Xie <ben717@andestech.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-05-12ACPI: Add documentation for exposing MRRM dataTony Luck
Initial implementation provides enumeration of the address ranges NUMA node numbers, and BIOS assigned region IDs for each range. Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://patch.msgid.link/20250505173819.419271-4-tony.luck@intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-05-12Merge tag 'imx-bindings-6.16' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into soc/dt i.MX dt-bindings change for 6.16: - New compatibles for TQ Group boards, i.MX943 EVK, Nitrogen8M Plus ENC Carrier, phyBOARD-Nash-i.MX93 and phyCORE-i.MX8MP FPSC from PHYTEC, and Toradex SMARC iMX8MP SoM/carrier * tag 'imx-bindings-6.16' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: bindings: arm: fsl: Add PHYTEC phyBOARD-Nash-i.MX93 board dt: bindings: arm: add bindings for TQMa95xxSA dt-bindings: arm: add TQMa8XxS boards dt-bindings: arm: fsl: add i.MX943 EVK board dt-bindings: arm: add imx8mp-libra-rdk-fpsc dt-bindings: arm: add MBa91xxCA Mainboard for TQMa93xxCA/LA SOM dt-bindings: arm: fsl: add Toradex SMARC iMX8MP SoM and carrier dt-bindings: arm: fsl: Add Boundary Device Nitrogen8M Plus ENC Carrier Board Link: https://lore.kernel.org/r/20250512103858.50501-2-shawnguo@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-05-12Merge 6.15-rc6 into driver-core-nextGreg Kroah-Hartman
We need the driver core fix in here as well for testing Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-05-12Merge branch 'cznic/platform' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc into soc/drivers These are updates from Marek Behún for the cznic platform drivers: This series adds support for generating ECDSA signatures with hardware stored private key on Turris Omnia and Turris MOX. This ability is exposed via the keyctl() syscall. * 'cznic/platform' of https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: platform: cznic: use ffs() instead of __bf_shf() firmware: turris-mox-rwtm: fix building without CONFIG_KEYS platform: cznic: fix function parameter names firmware: turris-mox-rwtm: Add support for ECDSA signatures with HW private key firmware: turris-mox-rwtm: Drop ECDSA signatures via debugfs platform: cznic: turris-omnia-mcu: Add support for digital message signing with HW private key platform: cznic: Add keyctl helpers for Turris platform platform: cznic: turris-omnia-mcu: Refactor requesting MCU interrupt Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-05-12platform/x86: dell-ddv: Expose the battery health to userspaceArmin Wolf
The health of a given battery is exposed over the Dell DDV WMI interface using the "BatteryManufactureAceess" WMI method. The resulting data contains, among other data, the health status of the battery. Expose this value to userspace using the power supply extension interface. Tested on a Dell Inspiron 3505. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20250429003606.303870-4-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-05-12platform/x86: dell-ddv: Expose the battery manufacture date to userspaceArmin Wolf
The manufacture date of a given battery is exposed over the Dell DDV WMI interface using the "BatteryManufactureDate" WMI method. The resulting data contains the manufacture date of the battery encoded inside a 16-bit value as described in the Smart Battery Data Specification. Expose this value to userspace using the power supply extension interface. Tested on a Dell Inspiron 3505. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20250429003606.303870-3-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-05-12platform/x86: dell-ddv: Implement the battery matching algorithmArmin Wolf
Since commit db0a507cb24d ("ACPICA: Update integer-to-hex-string conversions") the battery serial number is no longer distorted, allowing us to finally implement the battery matching algorithm. The battery matchign algorithm is necessary when translating between ACPI batteries and the associated indices used by the WMI interface based on the battery serial number. Since this serial number can only be retrieved when the battery is present we cannot perform the initial translation inside dell_wmi_ddv_add_battery() because the ACPI battery might be absent at this point in time. Introduce dell_wmi_ddv_battery_translate() which implements the battery matching algorithm and replaces dell_wmi_ddv_battery_index(). Also implement a translation cache for caching previous translations between ACPI batteries and indices. This is necessary because performing a translation can be very expensive. Tested on a Dell Inspiron 3505. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://lore.kernel.org/r/20250429003606.303870-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-05-12power: supply: core: Add additional health status valuesArmin Wolf
Some batteries can signal when an internal fuse was blown. In such a case POWER_SUPPLY_HEALTH_DEAD is too vague for userspace applications to perform meaningful diagnostics. Additionally some batteries can also signal when some of their internal cells are imbalanced. In such a case returning POWER_SUPPLY_HEALTH_UNSPEC_FAILURE is again too vague for userspace applications to perform meaningful diagnostics. Add new health status values for both cases. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20250429003606.303870-1-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-05-12platform/x86/amd/hsmp: acpi: Add sysfs files to display HSMP telemetrySuma Hegde
Make frequently fetched telemetry available via sysfs. These parameters do not fit in hwmon sensor model, hence make them available via sysfs. Create following sysfs files per acpi device node. * c0_residency_input * prochot_status * smu_fw_version * protocol_version * ddr_max_bw(GB/s) * ddr_utilised_bw_input(GB/s) * ddr_utilised_bw_perc_input(%) * mclk_input(MHz) * fclk_input(MHz) * clk_fmax(MHz) * clk_fmin(MHz) * cclk_freq_limit_input(MHz) * pwr_current_active_freq_limit(MHz) * pwr_current_active_freq_limit_source Signed-off-by: Suma Hegde <suma.hegde@amd.com> Reviewed-by: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20250506101542.200811-3-suma.hegde@amd.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-05-12platform/x86/amd/hsmp: Report power via hwmon sensorsSuma Hegde
Expose power reading and power limits via hwmon power sensors. Signed-off-by: Suma Hegde <suma.hegde@amd.com> Reviewed-by: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com> Link: https://lore.kernel.org/r/20250506101542.200811-2-suma.hegde@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-05-12docs: filesystems: add fuse-passthrough.rstChen Linxuan
Add a documentation about FUSE passthrough. It's mainly about why FUSE passthrough needs CAP_SYS_ADMIN. Link: https://lore.kernel.org/all/4b64a41c-6167-4c02-8bae-3021270ca519@fastmail.fm/T/#mc73e04df56b8830b1d7b06b5d9f22e594fba423e Link: https://lore.kernel.org/linux-fsdevel/CAOQ4uxhAY1m7ubJ3p-A3rSufw_53WuDRMT1Zqe_OC0bP_Fb3Zw@mail.gmail.com/ Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Chen Linxuan <chenlinxuan@uniontech.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
2025-05-12dt-bindings: arm: vt8500: Add VIA APC Rock/Paper boardsAlexey Charkov
APC Rock is a development board based on WonderMedia WM8950 SoC released around 2013. Paper is the same as Rock but lacking a VGA port and shipped with a recycled cardboard case. While at that, put myself as the maintainer, given that Tony is unavailable as of lately. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Alexey Charkov <alchark@gmail.com> Link: https://lore.kernel.org/r/20250425-apc_paper_binding-v5-1-3aef49e97332@gmail.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-05-12Revert "kbuild: make all file references relative to source root"Thomas Weißschuh
This reverts commit cacd22ce69585a91c386243cd662ada962431e63. -ffile-prefix-map breaks the ability of debuggers to find the source file corresponding to object files. As there is no simple or uniform way to specify the source directory explicitly, this breaks developers workflows. Revert the unconditional usage of -ffile-prefix-map. Reported-by: Matthieu Baerts <matttbe@kernel.org> Closes: https://lore.kernel.org/lkml/edc50aa7-0740-4942-8c15-96f12f2acc7e@kernel.org/ Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Closes: https://lore.kernel.org/lkml/aBEttQH4kimHFScx@intel.com/ Fixes: cacd22ce6958 ("kbuild: make all file references relative to source root") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-05-11scripts/gdb: update documentation for lx_per_cpuIllia Ostapyshyn
Commit db08c53fdd542bb7f83b ("scripts/gdb: fix parameter handling in $lx_per_cpu") changed the parameter handling of lx_per_cpu to use GdbValue instead of parsing the variable name. Update the documentation to reflect the new lx_per_cpu usage. Update the hrtimer_bases example to use rb_tree instead of the timerqueue_head.next pointer removed in commit 511885d7061eda3eb1fa ("lib/timerqueue: Rely on rbtree semantics for next timer"). Link: https://lkml.kernel.org/r/20250503123234.2407184-3-illia@yshyn.com Signed-off-by: Illia Ostapyshyn <illia@yshyn.com> Cc: Alex Shi <alexs@kernel.org> Cc: Brendan Jackman <jackmanb@google.com> Cc: Dongliang Mu <dzm91@hust.edu.cn> Cc: Florian Rommel <mail@florommel.de> Cc: Hu Haowen <2023002089@link.tyut.edu.cn> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Yanteng Si <si.yanteng@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-11relay: remove unused relay_late_setup_filesDr. David Alan Gilbert
The last use of relay_late_setup_files() was removed in 2018 by commit 2b47733045aa ("drm/i915/guc: Merge log relay file and channel creation") Remove it and the helper it used. relay_late_setup_files() was used for eventually registering 'buffer only' channels. With it gone, delete the docs that explain how to do that. Which suggests it should be possible to lose the 'has_base_filename' flags. (Are there any other uses??) Link: https://lkml.kernel.org/r/20250418234932.490863-1-linux@treblig.org Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Reviewed-by: Jens Axboe <axboe@kernel.dk> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Andriy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-11crash: export PAGE_UNACCEPTED_MAPCOUNT_VALUE to vmcoreinfoZhiquan Li
On Intel TDX guest, unaccepted memory is unusable free memory which is not managed by buddy, until it's accepted by guest. Before that, it cannot be accessed by the first kernel as well as the kexec'ed kernel. The kexec'ed kernel will skip these pages and fill in zero data for the reader of vmcore. The dump tool like makedumpfile creates a page descriptor (size 24 bytes) for each non-free page, including zero data page, but it will not create descriptor for free pages. If it is not able to distinguish these unaccepted pages with zero data pages, a certain amount of space will be wasted in proportion (~1/170). In fact, as a special kind of free page the unaccepted pages should be excluded, like the real free pages. Export the page type PAGE_UNACCEPTED_MAPCOUNT_VALUE to vmcoreinfo, so that dump tool can identify whether a page is unaccepted. [zhiquan1.li@intel.com: fix docs: "Title underline too short" warning] Link: https://lore.kernel.org/all/20240809114854.3745464-5-kirill.shutemov@linux.intel.com/ Link: https://lkml.kernel.org/r/20250405060610.860465-1-zhiquan1.li@intel.com Link: https://lore.kernel.org/all/20240809114854.3745464-5-kirill.shutemov@linux.intel.com/ Link: https://lkml.kernel.org/r/20250403030801.758687-1-zhiquan1.li@intel.com Signed-off-by: Zhiquan Li <zhiquan1.li@intel.com> Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by: Baoquan He <bhe@redhat.com> Cc: Dave Young <dyoung@redhat.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Zhiquan Li <zhiquan1.li@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-11Documentation: zram: update IDLE pages tracking documentationSergey Senozhatsky
Move IDLE pages tracking into a separate chapter because there are multiple features that use (or depend on) it either in built-in variant ("mark all") or in extended variant (ac-time tracking). In addition, recompression doesn't require memory tracking to be enabled in order to be able to perform idle recompression. Link: https://lkml.kernel.org/r/20250416042833.3858827-1-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> Reported-by: Shin Kawamura <kawasin@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Minchan Kim <minchan@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-11fs/proc: extend the PAGEMAP_SCAN ioctl to report guard regionsAndrei Vagin
Patch series "fs/proc: extend the PAGEMAP_SCAN ioctl to report guard regions", v2. Introduce the PAGE_IS_GUARD flag in the PAGEMAP_SCAN ioctl to expose information about guard regions. This allows userspace tools, such as CRIU, to detect and handle guard regions. Currently, CRIU utilizes PAGEMAP_SCAN as a more efficient alternative to parsing /proc/pid/pagemap. Without this change, guard regions are incorrectly reported as swap-anon regions, leading CRIU to attempt dumping them and subsequently failing. The series includes updates to the documentation and selftests to reflect the new functionality. This patch (of 3): Introduce the PAGE_IS_GUARD flag in the PAGEMAP_SCAN ioctl to expose information about guard regions. This allows userspace tools, such as CRIU, to detect and handle guard regions. Link: https://lkml.kernel.org/r/20250324065328.107678-1-avagin@google.com Link: https://lkml.kernel.org/r/20250324065328.107678-2-avagin@google.com Signed-off-by: Andrei Vagin <avagin@gmail.com> Acked-by: David Hildenbrand <david@redhat.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Shuah Khan <shuah@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-11mm/compaction: reduce the difference between low and high watermarksMichal Clapinski
Reduce the diff between low and high watermarks when compaction proactiveness is set to high. This allows users who set the proactiveness really high to have more stable fragmentation score over time. Link: https://lkml.kernel.org/r/20250404111103.1994507-3-mclapinski@google.com Signed-off-by: Michal Clapinski <mclapinski@google.com> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-11zram: modernize writeback interfaceSergey Senozhatsky
The writeback interface supports a page_index=N parameter which performs writeback of the given page. Since we rarely need to writeback just one single page, the typical use case involves a number of writeback calls, each performing writeback of one page: echo page_index=100 > zram0/writeback ... echo page_index=200 > zram0/writeback echo page_index=500 > zram0/writeback ... echo page_index=700 > zram0/writeback One obvious downside of this is that it increases the number of syscalls. Less obvious, but a significantly more important downside, is that when given only one page to post-process zram cannot perform an optimal target selection. This becomes a critical limitation when writeback_limit is enabled, because under writeback_limit we want to guarantee the highest memory savings hence we first need to writeback pages that release the highest amount of zsmalloc pool memory. This patch adds page_indexes=LOW-HIGH parameter to the writeback interface: echo page_indexes=100-200 page_indexes=500-700 > zram0/writeback This gives zram a chance to apply an optimal target selection strategy on each iteration of the writeback loop. We also now permit multiple page_index parameters per call (previously zram would recognize only one page_index) and a mix or single pages and page ranges: echo page_index=42 page_index=99 page_indexes=100-200 \ page_indexes=500-700 > zram0/writeback Apart from that the patch also unifies parameters passing and resembles other "modern" zram device attributes (e.g. recompression), while the old interface used a mixed scheme: values-less parameters for mode and a key=value format for page_index. We still support the "old" value-less format for compatibility reasons. [senozhatsky@chromium.org: simplify parse_page_index() range checks, per Brian] nk: https://lkml.kernel.org/r/20250404015327.2427684-1-senozhatsky@chromium.org [sozhatsky@chromium.org: fix uninitialized variable in zram_writeback_slots(), per Dan] nk: https://lkml.kernel.org/r/20250409112611.1154282-1-senozhatsky@chromium.org Link: https://lkml.kernel.org/r/20250327015818.4148660-1-senozhatsky@chromium.org Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> Reviewed-by: Brian Geffon <bgeffon@google.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Richard Chang <richardycc@google.com> Cc: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-05-11Merge tag 'its-for-linus-20250509' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 ITS mitigation from Dave Hansen: "Mitigate Indirect Target Selection (ITS) issue. I'd describe this one as a good old CPU bug where the behavior is _obviously_ wrong, but since it just results in bad predictions it wasn't wrong enough to notice. Well, the researchers noticed and also realized that thus bug undermined a bunch of existing indirect branch mitigations. Thus the unusually wide impact on this one. Details: ITS is a bug in some Intel CPUs that affects indirect branches including RETs in the first half of a cacheline. Due to ITS such branches may get wrongly predicted to a target of (direct or indirect) branch that is located in the second half of a cacheline. Researchers at VUSec found this behavior and reported to Intel. Affected processors: - Cascade Lake, Cooper Lake, Whiskey Lake V, Coffee Lake R, Comet Lake, Ice Lake, Tiger Lake and Rocket Lake. 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 direct branches in the guest. - Intra-mode using cBPF: cBPF can be used to poison the branch history to exploit ITS. Realigning the indirect branches and RETs mitigates this attack vector. - User/kernel: With eIBRS enabled user/kernel isolation is *not* impacted by ITS. - Indirect Branch Prediction Barrier (IBPB): Due to this bug indirect branches may be predicted with targets corresponding to direct branches which were executed prior to IBPB. This will be fixed in the microcode. Mitigation: As indirect branches in the first half of cacheline are affected, the mitigation is to replace those indirect branches with a call to thunk that is aligned to the second half of the cacheline. RETs that take prediction from RSB are not affected, but they may be affected by RSB-underflow condition. So, RETs in the first half of cacheline are also patched to a return thunk that executes the RET aligned to second half of cacheline" * tag 'its-for-linus-20250509' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: selftest/x86/bugs: Add selftests for ITS x86/its: FineIBT-paranoid vs ITS x86/its: Use dynamic thunks for indirect branches x86/ibt: Keep IBT disabled during alternative patching mm/execmem: Unify early execmem_cache behaviour x86/its: Align RETs in BHB clear sequence to avoid thunking x86/its: Add support for RSB stuffing mitigation x86/its: Add "vmexit" option to skip mitigation on some CPUs x86/its: Enable Indirect Target Selection mitigation x86/its: Add support for ITS-safe return thunk x86/its: Add support for ITS-safe indirect thunk x86/its: Enumerate Indirect Target Selection (ITS) bug Documentation: x86/bugs/its: Add ITS documentation
2025-05-12docs: rust: explain that `///` vs. `//` applies to private items tooMiguel Ojeda
Sometimes kernel developers use `//` for documenting private items, since those do not get rendered at the moment. That is reasonable, but the intention behind `///` (and `//!`) vs. `//` is to convey the distinction between documentation and other kinds of comments, such as implementation details or TODOs. It also increases consistency with the public items and thus e.g. allows to change visibility of an item with less changes involved. It is not just useful for human readers, but also tooling. For instance, we may want to eventually generate documentation for private items (perhaps as a toggle in the HTML UI). On top of that, `rustdoc` lints as usual for those, too, so we may want to do it even if we do not use the result. Thus document this explicitly. Link: https://lore.kernel.org/rust-for-linux/CANiq72n_C7exSOMe5yf-7jKKnhSCv+a9QcD=OE2B_Q2UFBL3Xg@mail.gmail.com/ Link: https://github.com/Rust-for-Linux/linux/issues/1157 Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Christian Schrefl <chrisi.schrefl@gmail.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20250416112454.2503872-1-ojeda@kernel.org [ Fixed typo. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>