summaryrefslogtreecommitdiffstats
path: root/drivers/firmware/arm_ffa/driver.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* firmware: arm_ffa: Handle partitions setup failuresCristian Marussi2024-01-221-5/+23
| | | | | | | | | Make ffa_setup_partitions() fail, cleanup and return an error when the Host partition setup fails: in such a case ffa_init() itself will fail. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240108-ffa_fixes_6-8-v1-6-75bf7035bc50@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Use xa_insert() and check for resultCristian Marussi2024-01-221-3/+16
| | | | | | | | | | | | | | While adding new partitions descriptors to the XArray the outcome of the stores should be checked and, in particular, it has also to be ensured that an existing entry with the same index was not already present, since partitions IDs are expected to be unique. Use xa_insert() instead of xa_store() since it returns -EBUSY when the index is already in use and log an error when that happens. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240108-ffa_fixes_6-8-v1-5-75bf7035bc50@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Simplify ffa_partitions_cleanup()Cristian Marussi2024-01-221-20/+6
| | | | | | | | | | | On cleanup iterate the XArrays with xa_for_each() and remove the existent entries with xa_erase(), finally destroy the XArray itself. Remove partition_count field from drv_info since no more used anywhwere. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240108-ffa_fixes_6-8-v1-4-75bf7035bc50@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Check xa_load() return valueCristian Marussi2024-01-221-0/+10
| | | | | | | | | | | | Add a check to verify the result of xa_load() during the partition lookups done while registering/unregistering the scheduler receiver interrupt callbacks and while executing the main scheduler receiver interrupt callback handler. Fixes: 0184450b8b1e ("firmware: arm_ffa: Add schedule receiver callback mechanism") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240108-ffa_fixes_6-8-v1-3-75bf7035bc50@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Add missing rwlock_init() for the driver partitionCristian Marussi2024-01-221-0/+1
| | | | | | | | | | | | Add the missing rwlock initialization for the FF-A partition associated the driver in ffa_setup_partitions(). It will the primary scheduler partition in the host or the VM partition in the virtualised environment. IOW, it corresponds to the partition with VM ID == drv_info->vm_id. Fixes: 1b6bf41b7a65 ("firmware: arm_ffa: Add notification handling mechanism") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240108-ffa_fixes_6-8-v1-2-75bf7035bc50@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Add missing rwlock_init() in ffa_setup_partitions()Cristian Marussi2024-01-221-0/+1
| | | | | | | | | | Add the missing rwlock initialization for the individual FF-A partition information in ffa_setup_partitions(). Fixes: 0184450b8b1e ("firmware: arm_ffa: Add schedule receiver callback mechanism") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20240108-ffa_fixes_6-8-v1-1-75bf7035bc50@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Fix ffa_notification_info_get() IDs handlingLorenzo Pieralisi2023-11-131-2/+2
| | | | | | | | | | | | | | | | To parse the retrieved ID lists appropriately in ffa_notification_info_get() the ids_processed variable should not be pre-incremented - we are dropping an identifier at the beginning of the list. Fix it by using the post-increment operator to increment the number of processed IDs. Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface") Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Cc: Sudeep Holla <sudeep.holla@arm.com> Link: https://lore.kernel.org/r/20231108111549.155974-1-lpieralisi@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Fix the size of the allocation in ffa_partitions_cleanup()Sudeep Holla2023-11-131-1/+1
| | | | | | | | | | | | | | | | | Arry of pointer to struct ffa_dev_part_info needs to be allocated to fetch the pointers stored in XArray. However, currently we allocate the entire structure instead of just pointers. Fix the allocation size. This will also eliminate the below Smatch istatic checker warning: | drivers/firmware/arm_ffa/driver.c:1251 ffa_partitions_cleanup() | warn: double check that we're allocating correct size: 8 vs 88 Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/0e8ddbca-d9da-4a3b-aae3-328993b62ba2@moroto.mountain Link: https://lore.kernel.org/r/20231031141335.3077026-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Fix FFA notifications cleanup pathSudeep Holla2023-11-131-4/+12
| | | | | | | | | | | | | | | | | | | We allow the FF-A to be initialised successfully even when notification fails. When the notification fails, ffa_notifications_cleanup() gets called on the failure path. However, the driver information about the notifications like the irq, workqueues and cpu hotplug state for enabling and disabling percpu IRQ are not cleared. This may result in unexpected behaviour during CPU hotplug because of percpu IRQ being enabled and disabled or during the driver removal when ffa_notifications_cleanup() gets executed again. Fix the FFA notifications cleanup path by clearing all the notification related driver information. Link: https://lore.kernel.org/r/20231024-ffa-notification-fixes-v1-4-d552c0ec260d@arm.com Tested-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Add checks for the notification enabled stateSudeep Holla2023-11-131-0/+17
| | | | | | | | | | | We need to check if the FF-A notifications are enabled or not in all the notification operations that are accessible for the FF-A device from the FF-A driver. This helps to avoid making calls to the FF-A firmware even if the notification setup has failed. Link: https://lore.kernel.org/r/20231024-ffa-notification-fixes-v1-3-d552c0ec260d@arm.com Tested-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Setup the partitions after the notification initialisationSudeep Holla2023-11-131-7/+8
| | | | | | | | | | | | | | | | Currently the notifications are setup of the partitions are probed and FF-A devices are added on the FF-A bus. The FF-A driver probe can be called even before the FF-A notification setup happens which is wrong and may result in failure or misbehaviour in the FF-A partition device probe. In order to ensure the FF-A notifications are setup before the FF-A devices are probed, let us move the FF-A partition setup after the completion of FF-A notification setup. Link: https://lore.kernel.org/r/20231024-ffa-notification-fixes-v1-2-d552c0ec260d@arm.com Tested-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Allow FF-A initialisation even when notification failsSudeep Holla2023-11-131-12/+8
| | | | | | | | | | | | | | | FF-A notifications are optional feature in the specification. Currently we allow to continue if the firmware reports no support for the notifications. However, we fail to continue and complete the FF-A driver initialisation if the notification setup fails for any reason. Let us allow the FF-A driver to complete the initialisation even if the notification fails to setup. We will just flag the error and continue to provide other features in the driver. Link: https://lore.kernel.org/r/20231024-ffa-notification-fixes-v1-1-d552c0ec260d@arm.com Tested-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Upgrade the driver version to v1.1Sudeep Holla2023-10-081-1/+1
| | | | | | | | With quite a few v1.1 features supported, we can bump the driver version to v1.1 now. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-17-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Update memory descriptor to support v1.1 formatSudeep Holla2023-10-081-3/+8
| | | | | | | | | | | | | | | | | | Update memory transaction descriptor structure to accommodate couple of new entries in v1.1 which were previously marked reserved and MBZ(must be zero). It also removes the flexible array member ep_mem_access in the memory transaction descriptor structure as it need not be at fixed offset. Also update ffa_mem_desc_offset() accessor to handle both old and new formats of memory transaction descriptors. The updated ffa_mem_region structure aligns with new format in v1.1 and hence the driver/user must take care not to use members beyond and including ep_mem_offset when using the old format. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-16-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Switch to using ffa_mem_desc_offset() accessorSudeep Holla2023-10-081-2/+4
| | | | | | | | | | | | | In preparation to add support to the new memory transaction descriptor, the ep_mem_access member needs to be removed and hence even the macro COMPOSITE_OFFSET(). Let us switch to using the new ffa_mem_desc_offset() accessor in ffa_setup_and_transmit(). This will enable adding the support for new format transparently without any changes here again. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-15-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Simplify the computation of transmit and fragment lengthSudeep Holla2023-10-061-6/+8
| | | | | | | | | | | | | | | | The computation of endpoint memory access descriptor's composite memory region descriptor offset is using COMPOSITE_CONSTITUENTS_OFFSET which is unnecessary complicated. Composite memory region descriptor always follow the endpoint memory access descriptor array and hence it is computed accordingly. COMPOSITE_CONSTITUENTS_OFFSET is useless and wrong for any input other than endpoint memory access descriptor count. Let us drop the usage of COMPOSITE_CONSTITUENTS_OFFSET to simplify the computation of total transmit and fragment length in the memory transactions. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-13-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Add notification handling mechanismSudeep Holla2023-10-061-1/+66
| | | | | | | | | | With all the necessary plumbing in place, let us add handling the notifications as part of schedule receiver interrupt handler. In order to do so, we need to just register scheduling callback on behalf of the driver partition. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-12-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Add interface to send a notification to a given partitionSudeep Holla2023-10-061-0/+13
| | | | | | | | | | | | The framework provides an interface to the sender endpoint to specify the notification to signal to the receiver endpoint. A sender signals a notification by requesting its partition manager to set the corresponding bit in the notifications bitmap of the receiver. Expose the ability to send a notification to another partition. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-11-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Add interfaces to request notification callbacksSudeep Holla2023-10-061-0/+145
| | | | | | | | | Add interface to the FFA driver to allow for client drivers to request and relinquish a notification as well as provide a callback for the notification. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-10-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Add schedule receiver callback mechanismSudeep Holla2023-10-061-3/+100
| | | | | | | | | Enable client drivers to register a callback function that will be called when one or more notifications are pending for a target partition as part of schedule receiver interrupt handling. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-9-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Initial support for scheduler receiver interruptSudeep Holla2023-10-061-10/+176
| | | | | | | | | | | | | | | | | | | | | | | | | | The Framework uses the schedule receiver interrupt to inform the receiver’s scheduler that the receiver must be run to handle a pending notification. A receiver’s scheduler can obtain the description of the schedule receiver interrupt by invoking the FFA_FEATURES interface. The delivery of the physical schedule receiver interrupt from the secure state to the non-secure state depends upon the state of the interrupt controller as configured by the hypervisor. The schedule seceiver interrupt is assumed to be a SGI. The Arm GIC specification defines 16 SGIs. It recommends that they are equally divided between the non-secure and secure states. OS like Linux kernel in the non-secure state typically do not have SGIs to spare. The usage of SGIs in the secure state is however limited. It is more likely that software in the Secure world does not use all the SGIs allocated to it. It is recommended that the secure world software donates an unused SGI to the normal world for use as the schedule receiver interrupt. This implies that secure world software must configure the SGI in the GIC as a non-secure interrupt before presenting it to the normal world. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-8-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interfaceSudeep Holla2023-10-061-0/+73
| | | | | | | | | | | | | | | | | The receiver’s scheduler uses the FFA_NOTIFICATION_INFO_GET interface to retrieve the list of endpoints that have pending notifications and must be run. A notification could be signaled by a sender in the secure world to a VM. The Hypervisor needs to determine which VM and vCPU (in case a per-vCPU notification is signaled) has a pending notification in this scenario. It must obtain this information through an invocation of the FFA_NOTIFICATION_INFO_GET. Add the implementation of the NOTIFICATION_INFO_GET interface and prepare to use this to handle the schedule receiver interrupt. Implementation of handling notifications will be added later. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-7-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Implement the FFA_NOTIFICATION_GET interfaceSudeep Holla2023-10-061-0/+37
| | | | | | | | | | | | | The framework provides an interface to the receiver to determine the identity of the notification. A receiver endpoint must use the FFA_NOTIFICATION_GET interface to retrieve its pending notifications and handle them. Add the support for FFA_NOTIFICATION_GET to allow the caller(receiver) to fetch its pending notifications from other partitions in the system. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-6-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Implement the FFA_NOTIFICATION_SET interfaceSudeep Holla2023-10-061-0/+20
| | | | | | | | | | | | | The framework provides an interface to the sender to specify the notification to signal to the receiver. A sender signals a notification by requesting its partition manager to set the corresponding bit in the notifications bitmap of the receiver invoking FFA_NOTIFICATION_SET. Implement the FFA_NOTIFICATION_SET to enable the caller(sender) to send the notifications for any other partitions in the system. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-5-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Implement the FFA_RUN interfaceSudeep Holla2023-10-061-0/+22
| | | | | | | | | | | | | | FFA_RUN is used by a scheduler to allocate CPU cycles to a target endpoint execution context specified in the target information parameter. If the endpoint execution context is in the waiting/blocked state, it transitions to the running state. Expose the ability to call FFA_RUN in order to give any partition in the system cpu cycles to perform IMPDEF functionality. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-4-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Implement the notification bind and unbind interfaceSudeep Holla2023-10-061-0/+29
| | | | | | | | | | | | | | | | | | | A receiver endpoint must bind a notification to any sender endpoint before the latter can signal the notification to the former. The receiver assigns one or more doorbells to a specific sender. Only the sender can ring these doorbells. A receiver uses the FFA_NOTIFICATION_BIND interface to bind one or more notifications to the sender. A receiver un-binds a notification from a sender endpoint to stop the notification from being signaled. It uses the FFA_NOTIFICATION_UNBIND interface to do this. Allow the FF-A driver to be able to bind and unbind a given notification ID to a specific partition ID. This will be used to register and unregister notification callbacks from the FF-A client drivers. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-3-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Implement notification bitmap create and destroy interfacesSudeep Holla2023-10-061-1/+62
| | | | | | | | | | | | | | | | | | | | On systems without a hypervisor the responsibility of requesting the creation of the notification bitmaps in the SPM falls to the FF-A driver. We use FFA features to determine if the ABI is supported, if it is not we can assume there is a hypervisor present and will take care of ensure the relevant notifications bitmaps are created on this partitions behalf. An endpoint’s notification bitmaps needs to be setup before it configures its notifications and before other endpoints and partition managers can start signaling these notifications. Add interface to create and destroy the notification bitmaps and use the same to do the necessary setup during the initialisation and cleanup during the module exit. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-2-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Update the FF-A command list with v1.1 additionsSudeep Holla2023-10-061-0/+1
| | | | | | | | | | | | Arm Firmware Framework for A-profile(FFA) v1.1 introduces notifications and indirect messaging based upon notifications support and extends some of the memory interfaces. Let us add all the newly supported FF-A function IDs in the spec. Also update to the error values and associated handling. Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-1-cddd3237809c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Allow the FF-A drivers to use 32bit mode of messagingSudeep Holla2023-10-061-10/+2
| | | | | | | | | | | | | | | | | | | An FF-A ABI could support both the SMC32 and SMC64 conventions. A callee that runs in the AArch64 execution state and implements such an ABI must implement both SMC32 and SMC64 conventions of the ABI. So the FF-A drivers will need the option to choose the mode irrespective of FF-A version and the partition execution mode flag in the partition information. Let us remove the check on the FF-A version for allowing the selection of 32bit mode of messaging. The driver will continue to set the 32-bit mode if the partition execution mode flag specified that the partition supports only 32-bit execution. Fixes: 106b11b1ccd5 ("firmware: arm_ffa: Set up 32bit execution mode flag using partiion property") Link: https://lore.kernel.org/r/20231005142823.278121-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Don't set the memory region attributes for MEM_LENDSudeep Holla2023-09-251-2/+14
| | | | | | | | | | | | | | | | 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 <joao.alves@arm.com> Reported-by: Olivier Deprez <olivier.deprez@arm.com> Link: https://lore.kernel.org/r/20230919-ffa_v1-1_notif-v2-13-6f3a3ca3923c@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Set handle field to zero in memory descriptorBalint Dobszay2023-06-061-0/+1
| | | | | | | | | | | | | As described in the commit 111a833dc5cb ("firmware: arm_ffa: Set reserved/MBZ fields to zero in the memory descriptors") some fields in the memory descriptor have to be zeroed explicitly. The handle field is one of these, but it was left out from that change, fix this now. Fixes: 111a833dc5cb ("firmware: arm_ffa: Set reserved/MBZ fields to zero in the memory descriptors") Reported-by: Imre Kis <imre.kis@arm.com> Signed-off-by: Balint Dobszay <balint.dobszay@arm.com> Link: https://lore.kernel.org/r/20230601140749.93812-1-balint.dobszay@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Set reserved/MBZ fields to zero in the memory descriptorsSudeep Holla2023-05-081-0/+6
| | | | | | | | | | | | | | | | | | | | The transmit buffers allocated by the driver can be used to transmit data by any messages/commands needing the buffer. However, it is not guaranteed to have been zero-ed before every new transmission and hence it will just contain residual value from the previous transmission. There are several reserved fields in the memory descriptors that must be zero(MBZ). The receiver can reject the transmission if any such MBZ fields are non-zero. While we can set the whole page to zero, it is not optimal as most of the fields get initialised to the value required for the current transmission. So, just set the reserved/MBZ fields to zero in the memory descriptors explicitly to honour the requirement and keep the receiver happy. Fixes: cc2195fe536c ("firmware: arm_ffa: Add support for MEM_* interfaces") Reported-by: Marc Bonnici <marc.bonnici@arm.com> Link: https://lore.kernel.org/r/20230503131252.12585-1-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Fix usage of partition info get count flagSudeep Holla2023-05-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | Commit bb1be7498500 ("firmware: arm_ffa: Add v1.1 get_partition_info support") adds support to discovery the UUIDs of the partitions or just fetch the partition count using the PARTITION_INFO_GET_RETURN_COUNT_ONLY flag. However the commit doesn't handle the fact that the older version doesn't understand the flag and must be MBZ which results in firmware returning invalid parameter error. That results in the failure of the driver probe which is in correct. Limit the usage of the PARTITION_INFO_GET_RETURN_COUNT_ONLY flag for the versions above v1.0(i.e v1.1 and onwards) which fixes the issue. Fixes: bb1be7498500 ("firmware: arm_ffa: Add v1.1 get_partition_info support") Reported-by: Jens Wiklander <jens.wiklander@linaro.org> Reported-by: Marc Bonnici <marc.bonnici@arm.com> Tested-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Link: https://lore.kernel.org/r/20230419-ffa_fixes_6-4-v2-2-d9108e43a176@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Move constants to header fileWill Deacon2022-12-011-91/+10
| | | | | | | | | | | | | | FF-A function IDs and error codes will be needed in the hypervisor too, so move to them to the header file where they can be shared. Rename the version constants with an "FFA_" prefix so that they are less likely to clash with other code in the tree. Co-developed-by: Andrew Walbran <qwandor@google.com> Signed-off-by: Andrew Walbran <qwandor@google.com> Signed-off-by: Quentin Perret <qperret@google.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Link: https://lore.kernel.org/r/20221116170335.2341003-2-qperret@google.com Signed-off-by: Will Deacon <will@kernel.org>
* firmware: arm_ffa: Split up ffa_ops into info, message and memory operationsSudeep Holla2022-09-081-2/+14
| | | | | | | | | | | | | | | In preparation to make memory operations accessible for a non ffa_driver/device, it is better to split the ffa_ops into different categories of operations: info, message and memory. The info and memory are ffa_device independent and can be used without any associated ffa_device from a non ffa_driver. However, we don't export these info and memory APIs yet without the user. The first users of these APIs can export them. Link: https://lore.kernel.org/r/20220907145240.1683088-11-sudeep.holla@arm.com Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Set up 32bit execution mode flag using partiion propertySudeep Holla2022-09-081-1/+13
| | | | | | | | | | | FF-A v1.1 adds a flag in the partition properties to indicate if the partition runs in the AArch32 or AArch64 execution state. Use the same to set-up the 32-bit execution flag mode in the ffa_dev automatically if the detected firmware version is above v1.0 and ignore any requests to do the same from the ffa_driver. Link: https://lore.kernel.org/r/20220907145240.1683088-10-sudeep.holla@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Add v1.1 get_partition_info supportSudeep Holla2022-09-081-8/+35
| | | | | | | | | | | | | FF-A v1.1 adds support to discovery the UUIDs of the partitions that was missing in v1.0 and which the driver workarounds by using UUIDs supplied by the ffa_drivers. Add the v1.1 get_partition_info support and disable the workaround if the detected FF-A version is greater than v1.0. Link: https://lore.kernel.org/r/20220907145240.1683088-9-sudeep.holla@arm.com Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Rename ffa_dev_ops as ffa_opsSudeep Holla2022-09-081-1/+1
| | | | | | | | | | | | | | Except the message APIs, all other APIs are ffa_device independent and can be used without any associated ffa_device from a non ffa_driver. In order to reflect the same, just rename ffa_dev_ops as ffa_ops to avoid any confusion or to keep it simple. Link: https://lore.kernel.org/r/20220907145240.1683088-8-sudeep.holla@arm.com Suggested-by: Sumit Garg <sumit.garg@linaro.org> Reviewed-by: Sumit Garg <sumit.garg@linaro.org> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Make memory apis ffa_device independentSudeep Holla2022-09-081-4/+2
| | | | | | | | | | | | | | | | | There is a requirement to make memory APIs independent of the ffa_device. One of the use-case is to have a common memory driver that manages the memory for all the ffa_devices. That common memory driver won't be a ffa_driver or won't have any ffa_device associated with it. So having these memory APIs accessible without a ffa_device is needed and should be possible as most of these are handled by the partition manager(SPM or hypervisor). Drop the ffa_device argument to the memory APIs and make them ffa_device independent. Link: https://lore.kernel.org/r/20220907145240.1683088-7-sudeep.holla@arm.com Acked-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Use FFA_FEATURES to detect if native versions are supportedSudeep Holla2022-09-081-6/+16
| | | | | | | | | | | | | | | | | Currently, the ffa_dev->mode_32bit is use to detect if the native 64-bit or 32-bit versions of FF-A ABI needs to be used. However for the FF-A memory ABIs, it is not dependent on the ffa_device(i.e. the partition) itself, but the partition manager(SPM). So, the FFA_FEATURES can be use to detect if the native 64bit ABIs are supported or not and appropriate calls can be made based on that. Use FFA_FEATURES to detect if native versions of MEM_LEND or MEM_SHARE are implemented and make of the same to use native memory ABIs later on. Link: https://lore.kernel.org/r/20220907145240.1683088-6-sudeep.holla@arm.com Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Add support for querying FF-A featuresSudeep Holla2022-09-081-0/+26
| | | | | | | | | | | | | | Add support for FFA_FEATURES to discover properties supported at the FF-A interface. This interface can be used to query: - If an FF-A interface is implemented by the component at the higher EL, - If an implemented FF-A interface also implements any optional features described in its interface definition, and - Any implementation details exported by an implemented FF-A interface as described in its interface definition. Link: https://lore.kernel.org/r/20220907145240.1683088-5-sudeep.holla@arm.com Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Remove ffa_dev_ops_get()Sudeep Holla2022-09-081-9/+0
| | | | | | | | | | | | The only user of this exported ffa_dev_ops_get() was OPTEE driver which now uses ffa_dev->ops directly, there are no other users for this. Also, since any ffa driver can use ffa_dev->ops directly, there will be no need for ffa_dev_ops_get(), so just remove ffa_dev_ops_get(). Link: https://lore.kernel.org/r/20220907145240.1683088-4-sudeep.holla@arm.com Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Add pointer to the ffa_dev_ops in struct ffa_devSudeep Holla2022-09-081-1/+1
| | | | | | | | | | | | | | | | | | Currently ffa_dev_ops_get() is the way to fetch the ffa_dev_ops pointer. It checks if the ffa_dev structure pointer is valid before returning the ffa_dev_ops pointer. Instead, the pointer can be made part of the ffa_dev structure and since the core driver is incharge of creating ffa_device for each identified partition, there is no need to check for the validity explicitly if the pointer is embedded in the structure. Add the pointer to the ffa_dev_ops in the ffa_dev structure itself and initialise the same as part of creation of the device. Link: https://lore.kernel.org/r/20220907145240.1683088-2-sudeep.holla@arm.com Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Remove incorrect assignment of driver_dataSudeep Holla2022-04-291-2/+0
| | | | | | | | | | | | The ffa core driver currently assigns its own driver information to individual ffa device driver_data which is wrong. Firstly, it leaks this core driver information to individual ffa_device and hence to ffa_driver. Secondly the ffa_device driver_data is for use by individual ffa_driver and not for this core driver managing all those devices. Link: https://lore.kernel.org/r/20220429113946.2087145-2-sudeep.holla@arm.com Fixes: d0c0bce83122 ("firmware: arm_ffa: Setup in-kernel users of FFA partitions") Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Fix uuid parameter to ffa_partition_probeSudeep Holla2022-04-291-1/+1
| | | | | | | | | | | | | | | While we pass uuid_null intentionally to ffa_partition_probe in ffa_setup_partitions to get the count of the partitions, it must not be uuid_null in ffa_partition_info_get which is used by the ffa_drivers to fetch the specific partition info passing the UUID of the partition. Fix ffa_partition_info_get by passing the received uuid down to ffa_partition_probe so that the correct partition information is fetched. Link: https://lore.kernel.org/r/20220429113946.2087145-1-sudeep.holla@arm.com Fixes: d0c0bce83122 ("firmware: arm_ffa: Setup in-kernel users of FFA partitions") Reported-by: Arunachalam Ganapathy <arunachalam.ganapathy@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Fix handling of fragmented memory descriptorsMarc Bonnici2022-04-271-7/+13
| | | | | | | | | | | | | | | | | | | | | | Fix the handling of MEM_FRAG_TX/RX SMCs when the full memory descriptor does not fit in a single innovation of a memory sharing request. The current implementation expects a FFA_MEM_SHARE/FFA_MEM_LEND call to always receive a FFA_SUCCESS response, however in the case where a full descriptor does not fit inside the partitions TX buffer, the call can instead complete with a FFA_MEM_FRAG_RX SMC to request the next part of the descriptor to be transmitted. Similarly a FFA_MEM_FRAG_TX call currently only expects FFA_MEM_FRAG_RX as a response, however once the full descriptor has been transmitted the FFA_SUCCESS ABI will be used to indicate successful transmission. Update the existing code to match the expected behaviour. Link: https://lore.kernel.org/r/20220426121219.1801601-1-marc.bonnici@arm.com Signed-off-by: Marc Bonnici <marc.bonnici@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Remove unused 'compat_version' variableArnd Bergmann2021-10-261-1/+0
| | | | | | | | | | | | | The newly added ffa_compatible_version_find() function causes a build warning because of a variable that is never used: drivers/firmware/arm_ffa/driver.c:180:6: error: unused variable 'compat_version' [-Werror,-Wunused-variable] u32 compat_version; Link: https://lore.kernel.org/r/20211026083400.3444946-1-arnd@kernel.org Fixes: 8e3f9da608f1 ("firmware: arm_ffa: Handle compatibility with different firmware versions") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Add support for MEM_LENDMarc Bonnici2021-10-181-0/+17
| | | | | | | | | | | | | | | | | | | As part of the FF-A spec, an endpoint is allowed to transfer access of, or lend, a memory region to one or more borrowers. Extend the existing memory sharing implementation to support FF-A MEM_LEND functionality and expose this to other kernel drivers. Note that upon a successful MEM_LEND request the caller must ensure that the memory region specified is not accessed until a successful MEM_RECALIM call has been made. On systems with a hypervisor present this will been enforced, however on systems without a hypervisor the responsibility falls to the calling kernel driver to prevent access. Link: https://lore.kernel.org/r/20211015165742.2513065-1-marc.bonnici@arm.com Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Marc Bonnici <marc.bonnici@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Handle compatibility with different firmware versionsSudeep Holla2021-10-181-5/+32
| | | | | | | | | | | | | | | The driver currently just support v1.0 of Arm FFA specification. It also expects the firmware implementation to match the same and bail out if it doesn't match. This is causing issue when running with higher version of firmware implementation(e.g. v1.1 which will released soon). In order to support compatibility with different firmware versions, let us add additional checks and find the compatible version the driver can work with. Link: https://lore.kernel.org/r/20211013091127.990992-1-sudeep.holla@arm.com Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Fix a possible ffa_linux_errmap buffer overflowSudeep Holla2021-07-121-2/+4
| | | | | | | | | | | | | | | | The ffa_linux_errmap buffer access index is supposed to range from 0-8 but it ranges from 1-9 instead. It reads one element out of bounds. It also changes the success into -EINVAL though ffa_to_linux_errno is never used in case of success, it is expected to work for success case too. It is slightly confusing code as the negative of the error code is used as index to the buffer. Fix it by negating it at the start and make it more readable. Link: https://lore.kernel.org/r/20210707134739.1869481-1-sudeep.holla@arm.com Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 18:53:58 +0100