Hi Daniel,
On 6/10/26 10:59 AM, Daniel Palmer wrote:
Hi Quentin,
On Wed, 10 Jun 2026 at 17:47, Quentin Schulz <[email protected]> wrote:
I'm fine fixing what needs to be fixed now and improvements later on.
Ok, I'll wait for if/when Tom replies and maybe send a v3 just fixes
the main u-boot part.
Note that we generally do not like complete rewrites in one patch but
rather small incremental changes (which may end up in the same result,
but is "more reviewable"). We don't have a maintainer for that feature,
though Tom is the "catch-all" maintainer, so maybe you can convince him
a full rewrite is ok. In any case, I'm sure we would really appreciate
tests (I don't think we have any from the cursory check I just made) so
make sure to include some (especially for the issues you encountered so
we don't regress!).
I haven't touched it for a long time. But from what I remember fixing
the issues in it was basically rewriting it because of the code style
etc being so different from the rest of u-boot.
Different code style is not an issue. I'm sure lwip and mbedtls have a
different coding style than U-Boot, yet they are still part of it
because we imported them and don't want to modify them too much from
their respective upstream.
It's unclear if there's an upstream for XYZ modem. But in any case,
different coding style isn't a sufficient reason for doing a full rewrite.
I guess it might be ok if it's incremental changes that are doing
nothing but changing the coding style (but then, is it really worth it)
and they are reasonably easy to review. Confidence in the patches doing
nothing but changes the coding style would be increased if tests are
written for the current state of the xyz modem support with the old
coding style and making sure they still pass after the "rewrite".
Maybe I can use AI for good and have it generate a series of patches
from my version. I'm assuming sensible non-spam AI assisted changes
are ok :)
The current somewhat-official-but-not-written-down stance of the project
on that topic is "don't", see
https://lore.kernel.org/u-boot/20260520143639.GM1858239@bill-the-cat/.
There are a quite a few defconfigs which enable
CONFIG_SPL_YMODEM_SUPPORT so we need to have a good confidence in the
patches not breaking existing boards, and the use of AI is not really
inspiring trust in that.
Cheers,
Quentin
