On 11 January 2018 at 20:38, Rob Herring [off-list ref] wrote:

On Sat, Jan 6, 2018 at 6:43 AM, PrasannaKumar Muralidharan
[off-list ref] wrote:

quoted

Hi Rob,

On 4 January 2018 at 01:32, Rob Herring [off-list ref] wrote:

quoted

On Thu, Dec 28, 2017 at 10:29:52PM +0100, Mathieu Malaterre wrote:

quoted

From: PrasannaKumar Muralidharan <redacted>

This patch brings support for the JZ4780 efuse. Currently it only expose
a read only access to the entire 8K bits efuse memory.

Tested-by: Mathieu Malaterre <redacted>
Signed-off-by: PrasannaKumar Muralidharan <redacted>
Signed-off-by: Mathieu Malaterre <redacted>
---
 .../ABI/testing/sysfs-driver-jz4780-efuse          |  16 ++
 .../bindings/nvmem/ingenic,jz4780-efuse.txt        |  17 ++

Please split bindings to separate patch.

quoted

 MAINTAINERS                                        |   5 +
 arch/mips/boot/dts/ingenic/jz4780.dtsi             |  40 ++-

dts files should also be separate.

quoted

 drivers/nvmem/Kconfig                              |  10 +
 drivers/nvmem/Makefile                             |   2 +
 drivers/nvmem/jz4780-efuse.c                       | 305 +++++++++++++++++++++
 7 files changed, 383 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-jz4780-efuse
 create mode 100644 Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.txt
 create mode 100644 drivers/nvmem/jz4780-efuse.c

diff --git a/Documentation/ABI/testing/sysfs-driver-jz4780-efuse b/Documentation/ABI/testing/sysfs-driver-jz4780-efuse
new file mode 100644
index 000000000000..bb6f5d6ceea0
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-jz4780-efuse

@@ -0,0 +1,16 @@
+What:                /sys/devices/*/<our-device>/nvmem
+Date:                December 2017
+Contact:     PrasannaKumar Muralidharan <prasannatsmkumar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+Description: read-only access to the efuse on the Ingenic JZ4780 SoC
+             The SoC has a one time programmable 8K efuse that is
+             split into segments. The driver supports read only.
+             The segments are
+             0x000   64 bit Random Number
+             0x008  128 bit Ingenic Chip ID
+             0x018  128 bit Customer ID
+             0x028 3520 bit Reserved
+             0x1E0    8 bit Protect Segment
+             0x1E1 2296 bit HDMI Key
+             0x300 2048 bit Security boot key

Why do these need to be exposed to userspace?

sysfs is 1 value per file and this is lots of different things.

We already have ways to feed random data (entropy) to the system. And we
have a way to expose SoC ID info to userspace (socdev).

Currently ingenic chip id is not used anywhere. The vendor BSP exposed
only chip id and customer id. Should we do the same? Please provide
your suggestion.

No. Don't create an ABI if you don't really need it.

Rob,
MAC address of the ethernet device is stored in customer id segment of
efuse. So only customer id is needed. Do you think exposing customer
id would suffice?

Srini,
Only user would be dm900 ethernet driver (need to make changes to it
once the efuse driver goes in). There is no need to expose it to user
space. I am planning to modify nvmem core to not expose efuse if the
efuse driver chooses so. Do you think it makes sense? The need to
maintain ABI for user space disappears if such a change is introduced.

Thanks,
PrasannaKumar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html