kernel/linux.git/drivers/mailbox/pcc.c, branch v6.1.168

mailbox: pcc: Remove spurious IRQF_ONESHOT usage

2026-03-04T12:20:31+00:00

[ Upstream commit 673327028cd61db68a1e0c708be2e302c082adf9 ] The PCC code currently specifies IRQF_ONESHOT if the interrupt could potentially be shared but doesn't actually use request_threaded_irq() and the interrupt handler does not use IRQ_WAKE_THREAD so IRQF_ONESHOT is never relevant. Since commit aef30c8d569c ("genirq: Warn about using IRQF_ONESHOT without a threaded handler") specifying it has resulted in a WARN_ON(), fix this by removing IRQF_ONESHOT. Reported-by: Aishwarya TCV Signed-off-by: Mark Brown Reviewed-by: Sudeep Holla Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin

mailbox: pcc: don't zero error register

2025-12-06T21:12:42+00:00

[ Upstream commit ff0e4d4c97c94af34cc9cad37b5a5cdbe597a3b0 ] The error status mask for a type 3/4 subspace is used for reading the error status, and the bitwise inverse is used for clearing the error with the intent being to preserve any of the non-error bits. However, we were previously applying the mask to extract the status and then applying the inverse to the result which ended up clearing all bits. Instead, store the inverse mask in the preserve mask and then use that on the original value read from the error status so that only the error is cleared. Fixes: c45ded7e1135 ("mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4)") Signed-off-by: Jamie Iles Signed-off-by: Punit Agrawal Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin

mailbox: pcc: Refactor error handling in irq handler into separate function

2025-12-06T21:12:42+00:00

[ Upstream commit 3a675f50415b95f2ae10bfd932e2154ba1a08ee7 ] The existing error handling logic in pcc_mbox_irq() is intermixed with the main flow of the function. The command complete check and the complete complete update/acknowledgment are nicely factored into separate functions. Moves error detection and clearing logic into a separate function called: pcc_mbox_error_check_and_clear() by extracting error-handling logic from pcc_mbox_irq(). This ensures error checking and clearing are handled separately and it improves maintainability by keeping the IRQ handler focused on processing events. Acked-by: Huisong Li Tested-by: Huisong Li Tested-by: Adam Young Signed-off-by: Sudeep Holla Signed-off-by: Jassi Brar Stable-dep-of: ff0e4d4c97c9 ("mailbox: pcc: don't zero error register") Signed-off-by: Sasha Levin

mailbox: pcc: Check before sending MCTP PCC response ACK

2025-12-06T21:12:42+00:00

[ Upstream commit 7f9e19f207be0c534d517d65e01417ba968cdd34 ] Type 4 PCC channels have an option to send back a response to the platform when they are done processing the request. The flag to indicate whether or not to respond is inside the message body, and thus is not available to the pcc mailbox. If the flag is not set, still set command completion bit after processing message. In order to read the flag, this patch maps the shared buffer to virtual memory. To avoid duplication of mapping the shared buffer is then made available to be used by the driver that uses the mailbox. Signed-off-by: Adam Young Cc: Sudeep Holla Signed-off-by: Jassi Brar Stable-dep-of: ff0e4d4c97c9 ("mailbox: pcc: don't zero error register") Signed-off-by: Sasha Levin

mailbox: pcc: Support shared interrupt for multiple subspaces

2025-12-06T21:12:42+00:00

[ Upstream commit 3db174e478cb0bb34888c20a531608b70aec9c1f ] If the platform acknowledge interrupt is level triggered, then it can be shared by multiple subspaces provided each one has a unique platform interrupt ack preserve and ack set masks. If it can be shared, then we can request the irq with IRQF_SHARED and IRQF_ONESHOT flags. The first one indicating it can be shared and the latter one to keep the interrupt disabled until the hardirq handler finished. Further, since there is no way to detect if the interrupt is for a given channel as the interrupt ack preserve and ack set masks are for clearing the interrupt and not for reading the status(in case Irq Ack register may be write-only on some platforms), we need a way to identify if the given channel is in use and expecting the interrupt. PCC type0, type1 and type5 do not support shared level triggered interrupt. The methods of determining whether a given channel for remaining types should respond to an interrupt are as follows: - type2: Whether the interrupt belongs to a given channel is only determined by the status field in Generic Communications Channel Shared Memory Region, which is done in rx_callback of PCC client. - type3: This channel checks chan_in_use flag first and then checks the command complete bit(value '1' indicates that the command has been completed). - type4: Platform ensure that the default value of the command complete bit corresponding to the type4 channel is '1'. This command complete bit is '0' when receive a platform notification. The new field, 'chan_in_use' is used by the type only support the communication from OSPM to Platform (like type3) and should be completely ignored by other types so as to avoid too many type unnecessary checks in IRQ handler. Signed-off-by: Huisong Li Reviewed-by: Hanjun Guo Link: https://lore.kernel.org/r/20230801063827.25336-3-lihuisong@huawei.com Signed-off-by: Sudeep Holla Stable-dep-of: ff0e4d4c97c9 ("mailbox: pcc: don't zero error register") Signed-off-by: Sasha Levin

