<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/include, branch linux-6.17.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.17.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.17.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2025-12-18T13:00:16Z</updated>
<entry>
<title>ALSA: hda/tas2781: fix speaker id retrieval for multiple probes</title>
<updated>2025-12-18T13:00:16Z</updated>
<author>
<name>Antheas Kapenekakis</name>
<email>lkml@antheas.dev</email>
</author>
<published>2025-10-26T19:16:34Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=aa463ec2fff179a539d7f6e8c11c8fce57b7aa44'/>
<id>urn:sha1:aa463ec2fff179a539d7f6e8c11c8fce57b7aa44</id>
<content type='text'>
commit 945865a0ddf3e3950aea32e23e10d815ee9b21bc upstream.

Currently, on ASUS projects, the TAS2781 codec attaches the speaker GPIO
to the first tasdevice_priv instance using devm. This causes
tas2781_read_acpi to fail on subsequent probes since the GPIO is already
managed by the first device. This causes a failure on Xbox Ally X,
because it has two amplifiers, and prevents us from quirking both the
Xbox Ally and Xbox Ally X in the realtek codec driver.

It is unnecessary to attach the GPIO to a device as it is static.
Therefore, instead of attaching it and then reading it when loading the
firmware, read its value directly in tas2781_read_acpi and store it in
the private data structure. Then, make reading the value non-fatal so
that ASUS projects that miss a speaker pin can still work, perhaps using
fallback firmware.

Fixes: 4e7035a75da9 ("ALSA: hda/tas2781: Add speaker id check for ASUS projects")
Cc: stable@vger.kernel.org # 6.17
Signed-off-by: Antheas Kapenekakis &lt;lkml@antheas.dev&gt;
Reviewed-by: Baojun Xu &lt;baojun.xu@ti.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Link: https://patch.msgid.link/20251026191635.2447593-1-lkml@antheas.dev
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>efi/cper: align ARM CPER type with UEFI 2.9A/2.10 specs</title>
<updated>2025-12-18T13:00:15Z</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab+huawei@kernel.org</email>
</author>
<published>2025-08-14T16:52:55Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=40e646ed350c138c1cd93c48a79a55554d0f0797'/>
<id>urn:sha1:40e646ed350c138c1cd93c48a79a55554d0f0797</id>
<content type='text'>
[ Upstream commit 96b010536ee020e716d28d9b359a4bcd18800aeb ]

Up to UEFI spec 2.9, the type byte of CPER struct for ARM processor
was defined simply as:

Type at byte offset 4:

	- Cache error
	- TLB Error
	- Bus Error
	- Micro-architectural Error
	All other values are reserved

Yet, there was no information about how this would be encoded.

Spec 2.9A errata corrected it by defining:

	- Bit 1 - Cache Error
	- Bit 2 - TLB Error
	- Bit 3 - Bus Error
	- Bit 4 - Micro-architectural Error
	All other values are reserved

That actually aligns with the values already defined on older
versions at N.2.4.1. Generic Processor Error Section.

Spec 2.10 also preserve the same encoding as 2.9A.

Adjust CPER and GHES handling code for both generic and ARM
processors to properly handle UEFI 2.9A and 2.10 encoding.

Link: https://uefi.org/specs/UEFI/2.10/Apx_N_Common_Platform_Error_Record.html#arm-processor-error-information
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Acked-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>efi/cper: Add a new helper function to print bitmasks</title>
<updated>2025-12-18T13:00:14Z</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab+huawei@kernel.org</email>
</author>
<published>2025-08-14T16:52:54Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9009be7ff281f3fdc09de16732f14eedd7449954'/>
<id>urn:sha1:9009be7ff281f3fdc09de16732f14eedd7449954</id>
<content type='text'>
[ Upstream commit a976d790f49499ccaa0f991788ad8ebf92e7fd5c ]

Add a helper function to print a string with names associated
to each bit field.

