From: Mattijs Korpershoek <mkorpershoek@kernel.org>
To: Hrushikesh Salunke <h-salunke@ti.com>,
Mattijs Korpershoek <mkorpershoek@kernel.org>,
trini@konsulko.com, lukma@denx.de, peng.fan@nxp.com,
marek.vasut+renesas@mailbox.org, anshuld@ti.com,
andre.przywara@arm.com, xypron.glpk@gmx.de, ye.li@nxp.com,
sjg@chromium.org, dario.binacchi@amarulasolutions.com,
a-dutta@ti.com, dinesh.maniyam@altera.com
Cc: u-boot@lists.denx.de, s-vadapalli@ti.com, danishanwar@ti.com
Subject: Re: [PATCH v4] spl: Add support for Device Firmware Upgrade (DFU) over PCIe
Date: Thu, 06 Nov 2025 10:11:24 +0100 [thread overview]
Message-ID: <87h5v7r0eb.fsf@kernel.org> (raw)
In-Reply-To: <ded6f86b-4003-4832-8d49-4a7285dddbb4@ti.com>
Hi Hrushikesh,
On Mon, Nov 03, 2025 at 11:10, Hrushikesh Salunke <h-salunke@ti.com> wrote:
> On 31/10/25 20:22, Mattijs Korpershoek wrote:
>> Hi Hrushikesh,
>>
>> Thank you for the patch.
>>
>> v4 is in good shape already. I have a couple of small remarks below.
>> Please have a look.
>>
>> On Thu, Oct 23, 2025 at 13:39, Hrushikesh Salunke <h-salunke@ti.com> wrote:
>>
>>> Introduces support for Device Firmware Upgrade (DFU) over PCIe in
>>> U-Boot. Traditionally, the DFU protocol is used over USB, where a
>
> [...]
>
>>>
>>> +#ifdef CONFIG_SPL_PCI_DFU
>>> + if (spl_boot_device() == BOOT_DEVICE_PCIE)
>>> + return dfu_over_pcie();
>>> +#endif
>>> +
>>> /* set default environment */
>>> env_set_default(NULL, 0);
>>> str_env = env_get(dfu_alt_info);
>>> diff --git a/common/spl/spl_ram.c b/common/spl/spl_ram.c
>>> index 71b7a8374bb..0c501cf02f2 100644
>>> --- a/common/spl/spl_ram.c
>>> +++ b/common/spl/spl_ram.c
>>> @@ -27,6 +27,11 @@ static ulong spl_ram_load_read(struct spl_load_info *load, ulong sector,
>>> if (IS_ENABLED(CONFIG_SPL_LOAD_FIT)) {
>>> addr = IF_ENABLED_INT(CONFIG_SPL_LOAD_FIT,
>>> CONFIG_SPL_LOAD_FIT_ADDRESS);
>>> +
>>> +#ifdef CONFIG_SPL_PCI_DFU
>>> + if (spl_boot_device() == BOOT_DEVICE_PCIE)
>>> + addr = CONFIG_SPL_PCI_DFU_SPL_LOAD_FIT_ADDRESS;
>>> +#endif
>>
>> Can't we rewrite this using IF_ENABLED_INT() similarly to what has been
>> done for CONFIG_SPL_LOAD_FIT_ADDRESS ?
>>
>> This should allow us to get rid of the #ifdef CONFIG_SPL_PCI_DFU part.
>>
>>> }
>>> addr += sector;
>>> if (CONFIG_IS_ENABLED(IMAGE_PRE_LOAD))
>>> @@ -47,6 +52,11 @@ static int spl_ram_load_image(struct spl_image_info *spl_image,
>>> if (IS_ENABLED(CONFIG_SPL_LOAD_FIT)) {
>>> addr = IF_ENABLED_INT(CONFIG_SPL_LOAD_FIT,
>>> CONFIG_SPL_LOAD_FIT_ADDRESS);
>>> +
>>> +#ifdef CONFIG_SPL_PCI_DFU
>>> + if (spl_boot_device() == BOOT_DEVICE_PCIE)
>>> + addr = CONFIG_SPL_PCI_DFU_SPL_LOAD_FIT_ADDRESS;
>>> +#endif
>>
>> Same here
>>
>>> }
>>>
>>> if (CONFIG_IS_ENABLED(IMAGE_PRE_LOAD)) {
>>> @@ -64,6 +74,11 @@ static int spl_ram_load_image(struct spl_image_info *spl_image,
>>> spl_dfu_cmd(0, "dfu_alt_info_ram", "ram", "0");
>>> #endif
>>>
>>> +#if CONFIG_IS_ENABLED(PCI_DFU)
>>> + if (bootdev->boot_device == BOOT_DEVICE_PCIE)
>>> + spl_dfu_cmd(0, "dfu_alt_info_ram", "ram", "0");
>>> +#endif
>>> +
>>
>> Same here. Please rewrite using if (IS_ENABLED(CONFIG_SPL_PCI_DFU)).
>> This way we are consistent with the rest of the file.
>>
>
>
> Thank you for the feedback. However, using IS_ENABLED() instead of
> #ifdef in these locations causes compilation errors on platforms where
> BOOT_DEVICE_PCIE is not defined. The BOOT_DEVICE_PCIE macro is only
> defined in platform-specific headers, and is not available universally
> across all architectures. With IS_ENABLED(CONFIG_SPL_PCI_DFU), the code
> inside the conditional is still visible to the compiler even when the
> config is disabled. This means the compiler will try to evaluate
> BOOT_DEVICE_PCIE on platforms where it doesn't exist, resulting in a
> compilation error like:
>
> error: 'BOOT_DEVICE_PCIE' undeclared
I see. Sorry I missed that.
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
I'll pick this up shortly to try to make it for v2026.01
>
> The #ifdef CONFIG_SPL_PCI_DFU approach ensures that the code referencing
> BOOT_DEVICE_PCIE is completely removed during preprocessing on platforms
> that don't support PCIe DFU, preventing the compilation error. This is
> similar to how other boot device checks are handled in U-Boot when the
> boot device macro may not be universally defined across all platforms.
>
> Regards,
> Hrushikesh.
>
>
>
>>> if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
>>> image_get_magic(header) == FDT_MAGIC) {
>>> struct spl_load_info load;
>>> @@ -102,3 +117,6 @@ SPL_LOAD_IMAGE_METHOD("RAM", 0, BOOT_DEVICE_RAM, spl_ram_load_image);
>>> #if CONFIG_IS_ENABLED(DFU)
>>> SPL_LOAD_IMAGE_METHOD("DFU", 0, BOOT_DEVICE_DFU, spl_ram_load_image);
>>> #endif
>>> +#if CONFIG_IS_ENABLED(PCI_DFU)
>>> +SPL_LOAD_IMAGE_METHOD("PCIE", 0, BOOT_DEVICE_PCIE, spl_ram_load_image);
>>> +#endif
>>> diff --git a/drivers/Makefile b/drivers/Makefile
>>> index 7560008a842..77fc66eb8ba 100644
>>> --- a/drivers/Makefile
>>> +++ b/drivers/Makefile
>>> @@ -26,6 +26,7 @@ obj-$(CONFIG_MULTIPLEXER) += mux/
>>> obj-$(CONFIG_$(PHASE_)ETH) += net/
>>> obj-$(CONFIG_$(PHASE_)PCH) += pch/
>>> obj-$(CONFIG_$(PHASE_)PCI) += pci/
>>> +obj-$(CONFIG_$(PHASE_)PCI_ENDPOINT) += pci_endpoint/
>>> obj-$(CONFIG_$(PHASE_)PHY) += phy/
>>> obj-$(CONFIG_$(PHASE_)PINCTRL) += pinctrl/
>>> obj-$(CONFIG_$(PHASE_)POWER) += power/
>>> --
>>> 2.34.1
next prev parent reply other threads:[~2025-11-06 9:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-23 8:09 [PATCH v4] spl: Add support for Device Firmware Upgrade (DFU) over PCIe Hrushikesh Salunke
2025-10-31 14:52 ` Mattijs Korpershoek
2025-11-03 5:40 ` Hrushikesh Salunke
2025-11-06 9:11 ` Mattijs Korpershoek [this message]
2025-11-06 9:18 ` Mattijs Korpershoek
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=87h5v7r0eb.fsf@kernel.org \
--to=mkorpershoek@kernel.org \
--cc=a-dutta@ti.com \
--cc=andre.przywara@arm.com \
--cc=anshuld@ti.com \
--cc=danishanwar@ti.com \
--cc=dario.binacchi@amarulasolutions.com \
--cc=dinesh.maniyam@altera.com \
--cc=h-salunke@ti.com \
--cc=lukma@denx.de \
--cc=marek.vasut+renesas@mailbox.org \
--cc=peng.fan@nxp.com \
--cc=s-vadapalli@ti.com \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
--cc=ye.li@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