linux-kernel - Re: [PATCH 1/4] ARM: multi_v7_defconfig: Enable common Rockchip devices/busses

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:	Mon, 7 Sep 2015 13:27:38 +0200
From:	Thierry Reding <treding@...dia.com>
To:	Javier Martinez Canillas <javier@....samsung.com>
CC:	Sjoerd Simons <sjoerd.simons@...labora.co.uk>,
	<linux-rockchip@...ts.infradead.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	Heiko Stuebner <heiko@...ech.de>,
	Kukjin Kim <kgene@...nel.org>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	<linux-kernel@...r.kernel.org>,
	Russell King <linux@....linux.org.uk>,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	Arnd Bergmann <arnd@...db.de>,
	Lee Jones <lee.jones@...aro.org>,
	Olof Johansson <olof@...om.net>, Ray Jui <rjui@...adcom.com>,
	Stephen Warren <swarren@...dia.com>
Subject: Re: [PATCH 1/4] ARM: multi_v7_defconfig: Enable common Rockchip
 devices/busses

On Mon, Sep 07, 2015 at 12:38:08PM +0200, Javier Martinez Canillas wrote:
> Hello Sjoerd,
> 
> On 09/07/2015 12:24 PM, Sjoerd Simons wrote:
> > On Mon, 2015-09-07 at 11:26 +0200, Javier Martinez Canillas wrote:
> >> Hello Sjoerd,
> >>
> >> On 09/06/2015 10:16 PM, Sjoerd Simons wrote:
> >>> Enable Rockchip I2C, SPI, PWM, thermal drivers.
> >>>
> >>> Builtin are:
> >>>  * I2C as it often controls the pmic.
> >>
> >> Having I2C as a module will cause more probe deferrals due missing
> >> regulators and slow down the boot but it should not cause issues.
> >> Or am I missing something?
> >>
> >> In fact, I think even the PMIC could be built as a module.
> > 
> > It could in principle. However as a lot of other drivers do need the
> > regulators provided by the pmic, they'll be deferred until that driver
> > is loaded. So e.g. with the i2c/pmic drivers as a module you cannot
> > boot to an NFS rootfs without using an initramfs. 
> >
> 
> Right, not needing an initramfs is certainly a good reason. If you could
> add something like that in the commit message of patches 1/4 and 2/4 that
> would be great.

I don't know. multi_v7_defconfig is primarily useful as a means to
quickly get a configuration that has most drivers enabled that most ARM
SoCs need. As such it's more of a convenience for build testing rather
than using it for booting a device.

I don't think the focus should be on optimizing for boot speed. Rather
if you do want to optimize for a device going through the trouble of
setting up an initial ramdisk isn't all that complicated. Even more so
because if you build drivers into the kernel and those drivers happen
to require firmware then people will be required to setup initial
ramdisks anyway.

Building too many drivers into the kernel has in the past often lead to
problems where all of a sudden the kernel became too big to fit into any
reasonably sized region of memory and cause all sorts of weird failures
in boot farms. Building everything as modules has the advantage that the
size of the zImage itself doesn't vary much, hence has less of a chance
to break boot farms.

There are quite a few drivers in multi_v7_defconfig that I suspect could
be built as loadable modules to decrease the size of the images that are
currently generated.

I understand that not everybody likes the additional ramdisk but, in my
opinion, that's what SoC-specific default configurations are good for.
We can use those to provide a base for developers where the focus is
ease of testability.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)