mailbox: pcc: Add support for platform notification handling

2025-12-06T21:12:42+00:00

[ Upstream commit 60c40b06fa68694dd08a1a0038ea8b9de3f3b1ca ] Currently, PCC driver doesn't support the processing of platform notification for type 4 PCC subspaces. According to ACPI specification, if platform sends a notification to OSPM, it must clear the command complete bit and trigger platform interrupt. OSPM needs to check whether the command complete bit is cleared, clear platform interrupt, process command, and then set the command complete and ring doorbell to the Platform. Let us stash the value of the pcc type and use the same while processing the interrupt of the channel. We also need to set the command complete bit and ring doorbell in the interrupt handler for the type 4 channel to complete the communication flow after processing the notification from the Platform. Signed-off-by: Huisong Li Reviewed-by: Hanjun Guo Link: https://lore.kernel.org/r/20230801063827.25336-2-lihuisong@huawei.com Signed-off-by: Sudeep Holla Stable-dep-of: ff0e4d4c97c9 ("mailbox: pcc: don't zero error register") Signed-off-by: Sasha Levin

mailbox: pcc: Use mbox_bind_client

2025-12-06T21:12:42+00:00

[ Upstream commit 76d4adacd52e78bea2e393081f2a5766261d1e3a ] Use generic mbox_bind_client() to bind omap mailbox channel to a client. mbox_bind_client is identical to the replaced lines, except that it: - Does the operation under con_mutex which prevents possible races in removal path - Sets TXDONE_BY_ACK if pcc uses TXDONE_BY_POLL and the client knows when tx is done. TXDONE_BY_ACK is already set if there's no interrupt, so this is not applicable. - Calls chan->mbox->ops->startup. This is usecase for requesting irq: move the devm_request_irq into the startup callback and unregister it in the shutdown path. Tested-by: Sudeep Holla Signed-off-by: Elliot Berman Signed-off-by: Jassi Brar Stable-dep-of: ff0e4d4c97c9 ("mailbox: pcc: don't zero error register") Signed-off-by: Sasha Levin

mailbox: pcc: Reset pcc_chan_count to zero in case of PCC probe failure

2022-12-31T12:31:57+00:00

[ Upstream commit 6d7d3c287410c0ad499e478e2338dc3d7e3392b1 ] Currently, 'pcc_chan_count' is remains set to a non-zero value if PCC subspaces are parsed successfully but something else fail later during the initial PCC probing phase. This will result in pcc_mbox_request_channel trying to access the resources that are not initialised or allocated and may end up in a system crash. Reset pcc_chan_count to 0 when the PCC probe fails in order to prevent the possible issue as described above. Fixes: ce028702ddbc ("mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe") Signed-off-by: Huisong Li Reviewed-by: Sudeep Holla Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

mailbox: pcc: Fix spelling mistake "Plaform" -> "Platform"

2022-10-06T02:51:14+00:00

There is a spelling mistake in a pr_err message. Fix it. Signed-off-by: Colin Ian King Signed-off-by: Jassi Brar

mailbox: pcc: Fix an invalid-load caught by the address sanitizer

2022-05-21T16:41:30+00:00

`pcc_mailbox_probe` doesn't initialize all memory that has been allocated before the first time that one of it's members `txdone_irq` may be accessed. This leads to a an invalid load any time that this member is accessed: [ 2.429769] UBSAN: invalid-load in drivers/mailbox/pcc.c:684:22 [ 2.430324] UBSAN: invalid-load in drivers/mailbox/mailbox.c:486:12 [ 4.276782] UBSAN: invalid-load in drivers/acpi/cppc_acpi.c:314:45 Link: https://bugzilla.kernel.org/show_bug.cgi?id=215587 Fixes: ce028702ddbc ("mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe") Signed-off-by: Mario Limonciello Reviewed-by: Sudeep Holla Signed-off-by: Jassi Brar