On Tue, 6 Nov 2007, Peter Zijlstra wrote:
> > Nonsense. Consider a simple tree: A is the root, B and C are two
> > children of A. Task 1 wants to lock all the entries in the tree, so it
> > acquires the locks for A (the parent), then B, and then C (the
> > children). Meanwhile task 2 also wants
On Tue, 2007-11-06 at 13:05 -0500, Alan Stern wrote:
> On Tue, 6 Nov 2007, Peter Zijlstra wrote:
>
> > > > *blink* someone needs to take all locks - why?
> > >
> > > It's for system suspend. All the devices are locked to prevent driver
> > > binding and unbinding during the suspend transition.
On Tue, 6 Nov 2007, Peter Zijlstra wrote:
> > > *blink* someone needs to take all locks - why?
> >
> > It's for system suspend. All the devices are locked to prevent driver
> > binding and unbinding during the suspend transition.
>
> Just locking the tree root is not enough? (thereby avoiding
On Tue, 2007-11-06 at 11:32 -0500, Alan Stern wrote:
> On Tue, 6 Nov 2007, Peter Zijlstra wrote:
> > On Tue, 2007-11-06 at 10:36 -0500, Alan Stern wrote:
> > > You can't possibly solve the lockdep problems here with a simple-minded
> > > approach like your DRIVER_NORMAL, DRIVER_PARENT, etc. The d
On Tue, 6 Nov 2007, Peter Zijlstra wrote:
> On Tue, 2007-11-06 at 10:36 -0500, Alan Stern wrote:
>
> > I gather the idea is to convert dev->sem to a mutex. This idea had
> > occurred to me a long time ago but I didn't pursue it because of the
> > sheer number of places where dev->sem gets used
On Tue, 2007-11-06 at 10:36 -0500, Alan Stern wrote:
> > > Would it be possible to break at the second scan, that is the device
> > > probe and stick that into a workqueue or something. Then we'd only ever
> > > have driver->device nesting.
> >
> > Alan and Oliver have done some work in this area
On Mon, 5 Nov 2007, Greg KH wrote:
> On Mon, Nov 05, 2007 at 11:57:14AM +0100, Peter Zijlstra wrote:
> > Hmm, the problem seems to be stuff like:
> >
> > add usb driver to pci
> > scan pci devices
> > add usb host controller device
> > scan usb devices
> > add usb hub dev
On Mon, 2007-11-05 at 14:49 -0800, Greg KH wrote:
> On Mon, Nov 05, 2007 at 11:57:14AM +0100, Peter Zijlstra wrote:
> > Hmm, the problem seems to be stuff like:
> >
> > add usb driver to pci
> > scan pci devices
> > add usb host controller device
> > scan usb devices
> > a
On Mon, 2007-11-05 at 17:38 -0800, David Brownell wrote:
> On Monday 05 November 2007, Greg KH wrote:
> > --- linux-2.6-2.orig/drivers/spi/spi.c
> > +++ linux-2.6-2/drivers/spi/spi.c
>
> It'd be quicker to end up in the right hands if you had
> split this big and random patch according to subsyste
On Monday 05 November 2007, Greg KH wrote:
> --- linux-2.6-2.orig/drivers/spi/spi.c
> +++ linux-2.6-2/drivers/spi/spi.c
It'd be quicker to end up in the right hands if you had
split this big and random patch according to subsystem...
There's already a patch in the MM queue that removes
the SPI-pr
On Mon, Nov 05, 2007 at 11:57:14AM +0100, Peter Zijlstra wrote:
> Hmm, the problem seems to be stuff like:
>
> add usb driver to pci
> scan pci devices
> add usb host controller device
> scan usb devices
> add usb hub device
> scan usb devices
> a
Peter Zijlstra wrote:
[sem-to-mutex in struct device and struct class]
> drivers/base/bus.c| 20 ++--
> drivers/base/class.c | 22 +++---
> drivers/base/core.c | 20 +---
> drivers/base/dd.c
Hmm, the problem seems to be stuff like:
add usb driver to pci
scan pci devices
add usb host controller device
scan usb devices
add usb hub device
scan usb devices
add usb .
This seems to be able to go on forever, as long as one can cascade u
On Sun, 2007-11-04 at 19:58 -0800, Greg KH wrote:
> On Sun, Nov 04, 2007 at 09:29:18PM +0100, Peter Zijlstra wrote:
> >
> > On Sat, 2007-11-03 at 12:48 -0700, Stephen Hemminger wrote:
> > > The sizeof(struct device) is way too big, especially in the network
> > > device case.
> > > We want to sup
On Sun, Nov 04, 2007 at 09:29:18PM +0100, Peter Zijlstra wrote:
>
> On Sat, 2007-11-03 at 12:48 -0700, Stephen Hemminger wrote:
> > The sizeof(struct device) is way too big, especially in the network device
> > case.
> > We want to support 1000's of device's and the change from class_device to
>
On Sat, 2007-11-03 at 12:48 -0700, Stephen Hemminger wrote:
> The sizeof(struct device) is way too big, especially in the network device
> case.
> We want to support 1000's of device's and the change from class_device to
> net_device has caused needless bloat.
>
> sizeof(struct device) = 272
> s
On Sat, Nov 03, 2007 at 12:48:23PM -0700, Stephen Hemminger wrote:
> The sizeof(struct device) is way too big, especially in the network device
> case.
> We want to support 1000's of device's and the change from class_device to
> net_device has caused needless bloat.
>
> sizeof(struct device) = 2
The sizeof(struct device) is way too big, especially in the network device case.
We want to support 1000's of device's and the change from class_device to
net_device has caused needless bloat.
sizeof(struct device) = 272
sizeof(struct class_device) = 92
* not the class_id in class_device could a
18 matches
Mail list logo
