On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote:

On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:

quoted

On Fri, 18 Jul 2014, Patrik Fimml wrote:

quoted

On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:

[cut]

quoted

quoted

I'm not sure what the appropriate action for a video camera is anyway.
Should it go away completely, including its device? Should it be there,
but certainly not be the default choice when there is an external
camera? I'm thinking along the lines of some application's settings
dialog here, where it might be desirable to still be able to select the
internal camera for future recordings.

Of course, userspace could still decide simply not to
quiesce|deactivate|inhibit the device if that was desired.

There's some question about how much of userspace needs to get
involved.  Just the daemon that manages these configuration changes, or
other programs as well?  I guess that's not really our problem...

We need to provide means of implementing policy; the policy itself is not 
really our concern ;)

quoted

In the end, it sounds like you're suggesting a new pair of PM
callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and
->uninhibit().  Plus an optional (?) sysfs interface for invoking the
callbacks.

We do need sysfs interface so that userspace can talk to the devices in 
question; and we also need to make sure that PM core is aware of the new 
callbacks and provides guarantees about their interactions with system- and 
runtime-PM callbacks so that individual drivers do not have to sort it out on 
their own.

A step back, please.

I have no idea why those need to be PM callbacks.

What you need really seems to be a way to tell a driver "ignore input from this
device from now on as it is most likely bogus".  A natural reaction of the
driver to that might be to stop processing input from the device and then
runtime suspend it (and prevent it from generating remote wakeup as that may
be bogus as well), but I don't see why the PM core needs to be involved in
that at all.

Rafael