<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/firmware, branch v7.1.6</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>firmware: stratix10-svc: handle NO_RESPONSE in async poll</title>
<updated>2026-08-03T09:25:52+00:00</updated>
<author>
<name>Adrian Ng Ho Yin</name>
<email>adrian.ho.yin.ng@altera.com</email>
</author>
<published>2026-07-14T05:37:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b5ed54a37ad54663692a89b7b0be894cdaf06bad'/>
<id>b5ed54a37ad54663692a89b7b0be894cdaf06bad</id>
<content type='text'>
commit 9e1dc434ca708e1134332e45918935752f4410cd upstream.

Define INTEL_SIP_SMC_STATUS_NO_RESPONSE (0x3) and handle it in
stratix10_svc_async_poll() the same way as INTEL_SIP_SMC_STATUS_BUSY,
returning -EAGAIN so callers can retry instead of treating the poll as
a hard failure.

When the Secure Device Manager has not yet produced a response for an
asynchronous transaction, ATF is expected to return
INTEL_SIP_SMC_STATUS_NO_RESPONSE. Without this handling, the service
layer maps the status to -EINVAL and async clients cannot distinguish
"not ready yet" from a real error.

Fixes: bcb9f4f07061 ("firmware: stratix10-svc: Add support for async communication")
Cc: stable@vger.kernel.org
Signed-off-by: Adrian Ng Ho Yin &lt;adrian.ho.yin.ng@altera.com&gt;
Signed-off-by: Dinh Nguyen &lt;dinguyen@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9e1dc434ca708e1134332e45918935752f4410cd upstream.

Define INTEL_SIP_SMC_STATUS_NO_RESPONSE (0x3) and handle it in
stratix10_svc_async_poll() the same way as INTEL_SIP_SMC_STATUS_BUSY,
returning -EAGAIN so callers can retry instead of treating the poll as
a hard failure.

When the Secure Device Manager has not yet produced a response for an
asynchronous transaction, ATF is expected to return
INTEL_SIP_SMC_STATUS_NO_RESPONSE. Without this handling, the service
layer maps the status to -EINVAL and async clients cannot distinguish
"not ready yet" from a real error.

Fixes: bcb9f4f07061 ("firmware: stratix10-svc: Add support for async communication")
Cc: stable@vger.kernel.org
Signed-off-by: Adrian Ng Ho Yin &lt;adrian.ho.yin.ng@altera.com&gt;
Signed-off-by: Dinh Nguyen &lt;dinguyen@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: stratix10-svc: fix teardown order in remove to prevent race</title>
<updated>2026-08-03T09:25:52+00:00</updated>
<author>
<name>Adrian Ng Ho Yin</name>
<email>adrian.ho.yin.ng@altera.com</email>
</author>
<published>2026-07-14T05:37:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7b14f42c746087485384684bcd2715b4c999e238'/>
<id>7b14f42c746087485384684bcd2715b4c999e238</id>
<content type='text'>
commit bba85375f8751d6c949036269b529cdcb2a2ed8f upstream.

In stratix10_svc_drv_remove(), stratix10_svc_async_exit() was called
before client devices were unregistered. This created a race window
where child devices could still be issuing service requests through
the async channels after the async infrastructure had already been
torn down.

Unregister client devices before tearing down the async threads and
channels to ensure all in-flight service calls drain before the
underlying infrastructure is destroyed.

Fixes: bcb9f4f07061 ("firmware: stratix10-svc: Add support for async communication")
Cc: stable@vger.kernel.org
Signed-off-by: Adrian Ng Ho Yin &lt;adrian.ho.yin.ng@altera.com&gt;
Signed-off-by: Dinh Nguyen &lt;dinguyen@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bba85375f8751d6c949036269b529cdcb2a2ed8f upstream.

In stratix10_svc_drv_remove(), stratix10_svc_async_exit() was called
before client devices were unregistered. This created a race window
where child devices could still be issuing service requests through
the async channels after the async infrastructure had already been
torn down.

Unregister client devices before tearing down the async threads and
channels to ensure all in-flight service calls drain before the
underlying infrastructure is destroyed.

