linux-kernel - Re: [RFC 1/3] pinctrl: add a driver for NVIDIA Tegra

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 13 Dec 2011 01:27:05 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dia.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	ext Tony Lindgren <tony@...mide.com>
Subject: Re: [RFC 1/3] pinctrl: add a driver for NVIDIA Tegra

On Mon, Dec 12, 2011 at 7:06 PM, Stephen Warren <swarren@...dia.com> wrote:
> Linus Walleij wrote at Friday, December 09, 2011 4:56 PM:

>> For me there are two points:
>>
>> - Avoiding clash with kernel maintainers who hate firmware-like tables and
>>   binary data filling up the kernel. Some certain other guy bearing my
>>   name comes to mind.
>
> Well, one of the nice things here is that everything to conctrol the HW
> is in the driver, unlike on other systems without all this data that
> have to rely on opaque BIOS/ACPI/EFI/... hooks.

Good point. I will have to play that card if the situation should arise.
Kernel devs also tend to hate stuff they can't control.

>> - Footprint: the majority of the stuff in your driver ends up in non-discardable
>>   memory, and will be kept around. Since we have this concept of a
>>   single zImage for a number of say ARMv7 systems, and since pin
>>   controllers can be pretty hard to load from modules, *all* of them
>>   may have to be compiled-in. If every driver for every board takes this
>>   approach I am afraid it will be end up with a measurable footprint.
>
> Perhaps what we need is a way to build all these drivers as modules, but
> still link them into the kernel so they're statically available during
> early boot, but allow them to be unloaded like modules after the system
> has booted and determined they aren't needed.
>
> This would have the advantage of getting rid of the unused driver code
> as well, whereas putting the data into DT only handles ensuring the data
> for other SoCs isn't present in the kernel after boot.

Hm that sounds pretty complicated. But also extremely useful if
we forge ahead on single zImages.

I'd never be able to pull it off thoug :-/

Anyway, we'll deal with this when we run into the problem.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/