08:12 <LeSpocky> sjg1: I'm hitting PREFER_IF checkpatch warnings suggesting to replace #ifdef with if (IS_ENABLED(…, the commit introducing that check gives no further explanation why this is useful. is there something in documentation or can you explain?

09:59 <marex> LeSpocky: if (IS_ENABLED(CONFIG...)) is compile-time test, so the code in this if block is checked by compiler even if disabled. Unlike code in #if ... which is removed by preprocessor and not checked by compiler . The former prevents bitrot better .

10:02 <LeSpocky> marex: mkay, and we rely on the compiler removing this stuff for disabled config symbols when optimizing?

10:06 <derRichard> is it considered bad practice to have different version of u-boot and the spl? usually both u-boot and spl are built from the very same source/version. on my desk i see a system where spl and u-boot can be from completely different u-boot versions

10:07 <derRichard> to me this smells like a footgun

10:08 <marex> LeSpocky: yes

10:09 <marex> LeSpocky: when the symbol is disabled, it becomes if (0) { code; } ... the code still has to be valid, but it is thrown out by the compiler

10:09 <LeSpocky> marex: okay thanks for confirming, I just played this through with compiler explorer and different -O options :-)

10:09 <marex> derRichard: it is possible if there is no real dependency between the two, which most of the time is the case

10:11 <derRichard> marex: ok. my fear is that future u-boot versions need different load adresses or such

10:12 <marex> derRichard: if the SPL is loading uimage/fitimage bundle, that should be OKish ?

10:13 <derRichard> it should, yes. at least i hope so :D

13:23 <samcday> 0/ hello chums. What's the general etiquette for nagging on patches in the list? I bumped into a null deref issue fixed by https://lists.denx.de/pipermail/u-boot/2025-January/577205.html ... if I've applied that to my tree and confirmed it fixes the issue is it appropriate for me to ping some kind of "+1 works on my machine!" follow-up on it?

13:24 <LeSpocky> sounds like you want to answer and add a line 'Tested-by: Your Name <your@email>' to your reply?

13:31 <mkorpershoek> samcday: it's on my rader, I plan to pick it up shortly. But yes, if you have tested it, please reply to the email with 'Tested-by: Your Name <your@email>' as LeSpocky said

13:32 <mkorpershoek> Additional testing is always helpful, so I'd like to include your Tested-by: credit in the commit message

13:32 <mkorpershoek> let me know if I should wait on your reply before applying the listed patch

13:40 <samcday> Hello to you both, thanks for the advice. I will send a reply in a few moments with the "Tested-by" tag

16:12 <sjg1> Tartarus: Thanks again for your help getting net going on rpi3. I made a small tweak and resent just that patch: https://patchwork.ozlabs.org/project/uboot/patch/20250123161114.84071-46-sjg@chromium.org/

16:29 <Tartarus> You're welcome. And I got it going on 32bit as well now, but I also run in to, seemingly spuriously, the "timeout" thing you added

16:31 <Tartarus> ! _pytest.outcomes.Exit: Lab timeout: Marking connection bad - no other tests will run !

16:31 <Tartarus> When, looking at the logs, hmm, it should have been a fail, but because of the kernel image being too big