Fixes: bcb9f4f07061 ("firmware: stratix10-svc: Add support for async communication")
Cc: stable@vger.kernel.org
Signed-off-by: Adrian Ng Ho Yin &lt;adrian.ho.yin.ng@altera.com&gt;
Signed-off-by: Dinh Nguyen &lt;dinguyen@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: stratix10-svc: fix memory leaks and list corruption bugs</title>
<updated>2026-08-03T09:25:52+00:00</updated>
<author>
<name>Tze Yee Ng</name>
<email>tze.yee.ng@altera.com</email>
</author>
<published>2026-06-24T10:06:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8e93a083456d78f6b0aa1f58d2b0c7071a2a7a47'/>
<id>8e93a083456d78f6b0aa1f58d2b0c7071a2a7a47</id>
<content type='text'>
commit 9119ceb76e987c2ec2b549ea100e3268ce3a1c7c upstream.

Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error
path. Switch pmem allocation from devm_kzalloc() to kzalloc() with
explicit kfree() in the free path to match its list-managed lifetime.
Remove the erroneous list_del(&amp;svc_data_mem) which corrupted the list head
on failed lookups.

Fixes: 7ca5ce896524 ("firmware: add Intel Stratix10 service layer driver")
Cc: stable@vger.kernel.org # 5.0+
Signed-off-by: Tze Yee Ng &lt;tze.yee.ng@altera.com&gt;
Signed-off-by: Dinh Nguyen &lt;dinguyen@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9119ceb76e987c2ec2b549ea100e3268ce3a1c7c upstream.

Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error
path. Switch pmem allocation from devm_kzalloc() to kzalloc() with
explicit kfree() in the free path to match its list-managed lifetime.
Remove the erroneous list_del(&amp;svc_data_mem) which corrupted the list head
on failed lookups.

Fixes: 7ca5ce896524 ("firmware: add Intel Stratix10 service layer driver")
Cc: stable@vger.kernel.org # 5.0+
Signed-off-by: Tze Yee Ng &lt;tze.yee.ng@altera.com&gt;
Signed-off-by: Dinh Nguyen &lt;dinguyen@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: arm_scmi: Rate-limit queue-full warnings in IRQ context</title>
<updated>2026-08-03T09:25:20+00:00</updated>
<author>
<name>Pushpendra Singh</name>
<email>pushpendra.singh@oss.qualcomm.com</email>
</author>
<published>2026-07-08T07:23:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3c746522a41fc37b83628f54981bca14def709de'/>
<id>3c746522a41fc37b83628f54981bca14def709de</id>
<content type='text'>
[ Upstream commit a4447c0693830d5ecadd6e755cb7fdc55d86aacc ]

The scmi_notify() function is called from interrupt context to queue
received notification events onto a per-protocol kfifo. When the kfifo
is full, it logs a warning via dev_warn() for every dropped event.

Under conditions where the platform sends a burst of SCMI notifications
faster than the deferred worker can drain the queue, this results in a
flood of dev_warn() calls from IRQ context. Each call acquires the
console lock and may execute blocking console writes, causing the CPU
to be held in interrupt context for an extended period and leading to
observable system stalls.

Fix this by switching to dev_warn_ratelimited() to limit the frequency
of log messages when the notification queue is full. This reduces
console overhead in interrupt context and prevents CPU stalls caused by
excessive logging, while still preserving diagnostic visibility.

Fixes: bd31b249692e ("firmware: arm_scmi: Add notification dispatch and delivery")
Signed-off-by: Pushpendra Singh &lt;pushpendra.singh@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20260708072339.3021140-1-pushpendra.singh@oss.qualcomm.com
Signed-off-by: Sudeep Holla &lt;sudeep.holla@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit a4447c0693830d5ecadd6e755cb7fdc55d86aacc ]

The scmi_notify() function is called from interrupt context to queue
received notification events onto a per-protocol kfifo. When the kfifo
is full, it logs a warning via dev_warn() for every dropped event.

Under conditions where the platform sends a burst of SCMI notifications
faster than the deferred worker can drain the queue, this results in a
flood of dev_warn() calls from IRQ context. Each call acquires the
console lock and may execute blocking console writes, causing the CPU
to be held in interrupt context for an extended period and leading to
observable system stalls.

