Commit graph

1,412,004 commits

Author SHA1 Message Date
Mauro Carvalho Chehab
ce062cdc2e docs: media: add missing c namespace to V4L headers
Media references belong to V4L namespace. Fix a lot of broken
links when including videodev2.h and probably fixing several
other broken cross-references between different files inside
media docs.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <b69fc5bd43da7d326b9f4720df59388088c64065.1759329363.git.mchehab+huawei@kernel.org>
2025-10-17 13:56:59 -06:00
Mauro Carvalho Chehab
11578a2ecb docs: kernel_include.py: use get_close_matches() to propose alternatives
Improve the suggestions algorithm by using get_close_matches() if
no suggestions with the same name are found. As we're now building
a dict, when the name is identical, but on a different domain,
the search is O(1), making it a lot faster.

The get_close_matches is also fast, as there is just one loop,
instead of 3.

This can be useful to detect typos on references, with could
be the base of a futuere extension that will handle ref unmatches
for the entire build, allowing someone to find typos and fix them.

As difflib and get_close_matches are there since the early
Python 3.x days, we don't need to handle any extra dependencies
to use it.

We're keeping the default values for the search, e.g. n=3, cutoff=0.6.
With that, we now have things like:

  $ make SPHINXDIRS="userspace-api/media" htmldocs
  ...
  include/uapi/linux/videodev2.h:199: WARNING: Invalid xref: c:type:`v4l2_memory`. Possible alternatives:
        c:type:`v4l2_meta_format` (from v4l/dev-meta)
        c:type:`v4l2_rect` (from v4l/dev-overlay)
        c:type:`v4l2_area` (from v4l/ext-ctrls-image-source) [ref.missing]
  ...
  include/uapi/linux/videodev2.h:1985: WARNING: Invalid xref: c:type:`V4L.v4l2_queryctrl`. Possible alternatives:
        std🏷️`v4l2-queryctrl` (from v4l/vidioc-queryctrl)
        std🏷️`v4l2-query-ext-ctrl` (from v4l/vidioc-queryctrl)

At the first example, it was not a typo, but a symbol that doesn't
seem to be properly documented. The second example points to
v4l2-queryctrl, which is a close match for the symbol.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <7365feb74cbdd6b982c87baf5863360ab98cf727.1759329363.git.mchehab+huawei@kernel.org>
2025-10-17 13:56:59 -06:00
Mauro Carvalho Chehab
2792fc7307 docs: media: mediactl: use TOC instead of file contents
All we wanted were to have a way to link the comprehensive
documentation with the actual symbols parsed from the header
file, as this helps to identify any broken references.

Use the new :toc: flag for media controller and enable warnings.

Here, we need to adjust the exceptions file to setup the C
namespace accordingly.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <5c8a87be712397563fc8ca914c3d92fe675e4071.1759329363.git.mchehab+huawei@kernel.org>
2025-10-17 13:56:59 -06:00
Mauro Carvalho Chehab
94d95887ea docs: media: rc: use TOC instead of file contents for LIRC header
All we wanted were to have a way to link the comprehensive
documentation with the actual symbols parsed from the header
file, as this helps to identify any broken references.

Use the new :toc: flag for LIRC and enable warnings.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <94dc601b4777ca544489ffc6cef9a2da5fe28e0e.1759329363.git.mchehab+huawei@kernel.org>
2025-10-17 13:56:59 -06:00
Mauro Carvalho Chehab
a75968226c docs: media: dvb: enable warnings for most headers
Except for two exception rules and dmx.h, the other files
are already handling properly cross references.

Fix the two exception rules for frontend.h, as those are
false-positives:

	include/uapi/linux/dvb/frontend.h:959: WARNING: can't link to: c:type:: FE_GET_PROPERTY
	include/uapi/linux/dvb/frontend.h:933: WARNING: can't link to: c:func:: FE_SET_FRONTEND_TUNE_MODE

The dmx.h are actual issues that will require an extra
patch to fill gaps.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <9ae6556ebd47de4f066a149ab0bbe7ce27acf2c4.1759329363.git.mchehab+huawei@kernel.org>
2025-10-17 13:56:59 -06:00
Mauro Carvalho Chehab
f0eb1b4ce7 docs: media: dvb: use TOC instead of file contents at headers
All we wanted were to have a way to link the comprehensive
documentation with the actual symbols parsed from the header
file, as this helps to identify any broken references.

Use the new :toc: flag for DVB.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <dbe95d83ae2117ed532fda423fd1c1d9906b7a19.1759329363.git.mchehab+huawei@kernel.org>
2025-10-17 13:56:59 -06:00
Mauro Carvalho Chehab
d2a72e1f27 tools: docs: parse_data_structs.py: accept more reftypes
Current regex is limited to only some c-domain reftypes.
There are several others.

Change the code to pick the name specified there.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <5c146923d1e3183893f290216fb1378954e2e540.1759329363.git.mchehab+huawei@kernel.org>
2025-10-17 13:56:59 -06:00
Mauro Carvalho Chehab
7f809e6a6f tools: docs: parse_data_structs.py: add namespace support
C domain supports a ".. c:namespace::" tag that allows setting a
symbol namespace. This is used within the kernel to avoid warnings
about duplicated symbols. This is specially important for syscalls,
as each subsystem may have their own documentation for them.
This is specially true for ioctl.

When such tag is used, all C domain symbols have c++ style,
e.g. they'll become "{namespace}.{reference}".

Allow specifying C namespace at the exception files, avoiding
the need of override rules for every symbol.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <cc27ec60ceb3bdac4197fb7266d2df8155edacda.1759329363.git.mchehab+huawei@kernel.org>
2025-10-17 13:56:59 -06:00
Mauro Carvalho Chehab
2cdd27a708 tools: docs: parse_data_structs.py: get rid of process_exceptions()
Add an extra parameter to parse_file to make it handle exceptions
internally, cleaning up the API.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <8575bbc94ff706aa7e7cc3a188399ca17a3169e6.1759329363.git.mchehab+huawei@kernel.org>
2025-10-17 13:56:59 -06:00
Mauro Carvalho Chehab
9e4173432e tools: docs: parse_data_structs: make process_exceptions two stages
Split the logic which parses exceptions on two stages, preparing
the exceptions file to have rules that will affect xref generation.

For now, preserve the original API.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <da9ca5f2ce1ffcfb355e32e676ff013607c227e0.1759329363.git.mchehab+huawei@kernel.org>
2025-10-17 13:56:59 -06:00
Mauro Carvalho Chehab
641a4a13f3 docs: kernel_include.py: propose alternatives
Specially when using c::namespace, it is not hard to break
a reference by forgetting to add a domain. Also, different
cases and using "-"/"_" the wrong way are typical cases that
people often gets wrong.

We might use a more complex logic here to also check for typos,
but let's keep it plain, simple.

This is enough to get thos exeptions from media controller:

  .../include/uapi/linux/media.h:26: WARNING: Invalid xref: c:type:`media_device_info`. Possible alternatives:
	c:type:`MC.media_device_info` (from mediactl/media-ioc-device-info)
  .../include/uapi/linux/media.h:149: WARNING: Invalid xref: c:type:`media_entity_desc`. Possible alternatives:
	c:type:`MC.media_entity_desc` (from mediactl/media-ioc-enum-entities)
  .../include/uapi/linux/media.h:228: WARNING: Invalid xref: c:type:`media_link_desc`. Possible alternatives:
	c:type:`MC.media_link_desc` (from mediactl/media-ioc-enum-links)
  .../include/uapi/linux/media.h:235: WARNING: Invalid xref: c:type:`media_links_enum`. Possible alternatives:
	c:type:`MC.media_links_enum` (from mediactl/media-ioc-enum-links)
  .../include/uapi/linux/media.h:212: WARNING: Invalid xref: c:type:`media_pad_desc`. Possible alternatives:
	c:type:`MC.media_pad_desc` (from mediactl/media-ioc-enum-links)
  .../include/uapi/linux/media.h:298: WARNING: Invalid xref: c:type:`media_v2_entity`. Possible alternatives:
	c:type:`MC.media_v2_entity` (from mediactl/media-ioc-g-topology)
  .../include/uapi/linux/media.h:312: WARNING: Invalid xref: c:type:`media_v2_interface`. Possible alternatives:
	c:type:`MC.media_v2_interface` (from mediactl/media-ioc-g-topology)
  .../include/uapi/linux/media.h:307: WARNING: Invalid xref: c:type:`media_v2_intf_devnode`. Possible alternatives:
	c:type:`MC.media_v2_intf_devnode` (from mediactl/media-ioc-g-topology)
  .../include/uapi/linux/media.h:341: WARNING: Invalid xref: c:type:`media_v2_link`. Possible alternatives:
	c:type:`MC.media_v2_link` (from mediactl/media-ioc-g-topology)
  .../include/uapi/linux/media.h:333: WARNING: Invalid xref: c:type:`media_v2_pad`. Possible alternatives:
	c:type:`MC.media_v2_pad` (from mediactl/media-ioc-g-topology)
  .../include/uapi/linux/media.h:349: WARNING: Invalid xref: c:type:`media_v2_topology`. Possible alternatives:
	c:type:`MC.media_v2_topology` (from mediactl/media-ioc-g-topology)

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <4c75d277e950e619ea00ba2dea336853a4aac976.1759329363.git.mchehab+huawei@kernel.org>
2025-10-17 13:56:59 -06:00
Mauro Carvalho Chehab
3ed9521772 docs: kernel_include.py: fix line numbers for TOC
On TOC output, we need to embeed line numbers with ViewList.

Change the parse class to produce a line-number parsed result,
and adjust the output accordingly.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <74eed96e32f79eaaef7a99ffe7c3224fed369c27.1759329363.git.mchehab+huawei@kernel.org>
2025-10-17 13:56:59 -06:00
Mauro Carvalho Chehab
ba9fbb3d9a tools: docs: parse_data_structs.py: output a line number
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <dcffa6844dede00052f5fb851a857991468f22b5.1759329363.git.mchehab+huawei@kernel.org>
2025-10-17 13:56:59 -06:00
Mauro Carvalho Chehab
ba99100687 tools: docs: parse_data_structs.py: drop contents header
When used in practice, one may want to have multiple header
files on a single rst file, like:

	***********************
	Digital TV uAPI symbols
	***********************

	.. contents:: Table of Contents
	   :depth: 2
	   :local:

	Frontend
	========

	.. kernel-include:: include/uapi/linux/dvb/frontend.h
	    :generate-cross-refs:
	    :toc:

	Demux
	=====

	.. kernel-include:: include/uapi/linux/dvb/dmx.h
	    :generate-cross-refs:
	    :toc:

	...

So, don't add ..contents:: here.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <4bf353e5248133a3b0abd82519a38453402fe7c6.1759329363.git.mchehab+huawei@kernel.org>
2025-10-17 13:56:59 -06:00
Imre Deak
c390bf0796 drm/i915/dp: Fix panel replay when DSC is enabled
Prevent enabling panel replay if the sink doesn't support this due to
DSC being enabled.

Panel replay has two modes, updating full frames or only selected
regions of the frame. If the sink doesn't support Panel Replay in full
frame update mode with DSC prevent Panel Replay completely if DSC is
enabled. If the sink doesn't support Panel Replay only in the selective
update mode while DSC is enabled, it will still support Panel Replay in
the full frame update mode, so only prevent selective updates in this
case.

v2:
- Use Panel Replay instead of PR in debug prints. (Jouni)
- Rebase on change tracking the link DSC state in the crtc state.

Cc: Jouni Högander <jouni.hogander@intel.com>
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14869
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20251015161934.262108-8-imre.deak@intel.com
2025-10-17 21:48:57 +03:00
Imre Deak
470b84af45 drm/i915/dp_mst: Recompute all MST link CRTCs if DSC gets enabled on the link
The state of all the CRTCs on an MST link must be recomputed, if DSC
gets enabled on any of the CRTCs on the link. For instance an MST
docking station's Panel Replay capability may depend on whether DSC is
enabled on any of the dock's streams (aka CRTCs). To assist the Panel
Replay state computation for a CRTC based on the above, track in the
CRTC state if DSC is enabled on any CRTC on an MST link.

The intel_link_bw_limits::force_fec_pipes mask is used for a reason
similar to the above: enable FEC on all CRTCs of a non-UHBR (8b10b) MST
link if DSC is enabled on any of the link's CRTCs. The FEC enabled state
for a CRTC doesn't indicate if DSC is enabled on a UHBR MST link (FEC is
always enabled by the HW for UHBR, hence it's not tracked by the
intel_crtc_state::fec_enable flag for such links, where this flag is
always false).

Based on the above, to be able to determine the DSC state on both
non-UHBR and UHBR MST links, track the more generic DSC-enabled-on-link
state (instead of the FEC-enabled-on-link state) for each CRTC in
intel_link_bw_limits.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251015161934.262108-7-imre.deak@intel.com
2025-10-17 21:48:52 +03:00
Imre Deak
7c027070e9 drm/i915/dp_mst: Track DSC enabled status on the MST link
Track whether DSC is enabled on any CRTC on a link. On DP-SST (and DSI)
this will always match the CRTC's DSC state, those links having only a
single stream (aka CRTC). For instance, on DP-MST if DSC is enabled for
CRTC#0, but disabled for CRTC#1, the DSC/FEC state for these CRTCs will
be as follows:

CRTC#0:
 - compression_enable = true
 - compression_enabled_on_link = true
 - fec_enable = true for 8b10b, false for 128b132b

CRTC#1:
 - compression_enable = false
 - compression_enabled_on_link = true
 - fec_enable = true for 8b10b, false for 128b132b

