<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/firmware, branch v6.5.9</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.5.9</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.5.9'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2023-10-25T10:16:30Z</updated>
<entry>
<title>efi/unaccepted: Fix soft lockups caused by parallel memory acceptance</title>
<updated>2023-10-25T10:16:30Z</updated>
<author>
<name>Kirill A. Shutemov</name>
<email>kirill.shutemov@linux.intel.com</email>
</author>
<published>2023-10-16T16:31:22Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b583bfcc5a36dbd1db1984dbfcfd23ba64d23604'/>
<id>urn:sha1:b583bfcc5a36dbd1db1984dbfcfd23ba64d23604</id>
<content type='text'>
[ Upstream commit 50e782a86c980d4f8292ef82ed8139282ca07a98 ]

Michael reported soft lockups on a system that has unaccepted memory.
This occurs when a user attempts to allocate and accept memory on
multiple CPUs simultaneously.

The root cause of the issue is that memory acceptance is serialized with
a spinlock, allowing only one CPU to accept memory at a time. The other
CPUs spin and wait for their turn, leading to starvation and soft lockup
reports.

To address this, the code has been modified to release the spinlock
while accepting memory. This allows for parallel memory acceptance on
multiple CPUs.

A newly introduced "accepting_list" keeps track of which memory is
currently being accepted. This is necessary to prevent parallel
acceptance of the same memory block. If a collision occurs, the lock is
released and the process is retried.

Such collisions should rarely occur. The main path for memory acceptance
is the page allocator, which accepts memory in MAX_ORDER chunks. As long
as MAX_ORDER is equal to or larger than the unit_size, collisions will
never occur because the caller fully owns the memory block being
accepted.

Aside from the page allocator, only memblock and deferered_free_range()
accept memory, but this only happens during boot.

The code has been tested with unit_size == 128MiB to trigger collisions
and validate the retry codepath.

Fixes: 2053bc57f367 ("efi: Add unaccepted memory support")
Signed-off-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Reported-by: Michael Roth &lt;michael.roth@amd.com
Reviewed-by: Nikolay Borisov &lt;nik.borisov@suse.com&gt;
Reviewed-by: Vlastimil Babka &lt;vbabka@suse.cz&gt;
Tested-by: Michael Roth &lt;michael.roth@amd.com&gt;
[ardb: drop unnecessary cpu_relax() call]
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>firmware: cirrus: cs_dsp: Only log list of algorithms in debug build</title>
<updated>2023-10-06T11:16:15Z</updated>
<author>
<name>Richard Fitzgerald</name>
<email>rf@opensource.cirrus.com</email>
</author>
<published>2023-09-13T16:05:23Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=12bf8311da03b10d62d762e3cb21a6071574159d'/>
<id>urn:sha1:12bf8311da03b10d62d762e3cb21a6071574159d</id>
<content type='text'>
[ Upstream commit 69343ce91435f222052015c5af86b550391bac85 ]

Change the logging of each algorithm from info level to debug level.

On the original devices supported by this code there were typically only
one or two algorithms in a firmware and one or two DSPs so this logging
only used a small number of log lines.

However, for the latest devices there could be 30-40 algorithms in a
firmware and 8 DSPs being loaded in parallel, so using 300+ lines of log
for information that isn't particularly important to have logged.

Signed-off-by: Richard Fitzgerald &lt;rf@opensource.cirrus.com&gt;
Link: https://lore.kernel.org/r/20230913160523.3701189-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>firmware: arm_ffa: Don't set the memory region attributes for MEM_LEND</title>
<updated>2023-10-06T11:16:06Z</updated>
<author>
<name>Sudeep Holla</name>
<email>sudeep.holla@arm.com</email>
</author>
<published>2023-09-19T17:41:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0f61048992cee35bad7ab5abf0d3ac8a6e7a9b00'/>
<id>urn:sha1:0f61048992cee35bad7ab5abf0d3ac8a6e7a9b00</id>
<content type='text'>
[ Upstream commit 9dda1178479aa0a73fe0eaabfe2d9a1c603cfeed ]

As per the FF-A specification: section "Usage of other memory region
attributes", in a transaction to donate memory or lend memory to a single
borrower, if the receiver is a PE or Proxy endpoint, the owner must not
specify the attributes and the relayer will return INVALID_PARAMETERS
if the attributes are set.

Let us not set the memory region attributes for MEM_LEND.

