<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git, branch v7.0.12</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v7.0.12</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v7.0.12'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-06-09T10:32:51+00:00</updated>
<entry>
<title>Linux 7.0.12</title>
<updated>2026-06-09T10:32:51+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2026-06-09T10:32:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f53879e2e1e2fa053040e734c1ef8f386109a61b'/>
<id>urn:sha1:f53879e2e1e2fa053040e734c1ef8f386109a61b</id>
<content type='text'>
Link: https://lore.kernel.org/r/20260607095728.031258202@linuxfoundation.org
Tested-by: Ronald Warsow &lt;rwarsow@gmx.de&gt;
Tested-by: Takeshi Ogasawara &lt;takeshi.ogasawara@futuring-girl.com&gt;
Tested-by: Jeffrin Jose T &lt;jeffrin@rajagiritech.edu.in&gt;
Tested-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
Tested-by: Pavel Machek (CIP) &lt;pavel@nabladev.com&gt;
Tested-by: Peter Schneider &lt;pschneider1968@googlemail.com&gt;
Tested-by: Ron Economos &lt;re@w6rz.net&gt;
Tested-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Tested-by: Mark Brown &lt;broonie@kernel.org&gt;
Tested-by: Dileep Malepu &lt;dileep.debian@gmail.com&gt;
Tested-by: Salvatore Bonaccorso &lt;carnil@debian.org&gt;
Tested-by: Justin M. Forbes &lt;jforbes@fedoraproject.org&gt;
Tested-by: Barry K. Nathan &lt;barryn@pobox.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: Reassign nested_mmus array behind mmu_lock</title>
<updated>2026-06-09T10:32:50+00:00</updated>
<author>
<name>Hyunwoo Kim</name>
<email>imv4bel@gmail.com</email>
</author>
<published>2026-06-05T08:27:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4424dbcb06d68e34e51c019a5781a7dc00731971'/>
<id>urn:sha1:4424dbcb06d68e34e51c019a5781a7dc00731971</id>
<content type='text'>
commit 70543358fa08e0f7cebc3447c3b70fe97ad7aaa8 upstream.

kvm-&gt;arch.nested_mmus[] is walked under kvm-&gt;mmu_lock, including from the
MMU notifier path (kvm_unmap_gfn_range() -&gt; kvm_nested_s2_unmap()), which
can run at any time. kvm_vcpu_init_nested() reallocates the array and frees
the old buffer while holding only kvm-&gt;arch.config_lock, so such a walker
can reference the freed array.

Allocate the new array outside of mmu_lock, as the allocation can sleep.
Under the lock, copy the existing entries, fix up the back pointers and
reassign the array. Free the old buffer after dropping the lock, as
kvfree() can sleep as well.

Fixes: 4f128f8e1aaac ("KVM: arm64: nv: Support multiple nested Stage-2 mmu structures")
Signed-off-by: Hyunwoo Kim &lt;imv4bel@gmail.com&gt;
Reviewed-by: Oliver Upton &lt;oupton@kernel.org&gt;
Link: https://patch.msgid.link/aiKIVVeIr1aAB1yp@v4bel
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Cc: stable@vger,kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry</title>
<updated>2026-06-09T10:32:50+00:00</updated>
<author>
<name>Hyunwoo Kim</name>
<email>imv4bel@gmail.com</email>
</author>
<published>2026-06-01T14:53:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9121f4605ab94969f62d1b5714ca3c6c69bd202f'/>
<id>urn:sha1:9121f4605ab94969f62d1b5714ca3c6c69bd202f</id>
<content type='text'>
commit 13031fb6b8357fbbcded2a7f4cba73e4781ee594 upstream.

vgic_its_invalidate_cache() walks the per-ITS translation cache with
xa_for_each() and drops the cache's reference on each entry with
vgic_put_irq(). It puts the iterated pointer, though, rather than the
value returned by xa_erase().

The function is called from contexts that do not exclude one another: the
ITS command handlers hold its_lock, the GITS_CTLR write path holds
cmd_lock, and the path that clears EnableLPIs in a redistributor's
GICR_CTLR holds neither. Two or more of them can drain the same cache
concurrently, and if each one observes the same entry, erases it and then
puts it, the single reference the cache holds on that entry is dropped
more than once. The entry can then be freed while an ITE still maps it.

