kernel/drivers/mailbox/pcc.c, branch linux-6.9.y

mailbox: pcc: Support shared interrupt for multiple subspaces

2023-09-11T09:31:17Z

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

mailbox: pcc: Add support for platform notification handling

2023-09-11T09:31:17Z

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

mailbox: pcc: Use mbox_bind_client

2023-04-18T16:48:56Z

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

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

2022-11-23T18:06:56Z

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

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

2022-10-06T02:51:14Z

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:30Z

`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

mailbox: pcc: Handle all PCC subtypes correctly in pcc_mbox_irq

2022-01-12T05:47:33Z

Commit c45ded7e1135 ("mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4)") enabled the type3/4 of PCCT, but the change in pcc_mbox_irq breaks the other PCC subtypes. The kernel reports a warning on an Ampere eMag server -->8 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4 #127 Hardware name: MiTAC RAPTOR EV-883832-X3-0001/RAPTOR, BIOS 0.14 02/22/2019 Call trace: dump_backtrace+0x0/0x200 show_stack+0x20/0x30 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 __report_bad_irq+0x54/0x17c note_interrupt+0x330/0x428 handle_irq_event_percpu+0x90/0x98 handle_irq_event+0x4c/0x148 handle_fasteoi_irq+0xc4/0x188 generic_handle_domain_irq+0x44/0x68 gic_handle_irq+0x84/0x2ec call_on_irq_stack+0x28/0x34 do_interrupt_handler+0x88/0x90 el1_interrupt+0x48/0xb0 el1h_64_irq_handler+0x18/0x28 el1h_64_irq+0x7c/0x80 Fixes: c45ded7e1135 ("mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4)") Reported-by: Justin He Tested-by: Justin He Signed-off-by: Sudeep Holla Signed-off-by: Jassi Brar

mailbox: pcc: Avoid using the uninitialized variable 'dev'

2022-01-12T05:47:33Z

Smatch static checker warns: | drivers/mailbox/pcc.c:292 pcc_mbox_request_channel() | error: uninitialized symbol 'dev'. Fix the same by using pr_err instead of dev_err as the variable 'dev' is uninitialized at that stage. Fixes: ce028702ddbc ("mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe") Cc: Jassi Brar Reported-by: Dan Carpenter Signed-off-by: Sudeep Holla Signed-off-by: Jassi Brar

mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe

2021-10-30T03:46:38Z

Move the PCCT subspace parsing and allocation into pcc_mbox_probe so that we can get rid of global PCC channel and mailbox controller data. It also helps to make use of devm_* APIs for all the allocations. Signed-off-by: Sudeep Holla Signed-off-by: Jassi Brar

mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4)

2021-10-30T03:46:38Z

With all the plumbing in place to avoid accessing PCCT type and other fields directly from the PCCT table all the time, let us now add the support for extended PCC subspaces(type 3 and 4). Signed-off-by: Sudeep Holla Signed-off-by: Jassi Brar