From: "Jiří Prchal" <jiri.prchal@aksignal.cz>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Rob Herring <robh+dt@kernel.org>,
Christian Eggers <ceggers@arri.de>, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v7 4/5] nvmem: eeprom: at25: export FRAM serial num
Date: Tue, 8 Jun 2021 12:07:52 +0200 [thread overview]
Message-ID: <e32ad2d9-f2b3-f5de-54e5-fe43cd5403a9@aksignal.cz> (raw)
In-Reply-To: <YL8+NOdz+ue3MTGg@kroah.com>
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
>
next prev parent reply other threads:[~2021-06-08 10:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-07 12:26 [PATCH v7 0/5] add support for FRAM Jiri Prchal
2021-06-07 12:26 ` [PATCH v7 1/5] nvmem: eeprom: at25: prepare basics for FRAM support Jiri Prchal
2021-06-07 12:35 ` Greg Kroah-Hartman
2021-06-07 12:26 ` [PATCH v7 2/5] nvmem: eeprom: at25: add support for FRAM Jiri Prchal
2021-06-07 12:26 ` [PATCH v7 3/5] nvmem: eeprom: add documentation " Jiri Prchal
2021-06-07 13:09 ` Enrico Weigelt, metux IT consult
2021-06-07 12:26 ` [PATCH v7 4/5] nvmem: eeprom: at25: export FRAM serial num Jiri Prchal
2021-06-07 12:36 ` Greg Kroah-Hartman
2021-06-07 14:47 ` Jiří Prchal
2021-06-08 9:03 ` Greg Kroah-Hartman
2021-06-08 9:45 ` Jiří Prchal
2021-06-08 9:53 ` Greg Kroah-Hartman
2021-06-08 10:07 ` Jiří Prchal [this message]
2021-06-10 7:51 ` Jiří Prchal
2021-06-07 12:26 ` [PATCH v7 5/5] nvmem: eeprom: add documentation of sysfs sernum file Jiri Prchal
2021-06-07 12:37 ` Greg Kroah-Hartman
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=e32ad2d9-f2b3-f5de-54e5-fe43cd5403a9@aksignal.cz \
--to=jiri.prchal@aksignal.cz \
--cc=arnd@arndb.de \
--cc=ceggers@arri.de \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.