linux-kernel - Re: [PATCH] OMAP: I2C driver for TI OMAP boards #2

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]

Message-Id: <20060804103135.77531faa.khali@linux-fr.org>
Date:	Fri, 4 Aug 2006 10:31:35 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	David Brownell <david-b@...bell.net>
Cc:	Komal Shah <komal_shah802003@...oo.com>, akpm@...l.org,
	gregkh@...e.de, i2c@...sensors.org, imre.deak@...ia.com,
	juha.yrjola@...idboot.com, linux-kernel@...r.kernel.org,
	r-woodruff2@...com, tony@...mide.com
Subject: Re: [PATCH] OMAP: I2C driver for TI OMAP boards #2

David,

> On Thursday 03 August 2006 2:19 am, Jean Delvare wrote:
> > The i2c core provides a mechanism to bypass the probing when you know
> > for sure what device is at a given address. For an embedded system, that
> > should work.
> 
> Unfortunately the mechanisms I'm aware of require either error-prone
> kernel command line parameters, or (not error prone, but inelegant)
> board-specific logic in the drivers, before driver registration, to
> do equivalent stuff.

I said it was possible, not that it was nice and elegant ;) I know it's
ugly at the moment - which is exactly why people have been asking for
an i2c-core conversion.

> It may help to see how the SPI core solves that problem.  Unlike I2C,
> SPI actually _can't_ probe (except in rare specialized cases), and when
> I did the SPI stuff I was thinking about models that could apply easily
> to help I2C avoid probing.  (Though not, at this point, code.)

I2C can't really probe either. We abuse a transaction type we known most
chips will reply to but otherwise ignore to achieve chip presence
detection. It did damage in the past (killing Thinkpad laptops) and
could do again in the future. So, having board-specific lists of chips
to avoid probing would help.

> That model of a table of board-specific declarations (with things like
> "I2C chip type X at address A, using interrupt I and platform_data P")
> should work for I2C too.

What we have in the works is "I2C chip type X at address A". No
interrupt nor platform data at this point. But once the conversion to
the device driver model is done, I guess it'll come naturally if needed.

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