Commit graph

1,462,193 commits

Author SHA1 Message Date
Nina Schoetterl-Glausch
0e9704f1bc KVM: s390: vsie: Implement ASTFLEIE facility 2
Implement shadowing of format-2 facility list when running in VSIE.

ASTFLEIE2 is available since IBM z16.
To function G1 has to run this KVM code and G1 and G2 have to run QEMU
with ASTFLEIE2 support.

Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
Co-developed-by: Christoph Schlameuss <schlameuss@linux.ibm.com>
Signed-off-by: Christoph Schlameuss <schlameuss@linux.ibm.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
[imbrenda@linux.ibm.com: Fix typo in comment]
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260612-vsie-alter-stfle-fac-v4-4-74f0e1559929@linux.ibm.com>
2026-06-12 15:13:30 +02:00
Nina Schoetterl-Glausch
bf8f3cec93 KVM: s390: vsie: Refactor handle_stfle
Use switch case in anticipation of handling format-1 and format-2
facility list designations in the future.
As the alternate STFLE facilities are not enabled, only case 0 is
possible.
No functional change intended.

Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
Co-developed-by: Christoph Schlameuss <schlameuss@linux.ibm.com>
Signed-off-by: Christoph Schlameuss <schlameuss@linux.ibm.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260612-vsie-alter-stfle-fac-v4-3-74f0e1559929@linux.ibm.com>
2026-06-12 15:13:27 +02:00
Nina Schoetterl-Glausch
a8ceca7d8c s390/sclp: Detect ASTFLEIE 2 facility
Detect alternate STFLE interpretive execution facility 2.

Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
Signed-off-by: Christoph Schlameuss <schlameuss@linux.ibm.com>
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260612-vsie-alter-stfle-fac-v4-2-74f0e1559929@linux.ibm.com>
2026-06-12 15:13:22 +02:00
Nina Schoetterl-Glausch
20dcfaf2d3 KVM: s390: Minor refactor of base/ext facility lists
Directly use the size of the arrays instead of going through the
indirection of kvm_s390_fac_size().
Don't use magic number for the number of entries in the non hypervisor
managed facility bit mask list.
Make the constraint of that number on kvm_s390_fac_base obvious.
Get rid of implicit double anding of stfle_fac_list.

Signed-off-by: Nina Schoetterl-Glausch <nsg@linux.ibm.com>
Co-developed-by: Christoph Schlameuss <schlameuss@linux.ibm.com>
Signed-off-by: Christoph Schlameuss <schlameuss@linux.ibm.com>
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260612-vsie-alter-stfle-fac-v4-1-74f0e1559929@linux.ibm.com>
2026-06-12 15:13:17 +02:00
Alex Mastro
298ab7e6f1 iommufd: Clarify IOAS_MAP_FILE dma-buf support
IOMMU_IOAS_MAP_FILE is documented as mapping a memfd, but the
implementation first tries to resolve the fd as a dma-buf and has a
special path for supported dma-buf exporters. In particular, VFIO PCI
dma-bufs exported through VFIO_DEVICE_FEATURE_DMA_BUF can be mapped when
they describe a single DMA range.

Update the UAPI comment so userspace understands that certain kinds of
dma-buf are supported in addition to memfd.

Fixes: 44ebaa1744 ("iommufd: Accept a DMABUF through IOMMU_IOAS_MAP_FILE")
Link: https://patch.msgid.link/r/20260610-tmp-v1-1-b8ccbf557391@fb.com
Signed-off-by: Alex Mastro <amastro@fb.com>
Assisted-by: Codex:gpt-5.5-high
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2026-06-12 10:10:34 -03:00
Miquel Raynal
c0a5405ec3
spi: spi-mem: Fix spi_controller_mem_ops kdoc
The secondary_op_tmpl kdoc line has been removed accidentally, add it
back.

Reported-by: Michael Walle <mwalle@kernel.org>
Closes: https://lore.kernel.org/linux-mtd/DJ56CDMRVFQ6.FOZRIQTF3VDW@kernel.org/T/#u
Fixes: 38fbe4b3f6 ("spi: spi-mem: Add a no_cs_assertion capability")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20260612-perso-fix-no-cs-assertion-kdoc-v1-1-626b2d6d0d9b@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-12 14:10:22 +01:00
Armin Wolf
3429ae7b2f
modpost: Handle malformed WMI GUID strings
Some WMI GUIDs found inside binary MOF files contain both
uppercase and lowercase characters. Blindly copying such
GUIDs will prevent the associated WMI driver from loading
automatically because the WMI GUID found inside WMI device ids
always contains uppercase characters.

Avoid this issue by always converting WMI GUID strings to
uppercase. Also verify that the WMI GUID string actually looks
like a valid GUID.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260610203453.816254-10-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-12 16:01:55 +03:00
Armin Wolf
c3cbac4be0
platform/wmi: Make sysfs attributes const
The sysfs core supports const attributes. Use this to mark all
sysfs attributes as const so that they can be placed into read-only
memory for better security.

Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260610203453.816254-9-W_Armin@gmx.de
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-12 16:01:53 +03:00
Armin Wolf
b79ad5e8ba
platform/wmi: Make wmi_bus_class const
The functions class_register()/_unregister() and device_create()
both support taking a const pointer to the class struct. Use this
to mark wmi_bus_class as const so that it can be placed into
read-only memory for better security.

Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260610203453.816254-8-W_Armin@gmx.de
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-12 16:01:52 +03:00
Armin Wolf
ab1eb37dd6
hwmon: (dell-smm) Use new buffer-based WMI API
Use the new buffer-based WMI API to also support ACPI firmware
implementations that do not use ACPI buffers for returning the
results of a SMM call.

Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260610203453.816254-7-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-12 16:01:50 +03:00
Armin Wolf
7fced293bb
platform/x86: dell-ddv: Use new buffer-based WMI API
Use the new buffer-based WMI API to also support ACPI firmware
implementations that do not use ACPI intergers/strings/packages
for exchanging data.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260610203453.816254-6-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-12 16:01:48 +03:00
Armin Wolf
982b0e683a
platform/x86: dell-wmi-base: Use new buffer-based WMI API
Use the new buffer-based WMI API to also support ACPI firmware
implementations that do not use ACPI buffers for the event data.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260610203453.816254-5-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-12 16:01:47 +03:00
Armin Wolf
6f918e3d95
platform/x86: dell-smbios-wmi: Use new buffer-based WMI API
Use the new buffer-based WMI API to also support ACPI firmware
implementations that do not use ACPI buffers for returning the
results of a SMBIOS call.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260610203453.816254-4-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-12 16:01:46 +03:00
Armin Wolf
1719340487
platform/x86: dell-privacy: Use new buffer-based WMI API
Use the new buffer-based WMI API to also support ACPI firmware
implementations that do not use ACPI buffers for the device state.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260610203453.816254-3-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-12 16:01:44 +03:00
Armin Wolf
0f2d6a3082
platform/x86: dell-descriptor: Use new buffer-based WMI API
Use the new buffer-based WMI API to also support ACPI firmware
implementations that do not use ACPI buffers for the descriptor.

Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260610203453.816254-2-W_Armin@gmx.de
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-12 16:01:42 +03:00
Mark Brown
b63c2c3199 Aside from preparation changes in the SPI NAND core, the changes carried
here focus on the shared spi-mem layer which is enhanced in order to
 bring two new features:
 
 - The possibility to fill a primary and a secondary operation template
   in the direct mapping structure in order to support continuous reads
   in SPI NAND, which may require two different read operations.
 
 - SPI controllers may indicate possible CS instabilities over long
   transfers by setting a boolean. This capability is related to the
   previous one, the need for it has arised while testing SPI NAND
   continuous reads with the Cadence QSPI controller which cannot, under
   certain conditions, keep the CS asserted for the length of
   an eraseblock-large transfer.
 -----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCgAdFiEE9HuaYnbmDhq/XIDIJWrqGEe9VoQFAmn4m50ACgkQJWrqGEe9
 VoSUzwf8D7an5inOVMcX2IsbXSkA6vKgrzjc1jG3rGiLrFks/bZyo0R8atp4pUsy
 6WDkJfFyHg6IzU92N/37Kha8rnFp7um9OhfB/z2O/ztyqr9d1yM6QDtenknYr+WH
 BwcuJ8zenyWuIY526Ar04REJ07s8MZpMUhcnUIw/KpvQiS12UR6NHgEaUrmIjtLD
 GCKKFTGOY++9dgObo8ZrkrsLlVUhV5GyvCqUtBNNbADTNAt7j4m6YuyztS7rrmwb
 b33RoZiWmG0szkUsTJJBDH15cMB/4wV2SoGm3wzsACHqJhCy0n9FvSVAXwcRm5l7
 qOLedtMoBIIIIwBbHPsf0SySToy2ag==
 =3qpz
 -----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmosAyEACgkQJNaLcl1U
 h9BOcgf9EtmCuxpcX2n0PQlE6j88fr/zFDArtOXFZNFKdhL46u2kUWhdrvDH8i0J
 1FBbxRWsQqfrLesveqHqzVSg0ub6USe80Cbzjt2Vo1Ri+RF2i0b+5KNd1VrHC/iF
 DG+8A2c4VmjdiuCkaNI1gixMqdRJHSSWEjGD61+rv4M/VBIr1YtAV5kIJ+tFLPoY
 lYrvNMGcUGUTHUK2tJx4uaMuo7dd3C+hIWnnMu6OZ+TB/VbX77z4jrhqTONzxdYy
 uV+Zxh1PPLBvysPsqwSXpdW2FjfUi2SSGYrNn+kw0pdb58Th3/x7Tocb3t7awfWU
 Ah5Yw6zUF2vJMBFAOhHNJ9r3hvtoBw==
 =WwE4
 -----END PGP SIGNATURE-----

spi: spi-mem: Add a no_cs_assertion capability

Merge tag 'mtd/spi-mem-cont-read-for-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux into spi-7.2

Miquel Raynal <miquel.raynal@bootlin.com> says:

Aside from preparation changes in the SPI NAND core, the changes carried
here focus on the shared spi-mem layer which is enhanced in order to
bring two new features:

- The possibility to fill a primary and a secondary operation template
  in the direct mapping structure in order to support continuous reads
  in SPI NAND, which may require two different read operations.

- SPI controllers may indicate possible CS instabilities over long
  transfers by setting a boolean. This capability is related to the
  previous one, the need for it has arised while testing SPI NAND
  continuous reads with the Cadence QSPI controller which cannot, under
  certain conditions, keep the CS asserted for the length of
  an eraseblock-large transfer.
2026-06-12 14:00:51 +01:00
Denis Benato
72dd918bbe
platform/x86: asus-armoury: add support for FX608JPR
Add TDP data for laptop model FX608JPR.

Signed-off-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260612121008.970269-4-denis.benato@linux.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-12 15:57:57 +03:00
Denis Benato
a0bb64f317
platform/x86: asus-armoury: add support for GA403UM
Add TDP data for laptop model GA403UM.

Signed-off-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260612121008.970269-3-denis.benato@linux.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-12 15:57:55 +03:00
Denis Benato
0b38a42bf5
platform/x86: asus-armoury: add support for GA402NJ
Add TDP data for laptop model GA402NJ.

Signed-off-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260612121008.970269-2-denis.benato@linux.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-12 15:57:53 +03:00
Joerg Roedel
dd8a3c6cd5 Merge branches 'apple/dart', 'arm/smmu/updates', 'arm/smmu/bindings', 'rockchip', 'verisilicon', 'riscv', 'intel/vt-d', 'amd/amd-vi' and 'core' into next 2026-06-12 14:57:23 +02:00
Li RongQing
db50fb8701 iommu/dma-iommu: Fix wrong scatterlist length assignment in P2PDMA path
In iommu_dma_map_sg(), when handling PCI P2PDMA cases, the DMA length
of the current scatterlist segment `s` is incorrectly assigned from the
head entry `sg->length` instead of the current entry `s->length`.

This typo causes all P2PDMA segments in the scatterlist to inherit the
length of the first segment, leading to corrupted DMA lengths for multi-
segment scatterlists.

Fix this by using `s->length` instead of `sg->length`.

Fixes: a25e7962db ("PCI/P2PDMA: Refactor the p2pdma mapping helpers")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-06-12 14:56:49 +02:00
Mateusz Guzik
cf30ceccfa
fs: fix ups and tidy ups to /proc/filesystems caching
- add missing unlocks in some corner cases
- whitespace touch ups
- s/smp_store_release/rcu_assign_pointer/ [nop, the macro expands to the same thing]
- mark file_systems_string as __read_mostly

Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://patch.msgid.link/20260610143954.34185-1-mjguzik@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-06-12 14:26:27 +02:00
Muralidhara M K
d20457b46e
platform/x86/amd/hsmp: Clamp ioctl/send_message indices (Spectre v1)
Although validate_message() checks msg_id, a mispredicted branch can
still allow speculative indexing into hsmp_msg_desc_table[]. Clamp
msg.msg_id with array_index_nospec() at entry to hsmp_ioctl_msg() so
downstream dereferences (including via is_get_msg() and
hsmp_send_message()) see a bounded index.

Similarly, hsmp_send_message() bounds-checks msg->sock_ind before
indexing hsmp_pdev.sock[], but a mispredicted branch can still
speculatively use the raw index (Spectre v1, CVE-2017-5753). Apply
array_index_nospec() after the check so every caller that reaches
hsmp_pdev.sock[] through this helper sees a clamped socket
index—including hsmp_ioctl_msg() and any other path that hands a
user-derived struct hsmp_message to hsmp_send_message().

Reviewed-by: Muthusamy Ramalingam <muthusamy.ramalingam@amd.com>
Signed-off-by: Muralidhara M K <muralidhara.mk@amd.com>
Link: https://patch.msgid.link/20260612042610.1629037-7-muralidhara.mk@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-12 15:24:04 +03:00
Cameron Graham
0ec17ee704 ALSA: hda/hdmi: Add force-connect quirk for HP EliteDesk 800 G5 Mini
The HP EliteDesk 800 G5 Mini (PCI subsystem 103c:8595) uses
Cannon Lake PCH cAVS HDA with DisplayPort audio pins 0x05 and
0x06 set to AC_JACK_PORT_NONE (N/A) in BIOS defaults, causing
hdmi_add_pin() to skip them and the DP audio device to not
appear in ALSA.

Add the board to the existing force_connect_list alongside the
similar HP EliteDesk 800 G4 entries.

