2021-06-07 12:29:00

by Jiri Prchal

[permalink] [raw]
Subject: [PATCH v7 0/5] add support for FRAM

Adds support for Cypress FRAMs.

Jiri Prchal (5):
nvmem: eeprom: at25: prepare basics for FRAM support
nvmem: eeprom: at25: add support for FRAM
nvmem: eeprom: add documentation for FRAM
nvmem: eeprom: at25: export FRAM serial num
nvmem: eeprom: add documentation of sysfs sernum file

.../ABI/testing/sysfs-class-spi-eeprom | 6 +
.../devicetree/bindings/eeprom/at25.yaml | 31 +++-
drivers/misc/eeprom/Kconfig | 5 +-
drivers/misc/eeprom/at25.c | 160 ++++++++++++++----
drivers/nvmem/core.c | 4 +
include/linux/nvmem-provider.h | 1 +
6 files changed, 169 insertions(+), 38 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-spi-eeprom

--
2.25.1


2021-06-07 12:29:12

by Jiri Prchal

[permalink] [raw]
Subject: [PATCH v7 4/5] nvmem: eeprom: at25: export FRAM serial num

This exports serial number of FRAM in sysfs file named "sernum".
Formatted in hex, each byte separated by space.
Example:
$ cat /sys/class/spi_master/spi0/spi0.0/sernum
0000a43644f2ae6c

Signed-off-by: Jiri Prchal <[email protected]>
---
v2: no change here
v3: resend and added more recipients
v4: resend
v5: reworked up on Greg comments: no spaces in string, sysfs done correctly
v6: no change here
v7: moved FM25_SN_LEN, static array, used sysfs_emit, DEVICE_ATTR_RO
---
drivers/misc/eeprom/at25.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/eeprom/at25.c b/drivers/misc/eeprom/at25.c
index 3b7ffef1f0d7..a28dfd7e1798 100644
--- a/drivers/misc/eeprom/at25.c
+++ b/drivers/misc/eeprom/at25.c
@@ -31,6 +31,7 @@
* AT25M02, AT25128B
*/

