a case for a common efuse API?

[sboyd@codeaurora.org (Stephen Boyd)]

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 at 34000 {
>> 		compatible = "sensor";
>> 		reg = <0x34000 0x1000>, <0x10018 0xc>;
>> 		reg-names = "sensor", "efuse_calib";
>> 	}
>>
>>
>> I imagine in DT we want something more like this:
>>
>> 	efuse: efuse at 10000 {
>> 		compatible = "efuse";
>> 		reg = <0x10000 0x1000>;
>> 	}
>>
>> 	thermal-sensor at 34000 {
>> 		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