Commit graph

1,399,042 commits

Author SHA1 Message Date
Leon Romanovsky
824927e884 ARC: build: Try to guess GCC variant of cross compiler
ARC GCC compiler is packaged starting from Fedora 39i and the GCC
variant of cross compile tools has arc-linux-gnu- prefix and not
arc-linux-. This is causing that CROSS_COMPILE variable is left unset.

This change allows builds without need to supply CROSS_COMPILE argument
if distro package is used.

Before this change:
$ make -j 128 ARCH=arc W=1 drivers/infiniband/hw/mlx4/
  gcc: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead
  gcc: error: unrecognized command-line option ‘-mmedium-calls’
  gcc: error: unrecognized command-line option ‘-mlock’
  gcc: error: unrecognized command-line option ‘-munaligned-access’

[1] https://packages.fedoraproject.org/pkgs/cross-gcc/gcc-arc-linux-gnu/index.html
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Vineet Gupta <vgupta@kernel.org>
2024-12-13 14:39:24 -08:00
Andrii Nakryiko
6a10d2d361 Merge branch 'bpftool-btf-support-dumping-a-single-type-from-file'
Daniel Xu says:

====================
bpftool: btf: Support dumping a single type from file

Some projects, for example xdp-tools [0], prefer to check in a minimized
vmlinux.h rather than the complete file which can get rather large.

However, when you try to add a minimized version of a complex struct (eg
struct xfrm_state), things can get quite complex if you're trying to
manually untangle and deduplicate the dependencies.

This commit teaches bpftool to do a minimized dump of a single type by
providing an optional root_id argument.

