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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