Re: klists and struct device semaphores

[Patrick Mochel]

On Thu, 31 Mar 2005, Alan Stern wrote:

> On Wed, 30 Mar 2005, Patrick Mochel wrote:

> > In fact, we probably want to add a counter to every device for all "open
> > connections" so the device doesn't try to automatically sleep while a
> > device node is open. Once it reaches 0, we can have it enter a
> > pre-configured state, which should save us a bit of power for very little
> > pain.
>
> By "open connections", do you mean something more than unsuspended
> children?

Yes, I mean anything that requires the device be awake and functional.
This would include open device nodes for many devices, open network
connections for network devices, active children for bridges and
controllers, etc.

This will require modification of at least the open() routines at the
subsystem level. They can simply access the class device and call down to
the driver, with some help from some core utility functions and some hand
waving. The driver (or bus subsystem) can determine if the parent needs to
be awakened at that same time, and awaken it if necessary.

> Are you proposing to add these counters to struct device?  If so, would
> they be used and maintained by the core or by the driver/subsystem?  I
> should think the core wouldn't know enough about the requirements of
> different devices to do anything useful.  But then if the core doesn't use
> the counters they should be stored in a private data structure, not in
> struct device.

The core would know very little to be useful. However, it would most
likely need to modify them around calls to e.g. probe()/remove() to make
sure the device is functional when accessing it. Maybe.

At the very least, the shortest path to getting every device working with
this is to modify the subsystems' open calls. The only way to bridge their
notion of class-specific objects (and class_devices) with physical devices
is through the core.

So, I think we need the counter in struct device, along with some helper
functions.


	Pat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/