linux-kernel - Re: [PATCH v3 1/5] Documentation: add DT bindings for ARM SCPI sensors

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 15 Sep 2015 12:03:30 +0100
From:	Mark Rutland <mark.rutland@....com>
To:	"Jon Medhurst (Tixy)" <tixy@...aro.org>
Cc:	Punit Agrawal <Punit.Agrawal@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Liviu Dudau <Liviu.Dudau@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"lm-sensors@...sensors.org" <lm-sensors@...sensors.org>,
	"edubezval@...il.com" <edubezval@...il.com>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"linux@...ck-us.net" <linux@...ck-us.net>,
	Sudeep Holla <Sudeep.Holla@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 1/5] Documentation: add DT bindings for ARM SCPI
 sensors

On Tue, Sep 15, 2015 at 11:46:02AM +0100, Jon Medhurst (Tixy) wrote:
> On Tue, 2015-09-15 at 10:37 +0100, Punit Agrawal wrote:
> > "Jon Medhurst (Tixy)" <tixy@...aro.org> writes:
> > 
> > > On Mon, 2015-09-14 at 15:38 +0100, Punit Agrawal wrote:
> > >> Mark Rutland <mark.rutland@....com> writes:
> > >> 
> [...]
> > >> The way the SCP interface is defined, the sensor identifiers are
> > >> contiguous,
> > >
> > > Is there any documentation other than DUI0922A? [1] From what I can seen
> > > that just says it's a 16-bit value and doesn't put any particular
> > > constraints on its value.
> > 
> > Although not explicitly stated, if you look at the Get Sensor Capability
> > [2] and Get Sensor Info [3] commands you can indirectly infer that the
> > Sensor IDs are contiguous.
> 
> I personally wouldn't even indirectly infer they are contiguous from
> what the document says. If I were implementing the firmware I would feel
> quite in my rights to, for example, use the top 8 bits of the ID for a
> sensor type and the bottom 8 for an index, if that made dispatching of
> requests more efficient. Or if some optional hardware was detected as
> missing, leaving some holes in ID space.
> 
> As a specification of a 'standard' the document seems to be rather
> lacking. So, Sensor ID should be documented as being "an unsigned
> integer less than then number of sensors returned by the Get Sensor
> Capability command", or something like that. I guess clocks and other
> devices suffer from similar lack of specificity.

I think from the PoV of the binding, this doesn't matter. The value is
just an arbitrary opaue token written down in a spec, that the FW
understands how to interpret.

I only asked about how the IDs were organised because I thought there
was additional translation in the kernel, but this is not the case.

The only potential problem is bit-width. Punit, I assume the value is
32-bit (or less) in the messages to the FW?

If for the moment we assume the values can index a small array, then we
can change that later (though ideally we'd handle the most geeneral case
we're aware of from the outset). We just need to not infer any semantics
from a value alone.

Thanks,
Mark.
--
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/