linux-kernel - Re: a case for a common efuse API?

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:	Wed, 09 Jul 2014 16:32:03 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Maxime Ripard <maxime.ripard@...e-electrons.com>
CC:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Bjorn Andersson <bjorn.andersson@...ymobile.com>,
	Stephen Warren <swarren@...dia.com>,
	Peter De Schrijver <pdeschrijver@...dia.com>,
	Arnd Bergmann <arnd@...db.de>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: a case for a common efuse API?

On 07/09/14 01:35, Maxime Ripard wrote:
> Hi Stephen,
>
> On Tue, Jul 08, 2014 at 01:00:23PM -0700, Stephen Boyd wrote:
>> Hi,
>>
>> On MSM chips we have some efuses (called qfprom) where we store things
>> like calibration data, speed bins, etc. We need to read out data from
>> the efuses in various drivers like the cpufreq, thermal, etc. This
>> essentially boils down to a bunch of readls on the efuse from a handful
>> of different drivers. In devicetree this looks a little odd because
>> these drivers end up having an extra reg property (or two) that points
>> to a register in the efuse and some length, i.e you see this:
>>
>> 	thermal-sensor@...00 {
>> 		compatible = "sensor";
>> 		reg = <0x34000 0x1000>, <0x10018 0xc>;
>> 		reg-names = "sensor", "efuse_calib";
>> 	}
>>
>>
>> I imagine in DT we want something more like this:
>>
>> 	efuse: efuse@...00 {
>> 		compatible = "efuse";
>> 		reg = <0x10000 0x1000>;
>> 	}
>>
>> 	thermal-sensor@...00 {
>> 		compatible = "sensor";
>> 		reg = <0x34000 0x1000>;
>> 		efuse = <&efuse 0x18>;
>> 	}
> We have pretty much the same things in the Allwinner SoCs. We have an
> efuse directly mapped into memory, with a few informations like a MAC
> address, the SoC ID, the serial number, some RSA keys for the device,
> etc.
>
> The thing is, some boards expose these informations in an external
> EEPROM as well.
>
> I started working and went quite far to create an "eeprom" framework
> to handle these cases, with a dt representation similar to what you
> were exposing.
>
> https://github.com/mripard/linux/tree/eeprom-framework-at24
>
> It was working quite well, I was about to send it, but was told that I
> should all be moved to MTD, and given up on it.

Did anything ever get merged? Or the whole thing was dropped?

That branch looks like what I want, assuming we could get an agreement
on the binding. It looks like pretty much every SoC has this, and there
isn't any API or binding for it that I've seen. The only thing I see is
Documentation/devicetree/bindings/eeprom.txt and that doesn't cover the
client aspect at all.

Taking a quick peek at the code, it might be better to change the read
API to take a buffer and length, so that the caller doesn't need to free
the data allocated by the eeprom layer. It also makes it symmetrical
with the write API. We'd probably also need to make it work really early
for SoC's like Tegra where we want to read the SoC revision early. So
probably split off the device registration part to a later time to allow
register() to be called early.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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