Fix this by switching to dev_warn_ratelimited() to limit the frequency
of log messages when the notification queue is full. This reduces
console overhead in interrupt context and prevents CPU stalls caused by
excessive logging, while still preserving diagnostic visibility.

Fixes: bd31b249692e ("firmware: arm_scmi: Add notification dispatch and delivery")
Signed-off-by: Pushpendra Singh &lt;pushpendra.singh@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20260708072339.3021140-1-pushpendra.singh@oss.qualcomm.com
Signed-off-by: Sudeep Holla &lt;sudeep.holla@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation</title>
<updated>2026-08-03T09:25:20+00:00</updated>
<author>
<name>Sebastian Ene</name>
<email>sebastianene@google.com</email>
</author>
<published>2026-07-02T10:38:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8ef18f0ab3c0ec1eac77289f5a542bd96a8a6d66'/>
<id>8ef18f0ab3c0ec1eac77289f5a542bd96a8a6d66</id>
<content type='text'>
[ Upstream commit b4d961351aa84fdf0148783fb1f3a1391b8a0adb ]

Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint
memory access array and to comply with the FF-A spec instead of defaulting
to `sizeof(struct ffa_mem_region)`.
This requires moving `ffa_mem_region_additional_setup()` earlier in the setup
flow.
Also, add sanity checks to ensure the calculated descriptor offsets do not
exceed `max_fragsize`.

Fixes: 113580530ee7 ("firmware: arm_ffa: Update memory descriptor to support v1.1 format")
Reviewed-by: Sudeep Holla &lt;sudeep.holla@kernel.org&gt;
Signed-off-by: Mostafa Saleh &lt;smostafa@google.com&gt;
Signed-off-by: Sebastian Ene &lt;sebastianene@google.com&gt;
Link: https://patch.msgid.link/20260702103848.1647249-3-sebastianene@google.com
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit b4d961351aa84fdf0148783fb1f3a1391b8a0adb ]

Use the descriptor's `ep_mem_offset` to calculate the start of the endpoint
memory access array and to comply with the FF-A spec instead of defaulting
to `sizeof(struct ffa_mem_region)`.
This requires moving `ffa_mem_region_additional_setup()` earlier in the setup
flow.
Also, add sanity checks to ensure the calculated descriptor offsets do not
exceed `max_fragsize`.

Fixes: 113580530ee7 ("firmware: arm_ffa: Update memory descriptor to support v1.1 format")
Reviewed-by: Sudeep Holla &lt;sudeep.holla@kernel.org&gt;
Signed-off-by: Mostafa Saleh &lt;smostafa@google.com&gt;
Signed-off-by: Sebastian Ene &lt;sebastianene@google.com&gt;
Link: https://patch.msgid.link/20260702103848.1647249-3-sebastianene@google.com
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit()</title>
<updated>2026-08-03T09:25:20+00:00</updated>
<author>
<name>Mostafa Saleh</name>
<email>smostafa@google.com</email>
</author>
<published>2026-07-02T10:38:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=27abdaf0c5c89b06694e4c3d8318e8d6a60c1d1b'/>
<id>27abdaf0c5c89b06694e4c3d8318e8d6a60c1d1b</id>
<content type='text'>
[ Upstream commit 3383ffb7ef937317361713ffcc21921a7848511a ]

Sashiko (locally) reports multiple out-of-bound issues in
ffa_setup_and_transmit:
1) Writing ep_mem_access-&gt;reserved can write out of bounds for FFA
   versions &lt; 1.2 as ffa_emad_size_get() returns 16 bytes in that case
   while reserved has an offset of 24.
   Instead of zeroing fields, memset the struct to zero first based on
   the FFA version.

2) Make sure there is enough size to write constituents.

While at it, convert the only sizeof() in the driver that uses a
type instead of variable.

Reviewed-by: Sudeep Holla &lt;sudeep.holla@kernel.org&gt;
Fixes: 111a833dc5cb ("firmware: arm_ffa: Set reserved/MBZ fields to zero in the memory descriptors")
Signed-off-by: Mostafa Saleh &lt;smostafa@google.com&gt;
Signed-off-by: Sebastian Ene &lt;sebastianene@google.com&gt;
Link: https://patch.msgid.link/20260702103848.1647249-2-sebastianene@google.com
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3383ffb7ef937317361713ffcc21921a7848511a ]

