Re: [RFC PATCH 6/9] memory: apple: Add apple-mcc driver to manage MCC perf in Apple SoCs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux