Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Jens Wiklander <jens.wiklander@linaro.org>
Cc: Trilok Soni <tsoni@codeaurora.org>,
	devicetree@vger.kernel.org, David Hartley <dhh@qti.qualcomm.com>,
	Andrew Walbran <qwandor@google.com>,
	Achin Gupta <Achin.Gupta@arm.com>,
	arve@android.com, Sudeep Holla <sudeep.holla@arm.com>,
	Arunachalam Ganapathy <arunachalam.ganapathy@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 6/7] firmware: arm_ffa: Setup in-kernel users of FFA partitions
Date: Wed, 13 Jan 2021 09:22:36 +0000	[thread overview]
Message-ID: <20210113092236.pnabzaufzuzwprmw@bogus> (raw)
In-Reply-To: <20201207123018.GA1748888@jade>

On Mon, Dec 07, 2020 at 01:30:18PM +0100, Jens Wiklander wrote:
> Hi Sudeep,
> 
> Some comments below.
> 
> On Fri, Dec 04, 2020 at 12:11:36PM +0000, Sudeep Holla wrote:

[...]

> > +
> > +int ffa_setup_partitions(struct device_node *np)
> > +{
> > +	int ret;
> > +	struct device_node *child;
> > +	struct ffa_device *ffa_dev;
> > +	struct ffa_partition_info pbuf;
> > +	const char *p_uuid, *pfx = "Ignoring FFA partition";
> > +	uuid_t uuid = UUID_INIT(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);
> > +
> > +	for_each_child_of_node(np, child) {
> 
> The spec says:
> – If the Nil UUID is specified at the Non-secure virtual FF-A instance,
>   the Hypervisor must provide information for partitions resident in both
>   security states.
>

That was my initial understanding of the specification. However I was told
it is designed mostly for Non-Secure Hypervisor for getting the list of
secure partitions and help in allocation of non-secure partition/endpoint IDs.
This has been topic of discussion recently.

> Doesn't that make this redundant?
>

Not exactly. One main reason why the discovery API (get partition info) is
not much useful here in this context is that it lacks UUID and hence not much
of use unless you know UUID. The result we get for Nil UUID needs to be mapped
to UUID and I can't think of anyway to do so outside the scope of the spec.
I have raised it but not sure if there is a strong requirement to add it.

Similarly, I would have like 32 vs 64 bit capable partition info from there
ideally, but we are here now.

-- 
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-01-13  9:24 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-04 12:11 [PATCH v3 0/7] firmware: Add initial support for Arm FF-A Sudeep Holla
2020-12-04 12:11 ` [PATCH v3 1/7] dt-bindings: Arm: Add Firmware Framework for Armv8-A (FF-A) binding Sudeep Holla
2020-12-14 22:01   ` Rob Herring
2020-12-16 12:24     ` Sudeep Holla
2020-12-16 13:46       ` Jens Wiklander
2021-01-13 10:00       ` Sudeep Holla
2020-12-04 12:11 ` [PATCH v3 2/7] arm64: smccc: Add support for SMCCCv1.2 input/output registers Sudeep Holla
2020-12-04 12:11 ` [PATCH v3 3/7] firmware: arm_ffa: Add initial FFA bus support for device enumeration Sudeep Holla
2020-12-04 12:11 ` [PATCH v3 4/7] firmware: arm_ffa: Add initial Arm FFA driver support Sudeep Holla
2020-12-04 12:11 ` [PATCH v3 5/7] firmware: arm_ffa: Add support for SMCCC as transport to FFA driver Sudeep Holla
2020-12-04 12:11 ` [PATCH v3 6/7] firmware: arm_ffa: Setup in-kernel users of FFA partitions Sudeep Holla
2020-12-07 12:30   ` Jens Wiklander
2021-01-13  9:22     ` Sudeep Holla [this message]
2020-12-11 10:45   ` Jens Wiklander
2020-12-11 10:59     ` Jens Wiklander
2021-01-13  9:44       ` Sudeep Holla
2021-01-13 12:30         ` Jens Wiklander
2021-01-13 13:58           ` Achin Gupta
2021-01-13 17:20             ` Sudeep Holla
2021-01-14  6:48               ` Jens Wiklander
2021-01-12 18:04     ` Sudeep Holla
2021-01-13  7:10       ` Jens Wiklander
2020-12-04 12:11 ` [PATCH v3 7/7] firmware: arm_ffa: Add support for MEM_* interfaces Sudeep Holla
2020-12-11 10:54   ` Jens Wiklander

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=20210113092236.pnabzaufzuzwprmw@bogus \
    --to=sudeep.holla@arm.com \
    --cc=Achin.Gupta@arm.com \
    --cc=arunachalam.ganapathy@arm.com \
    --cc=arve@android.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dhh@qti.qualcomm.com \
    --cc=jens.wiklander@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=qwandor@google.com \
    --cc=tsoni@codeaurora.org \
    /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