Re: [PATCH v4 05/10] drivers: qcom: rpmh-rsc: Kill cmd_cache and find_match() with fire

From: Stephen Boyd
Date: Mon Apr 13 2020 - 17:41:40 EST


Quoting Douglas Anderson (2020-04-13 10:04:10)
> The "cmd_cache" in RPMH wasn't terribly sensible. Specifically:
>
> - The current code doesn't realy detect "conflicts" properly any case

s/realy/really/

> where the sequence being checked has more than one entry. One
> simple way to see this in the current code is that if cmd[0].addr
> isn't found that cmd[1].addr is never checked.

s/that/then/ ?

> - The code attempted to use the "cmd_cache" to update an existing
> message in a sleep/wake TCS with new data. The goal appeared to be
> to update part of a TCS while leaving the rest of the TCS alone. We
> never actually do this. We always fully invalidate and re-write
> everything.
> - If/when we try to optimize things to not fully invalidate / re-write
> every time we update the TCSes we'll need to think it through very
> carefully. Specifically requirement of find_match() that the new
> sequence of addrs must match exactly the old sequence of addrs seems
> inflexible. It's also not documented in rpmh_write() and
> rpmh_write_batch(). In any case, if we do decide to require updates
> to keep the exact same sequence and length then presumably the API
> and data structures should be updated to understand groups more
> properly. The current algorithm doesn't really keep track of the
> length of the old sequence and there are several boundary-condition
> bugs because of that. Said another way: if we decide to do
> something like this in the future we should start from scratch and
> thus find_match() isn't useful to keep around.
>
> This patch isn't quite a no-op. Specifically:
>
> - It should be a slight performance boost of not searching through so
> many arrays.
> - The old code would have done something useful in one case: it would
> allow someone calling rpmh_write() to override the data that came
> from rpmh_write_batch(). I don't believe that actually happens in
> reality.
>
> Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
> Reviewed-by: Maulik Shah <mkshah@xxxxxxxxxxxxxx>
> Tested-by: Maulik Shah <mkshah@xxxxxxxxxxxxxx>
> ---

Reviewed-by: Stephen Boyd <swboyd@xxxxxxxxxxxx>