A typical example is:

	const char * const bits[] = {
		"bit 3 name",
		"bit 4 name",
		"bit 5 name",
	};
	char str[120];
        unsigned int bitmask = BIT(3) | BIT(5);

	#define MASK  GENMASK(5,3)

	cper_bits_to_str(str, sizeof(str), FIELD_GET(MASK, bitmask),
			 bits, ARRAY_SIZE(bits));

The above code fills string "str" with "bit 3 name|bit 5 name".

Reviewed-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Acked-by: Borislav Petkov (AMD) &lt;bp@alien8.de&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ALSA: uapi: Fix typo in asound.h comment</title>
<updated>2025-12-18T13:00:12Z</updated>
<author>
<name>Andres J Rosa</name>
<email>andyrosa@gmail.com</email>
</author>
<published>2025-12-03T16:25:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=152b482a4b87e547d9bf46a49b268844253134d1'/>
<id>urn:sha1:152b482a4b87e547d9bf46a49b268844253134d1</id>
<content type='text'>
[ Upstream commit 9a97857db0c5655b8932f86b5d18bb959079b0ee ]

Fix 'level-shit' to 'level-shift' in struct snd_cea_861_aud_if comment.

Fixes: 7ba1c40b536e ("ALSA: Add definitions for CEA-861 Audio InfoFrames")
Signed-off-by: Andres J Rosa &lt;andyrosa@gmail.com&gt;
Link: https://patch.msgid.link/20251203162509.1822-1-andyrosa@gmail.com
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>block: fix comment for op_is_zone_mgmt() to include RESET_ALL</title>
<updated>2025-12-18T13:00:11Z</updated>
<author>
<name>shechenglong</name>
<email>shechenglong@xfusion.com</email>
</author>
<published>2025-12-03T15:17:49Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3310d6375fdf7902588f19d75006482aa335ca3b'/>
<id>urn:sha1:3310d6375fdf7902588f19d75006482aa335ca3b</id>
<content type='text'>
[ Upstream commit 8a32282175c964eb15638e8dfe199fc13c060f67 ]

REQ_OP_ZONE_RESET_ALL is a zone management request, and op_is_zone_mgmt()
has returned true for it.

Update the comment to remove the misleading exception note so
the documentation matches the implementation.

Fixes: 12a1c9353c47 ("block: fix op_is_zone_mgmt() to handle REQ_OP_ZONE_RESET_ALL")
Signed-off-by: shechenglong &lt;shechenglong@xfusion.com&gt;
Reviewed-by: Damien Le Moal &lt;dlemoal@kernel.org&gt;
Reviewed-by: Johannes Thumshirn &lt;johannes.thumshirn@wdc.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>f2fs: revert summary entry count from 2048 to 512 in 16kb block support</title>
<updated>2025-12-18T13:00:10Z</updated>
<author>
<name>Daeho Jeong</name>
<email>daehojeong@google.com</email>
</author>
<published>2025-11-11T17:52:46Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=80c9941c2a5a4fb8c71edf86e7ca8374b5fe10d6'/>
<id>urn:sha1:80c9941c2a5a4fb8c71edf86e7ca8374b5fe10d6</id>
<content type='text'>
[ Upstream commit 7ee8bc3942f20964ad730871b885688ea3a2961a ]

The recent increase in the number of Segment Summary Area (SSA) entries
from 512 to 2048 was an unintentional change in logic of 16kb block
support. This commit corrects the issue.

To better utilize the space available from the erroneous 2048-entry
calculation, we are implementing a solution to share the currently
unused SSA space with neighboring segments. This enhances overall
SSA utilization without impacting the established 8MB segment size.

