summaryrefslogtreecommitdiffstats
path: root/drivers/firmware/arm_ffa
Commit message (Collapse)AuthorAgeFilesLines
* 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: Emit modalias for FF-A devicesSudeep Holla2023-10-061-1/+14
| | | | | | | | | | In order to enable libkmod lookups for FF-A device objects to their corresponding module, add 'modalias' to the base attribute of FF-A devices. Tested-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> Link: https://lore.kernel.org/r/20231005175640.379631-1-sudeep.holla@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: Assign the missing IDR allocation ID to the FFA deviceSudeep Holla2023-10-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 19b8766459c4 ("firmware: arm_ffa: Fix FFA device names for logical partitions") added an ID to the FFA device using ida_alloc() and append the same to "arm-ffa" to make up a unique device name. However it missed to stash the id value in ffa_dev to help freeing the ID later when the device is destroyed. Due to the missing/unassigned ID in FFA device, we get the following warning when the FF-A device is unregistered. | ida_free called for id=0 which is not allocated. | WARNING: CPU: 7 PID: 1 at lib/idr.c:525 ida_free+0x114/0x164 | CPU: 7 PID: 1 Comm: swapper/0 Not tainted 6.6.0-rc4 #209 | pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : ida_free+0x114/0x164 | lr : ida_free+0x114/0x164 | Call trace: | ida_free+0x114/0x164 | ffa_release_device+0x24/0x3c | device_release+0x34/0x8c | kobject_put+0x94/0xf8 | put_device+0x18/0x24 | klist_devices_put+0x14/0x20 | klist_next+0xc8/0x114 | bus_for_each_dev+0xd8/0x144 | arm_ffa_bus_exit+0x30/0x54 | ffa_init+0x68/0x330 | do_one_initcall+0xdc/0x250 | do_initcall_level+0x8c/0xac | do_initcalls+0x54/0x94 | do_basic_setup+0x1c/0x28 | kernel_init_freeable+0x104/0x170 | kernel_init+0x20/0x1a0 | ret_from_fork+0x10/0x20 Fix the same by actually assigning the ID in the FFA device this time for real. Fixes: 19b8766459c4 ("firmware: arm_ffa: Fix FFA device names for logical partitions") Link: https://lore.kernel.org/r/20231003085932.3553985-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 FFA device names for logical partitionsSudeep Holla2023-05-081-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Each physical partition can provide multiple services each with UUID. Each such service can be presented as logical partition with a unique combination of VM ID and UUID. The number of distinct UUID in a system will be less than or equal to the number of logical partitions. However, currently it fails to register more than one logical partition or service within a physical partition as the device name contains only VM ID while both VM ID and UUID are maintained in the partition information. The kernel complains with the below message: | sysfs: cannot create duplicate filename '/devices/arm-ffa-8001' | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc7 #8 | Hardware name: FVP Base RevC (DT) | Call trace: | dump_backtrace+0xf8/0x118 | show_stack+0x18/0x24 | dump_stack_lvl+0x50/0x68 | dump_stack+0x18/0x24 | sysfs_create_dir_ns+0xe0/0x13c | kobject_add_internal+0x220/0x3d4 | kobject_add+0x94/0x100 | device_add+0x144/0x5d8 | device_register+0x20/0x30 | ffa_device_register+0x88/0xd8 | ffa_setup_partitions+0x108/0x1b8 | ffa_init+0x2ec/0x3a4 | do_one_initcall+0xcc/0x240 | do_initcall_level+0x8c/0xac | do_initcalls+0x54/0x94 | do_basic_setup+0x1c/0x28 | kernel_init_freeable+0x100/0x16c | kernel_init+0x20/0x1a0 | ret_from_fork+0x10/0x20 | kobject_add_internal failed for arm-ffa-8001 with -EEXIST, don't try to | register things with the same name in the same directory. | arm_ffa arm-ffa: unable to register device arm-ffa-8001 err=-17 | ARM FF-A: ffa_setup_partitions: failed to register partition ID 0x8001 By virtue of being random enough to avoid collisions when generated in a distributed system, there is no way to compress UUID keys to the number of bits required to identify each. We can eliminate '-' in the name but it is not worth eliminating 4 bytes and add unnecessary logic for doing that. Also v1.0 doesn't provide the UUID of the partitions which makes it hard to use the same for the device name. So to keep it simple, let us alloc an ID using ida_alloc() and append the same to "arm-ffa" to make up a unique device name. Also stash the id value in ffa_dev to help freeing the ID later when the device is destroyed. Fixes: e781858488b9 ("firmware: arm_ffa: Add initial FFA bus support for device enumeration") Reported-by: Lucian Paul-Trifu <lucian.paul-trifu@arm.com> Link: https://lore.kernel.org/r/20230419-ffa_fixes_6-4-v2-3-d9108e43a176@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: Check if ffa_driver remove is present before executingSudeep Holla2023-05-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently ffa_drv->remove() is called unconditionally from ffa_device_remove(). Since the driver registration doesn't check for it and allows it to be registered without .remove callback, we need to check for the presence of it before executing it from ffa_device_remove() to above a NULL pointer dereference like the one below: | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | Mem abort info: | ESR = 0x0000000086000004 | EC = 0x21: IABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x04: level 0 translation fault | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881cc8000 | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 | Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP | CPU: 3 PID: 130 Comm: rmmod Not tainted 6.3.0-rc7 #6 | Hardware name: FVP Base RevC (DT) | pstate: 63402809 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=-c) | pc : 0x0 | lr : ffa_device_remove+0x20/0x2c | Call trace: | 0x0 | device_release_driver_internal+0x16c/0x260 | driver_detach+0x90/0xd0 | bus_remove_driver+0xdc/0x11c | driver_unregister+0x30/0x54 | ffa_driver_unregister+0x14/0x20 | cleanup_module+0x18/0xeec | __arm64_sys_delete_module+0x234/0x378 | invoke_syscall+0x40/0x108 | el0_svc_common+0xb4/0xf0 | do_el0_svc+0x30/0xa4 | el0_svc+0x2c/0x7c | el0t_64_sync_handler+0x84/0xf0 | el0t_64_sync+0x190/0x194 Fixes: 244f5d597e1e ("firmware: arm_ffa: Add missing remove callback to ffa_bus_type") Link: https://lore.kernel.org/r/20230419-ffa_fixes_6-4-v2-1-d9108e43a176@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* driver core: make struct bus_type.uevent() take a const *Greg Kroah-Hartman2023-01-271-2/+2
| | | | | | | | | | | | The uevent() callback in struct bus_type should not be modifying the device that is passed into it, so mark it as a const * and propagate the function signature changes out into all relevant subsystems that use this callback. Acked-by: Rafael J. Wysocki <rafael@kernel.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230111113018.459199-16-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* 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-082-2/+2
| | | | | | | | | | | | | | 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-082-2/+4
| | | | | | | | | | | | | | | | | | 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 __ffa_devices_unregisterSudeep Holla2021-10-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When arm_ffa firmware driver module is unloaded or removed we call __ffa_devices_unregister on all the devices on the ffa bus. It must unregister all the devices instead it is currently just releasing the devices without unregistering. That is pure wrong as when we try to load the module back again, it will result in the kernel crash something like below. -->8 CPU: 2 PID: 232 Comm: modprobe Not tainted 5.15.0-rc2+ #169 Hardware name: FVP Base RevC (DT) Call trace: dump_backtrace+0x0/0x1cc show_stack+0x18/0x64 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 sysfs_create_dir_ns+0xe4/0x140 kobject_add_internal+0x170/0x358 kobject_add+0x94/0x100 device_add+0x178/0x5f0 device_register+0x20/0x30 ffa_device_register+0x80/0xcc [ffa_module] ffa_setup_partitions+0x7c/0x108 [ffa_module] init_module+0x290/0x2dc [ffa_module] do_one_initcall+0xbc/0x230 do_init_module+0x58/0x304 load_module+0x15e0/0x1f68 __arm64_sys_finit_module+0xb8/0xf4 invoke_syscall+0x44/0x140 el0_svc_common+0xb4/0xf0 do_el0_svc+0x24/0x80 el0_svc+0x20/0x50 el0t_64_sync_handler+0x84/0xe4 el0t_64_sync+0x1a0/0x1a4 kobject_add_internal failed for arm-ffa-8001 with -EEXIST, don't try to register things with the same name in the same directory. ---- Fix the issue by calling device_unregister in __ffa_devices_unregister which will also take care of calling device_release(which is mapped to ffa_release_device) Link: https://lore.kernel.org/r/20210924092859.3057562-2-sudeep.holla@arm.com Fixes: e781858488b9 ("firmware: arm_ffa: Add initial FFA bus support for device enumeration") Tested-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Add missing remove callback to ffa_bus_typeSudeep Holla2021-10-051-0/+8
| | | | | | | | | | | | | | | | | | Currently the arm_ffa firmware driver can be built as module and hence all the users of FFA driver. If any driver on the ffa bus is removed or unregistered, the remove callback on all the device bound to the driver being removed should be callback. For that to happen, we must register a remove callback on the ffa_bus which is currently missing. This results in the probe getting called again without the previous remove callback on a device which may result in kernel crash. Fix the issue by registering the remove callback on the FFA bus. Link: https://lore.kernel.org/r/20210924092859.3057562-1-sudeep.holla@arm.com Fixes: e781858488b9 ("firmware: arm_ffa: Add initial FFA bus support for device enumeration") Reported-by: Jens Wiklander <jens.wiklander@linaro.org> Tested-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>
* firmware: arm_ffa: Fix the comment styleSudeep Holla2021-07-121-1/+1
| | | | | | | | | | | | | | | | clang produces the following warning: drivers/firmware/arm_ffa/driver.c:123: warning: expecting prototype for FF(). Prototype was for FFA_PAGE_SIZE() instead This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Fix the same by removing the kernel-doc style comment here. Link: https://lore.kernel.org/r/20210622162202.3485866-1-sudeep.holla@arm.com Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Simplify probe functionUwe Kleine-König2021-07-121-3/+0
| | | | | | | | | When the driver core calls the probe callback it already checked that the devices match, so there is no need to call the match callback again. Link: https://lore.kernel.org/r/20210621201652.127611-2-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Ensure drivers provide a probe functionUwe Kleine-König2021-07-121-0/+3
| | | | | | | | | | | The bus probe callback calls the driver callback without further checking. Better be safe than sorry and refuse registration of a driver without a probe function to prevent a NULL pointer exception. Link: https://lore.kernel.org/r/20210621201652.127611-1-u.kleine-koenig@pengutronix.de Fixes: e781858488b9 ("firmware: arm_ffa: Add initial FFA bus support for device enumeration") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Add support for MEM_* interfacesSudeep Holla2021-05-261-0/+199
| | | | | | | | | | Most of the MEM_* APIs share the same parameters, so they can be generalised. Currently only MEM_SHARE is implemented and the user space interface for that is not added yet. Link: https://lore.kernel.org/r/20210521151033.181846-6-sudeep.holla@arm.com Tested-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_ffa: Setup in-kernel users of FFA partitionsSudeep Holla2021-05-263-0/+233
| | | | | | | | | | | | | | | Parse the FFA nodes from the device-tree and register all the partitions whose services will be used in the kernel. In order to also enable in-kernel users of FFA interface, let us add simple set of operations for such devices. The in-kernel users are registered without the character device interface. Link: https://lore.kernel.org/r/20210521151033.181846-5-sudeep.holla@arm.com Tested-by: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-07 11:37:18 +0000