From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Tudor.Ambarus@microchip.com
Cc: thomas.petazzoni@bootlin.com, kamel.bouhara@bootlin.com,
Ludovic.Desroches@microchip.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5] soc: at91: Add Atmel SFR SN (Serial Number) support
Date: Fri, 4 Oct 2019 17:00:57 +0200 [thread overview]
Message-ID: <20191004150057.GZ4106@piout.net> (raw)
In-Reply-To: <a8c16919-9842-8a2a-81b0-16551c6a7944@microchip.com>
On 04/10/2019 14:54:37+0000, Tudor.Ambarus@microchip.com wrote:
>
>
> On 10/04/2019 05:12 PM, Kamel Bouhara wrote:
> > External E-Mail
> >
> >
> > Add support to read SFR's read-only registers providing the SoC
> > Serial Numbers (SN0+SN1) to userspace.
> >
> > ~ # hexdump -n 8 -e'"%d\n"' /sys/bus/nvmem/devices/atmel-sfr0/nvmem
> > 959527243
> > 371539274
> >
> > Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
> > ---
> > Changes in v5:
> > - Removed the blankline at EOF
> > - Feeded the entropy pool with the SoC SN using add_device_randomness()
> > and do it only once at probe().
> >
> > drivers/soc/atmel/Kconfig | 11 +++++
> > drivers/soc/atmel/Makefile | 1 +
> > drivers/soc/atmel/sfr.c | 99 ++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 111 insertions(+)
> > create mode 100644 drivers/soc/atmel/sfr.c
> >
> > diff --git a/drivers/soc/atmel/Kconfig b/drivers/soc/atmel/Kconfig
> > index 05528139b023..50caf6db9c0e 100644
> > --- a/drivers/soc/atmel/Kconfig
> > +++ b/drivers/soc/atmel/Kconfig
> > @@ -5,3 +5,14 @@ config AT91_SOC_ID
> > default ARCH_AT91
> > help
> > Include support for the SoC bus on the Atmel ARM SoCs.
> > +
> > +config AT91_SOC_SFR
> > + tristate "Special Function Registers support"
> > + depends on ARCH_AT91 || COMPILE_TEST
> > + help
> > + This is a driver for the Special Function Registers available on
> > + Atmel SAMA5Dx SoCs, providing access to specific aspects of the
> > + integrated memory, bridge implementations, processor etc.
> > +
> > + This driver can also be built as a module. If so, the module
> > + will be called sfr.
> > diff --git a/drivers/soc/atmel/Makefile b/drivers/soc/atmel/Makefile
> > index 7ca355d10553..d849a897cd77 100644
> > --- a/drivers/soc/atmel/Makefile
> > +++ b/drivers/soc/atmel/Makefile
> > @@ -1,2 +1,3 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > obj-$(CONFIG_AT91_SOC_ID) += soc.o
> > +obj-$(CONFIG_AT91_SOC_SFR) += sfr.o
> > diff --git a/drivers/soc/atmel/sfr.c b/drivers/soc/atmel/sfr.c
> > new file mode 100644
> > index 000000000000..145e9af63b4c
> > --- /dev/null
> > +++ b/drivers/soc/atmel/sfr.c
> > @@ -0,0 +1,99 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * sfr.c - driver for special function registers
> > + *
> > + * Copyright (C) 2019 Bootlin.
> > + *
> > + */
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/module.h>
> > +#include <linux/nvmem-provider.h>
> > +#include <linux/random.h>
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +
> > +#define SFR_SN0 0x4c
> > +#define SFR_SN_SIZE 8
> > +
> > +struct atmel_sfr_priv {
> > + struct regmap *regmap;
> > +};
> > +
> > +static int atmel_sfr_read(void *context, unsigned int offset,
> > + void *buf, size_t bytes)
> > +{
> > + struct atmel_sfr_priv *priv = context;
> > +
> > + return regmap_bulk_read(priv->regmap, SFR_SN0 + offset,
> > + buf, bytes / 4);
> > +}
> > +
> > +static struct nvmem_config atmel_sfr_nvmem_config = {
> > + .name = "atmel-sfr",
> > + .read_only = true,
> > + .word_size = 4,
> > + .stride = 4,
> > + .size = SFR_SN_SIZE,
> > + .reg_read = atmel_sfr_read,
> > +};
> > +
> > +static int atmel_sfr_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct device_node *np = dev->of_node;
> > + struct nvmem_device *nvmem;
> > + struct atmel_sfr_priv *priv;
> > + u8 sn[SFR_SN_SIZE];
> > + int ret;
> > +
> > + priv = devm_kmalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + priv->regmap = syscon_node_to_regmap(np);
> > + if (IS_ERR(priv->regmap)) {
> > + dev_err(dev, "cannot get parent's regmap\n");
> > + return PTR_ERR(priv->regmap);
> > + }
> > +
> > + atmel_sfr_nvmem_config.dev = dev;
> > + atmel_sfr_nvmem_config.priv = priv;
> > +
> > + nvmem = devm_nvmem_register(dev, &atmel_sfr_nvmem_config);
> > + if (IS_ERR(nvmem)) {
> > + dev_err(dev, "error registering nvmem config\n");
> > + return PTR_ERR(nvmem);
> > + }
> > +
> > + ret = atmel_sfr_read(priv, 0, sn, SFR_SN_SIZE);
> > + if (ret == 0)
> > + add_device_randomness(sn, SFR_SN_SIZE);
> > +
> > + return 0;
>
> return ret;
>
> to not miss a possible error from atmel_sfr_read().
>
> The code looks good, with this fixed one can add:
> Tested-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
>
> As I told in v3, I have some doubts on the use cases for this driver, but let's
> see what the at91 folks think.
>
There is already at least one microchip customer using it so I'm going
to apply it.
--
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
next prev parent reply other threads:[~2019-10-04 15:02 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 [this message]
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
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=20191004150057.GZ4106@piout.net \
--to=alexandre.belloni@bootlin.com \
--cc=Ludovic.Desroches@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).