Re: [RFC Add in_use attribute] Let the driver know if it's in use

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tuesday 21 April 2009, Alan Stern wrote:
> On Mon, 20 Apr 2009, Rafael J. Wysocki wrote:
> 
> > On Thursday 16 April 2009, Michael Trimarchi wrote:
> > > Drivers on embedded systems would be smart enough
> > > to know that some of the devices should remain powered up, because
> > > they could still be useful even when the CPU wasn't running.
> > > The patch add the in_use attribute, that it can be used by the
> > > the drivers to avoid power down during suspend.
> > 
> > OK, so the idea is that in_use will be set by the user space for devices that
> > shouldn't be suspended.  Is this correct?
> > 
> > Assuming it is, I'd call the flag 'in_use' rather than 'is_inuse'.  Also, if
> > may_inuse is supposed to mean that we can set in_use for this device, I'd call
> > it 'in_use_valid', I'd make it be unset by default and I'd allow the driver to
> > unset it if it is going to react to 'in_use'.
> 
> I don't see why two separate flags are needed.  Why can't there be just 
> one?

There could be one, but since the core would handle the sysfs attribute
associated with it, the second flag would be useful to indicate to the core
whether or not the attribute should be available at all.

> Also, I don't see why the in_use flag has to propagate down to all the 
> descendant devices when it is set.  Why not let userspace be 
> responsible for that?

Agreed.

Michael, would it be a problem if the user space were responsible for
setting the flag for all devices that shouldn't be suspended?

> Finally, I don't like either name very much.  This flag is supposed to
> indicate that the device is being used in a mode that can run by itself
> even when the rest of the system is suspended.  Calling it "in_use" 
> doesn't express the crucial fact that the device is self-sufficient.

You're rignt, it would be better to call it something like 'no_suspend'.

Thanks,
Rafael
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux