From: Christoph Niedermaier <cniedermaier@dh-electronics.com>
To: Marek Vasut <marex@denx.de>,
"u-boot@lists.denx.de" <u-boot@lists.denx.de>
Cc: NXP i.MX U-Boot Team <uboot-imx@nxp.com>,
Fabio Estevam <festevam@gmail.com>,
Stefano Babic <sbabic@denx.de>, Tom Rini <trini@konsulko.com>,
u-boot <u-boot@dh-electronics.com>
Subject: RE: [PATCH 2/2] arm64: imx8mp: Read item and serial number from EEPROM ID page on DH i.MX8MP DHCOM
Date: Tue, 22 Oct 2024 09:31:08 +0000 [thread overview]
Message-ID: <d06620ee891f4e419bfeb8fe657ba729@dh-electronics.com> (raw)
In-Reply-To: <a0f70ee2-6d71-4f66-b22e-994df2b28504@denx.de>
From: Marek Vasut <marex@denx.de>
Sent: Tuesday, October 22, 2024 1:01 AM
> On 10/21/24 5:38 PM, Christoph Niedermaier wrote:
>
> [...]
>
>>> If yes, then there is no need for any static variable:
>>>
>>> board_init() {
>>> u8 eeprom[32];
>>> dh_read_eeprom_wlp(eeprom); // read the eeprom once
>>> dh_setup_mac_address(eeprom); // extract MAC from EEPROM
>>> dh_add_item_number_and_serial_to_env(eeprom); // extract SN from EEPROM
>>> // once this function exits, the eeprom variable on stack is discarded
>>> // which is OK, since it won't be used anymore anyway
>>> }
>>
>> The idea is that function dh_add_item_number_and_serial_to_env() encapsulates
>> the reading.
>
> The function which interacts with the EEPROM on start up, once, can have
> this name, sure.
Sorry, I mean the function dh_get_value_from_eeprom_id_page() here.
>> I don't want to have to worry about the structure and number of
>> bytes of the EEPROM ID page and want to be independent of it. It is planned to
>> extend the structure and increase the number of bytes for the STM32MP2. The
>> changes to the size will then depend on the version of the data in the header
>> within the structure.
>
> It is OK to allocate 32 or 64 bytes on stack, since that chunk of memory
> is free'd on return from the function. The lifespan of that allocated
> memory is exactly as long as it should be, and it does not waste U-Boot
> memory unnecessarily.
>
> So far, all known EEPROMs have WLP size of 32 or 64 Byes.
>
>> However, these changes should then only have to be made
>> within the function dh_add_item_number_and_serial_to_env() for reading the
>> EEPROM ID page. I accept the static variable in order to better isolate the
>> function.
Sorry, here I mean also the function dh_get_value_from_eeprom_id_page().
> This can very well be:
>
> dh_add_item_number_and_serial_to_env() {
> u8 eeprom[32];
> dh_read_eeprom_wlp(eeprom); // read the eeprom once
> dh_setup_mac_address(eeprom); // extract MAC from EEPROM
> dh_add_item_number_and_serial_to_env(eeprom); // extract SN from EEPROM
> // once this function exits, the eeprom variable on stack is discarded
> // which is OK, since it won't be used anymore anyway
> }
>
> board_init() {
> ..
> dh_add_item_number_and_serial_to_env();
> ...
> }
>
>> Since the memory is freed up again when the operating system boots,
>> this consumption of 32 bytes in U-Boot is not a problem, because it is only
>> temporary.
> This is not good, please do not waste memory in U-Boot if it can be
> easily avoided by automatically allocating it on stack and freeing it
> when not needed.
>
> [...]
I don't want to allocate the memory in the function board_init(). I want to handle
size and caching in the function dh_get_value_from_eeprom_id_page(). So I don't
want to deal with size and structure in the function board_init(). For me, the use
of a static variable is OK, but you don't like it. Do you know how I can do this
without assigning a static variable, but not allocate the memory somewhere in a
caller function?
Regards
Christoph
next prev parent reply other threads:[~2024-10-22 9:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-10 13:23 [PATCH 1/2] arm64: imx8mp: Read MAC address from M24C32-D write-lockable page on DH i.MX8MP DHCOM if available Christoph Niedermaier
2024-10-10 13:23 ` [PATCH 2/2] arm64: imx8mp: Read item and serial number from EEPROM ID page on DH i.MX8MP DHCOM Christoph Niedermaier
2024-10-12 20:55 ` Marek Vasut
2024-10-16 12:31 ` Christoph Niedermaier
2024-10-17 0:22 ` Marek Vasut
2024-10-17 11:55 ` Christoph Niedermaier
2024-10-17 18:35 ` Marek Vasut
2024-10-21 15:38 ` Christoph Niedermaier
2024-10-21 23:00 ` Marek Vasut
2024-10-22 9:31 ` Christoph Niedermaier [this message]
2024-10-22 11:57 ` Marek Vasut
2024-10-23 12:18 ` Christoph Niedermaier
2024-10-23 12:41 ` Marek Vasut
2024-10-23 13:20 ` Christoph Niedermaier
2024-10-23 14:04 ` Marek Vasut
2024-10-25 15:36 ` Christoph Niedermaier
2024-10-12 20:42 ` [PATCH 1/2] arm64: imx8mp: Read MAC address from M24C32-D write-lockable page on DH i.MX8MP DHCOM if available Marek Vasut
2024-10-16 11:57 ` Christoph Niedermaier
2024-10-16 12:15 ` Marek Vasut
2024-10-17 11:09 ` Christoph Niedermaier
2024-10-17 14:01 ` Marek Vasut
2024-10-21 15:08 ` Christoph Niedermaier
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=d06620ee891f4e419bfeb8fe657ba729@dh-electronics.com \
--to=cniedermaier@dh-electronics.com \
--cc=festevam@gmail.com \
--cc=marex@denx.de \
--cc=sbabic@denx.de \
--cc=trini@konsulko.com \
--cc=u-boot@dh-electronics.com \
--cc=u-boot@lists.denx.de \
--cc=uboot-imx@nxp.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