On 14/10/2021 16.36, Krzysztof Kozlowski wrote:
On 14/10/2021 08:59, Hector Martin wrote:
Don't you have a limit of supported channels? It cannot be any uint32...
Today, it's max 8. But if come Monday we find out Apple's new chips have
16 channels and otherwise the same register layout, I'd much rather not
have to change the driver...
OK, however if the driver ever receives different DT with a different
value, it will accept it unconditionally and go via address space. I am
just saying that being conservative on received values is safer, but I
am fine with skipping this problem. At the end we trust DT that it will
always match the kernel, don't we? Oh wait, someone can use DT from
other kernel in this one...
DTs using these compatibles should have the same register layout, and
should work with this driver; if a new chip comes out that has a
different register layout we will change the compatibles (both) and
therefore older kernels won't bind at all. If it has the same layout
we'll keep the base compatible, `reg` will grow as needed to accomodate
the extra channels, and e.g. num-channels=16 will then just work on
older kernels with no changes.
Obviously a broken DT with an insane value here would crash the driver,
but so would any other number of crazy DT things; however, I don't
expect that to ever happen.
There's also the case where we end up with multiple memory controllers
at discrete offsets (e.g. rumored multi-die configurations); in that
case we'll end up with multiple genpd parents and have to add code to
support that, and in the meantime older kernels will just have broken
cpufreq on the p-cores. But I think that is ~acceptable as long as the
system boots; we don't expect to be able to *fully* support newer SoCs
on older kernels with no code changes. What I'm aiming for is just
making the system work, hopefully with NVMe and USB and a dumb
framebuffer, so that distro installers can run and then users can later
install a proper up to date kernel will full support for the new SoC.
Ah, I didn't realize that was a valid option for MODULE_LICENSE. I guess
anything containing "GPL" works with EXPORT_SYMBOL_GPL?
I don't think exporting symbols is related to how you license your code.
It is; only modules with a GPL-compatible MODULE_LICENSE get to use
symbols exported via EXPORT_SYMBOL_GPL.
See kernel/module.c for the symbol lookup logic and
include/linux/license.h for the logic to check the string (seems like
"Dual MIT/GPL" is explicitly whitelisted there).
Of course, this is a futile effort, as ~every time I see a proprietary
module in some embedded device, it either falsely declares itself to be
GPL, or they have a shim module that re-exports GPL symbols as non-GPL.
--
Hector Martin (marcan@xxxxxxxxx)
Public Key: https://mrcn.st/pub
