public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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

  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