kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-13 07:31:07 +00:00
Code Issues Releases Packages Activity
1,385,869 commits 117 branches 5,827 tags 6.3 GiB
Commit graph

1,385,869 commits

This branch
This branch
All branches
Author SHA1 Message Date
Mauro Carvalho Chehab
54c147f4c7 scripts: scripts/test_doc_build.py: add script to test doc build 
Testing Sphinx backward-compatibility is hard, as per version
minimal Python dependency requirements can be a nightmare.

Add a script to help automate such checks.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/93faf6c35ec865566246ca094868a8e6d85dde39.1750571906.git.mchehab+huawei@kernel.org
 2025-06-25 12:22:47 -06:00
Mauro Carvalho Chehab
30c83405e4 docs: Makefile: disable check rules on make cleandocs 
It doesn't make sense to check for missing ABI and documents
when cleaning the tree.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/8386afcee494c9e81d051c83235150104e3a2949.1750571906.git.mchehab+huawei@kernel.org
 2025-06-25 12:22:47 -06:00
Mauro Carvalho Chehab
097fe72746 docs: conf.py: properly handle include and exclude patterns 
When one does:
	make SPHINXDIRS="foo" htmldocs

All patterns would be relative to Documentation/foo, which
causes the include/exclude patterns like:

	include_patterns = [
		...
		f'foo/*.{ext}',
	]

to break. This is not what it is expected. Address it by
adding a logic to dynamically adjust the pattern when
SPHINXDIRS is used.

That allows adding parsers for other file types.

It should be noticed that include_patterns was added on
Sphinx 5.1:
	https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-include_patterns

So, a backward-compatible code is needed when we start
using it for real.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/429c9c670fe27860f5e4f29aaf72576a4ed52ad1.1750571906.git.mchehab+huawei@kernel.org
 2025-06-25 12:22:47 -06:00
Linus Torvalds
92ca6c498a SCSI fixes on 20250625 
ixes all in drivers.  ufs and megaraid_sas are small and obvious.  The
 large diffstat in fnic comes from two pieces: 1 the addition of quite
 a bit of logging (no change to function) and the reworking of the
 timeout allocation path for the two conditions that can occur
 simultaneously to prevent reusing the same abort frame and then both
 trying to free it.
 
 Signed-off-by: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
 -----BEGIN PGP SIGNATURE-----
 
 iJwEABMIAEQWIQTnYEDbdso9F2cI+arnQslM7pishQUCaFvomyYcamFtZXMuYm90
 dG9tbGV5QGhhbnNlbnBhcnRuZXJzaGlwLmNvbQAKCRDnQslM7pishT7SAPwJGbsT
 mdT2sqfnrFNEsXVE3wKnvOTNYi2mnXoc2Z7/pQEAj1KVXg8UgW/K4yPwx+utLDZW
 M+u7fIXkRcbdxjqXwk8=
 =Xfh8
 -----END PGP SIGNATURE-----

Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

Pull SCSI fixes from James Bottomley:
 "Fixes all in drivers.

  ufs and megaraid_sas are small and obvious.

  The large diffstat in fnic comes from two pieces: the addition of
  quite a bit of logging (no change to function) and the reworking of
  the timeout allocation path for the two conditions that can occur
  simultaneously to prevent reusing the same abort frame and then both
  trying to free it"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: fnic: Fix missing DMA mapping error in fnic_send_frame()
  scsi: fnic: Set appropriate logging level for log message
  scsi: fnic: Add and improve logs in FDMI and FDMI ABTS paths
  scsi: fnic: Turn off FDMI ACTIVE flags on link down
  scsi: fnic: Fix crash in fnic_wq_cmpl_handler when FDMI times out
  scsi: ufs: core: Fix clk scaling to be conditional in reset and restore
  scsi: megaraid_sas: Fix invalid node index
 2025-06-25 11:20:14 -07:00
Alexandre Courbot
4092e1b412 gpu: nova-core: replace Duration with Delta 
The kernel's `Delta` type was not available when the `wait_on` function
was introduced. Now that it is, switch to it as it is more compact than
`Duration` and cannot panic.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Link: https://lore.kernel.org/r/20250624-nova-delta-v1-1-b37d75a593ac@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
 2025-06-25 20:13:32 +02:00
Linus Torvalds
2dca89df0d Just a few fixes: 
- fix FP registers in seccomp mode
  - prevent duplicate devices in VFIO support
  - don't ignore errors in UBD thread start
  - reduce stack use with clang 19
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEpeA8sTs3M8SN2hR410qiO8sPaAAFAmhb5+cACgkQ10qiO8sP
 aACBSQ/+ObgcvoB5wEWoc4fWdR7OVysfRMwBKjP6YiKWVVIhISl5VV4ODhaulQCG
 QBt0pYBqmfljZosQ6vkmNm4wNm03Si/aF9pcFuVqP/HjioOWKglt5FH1PqUcTXQs
 sJTDZI4u4+uTqwZ2cD3nZjS2uUV2PjfYmX93Ni48OdoB8nefIKRKwFGHAkPb/34i
 0x58dr8ci1RAlSpQaOu8n7BdII3wp8EehsHDGBf49L1hDbhTsPLOnCllGZE8R+Uf
 SFGH/MTK5kVeo/Rfxa5m2znidUlSQ//XcdNDxcWZo7/ZuyebrilxdiSClpkXCdOb
 fTsHR/RtTo/s/gQOn2vvezv+njt9jmnNcHZXJaG844gPn0Q530KuUTLLHccIHY5s
 ITMkZU0Gf/OgTZJ78z1+fQfSm9Wop9T7b6+5RCS4IZSasPOfJVwycEGnALN1+s9N
 iCFPQXMsMQY38KDgOTse+wF0lcIbtpxfWTTkfr1IDVVk3PBzMyaa7n774aOLXAhE
 J0Dc2+DimrgRXJg/UF6KxWMTVL3V1BaRbxhQvHgiU+PT+nKdQKWoPuO4QkuD5ZBK
 cllS/uZp1M5C9Zn4Zyr2F8BsoUJw5liZfyeUXZGs6UoqWXMMQSu5WSurZaBLTh+J
 XzKJSZUZJhkEWHIcLSFpYeSrBFjcrthZlTXX+aHXQ36KDjziKcY=
 =wwuV
 -----END PGP SIGNATURE-----

Merge tag 'uml-for-6.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/uml/linux

Pull UML fixes from Johannes Berg:

 - fix FP registers in seccomp mode

 - prevent duplicate devices in VFIO support

 - don't ignore errors in UBD thread start

 - reduce stack use with clang 19

* tag 'uml-for-6.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/uml/linux:
  um: vector: Reduce stack usage in vector_eth_configure()
  um: Use correct data source in fpregs_legacy_set()
  um: vfio: Prevent duplicate device assignments
  um: ubd: Add missing error check in start_io_thread()
 2025-06-25 11:13:31 -07:00
Danilo Krummrich
d612799de7 MAINTAINERS: Add Alexandre Courbot as co-maintainer to nova-core 
Alex has extensive experience with NVIDIA GPU support, is closely
involved in nova-core development, and brings valuable Rust expertise.

In addition to his technical contributions, Alex is actively engaged with
the broader community. He works closely with contributors and
stakeholders to identify and solve issues, fosters collaboration, and
helps ensure that the Nova driver evolves in alignment with the
community.

I trust him to take a key role in making the Nova driver a successful
upstream solution for NVIDIA GPUs in the Linux kernel.

Cc: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: John Hubbard <jhubbard@nvidia.com>
Link: https://lore.kernel.org/r/20250624170517.105148-1-dakr@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
 2025-06-25 20:12:39 +02:00
Ian Rogers
45cd84bd7a perf tests: Add a DRM PMU test 
The test opens any DRM devices so that the shell has fdinfo files
containing the DRM data. The test then uses perf stat to make sure the
events can be read.

Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250624231837.179536-4-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
 2025-06-25 11:12:35 -07:00