Sashiko (locally) reports multiple out-of-bound issues in
ffa_setup_and_transmit:
1) Writing ep_mem_access-&gt;reserved can write out of bounds for FFA
   versions &lt; 1.2 as ffa_emad_size_get() returns 16 bytes in that case
   while reserved has an offset of 24.
   Instead of zeroing fields, memset the struct to zero first based on
   the FFA version.

2) Make sure there is enough size to write constituents.

While at it, convert the only sizeof() in the driver that uses a
type instead of variable.

Reviewed-by: Sudeep Holla &lt;sudeep.holla@kernel.org&gt;
Fixes: 111a833dc5cb ("firmware: arm_ffa: Set reserved/MBZ fields to zero in the memory descriptors")
Signed-off-by: Mostafa Saleh &lt;smostafa@google.com&gt;
Signed-off-by: Sebastian Ene &lt;sebastianene@google.com&gt;
Link: https://patch.msgid.link/20260702103848.1647249-2-sebastianene@google.com
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()</title>
<updated>2026-08-03T09:25:17+00:00</updated>
<author>
<name>Unnathi Chalicheemala</name>
<email>unnathi.chalicheemala@oss.qualcomm.com</email>
</author>
<published>2026-06-17T23:35:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=12a42c610e4432e7708cc48d607e5903fffe0aad'/>
<id>12a42c610e4432e7708cc48d607e5903fffe0aad</id>
<content type='text'>
[ Upstream commit 8ae5f8e4836667fcaffdf2e3c6068b0a8b364dd8 ]

ffa_partition_info_get() passes uuid_str directly to uuid_parse()
without a NULL check. When a caller passes NULL, uuid_parse() -&gt;
__uuid_parse() -&gt; uuid_is_valid() dereferences the pointer, causing
a kernel panic:

  |  Unable to handle kernel NULL pointer dereference at virtual address
  |  0000000000000040
  |  pc : uuid_parse+0x40/0xac
  |  lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa]

Add a NULL guard before uuid_parse() so a NULL argument returns
-ENODEV instead of crashing. Callers are expected to always supply
a valid partition UUID, so NULL is not a supported input.

Fixes: d0c0bce83122 ("firmware: arm_ffa: Setup in-kernel users of FFA partitions")
Signed-off-by: Unnathi Chalicheemala &lt;unnathi.chalicheemala@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20260617-ffa_partition_nullptr_fix-v2-1-bc801b4ce34c@oss.qualcomm.com
Signed-off-by: Sudeep Holla &lt;sudeep.holla@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 8ae5f8e4836667fcaffdf2e3c6068b0a8b364dd8 ]

ffa_partition_info_get() passes uuid_str directly to uuid_parse()
without a NULL check. When a caller passes NULL, uuid_parse() -&gt;
__uuid_parse() -&gt; uuid_is_valid() dereferences the pointer, causing
a kernel panic:

  |  Unable to handle kernel NULL pointer dereference at virtual address
  |  0000000000000040
  |  pc : uuid_parse+0x40/0xac
  |  lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa]

Add a NULL guard before uuid_parse() so a NULL argument returns
-ENODEV instead of crashing. Callers are expected to always supply
a valid partition UUID, so NULL is not a supported input.

Fixes: d0c0bce83122 ("firmware: arm_ffa: Setup in-kernel users of FFA partitions")
Signed-off-by: Unnathi Chalicheemala &lt;unnathi.chalicheemala@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20260617-ffa_partition_nullptr_fix-v2-1-bc801b4ce34c@oss.qualcomm.com
Signed-off-by: Sudeep Holla &lt;sudeep.holla@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: arm_ffa: Respect firmware advertised RX/TX buffer size limits</title>
<updated>2026-08-03T09:25:16+00:00</updated>
<author>
<name>Seth Forshee</name>
<email>sforshee@nvidia.com</email>
</author>
<published>2026-06-02T21:54:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bd2a4483a863478ce9250a0d98e53658b00c4930'/>
<id>bd2a4483a863478ce9250a0d98e53658b00c4930</id>
<content type='text'>
[ Upstream commit 53716a4d745f1dac7aff33f3d1494b701eb2f888 ]