Fixes: 82a8daaecfd9 ("firmware: arm_ffa: Add support for MEM_LEND")
Reported-by: Joao Alves &lt;joao.alves@arm.com&gt;
Reported-by: Olivier Deprez &lt;olivier.deprez@arm.com&gt;
Link: https://lore.kernel.org/r/20230919-ffa_v1-1_notif-v2-13-6f3a3ca3923c@arm.com
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>firmware: imx-dsp: Fix an error handling path in imx_dsp_setup_channels()</title>
<updated>2023-10-06T11:16:04Z</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2023-01-15T18:13:46Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=50d14cd5a67e3120e18baf3cf6c7b70db2f90027'/>
<id>urn:sha1:50d14cd5a67e3120e18baf3cf6c7b70db2f90027</id>
<content type='text'>
[ Upstream commit e527adfb9b7d9d05a4577c116519e59a2bda4b05 ]

If mbox_request_channel_byname() fails, the memory allocated a few lines
above still need to be freed before going to the error handling path.

Fixes: 046326989a18 ("firmware: imx: Save channel name for further use")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Reviewed-by: Daniel Baluta &lt;daniel.baluta@nxp.com&gt;
Signed-off-by: Shawn Guo &lt;shawnguo@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>firmware: arm_scmi: Fixup perf power-cost/microwatt support</title>
<updated>2023-10-06T11:16:02Z</updated>
<author>
<name>Sibi Sankar</name>
<email>quic_sibis@quicinc.com</email>
</author>
<published>2023-08-11T20:48:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3aeffe442077544573e2a0b5548eec2dda8b91c2'/>
<id>urn:sha1:3aeffe442077544573e2a0b5548eec2dda8b91c2</id>
<content type='text'>
[ Upstream commit c3638b851bc1ca0022dca9d6ca4beaa6ef03a216 ]

The perf power scale value would currently be reported as bogowatts if the
platform firmware supports microwatt power scale and meets the perf major
version requirements. Fix this by populating version information in the
driver private data before the call to protocol attributes is made.

CC: Chandra Sekhar Lingutla &lt;quic_lingutla@quicinc.com&gt;
Fixes: 3630cd8130ce ("firmware: arm_scmi: Add SCMI v3.1 perf power-cost in microwatts")
Signed-off-by: Sibi Sankar &lt;quic_sibis@quicinc.com&gt;
Reviewed-by: Cristian Marussi &lt;cristian.marussi@arm.com&gt;
Link: https://lore.kernel.org/r/20230811204818.30928-1-quic_sibis@quicinc.com
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>firmware: arm_scmi: Harden perf domain info access</title>
<updated>2023-10-06T11:16:02Z</updated>
<author>
<name>Cristian Marussi</name>
<email>cristian.marussi@arm.com</email>
</author>
<published>2023-07-17T16:12:45Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a6575f349ffa0aa9fa16769c1972a9ba7a6abe96'/>
<id>urn:sha1:a6575f349ffa0aa9fa16769c1972a9ba7a6abe96</id>
<content type='text'>
[ Upstream commit 3da82112355bba263597fcbb24d275fc57e69e7e ]

Harden internal accesses to domain info in the SCMI perf protocol.

Signed-off-by: Cristian Marussi &lt;cristian.marussi@arm.com&gt;
Link: https://lore.kernel.org/r/20230717161246.1761777-2-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Stable-dep-of: c3638b851bc1 ("firmware: arm_scmi: Fixup perf power-cost/microwatt support")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: sdei: abort running SDEI handlers during crash</title>
<updated>2023-09-13T07:53:55Z</updated>
<author>
<name>D Scott Phillips</name>
<email>scott@os.amperecomputing.com</email>
</author>
<published>2023-06-27T00:29:39Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4ed3664fbc7ab23fed55b6a1f2dd6af71ff7e51d'/>
<id>urn:sha1:4ed3664fbc7ab23fed55b6a1f2dd6af71ff7e51d</id>
<content type='text'>
commit 5cd474e57368f0957c343bb21e309cf82826b1ef upstream.

