linux-kernel - 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-next>] [day] [month] [year] [list]

Message-ID: <53BC4DD7.20906@codeaurora.org>
Date:	Tue, 08 Jul 2014 13:00:23 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
CC:	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: a case for a common efuse API?

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>;
	}

Where we can point to the efuse and give an address offset. From code we
could then call some efuse_read() function to read the sensor's
calibration data.

It's been suggested that we use syscon for this, but I wonder if that is
the right thing to do. With a syscon you're usually writing some
registers that got lumped together with other registers that aren't
directly related to your driver. It doesn't seem like syscon is made for
reading fuses or other things like eeproms. Maybe I'm wrong though.

Using syscon would probably work if we could add a way to point to
offsets within the syscon node (the 0x18 part in the example). In my
specific use-case the calibration data may have different offsets
depending on which SoC the hardware is instantiated in so we could also
make syscon work if the compatible field for the sensor node indicates
which SoC it is.

I added Tegra folks because I see that on Tegra this hardware is exposed
via an SoC specific API, tegra_fuse_readl(), and an associated driver in
drivers/misc/fuse/tegra/. Unfortunately I don't see any users of the API
outside of the speedo code in the same directory and the sysfs bin
attribute that may or may not be in use by some userspace code.

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