xa_erase() is atomic and returns the previous entry, so put only the entry
that this context actually removed. The cache reference is then dropped
exactly once per entry even when the invalidations run concurrently, and
the behavior is unchanged when only one context runs.

Fixes: 8201d1028caa ("KVM: arm64: vgic-its: Maintain a translation cache per ITS")
Signed-off-by: Hyunwoo Kim &lt;imv4bel@gmail.com&gt;
Reviewed-by: Oliver Upton &lt;oupton@kernel.org&gt;
Link: https://patch.msgid.link/ah2c5lu4JbUg7dj-@v4bel
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tools: ynl: add scope qualifier for definitions</title>
<updated>2026-06-09T10:32:50+00:00</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2026-05-10T19:29:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3c4e4e85e8f16c80d7ae0e3aeb46a39eec029b8b'/>
<id>urn:sha1:3c4e4e85e8f16c80d7ae0e3aeb46a39eec029b8b</id>
<content type='text'>
commit fbf5df34a4dbcd09d433dd4f0916bf9b2ddb16de upstream.

Using definitions in kernel policies is awkward right now.
On one hand we want defines for max values and such.
On the other we don't have a way of adding kernel-only defines.
Adding unnecessary defines to uAPI is a bad idea, we won't
be able to delete them. And when it comes to policy user
space should just query it via the policy dump, not use
hard coded defines.