Fixes: d7e9a9037de2 ("f2fs: Support Block Size == Page Size")
Signed-off-by: Daeho Jeong &lt;daehojeong@google.com&gt;
Reviewed-by: Chao Yu &lt;chao@kernel.org&gt;
Signed-off-by: Jaegeuk Kim &lt;jaegeuk@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NFS: Fix inheritance of the block sizes when automounting</title>
<updated>2025-12-18T13:00:09Z</updated>
<author>
<name>Trond Myklebust</name>
<email>trond.myklebust@hammerspace.com</email>
</author>
<published>2025-11-28T21:06:41Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e743a0ec4b37bde6fd419aa58014158e61b3839c'/>
<id>urn:sha1:e743a0ec4b37bde6fd419aa58014158e61b3839c</id>
<content type='text'>
[ Upstream commit 2b092175f5e301cdaa935093edfef2be9defb6df ]

Only inherit the block sizes that were actually specified as mount
parameters for the parent mount.

Fixes: 62a55d088cd8 ("NFS: Additional refactoring for fs_context conversion")
Signed-off-by: Trond Myklebust &lt;trond.myklebust@hammerspace.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: hsr: create an API to get hsr port type</title>
<updated>2025-12-18T13:00:06Z</updated>
<author>
<name>Xiaoliang Yang</name>
<email>xiaoliang.yang_1@nxp.com</email>
</author>
<published>2025-11-30T13:16:44Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2ecc02aa47f5e47cb14d0d3fdadc5b2908e92840'/>
<id>urn:sha1:2ecc02aa47f5e47cb14d0d3fdadc5b2908e92840</id>
<content type='text'>
[ Upstream commit a0244e76213980f3b9bb5d40b0b6705fcf24230d ]

