<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/mailbox, branch linux-6.14.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>mailbox: use error ret code of of_parse_phandle_with_args()</title>
<updated>2025-05-29T09:12:25+00:00</updated>
<author>
<name>Tudor Ambarus</name>
<email>tudor.ambarus@linaro.org</email>
</author>
<published>2025-02-24T08:27:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3531ead00c8921daea94c2d3d0103f36ad387b32'/>
<id>3531ead00c8921daea94c2d3d0103f36ad387b32</id>
<content type='text'>
[ Upstream commit 24fdd5074b205cfb0ef4cd0751a2d03031455929 ]

In case of error, of_parse_phandle_with_args() returns -EINVAL when the
passed index is negative, or -ENOENT when the index is for an empty
phandle. The mailbox core overwrote the error return code with a less
precise -ENODEV. Use the error returned code from
of_parse_phandle_with_args().

Signed-off-by: Tudor Ambarus &lt;tudor.ambarus@linaro.org&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&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 24fdd5074b205cfb0ef4cd0751a2d03031455929 ]

In case of error, of_parse_phandle_with_args() returns -EINVAL when the
passed index is negative, or -ENOENT when the index is for an empty
phandle. The mailbox core overwrote the error return code with a less
precise -ENODEV. Use the error returned code from
of_parse_phandle_with_args().

Signed-off-by: Tudor Ambarus &lt;tudor.ambarus@linaro.org&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mailbox: pcc: Use acpi_os_ioremap() instead of ioremap()</title>
<updated>2025-05-29T09:12:25+00:00</updated>
<author>
<name>Sudeep Holla</name>
<email>sudeep.holla@arm.com</email>
</author>
<published>2025-03-13T15:28:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3b5d1316fab3cfcd0dd9ed4cafe077c4ef1b7a16'/>
<id>3b5d1316fab3cfcd0dd9ed4cafe077c4ef1b7a16</id>
<content type='text'>
[ Upstream commit d181acea5b864e91f38f5771b8961215ce5017ae ]

The Platform Communication Channel (PCC) mailbox driver currently uses
ioremap() to map channel shared memory regions. However it is preferred
to use acpi_os_ioremap(), which is mapping function specific to EFI/ACPI
defined memory regions. It ensures that the correct memory attributes
are applied when mapping ACPI-provided regions.

While at it, also add checks for handling any errors with the mapping.

Acked-by: Huisong Li &lt;lihuisong@huawei.com&gt;
Tested-by: Huisong Li &lt;lihuisong@huawei.com&gt;
Tested-by: Adam Young &lt;admiyo@os.amperecomputing.com&gt;
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&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 d181acea5b864e91f38f5771b8961215ce5017ae ]

The Platform Communication Channel (PCC) mailbox driver currently uses
ioremap() to map channel shared memory regions. However it is preferred
to use acpi_os_ioremap(), which is mapping function specific to EFI/ACPI
defined memory regions. It ensures that the correct memory attributes
are applied when mapping ACPI-provided regions.

While at it, also add checks for handling any errors with the mapping.

Acked-by: Huisong Li &lt;lihuisong@huawei.com&gt;
Tested-by: Huisong Li &lt;lihuisong@huawei.com&gt;
Tested-by: Adam Young &lt;admiyo@os.amperecomputing.com&gt;
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mailbox: pcc: Always clear the platform ack interrupt first</title>
<updated>2025-05-02T06:01:59+00:00</updated>
<author>
<name>Sudeep Holla</name>
<email>sudeep.holla@arm.com</email>
</author>
<published>2025-03-13T15:28:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e6482cd66600bfe2e33a1b05423a3eef3a28edb1'/>
<id>e6482cd66600bfe2e33a1b05423a3eef3a28edb1</id>
<content type='text'>
[ Upstream commit cf1338c0e02880cd235a4590eeb15e2039c873bc ]

The PCC mailbox interrupt handler (pcc_mbox_irq()) currently checks
for command completion flags and any error status before clearing the
interrupt.

The below sequence highlights an issue in the handling of PCC mailbox
interrupts, specifically when dealing with doorbell notifications and
acknowledgment between the OSPM and the platform where type3 and type4
channels are sharing the interrupt.

-------------------------------------------------------------------------
| T |       Platform Firmware         |    OSPM/Linux PCC driver        |
|---|---------------------------------|---------------------------------|
| 1 |                                 | Build message in shmem          |
| 2 |                                 | Ring Type3 chan doorbell        |
| 3 | Receives the doorbell interrupt |                                 |
| 4 | Process the message from OSPM   |                                 |
| 5 | Build response for the message  |                                 |
| 6 | Ring Platform ACK interrupt on  |                                 |
|   |  Type3 chan to OSPM             | Received the interrupt          |
| 7 | Build Notification in Type4 Chan|                                 |
| 8 |                                 | Start processing interrupt in   |
|   |                                 |  pcc_mbox_irq() handler         |
| 9 |                                 | Enter PCC handler for Type4 chan|
|10 |                                 | Check command complete cleared  |
|11 |                                 | Read the notification           |
|12 |                                 | Clear Platform ACK interrupt    |
|   | No effect from the previous step yet as the Platform ACK          |
|   |  interrupt has not yet been triggered for this channel            |
|13 | Ring Platform ACK interrupt on  |                                 |
|   | Type4 chan to OSPM              |                                 |
|14 |                                 | Enter PCC handler for Type3 chan|
|15 |                                 | Command complete is set.        |
|16 |                                 | Read the response.              |
|17 |                                 | Clear Platform ACK interrupt    |
|18 |                                 | Leave PCC handler for Type3     |
|19 |                                 | Leave pcc_mbox_irq() handler    |
|20 |                                 | Re-enter pcc_mbox_irq() handler |
|21 |                                 | Enter PCC handler for Type4 chan|
|22 |                                 | Leave PCC handler for Type4 chan|
|23 |                                 | Enter PCC handler for Type3 chan|
|24 |                                 | Leave PCC handler for Type3 chan|
|25 |                                 | Leave pcc_mbox_irq() handler    |
-------------------------------------------------------------------------

The key issue occurs when OSPM tries to acknowledge platform ack
interrupt for a notification which is ready to be read and processed
but the interrupt itself is not yet triggered by the platform.

This ineffective acknowledgment leads to an issue later in time where
the interrupt remains pending as we exit the interrupt handler without
clearing the platform ack interrupt as there is no pending response or
notification. The interrupt acknowledgment order is incorrect.

To resolve this issue, the platform acknowledgment interrupt should
always be cleared before processing the interrupt for any notifications
or response.

Reported-by: Robbie King &lt;robbiek@xsightlabs.com&gt;
Reviewed-by: Huisong Li &lt;lihuisong@huawei.com&gt;
Tested-by: Huisong Li &lt;lihuisong@huawei.com&gt;
Tested-by: Adam Young &lt;admiyo@os.amperecomputing.com&gt;
Tested-by: Robbie King &lt;robbiek@xsightlabs.com&gt;
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&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 cf1338c0e02880cd235a4590eeb15e2039c873bc ]

The PCC mailbox interrupt handler (pcc_mbox_irq()) currently checks
for command completion flags and any error status before clearing the
interrupt.

The below sequence highlights an issue in the handling of PCC mailbox
interrupts, specifically when dealing with doorbell notifications and
acknowledgment between the OSPM and the platform where type3 and type4
channels are sharing the interrupt.

-------------------------------------------------------------------------
| T |       Platform Firmware         |    OSPM/Linux PCC driver        |
|---|---------------------------------|---------------------------------|
| 1 |                                 | Build message in shmem          |
| 2 |                                 | Ring Type3 chan doorbell        |
| 3 | Receives the doorbell interrupt |                                 |
| 4 | Process the message from OSPM   |                                 |
| 5 | Build response for the message  |                                 |
| 6 | Ring Platform ACK interrupt on  |                                 |
|   |  Type3 chan to OSPM             | Received the interrupt          |
| 7 | Build Notification in Type4 Chan|                                 |
| 8 |                                 | Start processing interrupt in   |
|   |                                 |  pcc_mbox_irq() handler         |
| 9 |                                 | Enter PCC handler for Type4 chan|
|10 |                                 | Check command complete cleared  |
|11 |                                 | Read the notification           |
|12 |                                 | Clear Platform ACK interrupt    |
|   | No effect from the previous step yet as the Platform ACK          |
|   |  interrupt has not yet been triggered for this channel            |
|13 | Ring Platform ACK interrupt on  |                                 |
|   | Type4 chan to OSPM              |                                 |
|14 |                                 | Enter PCC handler for Type3 chan|
|15 |                                 | Command complete is set.        |
|16 |                                 | Read the response.              |
|17 |                                 | Clear Platform ACK interrupt    |
|18 |                                 | Leave PCC handler for Type3     |
|19 |                                 | Leave pcc_mbox_irq() handler    |
|20 |                                 | Re-enter pcc_mbox_irq() handler |
|21 |                                 | Enter PCC handler for Type4 chan|
|22 |                                 | Leave PCC handler for Type4 chan|
|23 |                                 | Enter PCC handler for Type3 chan|
|24 |                                 | Leave PCC handler for Type3 chan|
|25 |                                 | Leave pcc_mbox_irq() handler    |
-------------------------------------------------------------------------

The key issue occurs when OSPM tries to acknowledge platform ack
interrupt for a notification which is ready to be read and processed
but the interrupt itself is not yet triggered by the platform.

This ineffective acknowledgment leads to an issue later in time where
the interrupt remains pending as we exit the interrupt handler without
clearing the platform ack interrupt as there is no pending response or
notification. The interrupt acknowledgment order is incorrect.

To resolve this issue, the platform acknowledgment interrupt should
always be cleared before processing the interrupt for any notifications
or response.

Reported-by: Robbie King &lt;robbiek@xsightlabs.com&gt;
Reviewed-by: Huisong Li &lt;lihuisong@huawei.com&gt;
Tested-by: Huisong Li &lt;lihuisong@huawei.com&gt;
Tested-by: Adam Young &lt;admiyo@os.amperecomputing.com&gt;
Tested-by: Robbie King &lt;robbiek@xsightlabs.com&gt;
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mailbox: pcc: Fix the possible race in updation of chan_in_use flag</title>
<updated>2025-05-02T06:01:58+00:00</updated>
<author>
<name>Huisong Li</name>
<email>lihuisong@huawei.com</email>
</author>
<published>2025-03-13T15:28:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9dbb80291cb75fbbe2e60dc2766e4d89c83e1273'/>
<id>9dbb80291cb75fbbe2e60dc2766e4d89c83e1273</id>
<content type='text'>
[ Upstream commit 9779d45c749340ab461d595c1a4a664cb28f3007 ]

The function mbox_chan_received_data() calls the Rx callback of the
mailbox client driver. The callback might set chan_in_use flag from
pcc_send_data(). This flag's status determines whether the PCC channel
is in use.

However, there is a potential race condition where chan_in_use is
updated incorrectly due to concurrency between the interrupt handler
(pcc_mbox_irq()) and the command sender(pcc_send_data()).

The 'chan_in_use' flag of a channel is set to true after sending a
command. And the flag of the new command may be cleared erroneous by
the interrupt handler afer mbox_chan_received_data() returns,

