Define a new, optional, callback that allows the driver to specify how the return data buffer is allocated. If that callback is set, mailbox/pcc.c is now responsible for reading from and writing to the PCC shared buffer. This also allows for proper checks of the Commnand complete flag between the PCC sender and receiver. For Type 4 channels, initialize the command complete flag prior to accepting messages. Since the mailbox does not know what memory allocation scheme to use for response messages, the client now has an optional callback that allows it to allocate the buffer for a response message. When an outbound message is written to the buffer, the mailbox checks for the flag indicating the client wants an tx complete notification via IRQ. Upon receipt of the interrupt It will pair it with the outgoing message. The expected use is to free the kernel memory buffer for the previous outgoing message. Signed-off-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
The existing check_and_ack() function had unnecessary complexity. The logic could be streamlined to improve code readability and maintainability. The command update register needs to be updated in order to acknowledge the platform notification through type 4 channel. So it can be done unconditionally. Currently it is complicated just to make use of pcc_send_data() which also executes the same updation. In order to simplify, let us just ring the doorbell directly from check_and_ack() instead of calling into pcc_send_data(). While at it, rename it into pcc_chan_check_and_ack() to maintain consistency in the driver. Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
Currently the shared memory communication address was mapped by the mailbox client drivers leading to all sorts of inconsistencies. It also has resulted in the inconsistent attributes used while mapping the shared memory regions. In order to remove/eliminate any issues, let us ensures the shared memory address is always mapped and unmapped when the PCC channels are requested and release. We need to map them as the ACPI PCCT associates these shared memory with each channel subspace and may need use the status or the flags in the headers of those shared memory communication address regions to manage the transport/channel. Note, until all the drivers using PCC start using this mapped shmem, there might be double mapping of the shared memory address. This shouldn't have any impact on existing mbox client drivers. Since there are no users of pcc_chan_ioremap() and also it is mapped by default, we can stop exporting it and merge the functionality into pcc_mbox_request_channel(). Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
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 <lihuisong@huawei.com> Tested-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
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 <lihuisong@huawei.com> Tested-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
pcc_mbox_cmd_complete_check() accesses pchan->cmd_complete.gas to check command completion status. Even if GAS is NULL, pcc_chan_reg_read() gets called which returns success doing nothing and then we return. Add an early return if pchan->cmd_complete.gas == NULL before performing any operations. Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
The Sparse static checker flags a type mismatch warning related to endianness conversion: | warning: incorrect type in argument 1 (different base types) | expected restricted __le32 const [usertype] *p | got unsigned int * This is because an explicit endianness conversion (le32_to_cpu()) was applied unnecessarily to a pcc_hdr.flags field that is already in little-endian format. The PCC driver is only enabled on little-endian kernels due to its dependency on ACPI and EFI, making the explicit conversion unnecessary. The redundant conversion occurs in pcc_chan_check_and_ack() for the pcc_hdr.flags field. Drop this unnecessary endianness conversion of pcc_hdr.flags. Also drop the redundant PCC_ACK_FLAG_MASK definition and use the more appropriate and already defined PCC_CMD_COMPLETION_NOTIFY. Acked-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
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 <robbiek@xsightlabs.com> Reviewed-by: Huisong Li <lihuisong@huawei.com> Tested-by: Huisong Li <lihuisong@huawei.com> Tested-by: Adam Young <admiyo@os.amperecomputing.com> Tested-by: Robbie King <robbiek@xsightlabs.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
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 <admiyo@os.amperecomputing.com> Tested-by: Robbie King <robbiek@xsightlabs.com> Signed-off-by: Huisong Li <lihuisong@huawei.com> (sudeep.holla: Minor updates to the subject, commit message and comment) Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
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 <admiyo@os.amperecomputing.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>