On 21/08/2021 07:40, Kalle Valo wrote:
Christian Lamparter <chunkeey@xxxxxxxxx> writes:
On most embedded ath9k devices (like range extenders,
routers, accesspoints, ...) the calibration data for
the RF/PHY is simply stored in a MTD partition named
"ART", "caldata"/"calibration", etc.
Any mtd partition is automatically registered in the
nvmem subsystem. This makes is possible to fetch the
necessary calibration directly from there at the low
cost of adding nvmem cell information via the
device-tree or via similar means.
This speeds up the driver's initialization a lot,
because the driver doesn't have to wait for userspace
to provide the data via helpers.
Signed-off-by: Christian Lamparter <chunkeey@xxxxxxxxx>
The series looks good to me. But I'm curious, why you marked this as
RFC? Is there something controversial I missed?
yeah. Last night (it was already really late) I was tunnel-visioning
at the thought that device-tree binding update was a must there.
... And ath9k's qca,ath9k.txt is still in that .txt and not .yaml
format. So, I'm not sure if that file has to be converted first.
(I couldn't get Rob's tools to work. And without them, I've no idea
what error messages a converted .yaml of it will pop up)
However... since then, I had the change to re-read:
<https://www.kernel.org/doc/Documentation/nvmem/nvmem.txt>
And found that nvmem cells and lookups can be specified in
the old platform data way as well... So that binding patch
1/3 is optional.
So, yeah. If nobody has an comment until next week, I'll post this
series with only patches 2/3 and 3/3.
Cheers,
Christian