+#define FM25_SN_LEN 8 /* serial number length */
struct at25_data {
struct spi_device *spi;
struct mutex lock;
@@ -39,6 +40,7 @@ struct at25_data {
struct nvmem_config nvmem_config;
struct nvmem_device *nvmem;
int has_sernum;
+ u8 sernum[FM25_SN_LEN];
};

#define AT25_WREN 0x06 /* latch the write enable */
@@ -172,6 +174,21 @@ static int fm25_aux_read(struct at25_data *at25, char *buf, uint8_t command,
return status;
}

+static ssize_t sernum_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct at25_data *at25;
+
+ at25 = dev_get_drvdata(dev);
+ return sysfs_emit(buf, "%016llx\n", *(unsigned long long *)at25->sernum);
+}
+static DEVICE_ATTR_RO(sernum);
+
+static struct attribute *sernum_attrs[] = {
+ &dev_attr_sernum.attr,
+ NULL,
+};
+ATTRIBUTE_GROUPS(sernum);
+
static int at25_ee_write(void *priv, unsigned int off, void *val, size_t count)
{
struct at25_data *at25 = priv;
@@ -416,8 +433,10 @@ static int at25_probe(struct spi_device *spi)
else
at25->chip.flags |= EE_ADDR2;

- if (id[8])
+ if (id[8]) {
at25->has_sernum = 1;
+ fm25_aux_read(at25, at25->sernum, FM25_RDSN, FM25_SN_LEN);
+ }
else
at25->has_sernum = 0;

@@ -471,6 +490,7 @@ static struct spi_driver at25_driver = {
.driver = {
.name = "at25",
.of_match_table = at25_of_match,
+ .dev_groups = sernum_groups,
},
.probe = at25_probe,
};
--
2.25.1

2021-06-07 12:29:24

by Jiri Prchal

[permalink] [raw]
Subject: [PATCH v7 2/5] nvmem: eeprom: at25: add support for FRAM

Added support for Cypress FRAMs.
These frams have ID and some of them have serial number too.
Size of them is recognized by ID. They don't have pages, it could
be read or written at once, but it's limited in this driver to
io limit 4096.

Signed-off-by: Jiri Prchal <[email protected]>
---
v2: fixed warning at %zd at int
Reported-by: kernel test robot <[email protected]>
v3: resend and added more recipients
v4: resend
v5: used in-kernel function int_pow
v6: no change here
v7: moved definition of sernum size to patch 4
---
drivers/misc/eeprom/Kconfig | 5 +-
drivers/misc/eeprom/at25.c | 140 ++++++++++++++++++++++++++++--------
2 files changed, 113 insertions(+), 32 deletions(-)

diff --git a/drivers/misc/eeprom/Kconfig b/drivers/misc/eeprom/Kconfig
index 0f791bfdc1f5..f0a7531f354c 100644
--- a/drivers/misc/eeprom/Kconfig
+++ b/drivers/misc/eeprom/Kconfig
@@ -32,12 +32,13 @@ config EEPROM_AT24
will be called at24.

config EEPROM_AT25
- tristate "SPI EEPROMs from most vendors"
+ tristate "SPI EEPROMs (FRAMs) from most vendors"
depends on SPI && SYSFS
select NVMEM
select NVMEM_SYSFS
help
- Enable this driver to get read/write support to most SPI EEPROMs,
+ Enable this driver to get read/write support to most SPI EEPROMs
+ and Cypress FRAMs,
after you configure the board init code to know about each eeprom
on your target board.

diff --git a/drivers/misc/eeprom/at25.c b/drivers/misc/eeprom/at25.c
index b76e4901b4a4..3b7ffef1f0d7 100644
--- a/drivers/misc/eeprom/at25.c
+++ b/drivers/misc/eeprom/at25.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* at25.c -- support most SPI EEPROMs, such as Atmel AT25 models
+ * and Cypress FRAMs FM25 models
*
* Copyright (C) 2006 David Brownell
*/
@@ -16,6 +17,9 @@
#include <linux/spi/spi.h>
#include <linux/spi/eeprom.h>
#include <linux/property.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/math.h>

/*
* NOTE: this is an *EEPROM* driver. The vagaries of product naming
@@ -34,6 +38,7 @@ struct at25_data {
unsigned addrlen;
struct nvmem_config nvmem_config;
struct nvmem_device *nvmem;
+ int has_sernum;
};

#define AT25_WREN 0x06 /* latch the write enable */
@@ -42,6 +47,9 @@ struct at25_data {
#define AT25_WRSR 0x01 /* write status register */
#define AT25_READ 0x03 /* read byte(s) */
#define AT25_WRITE 0x02 /* write byte(s)/sector */
+#define FM25_SLEEP 0xb9 /* enter sleep mode */
+#define FM25_RDID 0x9f /* read device ID */
+#define FM25_RDSN 0xc3 /* read S/N */

#define AT25_SR_nRDY 0x01 /* nRDY = write-in-progress */
#define AT25_SR_WEN 0x02 /* write enable (latched) */
@@ -51,6 +59,8 @@ struct at25_data {

#define AT25_INSTR_BIT3 0x08 /* Additional address bit in instr */

+#define FM25_ID_LEN 9 /* ID length */
+
#define EE_MAXADDRLEN 3 /* 24 bit addresses, up to 2 MBytes */

/* Specs often allow 5 msec for a page write, sometimes 20 msec;
@@ -58,6 +68,9 @@ struct at25_data {
*/
#define EE_TIMEOUT 25

+#define IS_EEPROM 0
+#define IS_FRAM 1
+
/*-------------------------------------------------------------------------*/

#define io_limit PAGE_SIZE /* bytes */
@@ -129,6 +142,36 @@ static int at25_ee_read(void *priv, unsigned int offset,
return status;
}

+/*
+ * read extra registers as ID or serial number
+ */
+static int fm25_aux_read(struct at25_data *at25, char *buf, uint8_t command,
+ int len)
+{
+ int status;
+ struct spi_transfer t[2];
+ struct spi_message m;
+
+ spi_message_init(&m);
+ memset(t, 0, sizeof(t));
+
+ t[0].tx_buf = &command;
+ t[0].len = 1;
+ spi_message_add_tail(&t[0], &m);
+
+ t[1].rx_buf = buf;
+ t[1].len = len;
+ spi_message_add_tail(&t[1], &m);
+
+ mutex_lock(&at25->lock);
+
+ status = spi_sync(at25->spi, &m);
+ dev_dbg(&at25->spi->dev, "read %d aux bytes --> %d\n", len, status);
+
+ mutex_unlock(&at25->lock);
+ return status;
+}
+
static int at25_ee_write(void *priv, unsigned int off, void *val, size_t count)
{
struct at25_data *at25 = priv;
@@ -303,34 +346,37 @@ static int at25_fw_to_chip(struct device *dev, struct spi_eeprom *chip)
return 0;
}

+static const struct of_device_id at25_of_match[] = {
+ { .compatible = "atmel,at25", .data = (const void *)IS_EEPROM },
+ { .compatible = "cypress,fm25", .data = (const void *)IS_FRAM },
+ { }
+};
+MODULE_DEVICE_TABLE(of, at25_of_match);
+
static int at25_probe(struct spi_device *spi)
{
struct at25_data *at25 = NULL;
struct spi_eeprom chip;
int err;
int sr;
- int addrlen;
+ char id[FM25_ID_LEN];
+ const struct of_device_id *match;
+ int is_fram = 0;
+
+ match = of_match_device(of_match_ptr(at25_of_match), &spi->dev);
+ if (match)
+ is_fram = (int)(uintptr_t)match->data;

/* Chip description */
if (!spi->dev.platform_data) {
- err = at25_fw_to_chip(&spi->dev, &chip);
- if (err)
- return err;
+ if (!is_fram) {
+ err = at25_fw_to_chip(&spi->dev, &chip);
+ if (err)
+ return err;
+ }
} else
chip = *(struct spi_eeprom *)spi->dev.platform_data;

- /* For now we only support 8/16/24 bit addressing */
- if (chip.flags & EE_ADDR1)
- addrlen = 1;
- else if (chip.flags & EE_ADDR2)
- addrlen = 2;
- else if (chip.flags & EE_ADDR3)
- addrlen = 3;
- else {
- dev_dbg(&spi->dev, "unsupported address type\n");
- return -EINVAL;
- }
-
/* Ping the chip ... the status register is pretty portable,
* unlike probing manufacturer IDs. We do expect that system
* firmware didn't write it in the past few milliseconds!
@@ -349,9 +395,49 @@ static int at25_probe(struct spi_device *spi)
at25->chip = chip;
at25->spi = spi;
spi_set_drvdata(spi, at25);
- at25->addrlen = addrlen;

- at25->nvmem_config.type = NVMEM_TYPE_EEPROM;
+ if (is_fram) {
+ /* Get ID of chip */
+ fm25_aux_read(at25, id, FM25_RDID, FM25_ID_LEN);
+ if (id[6] != 0xc2) {
+ dev_err(&spi->dev,
+ "Error: no Cypress FRAM (id %02x)\n", id[6]);
+ return -ENODEV;
+ }
+ /* set size found in ID */
+ if (id[7] < 0x21 || id[7] > 0x26) {
+ dev_err(&spi->dev, "Error: unsupported size (id %02x)\n", id[7]);
+ return -ENODEV;
+ }
+ chip.byte_len = int_pow(2, id[7] - 0x21 + 4) * 1024;
+
+ if (at25->chip.byte_len > 64 * 1024)
+ at25->chip.flags |= EE_ADDR3;
+ else
+ at25->chip.flags |= EE_ADDR2;
+
+ if (id[8])
+ at25->has_sernum = 1;
+ else
+ at25->has_sernum = 0;
+
+ at25->chip.page_size = PAGE_SIZE;
+ strncpy(at25->chip.name, "fm25", sizeof(at25->chip.name));
+ }
+
+ /* For now we only support 8/16/24 bit addressing */
+ if (at25->chip.flags & EE_ADDR1)
+ at25->addrlen = 1;
+ else if (at25->chip.flags & EE_ADDR2)
+ at25->addrlen = 2;
+ else if (at25->chip.flags & EE_ADDR3)
+ at25->addrlen = 3;
+ else {
+ dev_dbg(&spi->dev, "unsupported address type\n");
+ return -EINVAL;
+ }
+
+ at25->nvmem_config.type = is_fram ? NVMEM_TYPE_FRAM : NVMEM_TYPE_EEPROM;
at25->nvmem_config.name = dev_name(&spi->dev);
at25->nvmem_config.dev = &spi->dev;
at25->nvmem_config.read_only = chip.flags & EE_READONLY;
@@ -370,23 +456,17 @@ static int at25_probe(struct spi_device *spi)
if (IS_ERR(at25->nvmem))
return PTR_ERR(at25->nvmem);

- dev_info(&spi->dev, "%d %s %s eeprom%s, pagesize %u\n",
- (chip.byte_len < 1024) ? chip.byte_len : (chip.byte_len / 1024),
- (chip.byte_len < 1024) ? "Byte" : "KByte",
- at25->chip.name,
- (chip.flags & EE_READONLY) ? " (readonly)" : "",
- at25->chip.page_size);
+ dev_info(&spi->dev, "%d %s %s %s%s, pagesize %u\n",
+ (chip.byte_len < 1024) ? chip.byte_len : (chip.byte_len / 1024),
+ (chip.byte_len < 1024) ? "Byte" : "KByte",
+ at25->chip.name, is_fram ? "fram" : "eeprom",
+ (chip.flags & EE_READONLY) ? " (readonly)" : "",
+ at25->chip.page_size);
return 0;
}

/*-------------------------------------------------------------------------*/

-static const struct of_device_id at25_of_match[] = {
- { .compatible = "atmel,at25", },
- { }
-};
-MODULE_DEVICE_TABLE(of, at25_of_match);
-
static struct spi_driver at25_driver = {
.driver = {
.name = "at25",
--
2.25.1

2021-06-07 12:30:30

by Jiri Prchal

[permalink] [raw]
Subject: [PATCH v7 1/5] nvmem: eeprom: at25: prepare basics for FRAM support

Added enum and string for FRAM to expose it as "fram".

Signed-off-by: Jiri Prchal <[email protected]>
---
v2: no change here
v3: resend and added more recipients
v4: resend
v5: no change here
v6: changed commit subject
v7: no change here
---
drivers/nvmem/core.c | 4 ++++
include/linux/nvmem-provider.h | 1 +
2 files changed, 5 insertions(+)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 177f5bf27c6d..01ef9a934b0a 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -180,6 +180,7 @@ static const char * const nvmem_type_str[] = {
[NVMEM_TYPE_EEPROM] = "EEPROM",
[NVMEM_TYPE_OTP] = "OTP",
[NVMEM_TYPE_BATTERY_BACKED] = "Battery backed",
+ [NVMEM_TYPE_FRAM] = "FRAM",
};

#ifdef CONFIG_DEBUG_LOCK_ALLOC
@@ -359,6 +360,9 @@ static int nvmem_sysfs_setup_compat(struct nvmem_device *nvmem,
if (!config->base_dev)
return -EINVAL;

+ if (config->type == NVMEM_TYPE_FRAM)
+ bin_attr_nvmem_eeprom_compat.attr.name = "fram";
+
nvmem->eeprom = bin_attr_nvmem_eeprom_compat;
nvmem->eeprom.attr.mode = nvmem_bin_attr_get_umode(nvmem);
nvmem->eeprom.size = nvmem->size;
diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h
index e162b757b6d5..890003565761 100644
--- a/include/linux/nvmem-provider.h
+++ b/include/linux/nvmem-provider.h
@@ -25,6 +25,7 @@ enum nvmem_type {
NVMEM_TYPE_EEPROM,
NVMEM_TYPE_OTP,
NVMEM_TYPE_BATTERY_BACKED,
+ NVMEM_TYPE_FRAM,
};

#define NVMEM_DEVID_NONE (-1)
--
2.25.1

2021-06-07 12:31:30

by Jiri Prchal

[permalink] [raw]
Subject: [PATCH v7 5/5] nvmem: eeprom: add documentation of sysfs sernum file

Added sysfs sernum file documentation.

Signed-off-by: Jiri Prchal <[email protected]>
---
v5: new
v6: no change here
v7: no change here
---
Documentation/ABI/testing/sysfs-class-spi-eeprom | 6 ++++++
1 file changed, 6 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-spi-eeprom

diff --git a/Documentation/ABI/testing/sysfs-class-spi-eeprom b/Documentation/ABI/testing/sysfs-class-spi-eeprom
new file mode 100644
index 000000000000..4f063a97b735
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-spi-eeprom
@@ -0,0 +1,6 @@
+What: /sys/class/spi_master/spi<bus>/spi<bus>.<dev>/sernum
+Date: May 2021
+KernelVersion: 5.12.1
+Contact: Jiri Prchal <[email protected]>
+Description:
+ Exports serial number of Cypress FRAM (FM25VN). 8 bytes as is in chip in hex string.
--
2.25.1

2021-06-07 12:37:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH v7 1/5] nvmem: eeprom: at25: prepare basics for FRAM support

On Mon, Jun 07, 2021 at 02:26:36PM +0200, Jiri Prchal wrote:
> Added enum and string for FRAM to expose it as "fram".
>
> Signed-off-by: Jiri Prchal <[email protected]>
> ---
> v2: no change here
> v3: resend and added more recipients
> v4: resend
> v5: no change here
> v6: changed commit subject
> v7: no change here
> ---
> drivers/nvmem/core.c | 4 ++++
> include/linux/nvmem-provider.h | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index 177f5bf27c6d..01ef9a934b0a 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -180,6 +180,7 @@ static const char * const nvmem_type_str[] = {
> [NVMEM_TYPE_EEPROM] = "EEPROM",
> [NVMEM_TYPE_OTP] = "OTP",
> [NVMEM_TYPE_BATTERY_BACKED] = "Battery backed",
> + [NVMEM_TYPE_FRAM] = "FRAM",
> };
>
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
> @@ -359,6 +360,9 @@ static int nvmem_sysfs_setup_compat(struct nvmem_device *nvmem,
> if (!config->base_dev)
> return -EINVAL;
>
> + if (config->type == NVMEM_TYPE_FRAM)
> + bin_attr_nvmem_eeprom_compat.attr.name = "fram";
> +

As this is a new sysfs file, where is the documentation for it?

thanks,

greg k-h

2021-06-07 12:38:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH v7 4/5] nvmem: eeprom: at25: export FRAM serial num

On Mon, Jun 07, 2021 at 02:26:39PM +0200, Jiri Prchal wrote:
> This exports serial number of FRAM in sysfs file named "sernum".
> Formatted in hex, each byte separated by space.
> Example:
> $ cat /sys/class/spi_master/spi0/spi0.0/sernum
> 0000a43644f2ae6c
>
> Signed-off-by: Jiri Prchal <[email protected]>
> ---
> v2: no change here
> v3: resend and added more recipients
> v4: resend
> v5: reworked up on Greg comments: no spaces in string, sysfs done correctly
> v6: no change here
> v7: moved FM25_SN_LEN, static array, used sysfs_emit, DEVICE_ATTR_RO
> ---
> drivers/misc/eeprom/at25.c | 22 +++++++++++++++++++++-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/eeprom/at25.c b/drivers/misc/eeprom/at25.c
> index 3b7ffef1f0d7..a28dfd7e1798 100644
> --- a/drivers/misc/eeprom/at25.c
> +++ b/drivers/misc/eeprom/at25.c
> @@ -31,6 +31,7 @@
> * AT25M02, AT25128B
> */
>
> +#define FM25_SN_LEN 8 /* serial number length */
> struct at25_data {
> struct spi_device *spi;
> struct mutex lock;
> @@ -39,6 +40,7 @@ struct at25_data {
> struct nvmem_config nvmem_config;
> struct nvmem_device *nvmem;
> int has_sernum;
> + u8 sernum[FM25_SN_LEN];
> };
>
> #define AT25_WREN 0x06 /* latch the write enable */
> @@ -172,6 +174,21 @@ static int fm25_aux_read(struct at25_data *at25, char *buf, uint8_t command,
> return status;
> }
>
> +static ssize_t sernum_show(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + struct at25_data *at25;
> +
> + at25 = dev_get_drvdata(dev);
> + return sysfs_emit(buf, "%016llx\n", *(unsigned long long *)at25->sernum);

That's a horrid hack, why not use the %*phN modifier?

Look in the printk-formats.rst file for help.

thanks,

greg k-h

2021-06-07 12:38:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH v7 5/5] nvmem: eeprom: add documentation of sysfs sernum file

On Mon, Jun 07, 2021 at 02:26:40PM +0200, Jiri Prchal wrote:
> Added sysfs sernum file documentation.
>
> Signed-off-by: Jiri Prchal <[email protected]>
> ---
> v5: new
> v6: no change here
> v7: no change here
> ---
> Documentation/ABI/testing/sysfs-class-spi-eeprom | 6 ++++++
> 1 file changed, 6 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-class-spi-eeprom
>
> diff --git a/Documentation/ABI/testing/sysfs-class-spi-eeprom b/Documentation/ABI/testing/sysfs-class-spi-eeprom
> new file mode 100644
> index 000000000000..4f063a97b735
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-spi-eeprom
> @@ -0,0 +1,6 @@
> +What: /sys/class/spi_master/spi<bus>/spi<bus>.<dev>/sernum
> +Date: May 2021
> +KernelVersion: 5.12.1

Odd kernel version number, I do not think it is correct :)

thanks,

greg k-h

2021-06-07 14:50:00

by Jiri Prchal

[permalink] [raw]
Subject: Re: [PATCH v7 4/5] nvmem: eeprom: at25: export FRAM serial num



On 07. 06. 21 14:36, Greg Kroah-Hartman wrote:
> On Mon, Jun 07, 2021 at 02:26:39PM +0200, Jiri Prchal wrote:
>> + return sysfs_emit(buf, "%016llx\n", *(unsigned long long *)at25->sernum);
>
> That's a horrid hack, why not use the %*phN modifier?

Prints as little endian, is that OK?

Jiri

2021-06-08 09:07:22

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH v7 4/5] nvmem: eeprom: at25: export FRAM serial num

On Mon, Jun 07, 2021 at 04:47:44PM +0200, Jiří Prchal wrote:
>
>
> On 07. 06. 21 14:36, Greg Kroah-Hartman wrote:
> > On Mon, Jun 07, 2021 at 02:26:39PM +0200, Jiri Prchal wrote:
> > > + return sysfs_emit(buf, "%016llx\n", *(unsigned long long *)at25->sernum);
> >
> > That's a horrid hack, why not use the %*phN modifier?
>
> Prints as little endian, is that OK?

You tell me! What tool is going to be reading this? What do they
expect it to look like?

And it's a byte array, why would there be endian issues?

thanks,

greg k-h

2021-06-08 09:47:58

by Jiri Prchal

[permalink] [raw]
Subject: Re: [PATCH v7 4/5] nvmem: eeprom: at25: export FRAM serial num



On 08. 06. 21 11:03, Greg Kroah-Hartman wrote:
> On Mon, Jun 07, 2021 at 04:47:44PM +0200, Jiří Prchal wrote:
>>
>>
>> On 07. 06. 21 14:36, Greg Kroah-Hartman wrote:
>>> On Mon, Jun 07, 2021 at 02:26:39PM +0200, Jiri Prchal wrote:
>>>> + return sysfs_emit(buf, "%016llx\n", *(unsigned long long *)at25->sernum);
>>>
>>> That's a horrid hack, why not use the %*phN modifier?
>>
>> Prints as little endian, is that OK?
>
> You tell me! What tool is going to be reading this? What do they
> expect it to look like?

sh, php in my usecase as unique id.
So endianess does not matter to me too much. The question is what is
usual (like mac address, uuid...?).

> And it's a byte array, why would there be endian issues?

Now is printed as one big number. Not real issue. Just human
readability? Should I turn back it to space separated bytes?

J

2021-06-08 09:56:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH v7 4/5] nvmem: eeprom: at25: export FRAM serial num

On Tue, Jun 08, 2021 at 11:45:56AM +0200, Jiří Prchal wrote:
>
>
> On 08. 06. 21 11:03, Greg Kroah-Hartman wrote:
> > On Mon, Jun 07, 2021 at 04:47:44PM +0200, Jiří Prchal wrote:
> > >
> > >
> > > On 07. 06. 21 14:36, Greg Kroah-Hartman wrote:
> > > > On Mon, Jun 07, 2021 at 02:26:39PM +0200, Jiri Prchal wrote:
> > > > > + return sysfs_emit(buf, "%016llx\n", *(unsigned long long *)at25->sernum);
> > > >
> > > > That's a horrid hack, why not use the %*phN modifier?
> > >
> > > Prints as little endian, is that OK?
> >
> > You tell me! What tool is going to be reading this? What do they
> > expect it to look like?
>
> sh, php in my usecase as unique id.

I am sorry, I do not understand.

> So endianess does not matter to me too much. The question is what is usual
> (like mac address, uuid...?).

What does the device export? Why not just export it as:
0123456789ABCDEF
if it is 8 bytes long?

> > And it's a byte array, why would there be endian issues?
>
> Now is printed as one big number. Not real issue. Just human readability?
> Should I turn back it to space separated bytes?

It's up to you, what do you want to do with it and what does a tool want
it to look like?

thanks,

greg k-h

2021-06-08 10:28:00

by Jiri Prchal

[permalink] [raw]
Subject: Re: [PATCH v7 4/5] nvmem: eeprom: at25: export FRAM serial num



On 08. 06. 21 11:53, Greg Kroah-Hartman wrote:
>>>> Prints as little endian, is that OK?
>>>
>>> You tell me! What tool is going to be reading this? What do they
>>> expect it to look like?
>>
>> sh, php in my usecase as unique id.
>
> I am sorry, I do not understand.

In my use case: shell and php.

>
>> So endianess does not matter to me too much. The question is what is usual
>> (like mac address, uuid...?).
>
> What does the device export? Why not just export it as:
> 0123456789ABCDEF
> if it is 8 bytes long?

Yes, device contains 0123456789ABCDEF.

>
>>> And it's a byte array, why would there be endian issues?
>>
>> Now is printed as one big number. Not real issue. Just human readability?
>> Should I turn back it to space separated bytes?
>
> It's up to you, what do you want to do with it and what does a tool want
> it to look like?

Right now I export it as bytes separated by space. But no problem to
change it.
Just asking: for generic users what would be better or is there "best
practice"?

>
> thanks,
>
> greg k-h
>

2021-06-10 07:53:10

by Jiri Prchal

[permalink] [raw]
Subject: Re: [PATCH v7 4/5] nvmem: eeprom: at25: export FRAM serial num



On 08. 06. 21 12:07, Jiří Prchal wrote:
>
>
> On 08. 06. 21 11:53, Greg Kroah-Hartman wrote:
>> It's up to you, what do you want to do with it and what does a tool want
>> it to look like?
>
> Right now I export it as bytes separated by space. But no problem to
> change it.
> Just asking: for generic users what would be better or is there "best
> practice"?

Hi Greg and others,
if nobody bothers I'll make it as space separated bytes, MSB first.

Jiri