| cc0aac7c | 17-Jan-2025 |
Viresh Kumar <[email protected]> |
firmware: arm_ffa: Set dma_mask for ffa devices
Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer lead to following warning:
WARNING: CPU: 1 PID: 1 at kernel/dma/mappi
firmware: arm_ffa: Set dma_mask for ffa devices
Set dma_mask for FFA devices, otherwise DMA allocation using the device pointer lead to following warning:
WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124
Signed-off-by: Viresh Kumar <[email protected]> Message-Id: <e3dd8042ac680bd74b6580c25df855d092079c18.1737107520.git.viresh.kumar@linaro.org> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| c67c2332 | 23-Feb-2025 |
Sudeep Holla <[email protected]> |
firmware: arm_ffa: Skip the first/partition ID when parsing vCPU list
The FF-A notification id list received in response to the call FFA_NOTIFICATION_INFO_GET is encoded as: partition ID followed by
firmware: arm_ffa: Skip the first/partition ID when parsing vCPU list
The FF-A notification id list received in response to the call FFA_NOTIFICATION_INFO_GET is encoded as: partition ID followed by 0 or more vCPU ID. The count includes all of them.
Fix the issue by skipping the first/partition ID so that only the list of vCPU IDs are processed correctly for a given partition ID. The first/ partition ID is read before the start of the loop.
Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface") Reported-by: Andrei Homescu <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| 3e282f41 | 21-Feb-2025 |
Sudeep Holla <[email protected]> |
firmware: arm_ffa: Explicitly cast return value from NOTIFICATION_INFO_GET
The return value ret.a2 is of type unsigned long and FFA_RET_NO_DATA is a negative value.
Since the return value from the
firmware: arm_ffa: Explicitly cast return value from NOTIFICATION_INFO_GET
The return value ret.a2 is of type unsigned long and FFA_RET_NO_DATA is a negative value.
Since the return value from the firmware can be just 32-bit even on 64-bit systems as FFA specification mentions it as int32 error code in w0 register, explicitly casting to s32 ensures correct sign interpretation when comparing against a signed error code FFA_RET_NO_DATA.
Without casting, comparison between unsigned long and a negative constant could lead to unintended results due to type promotions.
Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface") Reported-by: Andrei Homescu <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| cecf6a50 | 21-Feb-2025 |
Sudeep Holla <[email protected]> |
firmware: arm_ffa: Explicitly cast return value from FFA_VERSION before comparison
The return value ver.a0 is unsigned long type and FFA_RET_NOT_SUPPORTED is a negative value.
Since the return valu
firmware: arm_ffa: Explicitly cast return value from FFA_VERSION before comparison
The return value ver.a0 is unsigned long type and FFA_RET_NOT_SUPPORTED is a negative value.
Since the return value from the firmware can be just 32-bit even on 64-bit systems as FFA specification mentions it as int32 error code in w0 register, explicitly casting to s32 ensures correct sign interpretation when comparing against a signed error code FFA_RET_NOT_SUPPORTED.
Without casting, comparison between unsigned long and a negative constant could lead to unintended results due to type promotions.
Fixes: 3bbfe9871005 ("firmware: arm_ffa: Add initial Arm FFA driver support") Reported-by: Andrei Homescu <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| 9472fe20 | 17-Feb-2025 |
Sudeep Holla <[email protected]> |
firmware: arm_ffa: Handle ffa_notification_get correctly at virtual FF-A instance
Currently it is assumed that the driver always calls ffa_notification_get() at the NS physical FF-A instance to requ
firmware: arm_ffa: Handle ffa_notification_get correctly at virtual FF-A instance
Currently it is assumed that the driver always calls ffa_notification_get() at the NS physical FF-A instance to request the SPMC to return pending SP or SPM Framework notifications. However, in order to support the driver invoking ffa_notification_get() at virtual FF-A instance, we need to make sure correct bits are enabled in the bitmaps enable flag.
It is expected to have hypervisor framework and VM notifications bitmap to be zero at the non-secure physical FF-A instance.
Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| be61da93 | 17-Feb-2025 |
Sudeep Holla <[email protected]> |
firmware: arm_ffa: Allow multiple UUIDs per partition to register SRI callback
A partition can implement multiple UUIDs and currently we successfully register each UUID service as a FF-A device. How
firmware: arm_ffa: Allow multiple UUIDs per partition to register SRI callback
A partition can implement multiple UUIDs and currently we successfully register each UUID service as a FF-A device. However when adding the same partition info to the XArray which tracks the SRI callbacks more than once, it fails.
In order to allow multiple UUIDs per partition to register SRI callbacks the partition information stored in the XArray needs to be extended to a listed list.
A function to remove the list of partition information in the XArray is not added as there are no users at the time. All the partitions are added at probe/initialisation and removed at cleanup stage.
Tested-by: Viresh Kumar <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| 285a5ea0 | 17-Feb-2025 |
Sudeep Holla <[email protected]> |
firmware: arm_ffa: Add support for handling framework notifications
Currently FF-A specification defines only one framework notification: RX buffer full notification. This notification is signaled b
firmware: arm_ffa: Add support for handling framework notifications
Currently FF-A specification defines only one framework notification: RX buffer full notification. This notification is signaled by the partition manager during transmission of a partition message through indirect messaging to,
1. Notify an endpoint that it has a pending message in its Rx buffer. 2. Inform the message receiver’s scheduler via the schedule receiver interrupt that the receiver must be run.
In response to an FFA_MSG_SEND2 invocation by a sender endpoint, the framework performs the following actions after the message is copied from the Tx buffer of the sender to the Rx buffer of the receiver:
1. The notification is pended in the framework notification bitmap of the receiver. 2. The partition manager of the endpoint that contains receiver’s scheduler pends the schedule receiver interrupt for this endpoint.
The receiver receives the notification and copies out the message from its Rx buffer.
Tested-by: Viresh Kumar <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| c10debfe | 17-Feb-2025 |
Sudeep Holla <[email protected]> |
firmware: arm_ffa: Add support for {un,}registration of framework notifications
Framework notifications are doorbells that are rung by the partition managers to signal common events to an endpoint.
firmware: arm_ffa: Add support for {un,}registration of framework notifications
Framework notifications are doorbells that are rung by the partition managers to signal common events to an endpoint. These doorbells cannot be rung by an endpoint directly. A partition manager can signal a Framework notification in response to an FF-A ABI invocation by an endpoint.
Two additional notify_ops interface is being added for any FF-A device/ driver to register and unregister for such a framework notifications.
Tested-by: Viresh Kumar <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| a3d73fe8 | 17-Feb-2025 |
Sudeep Holla <[email protected]> |
firmware: arm_ffa: Stash ffa_device instead of notify_type in notifier_cb_info
Currently, we store the type of the notification in the notifier_cb_info structure that is put into the hast list to id
firmware: arm_ffa: Stash ffa_device instead of notify_type in notifier_cb_info
Currently, we store the type of the notification in the notifier_cb_info structure that is put into the hast list to identify if the notification block is for the secure partition or the non secure VM.
In order to support framework notifications to reuse the hash list and to avoid creating one for each time, we need store the ffa_device pointer itself as the same notification ID in framework notifications can be registered by multiple FF-A devices.
Tested-by: Viresh Kumar <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| 07b760e7 | 17-Feb-2025 |
Sudeep Holla <[email protected]> |
firmware: arm_ffa: Refactoring to prepare for framework notification support
Currently, the framework notifications are not supported at all. handle_notif_callbacks() doesn't handle them though it i
firmware: arm_ffa: Refactoring to prepare for framework notification support
Currently, the framework notifications are not supported at all. handle_notif_callbacks() doesn't handle them though it is called with framework bitmap. Make that explicit by adding checks for the same.
Also, we need to further classify the framework notifications as Secure Partition Manager(SPM) and NonSecure Hypervisor(NS_HYP). Extend/change notify_type enumeration to accommodate all the 4 type and rejig the values so that it can be reused in the bitmap enable mask macros.
While at this, move ffa_notify_type_get() so that it can be used in notifier_hash_node_get() in the future.
No functional change.
Tested-by: Viresh Kumar <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| 9982cabf | 17-Feb-2025 |
Sudeep Holla <[email protected]> |
firmware: arm_ffa: Remove unnecessary declaration of ffa_partitions_cleanup()
In order to keep the uniformity, just move the ffa_partitions_cleanup() before it's first usage and drop the unnecessary
firmware: arm_ffa: Remove unnecessary declaration of ffa_partitions_cleanup()
In order to keep the uniformity, just move the ffa_partitions_cleanup() before it's first usage and drop the unnecessary forward declaration.
No functional change.
Tested-by: Viresh Kumar <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| efff6a7f | 17-Feb-2025 |
Sudeep Holla <[email protected]> |
firmware: arm_ffa: Reject higher major version as incompatible
When the firmware compatibility was handled previously in the commit 8e3f9da608f1 ("firmware: arm_ffa: Handle compatibility with differ
firmware: arm_ffa: Reject higher major version as incompatible
When the firmware compatibility was handled previously in the commit 8e3f9da608f1 ("firmware: arm_ffa: Handle compatibility with different firmware versions"), we only addressed firmware versions that have higher minor versions compared to the driver version which is should be considered compatible unless the firmware returns NOT_SUPPORTED.
However, if the firmware reports higher major version than the driver supported, we need to reject it. If the firmware can work in a compatible mode with the driver requested version, it must return the same major version as requested.
Tested-by: Viresh Kumar <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| 46dcd68a | 17-Feb-2025 |
Sudeep Holla <[email protected]> |
firmware: arm_ffa: Unregister the FF-A devices when cleaning up the partitions
Both the FF-A core and the bus were in a single module before the commit 18c250bd7ed0 ("firmware: arm_ffa: Split bus an
firmware: arm_ffa: Unregister the FF-A devices when cleaning up the partitions
Both the FF-A core and the bus were in a single module before the commit 18c250bd7ed0 ("firmware: arm_ffa: Split bus and driver into distinct modules").
The arm_ffa_bus_exit() takes care of unregistering all the FF-A devices. Now that there are 2 distinct modules, if the core driver is unloaded and reloaded, it will end up adding duplicate FF-A devices as the previously registered devices weren't unregistered when we cleaned up the modules.
Fix the same by unregistering all the FF-A devices on the FF-A bus during the cleaning up of the partitions and hence the cleanup of the module.
Fixes: 18c250bd7ed0 ("firmware: arm_ffa: Split bus and driver into distinct modules") Tested-by: Viresh Kumar <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| 2f622a8b | 17-Feb-2025 |
Sudeep Holla <[email protected]> |
firmware: arm_ffa: Handle the presence of host partition in the partition info
Currently it is assumed that the firmware doesn't present the host partition in the list of partitions presented as par
firmware: arm_ffa: Handle the presence of host partition in the partition info
Currently it is assumed that the firmware doesn't present the host partition in the list of partitions presented as part of the response to PARTITION_INFO_GET from the firmware. However, there are few platforms that prefer to present the same in the list of partitions. It is not manadatory but not restricted as well.
So handle the same by making sure to check the presence of the host VM ID in the XArray partition information maintained/managed in the driver before attempting to add it.
Tested-by: Viresh Kumar <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| 3c3d6767 | 17-Feb-2025 |
Viresh Kumar <[email protected]> |
firmware: arm_ffa: Refactor addition of partition information into XArray
Move the common code handling addition of the FF-A partition information into the XArray as a new routine. No functional cha
firmware: arm_ffa: Refactor addition of partition information into XArray
Move the common code handling addition of the FF-A partition information into the XArray as a new routine. No functional change.
Signed-off-by: Viresh Kumar <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| 7bc0f589 | 17-Feb-2025 |
Sudeep Holla <[email protected]> |
firmware: arm_ffa: Fix big-endian support in __ffa_partition_info_regs_get()
Currently the FF-A driver doesn't support big-endian correctly. It is hard to regularly test the setup due to lack of tes
firmware: arm_ffa: Fix big-endian support in __ffa_partition_info_regs_get()
Currently the FF-A driver doesn't support big-endian correctly. It is hard to regularly test the setup due to lack of test infrastructure and tools.
In order to support full stack, we need to take small steps in getting the support for big-endian kernel added slowly. This change fixes the support in __ffa_partition_info_regs_get() so that the response from the firmware are converted correctly as required. With this change, we can enumerate all the FF-A devices correctly in the big-endian kernel if the FFA_PARTITION_INFO_REGS_GET is supported.
Tested-by: Viresh Kumar <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| f94ebb72 | 17-Feb-2025 |
Sudeep Holla <[email protected]> |
firmware: arm_ffa: Fix big-endian support in __ffa_partition_info_get()
Currently the FF-A driver doesn't support big-endian correctly. It is hard to regularly test the setup due to lack of test inf
firmware: arm_ffa: Fix big-endian support in __ffa_partition_info_get()
Currently the FF-A driver doesn't support big-endian correctly. It is hard to regularly test the setup due to lack of test infrastructure and tools.
In order to support full stack, we need to take small steps in getting the support for big-endian kernel added slowly. This change fixes the support in __ffa_partition_info_get() so that the response from the firmware are converted correctly as required. With this change, we can enumerate all the FF-A devices correctly in the big-endian kernel.
Tested-by: Viresh Kumar <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| 8768972c | 17-Feb-2025 |
Sudeep Holla <[email protected]> |
firmware: arm_ffa: Align sync_send_receive{,2} function prototypes
Currently ffa_sync_send_receive2() takes UUID as a separate parameter instead of using the one available in ffa_device structure.
firmware: arm_ffa: Align sync_send_receive{,2} function prototypes
Currently ffa_sync_send_receive2() takes UUID as a separate parameter instead of using the one available in ffa_device structure.
Change the prototype of ffa_sync_send_receive2() to align with the ffa_sync_send_receive() and use ffa_device->uuid.
Tested-by: Viresh Kumar <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| b7c9f326 | 17-Feb-2025 |
Sudeep Holla <[email protected]> |
firmware: arm_ffa: Replace UUID buffer to standard UUID format
Currently ffa_partition_info structure holds the UUID in the format compatible with the firmware interface. However, most of the functi
firmware: arm_ffa: Replace UUID buffer to standard UUID format
Currently ffa_partition_info structure holds the UUID in the format compatible with the firmware interface. However, most of the functions in the FF-A core driver deals directly with uuid_t type.
Replace UUID buffer to standard UUID format in the ffa_partition_info structure.
Tested-by: Viresh Kumar <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|
| b0798838 | 14-Oct-2024 |
Gavin Shan <[email protected]> |
firmware: arm_ffa: Avoid string-fortify warning caused by memcpy()
Copying from a 144 byte structure arm_smccc_1_2_regs at an offset of 32 into an 112 byte struct ffa_send_direct_data2 causes a comp
firmware: arm_ffa: Avoid string-fortify warning caused by memcpy()
Copying from a 144 byte structure arm_smccc_1_2_regs at an offset of 32 into an 112 byte struct ffa_send_direct_data2 causes a compile-time warning:
| In file included from drivers/firmware/arm_ffa/driver.c:25: | In function 'fortify_memcpy_chk', | inlined from 'ffa_msg_send_direct_req2' at drivers/firmware/arm_ffa/driver.c:504:3: | include/linux/fortify-string.h:580:4: warning: call to '__read_overflow2_field' | declared with 'warning' attribute: detected read beyond size of field | (2nd parameter); maybe use struct_group()? [-Wattribute-warning] | __read_overflow2_field(q_size_field, size);
Fix it by not passing a plain buffer to memcpy() to avoid the overflow warning.
Fixes: aaef3bc98129 ("firmware: arm_ffa: Add support for FFA_MSG_SEND_DIRECT_{REQ,RESP}2") Signed-off-by: Gavin Shan <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sudeep Holla <[email protected]>
show more ...
|