linux-stable.git/Documentation, branch v6.1.136

sched/isolation: Prevent boot crash when the boot CPU is nohz_full

2025-03-28T20:58:48+00:00

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 
Signed-off-by: Oleg Nesterov 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Ingo Molnar 
Reviewed-by: Phil Auld 
Acked-by: Frederic Weisbecker 
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 
[ 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

mm: Don't pin ZERO_PAGE in pin_user_pages()

2025-03-07T15:56:47+00:00

[ Upstream commit c8070b78751955e59b42457b974bea4a4fe00187 ]

Make pin_user_pages*() leave a ZERO_PAGE unpinned if it extracts a pointer
to it from the page tables and make unpin_user_page*() correspondingly
ignore a ZERO_PAGE when unpinning.  We don't want to risk overrunning a
zero page's refcount as we're only allowed ~2 million pins on it -
something that userspace can conceivably trigger.

Add a pair of functions to test whether a page or a folio is a ZERO_PAGE.

Signed-off-by: David Howells 
cc: Christoph Hellwig 
cc: David Hildenbrand 
cc: Lorenzo Stoakes 
cc: Andrew Morton 
cc: Jens Axboe 
cc: Al Viro 
cc: Matthew Wilcox 
cc: Jan Kara 
cc: Jeff Layton 
cc: Jason Gunthorpe 
cc: Logan Gunthorpe 
cc: Hillf Danton 
cc: Christian Brauner 
cc: Linus Torvalds 
cc: linux-fsdevel@vger.kernel.org
cc: linux-block@vger.kernel.org
cc: linux-kernel@vger.kernel.org
cc: linux-mm@kvack.org
Reviewed-by: Lorenzo Stoakes 
Reviewed-by: Christoph Hellwig 
Acked-by: David Hildenbrand 
Link: https://lore.kernel.org/r/20230526214142.958751-2-dhowells@redhat.com
Signed-off-by: Jens Axboe 
Stable-dep-of: bddf10d26e6e ("uprobes: Reject the shared zeropage in uprobe_write_opcode()")
Signed-off-by: Sasha Levin

strparser: Add read_sock callback

2025-03-07T15:56:37+00:00

[ Upstream commit 0532a79efd68a4d9686b0385e4993af4b130ff82 ]

Added a new read_sock handler, allowing users to customize read operations
instead of relying on the native socket's read_sock.

Signed-off-by: Jiayuan Chen 
Signed-off-by: Martin KaFai Lau 
Reviewed-by: Jakub Sitnicki 
Acked-by: John Fastabend 
Link: https://patch.msgid.link/20250122100917.49845-2-mrpre@163.com
Stable-dep-of: 36b62df5683c ("bpf: Fix wrong copied_seq calculation")
Signed-off-by: Sasha Levin

kconfig: add warn-unknown-symbols sanity check

2025-02-21T12:49:24+00:00

[ 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 
Signed-off-by: Masahiro Yamada 
Stable-dep-of: a409fc1463d6 ("kconfig: fix memory leak in sym_warn_unmet_dep()")
Signed-off-by: Sasha Levin

dt-bindings: mfd: bd71815: Fix rsense and typos

2025-02-21T12:49:00+00:00

[ 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 
Acked-by: Conor Dooley 
Link: https://lore.kernel.org/r/0efd8e9de0ae8d62ee4c6b78cc565b04007a245d.1731430700.git.mazziesaccount@gmail.com
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

regulator: dt-bindings: mt6315: Drop regulator-compatible property

2025-02-21T12:49:00+00:00

[ 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 
Reviewed-by: AngeloGioacchino Del Regno 
Link: https://patch.msgid.link/20241211052427.4178367-2-wenst@chromium.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

dt-bindings: leds: class-multicolor: Fix path to color definitions

2025-02-21T12:48:59+00:00

[ 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 
Acked-by: Conor Dooley 
Link: https://lore.kernel.org/r/a3c7ea92e90b77032f2e480d46418b087709286d.1731588129.git.geert+renesas@glider.be
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

dt-bindings: mmc: controller: clarify the address-cells description

2025-02-21T12:48:59+00:00

[ 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 
Acked-by: Rob Herring (Arm) 
Message-ID: <20241128-topic-amlogic-arm32-upstream-bindings-fixes-convert-meson-mx-sdio-v4-1-11d9f9200a59@linaro.org>
Signed-off-by: Ulf Hansson 
Signed-off-by: Sasha Levin

dt-bindings: display: adi,adv7533: Drop single lane support

2025-01-09T12:30:06+00:00

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 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Biju Das 
Link: https://patchwork.freedesktop.org/patch/msgid/20241119192040.152657-3-biju.das.jz@bp.renesas.com
Signed-off-by: Dmitry Baryshkov 
Signed-off-by: Greg Kroah-Hartman

Documentation: PM: Clarify pm_runtime_resume_and_get() return value

2024-12-19T17:08:56+00:00

[ 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 
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 
Signed-off-by: Sasha Levin