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>

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>

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>

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>

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>

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>

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>

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>

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>

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>