Re: [PATCH] firmware: arm_scmi: add timeout in do_xfer_with_response()

["Matthew Bystrin" <dev.mbstr@gmail.com>]

Sudeep,

Thanks for taking your time.

Sudeep Holla, Apr 09, 2025 at 14:12:
> The start update should retain as soon as Platform uC acks the request.
> And 2 notifications can be sent out for update procedure started and
> completed. I don't see any issue there. What is the semantics you are
> talking about ?

I'm going to refer to section 4.1.1 from the spec, where stated following about
delayed responses,

"Messages sent to indicate completion of the work that is associated with an
asynchronous command" 

Compared to notifications,

"These messages provide notifications of events taking place in the platform.
Events might include changes in power state, performance state, or other
platform status"

So before I implemented mentioned driver I had red this two and had chosen
delayed responses, because it had seemed more appropriate. Details below.

> Even delayed response as some timeout so I would rather prefer to use
> notifications

Hmm, I see.

> in your usecase as it is completely async.

Just to emphasize, according to the spec I don't think that delayed responses
and events have different degree of asynchrony. The difference is in the
initiator of 'messaging'. Events are sent by platform to indicate its' state and
delayed responses are sent to indicate status of previously requested operation.

I used the latter, because firmware update can't happen spontaneously. That what
I meant when used term 'semantics'.

> Yes neither per-transport nor per-protocol timeout will suffice in your case.
> This 10s timeout is specific to the update operation and hence use
> notification. All other solution is just workarounds not generic solution.
>
> -- 
> Regards,
> Sudeep

I see your point of view. However, taking into account given arguments, did I
convince you that delayed responses handling should be implemented in slightly
different way?

-- 
Best regards,
Matthew