Since the introduction of HSR_PT_INTERLINK in commit 5055cccfc2d1 ("net:
hsr: Provide RedBox support (HSR-SAN)"), we see that different port
types require different settings for hardware offload, which was not the
case before when we only had HSR_PT_SLAVE_A and HSR_PT_SLAVE_B. But
there is currently no way to know which port is which type, so create
the hsr_get_port_type() API function and export it.

When hsr_get_port_type() is called from the device driver, the port can
must be found in the HSR port list. An important use case is for this
function to work from offloading drivers' NETDEV_CHANGEUPPER handler,
which is triggered by hsr_portdev_setup() -&gt; netdev_master_upper_dev_link().
Therefore, we need to move the addition of the hsr_port to the HSR port
list prior to calling hsr_portdev_setup(). This makes the error
restoration path also more similar to hsr_del_port(), where
kfree_rcu(port) is already used.

Cc: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Cc: Lukasz Majewski &lt;lukma@denx.de&gt;
Signed-off-by: Xiaoliang Yang &lt;xiaoliang.yang_1@nxp.com&gt;
Signed-off-by: Vladimir Oltean &lt;vladimir.oltean@nxp.com&gt;
Reviewed-by: Łukasz Majewski &lt;lukma@nabladev.com&gt;
Link: https://patch.msgid.link/20251130131657.65080-3-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Stable-dep-of: 30296ac76426 ("net: dsa: xrs700x: reject unsupported HSR configurations")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>rqspinlock: Enclose lock/unlock within lock entry acquisitions</title>
<updated>2025-12-18T13:00:03Z</updated>
<author>
<name>Kumar Kartikeya Dwivedi</name>
<email>memxor@gmail.com</email>
</author>
<published>2025-11-28T23:27:57Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=838b42af8d7ed8ad4e15ef563a89a6fb783b7ef4'/>
<id>urn:sha1:838b42af8d7ed8ad4e15ef563a89a6fb783b7ef4</id>
<content type='text'>
[ Upstream commit beb7021a6003d9c6a463fffca0d6311efb8e0e66 ]

Ritesh reported that timeouts occurred frequently for rqspinlock despite
reentrancy on the same lock on the same CPU in [0]. This patch closes
one of the races leading to this behavior, and reduces the frequency of
timeouts.

We currently have a tiny window between the fast-path cmpxchg and the
grabbing of the lock entry where an NMI could land, attempt the same
lock that was just acquired, and end up timing out. This is not ideal.
Instead, move the lock entry acquisition from the fast path to before
the cmpxchg, and remove the grabbing of the lock entry in the slow path,
assuming it was already taken by the fast path. The TAS fallback is
invoked directly without being preceded by the typical fast path,
therefore we must continue to grab the deadlock detection entry in that
case.

Case on lock leading to missed AA:

cmpxchg lock A
&lt;NMI&gt;
... rqspinlock acquisition of A
... timeout
&lt;/NMI&gt;
grab_held_lock_entry(A)

There is a similar case when unlocking the lock. If the NMI lands
between the WRITE_ONCE and smp_store_release, it is possible that we end
up in a situation where the NMI fails to diagnose the AA condition,
leading to a timeout.

Case on unlock leading to missed AA:

WRITE_ONCE(rqh-&gt;locks[rqh-&gt;cnt - 1], NULL)
&lt;NMI&gt;
... rqspinlock acquisition of A
... timeout
&lt;/NMI&gt;
smp_store_release(A-&gt;locked, 0)

The patch changes the order on unlock to smp_store_release() succeeded
by WRITE_ONCE() of NULL. This avoids the missed AA detection described
above, but may lead to a false positive if the NMI lands between these
two statements, which is acceptable (and preferred over a timeout).

The original intention of the reverse order on unlock was to prevent the
following possible misdiagnosis of an ABBA scenario:

grab entry A
lock A
grab entry B
lock B
unlock B
   smp_store_release(B-&gt;locked, 0)
							grab entry B
							lock B
							grab entry A
							lock A
							! &lt;detect ABBA&gt;
   WRITE_ONCE(rqh-&gt;locks[rqh-&gt;cnt - 1], NULL)

If the store release were is after the WRITE_ONCE, the other CPU would
not observe B in the table of the CPU unlocking the lock B.  However,
since the threads are obviously participating in an ABBA deadlock, it
is no longer appealing to use the order above since it may lead to a
250 ms timeout due to missed AA detection.

  [0]: https://lore.kernel.org/bpf/CAH6OuBTjG+N=+GGwcpOUbeDN563oz4iVcU3rbse68egp9wj9_A@mail.gmail.com

Fixes: 0d80e7f951be ("rqspinlock: Choose trylock fallback for NMI waiters")
Reported-by: Ritesh Oedayrajsingh Varma &lt;ritesh@superluminal.eu&gt;
Signed-off-by: Kumar Kartikeya Dwivedi &lt;memxor@gmail.com&gt;
Link: https://lore.kernel.org/r/20251128232802.1031906-2-memxor@gmail.com
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>vfio/pci: Use RCU for error/request triggers to avoid circular locking</title>
<updated>2025-12-18T13:00:03Z</updated>
<author>
<name>Alex Williamson</name>
<email>alex.williamson@nvidia.com</email>
</author>
<published>2025-11-24T22:36:22Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ef0a26b9d99f7153af64117dd795c7873987d9a7'/>
<id>urn:sha1:ef0a26b9d99f7153af64117dd795c7873987d9a7</id>
<content type='text'>
[ Upstream commit 98693e0897f754e3f51ce6626ed5f785f625ba2b ]

Thanks to a device generating an ACS violation during bus reset,
lockdep reported the following circular locking issue:

CPU0: SET_IRQS (MSI/X): holds igate, acquires memory_lock
CPU1: HOT_RESET: holds memory_lock, acquires pci_bus_sem
CPU2: AER: holds pci_bus_sem, acquires igate

This results in a potential 3-way deadlock.

Remove the pci_bus_sem-&gt;igate leg of the triangle by using RCU
to peek at the eventfd rather than locking it with igate.

Fixes: 3be3a074cf5b ("vfio-pci: Don't use device_lock around AER interrupt setup")
Signed-off-by: Alex Williamson &lt;alex.williamson@nvidia.com&gt;
Reviewed-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Link: https://lore.kernel.org/r/20251124223623.2770706-1-alex@shazbot.org
Signed-off-by: Alex Williamson &lt;alex@shazbot.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
