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.
"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.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel