Re: [PATCH 1/2] lib/crc: loongarch: Use hardware unaligned load in CRC32(C) loops

["Wentao Guan" <guanwentao@uniontech.com>]

> On Sun, Oct 11, 2026 at 10:29:29PM +0800, Huacai Chen wrote:
> > +static inline u32 get_le32(const void *p)
> > +{
> > + if (static_branch_likely(&have_ual))
> > + return *((__le32 *)p);
> > + else
> > + return get_unaligned_le32(p);
> > +}
> 
> No, this is just broken.  The bare misaligned access is undefined
> behavior in C.  Also, every other use of {get,put}_unaligned_* in the
> kernel would need this; it is not specific to the CRC code.  Also, it is
Right, I got your thought. It not belong to CRC level.

> inefficient to compile both code paths into the binary.
> 
> The only way that realistically works, as we know from the other
> architectures, is for the unaligned access support to be known at
> compile time, and to have {get,put}_unaligned_* do the right thing
> accordingly.
So the optimize it can be move to {get,put}_unaligned_* code?

> 
> Since loongarch made the incorrect decision to not specify unaligned
> access unconditionally, similar to RISC-V it can be worked around only
> by overriding that in the kconfig.  For loongarch that appears that
> already be implemented; just unset CONFIG_ARCH_STRICT_ALIGN when you
> know the kernel will run only on CPUs that have fixed this bug.
I think that we have the use cases to provide the general kernel instead of the two kernel with
different config, so the image increase will be tolerated.

BRs
Wentao Guan