Add a "scope" property to definitions, which will let us tell
the codegen that a definition is for kernel use only. Support
following values:
  - uapi: render into the uAPI header (default, today's behavior)
  - kernel: render to kernel header only
  - user: same as kernel but for the user-side generated header

Definitions may have a header property (definition is "external",
provided by existing header). Extend the scope to headers, too.
If definition has both scope and header properties we will only
generate the includes in the right scope.

Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Link: https://patch.msgid.link/20260510192904.3987113-8-kuba@kernel.org
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: core: Fix SuperSpeed root hub wMaxPacketSize</title>
<updated>2026-06-09T10:32:50+00:00</updated>
<author>
<name>Michal Pecio</name>
<email>michal.pecio@gmail.com</email>
</author>
<published>2026-05-18T05:31:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=023b3294aaf05b55300aa6a9961fbfb4dc62ed13'/>
<id>urn:sha1:023b3294aaf05b55300aa6a9961fbfb4dc62ed13</id>
<content type='text'>
commit d1e280334b7f0a1df441e08bd1f6a1bcc36b3bbb upstream.

There is no good reason to have wBytesPerInterval &lt; wMaxPacketSize -
either one is too low or the other too high, and we may want to warn
about such descriptors. Start with cleaning up our own root hubs.

USB 3.2 section 10.15.1 sets wMaxPacketSize and wBytesPerInterval of
SuperSpeed hub status endpoints at 2 bytes, so reduce wMaxPacketSize
from its former value of 4, which was derived from USB 2.0 spec and
the kernel's USB_MAXCHILDREN limit. They don't apply because USB 3.2
10.15.2.1 specifies SuperSpeed hubs to have up to 15 ports.

Suggested-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Michal Pecio &lt;michal.pecio@gmail.com&gt;
Link: https://patch.msgid.link/20260518073121.7bc1da0f.michal.pecio@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mailbox: Fix NULL message support in mbox_send_message()</title>
<updated>2026-06-09T10:32:50+00:00</updated>
<author>
<name>Jassi Brar</name>
<email>jassisinghbrar@gmail.com</email>
</author>
<published>2026-03-27T22:00:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c14c09650e6fe3b3f067184e50abd4935e8f069e'/>
<id>urn:sha1:c14c09650e6fe3b3f067184e50abd4935e8f069e</id>
<content type='text'>
commit c58e9456e30c7098cbcd9f04571992be8a2e4e63 upstream.

The active_req field serves double duty as both the "is a TX in
flight" flag (NULL means idle) and the storage for the in-flight
message pointer. When a client sends NULL via mbox_send_message(),
active_req is set to NULL, which the framework misinterprets as
"no active request". This breaks the TX state machine by:

 - tx_tick() short-circuits on (!mssg), skipping the tx_done
   callback and the tx_complete completion
 - txdone_hrtimer() skips the channel entirely since active_req
   is NULL, so poll-based TX-done detection never fires.

Fix this by introducing a MBOX_NO_MSG sentinel value that means
"no active request," freeing NULL to be valid message data. The
sentinel is defined in the subsystem-internal mailbox.h so that
controller drivers within drivers/mailbox/ can reference it, but
it is not exposed to clients outside the subsystem.

Fifteen in-tree callers send NULL (doorbell-style IPCs on Qualcomm,
Tegra, TI, Xilinx, i.MX, SCMI, and PCC platforms). All were
audited for regression:

 - Most already work around the bug via knows_txdone=true with a
   manual mbox_client_txdone() call, making the framework's
   tracking irrelevant. These are unaffected.

 - Poll-based callers (Xilinx zynqmp/r5) are strictly better off:
   the poll timer now correctly detects NULL-active channels
   instead of silently skipping them.

 - irq-qcom-mpm.c was a pre-existing bug -- the only Qualcomm
   caller that omitted the knows_txdone + mbox_client_txdone()
   pattern. Fixed in a companion commit ("irqchip/qcom-mpm: Fix
   missing mailbox TX done acknowledgment").

 - No caller sets both a tx_done callback and sends NULL, nor
   combines tx_block=true with NULL sends, so the newly reachable
   callback/completion paths are never exercised.

Also update tegra-hsp's flush callback, which directly inspects
active_req to wait for the channel to drain: the old "!= NULL"
check becomes "!= MBOX_NO_MSG", otherwise flush spins until
timeout since the sentinel is non-NULL.

The only tradeoff is that 'MBOX_NO_MSG' can not be used as a message
by clients.

Reported-by: Joonwon Kang &lt;joonwonkang@google.com&gt;
Reviewed-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&gt;
Signed-off-by: Joonwon Kang &lt;joonwonkang@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>xhci: tegra: Fix ghost USB device on dual-role port unplug</title>
<updated>2026-06-09T10:32:50+00:00</updated>
<author>
<name>Wei-Cheng Chen</name>
<email>weichengc@nvidia.com</email>
</author>
<published>2026-06-04T12:09:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=793c9fd29b143925bcf66813669ebd0fc4fa8a40'/>
<id>urn:sha1:793c9fd29b143925bcf66813669ebd0fc4fa8a40</id>
<content type='text'>
[ Upstream commit 5a4c828b8b29b47534814ade26d9aee09d5101fc ]

When a USB device is unplugged from the dual-role port, the device-mode
path in tegra_xhci_id_work() explicitly clears both SS and HS port power
via direct hub_control ClearPortFeature(POWER) calls. This preempts the
xHCI controller's normal disconnect processing -- PORT_CSC is never
generated, the USB core never sees the disconnect, and the device remains
in its internal tree as a ghost visible in lsusb.

Add an otg_set_port_power flag to control whether the dual-role switch
path performs explicit port power management. SoCs that need it
(Tegra124 / Tegra210 / Tegra186) set the flag; later SoCs (Tegra194 and
beyond) rely on the PHY mode change to handle disconnect naturally and
skip all port power calls.

Within the port power path, otg_reset_sspi additionally gates the SSPI
reset sequence on host-mode entry for SoCs that require it.

Flags set per SoC:
  Tegra124, Tegra186  -&gt; otg_set_port_power
  Tegra210            -&gt; otg_set_port_power, otg_reset_sspi
  Tegra194 and later  -&gt; (none)

[ Backport to 7.0.y: keep the host-mode snapshot in the existing
  tegra-&gt;lock section, preserve str_on_off(), and resolve context around
  the SoC ops/Tegra234 entries. ]

Fixes: f836e7843036 ("usb: xhci-tegra: Add OTG support")
Cc: stable@vger.kernel.org
Signed-off-by: Wei-Cheng Chen &lt;weichengc@nvidia.com&gt;
Link: https://patch.msgid.link/20260505112630.217704-1-weichengc@nvidia.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: phy: micrel: fix LAN8814 QSGMII soft reset</title>
<updated>2026-06-09T10:32:50+00:00</updated>
<author>
<name>Robert Marko</name>
<email>robert.marko@sartura.hr</email>
</author>
<published>2026-04-28T13:41:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=76502a5905e0c80a10c87e43da2e4d815604dd07'/>
<id>urn:sha1:76502a5905e0c80a10c87e43da2e4d815604dd07</id>
<content type='text'>
[ Upstream commit e027c218c482c6a0ae1948129ccda3b0a2033368 ]

LAN8814 QSGMII soft reset was moved into the probe function to avoid
triggering it for each of 4 PHY-s in the package.

However, that broke QSGMII link between the MAC and PHY on most LAN8814
PHY-s, specificaly for us on the Microchip LAN969x switch.
Reading the QSGMII status registers it was visible that lanes were only
partially synced.

It looks like the reset timing is crucial, so lets move the reset back
into the .config_init function but guard it with phy_package_init_once()
to avoid it being triggered on each of 4 PHY-s in the package.
Change the probe function to use phy_package_probe_once() for coma and PtP
setup.

Fixes: 96a9178a29a6 ("net: phy: micrel: lan8814 fix reset of the QSGMII interface")
Signed-off-by: Robert Marko &lt;robert.marko@sartura.hr&gt;
Link: https://patch.msgid.link/20260428134138.1741253-1-robert.marko@sartura.hr
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>hwmon: (pmbus/adm1266) serialize GPIO PMBus accesses with pmbus_lock</title>
<updated>2026-06-09T10:32:50+00:00</updated>
<author>
<name>Abdurrahman Hussain</name>
<email>abdurrahman@nexthop.ai</email>
</author>
<published>2026-06-01T13:36:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c5b9916fe2e4523de62d3342bd4f715e98df33a4'/>
<id>urn:sha1:c5b9916fe2e4523de62d3342bd4f715e98df33a4</id>
<content type='text'>
[ Upstream commit bab8c6fb5af8df7e753d196c1262cb78e92ca872 ]

adm1266_gpio_get(), adm1266_gpio_get_multiple(), and
adm1266_gpio_dbg_show() all issue PMBus reads against the device but
none of them take pmbus_lock.  The pmbus_core framework holds
pmbus_lock around its own multi-transaction sequences (notably the
"set PAGE, then read paged register" pattern used by hwmon
attributes), so an unlocked GPIO accessor can land between a PAGE
write and the subsequent paged read in another thread and corrupt
either side's view of the device state machine.

Take pmbus_lock at the top of each of the three accessors via the
scope-based guard().  The lock is uncontended in the common case and
adds only a single mutex round-trip per call.

Fixes: d98dfad35c38 ("hwmon: (pmbus/adm1266) Add support for GPIOs")
Cc: stable@vger.kernel.org
Signed-off-by: Abdurrahman Hussain &lt;abdurrahman@nexthop.ai&gt;
Reviewed-by: Bartosz Golaszewski &lt;bartosz.golaszewski@oss.qualcomm.com&gt;
Link: https://lore.kernel.org/r/20260518-adm1266-gpio-fixes-v3-6-e425e4f88139@nexthop.ai
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>hwmon: (pmbus/adm1266) serialize sequencer_state debugfs read with pmbus_lock</title>
<updated>2026-06-09T10:32:50+00:00</updated>
<author>
<name>Abdurrahman Hussain</name>
<email>abdurrahman@nexthop.ai</email>
</author>
<published>2026-06-01T12:37:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=75dcee5b34fa70cccde7608cfae4573e0eb0fd53'/>
<id>urn:sha1:75dcee5b34fa70cccde7608cfae4573e0eb0fd53</id>
<content type='text'>
[ Upstream commit 4e4af55aaca7f6d7673d5f9889ad0529db86a048 ]

adm1266_state_read() backs the sequencer_state debugfs entry and
issues an i2c_smbus_read_word_data(client, ADM1266_READ_STATE)
against the device without taking pmbus_lock.  pmbus_core holds
pmbus_lock around its own multi-transaction sequences (notably the
"set PAGE, then read paged register" pattern used by hwmon
attributes), so an unlocked debugfs reader can land between a PAGE
write and the subsequent paged read in another thread.  READ_STATE
itself is not paged, so it cannot corrupt PAGE in flight, but the
same defensive serialisation that applies to the GPIO accessors
applies here: any direct device access from outside pmbus_core
should be ordered with respect to pmbus_core's own.

Take pmbus_lock at the top of adm1266_state_read() via the
scope-based guard().

Fixes: ed1ff457e187 ("hwmon: (pmbus/adm1266) add debugfs for states")
Cc: stable@vger.kernel.org
Signed-off-by: Abdurrahman Hussain &lt;abdurrahman@nexthop.ai&gt;
Link: https://lore.kernel.org/r/20260518-adm1266-gpio-fixes-v3-8-e425e4f88139@nexthop.ai
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
