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: <1287416305.2038.70.camel@helium>
Date:	Mon, 18 Oct 2010 08:38:25 -0700
From:	David Brownell <david-b@...bell.net>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	"Hennerich, Michael" <Michael.Hennerich@...log.com>,
	Mike Frysinger <vapier@...too.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"uclinux-dist-devel@...ckfin.uclinux.org" 
	<uclinux-dist-devel@...ckfin.uclinux.org>,
	"device-drivers-devel@...ckfin.uclinux.org" 
	<device-drivers-devel@...ckfin.uclinux.org>
Subject: Re: [PATCH] i2c: add irq_flags to board info

On Mon, 2010-10-18 at 16:33 +0200, Jean Delvare wrote:


> 
> This is an interesting point. David, you're the one who added irq to
> struct i2c_client, you didn't add irq_flags then, did you have a good
> reason not to?

There was no evident need to do so.  The problem wasn't characterizing
the IRQ, but knowing what IRQ was associated with a given I2C chip.  The
IRQs would, as a rule, only have one behavior, known in advance by the
I2C chip's driver ... if it only had a way to know client->irq ...

In one model of IRQ setup (like PC BIOS), it's handled before drivers
do more than request the IRQ, and drivers just cope. irq_flags not
needed ... it's often a hardware-to-driver convention, likely matching
I2C chip defaults.  (Or more awkwardly, coping with whatever trigger
mode the platform uses).

In another model, drivers configure their chips according to desired
mode (level low, for the most common example, or edge triggered, etc)
and again, irq_flags not needed, but in this case the platform code
would have had *nothing* do do with such mode setup.



> 
> > There are drivers that work around this deficiency, by adding irq_flags to the bus clients dev.platform_data
> > See include/linux/spi/ads7846.h for one example.

Not a good example; that was changed earlier this year and, from a quick
glance, may not have tried much to avoid that change.  The driver had
worked for years with that alleged "deficiency".


- Dave

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