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 4:05 PM
> On 10/23/24 3:20 PM, Christoph Niedermaier wrote:
>> 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.
> 
> You are only passing in a block of unstructured memory allocated on
> stack, u8 block[64].
> 
>>>>>> 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.
> There seem to be multiple functions using the same data, so you have to
> pass pointer to those data around.

I will make a V2 with this approach, but unfortunately I can't work on
it next week. So the week after I will send V2.

Regards
Christoph