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]

Message-ID: <20080627124143.23ac7b7b@hyperion.delvare>
Date:	Fri, 27 Jun 2008 12:41:43 +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

Hi Ryan,

On Fri, 27 Jun 2008 09:12:54 +1200, Ryan Mallon wrote:
> Jean Delvare wrote:
> > I don't like option 2 at all. drivers/i2c/early could be, but not
> > drivers/i2c-early.
> 
> I don't think its a good idea either. The point was that in order to
> have two sets of i2c drivers with different link order (with regard to
> the rest of the driver subsystems) you would need two top level
> directories in drivers/.

I don't think so. Look at what the input subsystem does (from
drivers/Makefile):

obj-$(CONFIG_SERIO)		+= input/serio/
obj-$(CONFIG_GAMEPORT)		+= input/gameport/
obj-$(CONFIG_INPUT)		+= input/

And there are similar examples with video (video/i810/ and
video/intelfb/ are early in the list). We could do the same with i2c:

obj-$(CONFIG_I2C)		+= i2c/early/

(... lots of things ...)

obj-$(CONFIG_I2C)		+= i2c/

Of course this implies minor edits to drivers/i2c/Makefile. I don't
know if we want to do that, but from a technical point of view it seems
doable.

> The other way of course, is to use one
> directory, or subdirectories under drivers/i2c/ and use subsys_initcall.

> > (...)
> > If we are going to keep using subsys_initcall in bus drivers, then
> > moving the bus drivers using it to a separate directory is not needed.
> > Which doesn't mean we don't want to split the i2c bus drivers into
> > subdirectories for other reasons, but I want to see this as a separate
> > issue. BTW, I started categorizing the different types of i2c bus
> > drivers:
> > http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/i2c-group-bus-drivers.patch
> > If you want to help with embedded stuff or SOC or whatever makes sense
> > to group together, please do! For now, everything I am not familiar
> > with is in group "Others".
> 
> I don't know all of the embedded systems, but at a glance the following
> busses from your others section are used on embedded ARM processors:
> 
> i2c-at91
> i2c-davinci
> i2c-ixp2000
> i2c-omap
> i2c-pxa
> i2c-s3c2410
> i2c-versatile

OK, I've moved these to a section titled "Embebbed system I2C host
controller drivers", thanks.

> I'm sure someone else can point out any I missed, and any embedded i2c
> controllers from other architectures. i2c-gpio should probably also go
> under an embedded section as I assume that it is mostly used on embedded
> systems where there is no SoC i2c controller.

OK, I did this too. In theory, i2c-gpio could be used on any system,
but in practice you are most certainly right.

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