Signed-off-by: Cameron Graham <cam.graham@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20260612094601.1209845-1-cam.graham@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-06-12 14:20:38 +02:00
Andy Shevchenko
7cde561300 HID: nintendo: Use %pM format specifier for MAC addresses
Convert to %pM instead of using custom code.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Benjamin Tissoires <bentiss@kernel.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Link: https://patch.msgid.link/20260603104351.152085-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Petr Mladek <pmladek@suse.com>
2026-06-12 14:20:26 +02:00
Andy Shevchenko
76c9ed5b81 vsprintf: Add upper case flavour to %p[mM]
Some of the (ABI aware) code needs an upper case when printing MAC
addresses. Introduce an extension for that into the existing %p[mM].

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Link: https://patch.msgid.link/20260603104351.152085-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Petr Mladek <pmladek@suse.com>
2026-06-12 14:20:25 +02:00
Thomas Weißschuh
9bc0bd9617 sparc: Avoid -Wunused-but-set-parameter in clear_user_page()
The loop in clear_user_pages() iterates over all pages and calls
clear_user_page() for each of them. During the loop "vaddr" is modified.
However on sparc clear_user() is a macro which does not use "vaddr".
The compiler sees a variable which is modified but never used and emits
a warning for that:

	include/linux/highmem.h: In function 'clear_user_pages':
	include/linux/highmem.h:234:63: warning: parameter 'vaddr' set but not used [-Wunused-but-set-parameter=]
		static inline void clear_user_pages(void *addr, unsigned long vaddr,

Other architectures use an inline function for clear_user_page() which
avoids the warning. This is not possible on sparc, as
sparc_flush_page_to_ram() is not yet declared where clear_user_page() is
defined. Including cacheflush_32.h will trigger recursive and lots of
other issues.

So hide the warning with a cast to (void) instead.

While we are here, do the same for copy_user_page().

Fixes: 62a9f5a85b ("mm: introduce clear_pages() and clear_user_pages()")
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
2026-06-12 13:57:06 +02:00
Andrew Morton
1919c0e500 sparc: add _mcount() prototype
sparc64 defconfig told me

WARNING: modpost: EXPORT symbol "_mcount" [vmlinux] version generation failed, symbol will not be versioned.
Is "_mcount" prototyped in <asm/asm-prototypes.h>?

so I added it.

Cc: David S. Miller <davem@davemloft.net>
Cc: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Andreas Larsson <andreas@gaisler.com>
Tested-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
2026-06-12 13:55:59 +02:00
Jan Kara
5163e6ee1e udf: validate VAT inode size for old VAT format
Validate VAT inode is large enough to contain at least the header for
pre-2.00 UDF media format.

Signed-off-by: Jan Kara <jack@suse.cz>
2026-06-12 13:52:47 +02:00
Bryam Vargas
d8202786b3 udf: validate VAT header length against the VAT inode size
udf_load_vat() takes the virtual partition's start offset straight from
the on-disk VAT 2.0 header without checking it against the VAT inode
size:

	map->s_type_specific.s_virtual.s_start_offset =
		le16_to_cpu(vat20->lengthHeader);
	map->s_type_specific.s_virtual.s_num_entries =
		(sbi->s_vat_inode->i_size -
			map->s_type_specific.s_virtual.s_start_offset) >> 2;

lengthHeader is a fully attacker-controlled 16-bit value.  If it exceeds
the VAT inode size, the s_num_entries subtraction underflows to a huge
count, which defeats the "block > s_num_entries" bound in
udf_get_pblock_virt15(); and on the ICB-inline path that function reads

	((__le32 *)(iinfo->i_data + s_start_offset))[block]

so a large s_start_offset indexes past the inode's in-ICB data.  Mounting
a crafted UDF image with a virtual (VAT) partition then triggers an
out-of-bounds read.

Reject a VAT whose header length does not leave room for at least one
entry within the VAT inode.

Fixes: fa5e081563 ("udf: Handle VAT packed inside inode properly")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Link: https://patch.msgid.link/20260612-b4-disp-9a2317ee-v1-1-fefef5736154@proton.me
Signed-off-by: Jan Kara <jack@suse.cz>
2026-06-12 13:52:46 +02:00
Rosen Penev
5b0eee4cd8 sparc64: uprobes: add missing break
Missing fallthrough causes failure with newer compilers:

arch/sparc/kernel/uprobes.c:284:2: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
  284 |         default:
      |         ^
arch/sparc/kernel/uprobes.c:284:2: note: insert 'break;' to avoid fall-through
  284 |         default:
      |         ^
      |         break;

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Reviewed-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
2026-06-12 13:51:18 +02:00
Ethan Nelson-Moore
3774fd535f sparc: remove unused SERIAL_CONSOLE config option
There are no references to this option in SPARC or
architecture-independent code. Remove it to simplify the configuration
process.

Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Reviewed-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
2026-06-12 13:50:57 +02:00
Kexin Sun
2cdd477261 sparc32: remove deadwood swift_flush_tlb_page() debug code
Remove an #if 0 block that has been dead since at least
Linux 2.6.12.  The block was marked "P3: deadwood to debug
precise flushes on Swift" and contained a never-compiled
alternative implementation of swift_flush_tlb_page().  It also
referenced the since-removed srmmu_flush_tlb_page(), dropped
in commit 3d5f7d37c8 ("sparc32: drop unused functions in
pgtsrmmu.h").

Assisted-by: unnamed:deepseek-v3.2 coccinelle
Signed-off-by: Kexin Sun <kexinsun@smail.nju.edu.cn>
Reviewed-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
2026-06-12 13:50:29 +02:00
Thomas Weißschuh
84e8d9c34b sparc: uapi: Add ucontext.h
On SPARC the standard ucontext.h UAPI header is named 'uctx.h'.

Add an alias for the standard name.

Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
2026-06-12 13:50:01 +02:00
Thorsten Blum
a7532c505f sparc: vio: use sysfs_emit in sysfs show functions
Replace sprintf() and scnprintf() with sysfs_emit() in sysfs show
functions. sysfs_emit() is preferred to format sysfs output as it
provides better bounds checking.

Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Reviewed-by: Andreas Larsson <andreas@gaisler.com>
Tested-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
2026-06-12 13:48:40 +02:00
HanQuan
efc86691e4 ALSA: seq: Fix kernel heap address leak in bounce_error_event()
The comment above bounce_error_event() documents that user clients
should receive SNDRV_SEQ_EVENT_BOUNCE with the original event embedded
as variable-length data, while kernel clients should receive
SNDRV_SEQ_EVENT_KERNEL_ERROR with a quoted kernel pointer.

However, the implementation unconditionally uses
SNDRV_SEQ_EVENT_KERNEL_ERROR with data.quote.event set to the raw
struct snd_seq_event pointer for all clients.  When a bounce error
event is delivered to a USER_CLIENT via snd_seq_read(), the kernel
heap address in data.quote.event is exposed to userspace through
copy_to_user() in the fixed-length branch.

This is a distinct leak path from the one addressed by commit
705dd6dcbc ("ALSA: seq: Clear variable event pointer on read"),
which sanitizes data.ext.ptr in the variable-length branch of
snd_seq_read().  The bounce_error_event() leak uses fixed-length
events that take the else branch where no sanitization occurs.

Differentiate the bounce event by client type.  For USER_CLIENT,
send SNDRV_SEQ_EVENT_BOUNCE with SNDRV_SEQ_EVENT_LENGTH_VARIABLE
and data.ext pointing to the original event.  The variable-length
path in snd_seq_event_dup() copies the event data into chained
cells, and snd_seq_expand_var_event() copies only the content --
never the pointer -- to userspace.  For KERNEL_CLIENT, keep the
existing SNDRV_SEQ_EVENT_KERNEL_ERROR behavior with the quoted
pointer.

Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: HanQuan <eilaimemedsnaimel@gmail.com>
Link: https://patch.msgid.link/20260612103222.2528305-1-eilaimemedsnaimel@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-06-12 13:26:31 +02:00
Bryam Vargas
3ec997bd55 udf: validate sparing table length as an entry count, not a byte count
udf_load_sparable_map() accepts a sparing table when

	sizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize

is false, i.e. it treats reallocationTableLen as a number of BYTES that
must fit in the block.  But the table is walked as an array of 8-byte
sparingEntry elements:

	for (i = 0; i < le16_to_cpu(st->reallocationTableLen); i++) {
		struct sparingEntry *entry = &st->mapEntry[i];
		... entry->origLocation ...
	}

in udf_get_pblock_spar15() and udf_relocate_blocks().  A
reallocationTableLen of N therefore passes the check whenever
sizeof(*st) + N <= blocksize, yet the consumers index
sizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the
block.  On a crafted UDF image this is an out-of-bounds read in
udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the
same length to udf_update_tag(), whose crc_itu_t() reads far past the
block, and its memmove() through st->mapEntry[] is an out-of-bounds
write.

Validate reallocationTableLen as the entry count it is, with
struct_size().

Fixes: 1df2ae31c7 ("udf: Fortify loading of sparing table")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Link: https://patch.msgid.link/20260612-b4-disp-91780c4e-v1-1-f15112ff6882@proton.me
Signed-off-by: Jan Kara <jack@suse.cz>
2026-06-12 12:49:27 +02:00
Ryan Chen
9e84fd546d
arm64: dts: aspeed: Fix duplicate pinctrl labels and address scheme
A report from shashiko-bot highlighted some concerns concurrent to
application of the series[1].

Fix duplicate pinctrl_tach{0-15} and pinctrl_n{cts,dcd,dsr,ri}5 labels
in aspeed-g7-soc1-pinctrl.dtsi. These didn't cause errors from dtc
because dtc accepts duplicate labels for duplicate nodes specified
through a node reference[2].

Drop the cpu-index from secondary/tertiary container nodes: reduce
the "#address-cells" from 2 to 1 and update unit-addresses and reg
accordingly. The 2-cell scheme was proposed in an early mailing list
sketch to prompt discussion[3], but the design evolved in ways that made
it unnecessary.

Also remove URL comments from the DTS. The links were to comments in
the kernel sources with discussion justifying the approach, but are not
necessary to carry forward.

[arj: Extend discussion in the commit message]

Link: https://lore.kernel.org/all/20260609025708.ADBFE1F00893@smtp.kernel.org/ [1]
Link: https://lore.kernel.org/all/b226339bb2abe42ce23e90eadbc654b426131083.camel@codeconstruct.com.au/ [2]
Link: https://lore.kernel.org/all/1a2ca78746e00c2ec4bfc2953a897c48376ed36f.camel@codeconstruct.com.au/ [3]
Suggested-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Fixes: e77bb5dc57 ("arm64: dts: aspeed: Add initial AST27xx SoC device tree")
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
Link: https://patch.msgid.link/20260611-dtsi_fix-v1-1-ef2b7cd86d6d@aspeedtech.com
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Link: https://lore.kernel.org/r/20260612-aspeed-arm64-dt-v1-1-d1d1a4737905@codeconstruct.com.au
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-06-12 12:39:49 +02:00
Uwe Kleine-König (The Capable Hub)
426e83cab1 serial: 8250_pci: Don't specify conflicting values to pci_device_id members
The PCI_VDEVICE macro assigns 0 to .class and .class_mask to allow the
next value in the initializer to define the value for .driver_data.

So the construct

	{
		PCI_VDEVICE(INTASHIELD, 0x0D21),
		.class = PCI_CLASS_COMMUNICATION_MULTISERIAL << 8,
		.class_mask = 0xffff00,
		.driver_data = pbn_b2_4_115200,
	},

introduced in commit 44e55f1f30 ("serial: 8250_pci: Consistently
define pci_device_ids using named initializers") has conflicting
assignments. In only some configurations (i.e. W=1 for me) that makes
the compiler unhappy.

So convert the two affected items to PCI_DEVICE which doesn't have that
hidden assigment to .class and .class_mask.

Fixes: 44e55f1f30 ("serial: 8250_pci: Consistently define pci_device_ids using named initializers")
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Closes: https://lore.kernel.org/linux-serial/ah_5qVKOf8LXG1Xo@ashevche-desk.local/T/#ma6eab90ca801b4292639f5c255a89b4033b33d21
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260603095616.937968-2-u.kleine-koenig@baylibre.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-12 11:55:41 +02:00
Yi Yang
a287620312 vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write
A KASAN null-ptr-deref was observed in vcs_notifier():

BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130
Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {}

The issue is a race condition in vcs_write(). When the console_lock is
temporarily dropped (to copy data from userspace), the vc_data pointer
obtained from vcs_vc() may become stale. After re-acquiring the lock,
vcs_vc() is called again to re-validate the pointer. If the vc has been
deallocated in the meantime, vcs_vc() returns NULL, and the while loop
breaks (with written > 0). However, after the loop, vcs_scr_updated(vc)
is still called with the now-NULL vc pointer, leading to a null pointer
dereference in the notifier chain (vcs_notifier dereferences param->vc).

Fix this by adding a NULL check for vc before calling vcs_scr_updated().

Fixes: 8fb9ea65c9 ("vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAF")
Cc: stable@vger.kernel.org
Signed-off-by: Yi Yang <yiyang13@huawei.com>
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Link: https://patch.msgid.link/20260604060734.2914976-1-yiyang13@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-12 11:55:37 +02:00
Viken Dadhaniya
b93062b6d8 serial: qcom_geni: Fix RX DMA stall when SE_DMA_RX_LEN_IN is zero
In qcom_geni_serial_handle_rx_dma(), geni_se_rx_dma_unprep() clears
port->rx_dma_addr before SE_DMA_RX_LEN_IN is read. If the register is zero,
for example when the RX stale counter fires on an idle line, the handler
returns without calling geni_se_rx_dma_prep().

The next RX DMA interrupt then hits the !port->rx_dma_addr guard and
returns immediately, so the RX DMA buffer is never rearmed and later input
is lost.

Keep the handler on the rearm path when rx_in is zero. Warn about the
unexpected zero-length DMA completion, skip received-data handling, and
always call geni_se_rx_dma_prep().

Fixes: 2aaa43c707 ("tty: serial: qcom-geni-serial: add support for serial engine DMA")
Cc: stable@vger.kernel.org
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Link: https://patch.msgid.link/20260528-serial-rx-0-byte-fix-v2-1-b4195cfe342f@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-06-12 11:51:28 +02:00
Uwe Kleine-König (The Capable Hub)
21e7b9710a ata: Use named initializers for pci_device_id arrays
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.

The mentioned robustness is relevant for a planned change to struct
pci_device_id that replaces .driver_data by an anonymous union.

Also drop the comma after a few list terminators.

This patch doesn't modify the compiled array, only their representation
in source form benefits. The former was confirmed with x86 and arm64
builds.

Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2026-06-12 11:44:30 +02:00
Uwe Kleine-König (The Capable Hub)
3b5b35f28e ata: Drop unused assignments of pci_device_id driver data
The drivers explicitly set the .driver_data member of struct
pci_device_id to zero without relying on that value. Drop these unused
assignments.

While touching these arrays, convert the one driver not using PCI_DEVICE
to use that macro and align the array's coding style to what is used
most for these. (i.e. break very long lines, a single space in the list
terminator and no trailing comma.)

This patch doesn't modify the compiled array, only its representation in
source form benefits. The former was confirmed with builds on x86 and
arm64.

Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
2026-06-12 11:43:53 +02:00
Heiko Carstens
37540b8c28 s390: Revert support for DCACHE_WORD_ACCESS
load_unaligned_zeropad() reads eight bytes from unaligned addresses and may
cross page boundaries. It handles exceptions which may happen if reading
from the second page results in an exception.

For pages which are donated to the Ultravisor for secure execution purposes
the do_secure_storage_access() exception handler however does not handle
such exceptions correctly. Such an exception may result in an endless
exception loop which will never be resolved.

An attempt to fix this [1] turned out to be not sufficient. For now revert
load_unaligned_zeropad() until this problem has been resolved in a proper
way.

Note that the implementation of load_unaligned_zeropad() itself is
correct. The revert is just a temporary workaround until there is complete
fix for secure storage access exceptions.

[1] commit b00be77302 ("s390/mm: Add missing secure storage access fixups for donated memory")

Fixes: 802ba53eef ("s390: add support for DCACHE_WORD_ACCESS")
Cc: stable@vger.kernel.org
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2026-06-12 11:30:25 +02:00
Vlastimil Babka (SUSE)
dfdfd58cce Merge branch 'slab/for-7.2/alloc_token' into slab/for-next
Merge series "slab: support for compiler-assisted type-based slab cache
partitioning" from Marco Elver. From the cover letter [6]:

Rework the general infrastructure around RANDOM_KMALLOC_CACHES into more
flexible KMALLOC_PARTITION_CACHES, with the former being a partitioning
mode of the latter.

Introduce a new mode, KMALLOC_PARTITION_TYPED, which leverages a feature
available in Clang 22 and later, called "allocation tokens" via
__builtin_infer_alloc_token() [1]. Unlike KMALLOC_PARTITION_RANDOM
(formerly RANDOM_KMALLOC_CACHES), this mode deterministically assigns a
slab cache to an allocation of type T, regardless of allocation site.

The builtin __builtin_infer_alloc_token(<malloc-args>, ...) instructs
the compiler to infer an allocation type from arguments commonly passed
to memory-allocating functions and returns a type-derived token ID. The
implementation passes kmalloc-args to the builtin: the compiler performs
best-effort type inference, and then recognizes common patterns such as
`kmalloc(sizeof(T), ...)`, `kmalloc(sizeof(T) * n, ...)`, but also
`(T *)kmalloc(...)`. Where the compiler fails to infer a type the
fallback token (default: 0) is chosen.

Note: kmalloc_obj(..) APIs fix the pattern how size and result type are
expressed, and therefore ensures there's not much drift in which
patterns the compiler needs to recognize. Specifically, kmalloc_obj()
and friends expand to `(TYPE *)KMALLOC(__obj_size, GFP)`, which the
compiler recognizes via the cast to TYPE*.

Clang's default token ID calculation is described as [1]:

   typehashpointersplit: This mode assigns a token ID based on the hash
   of the allocated type's name, where the top half ID-space is reserved
   for types that contain pointers and the bottom half for types that do
   not contain pointers.

Separating pointer-containing objects from pointerless objects and data
allocations can help mitigate certain classes of memory corruption
exploits [2]: attackers who gains a buffer overflow on a primitive
buffer cannot use it to directly corrupt pointers or other critical
metadata in an object residing in a different, isolated heap region.

It is important to note that heap isolation strategies offer a
best-effort approach, and do not provide a 100% security guarantee,
albeit achievable at relatively low performance cost. Note that this
also does not prevent cross-cache attacks: while waiting for future
features like SLAB_VIRTUAL [3] to provide physical page isolation, this
feature should be deployed alongside SHUFFLE_PAGE_ALLOCATOR and
init_on_free=1 to mitigate cross-cache attacks and page-reuse attacks as
much as possible today.

With all that, my kernel (x86 defconfig) shows me a histogram of slab
cache object distribution per /proc/slabinfo (after boot):

  <slab cache>      <objs> <hist>
  kmalloc-part-15    1465  ++++++++++++++
  kmalloc-part-14    2988  +++++++++++++++++++++++++++++
  kmalloc-part-13    1656  ++++++++++++++++
  kmalloc-part-12    1045  ++++++++++
  kmalloc-part-11    1697  ++++++++++++++++
  kmalloc-part-10    1489  ++++++++++++++
  kmalloc-part-09     965  +++++++++
  kmalloc-part-08     710  +++++++
  kmalloc-part-07     100  +
  kmalloc-part-06     217  ++
  kmalloc-part-05     105  +
  kmalloc-part-04    4047  ++++++++++++++++++++++++++++++++++++++++
  kmalloc-part-03     183  +
  kmalloc-part-02     283  ++
  kmalloc-part-01     316  +++
  kmalloc            1422  ++++++++++++++

The above /proc/slabinfo snapshot shows me there are 6673 allocated
objects (slabs 00 - 07) that the compiler claims contain no pointers or
it was unable to infer the type of, and 12015 objects that contain
pointers (slabs 08 - 15). On a whole, this looks relatively sane.

Additionally, when I compile my kernel with -Rpass=alloc-token, which
provides diagnostics where (after dead-code elimination) type inference
failed, I see 186 allocation sites where the compiler failed to identify
a type (down from 966 when I sent the RFC [4]). Some initial review
confirms these are mostly variable sized buffers, but also include
structs with trailing flexible length arrays.

Link: https://clang.llvm.org/docs/AllocToken.html [1]
Link: https://blog.dfsec.com/ios/2025/05/30/blasting-past-ios-18/ [2]
Link: https://lwn.net/Articles/944647/ [3]
Link: https://lore.kernel.org/all/20250825154505.1558444-1-elver@google.com/ [4]
Link: https://discourse.llvm.org/t/rfc-a-framework-for-allocator-partitioning-hints/87434 [5]

Link: https://lore.kernel.org/all/20260511200136.3201646-1-elver@google.com/ [6]
2026-06-12 11:25:12 +02:00
Vlastimil Babka (SUSE)
d3c45a0fee Merge branch 'slab/for-7.2/alloc_bulk' into slab/for-next
Merge two separately sent but vaguely related patches from Christoph
Hellwig.  One changes the kmem_cache_alloc_bulk() API to return bool,
because it was already actiong as all-or-nothing, and that aspect was
not documented. Existing callers are updated.

The second patch simplifies the mempool_alloc_bulk() API to stop
skipping over non-NULL entries in the array, and removes a related
parameter that said how many are non-NULL.

A similar simplification of alloc_pages_bulk() is being discussed as
well and should follow in near future.
2026-06-12 11:25:12 +02:00
Vlastimil Babka (SUSE)
d196ea36a2 Merge branch 'slab/for-7.2/tools' into slab/for-next
Merge series "Cleanup and fix tools/mm/slabinfo utility" from Xuewen
Wang.

This series fixes one bug and cleans up two code quality issues in
tools/mm/slabinfo.

Additionally, add this tool and other related scripts and tools to the
SLAB ALLOCATOR of MAINTAINERS.

Link: https://lore.kernel.org/all/20260518062159.80664-1-wangxuewen@kylinos.cn/
2026-06-12 11:25:12 +02:00
Vlastimil Babka (SUSE)
648927ceb8 mm/slab: do not limit zeroing to orig_size when only red zoning is enabled
When init (zeroing) on allocation is requested, for kmalloc() we
generally have to zero the full object size even if a smaller size is
requested, in order to provide krealloc()'s __GFP_ZERO guarantees.

But if we track the requested size, krealloc() uses that information to
do the right thing, so we can zero only the requested size. With red
zoning also enabled, any extra size became part of the red zone, so it
must not be zeroed and thus we must zero only the requested size.

However the current check is imprecise, and will trigger also when only
SLAB_RED_ZONE is enabled without SLAB_STORE_USER (which enables tracking
the requested size). This means enabling red zoning alone can compromise
krealloc()'s __GFP_ZERO contract.

Fix this by using slub_debug_orig_size() instead, which is the exact
check for whether the requested size is tracked. We don't need to care
if red zoning is also enabled or not. Also update and expand the
comment accordingly.

Fixes: 9ce67395f5 ("mm/slub: only zero requested size of buffer for kzalloc when debug enabled")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260610-slab_alloc_flags-v2-1-7190909db118@kernel.org
Reviewed-by: Harry Yoo (Oracle) <harry@kernel.org>
Reviewed-by: Hao Li <hao.li@linux.dev>
Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-06-12 11:24:53 +02:00
Wolfram Sang
9bffa2a615
MAINTAINERS: hand over I2C to Andi Shyti
After 13.5 years of maintaining I2C, it is finally time for me to move
to other areas. So, I hereby transfer I2C maintainership to Andi Shyti.
He has been taking care of the I2C host drivers for a while now and
kindly agreed to look after the whole subsystem. Thank you, Andi! I also
want to thank all contributors, reviewers, and fellow maintainers making
all these years a mostly smooth ride. Happy hacking, everyone!

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20260609091612.8228-4-wsa+renesas@sang-engineering.com
2026-06-12 11:11:58 +02:00
Cássio Gabriel
e76296d137 ALSA: pcxhr: Share PLL frequency register calculation
The PCXHR and HR222 clock paths duplicate the PLL divider calculation and
register encoding. The HR222 variant extends the same format with an
additional range for rates above those supported by the older boards.

Move the complete encoding into pcxhr_pll_freq_register() and pass each
hardware path its existing maximum frequency. The additional encoding
branch is unreachable with the older 110 kHz limit, so this preserves both
paths' accepted ranges and generated register values while removing the
duplicate implementation and its long-standing TODO.

Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Link: https://patch.msgid.link/20260612-alsa-pcxhr-pll-helper-v1-1-c84ae2bd2e9b@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-06-12 11:07:34 +02:00