public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
To: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>, Simon Glass <sjg@chromium.org>,
	Jens Wiklander <jens.wiklander@linaro.org>,
	Hugues Kamba Mpiana <Hugues.KambaMpiana@arm.com>,
	u-boot@lists.denx.de
Subject: Re: [PATCH 3/8] arm_ffa: Add FFA_MEM_RECLAIM support
Date: Mon, 4 Nov 2024 11:22:04 +0000	[thread overview]
Message-ID: <20241104112204.GA68550@e130802.arm.com> (raw)
In-Reply-To: <ZyTx9rECRTWfZDf1@hera>

Hi Ilias,

> > +/**
> > + * ffa_memory_reclaim_hdlr() - FFA_MEM_RECLAIM handler function
> > + * @dev: The FF-A bus device
> > + * @g_handle: The memory region globally unique Handle
> > + * @flags: Zero memory and time slicing flags
> > + *
> > + * Implement FFA_MEM_RECLAIM FF-A function
> > + * to restore exclusive access to a memory region back to its Owner.
> > + *
> > + * Return:
> > + *
> > + * 0 on success. Otherwise, failure
> > + */
> > +int ffa_memory_reclaim_hdlr(struct udevice *dev, u64 g_handle, u32 flags)
> > +{
> > +	ffa_value_t res;
> > +	int ffa_errno;
> > +
> > +	invoke_ffa_fn((ffa_value_t){
> > +			.a0 = FFA_SMC_32(FFA_MEM_RECLAIM),
> > +			.a1 = HANDLE_LOW(g_handle), .a2 = HANDLE_HIGH(g_handle),
> > +			.a3 = flags,
> > +			},
> > +			&res
> > +	);
> > +
> > +	if (res.a0 != FFA_SMC_32(FFA_SUCCESS)) {
> > +		ffa_errno = res.a2;
> > +		ffa_print_error_log(FFA_MEM_RECLAIM, ffa_errno);
> > +		return ffa_to_std_errno(ffa_errno);
> > +	}
> > +
> > +	return 0;
> > +}
> 
> Is there a reason you have to define both ffa_memory_reclaim_hdlr() and ffa_memory_reclaim()?
> Can't you just move the checks of ffa_memory_reclaim() to
> ffa_memory_reclaim_hdlr()?

Yes, ffa_memory_reclaim() is the FF-A bus operation which is called by upper layers (clients).

ffa_memory_reclaim_hdlr() is the low level handler called by the operation.

The handler is set by the driver (e.g: Arm driver, sandbox driver) in the driver's ops structure [5].

So, the driver can set the handler and define its own if needed.

The client doesn't know which handler to use. It just calls the driver operation.

This design was followed in the other ABIs already merged. For example [1][2][3][4].

[1]: ffa_rxtx_unmap() operation: drivers/firmware/arm-ffa/arm-ffa-uclass.c#L999
[2]: ffa_unmap_rxtx_buffers_hdlr() handler: drivers/firmware/arm-ffa/arm-ffa-uclass.c#L999
[3]: rxtx_unmap ops callback in sandbox driver: drivers/firmware/arm-ffa/sandbox_ffa.c#L93
[4]: rxtx_unmap ops callback in Arm driver: drivers/firmware/arm-ffa/arm-ffa.c#L86
[5]: Arm's driver ops structure: drivers/firmware/arm-ffa/arm-ffa.c#L83

> > +
> >  /* FF-A driver operations (used by clients for communicating with FF-A)*/
> > ...
> > +/**
> > + * ffa_memory_reclaim() - FFA_MEM_RECLAIM driver operation
> > + * @dev: The FF-A bus device
> > + * @g_handle: The memory region globally unique Handle
> > + * @flags: Zero memory and time slicing flags
> > + *
> > + * Driver operation for FFA_MEM_RECLAIM.
> > + * Please see ffa_memory_reclaim_hdlr() description for more details.
> > + *
> > + * Return:
> > + *
> > + * 0 on success. Otherwise, failure
> > + */
> > +int ffa_memory_reclaim(struct udevice *dev, u64 g_handle, u32 flags)
> > +{
> > +	struct ffa_bus_ops *ops = ffa_get_ops(dev);
> > +
> > +	if (!ops || !ops->memory_reclaim)
> > +		return -ENOSYS;
> > +
> > +	return ops->memory_reclaim(dev, g_handle, flags);
> > +}

Cheers,
Abdellatif

  reply	other threads:[~2024-11-04 11:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-01 14:20 [PATCH 0/8] arm_ffa: Add FFA_MEM_SHARE and FFA_MEM_RECLAIM support abdellatif.elkhlifi
2024-11-01 14:20 ` [PATCH 1/8] arm_ffa: Add NULL pointer check to the driver operations abdellatif.elkhlifi
2024-11-01 15:14   ` Ilias Apalodimas
2024-11-04 12:48   ` Jens Wiklander
2024-11-01 14:20 ` [PATCH 2/8] arm_ffa: Add FFA_MEM_SHARE support abdellatif.elkhlifi
2024-11-01 14:20 ` [PATCH 3/8] arm_ffa: Add FFA_MEM_RECLAIM support abdellatif.elkhlifi
2024-11-01 15:21   ` Ilias Apalodimas
2024-11-04 11:22     ` Abdellatif El Khlifi [this message]
2024-11-01 14:20 ` [PATCH 4/8] arm_ffa: sandbox: Replace the emulator error log with debug log abdellatif.elkhlifi
2024-11-01 15:16   ` Ilias Apalodimas
2024-11-01 14:20 ` [PATCH 5/8] arm_ffa: sandbox: Add FFA_MEM_SHARE emulation abdellatif.elkhlifi
2024-11-01 14:20 ` [PATCH 6/8] arm_ffa: sandbox: Add FFA_MEM_SHARE tests abdellatif.elkhlifi
2024-11-01 14:20 ` [PATCH 7/8] arm_ffa: sandbox: Add FFA_MEM_RECLAIM emulation abdellatif.elkhlifi
2024-11-01 14:20 ` [PATCH 8/8] arm_ffa: sandbox: Add FFA_MEM_RECLAIM tests abdellatif.elkhlifi
2024-11-07 15:33 ` [PATCH 0/8] arm_ffa: Add FFA_MEM_SHARE and FFA_MEM_RECLAIM support Abdellatif El Khlifi
2024-11-20 13:13   ` Abdellatif El Khlifi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241104112204.GA68550@e130802.arm.com \
    --to=abdellatif.elkhlifi@arm.com \
    --cc=Hugues.KambaMpiana@arm.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=jens.wiklander@linaro.org \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox