Re: [PATCH] habanalabs: select CRC32

[Vegard Nossum <vegard.nossum@oracle.com>]

On 10/11/21 5:33 PM, Arnd Bergmann wrote:
> On Mon, Oct 11, 2021 at 5:14 PM Vegard Nossum <vegard.nossum@oracle.com> wrote:
>>
>> Fix the following build/link error by adding a dependency on the CRC32
>> routines:
>>
>>   ld: drivers/misc/habanalabs/common/firmware_if.o: in function `hl_fw_dynamic_request_descriptor':
>>   firmware_if.c:(.text.unlikely+0xc89): undefined reference to `crc32_le'
>>
>> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
> 
> Patch looks good to me, I wonder how I never caught that with my own randconfig
> build testing. May I ask how you found it?
> 
> Fixes: 8a43c83fec12 ("habanalabs: load boot fit to device")
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> 

Thanks.

I'm working on a couple of new make targets, satconfig and
satrandconfig, which can generate .configs that respect a set of choices
specified in a .satconfig file (and, of course, the Kconfig files).

In this case, I was just doing satrandconfig builds and noticed that the
crc32_le ones popped up quite often so I just added CONFIG_CRC32=n to my
.satconfig, which means that satrandconfig will generate only configs
that have CRC32=n.

I also suspect that satrandconfig samples the configuration space MUCH
more uniformly than randconfig, in the sense that "make randconfig" will
tend to have CRC32 enabled just because there are so many drivers that
_do_ select it. (Think of it this way, every prompt for an option that
has "select CRC32" in it will be another 50% probability of actually
enabling the option.)

I just tried doing 'make randconfig' 100 times and the result was
CRC32=y every single time.

If I do the same for 'make satrandconfig', I get the following
distribution of values:

48 CRC32=y
10 CRC32=m
42 CRC32=n

That's probably still not really uniform, but quite a bit better, and as
I said I can still put CONFIG_CRC32=n in my .satconfig and get _only_
configs that respect this choice.

The really cool thing about sat{,rand}config IMHO is that you can fairly
easily generate random configs that you know will be bootable (because
you've forced it to only output configs that respect options that you
need to boot on your particular setup).

This project itself is about 11 years old, but I made a breakthrough
recently and I'm polishing the patches for submission now. I thought I
would try to fix the breakage that I could find first so it doesn't
appear as if the tool itself is broken... (that's not to say it doesn't
have any bugs, however!)


Vegard