FFA_FEATURES reports the minimum size and alignment boundary required
for RXTX_MAP. In FF-A v1.2 and later it can also report a maximum buffer
size, with zero meaning that no maximum is enforced.

The driver only used the minimum value and then rounded it up to PAGE_SIZE
before invoking RXTX_MAP after commit 83210251fd70 ("firmware: arm_ffa:
Use the correct buffer size during RXTX_MAP"). On systems where PAGE_SIZE
is larger than the advertised minimum, this can exceed a non-zero maximum
reported by firmware. Older implementations do not advertise a maximum and
may also reject the rounded-up size.

Decode the maximum size and clamp the page-aligned minimum to it when it
is present. If no maximum is advertised and RXTX_MAP rejects the rounded
size with INVALID_PARAMETERS, retry with the advertised minimum size.
Record drv_info-&gt;rxtx_bufsz only after RXTX_MAP succeeds so it reflects
the size registered with firmware.

While there, also update RXTX_MAP_MIN_BUFSZ() to use FIELD_GET() for
consistency.

Fixes: 83210251fd70 ("firmware: arm_ffa: Use the correct buffer size during RXTX_MAP")
Suggested-by: Sudeep Holla &lt;sudeep.holla@kernel.org&gt;
Signed-off-by: Seth Forshee &lt;sforshee@nvidia.com&gt;
Link: https://patch.msgid.link/20260602-b4-ffa-rxtx-map-fixes-v2-1-7cb06508da84@nvidia.com
(sudeep.holla: Minor rewording subject and commit message)
Signed-off-by: Sudeep Holla &lt;sudeep.holla@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 53716a4d745f1dac7aff33f3d1494b701eb2f888 ]

FFA_FEATURES reports the minimum size and alignment boundary required
for RXTX_MAP. In FF-A v1.2 and later it can also report a maximum buffer
size, with zero meaning that no maximum is enforced.

