[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d72f2787-c41b-4933-a017-911232ff2f7f@gmail.com>
Date: Wed, 15 Jun 2022 15:58:49 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: Cristian Marussi <cristian.marussi@....com>
Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
sudeep.holla@....com, james.quinlan@...adcom.com,
Jonathan.Cameron@...wei.com, etienne.carriere@...aro.org,
vincent.guittot@...aro.org, souvik.chakravarty@....com
Subject: Re: [PATCH 11/22] firmware: arm_scmi: Add SCMIv3.1 extended names
protocols support
On 6/15/22 10:32, Cristian Marussi wrote:
>
> Ok, this was another place where a reply carrying a consistent number of
> non-segmented entries could trigger an jumbo-request to kmalloc...
>
> ..maybe this is where a transient fw issue can reply with a dramatic
> numbers of possible (non-segmented) levels (num_returned+num_remaining)
>
> (I filter out replies carrying descriptors for segmented voltage-levels
> that does not come in triplets (returned:3 remaining:0) since they are out
> of spec...but I just hit today on another fw sending such out of spec
> reply for clocks and I will relax such req probably not to break too
> many out-of-spec blobs out in the wild :P)
>
> So let me know if got new splats...
This turned out to be a nice firmware bug, someone *cough* *cough*
decided to add some extra "protection" using a temporary buffer and they
completely forgot the newly added voltage domain service, so we would
just return stale information, wonderful. This is now fixed.
Thanks a lot for your responsiveness and support.
--
Florian
Powered by blists - more mailing lists