[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