As a result, the interrupt being level triggered can't be cleared in
pcc_mbox_irq() and it will be disabled after the number of handled times
exceeds the specified value. The error log is as follows:

  |  kunpeng_hccs HISI04B2:00: PCC command executed timeout!
  |  kunpeng_hccs HISI04B2:00: get port link status info failed, ret = -110
  |  irq 13: nobody cared (try booting with the "irqpoll" option)
  |  Call trace:
  |   dump_backtrace+0x0/0x210
  |   show_stack+0x1c/0x2c
  |   dump_stack+0xec/0x130
  |   __report_bad_irq+0x50/0x190
  |   note_interrupt+0x1e4/0x260
  |   handle_irq_event+0x144/0x17c
  |   handle_fasteoi_irq+0xd0/0x240
  |   __handle_domain_irq+0x80/0xf0
  |   gic_handle_irq+0x74/0x2d0
  |   el1_irq+0xbc/0x140
  |   mnt_clone_write+0x0/0x70
  |   file_update_time+0xcc/0x160
  |   fault_dirty_shared_page+0xe8/0x150
  |   do_shared_fault+0x80/0x1d0
  |   do_fault+0x118/0x1a4
  |   handle_pte_fault+0x154/0x230
  |   __handle_mm_fault+0x1ac/0x390
  |   handle_mm_fault+0xf0/0x250
  |   do_page_fault+0x184/0x454
  |   do_translation_fault+0xac/0xd4
  |   do_mem_abort+0x44/0xb4
  |   el0_da+0x40/0x74
  |   el0_sync_handler+0x60/0xb4
  |   el0_sync+0x168/0x180
  |  handlers:
  |   pcc_mbox_irq
  |  Disabling IRQ #13

To solve this issue, pcc_mbox_irq() must clear 'chan_in_use' flag before
the call to mbox_chan_received_data().

Tested-by: Adam Young &lt;admiyo@os.amperecomputing.com&gt;
Tested-by: Robbie King &lt;robbiek@xsightlabs.com&gt;
Signed-off-by: Huisong Li &lt;lihuisong@huawei.com&gt;
(sudeep.holla: Minor updates to the subject, commit message and comment)
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&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 9779d45c749340ab461d595c1a4a664cb28f3007 ]

The function mbox_chan_received_data() calls the Rx callback of the
mailbox client driver. The callback might set chan_in_use flag from
pcc_send_data(). This flag's status determines whether the PCC channel
is in use.

However, there is a potential race condition where chan_in_use is
updated incorrectly due to concurrency between the interrupt handler
(pcc_mbox_irq()) and the command sender(pcc_send_data()).

The 'chan_in_use' flag of a channel is set to true after sending a
command. And the flag of the new command may be cleared erroneous by
the interrupt handler afer mbox_chan_received_data() returns,

As a result, the interrupt being level triggered can't be cleared in
pcc_mbox_irq() and it will be disabled after the number of handled times
exceeds the specified value. The error log is as follows:

  |  kunpeng_hccs HISI04B2:00: PCC command executed timeout!
  |  kunpeng_hccs HISI04B2:00: get port link status info failed, ret = -110
  |  irq 13: nobody cared (try booting with the "irqpoll" option)
  |  Call trace:
  |   dump_backtrace+0x0/0x210
  |   show_stack+0x1c/0x2c
  |   dump_stack+0xec/0x130
  |   __report_bad_irq+0x50/0x190
  |   note_interrupt+0x1e4/0x260
  |   handle_irq_event+0x144/0x17c
  |   handle_fasteoi_irq+0xd0/0x240
  |   __handle_domain_irq+0x80/0xf0
  |   gic_handle_irq+0x74/0x2d0
  |   el1_irq+0xbc/0x140
  |   mnt_clone_write+0x0/0x70
  |   file_update_time+0xcc/0x160
  |   fault_dirty_shared_page+0xe8/0x150
  |   do_shared_fault+0x80/0x1d0
  |   do_fault+0x118/0x1a4
  |   handle_pte_fault+0x154/0x230
  |   __handle_mm_fault+0x1ac/0x390
  |   handle_mm_fault+0xf0/0x250
  |   do_page_fault+0x184/0x454
  |   do_translation_fault+0xac/0xd4
  |   do_mem_abort+0x44/0xb4
  |   el0_da+0x40/0x74
  |   el0_sync_handler+0x60/0xb4
  |   el0_sync+0x168/0x180
  |  handlers:
  |   pcc_mbox_irq
  |  Disabling IRQ #13