Interrupts are blocked in SDEI context, per the SDEI spec: "The client
interrupts cannot preempt the event handler." If we crashed in the SDEI
handler-running context (as with ACPI's AGDI) then we need to clean up the
SDEI state before proceeding to the crash kernel so that the crash kernel
can have working interrupts.

Track the active SDEI handler per-cpu so that we can COMPLETE_AND_RESUME
the handler, discarding the interrupted context.

Fixes: f5df26961853 ("arm64: kernel: Add arch-specific SDEI entry code and CPU masking")
Signed-off-by: D Scott Phillips &lt;scott@os.amperecomputing.com&gt;
Cc: stable@vger.kernel.org
Reviewed-by: James Morse &lt;james.morse@arm.com&gt;
Tested-by: Mihai Carabas &lt;mihai.carabas@oracle.com&gt;
Link: https://lore.kernel.org/r/20230627002939.2758-1-scott@os.amperecomputing.com
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>firmware: cs_dsp: Fix new control name check</title>
<updated>2023-09-13T07:53:26Z</updated>
<author>
<name>Vlad Karpovich</name>
<email>vkarpovi@opensource.cirrus.com</email>
</author>
<published>2023-08-15T17:29:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=02c126aa0b33ccf9e3c9b7cc5e436e3ccf564be9'/>
<id>urn:sha1:02c126aa0b33ccf9e3c9b7cc5e436e3ccf564be9</id>
<content type='text'>
[ Upstream commit 7ac1102b227b36550452b663fd39ab1c09378a95 ]

Before adding a new FW control, its name is checked against
existing controls list. But the string length in strncmp used
to compare controls names is taken from the list, so if beginnings
of the controls are matching,  then the new control is not created.
For example, if CAL_R control already exists, CAL_R_SELECTED
is not created.
The fix is to compare string lengths as well.

Fixes: 6477960755fb ("ASoC: wm_adsp: Move check for control existence")
Signed-off-by: Vlad Karpovich &lt;vkarpovi@opensource.cirrus.com&gt;
Link: https://lore.kernel.org/r/20230815172908.3454056-1-vkarpovi@opensource.cirrus.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>firmware: meson_sm: fix to avoid potential NULL pointer dereference</title>
<updated>2023-09-13T07:53:22Z</updated>
<author>
<name>Zhang Shurong</name>
<email>zhang_shurong@foxmail.com</email>
</author>
<published>2023-07-15T14:13:38Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2d6c4a1a4e6678cb98dd57964f133a995ecc91c1'/>
<id>urn:sha1:2d6c4a1a4e6678cb98dd57964f133a995ecc91c1</id>
<content type='text'>
[ Upstream commit f2ed165619c16577c02b703a114a1f6b52026df4 ]

of_match_device() may fail and returns a NULL pointer.

Fix this by checking the return value of of_match_device.

Fixes: 8cde3c2153e8 ("firmware: meson_sm: Rework driver as a proper platform driver")
Signed-off-by: Zhang Shurong &lt;zhang_shurong@foxmail.com&gt;
Reviewed-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Link: https://lore.kernel.org/r/tencent_AA08AAA6C4F34D53ADCE962E188A879B8206@qq.com
Signed-off-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>firmware: ti_sci: Use system_state to determine polling</title>
<updated>2023-09-13T07:53:16Z</updated>
<author>
<name>Nishanth Menon</name>
<email>nm@ti.com</email>
</author>
<published>2023-06-20T13:03:29Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9d7db065a205ac902dbc0f18693b64ed34f8a719'/>
<id>urn:sha1:9d7db065a205ac902dbc0f18693b64ed34f8a719</id>
<content type='text'>
[ Upstream commit 9225bcdedf16297a346082e7d23b0e8434aa98ed ]

Commit b9e8a7d950ff ("firmware: ti_sci: Switch transport to polled
mode during system suspend") aims to resolve issues with tisci
operations during system suspend operation. However, the system may
enter a no_irq stage in various other usage modes, including power-off
and restart. To determine if polling mode is appropriate, use the
system_state instead.

While at this, drop the unused is_suspending state variable and
related helpers.

Fixes: b9e8a7d950ff ("firmware: ti_sci: Switch transport to polled mode during system suspend")
Reported-by: Francesco Dolcini &lt;francesco@dolcini.it&gt;
Reported-by: Wadim Egorov &lt;w.egorov@phytec.de&gt;
Tested-by: Francesco Dolcini &lt;francesco.dolcini@toradex.com&gt; # Toradex Verdin AM62
Link: https://lore.kernel.org/r/20230620130329.4120443-1-nm@ti.com
Closes: https://lore.kernel.org/all/ZGeHMjlnob2GFyHF@francesco-nb.int.toradex.com/
Signed-off-by: Nishanth Menon &lt;nm@ti.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
