Re: [PATCH v17 4/7] firmware: arm_rmm: Add support for SRO

[Suzuki K Poulose]

On 10/09/2026 10:51, Suzuki K Poulose wrote:
> Hi Gavin
>
> Thank you for the the review, much appreciated. Responses inline.
>
>
> On 09/09/2026 05:10, Gavin Shan wrote:
> > Hi Suzuki,
>
> > > +
> > > +    sro->addr_count = 0;
> > > +}
> > > +EXPORT_SYMBOL_GPL(rmi_sro_free);
> > > +
> > > +long rmi_sro_memxfer_execute(struct rmi_sro_state *sro, gfp_t gfp)
> > > +{
> > > +    unsigned long sro_handle;
> > > +    struct arm_smccc_1_2_regs *regs = &sro->regs;
> > > +    bool cancelled = false;
> > > +
> > > +    rmi_smccc_invoke(regs, regs);
> > > +
> > > +    sro_handle = regs->a1;
> > > +
> > > +    while (RMI_RETURN_STATUS(regs->a0) == RMI_INCOMPLETE) {
> > > +        bool can_cancel = RMI_RETURN_CAN_CANCEL(regs->a0);
> > > +        int ret = 0;
> > > +
> >
> > Strictly speaking, we need to refresh the SRO handle after every RMI 
> > call.
> >
> >          bool can_cancel = RMI_RETURN_CAN_CANCEL(regs->a0);
> >          unsigned long sro_handle = regs->a1;
> >          int ret = 0;
>
> Ack for both instances

This is not correct. e.g., after RMI_OP_MEM_DONATE and 
RMI_OP_MEM_RECLAIM, the regs->a1 is the number of granules consumed or 
reclaimed. The SRO handle once provided by an SRO triggering operation,
is invalidated by the RMI_OP_CONTINUE() running to completion.
i.e., RMI_OP_CONTINUE either completes with RMI_SUCCESS

OR

completes with a status other than RMI_BUSY or RMI_INCOMPLETE.

Thanks
Suzuki