This patch only sets compression_enabled_on_link for CRTC#0 above and
enables FEC on CRTC#0 if DSC was enabled on any other CRTC on the 8b10b
MST link. A follow-up change will make sure that the state of all the
CRTCs (CRTC#1 above) on an MST link is recomputed if DSC gets enabled on
any CRTC, setting compression_enabled_on_link and fec_enable for these.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251015161934.262108-6-imre.deak@intel.com
2025-10-17 21:48:47 +03:00
Imre Deak
b762ae4829 drm/i915/dp_mst: Reuse the DP-SST helper function to compute FEC config
Reuse the DP-SST helper to compute the state for the FEC enabled state
for DP-MST as well.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251015161934.262108-5-imre.deak@intel.com
2025-10-17 21:48:40 +03:00
Imre Deak
cb6c8f1f6f drm/i915/dp: Export helper to determine if FEC on non-UHBR links is required
Export the helper function to determine if FEC is required on a non-UHBR
(8b10b) SST or MST link. A follow up change will take this into use for
MST as well.

While at it determine the output type from the CRTC state, which allows
dropping the intel_dp argument. Also make the function return the
required FEC state, instead of setting this in the CRTC state, which
allows only querying this requirement, without changing the state.

Also rename the function to intel_dp_needs_8b10b_fec(), to clarify that
the function determines if FEC is required on an 8b10b link (on 128b132b
links FEC is always enabled by the HW implicitly, so the function will
return false for that case).

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251015161934.262108-4-imre.deak@intel.com
2025-10-17 21:48:34 +03:00
Imre Deak
69df31263b drm/i915/dp: Ensure the FEC state stays disabled for UHBR links
Atm, in the DP SST case the FEC state is computed before
intel_crtc_state::port_clock is initialized, hence intel_dp_is_uhbr()
will always return false and the FEC state will be always computed
assuming a non-UHBR link.

This happens to work, since the FEC state is recomputed later in
intel_dp_mtp_tu_compute_config(), where port_clock will be set already,
so intel_crtc_state::fec_enable will be reset as expected for UHBR. This
also depends on link rates being tried in an increasing order (i.e. from
non-UHBR -> UHBR link rates) in dsc_compute_link_config(), thus
intel_crtc_state::fec_enable being set for the non-UHBR rates and
getting reset for the first UHBR rate as expected.

A follow-up change will reuse intel_dp_fec_compute_config() for the DP
MST state computation, prepare for that here, making sure that the
function determines the correct intel_crtc_state::fec_enable=false state
for UHBR link rates based on the above.

The DP SST and MST state computation should be further unified to avoid
computing/setting the intel_crtc_state::fec_enable state multiple times,
but that's left for a follow-up change. For now add only code comments
about this.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251015161934.262108-3-imre.deak@intel.com
2025-10-17 21:48:27 +03:00
Imre Deak
c88e70dc8b drm/i915/dsc: Add helper to enable the DSC configuration for a CRTC
Add a helper to enable the DSC compression configuration for a CRTC.
Follow-up changes will introduce tracking for the same DSC state on the
whole link, which will need to be set whenever DSC is enabled for the
CRTC. Also, according to the above, when querying the DSC state on the
link, both the CRTC's and the link's DSC state must be considered.

Setting the DSC configuration for a CRTC and querying the DSC
configuration for the link (added by follow-up changes) is better done
via helper functions based on the above, prepare for that here.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251015161934.262108-2-imre.deak@intel.com
2025-10-17 21:48:00 +03:00
Brahmajit Das
a1e83d4c03 selftests/bpf: Fix redefinition of 'off' as different kind of symbol
This fixes the following build error

   CLNG-BPF [test_progs] verifier_global_ptr_args.bpf.o
progs/verifier_global_ptr_args.c:228:5: error: redefinition of 'off' as
different kind of symbol
   228 | u32 off;
       |     ^

The symbol 'off' was previously defined in
tools/testing/selftests/bpf/tools/include/vmlinux.h, which includes an
enum i40e_ptp_gpio_pin_state from
drivers/net/ethernet/intel/i40e/i40e_ptp.c:

	enum i40e_ptp_gpio_pin_state {
		end = -2,
		invalid = -1,
		off = 0,
		in_A = 1,
		in_B = 2,
		out_A = 3,
		out_B = 4,
	};

This enum is included when CONFIG_I40E is enabled. As of commit
032676ff82 ("LoongArch: Update Loongson-3 default config file"),
CONFIG_I40E is set in the defconfig, which leads to the conflict.

Renaming the local variable avoids the redefinition and allows the
build to succeed.

Suggested-by: Yonghong Song <yonghong.song@linux.dev>
Signed-off-by: Brahmajit Das <listout@listout.xyz>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20251017171551.53142-1-listout@listout.xyz
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-10-17 11:33:23 -07:00
Han Gao
fac4be7b3d riscv: dts: thead: add zfh for th1520
th1520 support Zfh ISA extension.
It supports the same RISC-V extensions as SG2042.

commit cb074bed11 ("riscv: dts: sophgo: add zfh for sg2042")

Signed-off-by: Han Gao <rabenda.cn@gmail.com>
Reviewed-by: Drew Fustini <fustini@kernel.org>
Signed-off-by: Drew Fustini <fustini@kernel.org>
2025-10-17 11:32:41 -07:00
Han Gao
bcc3b9c5de riscv: dts: thead: add ziccrse for th1520
Existing rv64 hardware conforms to the rva20 profile.

Ziccrse is an additional extension required by the rva20 profile, so
th1520 has this extension.

Signed-off-by: Han Gao <rabenda.cn@gmail.com>
Reviewed-by: Drew Fustini <fustini@kernel.org>
Signed-off-by: Drew Fustini <fustini@kernel.org>
2025-10-17 11:32:41 -07:00
Han Gao
aef6dc0066 riscv: dts: thead: add xtheadvector to the th1520 devicetree
The th1520 support xtheadvector [1] so it can be included in the
devicetree. Also include vlenb for the cpu. And set vlenb=16 [2].

This can be tested by passing the "mitigations=off" kernel parameter.

Link: https://lore.kernel.org/linux-riscv/20241113-xtheadvector-v11-4-236c22791ef9@rivosinc.com/ [1]
Link: https://lore.kernel.org/linux-riscv/aCO44SAoS2kIP61r@ghost/ [2]

Signed-off-by: Han Gao <rabenda.cn@gmail.com>
Reviewed-by: Drew Fustini <fustini@kernel.org>
Signed-off-by: Drew Fustini <fustini@kernel.org>
2025-10-17 11:32:41 -07:00
Sahil Chandna
7c33e97a6e bpf: Do not disable preemption in bpf_test_run().
The timer mode is initialized to NO_PREEMPT mode by default,
this disables preemption and force execution in atomic context
causing issue on PREEMPT_RT configurations when invoking
spin_lock_bh(), leading to the following warning:

BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6107, name: syz.0.17
preempt_count: 1, expected: 0
RCU nest depth: 1, expected: 1
Preemption disabled at:
[<ffffffff891fce58>] bpf_test_timer_enter+0xf8/0x140 net/bpf/test_run.c:42

Fix this, by removing NO_PREEMPT/NO_MIGRATE mode check.
Also, the test timer context no longer needs explicit calls to
migrate_disable()/migrate_enable() with rcu_read_lock()/rcu_read_unlock().
Use helpers rcu_read_lock_dont_migrate() and rcu_read_unlock_migrate()
instead.

Reported-by: syzbot+1f1fbecb9413cdbfbef8@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1f1fbecb9413cdbfbef8
Suggested-by: Yonghong Song <yonghong.song@linux.dev>
Suggested-by: Menglong Dong <menglong.dong@linux.dev>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Tested-by: syzbot+1f1fbecb9413cdbfbef8@syzkaller.appspotmail.com
Co-developed-by: Brahmajit Das <listout@listout.xyz>
Signed-off-by: Brahmajit Das <listout@listout.xyz>
Signed-off-by: Sahil Chandna <chandna.sahil@gmail.com>
Link: https://lore.kernel.org/r/20251014185635.10300-1-chandna.sahil@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-10-17 11:29:35 -07:00
Mark Brown
0cdb2b1b7e
spi: airoha: driver fixes & improvements
Merge series from Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>:

This patch series greatly improve airoha snfi driver and fix a
number of serious bugs.

Fixed bugs:
 * Fix reading/writing of flashes with more than one plane per lun
 * Fill the buffer with 0xff before writing
 * Fix reading of flashes supporting continuous reading mode
 * Fix error paths

Improvements:
 * Add support of dual/quad wires spi modes in exec_op(). This also
   fix flash reading/writing if dirmap can't be created.
 * Support of dualio/quadio flash reading commands
 * Remove dirty hack that reads flash page settings from SNFI registers
   during driver startup
 * Add support of EN7523 SoC

Patched kernel tests:

    root@OpenWrt:/lib/modules/6.6.79# insmod mtd_oobtest.ko dev=1
    [  263.191711]
    [  263.193218] =================================================
    [  263.199014] mtd_oobtest: MTD device: 1
    [  263.202768] mtd_oobtest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128
    [  263.216791] mtd_test: scanning for bad eraseblocks
    [  263.221956] mtd_test: scanned 2047 eraseblocks, 0 are bad
    [  263.227361] mtd_oobtest: test 1 of 5
    [  265.077216] mtd_oobtest: writing OOBs of whole device
    [  265.121767] mtd_oobtest: written up to eraseblock 0
    [  275.174147] mtd_oobtest: written up to eraseblock 256
    [  285.210279] mtd_oobtest: written up to eraseblock 512
    [  295.241724] mtd_oobtest: written up to eraseblock 768
    [  305.280167] mtd_oobtest: written up to eraseblock 1024
    [  315.326883] mtd_oobtest: written up to eraseblock 1280
    [  325.364049] mtd_oobtest: written up to eraseblock 1536
    [  335.398609] mtd_oobtest: written up to eraseblock 1792
    [  345.358981] mtd_oobtest: written 2047 eraseblocks
    [  345.363694] mtd_oobtest: verifying all eraseblocks
    [  345.386088] mtd_oobtest: verified up to eraseblock 0
    [  349.830833] mtd_oobtest: verified up to eraseblock 256
    [  354.276245] mtd_oobtest: verified up to eraseblock 512
    [  358.721496] mtd_oobtest: verified up to eraseblock 768
    [  363.166881] mtd_oobtest: verified up to eraseblock 1024
    [  367.612694] mtd_oobtest: verified up to eraseblock 1280
    [  372.058211] mtd_oobtest: verified up to eraseblock 1536
    [  376.503820] mtd_oobtest: verified up to eraseblock 1792
    [  380.914843] mtd_oobtest: verified 2047 eraseblocks
    [  380.919660] mtd_oobtest: test 2 of 5
    [  384.202620] mtd_oobtest: writing OOBs of whole device
    [  384.247584] mtd_oobtest: written up to eraseblock 0
    [  394.305121] mtd_oobtest: written up to eraseblock 256
    [  404.342199] mtd_oobtest: written up to eraseblock 512
    [  414.374204] mtd_oobtest: written up to eraseblock 768
    [  424.409891] mtd_oobtest: written up to eraseblock 1024
    [  434.453378] mtd_oobtest: written up to eraseblock 1280
    [  444.494321] mtd_oobtest: written up to eraseblock 1536
    [  454.534480] mtd_oobtest: written up to eraseblock 1792
    [  464.490962] mtd_oobtest: written 2047 eraseblocks
    [  464.495681] mtd_oobtest: verifying all eraseblocks
    [  464.518015] mtd_oobtest: verified up to eraseblock 0
    [  468.955635] mtd_oobtest: verified up to eraseblock 256
    [  473.395502] mtd_oobtest: verified up to eraseblock 512
    [  477.834373] mtd_oobtest: verified up to eraseblock 768
    [  482.272717] mtd_oobtest: verified up to eraseblock 1024
    [  486.712148] mtd_oobtest: verified up to eraseblock 1280
    [  491.150704] mtd_oobtest: verified up to eraseblock 1536
    [  495.589439] mtd_oobtest: verified up to eraseblock 1792
    [  499.993138] mtd_oobtest: verified 2047 eraseblocks
    [  499.997951] mtd_oobtest: test 3 of 5
    [  503.404228] mtd_oobtest: writing OOBs of whole device
    [  503.448822] mtd_oobtest: written up to eraseblock 0
    [  513.480773] mtd_oobtest: written up to eraseblock 256
    [  523.489361] mtd_oobtest: written up to eraseblock 512
    [  533.506896] mtd_oobtest: written up to eraseblock 768
    [  543.506268] mtd_oobtest: written up to eraseblock 1024
    [  553.506503] mtd_oobtest: written up to eraseblock 1280
    [  563.511266] mtd_oobtest: written up to eraseblock 1536
    [  573.519567] mtd_oobtest: written up to eraseblock 1792
    [  583.455111] mtd_oobtest: written 2047 eraseblocks
    [  583.459837] mtd_oobtest: verifying all eraseblocks
    [  583.499358] mtd_oobtest: verified up to eraseblock 0
    [  592.382953] mtd_oobtest: verified up to eraseblock 256
    [  601.267297] mtd_oobtest: verified up to eraseblock 512
    [  610.150907] mtd_oobtest: verified up to eraseblock 768
    [  619.034702] mtd_oobtest: verified up to eraseblock 1024
    [  627.919683] mtd_oobtest: verified up to eraseblock 1280
    [  636.821168] mtd_oobtest: verified up to eraseblock 1536
    [  645.705487] mtd_oobtest: verified up to eraseblock 1792
    [  654.520336] mtd_oobtest: verified 2047 eraseblocks
    [  654.525134] mtd_oobtest: test 4 of 5
    [  657.578146] mtd_oobtest: attempting to start write past end of OOB
    [  657.584336] mtd_oobtest: an error is expected...
    [  657.588974] mtd_oobtest: error occurred as expected
    [  657.593848] mtd_oobtest: attempting to start read past end of OOB
    [  657.599953] mtd_oobtest: an error is expected...
    [  657.604569] mtd_oobtest: error occurred as expected
    [  657.609450] mtd_oobtest: attempting to write past end of device
    [  657.615367] mtd_oobtest: an error is expected...
    [  657.619990] mtd_oobtest: error occurred as expected
    [  657.624864] mtd_oobtest: attempting to read past end of device
    [  657.630715] mtd_oobtest: an error is expected...
    [  657.635333] mtd_oobtest: error occurred as expected
    [  657.641043] mtd_oobtest: attempting to write past end of device
    [  657.646966] mtd_oobtest: an error is expected...
    [  657.651574] mtd_oobtest: error occurred as expected
    [  657.656451] mtd_oobtest: attempting to read past end of device
    [  657.662277] mtd_oobtest: an error is expected...
    [  657.666901] mtd_oobtest: error occurred as expected
    [  657.671774] mtd_oobtest: test 5 of 5
    [  659.382333] mtd_oobtest: writing OOBs of whole device
    [  659.388056] mtd_oobtest: written up to eraseblock 0
    [  659.393526] mtd_oobtest: written up to eraseblock 0
    [  659.704525] mtd_oobtest: written up to eraseblock 256
    [  659.710187] mtd_oobtest: written up to eraseblock 256
    [  660.021093] mtd_oobtest: written up to eraseblock 512
    [  660.026752] mtd_oobtest: written up to eraseblock 512
    [  660.338427] mtd_oobtest: written up to eraseblock 768
    [  660.344048] mtd_oobtest: written up to eraseblock 768
    [  660.655718] mtd_oobtest: written up to eraseblock 1024
    [  660.661462] mtd_oobtest: written up to eraseblock 1024
    [  660.970676] mtd_oobtest: written up to eraseblock 1280
    [  660.976386] mtd_oobtest: written up to eraseblock 1280
    [  661.286858] mtd_oobtest: written up to eraseblock 1536
    [  661.292587] mtd_oobtest: written up to eraseblock 1536
    [  661.605397] mtd_oobtest: written up to eraseblock 1792
    [  661.611142] mtd_oobtest: written up to eraseblock 1792
    [  661.918754] mtd_oobtest: written 2046 eraseblocks
    [  661.923458] mtd_oobtest: verifying all eraseblocks
    [  661.928812] mtd_oobtest: verified up to eraseblock 0
    [  662.072499] mtd_oobtest: verified up to eraseblock 256
    [  662.216152] mtd_oobtest: verified up to eraseblock 512
    [  662.359956] mtd_oobtest: verified up to eraseblock 768
    [  662.503238] mtd_oobtest: verified up to eraseblock 1024
    [  662.646847] mtd_oobtest: verified up to eraseblock 1280
    [  662.790603] mtd_oobtest: verified up to eraseblock 1536
    [  662.934269] mtd_oobtest: verified up to eraseblock 1792
    [  663.076329] mtd_oobtest: verified 2046 eraseblocks
    [  663.081114] mtd_oobtest: finished with 0 errors
    [  663.085647] =================================================

    root@OpenWrt:/lib/modules/6.6.79# insmod  mtd_pagetest.ko dev=1
    [ 1142.213082]
    [ 1142.214590] =================================================
    [ 1142.220433] mtd_pagetest: MTD device: 1
    [ 1142.224278] mtd_pagetest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128
    [ 1142.238388] mtd_test: scanning for bad eraseblocks
    [ 1142.243536] mtd_test: scanned 2047 eraseblocks, 0 are bad
    [ 1142.248935] mtd_pagetest: erasing whole device
    [ 1143.962562] mtd_pagetest: erased 2047 eraseblocks
    [ 1143.967301] mtd_pagetest: writing whole device
    [ 1144.011729] mtd_pagetest: written up to eraseblock 0
    [ 1154.137933] mtd_pagetest: written up to eraseblock 256
    [ 1164.265201] mtd_pagetest: written up to eraseblock 512
    [ 1174.393365] mtd_pagetest: written up to eraseblock 768
    [ 1184.525700] mtd_pagetest: written up to eraseblock 1024
    [ 1194.650920] mtd_pagetest: written up to eraseblock 1280
    [ 1204.773676] mtd_pagetest: written up to eraseblock 1536
    [ 1214.896934] mtd_pagetest: written up to eraseblock 1792
    [ 1224.942600] mtd_pagetest: written 2047 eraseblocks
    [ 1224.947410] mtd_pagetest: verifying all eraseblocks
    [ 1225.053133] mtd_pagetest: verified up to eraseblock 0
    [ 1250.760034] mtd_pagetest: verified up to eraseblock 256
    [ 1276.448242] mtd_pagetest: verified up to eraseblock 512
    [ 1302.138825] mtd_pagetest: verified up to eraseblock 768
    [ 1327.824020] mtd_pagetest: verified up to eraseblock 1024
    [ 1353.532178] mtd_pagetest: verified up to eraseblock 1280
    [ 1379.234385] mtd_pagetest: verified up to eraseblock 1536
    [ 1404.943865] mtd_pagetest: verified up to eraseblock 1792
    [ 1430.468816] mtd_pagetest: verified 2047 eraseblocks
    [ 1430.473702] mtd_pagetest: crosstest
    [ 1430.477717] mtd_pagetest: reading page at 0x0
    [ 1430.482328] mtd_pagetest: reading page at 0xffdf800
    [ 1430.487469] mtd_pagetest: reading page at 0x0
    [ 1430.492084] mtd_pagetest: verifying pages read at 0x0 match
    [ 1430.497668] mtd_pagetest: crosstest ok
    [ 1430.501409] mtd_pagetest: erasecrosstest
    [ 1430.505323] mtd_pagetest: erasing block 0
    [ 1430.511511] mtd_pagetest: writing 1st page of block 0
    [ 1430.517166] mtd_pagetest: reading 1st page of block 0
    [ 1430.522505] mtd_pagetest: verifying 1st page of block 0
    [ 1430.527739] mtd_pagetest: erasing block 0
    [ 1430.532565] mtd_pagetest: writing 1st page of block 0
    [ 1430.538229] mtd_pagetest: erasing block 2046
    [ 1430.544181] mtd_pagetest: reading 1st page of block 0
    [ 1430.549498] mtd_pagetest: verifying 1st page of block 0
    [ 1430.554718] mtd_pagetest: erasecrosstest ok
    [ 1430.558900] mtd_pagetest: erasetest
    [ 1430.562381] mtd_pagetest: erasing block 0
    [ 1430.567208] mtd_pagetest: writing 1st page of block 0
    [ 1430.572858] mtd_pagetest: erasing block 0
    [ 1430.577680] mtd_pagetest: reading 1st page of block 0
    [ 1430.582990] mtd_pagetest: verifying 1st page of block 0 is all 0xff
    [ 1430.589279] mtd_pagetest: erasetest ok
    [ 1430.593023] mtd_pagetest: finished with 0 errors
    [ 1430.597651] =================================================

    root@OpenWrt:/lib/modules/6.6.79# insmod  mtd_readtest.ko dev=1
    [ 1478.691648]
    [ 1478.693158] =================================================
    [ 1478.698981] mtd_readtest: MTD device: 1
    [ 1478.702829] mtd_readtest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128
    [ 1478.716939] mtd_test: scanning for bad eraseblocks
    [ 1478.722072] mtd_test: scanned 2047 eraseblocks, 0 are bad
    [ 1478.727475] mtd_readtest: testing page read
    [ 1548.352125] mtd_readtest: finished
    [ 1548.355553] =================================================

    root@OpenWrt:/lib/modules/6.6.79# insmod  mtd_speedtest.ko dev=1
    [ 1617.353002]
    [ 1617.354511] =================================================
    [ 1617.360332] mtd_speedtest: MTD device: 1
    [ 1617.364258] mtd_speedtest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128
    [ 1617.380150] mtd_test: scanning for bad eraseblocks
    [ 1617.385428] mtd_test: scanned 2047 eraseblocks, 0 are bad
    [ 1621.021861] mtd_speedtest: testing eraseblock write speed
    [ 1700.915306] mtd_speedtest: eraseblock write speed is 3279 KiB/s
    [ 1700.921250] mtd_speedtest: testing eraseblock read speed
    [ 1734.931886] mtd_speedtest: eraseblock read speed is 7705 KiB/s
    [ 1738.682742] mtd_speedtest: testing page write speed
    [ 1818.818644] mtd_speedtest: page write speed is 3269 KiB/s
    [ 1818.824058] mtd_speedtest: testing page read speed
    [ 1852.913595] mtd_speedtest: page read speed is 7687 KiB/s
    [ 1856.674492] mtd_speedtest: testing 2 page write speed
    [ 1936.437284] mtd_speedtest: 2 page write speed is 3285 KiB/s
    [ 1936.442869] mtd_speedtest: testing 2 page read speed
    [ 1970.498124] mtd_speedtest: 2 page read speed is 7694 KiB/s
    [ 1970.503624] mtd_speedtest: Testing erase speed
    [ 1974.343389] mtd_speedtest: erase speed is 68316 KiB/s
    [ 1974.348479] mtd_speedtest: Testing 2x multi-block erase speed
    [ 1976.068855] mtd_speedtest: 2x multi-block erase speed is 152811 KiB/s
    [ 1976.075309] mtd_speedtest: Testing 4x multi-block erase speed
    [ 1977.790232] mtd_speedtest: 4x multi-block erase speed is 153301 KiB/s
    [ 1977.796693] mtd_speedtest: Testing 8x multi-block erase speed
    [ 1979.511905] mtd_speedtest: 8x multi-block erase speed is 153273 KiB/s
    [ 1979.518367] mtd_speedtest: Testing 16x multi-block erase speed
    [ 1981.230700] mtd_speedtest: 16x multi-block erase speed is 153539 KiB/s
    [ 1981.237249] mtd_speedtest: Testing 32x multi-block erase speed
    [ 1982.948381] mtd_speedtest: 32x multi-block erase speed is 153648 KiB/s
    [ 1982.954918] mtd_speedtest: Testing 64x multi-block erase speed
    [ 1984.665992] mtd_speedtest: 64x multi-block erase speed is 153655 KiB/s
    [ 1984.672531] mtd_speedtest: finished
    [ 1984.676054] =================================================

    root@OpenWrt:/lib/modules/6.6.79# insmod mtd_stresstest.ko dev=1
    [ 2190.651750]
    [ 2190.653263] =================================================
    [ 2190.659087] mtd_stresstest: MTD device: 1
    [ 2190.663105] mtd_stresstest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128
    [ 2190.679846] mtd_test: scanning for bad eraseblocks
    [ 2190.684981] mtd_test: scanned 2047 eraseblocks, 0 are bad
    [ 2190.690389] mtd_stresstest: doing operations
    [ 2190.694655] mtd_stresstest: 0 operations done
    [ 2214.262705] mtd_stresstest: 1024 operations done
    [ 2239.019612] mtd_stresstest: 2048 operations done
    [ 2262.820899] mtd_stresstest: 3072 operations done
    [ 2285.061376] mtd_stresstest: 4096 operations done
    [ 2308.297322] mtd_stresstest: 5120 operations done
    [ 2330.530459] mtd_stresstest: 6144 operations done
    [ 2352.651759] mtd_stresstest: 7168 operations done
    [ 2375.188275] mtd_stresstest: 8192 operations done
    [ 2397.738174] mtd_stresstest: 9216 operations done
    [ 2414.792572] mtd_stresstest: finished, 10000 operations done
    [ 2414.798257] =================================================

Speed test of original driver (with patch to fix support of flashes
with more than one plane per lun)

    root@OpenWrt:/lib/modules/6.6.79# insmod  mtd_speedtest.ko dev=1
    [ 2894.142208]
    [ 2894.143719] =================================================
    [ 2894.149556] mtd_speedtest: MTD device: 1
    [ 2894.153486] mtd_speedtest: MTD device size 268304384, eraseblock size 131072, page size 2048, count of eraseblocks 2047, pages per eraseblock 64, OOB size 128
    [ 2894.168888] mtd_test: scanning for bad eraseblocks
    [ 2894.174023] mtd_test: scanned 2047 eraseblocks, 0 are bad
    [ 2897.500416] mtd_speedtest: testing eraseblock write speed
    [ 2977.807233] mtd_speedtest: eraseblock write speed is 3262 KiB/s
    [ 2977.813171] mtd_speedtest: testing eraseblock read speed
    [ 3013.906597] mtd_speedtest: eraseblock read speed is 7260 KiB/s
    [ 3017.440320] mtd_speedtest: testing page write speed
    [ 3097.833394] mtd_speedtest: page write speed is 3259 KiB/s
    [ 3097.838812] mtd_speedtest: testing page read speed
    [ 3134.004981] mtd_speedtest: page read speed is 7245 KiB/s
    [ 3137.538423] mtd_speedtest: testing 2 page write speed
    [ 3217.906288] mtd_speedtest: 2 page write speed is 3260 KiB/s
    [ 3217.911883] mtd_speedtest: testing 2 page read speed
    [ 3254.049757] mtd_speedtest: 2 page read speed is 7251 KiB/s
    [ 3254.055254] mtd_speedtest: Testing erase speed
    [ 3257.599146] mtd_speedtest: erase speed is 74027 KiB/s
    [ 3257.604213] mtd_speedtest: Testing 2x multi-block erase speed
    [ 3259.320945] mtd_speedtest: 2x multi-block erase speed is 153139 KiB/s
    [ 3259.327413] mtd_speedtest: Testing 4x multi-block erase speed
    [ 3261.044585] mtd_speedtest: 4x multi-block erase speed is 153098 KiB/s
    [ 3261.051047] mtd_speedtest: Testing 8x multi-block erase speed
    [ 3262.786520] mtd_speedtest: 8x multi-block erase speed is 151479 KiB/s
    [ 3262.792979] mtd_speedtest: Testing 16x multi-block erase speed
    [ 3264.509898] mtd_speedtest: 16x multi-block erase speed is 153130 KiB/s
    [ 3264.516454] mtd_speedtest: Testing 32x multi-block erase speed
    [ 3266.233403] mtd_speedtest: 32x multi-block erase speed is 153125 KiB/s
    [ 3266.239961] mtd_speedtest: Testing 64x multi-block erase speed
    [ 3267.957985] mtd_speedtest: 64x multi-block erase speed is 153029 KiB/s
    [ 3267.964525] mtd_speedtest: finished
    [ 3267.968039] =================================================

It looks like a patched driver is a bit faster

write speed: 3260 KiB/s  vs  3277 KiB/s
read speed:  7252 KiB/s  vs  7695 KiB/s
2025-10-17 19:28:14 +01:00
Ada Couprie Diaz
ea0d55ae4b arm64: debug: always unmask interrupts in el0_softstp()
We intend that EL0 exception handlers unmask all DAIF exceptions
before calling exit_to_user_mode().

When completing single-step of a suspended breakpoint, we do not call
local_daif_restore(DAIF_PROCCTX) before calling exit_to_user_mode(),
leaving all DAIF exceptions masked.

When pseudo-NMIs are not in use this is benign.

When pseudo-NMIs are in use, this is unsound. At this point interrupts
are masked by both DAIF.IF and PMR_EL1, and subsequent irq flag
manipulation may not work correctly. For example, a subsequent
local_irq_enable() within exit_to_user_mode_loop() will only unmask
interrupts via PMR_EL1 (leaving those masked via DAIF.IF), and
anything depending on interrupts being unmasked (e.g. delivery of
signals) will not work correctly.

This was detected by CONFIG_ARM64_DEBUG_PRIORITY_MASKING.

Move the call to `try_step_suspended_breakpoints()` outside of the check
so that interrupts can be unmasked even if we don't call the step handler.

Fixes: 0ac7584c08 ("arm64: debug: split single stepping exception entry")
Cc: <stable@vger.kernel.org> # 6.17
Signed-off-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
[catalin.marinas@arm.com: added Mark's rewritten commit log and some whitespace]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-10-17 18:08:05 +01:00
Lorenzo Pieralisi
e9ad390a48 arm64/sysreg: Fix GIC CDEOI instruction encoding
The GIC CDEOI system instruction requires the Rt field to be set to 0b11111
otherwise the instruction behaviour becomes CONSTRAINED UNPREDICTABLE.

Currenly, its usage is encoded as a system register write, with a constant
0 value:

write_sysreg_s(0, GICV5_OP_GIC_CDEOI)

While compiling with GCC, the 0 constant value, through these asm
constraints and modifiers ('x' modifier and 'Z' constraint combo):

asm volatile(__msr_s(r, "%x0") : : "rZ" (__val));

forces the compiler to issue the XZR register for the MSR operation (ie
that corresponds to Rt == 0b11111) issuing the right instruction encoding.

Unfortunately LLVM does not yet understand that modifier/constraint
combo so it ends up issuing a different register from XZR for the MSR
source, which in turns means that it encodes the GIC CDEOI instruction
wrongly and the instruction behaviour becomes CONSTRAINED UNPREDICTABLE
that we must prevent.

Add a conditional to write_sysreg_s() macro that detects whether it
is passed a constant 0 value and issues an MSR write with XZR as source
register - explicitly doing what the asm modifier/constraint is meant to
achieve through constraints/modifiers, fixing the LLVM compilation issue.

Fixes: 7ec80fb3f0 ("irqchip/gic-v5: Add GICv5 PPI support")
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Acked-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Cc: Sascha Bischoff <sascha.bischoff@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-10-17 17:55:01 +01:00
Ting-Chang Hou
1fabe43b4e btrfs: send: fix duplicated rmdir operations when using extrefs
Commit 29d6d30f5c ("Btrfs: send, don't send rmdir for same target
multiple times") has fixed an issue that a send stream contained a rmdir
operation for the same directory multiple times. After that fix we keep
track of the last directory for which we sent a rmdir operation and
compare with it before sending a rmdir for the parent inode of a deleted
hardlink we are processing. But there is still a corner case that in
between rmdir dir operations for the same inode we find deleted hardlinks
for other parent inodes, so tracking just the last inode for which we sent
a rmdir operation is not enough.

Hardlinks of a file in the same directory are stored in the same INODE_REF
item, but if the number of hardlinks is too large and can not fit in a
leaf, we use INODE_EXTREF items to store them. The key of an INODE_EXTREF
item is (inode_id, INODE_EXTREF, hash[name, parent ino]), so between two
hardlinks for the same parent directory, we can find others for other
parent directories. For example for the reproducer below we get the
following (from a btrfs inspect-internal dump-tree output):

    item 0 key (259 INODE_EXTREF 2309449) itemoff 16257 itemsize 26
            index 6925 parent 257 namelen 8 name: foo.6923
    item 1 key (259 INODE_EXTREF 2311350) itemoff 16231 itemsize 26
            index 6588 parent 258 namelen 8 name: foo.6587
    item 2 key (259 INODE_EXTREF 2457395) itemoff 16205 itemsize 26
            index 6611 parent 257 namelen 8 name: foo.6609
    (...)

So tracking the last directory's inode number does not work in this case
since we process a link for parent inode 257, then for 258 and then back
again for 257, and that second time we process a deleted link for 257 we
think we have not yet sent a rmdir operation.

Fix this by using a rbtree to keep track of all the directories for which
we have already sent rmdir operations, and add those directories to the
'check_dirs' ref list in process_recorded_refs() only if the directory is
not yet in the rbtree, otherwise skip it since it means we have already
sent a rmdir operation for that directory.

The following test script reproduces the problem:

  $ cat test.sh
  #!/bin/bash

  DEV=/dev/sdi
  MNT=/mnt/sdi

  mkfs.btrfs -f $DEV
  mount $DEV $MNT

  mkdir $MNT/a $MNT/b

  echo 123 > $MNT/a/foo
  for ((i = 1; i <= 1000; i++)); do
     ln $MNT/a/foo $MNT/a/foo.$i
     ln $MNT/a/foo $MNT/b/foo.$i
  done

  btrfs subvolume snapshot -r $MNT $MNT/snap1
  btrfs send $MNT/snap1 -f /tmp/base.send

  rm -r $MNT/a $MNT/b

  btrfs subvolume snapshot -r $MNT $MNT/snap2
  btrfs send -p $MNT/snap1 $MNT/snap2 -f /tmp/incremental.send

  umount $MNT
  mkfs.btrfs -f $DEV
  mount $DEV $MNT

  btrfs receive $MNT -f /tmp/base.send
  btrfs receive $MNT -f /tmp/incremental.send

  rm -f /tmp/base.send /tmp/incremental.send

  umount $MNT

When running it, it fails like this:

  $ ./test.sh
  (...)
  At subvol snap1
  At snapshot snap2
  ERROR: rmdir o257-9-0 failed: No such file or directory

CC: <stable@vger.kernel.org>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Ting-Chang Hou <tchou@synology.com>
[ Updated changelog ]
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2025-10-17 18:33:34 +02:00
Dewei Meng
17679ac6df btrfs: directly free partially initialized fs_info in btrfs_check_leaked_roots()
If fs_info->super_copy or fs_info->super_for_commit allocated failed in
btrfs_get_tree_subvol(), then no need to call btrfs_free_fs_info().
Otherwise btrfs_check_leaked_roots() would access NULL pointer because
fs_info->allocated_roots had not been initialised.

syzkaller reported the following information:
  ------------[ cut here ]------------
  BUG: unable to handle page fault for address: fffffffffffffbb0
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 64c9067 P4D 64c9067 PUD 64cb067 PMD 0
  Oops: Oops: 0000 [#1] SMP KASAN PTI
  CPU: 0 UID: 0 PID: 1402 Comm: syz.1.35 Not tainted 6.15.8 #4 PREEMPT(lazy)
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), (...)
  RIP: 0010:arch_atomic_read arch/x86/include/asm/atomic.h:23 [inline]
  RIP: 0010:raw_atomic_read include/linux/atomic/atomic-arch-fallback.h:457 [inline]
  RIP: 0010:atomic_read include/linux/atomic/atomic-instrumented.h:33 [inline]
  RIP: 0010:refcount_read include/linux/refcount.h:170 [inline]
  RIP: 0010:btrfs_check_leaked_roots+0x18f/0x2c0 fs/btrfs/disk-io.c:1230
  [...]
  Call Trace:
   <TASK>
   btrfs_free_fs_info+0x310/0x410 fs/btrfs/disk-io.c:1280
   btrfs_get_tree_subvol+0x592/0x6b0 fs/btrfs/super.c:2029
   btrfs_get_tree+0x63/0x80 fs/btrfs/super.c:2097
   vfs_get_tree+0x98/0x320 fs/super.c:1759
   do_new_mount+0x357/0x660 fs/namespace.c:3899
   path_mount+0x716/0x19c0 fs/namespace.c:4226
   do_mount fs/namespace.c:4239 [inline]
   __do_sys_mount fs/namespace.c:4450 [inline]
   __se_sys_mount fs/namespace.c:4427 [inline]
   __x64_sys_mount+0x28c/0x310 fs/namespace.c:4427
   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
   do_syscall_64+0x92/0x180 arch/x86/entry/syscall_64.c:94
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f032eaffa8d
  [...]

Fixes: 3bb17a25bc ("btrfs: add get_tree callback for new mount API")
CC: stable@vger.kernel.org # 6.12+
Reviewed-by: Daniel Vacek <neelx@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Dewei Meng <mengdewei@cqsoftware.com.cn>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2025-10-17 18:33:27 +02:00
Dan Carpenter
0cc08c8130
spi: aspeed: Fix an IS_ERR() vs NULL bug in probe()
The platform_get_resource() function doesn't return error pointers, it
returns NULL on error.  Update the error checking to match.

Fixes: 64d87ccfae ("spi: aspeed: Only map necessary address window region")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/aPJpEnfK31pHz8_w@stanley.mountain
Signed-off-by: Mark Brown <broonie@kernel.org>
2025-10-17 17:21:03 +01:00
Zhang Lixu
5677aa6a08 HID: intel-ish-hid: ipc: Separate hibernate callbacks in dev_pm_ops
The same suspend and resume callbacks are used for both suspend-to-RAM/idle
and hibernation. These callbacks invoke pm_suspend_via_firmware() and
pm_resume_via_firmware(), respectively. In the .freeze() of hibernation,
pm_suspend_via_firmware() returns false, causing the driver to put ISH into
D0i3. However, during the .thaw(), pm_resume_via_firmware() returns true,
leading the driver to treat ISH as resuming from D3 instead of D0i3. The
asymmetric behavior between .freeze() and .thaw() during hibernation can
cause the client connection states on the firmware side and the driver side
to become inconsistent.

To address the inconsistent client connection states issue, separate
hibernate-related callbacks (freeze, thaw) in dev_pm_ops. Since ISH does
not need to save any firmware-related state when entering hibernation, it
is sufficient to call pci_save_state() in .freeze() to prevent the PCI bus
from changing the ISH power state. No actions are required in .thaw().

Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17 17:47:54 +02:00
Zhang Lixu
507561b00a HID: intel-ish-hid: Use IPC RESET instead of void message in ish_wakeup()
On ISH power-up, the bootloader enters sleep after preparing to load the
main firmware, waiting for the driver to be ready. When the driver is
ready, it sends a void message to wake up the bootloader and load the main
firmware. The main firmware then sends MNG_RESET_NOTIFY to the driver for
handshake.

This void message-based IPC handshake only works if the main firmware has
not been loaded. During hibernation resume, if the restore kernel has the
ISH driver, the driver wakes up the bootloader to load the main firmware
and perform IPC handshake. However, when switching to the image kernel,
since the main firmware is already loaded, sending a void message in the
.restore() callback does not trigger IPC handshake.

By sending MNG_RESET_NOTIFY (IPC RESET message) in ish_wakeup() instead of
a void message, we can explicitly wake up the bootloader and perform IPC
handshake, regardless of the firmware state. Additionally, since
ish_ipc_reset() already waits for recvd_hw_ready, the redundant wait for
recvd_hw_ready in ish_hw_start() is removed.

The timeout for waiting for HW ready is set to 10 seconds, matching the
original timeout value used in ish_wakeup(), to ensure reliable wakeup on
hardware that requires more time, such as the Lenovo ThinkPad X1 Titanium
Gen 1.

Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17 17:47:54 +02:00
Zhang Lixu
9e097dc9df HID: intel-ish-hid: ipc: Always schedule FW reset work on RESET_NOTIFY/ACK
Both ISH firmware and driver can actively send MNG_RESET_NOTIFY to initiate
an FW reset handshake. Upon receiving this, the peer should reply with
MNG_RESET_NOTIFY_ACK. Therefore, the driver should schedule the FW reset
handshake work function when receiving either MNG_RESET_NOTIFY or
MNG_RESET_NOTIFY_ACK.

Previously, driver only scheduled the work function on MNG_RESET_NOTIFY.
This patch ensures the work function is scheduled on both messages, but
only replies with MNG_RESET_NOTIFY_ACK when receiving MNG_RESET_NOTIFY.

Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17 17:47:54 +02:00
Zhang Lixu
bd1b9a8df5 HID: intel-ish-ipc: Reset clients state on resume from D3
When ISH resumes from D3, the connection between ishtp clients and firmware
is lost. The ish_resume() function schedules resume_work asynchronously to
re-initiate the connection and then returns immediately. This can cause a
race where the upper-layer ishtp client driver's .resume() may execute
before the connection is fully restored, leaving the client in a stale
connected state. If the client sends messages during this window, the
firmware cannot respond.

To avoid this, reset the ishtp clients' state before returning from
ish_resume() if ISH is resuming from D3.

Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17 17:47:53 +02:00
Zhang Lixu
3cbf6544b0 HID: intel-ishtp-hid: Clear suspended flag only after connected on resume
When resuming from suspend-to-RAM or hibernate, the ISH firmware is powered
on from D3, causing all previous client connections between the firmware
and driver to be lost. Although the underlying ishtp bus driver initiates a
client reconnection flow, this process is asynchronous. As a result, when
hid_ishtp_cl_resume_handler() is executed, the connection may not have been
re-established yet. Clearing the suspended flag prematurely in this
scenario can lead to a timeout when the upper-layer HID sensor driver set
feature during resume.

To prevent such timeouts, only clear the suspended flag after confirming
that the connection state is ISHTP_CL_CONNECTED.

Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17 17:47:53 +02:00
Zhang Lixu
011aa2aa2c HID: intel-ish-hid: Add ishtp_get_connection_state() interface
Add the ishtp_get_connection_state() function for struct ishtp_cl, allowing
ishtp client drivers to retrieve the current connection state.

Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17 17:47:53 +02:00
Zhang Lixu
0d30dae38f HID: intel-ish-hid: Use dedicated unbound workqueues to prevent resume blocking
During suspend/resume tests with S2IDLE, some ISH functional failures were
observed because of delay in executing ISH resume handler. Here
schedule_work() is used from resume handler to do actual work.
schedule_work() uses system_wq, which is a per CPU work queue. Although
the queuing is not bound to a CPU, but it prefers local CPU of the caller,
unless prohibited.

Users of this work queue are not supposed to queue long running work.
But in practice, there are scenarios where long running work items are
queued on other unbound workqueues, occupying the CPU. As a result, the
ISH resume handler may not get a chance to execute in a timely manner.

In one scenario, one of the ish_resume_handler() executions was delayed
nearly 1 second because another work item on an unbound workqueue occupied
the same CPU. This delay causes ISH functionality failures.

A similar issue was previously observed where the ISH HID driver timed out
while getting the HID descriptor during S4 resume in the recovery kernel,
likely caused by the same workqueue contention problem.

Create dedicated unbound workqueues for all ISH operations to allow work
items to execute on any available CPU, eliminating CPU-specific bottlenecks
and improving resume reliability under varying system loads. Also ISH has
three different components, a bus driver which implements ISH protocols, a
PCI interface layer and HID interface. Use one dedicated work queue for all
of them.

Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
2025-10-17 17:47:07 +02:00
Linus Torvalds
6f3b6e91f7 io_uring-6.18-20251016
-----BEGIN PGP SIGNATURE-----
 
 iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmjxoFsQHGF4Ym9lQGtl
 cm5lbC5kawAKCRD301j7KXHgpikOEACOO8yYwkuPUdNFAAObjxQ0B5qRsucgKH7N
 ZzHDcFPDUQ34bZpvXUg4XUNU0lmQbOHM1jclpI8zpk42g4XEX9pH2s4DZsiR2s+I
 Nssqf8AZEtsk+kUIqLrt51yIUfNfax1lwF3oRdKxf4/oePfHAM7bmyPpOsvewqHi
 SbdF5JA6jSSO1WO8wr2Okb5LXnwxMWTC5BXi/sJi6xG2q7ADHlBRemdEfS3zylwm
 TS2hlKJ13F5W0REZMLO4BZfw0F2UyDFCU2JOJ6SkuVrq1CCPjqYX17Bowke8m1rY
 wIX/Tm3VcGZHlOgK+OZtbuIS1/yXBuhvmnYENYp7qWCGfhP5iasKXDau5TEck5kY
 p/u39WOtptJv/7zentzkL58/9ZEk/7yRqotulpDm6O+uwJCdfLqPyVpaiUPB6Oc0
 DPj5G7vGzUWK0vvoTdQEis37B4MOtwQh2cA9ARpZvfPDFJLxQYA7+bUDhSusqPOR
 g2/nnoioekBDVtFhotRieeGEEe0qQ3Qon6NM+0GOoauaujXhP1wNvldZVloVV6rA
 qc9UK2Of0/DuKYpCCvDaSd+i3B/TOh0dphip3R7MFxcovIPJ3PifSfdkrkiG6dgU
 D81BK+JWM/gmQHKDIInoxj5asfo3kU/fIVuz0yy9Gu9d8mlbAU5xYf46ZEiARPk2
 Hs5PWFEoMg==
 =uCEM
 -----END PGP SIGNATURE-----

Merge tag 'io_uring-6.18-20251016' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux

Pull io_uring fixes from Jens Axboe:

 - Revert of a change that went into an older kernel, and which has been
   reported to cause a regression for some write workloads on LVM while
   a snapshop is being created

 - Fix a regression from this merge window, where some compilers (and/or
   certain .config options) would cause an earlier evaluations of a
   dereference which would then cause a NULL pointer dereference.

   I was only able to reproduce this with OPTIMIZE_FOR_SIZE=y, but David
   Howells hit it with just KASAN enabled. Depending on how things
   inlined, this makes sense

 - Fix for a missing lock around a mem region unregistration

 - Fix for ring resizing with the same placement after resize

* tag 'io_uring-6.18-20251016' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
  io_uring/rw: check for NULL io_br_sel when putting a buffer
  io_uring: fix unexpected placement on same size resizing
  io_uring: protect mem region deregistration
  Revert "io_uring/rw: drop -EOPNOTSUPP check in __io_complete_rw_common()"
2025-10-17 08:45:54 -07:00
Randy Dunlap
0fbbcab7f9 cgroup/misc: fix misc_res_type kernel-doc warning
Format the kernel-doc for SCALE_HW_CALIB_INVALID correctly to
avoid a kernel-doc warning:

Warning: include/linux/misc_cgroup.h:26 Enum value
 'MISC_CG_RES_TDX' not described in enum 'misc_res_type'

Fixes: 7c035bea94 ("KVM: TDX: Register TDX host key IDs to cgroup misc controller")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
2025-10-17 05:31:56 -10:00
Linus Torvalds
0c8df15f75 block-6.18-20251016
-----BEGIN PGP SIGNATURE-----
 
 iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmjxoHoQHGF4Ym9lQGtl
 cm5lbC5kawAKCRD301j7KXHgprKCD/4irkkA7mBorYyNROXMwANOUg+2pl20xp/X
 8reZsIZKWztUS18Emfg2jS2NIXP6LIFc3ZehfJX/9FrM26B9URH9cq/F/D/mHc/+
 G4qfT5HUR5Eyav0qCP+pbru53irUOUWSUKKgrWRR8gDY9BcT7apjV8pULd/1PAfo
 3XLfY2o39u68TBzmcwZvDudtBFcBfSan/JCIiW6IMxHWerHhV+IEJG5ABncFo8n9
 +Ep5uOVWYQanM1lvat+Zy+aiWz0Fb0yYzXvtDatcGsAxfxJIf2Bs8ryZMAxgw7yk
 B9Jsd5kGTw9Tfn/H7kl2P4RGQ0gGr91dl0FmaUkDMXTyZcsz/Nq2PbwiiJaESp/4
 Ixk3m9QjXpA6ofxAeorXFtTo98obnKklZLpCPzV5sqslzpGSWXdsbPmHOB5A4XcH
 M2QT/uM2eZbUtHUkymoUBMJTcqCfUsL827+Z6DGLl+Rrb0bjRvunlVCoxoTPuAeg
 ulOpuWd888Gy3X8lT7vBhY/9iWyljFwja/suiFx3f29e2DULXiXDTXrrA0GIxcO+
 l7PA7BgcMf/0lJfo2gpGtPZvHYvtFXoRwxGaIGbusXixgg/dLY2LQ64BYPpu0JU8
 Ph3xsL3pgLLPFVMBarHqwKoSb/4avOvzMaM7xGQQICg+0Gx2x9YPpLosaMgbdYPY
 OFPSLihwUg==
 =qiT3
 -----END PGP SIGNATURE-----

Merge tag 'block-6.18-20251016' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux

Pull block fixes from Jens Axboe:

 - NVMe pull request via Keith:
     - iostats accounting fixed on multipath retries (Amit)
     - secure concatenation response fixup (Martin)
     - tls partial record fixup (Wilfred)

 - Fix for a lockdep reported issue with the elevator lock and
   blk group frozen operations

 - Fix for a regression in this merge window, where updating
   'nr_requests' would not do the right thing for queues with
   shared tags

* tag 'block-6.18-20251016' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
  nvme/tcp: handle tls partially sent records in write_space()
  block: Remove elevator_lock usage from blkg_conf frozen operations
  blk-mq: fix stale tag depth for shared sched tags in blk_mq_update_nr_requests()
  nvme-auth: update sc_c in host response
  nvme-multipath: Skip nr_active increments in RETRY disposition
2025-10-17 08:31:26 -07:00
Linus Torvalds
cf1ea8854e MMC core:
- Move rpmb_frame struct and constants to rpmb common header
 -----BEGIN PGP SIGNATURE-----
 
 iQJLBAABCgA1FiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAmjyBP8XHHVsZi5oYW5z
 c29uQGxpbmFyby5vcmcACgkQ/iaEJXNYjClIPBAAnf5knVISlKIl922oXiuD/WFR
 BX18mt80V+1IFiKv6zm6AN4K0n8sf1p2IZbJz5ka6gpvWATIEnelRSuSqSCdKJBG
 YVRu8tlET8h4BIc8oTB9b72vfbccXaFmFmyen1wZ+mXjOg4WnPQ0IbFkRv4ArWV6
 Hgurc3bJSwfPuWjq/J8ANHhepmkx/8asNPJB9jwlXf23kcuwlLBeQoZ1A3PUTWfe
 slHJWoQobKf682XlFCaSmf6ZO0bvT9YAGo/GwVFKlXlcg2rLXuA2ksX8qhtqqMaB
 oX8X3pBMTLJhbCxwO1eVKqE9AmAiHV/NM52m0Z5Z47qIxaRAla3Mt7U2oG92fZoy
 r/N5o+heZscRELuG/XlhpRUaP3YrJj7oLoSH4wF6efUDvnZSTQReYuEePbJxszML
 7juEU/+xiFnN26OJc+Z0aXGXMUvJaxPoX+h9h5PeIlrn9ruUw2+iDb53bSLc01fr
 qAtP9127SGA0dWlpCamQtWThTvzSQUy7tSAcFHssqQXPdlVjZzc2MfWJXI1ODfPN
 UAtLmjcBhAo06oYsJHxn6riuA9wJrh/fi4ijh+deQT4clPN2F07xadfZPjRsTfym
 6G4sXnky2sfUPL+91PKr2WTWPMZwMJ/rtQxM6prmXmQkAkJxyrBMS261AghTnkZZ
 OOYr1wLvQohhAQOMhq4=
 =HuJc
 -----END PGP SIGNATURE-----

Merge tag 'mmc-v6.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc

Pull mmc cleanup from Ulf Hansson:
 "Move rpmb_frame struct and constants to rpmb common header

  This helps us to avoid sharing an immutable branch between our git
  trees. I was planning to send it before rc1, but I didn't make it"

* tag 'mmc-v6.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
  rpmb: move rpmb_frame struct and constants to common header
2025-10-17 08:22:20 -07:00
Linus Torvalds
1422424187 sound fixes for 6.18-rc2
A collection of small fixes.  All changes are rather boring
 device-specific fixes and quirks.
 
 - A few fixes for missing NULL checks
 - ASoC NAU8821 fixes for jack and irq handling
 - Various fixes for ASoC TAS2781, IDT821034, sc8280xp, max9809x,
   wcd938x, and SoundWire
 - Usual HD-audio and USB-audio quirks
 -----BEGIN PGP SIGNATURE-----
 
 iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmjyWIMOHHRpd2FpQHN1
 c2UuZGUACgkQLtJE4w1nLE8pnA//aBNWUaEDDTlNzIRyMC8oKhWJhJPxFW7itXch
 OF6pfGKJNczyhEResn7R5tYtXMpsaZWVu6no42yxOHkYGV7Xw3gV03hTuK6Egio1
 T9CVQ1DjokUw+XxACfmo5gKDTq/tl6LwmsrTU5i4zTlMrl8FRwPw9l7A20/JUNpX
 OM6Rp8RAWEhr8dIbmgfZITUOJ4irjzoQ0gUxrodQ5Dc/uuZAKGTeIQdaIg/K1uN6
 1eyG3V8gOrt7im0YbIlzVDj6W/bKJckzVUADMiq3ZKXV7H5QELMcKzXzIbkwSZi4
 E12q5PjkRarLyjDabKM6XJgjfROin08VDlEUaccCANBB9a13jqICzowfd0EXvUZW
 JRgSbJKpKMewYk2BJV7Y9I+ScFBfdVZE0ZtiCYPyTJEvVNzeplOxLNqyqGLP/s+s
 EM7hxwGy9vnLMQhbWpP4CclzKUnDeb+PTxnj0p6osXnF0c++0DhxuF1IkZnjQ0xC
 wXS3uiTwqXOCYOlL6VP9eZgtqCKxAsq0NXC1rUTcOs3UefffeJ5lrT1xhppDQ4CV
 r7iLQCBBAmcrKWwjvvqEXSu7BoPBKPiM9TAyCFEKQQ/1QSgbI5oNjpz/mTCKZRkF
 7xX5iPmoPDTKRbjubEtRlp/HB+bd0fuk40dWuv35qC3IR5fbqizl67B2LPmquDix
 9EPHwiQ=
 =9RjP
 -----END PGP SIGNATURE-----

Merge tag 'sound-6.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "A collection of small fixes. All changes are rather boring
  device-specific fixes and quirks:

   - A few fixes for missing NULL checks

   - ASoC NAU8821 fixes for jack and irq handling

   - Various fixes for ASoC TAS2781, IDT821034, sc8280xp, max9809x,
     wcd938x, and SoundWire

   - Usual HD-audio and USB-audio quirks"

* tag 'sound-6.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (27 commits)
  ALSA: hda/realtek: Fix mute led for HP Omen 17-cb0xxx
  ALSA: usb-audio: fix vendor quirk for Logitech H390
  ALSA: usb-audio: add volume quirks for MS LifeChat LX-3000
  ASoC: amd/sdw_utils: avoid NULL deref when devm_kasprintf() fails
  ASoC: max98090/91: fixed max98091 ALSA widget powering up/down
  ASoC: dt-bindings: Add compatible string fsl,imx-audio-tlv320
  ASoC: codecs: wcd938x-sdw: remove redundant runtime pm calls
  ASoC: sdw_utils: add rt1321 part id to codec_info_list
  ALSA: usb-audio: Fix NULL pointer deference in try_to_register_card
  ALSA: firewire: amdtp-stream: fix enum kernel-doc warnings
  ALSA: usb-audio: add mixer_playback_min_mute quirk for Logitech H390
  ASoC: nau8821: Avoid unnecessary blocking in IRQ handler
  ASoC: nau8821: Add DMI quirk to bypass jack debounce circuit
  ASoC: nau8821: Consistently clear interrupts before unmasking
  ASoC: nau8821: Generalize helper to clear IRQ status
  ASoC: nau8821: Cancel jdet_work before handling jack ejection
  ASoC: codecs: Fix gain setting ranges for Renesas IDT821034 codec
  ASoC: tas2781: Update ti,tas2781.yaml for adding tas58xx
  ASoC: tas2781: Support more newly-released amplifiers tas58xx in the driver
  ASoC: qcom: sc8280xp: Add support for QCS615
  ...
2025-10-17 08:20:10 -07:00
Linus Torvalds
e96687c6d3 drm fixes for 6.18-rc2
draw:
 - Avoid color truncation
 
 gpuvm:
 - Avoid kernel-doc warning
 
 sched:
 - Avoid double free
 
 i915:
 - Skip GuC communication warning if reset is in progress
 - Couple frontbuffer related fixes
 - Deactivate PSR only on LNL and when selective fetch enabled
 
 xe:
 - Increase global invalidation timeout to handle some workloads
 - Fix NPD while evicting BOs in an array of VM binds
 - Fix resizable BAR to account for possibly needing to move BARs other
   than the LMEMBAR
 - Fix error handling in xe_migrate_init()
 - Fix atomic fault handling with mixed mappings or if the page is
   already in VRAM
 - Enable media samplers power gating for platforms before Xe2
 - Fix de-registering exec queue from GuC when unbinding
 - Ensure data migration to system if indicated by madvise with SVM
 - Fix kerneldoc for kunit change
 - Always account for cacheline alignment on migration
 - Drop bogus assertion on eviction
 
 amdgpu:
 - Backlight fix
 - SI fixes
 - CIK fix
 - Make CE support debug only
 - IP discovery fix
 - Ring reset fixes
 - GPUVM fault memory barrier fix
 - Drop unused structures in amdgpu_drm.h
 - JPEG debugfs fix
 - VRAM handling fixes for GPUs without VRAM
 - GC 12 MES fixes
 
 amdkfd:
 - MES fix
 
 ast:
 - Fix display output after reboot
 
 bridge:
 - lt9211: Fix version check
 
 panthor:
 - Fix MCU suspend
 
 qaic:
 - Init bootlog in correct order
 - Treat remaining == 0 as error in find_and_map_user_pages()
 - Lock access to DBC request queue
 
 rockchip:
 - vop2: Fix destination size in atomic check
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEEKbZHaGwW9KfbeusDHTzWXnEhr4FAmjx3eUACgkQDHTzWXnE
 hr5eaw//RER6npuJ0c+fhpqXDL45pcEEGrozoctgxSb74PXf+vmcn2IbRgnGJz46
 a7XfdMvSsvmpKphmNGT5wMPDYkW5Fdq4/vIlz7DL/qsnmd+l+yw5xIKveCoi92g8
 4w4R/YzH33ApVmybIu1mSTzKSxtDYYHvdMlAPgwVo6rcG1wSzk9ONaRtuT+SE2At
 kkP7pKIG1fhxuM9zJOesz0YvBn4KF4UstOvfQO4i18tsVnKbk2LhIngftf06Sxis
 g77Ng+fqLuWuk3uxY4d5ElrSqQdLSAkW5UxNgCiV7nkIDqO+oyvH+AvTALizJhvG
 eZZtpgHiqEbUsRdb5YK2mcyzVkYkD1MBqI5kWgzH2iCQFj+gQ4FJjka51pSpdzq2
 c4cWHojLuEongQ19xrckBSQyFqDusA6a/U+B40HFe9ErlvLNTc4UlI4NwuumZrM8
 Q4fY5kbRYdqBoGTZD63UoGOqHgovMq1XXDmNcjPH0XVsYx10aKdfKYootHVA/JjG
 wHyNttXxzYTXHkpUup8ueQHLsJQ0iusp062i8ep59n6osNosvAr7XJv5RoB8n48Q
 TNp1BwjhLNqQ64PxKEq+ohULaehckchonuuN48dtuUft2zGEmoHj7xvYJB13FDrM
 gAtNp/llpufFDs+Yca7ZVRldmAqmXgadLVXPdGN/9KRJ3/8TbnU=
 =QedI
 -----END PGP SIGNATURE-----

Merge tag 'drm-fixes-2025-10-17' of https://gitlab.freedesktop.org/drm/kernel

Pull drm fixes from Dave Airlie:
 "As per usual xe/amdgpu are the leaders, with some i915 and then a
  bunch of scattered fixes. There are a bunch of stability fixes for
  some older amdgpu cards.

  draw:
   - Avoid color truncation

  gpuvm:
   - Avoid kernel-doc warning

  sched:
   - Avoid double free

  i915:
   - Skip GuC communication warning if reset is in progress
   - Couple frontbuffer related fixes
   - Deactivate PSR only on LNL and when selective fetch enabled

  xe:
   - Increase global invalidation timeout to handle some workloads
   - Fix NPD while evicting BOs in an array of VM binds
   - Fix resizable BAR to account for possibly needing to move BARs
     other than the LMEMBAR
   - Fix error handling in xe_migrate_init()
   - Fix atomic fault handling with mixed mappings or if the page is
     already in VRAM
   - Enable media samplers power gating for platforms before Xe2
   - Fix de-registering exec queue from GuC when unbinding
   - Ensure data migration to system if indicated by madvise with SVM
   - Fix kerneldoc for kunit change
   - Always account for cacheline alignment on migration
   - Drop bogus assertion on eviction

  amdgpu:
   - Backlight fix
   - SI fixes
   - CIK fix
   - Make CE support debug only
   - IP discovery fix
   - Ring reset fixes
   - GPUVM fault memory barrier fix
   - Drop unused structures in amdgpu_drm.h
   - JPEG debugfs fix
   - VRAM handling fixes for GPUs without VRAM
   - GC 12 MES fixes

  amdkfd:
   - MES fix

  ast:
   - Fix display output after reboot

  bridge:
   - lt9211: Fix version check

  panthor:
   - Fix MCU suspend

  qaic:
   - Init bootlog in correct order
   - Treat remaining == 0 as error in find_and_map_user_pages()
   - Lock access to DBC request queue

  rockchip:
   - vop2: Fix destination size in atomic check"

* tag 'drm-fixes-2025-10-17' of https://gitlab.freedesktop.org/drm/kernel: (44 commits)
  drm/sched: Fix potential double free in drm_sched_job_add_resv_dependencies
  drm/xe/evict: drop bogus assert
  drm/xe/migrate: don't misalign current bytes
  drm/xe/kunit: Fix kerneldoc for parameterized tests
  drm/xe/svm: Ensure data will be migrated to system if indicated by madvise.
  drm/gpuvm: Fix kernel-doc warning for drm_gpuvm_map_req.map
  drm/i915/psr: Deactivate PSR only on LNL and when selective fetch enabled
  drm/ast: Blank with VGACR17 sync enable, always clear VGACRB6 sync off
  accel/qaic: Synchronize access to DBC request queue head & tail pointer
  accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages()
  accel/qaic: Fix bootlog initialization ordering
  drm/rockchip: vop2: use correct destination rectangle height check
  drm/draw: fix color truncation in drm_draw_fill24
  drm/xe/guc: Check GuC running state before deregistering exec queue
  drm/xe: Enable media sampler power gating
  drm/xe: Handle mixed mappings and existing VRAM on atomic faults
  drm/xe/migrate: Fix an error path
  drm/xe: Move rebar to be done earlier
  drm/xe: Don't allow evicting of BOs in same VM in array of VM binds
  drm/xe: Increase global invalidation timeout to 1000us
  ...
2025-10-17 08:16:58 -07:00
Michal Wajdeczko
ee74634683 drm/xe/pf: Allow to restore auto-provisioning mode
After doing tweaks to the VFs provisioning we may want to restore
back the auto-provisioning mode. Allow that unless VFs are still
enabled. This can be also used to release all VFs resources.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://lore.kernel.org/r/20251015091211.592-5-michal.wajdeczko@intel.com
2025-10-17 17:12:45 +02:00
Linus Torvalds
389dfd9db6 i2c-for-6.18-rc2
- subsystem: PM cleanup after all prerequisites are merged with rc1
 - usbio: missing addition after all dependencies are in
 - slimpro: DT binding schema conversion
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAmjxObkACgkQFA3kzBSg
 KbZ5XQ//WpTB8e3U9ZS8YmuFdn2tWikbKSopy+Rt/Q65XECzFdFkh1jWgNJaGaZv
 jfyw86FSTDw1+QZz0yh1fgW3Yg1kRTvyA2s7AAsaA+NrJbEMSXl11TI7ptucVv65
 NHxzhia+Le5RW4fLoPAyMeFDkoiCeAv07YEb0XLcoUY8n3MnOv+6EK98VjsNKbDq
 Auyi6uBeNC23o+wER9Z/ybWDxoXQIVmxqiTh8Vuaps3AUnf1LOlBJfQ8Udg3ZtQw
 mEQmUeLBTjxBTMo5ggsQSFl/riHkNQ+Zs56UXjVIqQVhUCn00uOdA3Y8Fl4AWLC9
 d4XsyICTfVFH2Ll2Aj2L1uNO/QLgbYJy3O6EemCG6NScJxrBvWK3CHiQOS9XgeYh
 SD21XSn418Gcse8W9iIcXBgIr6HzuwrCksJMRquqMtTw1oJlYfIxIepNDs0BkpjE
 fUGLOtq2lVAgY4B0I/kxc9K5R20XXGVR8KsRkF5+3JEADoV34sZ/g0mGDJnQYf8k
 mnG9vffSWUqeqtmm4GuggJqW4O3Pw2qo7dnMf4GPwYaA1DjCM9biqGZF233MR0hs
 4CpLix0ZwCtygNqeTbY8ylI8xJyA/8KFEUs85dinE8wwQAZa1Hd/5YDzYpOU9TfP
 TgZiFqOqHIrfqjV5novcVYHWB6N07k7HyAeu9t5kp3l8A1qHb2s=
 =2d8F
 -----END PGP SIGNATURE-----

Merge tag 'i2c-for-6.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux

Pull i2c fixes from Wolfram Sang:

 - PM cleanup after all prerequisites are merged with rc1

 - usbio: missing addition after all dependencies are in

 - slimpro: DT binding schema conversion

* tag 'i2c-for-6.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  dt-bindings: i2c: Convert apm,xgene-slimpro-i2c to DT schema
  i2c: usbio: Add ACPI device-id for MTL-CVF devices
  i2c: Remove redundant pm_runtime_mark_last_busy() calls
2025-10-17 08:12:19 -07:00
Michal Wajdeczko
b1767ca123 drm/xe/pf: Disable auto-provisioning if changed using debugfs
When we attempt to tweak VFs configurations using debugfs, stop
assuming that VFs need auto-(un)provisioning.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://lore.kernel.org/r/20251015091211.592-4-michal.wajdeczko@intel.com
2025-10-17 17:11:09 +02:00
Michal Wajdeczko
5546bc2071 drm/xe/pf: Automatically provision VFs only in auto-mode
We shouldn't attempt to auto-provision VFs once we allow other
provisioning methods. Make the code aware of the new condition.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://lore.kernel.org/r/20251015091211.592-3-michal.wajdeczko@intel.com
2025-10-17 17:10:15 +02:00
Michal Wajdeczko
a5efeaf8a1 drm/xe/pf: Promote VFs provisioning helpers
As we plan to add more VFs provisioning methods, start moving
related code into single place.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://lore.kernel.org/r/20251015091211.592-2-michal.wajdeczko@intel.com
2025-10-17 17:09:39 +02:00