<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel, branch linux-6.15.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.15.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.15.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2025-08-20T16:36:36Z</updated>
<entry>
<title>Linux 6.15.11</title>
<updated>2025-08-20T16:36:36Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2025-08-20T16:36:36Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=4afb9d6bd4c4b3dad7e2c9c48b6c8a55275d8f46'/>
<id>urn:sha1:4afb9d6bd4c4b3dad7e2c9c48b6c8a55275d8f46</id>
<content type='text'>
Link: https://lore.kernel.org/r/20250818124458.334548733@linuxfoundation.org
Tested-by: Brett A C Sheffield &lt;bacs@librecast.net&gt;
Tested-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Tested-by: Shuah Khan &lt;skhan@linuxfoundation.org&gt;
Tested-by: Ron Economos &lt;re@w6rz.net&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Link: https://lore.kernel.org/r/20250819122834.836683687@linuxfoundation.org
Tested-by: Peter Schneider &lt;pschneider1968@googlemail.com&gt;
Tested-by: Florian Fainelli &lt;floria.fainelli@broadcom.com&gt;
Tested-by: Justin M. Forbes &lt;jforbes@fedoraproject.org&gt;
Tested-by: Brett A C Sheffield &lt;bacs@librecast.net&gt;
Tested-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ACPI: Return -ENODEV from acpi_parse_spcr() when SPCR support is disabled</title>
<updated>2025-08-20T16:36:36Z</updated>
<author>
<name>Li Chen</name>
<email>chenl311@chinatelecom.cn</email>
</author>
<published>2025-06-20T13:13:07Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a3a38cafa9c1cf42e41693547f765ce0857f5d6d'/>
<id>urn:sha1:a3a38cafa9c1cf42e41693547f765ce0857f5d6d</id>
<content type='text'>
commit b9f58d3572a8e1ef707b941eae58ec4014b9269d upstream.

If CONFIG_ACPI_SPCR_TABLE is disabled, acpi_parse_spcr()
currently returns 0, which may incorrectly suggest that
SPCR parsing was successful. This patch changes the behavior
to return -ENODEV to clearly indicate that SPCR support
is not available.

This prepares the codebase for future changes that depend
on acpi_parse_spcr() failure detection, such as suppressing
misleading console messages.

Signed-off-by: Li Chen &lt;chenl311@chinatelecom.cn&gt;
Acked-by: Hanjun Guo &lt;guohanjun@huawei.com&gt;
Link: https://lore.kernel.org/r/20250620131309.126555-2-me@linux.beauty
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dm: split write BIOs on zone boundaries when zone append is not emulated</title>
<updated>2025-08-20T16:36:35Z</updated>
<author>
<name>Shin'ichiro Kawasaki</name>
<email>shinichiro.kawasaki@wdc.com</email>
</author>
<published>2025-07-17T10:35:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d86f0b918e93a8183cf02dd159b823338db63656'/>
<id>urn:sha1:d86f0b918e93a8183cf02dd159b823338db63656</id>
<content type='text'>
commit 675f940576351bb049f5677615140b9d0a7712d0 upstream.

Commit 2df7168717b7 ("dm: Always split write BIOs to zoned device
limits") updates the device-mapper driver to perform splits for the
write BIOs. However, it did not address the cases where DM targets do
not emulate zone append, such as in the cases of dm-linear or dm-flakey.
For these targets, when the write BIOs span across zone boundaries, they
trigger WARN_ON_ONCE(bio_straddles_zones(bio)) in
blk_zone_wplug_handle_write(). This results in I/O errors. The errors
are reproduced by running blktests test case zbd/004 using zoned
dm-linear or dm-flakey devices.

To avoid the I/O errors, handle the write BIOs regardless whether DM
targets emulate zone append or not, so that all write BIOs are split at
zone boundaries. For that purpose, drop the check for zone append
emulation in dm_zone_bio_needs_split(). Its argument 'md' is no longer
used then drop it also.

Fixes: 2df7168717b7 ("dm: Always split write BIOs to zoned device limits")
Signed-off-by: Shin'ichiro Kawasaki &lt;shinichiro.kawasaki@wdc.com&gt;
Reviewed-by: Damien Le Moal &lt;dlemoal@kernel.org&gt;
Reviewed-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Link: https://lore.kernel.org/r/20250717103539.37279-1-shinichiro.kawasaki@wdc.com
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>rcu: Fix racy re-initialization of irq_work causing hangs</title>
<updated>2025-08-20T16:36:35Z</updated>
<author>
<name>Frederic Weisbecker</name>
<email>frederic@kernel.org</email>
</author>
<published>2025-08-08T17:03:22Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7033b93bc0061c2cb177cce59a15ea302caeb458'/>
<id>urn:sha1:7033b93bc0061c2cb177cce59a15ea302caeb458</id>
<content type='text'>
commit 61399e0c5410567ef60cb1cda34cca42903842e3 upstream.

RCU re-initializes the deferred QS irq work everytime before attempting
to queue it. However there are situations where the irq work is
attempted to be queued even though it is already queued. In that case
re-initializing messes-up with the irq work queue that is about to be
handled.

The chances for that to happen are higher when the architecture doesn't
support self-IPIs and irq work are then all lazy, such as with the
following sequence:

1) rcu_read_unlock() is called when IRQs are disabled and there is a
   grace period involving blocked tasks on the node. The irq work
   is then initialized and queued.