Ian Rogers
28917cb17f perf drm_pmu: Add a tool like PMU to expose DRM information 
DRM clients expose information through usage stats as documented in
Documentation/gpu/drm-usage-stats.rst (available online at
https://docs.kernel.org/gpu/drm-usage-stats.html). Add a tool like
PMU, similar to the hwmon PMU, that exposes DRM information. For
example on a tigerlake laptop:
```
$ perf list drm

List of pre-defined events (to be used in -e or -M):

drm:
  drm-active-stolen-system0
       [Total memory active in one or more engines. Unit: drm_i915]
  drm-active-system0
       [Total memory active in one or more engines. Unit: drm_i915]
  drm-engine-capacity-video
       [Engine capacity. Unit: drm_i915]
  drm-engine-copy
       [Utilization in ns. Unit: drm_i915]
  drm-engine-render
       [Utilization in ns. Unit: drm_i915]
  drm-engine-video
       [Utilization in ns. Unit: drm_i915]
  drm-engine-video-enhance
       [Utilization in ns. Unit: drm_i915]
  drm-purgeable-stolen-system0
       [Size of resident and purgeable memory bufers. Unit: drm_i915]
  drm-purgeable-system0
       [Size of resident and purgeable memory bufers. Unit: drm_i915]
  drm-resident-stolen-system0
       [Size of resident memory bufers. Unit: drm_i915]
  drm-resident-system0
       [Size of resident memory bufers. Unit: drm_i915]
  drm-shared-stolen-system0
       [Size of shared memory bufers. Unit: drm_i915]
  drm-shared-system0
       [Size of shared memory bufers. Unit: drm_i915]
  drm-total-stolen-system0
       [Size of shared and private memory. Unit: drm_i915]
  drm-total-system0
       [Size of shared and private memory. Unit: drm_i915]
```

System wide data can be gathered:
```
$ perf stat -x, -I 1000 -e drm-active-stolen-system0,drm-active-system0,drm-engine-capacity-video,drm-engine-copy,drm-engine-render,drm-engine-video,drm-engine-video-enhance,drm-purgeable-stolen-system0,drm-purgeable-system0,drm-resident-stolen-system0,drm-resident-system0,drm-shared-stolen-system0,drm-shared-system0,drm-total-stolen-system0,drm-total-system0
1.000904910,0,bytes,drm-active-stolen-system0,1,100.00,,
1.000904910,0,bytes,drm-active-system0,1,100.00,,
1.000904910,36,capacity,drm-engine-capacity-video,1,100.00,,
1.000904910,0,ns,drm-engine-copy,1,100.00,,
1.000904910,1472970566175,ns,drm-engine-render,1,100.00,,
1.000904910,0,ns,drm-engine-video,1,100.00,,
1.000904910,0,ns,drm-engine-video-enhance,1,100.00,,
1.000904910,0,bytes,drm-purgeable-stolen-system0,1,100.00,,
1.000904910,38199296,bytes,drm-purgeable-system0,1,100.00,,
1.000904910,0,bytes,drm-resident-stolen-system0,1,100.00,,
1.000904910,4643196928,bytes,drm-resident-system0,1,100.00,,
1.000904910,0,bytes,drm-shared-stolen-system0,1,100.00,,
1.000904910,1886871552,bytes,drm-shared-system0,1,100.00,,
1.000904910,0,bytes,drm-total-stolen-system0,1,100.00,,
1.000904910,4643196928,bytes,drm-total-system0,1,100.00,,
2.264426839,0,bytes,drm-active-stolen-system0,1,100.00,,
```

Or for a particular process:
```
$ perf stat -x, -I 1000 -e drm-active-stolen-system0,drm-active-system0,drm-engine-capacity-video,drm-engine-copy,drm-engine-render,drm-engine-video,drm-engine-video-enhance,drm-purgeable-stolen-system0,drm-purgeable-system0,drm-resident-stolen-system0,drm-resident-system0,drm-shared-stolen-system0,drm-shared-system0,drm-total-stolen-system0,drm-total-system0 -p 200027
1.001040274,0,bytes,drm-active-stolen-system0,6,100.00,,
1.001040274,0,bytes,drm-active-system0,6,100.00,,
1.001040274,12,capacity,drm-engine-capacity-video,6,100.00,,
1.001040274,0,ns,drm-engine-copy,6,100.00,,
1.001040274,1542300,ns,drm-engine-render,6,100.00,,
1.001040274,0,ns,drm-engine-video,6,100.00,,
1.001040274,0,ns,drm-engine-video-enhance,6,100.00,,
1.001040274,0,bytes,drm-purgeable-stolen-system0,6,100.00,,
1.001040274,13516800,bytes,drm-purgeable-system0,6,100.00,,
1.001040274,0,bytes,drm-resident-stolen-system0,6,100.00,,
1.001040274,27746304,bytes,drm-resident-system0,6,100.00,,
1.001040274,0,bytes,drm-shared-stolen-system0,6,100.00,,
1.001040274,0,bytes,drm-shared-system0,6,100.00,,
1.001040274,0,bytes,drm-total-stolen-system0,6,100.00,,
1.001040274,27746304,bytes,drm-total-system0,6,100.00,,
2.016629075,0,bytes,drm-active-stolen-system0,6,100.00,,
```

As with the hwmon PMU, high numbered PMU types are used to encode
multiple possible "DRM" PMUs. The appropriate fdinfo is found by
scanning /proc and filtering which fdinfos to read with stat. To avoid
some unneeding scanning, events not starting with "drm-" are
ignored. The patch builds on commit 57e13264dc ("perf pmus:
Restructure pmu_read_sysfs to scan fewer PMUs") and later so that only
if full wild carding is being done, the PMU starts with "drm_" or the
event starts with "drm-" will /proc be scanned. That is there should
be little to no cost in this PMU unless DRM events are requested.

Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250624231837.179536-3-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
 2025-06-25 11:12:35 -07:00
Ian Rogers
e1ec69ed5d perf parse-events: Avoid scanning PMUs that can't contain events 
Add perf_pmus__scan_for_event that only reads sysfs for pmus that
could contain a given event.

Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250624231837.179536-2-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
 2025-06-25 11:12:35 -07:00
Sakari Ailus
d6b93bfa5d drm/nouveau/disp: Use dev->dev to get the device 
The local variable dev points to drm->dev already, use dev directly.

Link: https://lore.kernel.org/r/20250409103344.3661603-1-sakari.ailus@linux.intel.com
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
 2025-06-25 20:07:03 +02:00
Ian Rogers
9c9f4a27eb perf debug: Add function symbols to dump_stack 
Symbolize stack traces by creating a live machine. Add this
functionality to dump_stack and switch dump_stack users to use
it. Switch TUI to use it. Add stack traces to the child test function
which can be useful to diagnose blocked code.

Example output:
```
$ perf test -vv PERF_RECORD_
...
  7: PERF_RECORD_* events & perf_sample fields:
  7: PERF_RECORD_* events & perf_sample fields                       : Running (1 active)
^C
Signal (2) while running tests.
Terminating tests with the same signal
Internal test harness failure. Completing any started tests:
:  7: PERF_RECORD_* events & perf_sample fields:

---- unexpected signal (2) ----
    #0 0x55788c6210a3 in child_test_sig_handler builtin-test.c:0
    #1 0x7fc12fe49df0 in __restore_rt libc_sigaction.c:0
    #2 0x7fc12fe99687 in __internal_syscall_cancel cancellation.c:64
    #3 0x7fc12fee5f7a in clock_nanosleep@GLIBC_2.2.5 clock_nanosleep.c:72
    #4 0x7fc12fef1393 in __nanosleep nanosleep.c:26
    #5 0x7fc12ff02d68 in __sleep sleep.c:55
    #6 0x55788c63196b in test__PERF_RECORD perf-record.c:0
    #7 0x55788c620fb0 in run_test_child builtin-test.c:0
    #8 0x55788c5bd18d in start_command run-command.c:127
    #9 0x55788c621ef3 in __cmd_test builtin-test.c:0
    #10 0x55788c6225bf in cmd_test ??:0
    #11 0x55788c5afbd0 in run_builtin perf.c:0
    #12 0x55788c5afeeb in handle_internal_command perf.c:0
    #13 0x55788c52b383 in main ??:0
    #14 0x7fc12fe33ca8 in __libc_start_call_main libc_start_call_main.h:74
    #15 0x7fc12fe33d65 in __libc_start_main@@GLIBC_2.34 libc-start.c:128
    #16 0x55788c52b9d1 in _start ??:0

---- unexpected signal (2) ----
    #0 0x55788c6210a3 in child_test_sig_handler builtin-test.c:0
    #1 0x7fc12fe49df0 in __restore_rt libc_sigaction.c:0
    #2 0x7fc12fea3a14 in pthread_sigmask@GLIBC_2.2.5 pthread_sigmask.c:45
    #3 0x7fc12fe49fd9 in __GI___sigprocmask sigprocmask.c:26
    #4 0x7fc12ff2601b in __longjmp_chk longjmp.c:36
    #5 0x55788c6210c0 in print_test_result.isra.0 builtin-test.c:0
    #6 0x7fc12fe49df0 in __restore_rt libc_sigaction.c:0
    #7 0x7fc12fe99687 in __internal_syscall_cancel cancellation.c:64
    #8 0x7fc12fee5f7a in clock_nanosleep@GLIBC_2.2.5 clock_nanosleep.c:72
    #9 0x7fc12fef1393 in __nanosleep nanosleep.c:26
    #10 0x7fc12ff02d68 in __sleep sleep.c:55
    #11 0x55788c63196b in test__PERF_RECORD perf-record.c:0
    #12 0x55788c620fb0 in run_test_child builtin-test.c:0
    #13 0x55788c5bd18d in start_command run-command.c:127
    #14 0x55788c621ef3 in __cmd_test builtin-test.c:0
    #15 0x55788c6225bf in cmd_test ??:0
    #16 0x55788c5afbd0 in run_builtin perf.c:0
    #17 0x55788c5afeeb in handle_internal_command perf.c:0
    #18 0x55788c52b383 in main ??:0
    #19 0x7fc12fe33ca8 in __libc_start_call_main libc_start_call_main.h:74
    #20 0x7fc12fe33d65 in __libc_start_main@@GLIBC_2.34 libc-start.c:128
    #21 0x55788c52b9d1 in _start ??:0
  7: PERF_RECORD_* events & perf_sample fields                       : Skip (permissions)
```

Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20250624210500.2121303-1-irogers@google.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
 2025-06-25 10:59:19 -07:00
Jonathan Corbet
07e04d8e7d docs: kdoc: finish disentangling the BODY and SPECIAL_SECTION states 
Move the last SPECIAL_SECTION special case into the proper handler
function, getting rid of more if/then/else logic.  The leading-space
tracking was tightened up a bit in the move.  Add some comments describing
what is going on.

No changes to the generated output.

Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250621203512.223189-10-corbet@lwn.net
 2025-06-25 11:30:26 -06:00
Jonathan Corbet
ccad65a494 docs: kdoc: Add some comments to process_decl() 
Now that the function can actually fit into a human brain, add a few
comments.  While I was at it, I switched to the trim_whitespace() helper
rather than open-coding it.

Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250621203512.223189-9-corbet@lwn.net
 2025-06-25 11:30:26 -06:00
Jonathan Corbet
2ad02b9491 docs: kdoc: coalesce the end-of-comment processing 
Separate out the end-of-comment logic into its own helper and remove the
duplicated code introduced earlier.

Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250621203512.223189-8-corbet@lwn.net
 2025-06-25 11:30:26 -06:00
Jonathan Corbet
e65d54e191 docs: kdoc: rework the handling of SPECIAL_SECTION 
Move the recognition of this state to when we enter it, rather than when we
exit, eliminating some twisty logic along the way.

Some changes in output do result from this shift, generally for kerneldoc
comments that do not quite fit the format.  See, for example,
struct irqdomain.  As far as I can tell, the new behavior is more correct
in each case.

Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250621203512.223189-7-corbet@lwn.net
 2025-06-25 11:30:26 -06:00
Jonathan Corbet
99327067e1 docs: kdoc: coalesce the new-section handling 
Merge the duplicated code back into a single implementation.  Code movement
only, no logic changes.

Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250621203512.223189-6-corbet@lwn.net
 2025-06-25 11:30:26 -06:00
Jonathan Corbet
74cee0dfc2 docs: kdoc: split out the special-section state 
The state known as BODY_WITH_BLANK_LINE really, in a convoluted way,
indicates a "special section" that is terminated by a blank line or the
beginning of a new section.  That is either "@param: desc" sections, or the
weird "context" section that plays by the same rules.

Rename the state to SPECIAL_SECTION and split its processing into a
separate function; no real changes to the logic yet.

Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250621203512.223189-5-corbet@lwn.net
 2025-06-25 11:30:26 -06:00
Jonathan Corbet
e4153a2255 docs: kdoc: separate out the handling of the declaration phase 
The BODY_MAYBE state really describes the "we are in a declaration" state.
Rename it accordingly, and split the handling of this state out from that
of the other BODY* states.  This change introduces a fair amount of
duplicated code that will be coalesced in a later patch.

Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250621203512.223189-4-corbet@lwn.net
 2025-06-25 11:30:26 -06:00
Jonathan Corbet
df27552694 docs: kdoc: consolidate the "begin section" logic 
Pull the repeated "begin a section" logic into a single place and hide it
within the KernelEntry class.

Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250621203512.223189-3-corbet@lwn.net
 2025-06-25 11:30:26 -06:00
Jonathan Corbet
823d6f9566 docs: kdoc: Make body_with_blank_line parsing more flexible 
The regex in the BODY_WITH_BLANK_LINE case was looking for lines starting
with " * ", where exactly one space was allowed before the following text.
There are many kerneldoc comments where the authors have put multiple
spaces instead, leading to mis-formatting of the documentation.
Specifically, in this case, the description portion is associated with the
last of the parameters.

Allow multiple spaces in this context.

See, for example, synchronize_hardirq() and how its documentation is
formatted before and after the change.

Acked-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Tested-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20250621203512.223189-2-corbet@lwn.net
 2025-06-25 11:30:26 -06:00
Jakub Kicinski
ab4eb6a25d The usual features/cleanups/etc., notably: 
- rtw88: IBSS mode for SDIO devices
  - rtw89:
    - BT coex for MLO/WiFi7
    - work on station + P2P concurrency
  - ath: fix W=2 export.h warnings
  - ath12k: fix scan on multi-radio devices
  - cfg80211/mac80211: MLO statistics
  - mac80211: S1G aggregation
  - cfg80211/mac80211: per-radio RTS threshold
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEpeA8sTs3M8SN2hR410qiO8sPaAAFAmhb5KsACgkQ10qiO8sP
 aAC8mQ//RPsycyRQ3XRf3E1OsGV61M1iJJRvdmNtW7GMi6Ztc96xkf1oGHQRH2x1
 lQ6PiDGEG9dvtQNvE2rS1vtgsFAa0pWB4+pD2t+mIs3umwxGI8OhgwgSIY1GYTwe
 Jq9IqsxSFMc38pI4RPVL2TgKJ81W3Ak51DAbCBxP5Lo2vFyFYe6toVc8+88WyPTX
 +hhY5cw2WSDwWiRQ9BPTgs5+LKRnIVh8xmX0I69bUX8zZ0MxU2z0UGzjVQOjywDK
 w89jdqwwbMVMIL8Ti2foIfI8UC4N+KwDeMB7HLJhkTEf8B4VScd8aeSFIOtjz/j0
 V20fegLfJ31DvsXWI5I2ia7DKDnMRA3Kb1XZzsS5qeY7jTolLMUS9c96fw7SUfVd
 P3clV5H1kKretnzxKijUbrG2MgHsuIzX3x6GXWtuZEcVyrovh9wSz08B4/DbfPe7
 PSqVug+GOnH5YV7RpP9jByvY86MT846O/V+MYi+CkrwgMATRyX0jA6EXUVe26kzT
 mL3Xr68aSUKLxkLgiCWSdzQw7e+YF56JbpcbJQOq0Z16CIOw1k84r62kBUFzNB3k
 tG5InbFYAGiNJu2LmhFFZN8grD1TrDYKuzmgBoia48TpI2gwlwcW3kCWfMfty25L
 IJ4p+SAsTvnYpbLesWQHDZ0bouQCKPouB5NUqVHFNhBCIBMo634=
 =16yP
 -----END PGP SIGNATURE-----

Merge tag 'wireless-next-2025-06-25' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next

Johannes Berg says:

====================
The usual features/cleanups/etc., notably:

 - rtw88: IBSS mode for SDIO devices
 - rtw89:
   - BT coex for MLO/WiFi7
   - work on station + P2P concurrency
 - ath: fix W=2 export.h warnings
 - ath12k: fix scan on multi-radio devices
 - cfg80211/mac80211: MLO statistics
 - mac80211: S1G aggregation
 - cfg80211/mac80211: per-radio RTS threshold

* tag 'wireless-next-2025-06-25' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (171 commits)
  wifi: iwlwifi: dvm: fix potential overflow in rs_fill_link_cmd()
  iwlwifi: Add missing check for alloc_ordered_workqueue
  wifi: iwlwifi: Fix memory leak in iwl_mvm_init()
  iwlwifi: api: delete repeated words
  iwlwifi: remove unused no_sleep_autoadjust declaration
  iwlwifi: Fix comment typo
  iwlwifi: use DECLARE_BITMAP macro
  iwlwifi: fw: simplify the iwl_fw_dbg_collect_trig()
  wifi: iwlwifi: mld: ftm: fix switch end indentation
  MAINTAINERS: update iwlwifi git link
  wifi: iwlwifi: pcie: fix non-MSIX handshake register
  wifi: iwlwifi: mld: don't exit EMLSR when we shouldn't
  wifi: iwlwifi: move _iwl_trans_set_bits_mask utilities
  wifi: iwlwifi: mld: make iwl_mld_add_all_rekeys void
  wifi: iwlwifi: move iwl_trans_pcie_write_mem to iwl-trans.c
  wifi: iwlwifi: pcie: move iwl_trans_pcie_dump_regs() to utils.c
  wifi: iwlwifi: mld: advertise support for TTLM changes
  wifi: iwlwifi: mld: Block EMLSR when scanning on P2P Device
  wifi: iwlwifi: mld: use the correct struct size for tracing
  wifi: iwlwifi: support RZL platform device ID
  ...
====================

Link: https://patch.msgid.link/20250625120135.41933-55-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
 2025-06-25 10:28:13 -07:00
Jakub Kicinski
010c40c1f5 Just a few fixes: 
- iwlegacy: work around large stack with clang/kasan
  - mac80211: fix integer overflow
  - mac80211: fix link struct init vs. RCU publish
  - iwlwifi: fix warning on IFF_UP
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEpeA8sTs3M8SN2hR410qiO8sPaAAFAmhb4zAACgkQ10qiO8sP
 aAAJMA/+KBq3/uvXAv7Mxtg2YTvmzKMs/Zsk3Uh1yCijsm6K9/yMkcuvyRDs9n+M
 yobTGwlNKsg+xZmwKM6vT2TwFN4cJhFsz9pL/QQ7M6k4ZARv6MkIgXxhJ5504trv
 ufsea2iCN2xHQ7Y81SNFjtZwckMPhS1Cgs7OdjOkP8GJPDsTXrdTNSZZh69l3XX1
 RG0Fp98RhPnONmzj+ewj3leVMwJlCyAdzqx1B3Hk1tJQojUtkmwg1F+bpAifYBLs
 arORBtkL4cVYXcYkoBJ+WFLMztooAaqo4Oal8s4zl5/VubjCb30+mBFRQytD9ldD
 gp2gqY6Y1BAiCZKBxjAwRvG743CBPEBD7tHUDtS4cbPPChjMKWXrakWkLGjTDv50
 wYnb9EsPKt03L353vaQ/BHW2m88ebxIYiaSVUY+animRvadpFihzT2fF9P+0/eHi
 zU2AFlmF0bS74OtjyOVXSSin0pTmBEHDIRfqBdw/szGhMqBdHDq+qPb2H2TJnfZy
 eec1MS0td8MYN9SV9xPac+4EqUbOHDlQ4fVD3rCn74+wESQp7HUnSJOgobB6cOJg
 N3tao+n/K8kYxdaCplqAeWMD3bFSYs9oz404K3wOeO85lHz+lB581j6as8zJ86cL
 nJVLEflnDCQHnxFCEMHeV/1q/GjIU7Xv5+rwDpfMEY3hx0jH1d8=
 =6koP
 -----END PGP SIGNATURE-----

Merge tag 'wireless-2025-06-25' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless

Johannes Berg says:

====================
Just a few fixes:
 - iwlegacy: work around large stack with clang/kasan
 - mac80211: fix integer overflow
 - mac80211: fix link struct init vs. RCU publish
 - iwlwifi: fix warning on IFF_UP

* tag 'wireless-2025-06-25' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless:
  wifi: mac80211: finish link init before RCU publish
  wifi: iwlwifi: mvm: assume '1' as the default mac_config_cmd version
  wifi: mac80211: fix beacon interval calculation overflow
  wifi: iwlegacy: work around excessive stack usage on clang/kasan
====================

Link: https://patch.msgid.link/20250625115433.41381-3-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
 2025-06-25 10:26:16 -07:00
Matthew Brost
5a2f117a80 drm/xe: Do not wedge device on killed exec queues 
When a user closes an exec queue or interrupts an app with Ctrl-C,
this does not warrant wedging the device in mode 2.

Avoid this by skipping the wedge check for killed exec queues in
the TDR and LR exec queue cleanup worker.

Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250624174103.2707941-1-matthew.brost@intel.com
 2025-06-25 09:55:20 -07:00
Sean Christopherson
bbc13ae593 VFIO: KVM: x86: Drop kvm_arch_{start,end}_assignment() 
Drop kvm_arch_{start,end}_assignment() and all associated code now that
KVM x86 no longer consumes assigned_device_count.  Tracking whether or not
a VFIO-assigned device is formally associated with a VM is fundamentally
flawed, as such an association is optional for general usage, i.e. is prone
to false negatives.  E.g. prior to commit 2edd9cb79f ("kvm: detect
assigned device via irqbypass manager"), device passthrough via VFIO would
fail to enable IRQ bypass if userspace omitted the formal VFIO<=>KVM
binding.

And device drivers that *need* the VFIO<=>KVM connection, e.g. KVM-GT,
shouldn't be relying on generic x86 tracking infrastructure.

Cc: Jim Mattson <jmattson@google.com>
Link: https://lore.kernel.org/r/20250523011756.3243624-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
 2025-06-25 09:51:33 -07:00
Sean Christopherson
ff845e6a84 Revert "kvm: detect assigned device via irqbypass manager" 
Now that KVM explicitly tracks the number of possible bypass IRQs, and
doesn't conflate IRQ bypass with host MMIO access, stop bumping the
assigned device count when adding an IRQ bypass producer.

This reverts commit 2edd9cb79f.

Link: https://lore.kernel.org/r/20250523011756.3243624-5-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
 2025-06-25 09:51:29 -07:00
Sean Christopherson
95d9b5d8d6 Merge branch 'kvm-x86 mmio' 
Merge the MMIO stale data branch with the device posted IRQs branch to
provide a common base for removing KVM's tracking of "assigned" devices.

Link: https://lore.kernel.org/all/20250523011756.3243624-1-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
 2025-06-25 09:50:58 -07:00
Chao Gao
05186d7a8e KVM: SVM: Simplify MSR interception logic for IA32_XSS MSR 
Use svm_set_intercept_for_msr() directly to configure IA32_XSS MSR
interception, ensuring consistency with other cases where MSRs are
intercepted depending on guest caps and CPUIDs.

No functional change intended.

Signed-off-by: Chao Gao <chao.gao@intel.com>
Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
Link: https://lore.kernel.org/r/20250612081947.94081-3-chao.gao@intel.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
 2025-06-25 09:47:28 -07:00
Mark Brown
086d0960d8
 		ASoC: sdw_utils: generate combined spk components 
Merge series from Bard Liao <yung-chuan.liao@linux.intel.com>:

The series adds support for combined speaker components with one "spk:"
tag in the card->components string. This is a UCM request.
 2025-06-25 17:23:15 +01:00
Jens Axboe
9a709b7e98 io_uring/net: mark iov as dynamically allocated even for single segments 
A bigger array of vecs could've been allocated, but
io_ring_buffers_peek() still decided to cap the mapped range depending
on how much data was available. Hence don't rely on the segment count
to know if the request should be marked as needing cleanup, always
check upfront if the iov array is different than the fast_iov array.

Fixes: 26ec15e4b0 ("io_uring/kbuf: don't truncate end buffer for multiple buffer peeks")
Signed-off-by: Jens Axboe <axboe@kernel.dk>
 2025-06-25 10:17:06 -06:00
Manuel Andreas
fa787ac07b KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush 
In KVM guests with Hyper-V hypercalls enabled, the hypercalls
HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX
allow a guest to request invalidation of portions of a virtual TLB.
For this, the hypercall parameter includes a list of GVAs that are supposed
to be invalidated.

However, when non-canonical GVAs are passed, there is currently no
filtering in place and they are eventually passed to checked invocations of
INVVPID on Intel / INVLPGA on AMD.  While AMD's INVLPGA silently ignores
non-canonical addresses (effectively a no-op), Intel's INVVPID explicitly
signals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():

  invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000
  WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482
  invvpid_error+0x91/0xa0 [kvm_intel]
  Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse
  CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary)
  RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel]
  Call Trace:
    vmx_flush_tlb_gva+0x320/0x490 [kvm_intel]
    kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm]
    kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]

