linux-kernel - Re: multiple drivers, single device (was Re: Announce: Linux-next (Or Andrew's dream :-)))

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: <20080212181037.GA2445@kroah.com>
Date:	Tue, 12 Feb 2008 10:10:37 -0800
From:	Greg KH <greg@...ah.com>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	LKML <linux-kernel@...r.kernel.org>, linux-next@...r.kernel.org,
	linux-arch@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus <torvalds@...ux-foundation.org>
Subject: Re: multiple drivers, single device (was Re: Announce: Linux-next
	(Or Andrew's dream  :-)))

On Tue, Feb 12, 2008 at 12:56:35PM -0500, Jeff Garzik wrote:
> Greg KH wrote:
>> The work I'm doing here is for stupid PCI firmware engineers, who have
>> created devices that are different things, all bound up under the same
>> PCI device.  I'm thinking of watchdog timers and random number
>> generator and i2c controller on the same PCI device, or even the more
>> basic, frame buffer and DRM access to the same PCI video device.
>
> Yes, that has a known solution:  have your driver register i2c, rng, 
> watchdog, etc. functions.
>
> Works just fine inside today's infrastructure, no changes needed.

Except that the individual drivers are a lot of the time written by
different people, live in different portions of the tree, and are
combined into different combinations depending on the chipset.

For i2c devices, I see the scx200_acb, i2c-elektor, i2c-sis5595, and
i2c-sis630 drivers needing this.  The last one happens to share the pci
device with a video driver, that doesn't always need to be / want to be
loaded by users just so they can read the temperature of their
processors.

Oh, the EDAC code also needs this, and I know that no one wants to merge
that stuff into their individual drivers :)

Same goes for framebuffer vs. DRM.  Yeah, I know DRM ended up "winning"
here, but for some hardware setups, both are still valid, and it really
would be good for both drivers to be notified when the system is about
to go into suspend/resume and other stuff like that.

If the driver core can provide this in a simple manner, I think it is
worth it, especially as there are lots of hardware that seems to need
it.

thanks,

greg k-h
--
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/