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: <20080212213850.GA22600@kroah.com>
Date:	Tue, 12 Feb 2008 13:38:50 -0800
From:	Greg KH <greg@...ah.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jeff Garzik <jeff@...zik.org>,
	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>
Subject: Re: multiple drivers, single device (was Re: Announce: Linux-next
	(Or Andrew's dream  :-)))

On Tue, Feb 12, 2008 at 10:30:04AM -0800, Linus Torvalds wrote:
> 
> 
> On Tue, 12 Feb 2008, 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.
> 
> Indeed. If you have a multi-function device that shows up as a single PCI 
> function, just make it have its own "private bus", and make it show up as 
> a "devices within a device".

That's how I first tried to do this (old pci-piggy patches in -mm were a
result of this...).

But, we have the issue of the foolish-in-retrospect sysdev devices.
They are an example of "multiple drivers per device" type thing.  To
clean them up properly, they need to move to the general 'struct device'
and if that is going to already support the one-to-many model, well,
then any PCI implementation of such an internal bus can also use the
same code.

This is a lot of handwaving right now, let me go work on some code and
see how it turns out.

Don't worry, I'll expect a lot of review cycles :)

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/