Hyper-V documents that invalid GVAs (those that are beyond a partition's
GVA space) are to be ignored.  While not completely clear whether this
ruling also applies to non-canonical GVAs, it is likely fine to make that
assumption, and manual testing on Azure confirms "real" Hyper-V interprets
the specification in the same way.

Skip non-canonical GVAs when processing the list of address to avoid
tripping the INVVPID failure.  Alternatively, KVM could filter out "bad"
GVAs before inserting into the FIFO, but practically speaking the only
downside of pushing validation to the final processing is that doing so
is suboptimal for the guest, and no well-behaved guest will request TLB
flushes for non-canonical addresses.

Fixes: 260970862c ("KVM: x86: hyper-v: Handle HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST{,EX} calls gently")
Cc: stable@vger.kernel.org
Signed-off-by: Manuel Andreas <manuel.andreas@tum.de>
Suggested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Link: https://lore.kernel.org/r/c090efb3-ef82-499f-a5e0-360fc8420fb7@tum.de
Signed-off-by: Sean Christopherson <seanjc@google.com>
 2025-06-25 09:15:24 -07:00
Dharma Balasubiramani
7360dab3be ARM: dts: microchip: sam9x7: Add LVDS controller 
Add support for LVDS controller.

Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com>
Link: https://lore.kernel.org/r/20250625-b4-sam9x7-dts-v1-1-92aaee14ed16@microchip.com
Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
 2025-06-25 19:13:22 +03:00
