linux-kernel - Re: [PATCH, RFC] Earlier I2C initialization

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 Jun 2008 14:18:52 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	Ryan Mallon <ryan@...ewatersys.com>
Cc:	David Brownell <david-b@...bell.net>,
	Uli Luckas <u.luckas@...d.de>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	i2c@...sensors.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH, RFC] Earlier I2C initialization

On Thu, 12 Jun 2008 08:13:09 +1200, Ryan Mallon wrote:
> Jean Delvare wrote:
> > Which problem are you trying to solve? Is there any actual drawback to
> > abusing subsys_initcall() for the handful of i2c bus drivers which may
> > need to come up early?
>
> On many embedded devices there is a need for i2c to be early since it is
> often used for core functionality. It seems at the moment, that the 
> answer to this is to juggle a few of the drivers which people need to
> get this to work. There are the drivers in drivers/i2c which use 
> subsys_initcall. It does work, but it feels a bit untidy. Some of the i2c
> IO expander drivers are now in drivers/gpio since that comes up early.
> This can lead to confusion (see drivers/gpio/pca953x.c and 
> drivers/i2c/chips/pca9539.c).

The GPIO drivers under drivers/i2c/chips are deprecated and tagged for
removal. We only need a user-space interface for the new GPIO drivers
(I think we do by now) and a way to instantiate these new GPIO devices
from user-space (not done yet) before the deprecated drivers can be
removed. The only remaining users for these deprecated drivers are
electronics enthusiasts controlling GPIO chips over the PC parallel
port. In the context of embedded platforms, there's no room for
confusion here.

>                               As David suggested, if i2c is needed early
> in enough cases, why not just move it early in the link order? My patch
> was just an alternative approach which mimics the current behaviour, but
> makes it possible to get any i2c driver early. Why not just mark all of
> the drivers/busses that get used on embedded devices as subsys_initcall,
> just in case somebody needs them early?

Because this is an abuse of subsys_initcall? I guess that was
acceptable when only a couple drivers were doing that, but making it
official sounds bad.

> (...)
> I just ran a sed script over the drivers/i2c directory. The intent was to
> mark the entire subsystem to come up early if CONFIG_I2C_EARLY is set,
> and use i2c_module_init every where since it makes it more consistent, and
> doesn't cost anything on setups where CONFIG_I2C_EARLY isn't defined.

It costs readability and build time.

> The idea was basically that a board could clearly say: I want i2c early,
> and have any busses and devices drivers it has configured as builtins
> automatically be present early on.

I get the idea, but I don't buy the implementation.

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