The driver only used the minimum value and then rounded it up to PAGE_SIZE
before invoking RXTX_MAP after commit 83210251fd70 ("firmware: arm_ffa:
Use the correct buffer size during RXTX_MAP"). On systems where PAGE_SIZE
is larger than the advertised minimum, this can exceed a non-zero maximum
reported by firmware. Older implementations do not advertise a maximum and
may also reject the rounded-up size.

Decode the maximum size and clamp the page-aligned minimum to it when it
is present. If no maximum is advertised and RXTX_MAP rejects the rounded
size with INVALID_PARAMETERS, retry with the advertised minimum size.
Record drv_info-&gt;rxtx_bufsz only after RXTX_MAP succeeds so it reflects
the size registered with firmware.

While there, also update RXTX_MAP_MIN_BUFSZ() to use FIELD_GET() for
consistency.

Fixes: 83210251fd70 ("firmware: arm_ffa: Use the correct buffer size during RXTX_MAP")
Suggested-by: Sudeep Holla &lt;sudeep.holla@kernel.org&gt;
Signed-off-by: Seth Forshee &lt;sforshee@nvidia.com&gt;
Link: https://patch.msgid.link/20260602-b4-ffa-rxtx-map-fixes-v2-1-7cb06508da84@nvidia.com
(sudeep.holla: Minor rewording subject and commit message)
Signed-off-by: Sudeep Holla &lt;sudeep.holla@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>remoteproc: xlnx: Check remote core state</title>
<updated>2026-07-24T14:20:57+00:00</updated>
<author>
<name>Tanmay Shah</name>
<email>tanmay.shah@amd.com</email>
</author>
<published>2026-04-28T22:18:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f80fafe24f7221bfd1108b752108c1fcc6528fca'/>
<id>f80fafe24f7221bfd1108b752108c1fcc6528fca</id>
<content type='text'>
commit a48df51d23138388900995add2854cda4aa68e55 upstream.

The remote state is set to RPROC_DETACHED if the resource table is found
in the memory. However, this can be wrong if the remote is not started,
but firmware is still loaded in the memory. Use PM_GET_NODE_STATUS call
to the firmware to request the state of the RPU node. If the RPU is
actually out of reset and running, only then move the remote state to
RPROC_DETACHED, otherwise keep the remote state to RPROC_OFFLINE.

Signed-off-by: Tanmay Shah &lt;tanmay.shah@amd.com&gt;
Fixes: bca4b02ef92e ("remoteproc: xlnx: Add attach detach support")
Reviewed-by: Beleswar Padhi &lt;b-padhi@ti.com&gt;
Acked-by: Michal Simek &lt;michal.simek@amd.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20260428221855.313752-1-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier &lt;mathieu.poirier@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a48df51d23138388900995add2854cda4aa68e55 upstream.

The remote state is set to RPROC_DETACHED if the resource table is found
in the memory. However, this can be wrong if the remote is not started,
but firmware is still loaded in the memory. Use PM_GET_NODE_STATUS call
to the firmware to request the state of the RPU node. If the RPU is
actually out of reset and running, only then move the remote state to
RPROC_DETACHED, otherwise keep the remote state to RPROC_OFFLINE.

Signed-off-by: Tanmay Shah &lt;tanmay.shah@amd.com&gt;
Fixes: bca4b02ef92e ("remoteproc: xlnx: Add attach detach support")
Reviewed-by: Beleswar Padhi &lt;b-padhi@ti.com&gt;
Acked-by: Michal Simek &lt;michal.simek@amd.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20260428221855.313752-1-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier &lt;mathieu.poirier@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: samsung: acpm: Add devm_acpm_get_by_phandle helper</title>
<updated>2026-07-24T14:19:24+00:00</updated>
<author>
<name>Tudor Ambarus</name>
<email>tudor.ambarus@linaro.org</email>
</author>
<published>2026-05-15T09:32:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=75c70913d30c3b3c395a4efa0d8c0e9c90553fa7'/>
<id>75c70913d30c3b3c395a4efa0d8c0e9c90553fa7</id>
<content type='text'>
[ Upstream commit fc13a4b9b9c8cb0b8e5ba54b21712d00f810496c ]

Introduce devm_acpm_get_by_phandle() to standardize how consumer
drivers acquire a handle to the ACPM IPC interface. Enforce the
use of the "samsung,acpm-ipc" property name across the SoC and
simplify the boilerplate code in client drivers.

The first consumer of this helper is the Exynos ACPM Thermal Management
Unit (TMU) driver. The TMU utilizes a hybrid management approach: direct
register access from the Application Processor (AP) is restricted to the
interrupt pending (INTPEND) registers for event identification.
High-level functional tasks, such as sensor initialization, threshold
programming, and temperature reads, are delegated to the ACPM firmware
via this IPC interface.

Signed-off-by: Tudor Ambarus &lt;tudor.ambarus@linaro.org&gt;
Reviewed-by: Peter Griffin &lt;peter.griffin@linaro.org&gt;
Link: https://patch.msgid.link/20260515-acpm-tmu-helpers-v2-6-8ca011d5a965@linaro.org
Signed-off-by: Krzysztof Kozlowski &lt;krzk@kernel.org&gt;
Stable-dep-of: 7b661285aa75 ("firmware: samsung: acpm: remove compile-testing stubs")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit fc13a4b9b9c8cb0b8e5ba54b21712d00f810496c ]

Introduce devm_acpm_get_by_phandle() to standardize how consumer
drivers acquire a handle to the ACPM IPC interface. Enforce the
use of the "samsung,acpm-ipc" property name across the SoC and
simplify the boilerplate code in client drivers.

The first consumer of this helper is the Exynos ACPM Thermal Management
Unit (TMU) driver. The TMU utilizes a hybrid management approach: direct
register access from the Application Processor (AP) is restricted to the
interrupt pending (INTPEND) registers for event identification.
High-level functional tasks, such as sensor initialization, threshold
programming, and temperature reads, are delegated to the ACPM firmware
via this IPC interface.

Signed-off-by: Tudor Ambarus &lt;tudor.ambarus@linaro.org&gt;
Reviewed-by: Peter Griffin &lt;peter.griffin@linaro.org&gt;
Link: https://patch.msgid.link/20260515-acpm-tmu-helpers-v2-6-8ca011d5a965@linaro.org
Signed-off-by: Krzysztof Kozlowski &lt;krzk@kernel.org&gt;
Stable-dep-of: 7b661285aa75 ("firmware: samsung: acpm: remove compile-testing stubs")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