Stefan Metzmacher
1944f6ab49 smb: client: let smbd_post_send_iter() respect the peers max_send_size and transmit all data 
We should not send smbdirect_data_transfer messages larger than
the negotiated max_send_size, typically 1364 bytes, which means
24 bytes of the smbdirect_data_transfer header + 1340 payload bytes.

This happened when doing an SMB2 write with more than 1340 bytes
(which is done inline as it's below rdma_readwrite_threshold).

It means the peer resets the connection.

When testing between cifs.ko and ksmbd.ko something like this
is logged:

client:

    CIFS: VFS: RDMA transport re-established
    siw: got TERMINATE. layer 1, type 2, code 2
    siw: got TERMINATE. layer 1, type 2, code 2
    siw: got TERMINATE. layer 1, type 2, code 2
    siw: got TERMINATE. layer 1, type 2, code 2
    siw: got TERMINATE. layer 1, type 2, code 2
    siw: got TERMINATE. layer 1, type 2, code 2
    siw: got TERMINATE. layer 1, type 2, code 2
    siw: got TERMINATE. layer 1, type 2, code 2
    siw: got TERMINATE. layer 1, type 2, code 2
    CIFS: VFS: \\carina Send error in SessSetup = -11
    smb2_reconnect: 12 callbacks suppressed
    CIFS: VFS: reconnect tcon failed rc = -11
    CIFS: VFS: reconnect tcon failed rc = -11
    CIFS: VFS: reconnect tcon failed rc = -11
    CIFS: VFS: SMB: Zero rsize calculated, using minimum value 65536

and:

    CIFS: VFS: RDMA transport re-established
    siw: got TERMINATE. layer 1, type 2, code 2
    CIFS: VFS: smbd_recv:1894 disconnected
    siw: got TERMINATE. layer 1, type 2, code 2

The ksmbd dmesg is showing things like:

    smb_direct: Recv error. status='local length error (1)' opcode=128
    smb_direct: disconnected
    smb_direct: Recv error. status='local length error (1)' opcode=128
    ksmbd: smb_direct: disconnected
    ksmbd: sock_read failed: -107

As smbd_post_send_iter() limits the transmitted number of bytes
we need loop over it in order to transmit the whole iter.

Reviewed-by: David Howells <dhowells@redhat.com>
Tested-by: David Howells <dhowells@redhat.com>
Tested-by: Meetakshi Setiya <msetiya@microsoft.com>
Cc: Tom Talpey <tom@talpey.com>
Cc: linux-cifs@vger.kernel.org
Cc: <stable+noautosel@kernel.org> # sp->max_send_size should be info->max_send_size in backports
Fixes: 3d78fe73fa ("cifs: Build the RDMA SGE list directly from an iterator")
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
 2025-06-25 11:12:54 -05:00
Danilo Krummrich
9da36b9fae samples: rust: platform: conditionally call Self::properties_parse() 
Only call Self::properties_parse() when the FwNode is an OF node.

Once we add ACPI support, we don't want the ACPI device to fail probing
in Self::properties_parse().

Signed-off-by: Igor Korotin <igor.korotin.linux@gmail.com>
Link: https://lore.kernel.org/r/20250620152103.282763-1-igor.korotin.linux@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
 2025-06-25 18:10:12 +02:00
Danilo Krummrich
c69072d3a1 samples: rust: platform: don't call as_ref() repeatedly 
In SampleDriver::probe() don't call pdev.as_ref() repeatedly, instead
introduce a dedicated &Device.

Signed-off-by: Igor Korotin <igor.korotin.linux@gmail.com>
Reviewed-by: Dirk Behme <dirk.behme@de.bosch.com>
Link: https://lore.kernel.org/r/20250620151849.281238-1-igor.korotin.linux@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
 2025-06-25 18:10:12 +02:00
Danilo Krummrich
56a789f776 rust: device: implement FwNode::is_of_node() 
Implement FwNode::is_of_node() in order to check whether a FwNode
instance is embedded in a struct device_node.

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Igor Korotin <igor.korotin.linux@gmail.com>
Link: https://lore.kernel.org/r/20250620151504.278766-1-igor.korotin.linux@gmail.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
 2025-06-25 18:10:12 +02:00
Remo Senekowitsch
c79cbde9b7 samples: rust: platform: Add property child and reference args examples 
Add some example usage of the device property methods for reading
DT/ACPI/swnode child nodes and reference args.

Signed-off-by: Remo Senekowitsch <remo@buenzli.dev>
Link: https://lore.kernel.org/r/20250616154511.1862909-4-remo@buenzli.dev
[ Convert 'child@{0,1}' to 'child-{0,1}'; skip child nodes without
  'compatible' property in of_unittest_platform_populate() as proposed
  by Rob Herring. - Danilo]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
 2025-06-25 17:48:41 +02:00
Remo Senekowitsch
c3e05bd15e rust: device: Add property_get_reference_args 
Allow Rust code to read reference args from device properties. The
wrapper type `FwNodeReferenceArgs` allows callers to access the buffer
of read args safely.

Signed-off-by: Remo Senekowitsch <remo@buenzli.dev>
Link: https://lore.kernel.org/r/20250616154511.1862909-3-remo@buenzli.dev
[ Move up NArgs; refer to FwNodeReferenceArgs in NArgs doc-comment.
  - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
 2025-06-25 17:47:13 +02:00
Sean Christopherson
83ebe71574 KVM: VMX: Apply MMIO Stale Data mitigation if KVM maps MMIO into the guest 
Enforce the MMIO State Data mitigation if KVM has ever mapped host MMIO
into the VM, not if the VM has an assigned device.  VFIO is but one of
many ways to map host MMIO into a KVM guest, and even within VFIO,
formally attaching a device to a VM via KVM_DEV_VFIO_FILE_ADD is entirely
optional.

Track whether or not the guest can access host MMIO on a per-MMU basis,
i.e. based on whether or not the vCPU has a mapping to host MMIO.  For
simplicity, track MMIO mappings in "special" rools (those without a
kvm_mmu_page) at the VM level, as only Intel CPUs are vulnerable, and so
only legacy 32-bit shadow paging is affected, i.e. lack of precise
tracking is a complete non-issue.

Make the per-MMU and per-VM flags sticky.  Detecting when *all* MMIO
mappings have been removed would be absurdly complex.  And in practice,
removing MMIO from a guest will be done by deleting the associated memslot,
which by default will force KVM to re-allocate all roots.  Special roots
will forever be mitigated, but as above, the affected scenarios are not
expected to be performance sensitive.

Use a VMX_RUN flag to communicate the need for a buffers flush to
vmx_vcpu_enter_exit() so that kvm_vcpu_can_access_host_mmio() and all its
dependencies don't need to be marked __always_inline, e.g. so that KASAN
doesn't trigger a noinstr violation.

Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Fixes: 8cb861e9e3 ("x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data")
Tested-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Link: https://lore.kernel.org/r/20250523011756.3243624-4-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
 2025-06-25 08:42:51 -07:00
Mark Brown
51c18d4d88
 		ASoC: Standardize ASoC menu 
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:

Current Kconfig menu at [ALSA for SoC audio support] has no rules.
So, some venders are using menu style, some venders are listed each drivers
on top page, etc. It is difficult to find target vender and/or drivers
because it is very random.

Let's standardize ASoC menu, like below

	--- ALSA for SoC audio support
	      Analog Devices  --->
	      AMD  --->
	      Apple  --->
	      Atmel  --->
	      Au1x  ----
	      Broadcom  --->
	      Cirrus Logic  --->
	      DesignWare  --->
	      Freescale  --->
	      Google  --->
	      Hisilicon  --->
	      ...

One concern is *vender folder* alphabetical order vs *vender name*
alphabetical order were different. For example "sunxi" menu is
"Allwinner".

Link: https://lore.kernel.org/r/8734c8bf3l.wl-kuninori.morimoto.gx@renesas.com
 2025-06-25 16:27:47 +01:00
Remo Senekowitsch
c942dba380 rust: device: Add child accessor and iterator 
Allow Rust drivers to access children of a fwnode either by name or by
iterating over all of them.

In C, there is the function `fwnode_get_next_child_node` for iteration
and the macro `fwnode_for_each_child_node` that helps with handling the
pointers. Instead of a macro, a native iterator is used in Rust such
that regular for-loops can be used.

Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: Remo Senekowitsch <remo@buenzli.dev>
Link: https://lore.kernel.org/r/20250616154511.1862909-2-remo@buenzli.dev
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
 2025-06-25 17:18:07 +02:00
Jayesh Choudhary
55e8ff8420 drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type 
By default, HPD was disabled on SN65DSI86 bridge. When the driver was
added (commit "a095f15c00e27"), the HPD_DISABLE bit was set in pre-enable
call which was moved to other function calls subsequently.
Later on, commit "c312b0df3b" added detect utility for DP mode. But with
HPD_DISABLE bit set, all the HPD events are disabled[0] and the debounced
state always return 1 (always connected state).

Set HPD_DISABLE bit conditionally based on display sink's connector type.
Since the HPD_STATE is reflected correctly only after waiting for debounce
time (~100-400ms) and adding this delay in detect() is not feasible
owing to the performace impact (glitches and frame drop), remove runtime
calls in detect() and add hpd_enable()/disable() bridge hooks with runtime
calls, to detect hpd properly without any delay.

[0]: <https://www.ti.com/lit/gpn/SN65DSI86> (Pg. 32)

Fixes: c312b0df3b ("drm/bridge: ti-sn65dsi86: Implement bridge connector operations for DP")
Cc: Max Krummenacher <max.krummenacher@toradex.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20250624044835.165708-1-j-choudhary@ti.com
 2025-06-25 07:49:01 -07:00
Avadhut Naik
a3f3040657 EDAC/amd64: Fix size calculation for Non-Power-of-Two DIMMs 
Each Chip-Select (CS) of a Unified Memory Controller (UMC) on AMD Zen-based
SOCs has an Address Mask and a Secondary Address Mask register associated with
it. The amd64_edac module logs DIMM sizes on a per-UMC per-CS granularity
during init using these two registers.

Currently, the module primarily considers only the Address Mask register for
computing DIMM sizes. The Secondary Address Mask register is only considered
for odd CS. Additionally, if it has been considered, the Address Mask register
is ignored altogether for that CS. For power-of-two DIMMs i.e. DIMMs whose
total capacity is a power of two (32GB, 64GB, etc), this is not an issue
since only the Address Mask register is used.

For non-power-of-two DIMMs i.e., DIMMs whose total capacity is not a power of
two (48GB, 96GB, etc), however, the Secondary Address Mask register is used
in conjunction with the Address Mask register. However, since the module only
considers either of the two registers for a CS, the size computed by the
module is incorrect. The Secondary Address Mask register is not considered for
even CS, and the Address Mask register is not considered for odd CS.

Introduce a new helper function so that both Address Mask and Secondary
Address Mask registers are considered, when valid, for computing DIMM sizes.
Furthermore, also rename some variables for greater clarity.

Fixes: 81f5090db8 ("EDAC/amd64: Support asymmetric dual-rank DIMMs")
Closes: https://lore.kernel.org/dbec22b6-00f2-498b-b70d-ab6f8a5ec87e@natrix.lt
Reported-by: Žilvinas Žaltiena <zilvinas@natrix.lt>
Signed-off-by: Avadhut Naik <avadhut.naik@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
Tested-by: Žilvinas Žaltiena <zilvinas@natrix.lt>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/20250529205013.403450-1-avadhut.naik@amd.com
 2025-06-25 16:40:03 +02:00
Mark Brown
b28ecd8606
 		Add SoundWire machines for ACP7.0/ACP7.1 sof stack 
Merge series from Vijendar Mukunda <Vijendar.Mukunda@amd.com>:

Add SoundWire machines as alternate machines for ACP7.0 & ACP7.1
platforms with the below machine configuration.
Link 0: RT722 codec with three endpoints: Headset, Speaker, and DMIC.
 2025-06-25 15:36:29 +01:00
Mark Brown
9d330278c9
 		ASoC: codecs: wcd93xx: Drop enums for chipid values 
Merge series from Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>:

Minor cleanup while preparing for adding WCD9378 support: do not use
enum for values which are not an enumeration.
 2025-06-25 15:36:25 +01:00
Nikunj A Dadhania
51a4273dca KVM: SVM: Add missing member in SNP_LAUNCH_START command structure 
The sev_data_snp_launch_start structure should include a 4-byte
desired_tsc_khz field before the gosvw field, which was missed in the
initial implementation. As a result, the structure is 4 bytes shorter than
expected by the firmware, causing the gosvw field to start 4 bytes early.
Fix this by adding the missing 4-byte member for the desired TSC frequency.

Fixes: 3a45dc2b41 ("crypto: ccp: Define the SEV-SNP commands")
Cc: stable@vger.kernel.org
Suggested-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Tested-by: Vaishali Thakkar <vaishali.thakkar@suse.com>
Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
Link: https://lore.kernel.org/r/20250408093213.57962-3-nikunj@amd.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
 2025-06-25 07:27:27 -07:00
Daniele Ceraolo Spurio
dfe6c28132
 		Revert "drm/xe/ptl: Apply Wa_16026007364" 
This reverts commit 3972872e45.

There are several things wrong with the way this WA was implemented:

- The KLV is only supported on GuC 70.47.0 or newer, so we shouldn't
  apply it unconditionally.

- The KLV requires 2 DWs of data, which are not currently provided.

The GuC currently ignores any unknown KLVs, so on versions older that
70.47.0 nothing happens. However, starting on 70.47.0 the GuC attempts
to parse the KLV and fails due to the missing data, causing a GuC load
abort.

Given that 70.47.0 is the first GuC version approved for public release
for PTL, let's revert this patch so it doesn't cause the GuC load to
fail with that blob. We can then re-apply it properly fixed after the
GuC definition is merged, which will also have the added benefit of
running the KLV addition through CI with the right GuC version.

Fixes: 3972872e45 ("drm/xe/ptl: Apply Wa_16026007364")
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: sanirban <sk.anirban@intel.com>
Cc: Badal Nilawar <badal.nilawar@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250625001202.1616606-2-daniele.ceraolospurio@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
 2025-06-25 10:18:04 -04:00
Peter Griffin
2642f55d44 pinctrl: samsung: add support for gs101 wakeup mask programming 
gs101 differs to other currently supported SoCs in that it has 3 wakeup
mask registers for the 67 external wakeup interrupt pins in alive and
far_alive.

EINT_WAKEUP_MASK  0x3A80 EINT[31:0]
EINT_WAKEUP_MASK2 0x3A84 EINT[63:32]
EINT_WAKEUP_MASK3 0x3A88 EINT[66:64]

Add gs101 specific callbacks and a dedicated gs101_wkup_irq_chip struct to
handle these differences.

The current wakeup mask with upstream is programmed as
WAKEUP_MASK0[0x3A80] value[0xFFFFFFFF]
WAKEUP_MASK1[0x3A84] value[0xF2FFEFFF]
WAKEUP_MASK2[0x3A88] value[0xFFFFFFFF]

Which corresponds to the following wakeup sources:
gpa7-3  vol down
gpa8-1  vol up
gpa10-1 power
gpa8-2  typec-int

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Link: https://lore.kernel.org/r/20250619-gs101-eint-mask-v1-2-89438cfd7499@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
 2025-06-25 16:17:05 +02:00
Peter Griffin
c8edb80494 pinctrl: samsung: rename exynosautov920_retention_data to no_retention_data 
To avoid having an exact copy of this struct for gs101 rename it and use it
for both SoCs for eint banks.

The purpose of this for exynosautov920 and gs101 is to obtain the PMU
syscon for writing the calculated WAKEUP_MASK register(s).

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Link: https://lore.kernel.org/r/20250619-gs101-eint-mask-v1-1-89438cfd7499@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
 2025-06-25 16:17:05 +02:00
Shuicheng Lin
771f002ef1
 		drm/xe/uapi: Correct sync type definition in comments 
Commit 37d078e51b ("drm/xe/uapi: Split xe_sync types from flags") renamed some DRM_XE_SYNC_*
defines but later commits kept using the old names. Correct them with the new definition.

v2: correct fixes tag and update commit message to explain why (Lucas)

Fixes: 9329f06672 ("drm/xe/uapi: Use LR abbrev for long-running vms")
Fixes: 4b437893a8 ("drm/xe/uapi: More uAPI documentation additions and cosmetic updates")
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Francois Dugast <francois.dugast@intel.com>
Cc: Zongyao Bai <zongyao.bai@intel.com>
Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://lore.kernel.org/r/20250608230133.1250849-1-shuicheng.lin@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
 2025-06-25 10:15:54 -04:00