To solve this issue, pcc_mbox_irq() must clear 'chan_in_use' flag before
the call to mbox_chan_received_data().

Tested-by: Adam Young &lt;admiyo@os.amperecomputing.com&gt;
Tested-by: Robbie King &lt;robbiek@xsightlabs.com&gt;
Signed-off-by: Huisong Li &lt;lihuisong@huawei.com&gt;
(sudeep.holla: Minor updates to the subject, commit message and comment)
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mailbox: tegra-hsp: Define dimensioning masks in SoC data</title>
<updated>2025-04-20T08:23:03+00:00</updated>
<author>
<name>Kartik Rajput</name>
<email>kkartik@nvidia.com</email>
</author>
<published>2025-01-23T12:46:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ec46037fd9a6b4251eb2f01a00ed3b64bc2b0dd7'/>
<id>ec46037fd9a6b4251eb2f01a00ed3b64bc2b0dd7</id>
<content type='text'>
commit bf0c9fb462038815f5f502653fb6dba06e6af415 upstream.

Tegra264 has updated HSP_INT_DIMENSIONING register as follows:
	* nSI is now BIT17:BIT21.
	* nDB is now BIT12:BIT16.

Currently, we are using a static macro HSP_nINT_MASK to get the values
from HSP_INT_DIMENSIONING register. This results in wrong values for nSI
for HSP instances that supports 16 shared interrupts.

Define dimensioning masks in soc data and use them to parse nSI, nDB,
nAS, nSS &amp; nSM values.

Fixes: 602dbbacc3ef ("mailbox: tegra: add support for Tegra264")
Cc: stable@vger.kernel.org
Signed-off-by: Kartik Rajput &lt;kkartik@nvidia.com&gt;
Acked-by: Thierry Reding &lt;treding@nvidia.com&gt;
Acked-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&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 bf0c9fb462038815f5f502653fb6dba06e6af415 upstream.

Tegra264 has updated HSP_INT_DIMENSIONING register as follows:
	* nSI is now BIT17:BIT21.
	* nDB is now BIT12:BIT16.

Currently, we are using a static macro HSP_nINT_MASK to get the values
from HSP_INT_DIMENSIONING register. This results in wrong values for nSI
for HSP instances that supports 16 shared interrupts.

Define dimensioning masks in soc data and use them to parse nSI, nDB,
nAS, nSS &amp; nSM values.

Fixes: 602dbbacc3ef ("mailbox: tegra: add support for Tegra264")
Cc: stable@vger.kernel.org
Signed-off-by: Kartik Rajput &lt;kkartik@nvidia.com&gt;
Acked-by: Thierry Reding &lt;treding@nvidia.com&gt;
Acked-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mailbox: th1520: Fix memory corruption due to incorrect array size</title>
<updated>2025-01-18T22:20:55+00:00</updated>
<author>
<name>Michal Wilczynski</name>
<email>m.wilczynski@samsung.com</email>
</author>
<published>2024-12-02T10:05:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=db049866943a38bf46a34fa120d526663339d7a5'/>
<id>db049866943a38bf46a34fa120d526663339d7a5</id>
<content type='text'>
The functions th1520_mbox_suspend_noirq and th1520_mbox_resume_noirq are
intended to save and restore the interrupt mask registers in the MBOX
ICU0. However, the array used to store these registers was incorrectly
sized, leading to memory corruption when accessing all four registers.

This commit corrects the array size to accommodate all four interrupt
mask registers, preventing memory corruption during suspend and resume
operations.

Fixes: 5d4d263e1c6b ("mailbox: Introduce support for T-head TH1520 Mailbox driver")
Reported-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Closes: https://lore.kernel.org/all/a99e72be-8490-4960-ad26-cbfef6af238f@stanley.mountain/
Signed-off-by: Michal Wilczynski &lt;m.wilczynski@samsung.com&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The functions th1520_mbox_suspend_noirq and th1520_mbox_resume_noirq are
intended to save and restore the interrupt mask registers in the MBOX
ICU0. However, the array used to store these registers was incorrectly
sized, leading to memory corruption when accessing all four registers.

This commit corrects the array size to accommodate all four interrupt
mask registers, preventing memory corruption during suspend and resume
operations.

Fixes: 5d4d263e1c6b ("mailbox: Introduce support for T-head TH1520 Mailbox driver")
Reported-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Closes: https://lore.kernel.org/all/a99e72be-8490-4960-ad26-cbfef6af238f@stanley.mountain/
Signed-off-by: Michal Wilczynski &lt;m.wilczynski@samsung.com&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mailbox: zynqmp: Remove invalid __percpu annotation in zynqmp_ipi_probe()</title>
<updated>2025-01-18T22:20:21+00:00</updated>
<author>
<name>Uros Bizjak</name>
<email>ubizjak@gmail.com</email>
</author>
<published>2024-12-14T09:12:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=170a264d2611a0bfa96b7818730473db5e7546fc'/>
<id>170a264d2611a0bfa96b7818730473db5e7546fc</id>
<content type='text'>
struct zynqmp_ipi_pdata __percpu *pdata is not a per-cpu variable,
so it should not be annotated with __percpu annotation.

Remove invalid __percpu annotation to fix several

zynqmp-ipi-mailbox.c:920:15: warning: incorrect type in assignment (different address spaces)
zynqmp-ipi-mailbox.c:920:15:    expected struct zynqmp_ipi_pdata [noderef] __percpu *pdata
zynqmp-ipi-mailbox.c:920:15:    got void *
zynqmp-ipi-mailbox.c:927:56: warning: incorrect type in argument 3 (different address spaces)
zynqmp-ipi-mailbox.c:927:56:    expected unsigned int [usertype] *out_value
zynqmp-ipi-mailbox.c:927:56:    got unsigned int [noderef] __percpu *
...

and several

drivers/mailbox/zynqmp-ipi-mailbox.c:924:9: warning: dereference of noderef expression
...

sparse warnings.

There were no changes in the resulting object file.

Cc: stable@vger.kernel.org
Fixes: 6ffb1635341b ("mailbox: zynqmp: handle SGI for shared IPI")
Signed-off-by: Uros Bizjak &lt;ubizjak@gmail.com&gt;
Reviewed-by: Michal Simek &lt;michal.simek@amd.com&gt;
Reviewed-by: Tanmay Shah &lt;tanmay.shah@amd.com&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
struct zynqmp_ipi_pdata __percpu *pdata is not a per-cpu variable,
so it should not be annotated with __percpu annotation.

Remove invalid __percpu annotation to fix several

zynqmp-ipi-mailbox.c:920:15: warning: incorrect type in assignment (different address spaces)
zynqmp-ipi-mailbox.c:920:15:    expected struct zynqmp_ipi_pdata [noderef] __percpu *pdata
zynqmp-ipi-mailbox.c:920:15:    got void *
zynqmp-ipi-mailbox.c:927:56: warning: incorrect type in argument 3 (different address spaces)
zynqmp-ipi-mailbox.c:927:56:    expected unsigned int [usertype] *out_value
zynqmp-ipi-mailbox.c:927:56:    got unsigned int [noderef] __percpu *
...

and several

drivers/mailbox/zynqmp-ipi-mailbox.c:924:9: warning: dereference of noderef expression
...

sparse warnings.

There were no changes in the resulting object file.

