RE: [PATCH 2/2] arm64: imx8mp: Read item and serial number from EEPROM ID page on DH i.MX8MP DHCOM

[Christoph Niedermaier <cniedermaier@dh-electronics.com>]

From: Marek Vasut <marex@denx.de>
Sent: Wednesday, October 23, 2024 2:41 PM
> On 10/23/24 2:18 PM, Christoph Niedermaier wrote:
> 
> [...]
> 
>>> You do not, the following automatically reserves space on stack when
>>> called and frees it up upon function return:
>>>
>>> function foo() {
>>>     u8 array[12];
>>>     ...
>>>     stuff(array);
>>>     ...
>>> }
>>
>> Sorry, I expressed myself incorrectly here. Of course I meant that
>> I don't want to reserve memory on the stack for the EEPROM ID page
>> in the board_init() function.
> 
> Why ?

It's about structuring the software. I want to isolate the function which
is responsible for evaluate the EEPROM from the caller function. I wanted
to avoid entangling the two. This means that I, as the caller of the function,
do not have to worry about the internal structure of the EEPROM ID page.

>>>> 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?
>>> Even the static variable space is allocated somewhere, either in .bss or
>>> .data section, except with static variable(s) the memory persists
>>> throughout the lifetime of U-Boot because their content has to be
>>> retained even when the function using their content returns.
>>>
>>> With variable(s) allocated on stack (which is majority of variable), the
>>> memory allocation happens on entry to the function and the memory is
>>> automatically freed on exit from the function.
>>>
>>> It is perfectly fine to call some wrapper superfunction from
>>> board_init() which holds the array on stack and calls all the EEPROM
>>> parser/handler functions:
>>>
>>> eeprom_superwrapper() {
>>>     u8 eeprom[64];
>>>     ...
>>>     eeprom_do_stuff1(eeprom);
>>>     eeprom_do_stuff2(eeprom);
>>>     ...
>>> }
>>>
>>> board_init() {
>>>     ...
>>>     eeprom_superwrapper();
>>>     ...
>>> }
>>
>> That's not what I'm looking for. Do you have another solution?
> No. I do not understand what is the problem with allocating 64 Bytes on
> stack ?

There is no problem with the reservation of the EEPROM buffer on the
stack. I wanted to isolate the evaluation function from the caller
function, so that I have no dependencies on the caller. Since there
seems to be no better solution, I will add the variable to the
board_init() function in V2.


Regards
Christoph