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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 12 Dec 2011 10:06:24 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Linus Walleij <linus.walleij@...aro.org>
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

Linus Walleij wrote at Friday, December 09, 2011 4:56 PM:
> On Fri, Dec 9, 2011 at 6:28 PM, Stephen Warren <swarren@...dia.com> wrote:
> 
> > Hence, there's no point parsing it from device tree; we end up with exactly
> > the same data in the driver, yet have spent a bunch of time parsing it out
> > from device tree instead of just embedding it into the kernel binary.
> 
> 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.

> - 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.

-- 
nvpublic

--
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/