Example usage:

    $ ./bpftool btf dump file ~/dev/linux/vmlinux | rg "STRUCT 'xfrm_state'"
    [12643] STRUCT 'xfrm_state' size=912 vlen=58

    $ ./bpftool btf dump file ~/dev/linux/vmlinux root_id 12643 format c
    #ifndef __VMLINUX_H__
    #define __VMLINUX_H__

    [..]

    struct xfrm_type_offload;

    struct xfrm_sec_ctx;

    struct xfrm_state {
            possible_net_t xs_net;
            union {
                    struct hlist_node gclist;
                    struct hlist_node bydst;
            };
            union {
                    struct hlist_node dev_gclist;
                    struct hlist_node bysrc;
            };
            struct hlist_node byspi;
    [..]

[0]: https://github.com/xdp-project/xdp-tools/blob/master/headers/bpf/vmlinux.h

=== Changelog ===

Changes in v5:
* Update bash-completion to support repeating root_id
* Update man page to mention root_id NAND map key/value/kv/all

Changes in v4:
* Support multiple instances of root_id

Changes in v3:
* Make `root_id` a top level btf-dump argument rather than attached to `file`
* Update bash completion script
* Refactor root_type_ids checking to after btf handle creation
* Update help messages and fix existing man page inconsistency

Changes in v2:
* Add early error check for invalid BTF ID
====================

Link: https://patch.msgid.link/cover.1734119028.git.dxu@dxuuu.xyz
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
2024-12-13 14:35:43 -08:00
Daniel Xu
9d294f6986 bpftool: bash: Add bash completion for root_id argument
This commit updates the bash completion script with the new root_id
argument.

Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/37016c786620761e621a88240e36f6cb27a8f628.1734119028.git.dxu@dxuuu.xyz
2024-12-13 14:35:42 -08:00
Daniel Xu
a812d92ed2 bpftool: btf: Support dumping a specific types from file
Some projects, for example xdp-tools [0], prefer to check in a minimized
vmlinux.h rather than the complete file which can get rather large.

However, when you try to add a minimized version of a complex struct (eg
struct xfrm_state), things can get quite complex if you're trying to
manually untangle and deduplicate the dependencies.

This commit teaches bpftool to do a minimized dump of a specific types by
providing a optional root_id argument(s).

Example usage:

    $ ./bpftool btf dump file ~/dev/linux/vmlinux | rg "STRUCT 'xfrm_state'"
    [12643] STRUCT 'xfrm_state' size=912 vlen=58

    $ ./bpftool btf dump file ~/dev/linux/vmlinux root_id 12643 format c
    #ifndef __VMLINUX_H__
    #define __VMLINUX_H__

    [..]

    struct xfrm_type_offload;

    struct xfrm_sec_ctx;

    struct xfrm_state {
            possible_net_t xs_net;
            union {
                    struct hlist_node gclist;
                    struct hlist_node bydst;
            };
            union {
                    struct hlist_node dev_gclist;
                    struct hlist_node bysrc;
            };
            struct hlist_node byspi;
    [..]

[0]: https://github.com/xdp-project/xdp-tools/blob/master/headers/bpf/vmlinux.h

Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/04feb860c0a56a7da66f923551484e1483a72074.1734119028.git.dxu@dxuuu.xyz
2024-12-13 14:35:42 -08:00
Daniel Xu
7f5819e1ac bpftool: btf: Validate root_type_ids early
Handle invalid root_type_ids early, as an invalid ID will cause dumpers
to half-emit valid boilerplate and then bail with an unclean exit. This
is ugly and possibly confusing for users, so preemptively handle the
common error case before any dumping begins.

Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Reviewed-by: Quentin Monnet <qmo@kernel.org>
Link: https://lore.kernel.org/bpf/33e09a08a6072f8381cb976218a009709309b7e1.1734119028.git.dxu@dxuuu.xyz
2024-12-13 14:35:42 -08:00
Daniel Xu
5e3ad22d82 bpftool: man: Add missing format argument to command description
The command description was missing the optional argument. Add it there
for consistency with the rest of the commands.

Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Reviewed-by: Quentin Monnet <qmo@kernel.org>
Link: https://lore.kernel.org/bpf/140402f22fc377fba4c34376b7e1d2eba2c276b1.1734119028.git.dxu@dxuuu.xyz
2024-12-13 14:35:42 -08:00
Linus Torvalds
4800575d8c Bug fixes for 6.13-rc3
* Fixes for scrub subsystem
 * Fix quota crashes
 * Fix sb_spino_align checons on large fsblock sizes
 * Fix discarded superblock updates
 * fix stuck unmount due to a locked inode
 
 Signed-off-by: Carlos Maiolino <cem@kernel.org>
 -----BEGIN PGP SIGNATURE-----
 
 iJUEABMJAB0WIQQMHYkcUKcy4GgPe2RGdaER5QtfpgUCZ1yHBQAKCRBGdaER5Qtf
 pvogAX98nf8qE2Y2I6DvXVeX+LOPWNG+WTiRpF3d8NxjhCfGn79am71YrtkHf6qC
 V0halh8Bfi+SWsVqYYuJK+7/SUjGS2MzNqG0NY32wNYqAIroQA/Xh9IaQXX0q8t2
 FLGWIaxWOA==
 =0g8J
 -----END PGP SIGNATURE-----

Merge tag 'xfs-fixes-6.13-rc3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux

Pull xfs fixes from Carlos Maiolino:

 - Fixes for scrub subsystem

 - Fix quota crashes

 - Fix sb_spino_align checons on large fsblock sizes

 - Fix discarded superblock updates

 - Fix stuck unmount due to a locked inode

* tag 'xfs-fixes-6.13-rc3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: (28 commits)
  xfs: port xfs_ioc_start_commit to multigrain timestamps
  xfs: return from xfs_symlink_verify early on V4 filesystems
  xfs: fix zero byte checking in the superblock scrubber
  xfs: check pre-metadir fields correctly
  xfs: don't crash on corrupt /quotas dirent
  xfs: don't move nondir/nonreg temporary repair files to the metadir namespace
  xfs: fix sb_spino_align checks for large fsblock sizes
  xfs: convert quotacheck to attach dquot buffers
  xfs: attach dquot buffer to dquot log item buffer
  xfs: clean up log item accesses in xfs_qm_dqflush{,_done}
  xfs: separate dquot buffer reads from xfs_dqflush
  xfs: don't lose solo dquot update transactions
  xfs: don't lose solo superblock counter update transactions
  xfs: avoid nested calls to __xfs_trans_commit
  xfs: only run precommits once per transaction object
  xfs: unlock inodes when erroring out of xfs_trans_alloc_dir
  xfs: fix scrub tracepoints when inode-rooted btrees are involved
  xfs: update btree keys correctly when _insrec splits an inode root block
  xfs: fix error bailout in xfs_rtginode_create
  xfs: fix null bno_hint handling in xfs_rtallocate_rtg
  ...
2024-12-13 14:27:40 -08:00
Ville Syrjälä
46e417b150 drm/modes: Fix drm_mode_vrefres() docs
We no longer store a cache vrefresh value in the mode.
Remove the stale information from drm_vrefresh() docs.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241129042629.18280-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-12-14 00:23:45 +02:00
Linus Torvalds
01af50af76 arm64 fixes for 6.13-rc3:
- arm64 stacktrace: address some fallout from the recent changes to
   unwinding across exception boundaries
 
 - Ensure the arm64 signal delivery failure is recoverable - only
   override the return registers after all the user accesses took place
 
 - Fix the arm64 kselftest access to SVCR - only when SME is detected
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEE5RElWfyWxS+3PLO2a9axLQDIXvEFAmdccV0ACgkQa9axLQDI
 XvHC6Q//X7A2aziMs+FTYrDc0sqK09Ur53SNyQZuA6v1dXqxLH+SbzM75n6TMv9O
 a5lv/1Jxw0aQPOhTsRgg7wV+svMWyOx52ouUSjFVRPocBFgnxiyyxcxgC9TmPMTh
 MbZPa36R7qSpfUSPK6+uOTI/eQ6cD66az4fq7Y936cyY8J1/xg5pQXSE2WWGx4nz
 Ryci4iksNB8IXH37twDmPvE6446Q82eLcJR9zfh+lhf+Rgx5/rNEPdqtNJPR1a7N
 ftVDHTvcMTLmoMsjvOkhtfjbwsGBbz4Ezji0GW3+zPcZK5EYRjUZvOnG3HD2/mds
 iYfh0xux0GBEsjozkIshu7wg1JqMwJJ8zBXu62/TcKHG8LG3C/k6kCr+SN7IL8p8
 qzxxkkD61AxAY0aHuJ56Ao9nCLbHkAFGOJXUiyDJQALzt2KKN4aoOt+0zj35yYFz
 PONt4FPy3ulX6fk0XrAcI5E64hjeW/ib5wluOxb79Wn07ZYZQ/Ff42kJEMVL6VA7
 bFbbYKtbjFhQQPac/TLbqtwgMX0lA6bSZ5bPhoPZys3iReVbDiGvszRsWh4WQYgX
 X0sujmaSMkjU1IICfZs3yABLQ0aDJKeuaKHnri9WT3iuBOjiLlChVnXqd4VRgXfy
 DUE6bKQ3ohHVTrIxpNcBzWUYsSAeZMPyakuCY6pxuVwzBPrOR28=
 =s7gn
 -----END PGP SIGNATURE-----

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

Pull arm64 fixes from Catalin Marinas:

 - arm64 stacktrace: address some fallout from the recent changes to
   unwinding across exception boundaries

 - Ensure the arm64 signal delivery failure is recoverable - only
   override the return registers after all the user accesses took place

 - Fix the arm64 kselftest access to SVCR - only when SME is detected

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  kselftest/arm64: abi: fix SVCR detection
  arm64: signal: Ensure signal delivery failure is recoverable
  arm64: stacktrace: Don't WARN when unwinding other tasks
  arm64: stacktrace: Skip reporting LR at exception boundaries
2024-12-13 14:23:09 -08:00
Linus Torvalds
a5b3d5dfce RISC-V Fixes for 6.13-rc3
* A fix to avoid taking a mutex while resolving jump_labels in the mutex
   implementation.
 * A fix to avoid trying to resolve the early boot DT pointer via the
   linear map.
 * A fix to avoid trying to IPI kfence TLB flushes, as kfence might flush
   with IRQs disabled.
 * A fix to avoid calling PMD destructors on PMDs that were never
   constructed.
 -----BEGIN PGP SIGNATURE-----
 
 iQJHBAABCAAxFiEEKzw3R0RoQ7JKlDp6LhMZ81+7GIkFAmdcYiETHHBhbG1lckBk
 YWJiZWx0LmNvbQAKCRAuExnzX7sYif8DD/4x/V+ZDInlTpQcPpKC7LtDaNBUyZ2r
 4nENb4CcHkLTJjHHKUS9WFkH+woH0hx43yDkm5AKO3RttYj41fbybhBiomeEQdbE
 iA6d7zQD3EFTXP+Pg/fBfzEWgMUCl9GJjtJn8ZpwqsibMOcNrfog9i/6ErPnPOKi
 Q5+nx/Qyg2pxKI/9kTFsJ8W39iRaFZTVltrfZHc26i96ohx1b8J93KXT2dRFvkV8
 doPcJkuEAP1l52B4y+Vo3T+01LS4bVWwv2Ye5r268lLB4DkYIwk/Hh6HG0DTeAID
 o0TWbCREuR4gvur8ge3C6P4v7lCT+gv2tSxW9vxd1y6vMhIgRnDHYMoloDDWw352
 6hTDg6akqTC4jfMFwyOFo98qze/bghCG+ELgMxhbgQamrWO7qzVZCjkgKB2Wal3b
 rcY5eYMPFIR0YIBHa/kQ4J6mFVGhK4sBxpB9w3Z7BSYnMU+uCXChMmxo4kSXJelt
 N2Ny9rYlNxxhUg6OSDXAWQAoIUHo6O89gWZyXnFlBUfaI6cnVFDwd+2F6QoRhmhu
 XNTHl699qcV5Unb08qd2wnCXFv0X0WVVGTPO5rFH2/HlkPoPwZIGEv/kU+U42n5p
 OiIteste0TH5w20knrWYHZKEnNkaONcxNqmloTK89qQL+526s65pcgPk6W1hFqow
 4WpJWIgwTRdd3A==
 =uaBB
 -----END PGP SIGNATURE-----

Merge tag 'riscv-for-linus-6.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux

Pull RISC-V fixes from Palmer Dabbelt:

 - avoid taking a mutex while resolving jump_labels in the mutex
   implementation

 - avoid trying to resolve the early boot DT pointer via the linear map

 - avoid trying to IPI kfence TLB flushes, as kfence might flush with
   IRQs disabled

 - avoid calling PMD destructors on PMDs that were never constructed

* tag 'riscv-for-linus-6.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  riscv: mm: Do not call pmd dtor on vmemmap page table teardown
  riscv: Fix IPIs usage in kfence_protect_page()
  riscv: Fix wrong usage of __pa() on a fixmap address
  riscv: Fixup boot failure when CONFIG_DEBUG_RT_MUTEXES=y
2024-12-13 14:18:18 -08:00
Ville Syrjälä
9398332f23 drm/modes: Avoid divide by zero harder in drm_mode_vrefresh()
drm_mode_vrefresh() is trying to avoid divide by zero
by checking whether htotal or vtotal are zero. But we may
still end up with a div-by-zero of vtotal*htotal*...

Cc: stable@vger.kernel.org
Reported-by: syzbot+622bba18029bcde672e1@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=622bba18029bcde672e1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241129042629.18280-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-12-14 00:05:32 +02:00
John Harrison
70fb86a85d
drm/xe: Revert some changes that break a mesa debug tool
There is a mesa debug tool for decoding devcoredump files. Recent
changes to improve the devcoredump output broke that tool. So revert
the changes until the tool can be extended to support the new fields.

Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Fixes: c28fd6c358 ("drm/xe/devcoredump: Improve section headings and add tile info")
Fixes: ec1455ce7e ("drm/xe/devcoredump: Add ASCII85 dump helper function")
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Julia Filipchuk <julia.filipchuk@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-xe@lists.freedesktop.org
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241213172833.1733376-1-John.C.Harrison@Intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-12-13 17:01:26 -05:00
Tom Lendacky
3e43c60eb3 x86/sev: Prepare for using the RMPREAD instruction to access the RMP
The RMPREAD instruction returns an architecture defined format of an RMP
entry. This is the preferred method for examining RMP entries.

In preparation for using the RMPREAD instruction, convert the existing code
that directly accesses the RMP to map the raw RMP information into the
architecture defined format.

RMPREAD output returns a status bit for the 2MB region status. If the input
page address is 2MB aligned and any other pages within the 2MB region are
assigned, then 2MB region status will be set to 1. Otherwise, the 2MB region
status will be set to 0.

For systems that do not support RMPREAD, calculating this value would require
looping over all of the RMP table entries within that range until one is found
with the assigned bit set. Since this bit is not defined in the current
format, and so not used today, do not incur the overhead associated with
calculating it.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Nikunj A Dadhania <nikunj@amd.com>
Reviewed-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Link: https://lore.kernel.org/r/da49d5af1eb7f9039f35f14a32ca091efb2dd818.1733172653.git.thomas.lendacky@amd.com
2024-12-13 22:46:14 +01:00
Christian Göttsche
4aa1761934 selinux: add support for xperms in conditional policies
Add support for extended permission rules in conditional policies.
Currently the kernel accepts such rules already, but evaluating a
security decision will hit a BUG() in
services_compute_xperms_decision().  Thus reject extended permission
rules in conditional policies for current policy versions.

Add a new policy version for this feature.

Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Tested-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
2024-12-13 16:35:38 -05:00
Arnaldo Carvalho de Melo
701b27403c tools build feature: Don't set feature-libslang-include-subdir=1 if test-all.c builds
As it is not really included in tools/build/feature/test-all.c, so any
questioning about this feature should really try to build
tools/build/feature/test-libslang-include-subdir.c and not set it as
detected when test-all.c builds.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/lkml/20241213195052.914914-2-acme@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2024-12-13 18:30:57 -03:00
Arnaldo Carvalho de Melo
dea654e34a perf tests switch-tracking: Set this test to run exclusively
This test was failing when run with the default 'perf test' mode, which
is to run multiple regression tests in parallel.

Since it checks system_wide mode, set it to run in exclusive mode.

Reviewed-by: Ian Rogers <irogers@google.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Ravi Bangoria <ravi.bangoria@amd.com>
Link: https://lore.kernel.org/lkml/Z1yPYqYYs_isO1PJ@x1
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2024-12-13 18:30:48 -03:00
Rafael J. Wysocki
e14d5ae28e Merge branch 'acpica'
Merge an ACPICA fix for 6.13-rc3:

 - Don't release a context_mutex that was never acquired in
   acpi_remove_address_space_handler() (Daniil Tatianin).

* acpica:
  ACPICA: events/evxfregn: don't release the ContextMutex that was never acquired
2024-12-13 21:32:06 +01:00
Ravi Bangoria
4cd67bac9d perf test: Introduce DEFINE_SUITE_EXCLUSIVE()
A variant of DEFINE_SUITE() but sets ->exclusive bit for the test so the
test will be executed sequentially.

Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ananth Narayan <ananth.narayan@amd.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sandipan Das <sandipan.das@amd.com>
Cc: Santosh Shukla <santosh.shukla@amd.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86@kernel.org
Link: https://lore.kernel.org/r/20241210093449.1662-10-ravi.bangoria@amd.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2024-12-13 16:55:09 -03:00
Nicolas Dufresne
d216d9cb4d media: hantro: Replace maintainers
As per a long time request from Ezequiel, who left the project around
2020, replace the top maintainers with Benjamin and myself, and also
keeping Philipp, who is still active in the subsystem.

Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2024-12-13 19:48:25 +00:00
Benjamin Gaignard
555936182d media: verisilicon: av1: Store chroma and mv offsets
Store the chroma and motion vector offsets for each frame so that they
can be used later when the resolution changes.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2024-12-13 19:48:25 +00:00
Benjamin Gaignard
e5453f2a94 media: verisilicon: Fix IMX8 native pixel-format step values
The Hantro decoder non post-processed pixel-format steps are different
from the post-processed ones. Fix the steps according to the hardware
limitations. Since reference frame pixel-format issues have been fixed,
it is possible to use V4L2_PIX_FMT_NV15_4L4 rather V4L2_PIX_FMT_P010_4L4
for 10bit streams.

Fluster VP9 score goes up to 207/305.
HEVC score is still 141/147.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2024-12-13 19:48:25 +00:00
Benjamin Gaignard
db300ab0e9 media: verisilicon: Store reference frames pixels format
The Hantro decoder always produces tiled pixel-formats, but when the
post-processor is used, the destination pixel-format is a non-tiled
pixel-format. This causes an incorrect computation of the reference
frame size and offsets. Get and save the correct tiled pixel-format for
8 and 10 bit streams to solve these computation issues.

Fluster VP9 score increase to 166/305 (vs 145/305).
HEVC score is still 141/147.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2024-12-13 19:48:25 +00:00
Kyle Meyer
584e09743d EDAC/{i10nm,skx,skx_common}: Support UV systems
The 3-bit source IDs in PCI configuration space registers, used to map
devices to sockets, are limited to 8 unique IDs, and each ID is local to
a UPI/QPI domain.

Source IDs cannot be used to map devices to sockets on UV systems
because they can exceed 8 sockets and have multiple UPI/QPI domains with
identical, repeating source IDs.

Use NUMA information to get package IDs instead of source IDs on UV
systems, and use package/source IDs to name IMC information structures.

Signed-off-by: Kyle Meyer <kyle.meyer@hpe.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Tested-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Link: https://lore.kernel.org/all/20241213012549.43099-1-kyle.meyer@hpe.com/
2024-12-13 11:10:31 -08:00
Paolo Bonzini
3522c41975 KVM/riscv fixes for 6.13, take #1
- Replace csr_write() with csr_set() for HVIEN PMU overflow bit
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEZdn75s5e6LHDQ+f/rUjsVaLHLAcFAmdcUn0ACgkQrUjsVaLH
 LAcoyg//RD70/kMg4ZvE9rjNSBE7c4TemvHaCPgSpI4qM/r1HeJSMUDj+AIHvhg2
 S3jwgi32oJYaSXHEknvwwtaPN61JHn/mMeTcDlNSBG0vXacoAnprmfDMKzUoYNHc
 Ui9bkXhmkUUjLsbaW+lTOIHgUUCaLm4hh5m6W3adslCA/AfYn8v0XKiCHYVRSAXR
 qOgWvo2QSyowaGf9tU9ttvaigkV9FBUyIWJyOJcxwvkcvOg/fhvYF1CkQTxJh+m1
 N7C7fh5CzvdugojlWtjMIm9kAGPnhLXnuNFLGZfAkgxltAlI+nzGALAS2tdq70/n
 DOBbf0J2zI1zPCCGYt0nPCIyqacduJHTxHLbS7gX+nIGdfoACVtS/ir/3gNIS4RW
 NnMgJi7OSvnAudlmOluJdp6K8Xavk/EVxgGY7ItUXpncH2g2lOe/2C7Ihsb6x/mF
 xbap8hTYOtUh9jUhmjcx47CzrmkufUKGwBJAk36PsLAwRkvVqS/gsQDVuHwqhpby
 66cAj0xDqq8gSg2dJhQQzOB8bUvWhozUAjoaJMpWX1UjNph9ZkqwZPsKB1YXyLsx
 N5OhcmGCMdVIaJ2R/wmflWZCJI4U4ycZXO9VMdOFW882JoNya6uiNohJv/fosUjF
 5JXFAgbM4tJ0M+UdDyAb3k85SQ/pTIKE/aoON8VtZBefku/DyNw=
 =/5Vc
 -----END PGP SIGNATURE-----

Merge tag 'kvm-riscv-fixes-6.13-1' of https://github.com/kvm-riscv/linux into HEAD

KVM/riscv fixes for 6.13, take #1

- Replace csr_write() with csr_set() for HVIEN PMU overflow bit
2024-12-13 13:59:20 -05:00
Sean Christopherson
1201f226c8 KVM: x86: Cache CPUID.0xD XSTATE offsets+sizes during module init
Snapshot the output of CPUID.0xD.[1..n] during kvm.ko initiliaization to
avoid the overead of CPUID during runtime.  The offset, size, and metadata
for CPUID.0xD.[1..n] sub-leaves does not depend on XCR0 or XSS values, i.e.
is constant for a given CPU, and thus can be cached during module load.

On Intel's Emerald Rapids, CPUID is *wildly* expensive, to the point where
recomputing XSAVE offsets and sizes results in a 4x increase in latency of
nested VM-Enter and VM-Exit (nested transitions can trigger
xstate_required_size() multiple times per transition), relative to using
cached values.  The issue is easily visible by running `perf top` while
triggering nested transitions: kvm_update_cpuid_runtime() shows up at a
whopping 50%.

As measured via RDTSC from L2 (using KVM-Unit-Test's CPUID VM-Exit test
and a slightly modified L1 KVM to handle CPUID in the fastpath), a nested
roundtrip to emulate CPUID on Skylake (SKX), Icelake (ICX), and Emerald
Rapids (EMR) takes:

  SKX 11650
  ICX 22350
  EMR 28850

Using cached values, the latency drops to:

  SKX 6850
  ICX 9000
  EMR 7900

The underlying issue is that CPUID itself is slow on ICX, and comically
slow on EMR.  The problem is exacerbated on CPUs which support XSAVES
and/or XSAVEC, as KVM invokes xstate_required_size() twice on each
runtime CPUID update, and because there are more supported XSAVE features
(CPUID for supported XSAVE feature sub-leafs is significantly slower).

 SKX:
  CPUID.0xD.2  = 348 cycles
  CPUID.0xD.3  = 400 cycles
  CPUID.0xD.4  = 276 cycles
  CPUID.0xD.5  = 236 cycles
  <other sub-leaves are similar>

 EMR:
  CPUID.0xD.2  = 1138 cycles
  CPUID.0xD.3  = 1362 cycles
  CPUID.0xD.4  = 1068 cycles
  CPUID.0xD.5  = 910 cycles
  CPUID.0xD.6  = 914 cycles
  CPUID.0xD.7  = 1350 cycles
  CPUID.0xD.8  = 734 cycles
  CPUID.0xD.9  = 766 cycles
  CPUID.0xD.10 = 732 cycles
  CPUID.0xD.11 = 718 cycles
  CPUID.0xD.12 = 734 cycles
  CPUID.0xD.13 = 1700 cycles
  CPUID.0xD.14 = 1126 cycles
  CPUID.0xD.15 = 898 cycles
  CPUID.0xD.16 = 716 cycles
  CPUID.0xD.17 = 748 cycles
  CPUID.0xD.18 = 776 cycles

Note, updating runtime CPUID information multiple times per nested
transition is itself a flaw, especially since CPUID is a mandotory
intercept on both Intel and AMD.  E.g. KVM doesn't need to ensure emulated
CPUID state is up-to-date while running L2.  That flaw will be fixed in a
future patch, as deferring runtime CPUID updates is more subtle than it
appears at first glance, the benefits aren't super critical to have once
the XSAVE issue is resolved, and caching CPUID output is desirable even if
KVM's updates are deferred.

Cc: Jim Mattson <jmattson@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20241211013302.1347853-2-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2024-12-13 13:58:10 -05:00
Kim Seer Paller
57e5a9a85b power: supply: ltc4162-l-charger: Add support for ltc4162-f/s and ltc4015
LTC4162-L 35V/3.2A Multi-Cell Lithium-Ion Step-Down Battery Charger
LTC4162-F 35V/3.2A Multi-Cell LiFePO4 Step-Down Battery Charger
LTC4162-S 35V/3.2A Lead-Acid Step-Down Battery Charger
LTC4015 35V/3.2A Multichemistry Buck Battery Charger Controller

The LTC4162-L/F/S variants and LTC4015 share a common set of registers.
The difference lies in the resolution value of the scaling factor for
battery voltage and battery current measurement, input voltage, and
input current for different battery chemistries. The difference also
includes the calculation of setting and getting the actual voltage
setting applied to the charge voltage, as well as getting the die
temperature. Adding chip info structure to encapsulates these
differences by defining function pointers and parameters specific to
each device. This structure includes:
  - function pointers for getting and setting various parameters such as
    battery voltage, charge voltage, and die temperature
  - resolution parameters for battery current and input voltage
  - telemetry mask to specify which bits in the register are used for
    telemetry features

Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
Link: https://lore.kernel.org/r/20241213023746.34168-3-kimseer.paller@analog.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-13 19:42:55 +01:00
Kim Seer Paller
649399c5da dt-bindings: power: supply: ltc4162-l-charger: Add ltc4162-f/s and ltc4015
Add LTC4162-F/S and LTC4015 to the supported devices of LTC4162-L.
They share a common set of registers. The only differences lie in the
resolution value of the scaling factor for battery voltage and battery
current measurement, input voltage, and input current for different
battery chemistries. The differences also include the calculation of
setting and getting the actual voltage applied to the charge voltage,
as well as getting the die temperature.

This add compatible entries for ltc4162-f/s and ltc4015 and include
datasheets for new devices.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com>
Link: https://lore.kernel.org/r/20241213023746.34168-2-kimseer.paller@analog.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-12-13 19:42:50 +01:00
Ilia Levi
f0d3a3cffd
drm/xe/irq: Manage MSI-X interrupts allocation
Expose functions to request and free MSI-X interrupts.

The request has two flavors:
- Static MSI-X allocation, for known MSI-X interrupts (e.g. GuC-to-host)
- Dynamic MSI-X allocation, which uses the next available MSI-X interrupt

Signed-off-by: Ilia Levi <ilia.levi@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241213072538.6823-4-ilia.levi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-12-13 13:38:13 -05:00
Ilia Levi
21d07f5fdc
drm/xe: Initial MSI-X support for HW engines
- Configure the HW engines to work with MSI-X
- Program the LRC to use memirq infra (similar to VF)
- CS_INT_VEC field added to the LRC

Bspec: 60342, 72547

Signed-off-by: Ilia Levi <ilia.levi@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241213072538.6823-3-ilia.levi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-12-13 13:38:13 -05:00
Ilia Levi
da889070be
drm/xe/irq: Separate MSI and MSI-X flows
A new flow is added for devices that support MSI-X:
- MSI-X vector 0 is used for GuC-to-host interrupt
- MSI-X vector 1 (aka default MSI-X) is used for HW engines

The default MSI-X will be passed to the HW engines in a subsequent
patch.

Signed-off-by: Ilia Levi <ilia.levi@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241213072538.6823-2-ilia.levi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-12-13 13:38:13 -05:00
Jian-Hong Pan
1db806ec06 PCI/ASPM: Save parent L1SS config in pci_save_aspm_l1ss_state()
After 17423360a2 ("PCI/ASPM: Save L1 PM Substates Capability for
suspend/resume"), pci_save_aspm_l1ss_state(dev) saves the L1SS state for
"dev", and pci_restore_aspm_l1ss_state(dev) restores the state for both
"dev" and its parent.

The problem is that unless pci_save_state() has been used in some other
path and has already saved the parent L1SS state, we will restore junk to
the parent, which means the L1 Substates likely won't work correctly.

Save the L1SS config for both the device and its parent in
pci_save_aspm_l1ss_state().  When restoring, we need both because L1SS must
be enabled at the parent (the Downstream Port) before being enabled at the
child (the Upstream Port).

Link: https://lore.kernel.org/r/20241115072200.37509-3-jhp@endlessos.org
Fixes: 17423360a2 ("PCI/ASPM: Save L1 PM Substates Capability for suspend/resume")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218394
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Jian-Hong Pan <jhp@endlessos.org>
[bhelgaas: parallel save/restore structure, simplify commit log, patch at
https://lore.kernel.org/r/20241212230340.GA3267194@bhelgaas]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Jian-Hong Pan <jhp@endlessos.org> # Asus B1400CEAE
2024-12-13 12:20:58 -06:00
Arnd Bergmann
e5a8f19c39 accel/amdxdna: use modern PM helpers
The old SET_SYSTEM_SLEEP_PM_OPS and SET_RUNTIME_PM_OPS macros cause a build
warning when CONFIG_PM is disabled:

drivers/accel/amdxdna/amdxdna_pci_drv.c:343:12: error: 'amdxdna_pmops_resume' defined but not used [-Werror=unused-function]
  343 | static int amdxdna_pmops_resume(struct device *dev)
      |            ^~~~~~~~~~~~~~~~~~~~
drivers/accel/amdxdna/amdxdna_pci_drv.c:328:12: error: 'amdxdna_pmops_suspend' defined but not used [-Werror=unused-function]
  328 | static int amdxdna_pmops_suspend(struct device *dev)
      |            ^~~~~~~~~~~~~~~~~~~~~

Change these to the modern replacements.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
Tested-by: Lizhi Hou <lizhi.hou@amd.com>
Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241213090259.68492-1-arnd@kernel.org
2024-12-13 11:09:42 -07:00
Linus Torvalds
243f750a2d gpio fixes for v6.13-rc3
- fix several low-level issues in gpio-graniterapids
 - fix an initialization order issue that manifests itself with
   __counted_by() checks in gpio-ljca
 - don't default to y for CONFIG_GPIO_MVEBU with COMPILE_TEST enabled
 - move the DEFAULT_SYMBOL_NAMESPACE define before the export.h include
   in gpio-idio-16
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAmdcOcIACgkQEacuoBRx
 13Ky3g/+JZawOniCmm5vBEH5SS4lhjEMts0i0WkaH5oIhESxsLgfZO8e0ucQt4td
 AmVk7ingHaoY1GYL1bmhkZEELHhqrSYb0uCMMtK1AxvXOeMUdGRj2QYpdKLGdWL3
 dCrWemJi8sx0UDWs4LLvR5HcoKAACB5Mu2NmOMTtuYiBB8qIfCWQ0+0Q09/yhJM8
 WNhGComnuKPvVgndHrGcd5H7CTUJobyacYu3dwvzPjPC+PvC6YTrkos5xonbyx1E
 GQQ3bxgU/ZvuGp6OKKeugaMxJcWOcrBm7emYiCyYwcasrh3GghUAcQ8UAP9CLYSx
 U1AzWI1lDqNdh7a+pr+HYR43aJ8RJ8lWFKA5wlUHSZv97G4aZyFRPBIC0AI4C9os
 OvW/sS4IvJ/snY7dyQ7972RLEMzmSSpEDWyYdrwOCDAtRt6KGpK7GH6yQrxQJCUN
 6g30wry+zzlybki0gyyQB53b8X5pth6VuDtpaPSwFPQo1JL+Z0abbIPjqJKrVZBt
 UoVLKAev5Jo6U5/aiPvddBMw31RPeAN2dQTuYxKI8fv9xtWMYrpa9y9Hzgt4s1HX
 F+Pl2cVUnM+cKWYQbk7m1s07jHMjsnaH0RCxPX54RnXaQ7hevXfBn0HeNkETN426
 uZmlQIPgIB7cP2zdBDnJ6Jzgzv5mu+azIuTb11PL6JmL+DOXzhw=
 =nunS
 -----END PGP SIGNATURE-----

Merge tag 'gpio-fixes-for-v6.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux

Pull gpio fixes from Bartosz Golaszewski:

 - fix several low-level issues in gpio-graniterapids

 - fix an initialization order issue that manifests itself with
   __counted_by() checks in gpio-ljca

 - don't default to y for CONFIG_GPIO_MVEBU with COMPILE_TEST enabled

 - move the DEFAULT_SYMBOL_NAMESPACE define before the export.h include
   in gpio-idio-16

* tag 'gpio-fixes-for-v6.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
  gpio: idio-16: Actually make use of the GPIO_IDIO_16 symbol namespace
  gpio: graniterapids: Fix GPIO Ack functionality
  gpio: graniterapids: Check if GPIO line can be used for IRQs
  gpio: graniterapids: Determine if GPIO pad can be used by driver
  gpio: graniterapids: Fix invalid RXEVCFG register bitmask
  gpio: graniterapids: Fix invalid GPI_IS register offset
  gpio: graniterapids: Fix incorrect BAR assignment
  gpio: graniterapids: Fix vGPIO driver crash
  gpio: ljca: Initialize num before accessing item in ljca_gpio_config
  gpio: GPIO_MVEBU should not default to y when compile-testing
2024-12-13 09:57:15 -08:00
Nilay Shroff
be26ba9642 block: Fix potential deadlock while freezing queue and acquiring sysfs_lock
For storing a value to a queue attribute, the queue_attr_store function
first freezes the queue (->q_usage_counter(io)) and then acquire
->sysfs_lock. This seems not correct as the usual ordering should be to
acquire ->sysfs_lock before freezing the queue. This incorrect ordering
causes the following lockdep splat which we are able to reproduce always
simply by accessing /sys/kernel/debug file using ls command:

[   57.597146] WARNING: possible circular locking dependency detected
[   57.597154] 6.12.0-10553-gb86545e02e8c #20 Tainted: G        W
[   57.597162] ------------------------------------------------------
[   57.597168] ls/4605 is trying to acquire lock:
[   57.597176] c00000003eb56710 (&mm->mmap_lock){++++}-{4:4}, at: __might_fault+0x58/0xc0
[   57.597200]
               but task is already holding lock:
[   57.597207] c0000018e27c6810 (&sb->s_type->i_mutex_key#3){++++}-{4:4}, at: iterate_dir+0x94/0x1d4
[   57.597226]
               which lock already depends on the new lock.

[   57.597233]
               the existing dependency chain (in reverse order) is:
[   57.597241]
               -> #5 (&sb->s_type->i_mutex_key#3){++++}-{4:4}:
[   57.597255]        down_write+0x6c/0x18c
[   57.597264]        start_creating+0xb4/0x24c
[   57.597274]        debugfs_create_dir+0x2c/0x1e8
[   57.597283]        blk_register_queue+0xec/0x294
[   57.597292]        add_disk_fwnode+0x2e4/0x548
[   57.597302]        brd_alloc+0x2c8/0x338
[   57.597309]        brd_init+0x100/0x178
[   57.597317]        do_one_initcall+0x88/0x3e4
[   57.597326]        kernel_init_freeable+0x3cc/0x6e0
[   57.597334]        kernel_init+0x34/0x1cc
[   57.597342]        ret_from_kernel_user_thread+0x14/0x1c
[   57.597350]
               -> #4 (&q->debugfs_mutex){+.+.}-{4:4}:
[   57.597362]        __mutex_lock+0xfc/0x12a0
[   57.597370]        blk_register_queue+0xd4/0x294
[   57.597379]        add_disk_fwnode+0x2e4/0x548
[   57.597388]        brd_alloc+0x2c8/0x338
[   57.597395]        brd_init+0x100/0x178
[   57.597402]        do_one_initcall+0x88/0x3e4
[   57.597410]        kernel_init_freeable+0x3cc/0x6e0
[   57.597418]        kernel_init+0x34/0x1cc
[   57.597426]        ret_from_kernel_user_thread+0x14/0x1c
[   57.597434]
               -> #3 (&q->sysfs_lock){+.+.}-{4:4}:
[   57.597446]        __mutex_lock+0xfc/0x12a0
[   57.597454]        queue_attr_store+0x9c/0x110
[   57.597462]        sysfs_kf_write+0x70/0xb0
[   57.597471]        kernfs_fop_write_iter+0x1b0/0x2ac
[   57.597480]        vfs_write+0x3dc/0x6e8
[   57.597488]        ksys_write+0x84/0x140
[   57.597495]        system_call_exception+0x130/0x360
[   57.597504]        system_call_common+0x160/0x2c4
[   57.597516]
               -> #2 (&q->q_usage_counter(io)#21){++++}-{0:0}:
[   57.597530]        __submit_bio+0x5ec/0x828
[   57.597538]        submit_bio_noacct_nocheck+0x1e4/0x4f0
[   57.597547]        iomap_readahead+0x2a0/0x448
[   57.597556]        xfs_vm_readahead+0x28/0x3c
[   57.597564]        read_pages+0x88/0x41c
[   57.597571]        page_cache_ra_unbounded+0x1ac/0x2d8
[   57.597580]        filemap_get_pages+0x188/0x984
[   57.597588]        filemap_read+0x13c/0x4bc
[   57.597596]        xfs_file_buffered_read+0x88/0x17c
[   57.597605]        xfs_file_read_iter+0xac/0x158
[   57.597614]        vfs_read+0x2d4/0x3b4
[   57.597622]        ksys_read+0x84/0x144
[   57.597629]        system_call_exception+0x130/0x360
[   57.597637]        system_call_common+0x160/0x2c4
[   57.597647]
               -> #1 (mapping.invalidate_lock#2){++++}-{4:4}:
[   57.597661]        down_read+0x6c/0x220
[   57.597669]        filemap_fault+0x870/0x100c
[   57.597677]        xfs_filemap_fault+0xc4/0x18c
[   57.597684]        __do_fault+0x64/0x164
[   57.597693]        __handle_mm_fault+0x1274/0x1dac
[   57.597702]        handle_mm_fault+0x248/0x484
[   57.597711]        ___do_page_fault+0x428/0xc0c
[   57.597719]        hash__do_page_fault+0x30/0x68
[   57.597727]        do_hash_fault+0x90/0x35c
[   57.597736]        data_access_common_virt+0x210/0x220
[   57.597745]        _copy_from_user+0xf8/0x19c
[   57.597754]        sel_write_load+0x178/0xd54
[   57.597762]        vfs_write+0x108/0x6e8
[   57.597769]        ksys_write+0x84/0x140
[   57.597777]        system_call_exception+0x130/0x360
[   57.597785]        system_call_common+0x160/0x2c4
[   57.597794]
               -> #0 (&mm->mmap_lock){++++}-{4:4}:
[   57.597806]        __lock_acquire+0x17cc/0x2330
[   57.597814]        lock_acquire+0x138/0x400
[   57.597822]        __might_fault+0x7c/0xc0
[   57.597830]        filldir64+0xe8/0x390
[   57.597839]        dcache_readdir+0x80/0x2d4
[   57.597846]        iterate_dir+0xd8/0x1d4
[   57.597855]        sys_getdents64+0x88/0x2d4
[   57.597864]        system_call_exception+0x130/0x360
[   57.597872]        system_call_common+0x160/0x2c4
[   57.597881]
               other info that might help us debug this:

[   57.597888] Chain exists of:
                 &mm->mmap_lock --> &q->debugfs_mutex --> &sb->s_type->i_mutex_key#3

[   57.597905]  Possible unsafe locking scenario:

[   57.597911]        CPU0                    CPU1
[   57.597917]        ----                    ----
[   57.597922]   rlock(&sb->s_type->i_mutex_key#3);
[   57.597932]                                lock(&q->debugfs_mutex);
[   57.597940]                                lock(&sb->s_type->i_mutex_key#3);
[   57.597950]   rlock(&mm->mmap_lock);
[   57.597958]
                *** DEADLOCK ***

[   57.597965] 2 locks held by ls/4605:
[   57.597971]  #0: c0000000137c12f8 (&f->f_pos_lock){+.+.}-{4:4}, at: fdget_pos+0xcc/0x154
[   57.597989]  #1: c0000018e27c6810 (&sb->s_type->i_mutex_key#3){++++}-{4:4}, at: iterate_dir+0x94/0x1d4

Prevent the above lockdep warning by acquiring ->sysfs_lock before
freezing the queue while storing a queue attribute in queue_attr_store
function. Later, we also found[1] another function __blk_mq_update_nr_
hw_queues where we first freeze queue and then acquire the ->sysfs_lock.
So we've also updated lock ordering in __blk_mq_update_nr_hw_queues
function and ensured that in all code paths we follow the correct lock
ordering i.e. acquire ->sysfs_lock before freezing the queue.

[1] https://lore.kernel.org/all/CAFj5m9Ke8+EHKQBs_Nk6hqd=LGXtk4mUxZUN5==ZcCjnZSBwHw@mail.gmail.com/

Reported-by: kjain@linux.ibm.com
Fixes: af28141498 ("block: freeze the queue in queue_attr_store")
Tested-by: kjain@linux.ibm.com
Cc: hch@lst.de
Cc: axboe@kernel.dk
Cc: ritesh.list@gmail.com
Cc: ming.lei@redhat.com
Cc: gjoyce@linux.ibm.com
Signed-off-by: Nilay Shroff <nilay@linux.ibm.com>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20241210144222.1066229-1-nilay@linux.ibm.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-12-13 10:51:58 -07:00
Linus Torvalds
de20dc2b96 sound fixes for 6.13-rc3
A collection of fixes; all look small, device-specific and boring.
 -----BEGIN PGP SIGNATURE-----
 
 iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmda9xkOHHRpd2FpQHN1
 c2UuZGUACgkQLtJE4w1nLE/kUA/+Jx7jW36zxRhPqRydtpmkRXGPOcsV1y6NZyD8
 i0vjlW6oNHZZeOtdU4ap2CL8x6YMYnCzQhtFbZD1Lob2O2G2aUYi9tWtYWeetws1
 OIB/Nj7xebJDtPl7yIrE5I9TRYGQKMT33LVopnFdihcVlQhSGmxIhJSm1C+n1Nsf
 gFGt2smUnaJ3dzaRXcUDaAcwoc4+DGJ4owpWJfnQae+klI+A6iiVSEoOcfoFL++q
 yp200Zb9Q49OUnDkqe2Nwjsqj3rSMulEtuF6S/NOiFqDR/Q6TDQfv+a1jaTPx58v
 OVtyeByMFV+usvq8qRPEgaAsQuWX+IukHoHEkLH3uUEt3DXAi5p2USl33bnabNv/
 le+du0O1vJmYkZD72jPBtkKwDElnRs8w1BlMcrenAdjHtwfB+Wy+cW6bzugiV53K
 ykQV3jGEThPerXomR9etYrumsvBNW7SsaZpy+8T7WjTAS1IPHaOkitlHAI16Ejv4
 F8o2SDm8pf2lBc9pGPZmOk3wJWLeLk1dn2q62wtRCD5RHFbC/Eh4JFn7hKq2rfyl
 am9c9fmfs+3BMHNuue8UJgsO4BV8+pUwRy5ZrG1sbUQ0ZOxqczSw+/+ehHozahBC
 i7DtlpJNBuOhRrZukAp3sGE0Mx6muoslZXo0CVqvFIJFgXR0BXx4Ymt8LLqOTBTl
 1w0FBoE=
 =u9jP
 -----END PGP SIGNATURE-----

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

Pull sound fixes from Takashi Iwai:
 "A collection of fixes; all look small, device-specific and boring"

* tag 'sound-6.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ASoC: Intel: sof_sdw: Add space for a terminator into DAIs array
  ASoC: fsl_spdif: change IFACE_PCM to IFACE_MIXER
  ASoC: fsl_xcvr: change IFACE_PCM to IFACE_MIXER
  ASoC: tas2781: Fix calibration issue in stress test
  ASoC: audio-graph-card: Call of_node_put() on correct node
  ASoC: amd: yc: Fix the wrong return value
  ALSA: control: Avoid WARN() for symlink errors
  sound: usb: format: don't warn that raw DSD is unsupported
  sound: usb: enable DSD output for ddHiFi TC44C
  ALSA: hda/realtek: Add new alc2xx-fixup-headset-mic model
  ALSA: hda/ca0132: Use standard HD-audio quirk matching helpers
  ALSA: usb-audio: Add implicit feedback quirk for Yamaha THR5
  ALSA: hda/realtek - Add support for ASUS Zen AIO 27 Z272SD_A272SD audio
  ALSA: hda/realtek: Fix headset mic on Acer Nitro 5
  ALSA: hda: cs35l56: Remove calls to cs35l56_force_sync_asp1_registers_from_cache()
2024-12-13 09:51:40 -08:00
Linus Torvalds
a3170b7d93 A single fix for a docs-build regression caused by the EXPORT_SYMBOL_NS()
mass change.
 -----BEGIN PGP SIGNATURE-----
 
 iQFDBAABCAAtFiEEIw+MvkEiF49krdp9F0NaE2wMflgFAmdcUaMPHGNvcmJldEBs
 d24ubmV0AAoJEBdDWhNsDH5YHocH+gJMedy9MoAzDORi1D22qRBYdYcjSkE1vFcu
 lNNoxDckzu1OnycWFfdkKG4dZct8G9JoSec3sxoofqRlHCvayrfeRanLveY7kLMv
 p5KK1HZSe9G7C8HXnJGoiRzmTiBzYFI8NWtCb/S1XplwzoTUeorbKSiV4EmyGdcS
 Dm4Hx0PK9HIij8klL9KN1QKWhpWFk5qs8Js8fJIIUZiV0T1B9VDMYAK8LjPdH7lG
 gKPTHT21OGF7AuIgLQBrqHwutBKSbnrfHqfoRFY/dyZQS8PXtqmMuNepCqsPAQQ0
 vNuAbdAihsaFSof69Sdx8s4uw7PoTDZIf/GoWrB+B9Q9MLh75G8=
 =HZYa
 -----END PGP SIGNATURE-----

Merge tag 'docs-6.13-fix' of git://git.lwn.net/linux

Pull documentation fix from Jonathan Corbet:
 "A single fix for a docs-build regression caused by the
  EXPORT_SYMBOL_NS() mass change"

* tag 'docs-6.13-fix' of git://git.lwn.net/linux:
  scripts/kernel-doc: Get -export option working again
2024-12-13 09:46:02 -08:00
Linus Torvalds
266facde83 slab fixes for 6.13-rc3
-----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCAAdFiEEe7vIQRWZI0iWSE3xu+CwddJFiJoFAmdb/84ACgkQu+CwddJF
 iJqEhQf+KHXQfZ/m7ma6bUEisjVOkUsxnpSj/DM1CP03+czqXoSEr+CHX2g1v0Os
 pZSOGGPTtvDgSBO0UZgo1P+sXyl0hrs2A/XrVQfKPmTfc9mPoxFTkbhI7Rv9hZfi
 9OVh9kg3OE2hixD9ussGmxtFTXE3vXeu9zASa2sEdpakc3gxgeNhIklGK9r3oQuF
 4aa33JpRV/oF80XAAUch5ltAO0tqQWtN50CbnoKc5cGRDuFRRdzXMMiL7gGiCctI
 te3sVMc6mnusdJqvp+AE10aT0iQpRWwL1lzGrgp3PuZ7DN8UQHxBIf8u8VIjyPML
 D2JZEYmqykKSvXbDzYBdOAF8XLEYCw==
 =PpHb
 -----END PGP SIGNATURE-----

Merge tag 'slab-for-6.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab

Pull slab fix from Vlastimil Babka:

 - Fix for memcg unreclaimable slab stats drift when post-charging large
   kmalloc allocations (Shakeel Butt)

* tag 'slab-for-6.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab:
  memcg: slub: fix SUnreclaim for post charged objects
2024-12-13 09:43:50 -08:00
Mark Brown
5ce3beed07
ASoC: fsl: add memory to memory function for ASRC
Merge series from Shengjiu Wang <shengjiu.wang@nxp.com>:

This function is base on the accelerator implementation
for compress API:
04177158cf ("ALSA: compress_offload: introduce accel operation mode")

Audio signal processing also has the requirement for memory to
memory similar as Video.

This asrc memory to memory (memory ->asrc->memory) case is a non
real time use case.

User fills the input buffer to the asrc module, after conversion, then asrc
sends back the output buffer to user. So it is not a traditional ALSA playback
and capture case.

Because we had implemented the "memory -> asrc ->i2s device-> codec"
use case in ALSA.  Now the "memory->asrc->memory" needs
to reuse the code in asrc driver, so the patch 1 and patch 2 is for refining
the code to make it can be shared by the "memory->asrc->memory"
driver.

Other change is to add memory to memory support for two kinds of i.MX ASRC
modules.
2024-12-13 17:33:09 +00:00
Mark Brown
94c545aa53
firmware: cirrus: Add KUnit tests for cs_dsp
Merge series from Richard Fitzgerald <rf@opensource.cirrus.com>:

This series adds KUnit tests for the cs_dsp module.

Most of the functionality in cs_dsp is for downloading firmware to
DSP memory and interacting with "control" words defined in that
memory. This doesn't require any emulation of running firmware,
because it is only reading and writing registers. So the testing can
be done using a dummy regmap. The way this is used to perform testing
is described in more detail in the commit message for each test.

ADSP1 is not tested because this was only used by the WM2200 codec,
a long-obsolete part that was discontinued in 2015.
2024-12-13 17:33:05 +00:00
Mark Brown
9b94f41449
ASoC: SOF: core/Intel: Handle pause supported token
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:

A new set of tokens have been added to SOF topology to indicate that the pause
operation is supported or not on the given PCM device.
Pause is an optional feature that depends on pipeline, topology and modules
used by the PCM.

Add a pause_supported flag to snd_sof_pcm_stream and use this flag in Intel
platform code to keep the pause support enabled or to disable it.
2024-12-13 17:33:00 +00:00
Uwe Kleine-König
b690f5d955 drm: Drop explicit initialization of struct i2c_device_id::driver_data to 0
These drivers don't use the driver_data member of struct i2c_device_id,
so don't explicitly initialize this member.

This prepares putting driver_data in an anonymous union which requires
either no initialization or named designators. But it's also a nice
cleanup on its own.

While add it, also remove commas after the sentinel entries.

Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Liu Ying <victor.liu@nxp.com> # ite-it6263.c
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20241204105827.1682632-2-u.kleine-koenig@baylibre.com
2024-12-13 09:27:46 -08:00
Marc Zyngier
773c05f417 irqchip/gic-v3: Work around insecure GIC integrations
It appears that the relatively popular RK3399 SoC has been put together
using a large amount of illicit substances, as experiments reveal that its
integration of GIC500 exposes the *secure* programming interface to
non-secure.

This has some pretty bad effects on the way priorities are handled, and
results in a dead machine if booting with pseudo-NMI enabled
(irqchip.gicv3_pseudo_nmi=1) if the kernel contains 18fdb6348c ("arm64:
irqchip/gic-v3: Select priorities at boot time"), which relies on the
priorities being programmed using the NS view.

Let's restore some sanity by going one step further and disable security
altogether in this case. This is not any worse, and puts us in a mode where
priorities actually make some sense.

Huge thanks to Mark Kettenis who initially identified this issue on
OpenBSD, and to Chen-Yu Tsai who reported the problem in Linux.

Fixes: 18fdb6348c ("arm64: irqchip/gic-v3: Select priorities at boot time")
Reported-by: Mark Kettenis <mark.kettenis@xs4all.nl>
Reported-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Chen-Yu Tsai <wens@csie.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/20241213141037.3995049-1-maz@kernel.org
2024-12-13 18:15:29 +01:00
Uros Bizjak
a1855f1b7c irqchip/gic: Correct declaration of *percpu_base pointer in union gic_base
percpu_base is used in various percpu functions that expect variable in
__percpu address space. Correct the declaration of percpu_base to

void __iomem * __percpu *percpu_base;

to declare the variable as __percpu pointer.

The patch fixes several sparse warnings:

irq-gic.c:1172:44: warning: incorrect type in assignment (different address spaces)
irq-gic.c:1172:44:    expected void [noderef] __percpu *[noderef] __iomem *percpu_base
irq-gic.c:1172:44:    got void [noderef] __iomem *[noderef] __percpu *
...
irq-gic.c:1231:43: warning: incorrect type in argument 1 (different address spaces)
irq-gic.c:1231:43:    expected void [noderef] __percpu *__pdata
irq-gic.c:1231:43:    got void [noderef] __percpu *[noderef] __iomem *percpu_base

There were no changes in the resulting object files.

Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/all/20241213145809.2918-2-ubizjak@gmail.com
2024-12-13 18:11:52 +01:00
Mike Lothian
d408916885 accel/amdxdna: Add include interrupt.h to amdxdna_mailbox.c
For amdxdna_mailbox.c, linux/interrupt.h is indirectly included by
trace/events/amdxdna.h. So if TRACING is disabled, driver compiling will
fail.

Fixes: b87f920b93 ("accel/amdxdna: Support hardware mailbox")
Reported-by: Mike Lothian <mike@fireburn.co.uk>
Closes: https://lore.kernel.org/dri-devel/CAHbf0-E+Z2O7rW-x+-EKNQ-nLbf=_ohaNzXxE7WD2cj9kFJERQ@mail.gmail.com/
Signed-off-by: Mike Lothian <mike@fireburn.co.uk>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241213163856.1472207-1-lizhi.hou@amd.com
2024-12-13 10:02:36 -07:00
Krzysztof Karas
080b2e7b5e drm/display: use ERR_PTR on DP tunnel manager creation fail
Instead of returning a generic NULL on error from
drm_dp_tunnel_mgr_create(), use error pointers with informative codes
to align the function with stub that is executed when
CONFIG_DRM_DISPLAY_DP_TUNNEL is unset. This will also trigger IS_ERR()
in current caller (intel_dp_tunnerl_mgr_init()) instead of bypassing it
via NULL pointer.

v2: use error codes inside drm_dp_tunnel_mgr_create() instead of handling
 on caller's side (Michal, Imre)

v3: fixup commit message and add "CC"/"Fixes" lines (Andi),
 mention aligning function code with stub

Fixes: 91888b5b1a ("drm/i915/dp: Add support for DP tunnel BW allocation")
Cc: Imre Deak <imre.deak@intel.com>
Cc: <stable@vger.kernel.org> # v6.9+
Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7q4fpnmmztmchczjewgm6igy55qt6jsm7tfd4fl4ucfq6yg2oy@q4lxtsu6445c
2024-12-13 18:57:34 +02:00
Arnd Bergmann
8b55f88189 media: mediatek: vcodec: mark vdec_vp9_slice_map_counts_eob_coef noinline
With KASAN enabled, clang fails to optimize the inline version of
vdec_vp9_slice_map_counts_eob_coef() properly, leading to kilobytes
of temporary values spilled to the stack:

drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c:1526:12: error: stack frame size (2160) exceeds limit (2048) in 'vdec_vp9_slice_update_prob' [-Werror,-Wframe-larger-than]

This seems to affect all versions of clang including the latest (clang-20),
but the degree of stack overhead is different per release.

Marking the function as noinline_for_stack is harmless here and avoids
the problem completely.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2024-12-13 17:51:35 +01:00
Liang Jie
e197f5ec3a sched_ext: Use sizeof_field for key_len in dsq_hash_params
Update the `dsq_hash_params` initialization to use `sizeof_field`
for the `key_len` field instead of a hardcoded value.

This improves code readability and ensures the key length dynamically
matches the size of the `id` field in the `scx_dispatch_q` structure.

Signed-off-by: Liang Jie <liangjie@lixiang.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
2024-12-13 06:51:19 -10:00
Lizhi Hou
c1e9a0ff94 accel/amdxdna: Add query firmware version
Enhance GET_INFO ioctl to support retrieving firmware version.

Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241206220001.164049-6-lizhi.hou@amd.com
2024-12-13 09:49:20 -07:00
Lizhi Hou
cfc722fc1c accel/amdxdna: Replace mmput with mmput_async to avoid dead lock
Hardware mailbox message receiving handler calls mmput to release the
process mm. If the process has already exited, the mmput here may call mmu
notifier handler, amdxdna_hmm_invalidate, which will cause a dead lock.
Using mmput_async instead prevents this dead lock.

Fixes: aac243092b ("accel/amdxdna: Add command execution")
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241206220001.164049-3-lizhi.hou@amd.com
2024-12-13 09:32:57 -07:00
Chun-Kuang Hu
7f78c081d4 soc: mediatek: cmdq: Remove cmdq_pkt_finalize() helper function
In order to have fine-grained control, use cmdq_pkt_eoc() and
cmdq_pkt_jump_rel() to replace cmdq_pkt_finalize().

Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Acked-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2024-12-13 17:30:58 +01:00