[PATCH 0/6] nvmem: sunxi_sid: native format and A83T/H5 support

[PATCH 0/6] nvmem: sunxi_sid: native format and A83T/H5 support

[Chen-Yu Tsai]

From: Chen-Yu Tsai <wens@csie.org>

Hi everyone,

This series converts the sunxi_sid driver to read out data in native
endianness for all Allwinner SoCs. It was already the case for the H3,
which used a different read-out method. The endianness for this hardware
was found to be either native or little endian [1], based on the data
layout for the thermal sensor calibration data stored within. Some SoCs
have either 1 or 3 sensors, and calibration data for each sensor is 2
bytes wide, with data for 2 sensors packed into 1 word.

The first three patches do some clean-up and improvements of the code
overall. The fourth patch converts the driver to reading out data in
native endianness. The fifth adds support for the A83T and H5. These
two were already listed in the device tree bindings. The last patch
adds a device node for it on H3 and H5.

Please have a look.

Regards
ChenYu

[1] https://lkml.org/lkml/2019/2/18/134

Chen-Yu Tsai (6):
  nvmem: sunxi_sid: Read out SID for randomness without looping
  nvmem: sunxi_sid: Optimize register read-out method
  nvmem: sunxi_sid: Dynamically allocate nvmem_config structure
  nvmem: sunxi_sid: Read out data in native format
  nvmem: sunxi_sid: Support SID on A83T and H5
  ARM: dts: sunxi: h3/h5: Add device node for SID

 arch/arm/boot/dts/sun8i-h3.dtsi              |  4 +
 arch/arm/boot/dts/sunxi-h3-h5.dtsi           |  5 +
 arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi |  4 +
 drivers/nvmem/sunxi_sid.c                    | 98 ++++++++------------
 4 files changed, 52 insertions(+), 59 deletions(-)

-- 
2.20.1

[PATCH 1/6] nvmem: sunxi_sid: Read out SID for randomness without looping

[Chen-Yu Tsai]

From: Chen-Yu Tsai <wens@csie.org>

Since the reg_read callbacks already support arbitrary, but 4-byte
aligned. offsets and lengths into the SID, there is no need for another
for loop just to use it to read 1 byte at a time.

Read out the whole SID block in one go.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/nvmem/sunxi_sid.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
index 570a2e354f30..704c35edf796 100644
--- a/drivers/nvmem/sunxi_sid.c
+++ b/drivers/nvmem/sunxi_sid.c
@@ -154,7 +154,7 @@ static int sunxi_sid_probe(struct platform_device *pdev)
 	struct resource *res;
 	struct nvmem_device *nvmem;
 	struct sunxi_sid *sid;
-	int i, size;
+	int size;
 	char *randomness;
 	const struct sunxi_sid_cfg *cfg;
 
@@ -189,8 +189,7 @@ static int sunxi_sid_probe(struct platform_device *pdev)
 	if (!randomness)
 		return -ENOMEM;
 
-	for (i = 0; i < size; i++)
-		econfig.reg_read(sid, i, &randomness[i], 1);
+	econfig.reg_read(sid, 0, randomness, size);
 
 	add_device_randomness(randomness, size);
 	kfree(randomness);
-- 
2.20.1

[PATCH 2/6] nvmem: sunxi_sid: Optimize register read-out method

[Chen-Yu Tsai]

From: Chen-Yu Tsai <wens@csie.org>

SID cells are 32-bit aligned, and a multiple of 32 bits in length. The
only outlier is the thermal sensor calibration data, which is 16 bits
per sensor. However a whole 64 bits is allocated for this purpose, so
we could consider it conforming to the rule above.

Also, the register read-out method assumes native endian, unlike the
direct MMIO method, which assumes big endian. Thus no endian conversion
is involved.

Under these assumptions, the register read-out method can be slightly
optimized. Instead of reading one word then discarding 3 bytes, read
the whole word directly into the buffer. However, for reads under 4
bytes or trailing bytes, we still use a scratch buffer to extract the
requested bytes.