2) The related tasks are unblocked and the CPU quiescent state
   is reported. rdp-&gt;defer_qs_iw_pending is reset to DEFER_QS_IDLE,
   allowing the irq work to be requeued in the future (note the previous
   one hasn't fired yet).

3) A new grace period starts and the node has blocked tasks.

4) rcu_read_unlock() is called when IRQs are disabled again. The irq work
   is re-initialized (but it's queued! and its node is cleared) and
   requeued. Which means it's requeued to itself.

5) The irq work finally fires with the tick. But since it was requeued
   to itself, it loops and hangs.

Fix this with initializing the irq work only once before the CPU boots.

Fixes: b41642c87716 ("rcu: Fix rcu_read_unlock() deadloop due to IRQ work")
Reported-by: kernel test robot &lt;oliver.sang@intel.com&gt;
Closes: https://lore.kernel.org/oe-lkp/202508071303.c1134cce-lkp@intel.com
Signed-off-by: Frederic Weisbecker &lt;frederic@kernel.org&gt;
Reviewed-by: Joel Fernandes &lt;joelagnelf@nvidia.com&gt;
Signed-off-by: Neeraj Upadhyay (AMD) &lt;neeraj.upadhyay@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Allow DCN301 to clear update flags</title>
<updated>2025-08-20T16:36:35Z</updated>
<author>
<name>Ivan Lipski</name>
<email>ivan.lipski@amd.com</email>
</author>
<published>2025-07-17T17:58:35Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c492e9398e26162d727bb34a2b827d53698a7a74'/>
<id>urn:sha1:c492e9398e26162d727bb34a2b827d53698a7a74</id>
<content type='text'>
commit 2d418e4fd9f1eca7dfce80de86dd702d36a06a25 upstream.

