Re: sysfs and power management

[Onkalo Samu]

On Sat, 2010-10-30 at 16:00 +0200, ext Henrique de Moraes Holschuh
wrote:
> On Fri, 29 Oct 2010, Greg KH wrote:
> > back to sleep.  That's probably the best way to do this, as userspace
> > isn't going to open the sysfs file and not close it instantly anyway
> > after it has read the data (seeking on a sysfs file isn't really
> > recommended, even if it sometimes seems to work.)
> 
> Well, it is documented that seek(start of file) on sysfs works, and it
> is ABI already (some userspace uses it on poll/select-capable
> attributes).  So, maybe seek(somewhere that is not the start of the
> file) doesn't work -- and it should return an error in that case if it
> doesn't already...  but it is a lot more deterministic than "sometimes"
> ;-)
> 
> So yes, userspace will open() and not close() a sysfs attribute immediately
> afterwards.  It is not only shell crap that interfaces to the kernel over
> sysfs :-)
> 

What I would like to do is:

Control sensors operating mode and regulators based on the userspace
activity. If no-one is interested about the sensor, it can be turned
totally off including its operating power via regulator framework.

So far the only accepted interface for the small sensor seems to be
sysfs. I tried use misc device but it was not accepted.

For example ambient light sensor or proximity sensor may operate fully
under interrupts. There is no need to poll status which is fine with
sysfs. However, problem is that kernel driver have no idea if someone
keeps some sysfs entry open and waits for the data.

What I would like to have is just an indication that at least one of the
sysfs entries is opened by some application. When that condition is
true, the sensor would be powered on and kept running.
And similarly, then all the users has gone, turn the device off.

I can prepare a patch to show what I mean.

-Samu

> It would make a lot of sense to support the poll/select model on any
> sensor for which you have event-driven notifications of change from the
> hardware or firmware.
> 
> I don't know about open/close notifications, however.  Usually you need
> those when you're going to stream something to userspace, and there are FAR
> better interfaces to use in that case, such as the ring buffers used by the
> data acquisition devices, netlink (which userspace programmers seems not to
> like much :p), input devices, and generic character devices...
> 


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