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 V3 3/3] board: dhelectronics: Sync env variable dh_som_serial_number with SN
Date: Wed, 27 Nov 2024 16:11:55 +0000 [thread overview]
Message-ID: <bc2b78f451ee416fb3b38e1a788df01d@dh-electronics.com> (raw)
In-Reply-To: <751efcf2-b51f-43b8-affb-46fdbd59002a@denx.de>
From: Marek Vasut <marex@denx.de>
Sent: Sunday, November 24, 2024 11:11 PM
> On 11/24/24 10:10 PM, Marek Vasut wrote:
>> On 11/21/24 6:21 PM, Christoph Niedermaier wrote:
>>> The env variable "SN" is used to store the serial number on DH
>>> electronics
>>> SoMs. New SoMs will use the variable "dh_som_serial_number". To ensure
>>> compatibility, these env variables are synchronized. This is achieved
>>> using callback functions. To avoid recursive calls, these are locked
>>> against each other.
>>
>> What kind of recursive calls?
>>
>> It would be good to expand the commit message and elaborate on the
>> recursive calls problem .
>>
>>> diff --git a/board/dhelectronics/common/dh_common.c b/board/
>>> dhelectronics/common/dh_common.c
>>> index a7b0472a09..2e3e5c483b 100644
>>> --- a/board/dhelectronics/common/dh_common.c
>>> +++ b/board/dhelectronics/common/dh_common.c
>>> @@ -45,6 +45,32 @@ struct eeprom_id_page {
>>> #define DH_EEPROM_ID_PAGE_V1_0_DATA_LEN (sizeof(struct
>>> eeprom_id_page) - \
>>> offsetof(struct eeprom_id_page, mac0))
>>> +static bool in_dh_som_serial_number;
>>> +static bool in_SN;
>>> +
>>> +static int on_dh_som_serial_number(const char *name, const char
>>> *value, enum env_op op,
>>> + int flags)
>>> +{
>>> + in_dh_som_serial_number = true;
>>> + if (!in_SN)
>>> + env_set("SN", value);
>>> + in_dh_som_serial_number = false;
>>> + return 0;
>>> +}
> Maybe a more generic solution is:
>
> diff --git a/lib/hashtable.c b/lib/hashtable.c
> index e8a59e2dcac..75c263b5053 100644
> --- a/lib/hashtable.c
> +++ b/lib/hashtable.c
> @@ -221,11 +221,32 @@ static int
> do_callback(const struct env_entry *e, const char *name, const char
> *value,
> enum env_op op, int flags)
> {
> + int ret = 0;
> +
> #ifndef CONFIG_XPL_BUILD
> - if (e->callback)
> - return e->callback(name, value, op, flags);
> + static bool in_callback;
> +
> + if (!e->callback || in_callback)
> + return 0;
> +
> + /*
> + * In case there are two variables which each implement env callback
> + * that performs env_set() on the other variable, the callbacks will
> + * call each other recursively until the stack runs out. Prevent such
> + * a recursion from happening.
> + *
> + * Example which triggers this behavior:
> + * static int on_foo(...) { env_set("bar", 0); ... }
> + * static int on_bar(...) { env_set("foo", 0); ... }
> + * U_BOOT_ENV_CALLBACK(foo, on_foo);
> + * U_BOOT_ENV_CALLBACK(bar, on_bar);
> + */
> + in_callback = true;
> + ret = e->callback(name, value, op, flags);
> + in_callback = false;
> #endif
> - return 0;
> +
> + return ret;
> }
>
> /*
Looks good, I will integrate it in V4.
Regards
Christoph
next prev parent reply other threads:[~2024-11-27 16:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-21 17:21 [PATCH V3 1/3] arm64: dts: imx8mp: Add aliases for the access to the EEMPROM ID page node Christoph Niedermaier
2024-11-21 17:21 ` [PATCH V3 2/3] arm64: imx8mp: Read values from M24C32-D write-lockable page on DHCOM i.MX8MP Christoph Niedermaier
2024-11-24 21:01 ` Marek Vasut
2024-11-26 16:18 ` Christoph Niedermaier
2024-11-21 17:21 ` [PATCH V3 3/3] board: dhelectronics: Sync env variable dh_som_serial_number with SN Christoph Niedermaier
2024-11-24 21:10 ` Marek Vasut
2024-11-24 22:11 ` Marek Vasut
2024-11-27 16:11 ` Christoph Niedermaier [this message]
2024-11-21 17:37 ` [PATCH V3 1/3] arm64: dts: imx8mp: Add aliases for the access to the EEMPROM ID page node Marek Vasut
2024-11-22 21:57 ` 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=bc2b78f451ee416fb3b38e1a788df01d@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