[PATCH 1/4] nvmem: rockchip-otp: Serialize reads
Alexey Charkov
alchark at flipper.net
Wed Sep 2 02:24:00 PDT 2026
On Wed, Sep 2, 2026 at 1:10 PM Miquel Raynal <miquel.raynal at bootlin.com> wrote:
>
> On 01/09/2026 at 19:33:11 +04, Alexey Charkov <alchark at flipper.net> wrote:
>
> > The OTP controller is driven through a single set of registers holding a
> > state machine which has to be stepped through for every word read, yet
> > nothing keeps two readers out of each other's way. Concurrent reads
> > interleave, and the outcome is either a reader bailing out:
> >
> > rockchip-otp 2a580000.otp: timeout during read setup
> >
> > or, worse, one of them silently taking delivery of the other's data.
> >
> > Reading two cells in parallel from userspace on RK3576 reproduces both
> > within 150 iterations - 53 read errors and 9 corrupted results, the latter
> > either losing their first word or, in one case, ending in the two bytes
> > which belong to the other reader's cell - whereas the same reads issued
> > sequentially never fail. Concurrency is not hypothetical here, as six
> > thermal sensors source their trim values from the OTP and reach the driver
> > straight from asynchronous driver probing.
> >
> > Guard the read path with a mutex. Reads are the only way into the hardware,
> > as the driver registers no write callback, and they always run in process
> > context, so a plain mutex spanning the whole clock-enable, read,
> > clock-disable sequence is enough.
> >
> > Fixes: 755864feb729 ("nvmem: add Rockchip OTP driver")
> > Cc: stable at vger.kernel.org
> > Signed-off-by: Alexey Charkov <alchark at flipper.net>
>
> Reviewed-by: Miquel Raynal <miquel.raynal at bootlin.com>
Thanks for your review Miquel!
Sashiko complained about mixing a scope-based guard into a function
with goto-based error handling, so I am replacing the guard(mutex)
with explicit lock and unlock calls for v2. There won't be any
semantic change though, so if you don't mind I'd like to carry your
tag into the v2 version.
Best regards,
Alexey
More information about the linux-arm-kernel
mailing list