linux-kernel - Re: [PATCH] drivers/misc: introduce Freescale Data Collection Manager driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 2 Aug 2011 11:26:59 +0900
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Tabi Timur-B04825 <B04825@...escale.com>
Cc:	"arnd@...db.de" <arnd@...db.de>,
	"grant.likely@...retlab.ca" <grant.likely@...retlab.ca>,
	"linuxppc-dev@...abs.org" <linuxppc-dev@...abs.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drivers/misc: introduce Freescale Data Collection
 Manager driver

On Tue, Aug 02, 2011 at 01:57:45AM +0000, Tabi Timur-B04825 wrote:
> Mark Brown wrote:

> > I'd expect that things like the _lowest, _highest and _average
> > attributes which a number of drivers have are what you're looking for.

> Yes, but then all I'm doing is presenting numbers that don't change to an 
> interface, simply on the basis that the numbers represent sensor values.

> If I'm running a sensor application, I'm doing it to get real-time 
> monitoring of the sensors in my system.  The DCM on our boards is not 
> capable of real-time results.  So you're not actually "monitoring" the 
> hardware.  The data from the DCM is available only *after* you stop 
> running the background process.

Right, that seems to fit reasonably well with things like averages and
extremes.

> > At the very least it seems obvious how you might extend the interface if
> > some features you need are missing.  The subsystem has fairly extensive
> > documentation in Documentation/hwmon.

> I just don't see how it fits.  Yes, I could do it, but then I'd end up 
> with something that doesn't make any sense.  I would have to use a custom 
> interface to start monitoring and then another interface to stop it.  Then 

The most obvious thing seems to be to use the existing _reset_history
stuff to trigger a restart.  If the hardware is so incapable that it
can't cope with reads while active and needs to be reset to even pause
that's seems pretty rubbish, I'd have expected you could at least pause
measurement momentarily to do a read.

Perhaps integration as a PMU may make more sense?  The general point
here is that this doesn't sound like it's doing something so odd that it
shouldn't even be trying to work within any sort of framework.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/