We could go one step further if .word_size was 4, but changing that
would affect the sysfs interface's behavior.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/nvmem/sunxi_sid.c | 38 ++++++++++++++++++--------------------
 1 file changed, 18 insertions(+), 20 deletions(-)

diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
index 704c35edf796..15fbfab62595 100644
--- a/drivers/nvmem/sunxi_sid.c
+++ b/drivers/nvmem/sunxi_sid.c
@@ -115,36 +115,34 @@ static int sun8i_sid_register_readout(const struct sunxi_sid *sid,
  * to be not reliable at all.
  * Read by the registers instead.
  */
-static int sun8i_sid_read_byte_by_reg(const struct sunxi_sid *sid,
-				      const unsigned int offset,
-				      u8 *out)
-{
-	u32 word;
-	int ret;
-
-	ret = sun8i_sid_register_readout(sid, offset & ~0x03, &word);
-
-	if (ret)
-		return ret;
-
-	*out = (word >> ((offset & 0x3) * 8)) & 0xff;
-
-	return 0;
-}
-
 static int sun8i_sid_read_by_reg(void *context, unsigned int offset,
 				 void *val, size_t bytes)
 {
 	struct sunxi_sid *sid = context;
-	u8 *buf = val;
+	u32 word;
 	int ret;
 
-	while (bytes--) {
-		ret = sun8i_sid_read_byte_by_reg(sid, offset++, buf++);
+	/* .stride = 4 so offset is guaranteed to be aligned */
+	while (bytes >= 4) {
+		ret = sun8i_sid_register_readout(sid, offset, val);
 		if (ret)
 			return ret;
+
+		val += 4;
+		offset += 4;
+		bytes -= 4;
 	}
 
+	if (!bytes)
+		return 0;
+
+	/* Handle any trailing bytes */
+	ret = sun8i_sid_register_readout(sid, offset, &word);
+	if (ret)
+		return ret;
+
+	memcpy(val, &word, bytes);
+
 	return 0;
 }
 
-- 
2.20.1

[PATCH 3/6] nvmem: sunxi_sid: Dynamically allocate nvmem_config structure

[Chen-Yu Tsai]

From: Chen-Yu Tsai <wens@csie.org>

The sunxi_sid driver currently uses a statically allocated nvmem_config
structure that is updated at probe time. This is sub-optimal as it
limits the driver to one instance, and also takes up space even if the
device is not present.

Modify the driver to allocate the nvmem_config structure at probe time,
plugging in the desired parameters along the way.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/nvmem/sunxi_sid.c | 32 +++++++++++++++++---------------
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
index 15fbfab62595..75c1f48cb3d0 100644
--- a/drivers/nvmem/sunxi_sid.c
+++ b/drivers/nvmem/sunxi_sid.c
@@ -35,13 +35,6 @@
 #define SUN8I_SID_OP_LOCK	(0xAC << 8)
 #define SUN8I_SID_READ		BIT(1)
 
-static struct nvmem_config econfig = {
-	.name = "sunxi-sid",
-	.read_only = true,
-	.stride = 4,
-	.word_size = 1,
-};
-
 struct sunxi_sid_cfg {
 	u32	value_offset;
 	u32	size;
@@ -150,6 +143,7 @@ static int sunxi_sid_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct resource *res;
+	struct nvmem_config *nvmem_cfg;
 	struct nvmem_device *nvmem;
 	struct sunxi_sid *sid;
 	int size;
@@ -172,14 +166,23 @@ static int sunxi_sid_probe(struct platform_device *pdev)
 
 	size = cfg->size;
 
-	econfig.size = size;
-	econfig.dev = dev;
+	nvmem_cfg = devm_kzalloc(dev, sizeof(*nvmem_cfg), GFP_KERNEL);
+	if (!nvmem_cfg)
+		return -ENOMEM;
+
+	nvmem_cfg->dev = dev;
+	nvmem_cfg->name = "sunxi-sid";
+	nvmem_cfg->read_only = true;
+	nvmem_cfg->size = cfg->size;
+	nvmem_cfg->word_size = 1;
+	nvmem_cfg->stride = 4;
+	nvmem_cfg->priv = sid;
 	if (cfg->need_register_readout)
-		econfig.reg_read = sun8i_sid_read_by_reg;
+		nvmem_cfg->reg_read = sun8i_sid_read_by_reg;
 	else
-		econfig.reg_read = sunxi_sid_read;
-	econfig.priv = sid;
-	nvmem = devm_nvmem_register(dev, &econfig);
+		nvmem_cfg->reg_read = sunxi_sid_read;
+
+	nvmem = devm_nvmem_register(dev, nvmem_cfg);
 	if (IS_ERR(nvmem))
 		return PTR_ERR(nvmem);
 
@@ -187,8 +190,7 @@ static int sunxi_sid_probe(struct platform_device *pdev)
 	if (!randomness)
 		return -ENOMEM;
 
-	econfig.reg_read(sid, 0, randomness, size);
-
+	nvmem_cfg->reg_read(sid, 0, randomness, size);
 	add_device_randomness(randomness, size);
 	kfree(randomness);
 
-- 
2.20.1

[PATCH 4/6] nvmem: sunxi_sid: Read out data in native format

[Chen-Yu Tsai]

From: Chen-Yu Tsai <wens@csie.org>

Originally the SID e-fuses were thought to be in big-endian format.
Later sources show that they are in fact native or little-endian.
The most compelling evidence is the thermal sensor calibration data,
which is a set of one to three 16-bit values. In native-endian they
are in 16-bit cells with increasing offsets, whereas with big-endian
they are in the wrong order, and a gap with no data will show if there
are one or three cells.

Switch to a native endian representation for the nvmem device. For the
H3, the register read-out method was already returning data in native
endian. This only affects the other SoCs.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/nvmem/sunxi_sid.c | 23 +----------------------
 1 file changed, 1 insertion(+), 22 deletions(-)

diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
index 75c1f48cb3d0..14c114620ed6 100644
--- a/drivers/nvmem/sunxi_sid.c
+++ b/drivers/nvmem/sunxi_sid.c
@@ -46,33 +46,12 @@ struct sunxi_sid {
 	u32			value_offset;
 };
 
-/* We read the entire key, due to a 32 bit read alignment requirement. Since we
- * want to return the requested byte, this results in somewhat slower code and
- * uses 4 times more reads as needed but keeps code simpler. Since the SID is
- * only very rarely probed, this is not really an issue.
- */
-static u8 sunxi_sid_read_byte(const struct sunxi_sid *sid,
-			      const unsigned int offset)
-{
-	u32 sid_key;
-
-	sid_key = ioread32be(sid->base + round_down(offset, 4));
-	sid_key >>= (offset % 4) * 8;
-
-	return sid_key; /* Only return the last byte */
-}
-
 static int sunxi_sid_read(void *context, unsigned int offset,
 			  void *val, size_t bytes)
 {
 	struct sunxi_sid *sid = context;
-	u8 *buf = val;
-
-	/* Offset the read operation to the real position of SID */
-	offset += sid->value_offset;
 
-	while (bytes--)
-		*buf++ = sunxi_sid_read_byte(sid, offset++);
+	memcpy_fromio(val, sid->base + sid->value_offset + offset, bytes);
 
 	return 0;
 }
-- 
2.20.1

[PATCH 5/6] nvmem: sunxi_sid: Support SID on A83T and H5

[Chen-Yu Tsai]

From: Chen-Yu Tsai <wens@csie.org>

The device tree binding already lists compatible strings for these two
SoCs. They don't have the defect as seen on the H3, and the size and
register layout is the same as the A64. Furthermore, the driver does
not include nvmem cell definitions.

Add support for these two compatible strings, re-using the config for
the A64.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 drivers/nvmem/sunxi_sid.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
index 14c114620ed6..e7936380ce89 100644
--- a/drivers/nvmem/sunxi_sid.c
+++ b/drivers/nvmem/sunxi_sid.c
@@ -200,8 +200,10 @@ static const struct sunxi_sid_cfg sun50i_a64_cfg = {
 static const struct of_device_id sunxi_sid_of_match[] = {
 	{ .compatible = "allwinner,sun4i-a10-sid", .data = &sun4i_a10_cfg },
 	{ .compatible = "allwinner,sun7i-a20-sid", .data = &sun7i_a20_cfg },
+	{ .compatible = "allwinner,sun8i-a83t-sid", .data = &sun50i_a64_cfg },
 	{ .compatible = "allwinner,sun8i-h3-sid", .data = &sun8i_h3_cfg },
 	{ .compatible = "allwinner,sun50i-a64-sid", .data = &sun50i_a64_cfg },
+	{ .compatible = "allwinner,sun50i-h5-sid", .data = &sun50i_a64_cfg },
 	{/* sentinel */},
 };
 MODULE_DEVICE_TABLE(of, sunxi_sid_of_match);
-- 
2.20.1

[PATCH 6/6] ARM: dts: sunxi: h3/h5: Add device node for SID

[Chen-Yu Tsai]

From: Chen-Yu Tsai <wens@csie.org>

The device tree binding already lists compatible strings for these two
SoCs. Add a device node for them.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
 arch/arm/boot/dts/sun8i-h3.dtsi              | 4 ++++
 arch/arm/boot/dts/sunxi-h3-h5.dtsi           | 5 +++++
 arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 4 ++++
 3 files changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 959d265e7254..e37c30e811d3 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -231,3 +231,7 @@
 &rtc {
 	compatible = "allwinner,sun8i-h3-rtc";
 };
+
+&sid {
+	compatible = "allwinner,sun8i-h3-sid";
+};
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index d74a6cbbfdf4..e2100b673a51 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -227,6 +227,11 @@
 			#size-cells = <0>;
 		};
 
+		sid: eeprom@1c14000 {
+			/* compatible and clocks are in per SoC .dtsi file */
+			reg = <0x1c14000 0x400>;
+		};
+
 		usb_otg: usb@1c19000 {
 			compatible = "allwinner,sun8i-h3-musb";
 			reg = <0x01c19000 0x400>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
index 96acafd3a852..f002a496d7cb 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
@@ -209,3 +209,7 @@
 &rtc {
 	compatible = "allwinner,sun50i-h5-rtc";
 };
+
+&sid {
+	compatible = "allwinner,sun50i-h5-sid";
+};
-- 
2.20.1

Re: [PATCH 4/6] nvmem: sunxi_sid: Read out data in native format

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

Hi,

On Mon, Mar 18, 2019 at 03:33:52PM +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai <wens@csie.org>
>
> Originally the SID e-fuses were thought to be in big-endian format.
> Later sources show that they are in fact native or little-endian.
> The most compelling evidence is the thermal sensor calibration data,
> which is a set of one to three 16-bit values. In native-endian they
> are in 16-bit cells with increasing offsets, whereas with big-endian
> they are in the wrong order, and a gap with no data will show if there
> are one or three cells.
>
> Switch to a native endian representation for the nvmem device. For the
> H3, the register read-out method was already returning data in native
> endian. This only affects the other SoCs.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>

I thought only the newer SoCs were impacted by this issue?

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 4/6] nvmem: sunxi_sid: Read out data in native format

[Chen-Yu Tsai]

On Mon, Mar 18, 2019 at 4:42 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Hi,
>
> On Mon, Mar 18, 2019 at 03:33:52PM +0800, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai <wens@csie.org>
> >
> > Originally the SID e-fuses were thought to be in big-endian format.
> > Later sources show that they are in fact native or little-endian.
> > The most compelling evidence is the thermal sensor calibration data,
> > which is a set of one to three 16-bit values. In native-endian they
> > are in 16-bit cells with increasing offsets, whereas with big-endian
> > they are in the wrong order, and a gap with no data will show if there
> > are one or three cells.
> >
> > Switch to a native endian representation for the nvmem device. For the
> > H3, the register read-out method was already returning data in native
> > endian. This only affects the other SoCs.
> >
> > Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>
> I thought only the newer SoCs were impacted by this issue?

It is noticable on the newer SoCs. The old ones only have the 128-bit SID,
which could be read either way, as AFAIK it's just a serial number.

If you think we should leave the old ones alone I can factor that in.

ChenYu

Re: [PATCH 4/6] nvmem: sunxi_sid: Read out data in native format

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

On Mon, Mar 18, 2019 at 04:45:19PM +0800, Chen-Yu Tsai wrote:
> On Mon, Mar 18, 2019 at 4:42 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > Hi,
> >
> > On Mon, Mar 18, 2019 at 03:33:52PM +0800, Chen-Yu Tsai wrote:
> > > From: Chen-Yu Tsai <wens@csie.org>
> > >
> > > Originally the SID e-fuses were thought to be in big-endian format.
> > > Later sources show that they are in fact native or little-endian.
> > > The most compelling evidence is the thermal sensor calibration data,
> > > which is a set of one to three 16-bit values. In native-endian they
> > > are in 16-bit cells with increasing offsets, whereas with big-endian
> > > they are in the wrong order, and a gap with no data will show if there
> > > are one or three cells.
> > >
> > > Switch to a native endian representation for the nvmem device. For the
> > > H3, the register read-out method was already returning data in native
> > > endian. This only affects the other SoCs.
> > >
> > > Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >
> > I thought only the newer SoCs were impacted by this issue?
>
> It is noticable on the newer SoCs. The old ones only have the 128-bit SID,
> which could be read either way, as AFAIK it's just a serial number.
>
> If you think we should leave the old ones alone I can factor that in.

IIRC, there was also the SoC ID in the SID on those SoCs as well,
which we might have to use in the future so we'll want to make sure it
is correct.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 4/6] nvmem: sunxi_sid: Read out data in native format

[Chen-Yu Tsai]

On Mon, Mar 18, 2019 at 4:57 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Mon, Mar 18, 2019 at 04:45:19PM +0800, Chen-Yu Tsai wrote:
> > On Mon, Mar 18, 2019 at 4:42 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > >
> > > Hi,
> > >
> > > On Mon, Mar 18, 2019 at 03:33:52PM +0800, Chen-Yu Tsai wrote:
> > > > From: Chen-Yu Tsai <wens@csie.org>
> > > >
> > > > Originally the SID e-fuses were thought to be in big-endian format.
> > > > Later sources show that they are in fact native or little-endian.
> > > > The most compelling evidence is the thermal sensor calibration data,
> > > > which is a set of one to three 16-bit values. In native-endian they
> > > > are in 16-bit cells with increasing offsets, whereas with big-endian
> > > > they are in the wrong order, and a gap with no data will show if there
> > > > are one or three cells.
> > > >
> > > > Switch to a native endian representation for the nvmem device. For the
> > > > H3, the register read-out method was already returning data in native
> > > > endian. This only affects the other SoCs.
> > > >
> > > > Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> > >
> > > I thought only the newer SoCs were impacted by this issue?
> >
> > It is noticable on the newer SoCs. The old ones only have the 128-bit SID,
> > which could be read either way, as AFAIK it's just a serial number.
> >
> > If you think we should leave the old ones alone I can factor that in.
>
> IIRC, there was also the SoC ID in the SID on those SoCs as well,
> which we might have to use in the future so we'll want to make sure it
> is correct.

We'll need to ask Allwinner about this then.

FWIW, the fel command in sunxi-tools reads them out in little endian. I
believe this and the SID page on the linux-sunxi wiki predate the sunxi_sid
driver.

ChenYu

Re: [PATCH 4/6] nvmem: sunxi_sid: Read out data in native format

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2249 bytes --]

On Mon, Mar 18, 2019 at 05:09:44PM +0800, Chen-Yu Tsai wrote:
> On Mon, Mar 18, 2019 at 4:57 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Mon, Mar 18, 2019 at 04:45:19PM +0800, Chen-Yu Tsai wrote:
> > > On Mon, Mar 18, 2019 at 4:42 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Mon, Mar 18, 2019 at 03:33:52PM +0800, Chen-Yu Tsai wrote:
> > > > > From: Chen-Yu Tsai <wens@csie.org>
> > > > >
> > > > > Originally the SID e-fuses were thought to be in big-endian format.
> > > > > Later sources show that they are in fact native or little-endian.
> > > > > The most compelling evidence is the thermal sensor calibration data,
> > > > > which is a set of one to three 16-bit values. In native-endian they
> > > > > are in 16-bit cells with increasing offsets, whereas with big-endian
> > > > > they are in the wrong order, and a gap with no data will show if there
> > > > > are one or three cells.
> > > > >
> > > > > Switch to a native endian representation for the nvmem device. For the
> > > > > H3, the register read-out method was already returning data in native
> > > > > endian. This only affects the other SoCs.
> > > > >
> > > > > Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> > > >
> > > > I thought only the newer SoCs were impacted by this issue?
> > >
> > > It is noticable on the newer SoCs. The old ones only have the 128-bit SID,
> > > which could be read either way, as AFAIK it's just a serial number.
> > >
> > > If you think we should leave the old ones alone I can factor that in.
> >
> > IIRC, there was also the SoC ID in the SID on those SoCs as well,
> > which we might have to use in the future so we'll want to make sure it
> > is correct.
>
> We'll need to ask Allwinner about this then.
>
> FWIW, the fel command in sunxi-tools reads them out in little endian. I
> believe this and the SID page on the linux-sunxi wiki predate the sunxi_sid
> driver.

Yeah, and the driver has a readl as well:
https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/arch/arm/plat-sunxi/soc-detect.c#L92

For the whole series,
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [linux-sunxi] [PATCH 6/6] ARM: dts: sunxi: h3/h5: Add device node for SID

[Samuel Holland]

On 03/18/19 02:33, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai <wens@csie.org>
> 
> The device tree binding already lists compatible strings for these two
> SoCs. Add a device node for them.
> 
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi              | 4 ++++
>  arch/arm/boot/dts/sunxi-h3-h5.dtsi           | 5 +++++
>  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 4 ++++
>  3 files changed, 13 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 959d265e7254..e37c30e811d3 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -231,3 +231,7 @@
>  &rtc {
>  	compatible = "allwinner,sun8i-h3-rtc";
>  };
> +
> +&sid {
> +	compatible = "allwinner,sun8i-h3-sid";
> +};
> diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> index d74a6cbbfdf4..e2100b673a51 100644
> --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> @@ -227,6 +227,11 @@
>  			#size-cells = <0>;
>  		};
>  
> +		sid: eeprom@1c14000 {
> +			/* compatible and clocks are in per SoC .dtsi file */

There are no clocks for this node, just a compatible string.

> +			reg = <0x1c14000 0x400>;
> +		};
> +
>  		usb_otg: usb@1c19000 {
>  			compatible = "allwinner,sun8i-h3-musb";
>  			reg = <0x01c19000 0x400>;
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> index 96acafd3a852..f002a496d7cb 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
> @@ -209,3 +209,7 @@
>  &rtc {
>  	compatible = "allwinner,sun50i-h5-rtc";
>  };
> +
> +&sid {
> +	compatible = "allwinner,sun50i-h5-sid";
> +};
> 

Re: [linux-sunxi] [PATCH 6/6] ARM: dts: sunxi: h3/h5: Add device node for SID

[Chen-Yu Tsai]

On Tue, Mar 19, 2019 at 9:55 AM Samuel Holland <samuel@sholland.org> wrote:
>
> On 03/18/19 02:33, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai <wens@csie.org>
> >
> > The device tree binding already lists compatible strings for these two
> > SoCs. Add a device node for them.
> >
> > Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> > ---
> >  arch/arm/boot/dts/sun8i-h3.dtsi              | 4 ++++
> >  arch/arm/boot/dts/sunxi-h3-h5.dtsi           | 5 +++++
> >  arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 4 ++++
> >  3 files changed, 13 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> > index 959d265e7254..e37c30e811d3 100644
> > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > @@ -231,3 +231,7 @@
> >  &rtc {
> >       compatible = "allwinner,sun8i-h3-rtc";
> >  };
> > +
> > +&sid {
> > +     compatible = "allwinner,sun8i-h3-sid";
> > +};
> > diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > index d74a6cbbfdf4..e2100b673a51 100644
> > --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> > @@ -227,6 +227,11 @@
> >                       #size-cells = <0>;
> >               };
> >
> > +             sid: eeprom@1c14000 {
> > +                     /* compatible and clocks are in per SoC .dtsi file */
>
> There are no clocks for this node, just a compatible string.

Right. I'll fix this when applying.

ChenYu

Re: [PATCH 0/6] nvmem: sunxi_sid: native format and A83T/H5 support

[Srinivas Kandagatla]

On 18/03/2019 07:33, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai <wens@csie.org>
> 
> Hi everyone,
> 
> This series converts the sunxi_sid driver to read out data in native
> endianness for all Allwinner SoCs. It was already the case for the H3,
> which used a different read-out method. The endianness for this hardware
> was found to be either native or little endian [1], based on the data
> layout for the thermal sensor calibration data stored within. Some SoCs
> have either 1 or 3 sensors, and calibration data for each sensor is 2
> bytes wide, with data for 2 sensors packed into 1 word.
> 
> The first three patches do some clean-up and improvements of the code
> overall. The fourth patch converts the driver to reading out data in
> native endianness. The fifth adds support for the A83T and H5. These
> two were already listed in the device tree bindings. The last patch
> adds a device node for it on H3 and H5.
> 
> Please have a look.
> 
> Regards
> ChenYu
> 
> [1] https://lkml.org/lkml/2019/2/18/134
> 
> Chen-Yu Tsai (6):
>    nvmem: sunxi_sid: Read out SID for randomness without looping
>    nvmem: sunxi_sid: Optimize register read-out method
>    nvmem: sunxi_sid: Dynamically allocate nvmem_config structure
>    nvmem: sunxi_sid: Read out data in native format
>    nvmem: sunxi_sid: Support SID on A83T and H5
>    ARM: dts: sunxi: h3/h5: Add device node for SID
> 
Applied all the nvmem patches except DTS patch to nvmem next

Thanks,
srini

Re: [PATCH 0/6] nvmem: sunxi_sid: native format and A83T/H5 support

[Chen-Yu Tsai]

On Wed, Mar 20, 2019 at 10:25 PM Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
> On 18/03/2019 07:33, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai <wens@csie.org>
> >
> > Hi everyone,
> >
> > This series converts the sunxi_sid driver to read out data in native
> > endianness for all Allwinner SoCs. It was already the case for the H3,
> > which used a different read-out method. The endianness for this hardware
> > was found to be either native or little endian [1], based on the data
> > layout for the thermal sensor calibration data stored within. Some SoCs
> > have either 1 or 3 sensors, and calibration data for each sensor is 2
> > bytes wide, with data for 2 sensors packed into 1 word.
> >
> > The first three patches do some clean-up and improvements of the code
> > overall. The fourth patch converts the driver to reading out data in
> > native endianness. The fifth adds support for the A83T and H5. These
> > two were already listed in the device tree bindings. The last patch
> > adds a device node for it on H3 and H5.
> >
> > Please have a look.
> >
> > Regards
> > ChenYu
> >
> > [1] https://lkml.org/lkml/2019/2/18/134
> >
> > Chen-Yu Tsai (6):
> >    nvmem: sunxi_sid: Read out SID for randomness without looping
> >    nvmem: sunxi_sid: Optimize register read-out method
> >    nvmem: sunxi_sid: Dynamically allocate nvmem_config structure
> >    nvmem: sunxi_sid: Read out data in native format
> >    nvmem: sunxi_sid: Support SID on A83T and H5
> >    ARM: dts: sunxi: h3/h5: Add device node for SID
> >
> Applied all the nvmem patches except DTS patch to nvmem next

Thanks. Merged the DTS patch with Maxime's ack for 5.2.

ChenYu