Cc: stable@vger.kernel.org
Fixes: 6ffb1635341b ("mailbox: zynqmp: handle SGI for shared IPI")
Signed-off-by: Uros Bizjak &lt;ubizjak@gmail.com&gt;
Reviewed-by: Michal Simek &lt;michal.simek@amd.com&gt;
Reviewed-by: Tanmay Shah &lt;tanmay.shah@amd.com&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mailbox: add Samsung Exynos driver</title>
<updated>2025-01-18T22:18:48+00:00</updated>
<author>
<name>Tudor Ambarus</name>
<email>tudor.ambarus@linaro.org</email>
</author>
<published>2025-01-15T14:18:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fbf7e5ce408e0619072e84e93e875de52f2b5fa5'/>
<id>fbf7e5ce408e0619072e84e93e875de52f2b5fa5</id>
<content type='text'>
The Samsung Exynos mailbox controller, used on Google GS101 SoC, has 16
flag bits for hardware interrupt generation and a shared register for
passing mailbox messages. When the controller is used by the
ACPM interface the shared register is ignored and the mailbox controller
acts as a doorbell. The controller just raises the interrupt to APM
after the ACPM interface has written the message to SRAM.

Add support for the Samsung Exynos mailbox controller.

Signed-off-by: Tudor Ambarus &lt;tudor.ambarus@linaro.org&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The Samsung Exynos mailbox controller, used on Google GS101 SoC, has 16
flag bits for hardware interrupt generation and a shared register for
passing mailbox messages. When the controller is used by the
ACPM interface the shared register is ignored and the mailbox controller
acts as a doorbell. The controller just raises the interrupt to APM
after the ACPM interface has written the message to SRAM.

Add support for the Samsung Exynos mailbox controller.

Signed-off-by: Tudor Ambarus &lt;tudor.ambarus@linaro.org&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mailbox: qcom: Add support for IPQ5424 APCS IPC</title>
<updated>2025-01-18T22:17:21+00:00</updated>
<author>
<name>Gokul Sriram Palanisamy</name>
<email>quic_gokulsri@quicinc.com</email>
</author>
<published>2025-01-07T10:16:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=443a5cae7e61cac66f4ec5a000d6eaacab59feda'/>
<id>443a5cae7e61cac66f4ec5a000d6eaacab59feda</id>
<content type='text'>
IPQ5424 mailbox do not have clock support and reuses msm8994_apcs_data.

Signed-off-by: Gokul Sriram Palanisamy &lt;quic_gokulsri@quicinc.com&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
IPQ5424 mailbox do not have clock support and reuses msm8994_apcs_data.

Signed-off-by: Gokul Sriram Palanisamy &lt;quic_gokulsri@quicinc.com&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mailbox: qcom-ipcc: Reset CLEAR_ON_RECV_RD if set from boot firmware</title>
<updated>2025-01-18T22:15:33+00:00</updated>
<author>
<name>Mukesh Ojha</name>
<email>mukesh.ojha@oss.qualcomm.com</email>
</author>
<published>2024-12-30T07:54:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=16274d7e51bd6e8029b0189a8950583681c254f1'/>
<id>16274d7e51bd6e8029b0189a8950583681c254f1</id>
<content type='text'>
For some SoCs, boot firmware is using the same IPCC instance used
by Linux and it has kept CLEAR_ON_RECV_RD set which basically means
interrupt pending registers are cleared when RECV_ID is read and the
register automatically updates to the next pending interrupt/client
status based on priority.

Clear the CLEAR_ON_RECV_RD if it is set from the boot firmware.

Signed-off-by: Mukesh Ojha &lt;mukesh.ojha@oss.qualcomm.com&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For some SoCs, boot firmware is using the same IPCC instance used
by Linux and it has kept CLEAR_ON_RECV_RD set which basically means
interrupt pending registers are cleared when RECV_ID is read and the
register automatically updates to the next pending interrupt/client
status based on priority.

Clear the CLEAR_ON_RECV_RD if it is set from the boot firmware.

Signed-off-by: Mukesh Ojha &lt;mukesh.ojha@oss.qualcomm.com&gt;
Signed-off-by: Jassi Brar &lt;jassisinghbrar@gmail.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
