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

[Wentao Guan]

Hi Eric,

> On Mon, Oct 12, 2026 at 02:43:47PM +0800, Huacai Chen wrote:
> > Yes, we considered modifying {get,put}_unaligned_* globally. But it is
> > not arch-specific code and we have no way to override it.
> >
> > On the other hand, the byte-to-byte {get,put}_unaligned_* is always
> > correct, we are free to only optimise the hot path (like crc32 code).
> 
> The unaligned access macros are used in lots of other
> performance-critical code.  Hacks in random places don't scale.
Agree, from their side, they thought may like: the change is minimal?
My thought like what other arch did, use alternative to patch the {get,put}_unaligned_*?

> > > > 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.
> > Yes, the default configuration is to keep CONFIG_ARCH_STRICT_ALIGN set
> > for single kernel binary.
> 
> So don't do that.  It does not work for divergent unaligned access
> support, as the other architectures have learned long ago.
From RISC-V workaround learn, their model is different,
they want to default unaligned access, and trap and emulate the access.

This LoongArch model is point to default safely aligned access,
after detected the unaligned access support, next to use the unaligned to speed up.
Or did anything I missing?

BRs
Wentao Guan