[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

On 06.02.18 17:39, Julien Grall wrote:

On 02/06/2018 03:28 PM, Volodymyr Babchuk wrote:
Hi Julien,

On 06.02.18 16:45, Julien Grall wrote:

+ * PSCI 0.2 or later calls. It will return false if the function ID is
+ * not handled.
+ */
+bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid)
+    /*
+     * /!\ VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated when
+     * adding/removing a function
+     */
Should we also update revision of SSSC interface as well? SMCCC requires this.

Meh, you can't rely on the SSSC revision most of the time as the version for PSCI is done through PSCI_get_version. I can add a comment if you want.

Yes, I agree with you. But section 5.4 of SMCCC 1.0 applies to SSSC as well. So you can write something like "ARM SMCCC requires that SSSC revision and function call count should be updated every time you add or remove a function"

Usually we update versioning number only once per release. I would follow the same approach for this one. So I would suggest

It is not stated clearly in SMCCC, but I've got a felling that revision belongs not to product version, but to SMC interface version. So I see no reason to change revision, if there was no changes to interface itself.
I'm okay witch changing revision only one time per release, but only
if there was changes to PSCI interface. On other hand, person
responsible for release need to track if there was any changes in PSCI
and act accordingly. This is not very convenient.
So, I would prefer to change revision in the same patch (or patch series) which alters the interface.
At the end of the day this is closely tie to product revision. A new revision may produce change in the implementation and therefore the version will be bumped. But there are always exception when you do a release just for bug fix.

This is the same for Xen, we only change interface version if something major as changed. If nothing, then the version stays the same.

Then I'm okay with this. I just wanted to sure that we are on the same page.

"VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated when adding removing a function. SSCCC_SMCCC_*_REVISION should be updated once per Xen release".

And who will be responsible for this?

The first patch modifying the SMCCC implementation after the tree is re-opened. This is how we deal the rest of the versions in Xen, and it works.

I'm good with this then.

Volodymyr Babchuk

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.