[Why &amp; How]
Not letting DCN301 to clear after surface/stream update results
in artifacts when switching between active overlay planes. The issue
is known and has been solved initially. See below:
(https://gitlab.freedesktop.org/drm/amd/-/issues/3441)

Fixes: f354556e29f4 ("drm/amd/display: limit clear_update_flags t dcn32 and above")
Reviewed-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Signed-off-by: Ivan Lipski &lt;ivan.lipski@amd.com&gt;
Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>firmware: arm_scmi: Convert to SYSTEM_SLEEP_PM_OPS</title>
<updated>2025-08-20T16:36:35Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2025-07-09T07:01:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fb9c2eef2390f73bec2f4bc846c2eb4bf08916da'/>
<id>urn:sha1:fb9c2eef2390f73bec2f4bc846c2eb4bf08916da</id>
<content type='text'>
commit 62d6b81e8bd207ad44eff39d1a0fe17f0df510a5 upstream.

The old SET_SYSTEM_SLEEP_PM_OPS() macro leads to a warning about an
unused function:

  |  drivers/firmware/arm_scmi/scmi_power_control.c:363:12: error:
  | 	'scmi_system_power_resume' defined but not used [-Werror=unused-function]
  |         static int scmi_system_power_resume(struct device *dev)

The proper way to do this these days is to use SYSTEM_SLEEP_PM_OPS()
and pm_sleep_ptr().

Fixes: 9a0658d3991e ("firmware: arm_scmi: power_control: Ensure SCMI_SYSPOWER_IDLE is set early during resume")
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Peng Fan &lt;peng.fan@nxp.com&gt;
Message-Id: &lt;20250709070107.1388512-1-arnd@kernel.org&gt;
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>io_uring/rw: cast rw-&gt;flags assignment to rwf_t</title>
<updated>2025-08-20T16:36:35Z</updated>
<author>
<name>Jens Axboe</name>
<email>axboe@kernel.dk</email>
</author>
<published>2025-07-07T22:46:30Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=29c1a8e6e749c6213e6bea903a8980fbf7017e4a'/>
<id>urn:sha1:29c1a8e6e749c6213e6bea903a8980fbf7017e4a</id>
<content type='text'>
commit 825aea662b492571877b32aeeae13689fd9fbee4 upstream.

kernel test robot reports that a recent change of the sqe-&gt;rw_flags
field throws a sparse warning on 32-bit archs:

&gt;&gt; io_uring/rw.c:291:19: sparse: sparse: incorrect type in assignment (different base types) @@     expected restricted __kernel_rwf_t [usertype] flags @@     got unsigned int @@
   io_uring/rw.c:291:19: sparse:     expected restricted __kernel_rwf_t [usertype] flags
   io_uring/rw.c:291:19: sparse:     got unsigned int

Force cast it to rwf_t to silence that new sparse warning.

Fixes: cf73d9970ea4 ("io_uring: don't use int for ABI")
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Closes: https://lore.kernel.org/oe-kbuild-all/202507032211.PwSNPNSP-lkp@intel.com/
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ata: libata-sata: Add link_power_management_supported sysfs attribute</title>
<updated>2025-08-20T16:36:35Z</updated>
<author>
<name>Damien Le Moal</name>
<email>dlemoal@kernel.org</email>
</author>
<published>2025-07-28T04:04:29Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b4f7089949b8a1000df7d54cfc3729a0e768c52a'/>
<id>urn:sha1:b4f7089949b8a1000df7d54cfc3729a0e768c52a</id>
<content type='text'>
commit 0060beec0bfa647c4b510df188b1c4673a197839 upstream.

A port link power management (LPM) policy can be controlled using the
link_power_management_policy sysfs host attribute. However, this
attribute exists also for hosts that do not support LPM and in such
case, attempting to change the LPM policy for the host (port) will fail
with -EOPNOTSUPP.

Introduce the new sysfs link_power_management_supported host attribute
to indicate to the user if a the port and the devices connected to the
port for the host support LPM, which implies that the
link_power_management_policy attribute can be used.

Since checking that a port and its devices support LPM is common between
the new ata_scsi_lpm_supported_show() function and the existing
ata_scsi_lpm_store() function, the new helper ata_scsi_lpm_supported()
is introduced.

Fixes: 413e800cadbf ("ata: libata-sata: Disallow changing LPM state if not supported")
Reported-by: Borah, Chaitanya Kumar &lt;chaitanya.kumar.borah@intel.com&gt;
Reported-by: kernel test robot &lt;oliver.sang@intel.com&gt;
Closes: https://lore.kernel.org/oe-lkp/202507251014.a5becc3b-lkp@intel.com
Signed-off-by: Damien Le Moal &lt;dlemoal@kernel.org&gt;
Reviewed-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>wifi: ath12k: install pairwise key first</title>
<updated>2025-08-20T16:36:35Z</updated>
<author>
<name>Baochen Qiang</name>
<email>quic_bqiang@quicinc.com</email>
</author>
<published>2025-05-23T03:49:02Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0757df22c2326c377b9b7190d9d25a6129dc0177'/>
<id>urn:sha1:0757df22c2326c377b9b7190d9d25a6129dc0177</id>
<content type='text'>
commit 66e865f9dc78d00e6d1c8c6624cb0c9004e5aafb upstream.

As station, WCN7850 firmware requires pairwise key to be installed before
group key. Currently host does not care about this, so it is up to kernel
or userspace to decide which one will be installed first. In case above
requirement is not met, WCN7850 firmware's EAPOL station machine is messed
up, and finally connection fails [1].

Reorder key install for station interface in that case: this is done by
caching group key first; Later when pairwise key arrives, both can be
installed in required order.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00217-QCAHKSWPL_SILICONZ-1

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218733
Link: https://lore.kernel.org/all/AS8P190MB12051DDBD84CD88E71C40AD7873F2@AS8P190MB1205.EURP190.PROD.OUTLOOK.COM # [1]
Signed-off-by: Baochen Qiang &lt;quic_bqiang@quicinc.com&gt;
Reviewed-by: Vasanthakumar Thiagarajan &lt;vasanthakumar.thiagarajan@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20250523-ath12k-unicast-key-first-v1-2-f53c3880e6d8@quicinc.com
Signed-off-by: Jeff Johnson &lt;jeff.johnson@oss.qualcomm.com&gt;
Signed-off-by: Baochen Qiang &lt;baochen.qiang@oss.qualcomm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>HID: magicmouse: avoid setting up battery timer when not needed</title>
<updated>2025-08-20T16:36:35Z</updated>
<author>
<name>Aditya Garg</name>
<email>gargaditya08@live.com</email>
</author>
<published>2025-06-30T12:37:13Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=983fa680193390b8d3dc4a7aa989eeccdfaa2abd'/>
<id>urn:sha1:983fa680193390b8d3dc4a7aa989eeccdfaa2abd</id>
<content type='text'>
commit 9bdc30e35cbc1aa78ccf01040354209f1e11ca22 upstream.

Currently, the battery timer is set up for all devices using
hid-magicmouse, irrespective of whether they actually need it or not.

The current implementation requires the battery timer for Magic Mouse 2
and Magic Trackpad 2 when connected via USB only. Add checks to ensure
that the battery timer is only set up when they are connected via USB.

Fixes: 0b91b4e4dae6 ("HID: magicmouse: Report battery level over USB")
Cc: stable@vger.kernel.org
Signed-off-by: Aditya Garg &lt;gargaditya08@live.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
