From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Nicolas.Ferre@microchip.com, Tudor.Ambarus@microchip.com,
kamel.bouhara@bootlin.com, Ludovic.Desroches@microchip.com,
linux-arm-kernel@lists.infradead.org,
thomas.petazzoni@bootlin.com
Subject: Re: [PATCH v5] soc: at91: Add Atmel SFR SN (Serial Number) support
Date: Tue, 5 Nov 2019 18:29:36 +0100 [thread overview]
Message-ID: <20191105172936.GG8309@piout.net> (raw)
In-Reply-To: <20191101071348.niwyn3w3ybxoltvg@falbala.internal.home.lespocky.de>
On 01/11/2019 08:13:49+0100, Alexander Dahl wrote:
> Hei hei,
>
> I know this was already applied, but let me add some comments.
>
> On Fri, Oct 04, 2019 at 03:25:27PM +0000, Nicolas.Ferre@microchip.com wrote:
> > Well, I'm sure to not know all the applications of this feature but
> > surely unique serial number (per single chip) is very useful while
> > wanting to identify your system precisely: attributing a MAC address,
> > pairing with one service or user software, generating unique keys, etc.
>
> +1
>
> > What I don't know is if there is special API in the kernel to use it as
> > several vendors seem to expose it differently (/proc/cpuinfo being one
> > other option). This one in nvmem /sys file is surely a valid one.
>
> With commit 9aebf4de2203 ("base: soc: Add serial_number attribute to soc")
> there was added a member serial_number to struct soc_device_attribute.
> As far as I can see this is part of mainline since v5.4-rc1.
>
> I saw some patches for i.MX on this list recently, which also got
> applied, and which use that mechanism. So there seem to be at least
> two different ways to access this now.
>
> FWIW: I was working on a patch for exposing the sama5d2 SN through
> that interface. If anyone is interested:
>
> https://github.com/LeSpocky/linux/tree/wip/sama5d2-sn-squash
>
The main issue with that interface is that there is no way to consume
the SN from the kernel while nvmem has both in-kernel and userspace
APIs.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2019-11-05 17:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-04 14:12 [PATCH v5] soc: at91: Add Atmel SFR SN (Serial Number) support Kamel Bouhara
2019-10-04 14:54 ` Tudor.Ambarus
2019-10-04 15:00 ` Alexandre Belloni
2019-10-04 15:04 ` Tudor.Ambarus
2019-10-04 15:10 ` Alexandre Belloni
2019-10-04 15:16 ` Tudor.Ambarus
2019-10-04 15:25 ` Nicolas.Ferre
2019-11-01 7:13 ` Alexander Dahl
2019-11-05 17:29 ` Alexandre Belloni [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191105172936.GG8309@piout.net \
--to=alexandre.belloni@bootlin.com \
--cc=Ludovic.Desroches@microchip.com \
--cc=Nicolas.Ferre@microchip.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=kamel.bouhara@bootlin.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).