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

[Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>]

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.
> "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?

--
Volodymyr Babchuk

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel