[PATCH v2] xyz-modem: Select CRC16

[Quentin Schulz]

Hi Daniel,

On 6/10/26 10:59 AM, Daniel Palmer wrote:
> Hi Quentin,
> 
> On Wed, 10 Jun 2026 at 17:47, Quentin Schulz <quentin.schulz at cherry.de> 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