Re: [PATCH v2 07/16] LoongArch: lib: General routines

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2225 bytes --]

On Thu, Jul 02, 2026 at 08:56:46PM +0000, Yao Zi wrote:
> On Thu, Jul 02, 2026 at 08:07:08AM -0600, Tom Rini wrote:
> > On Thu, Jul 02, 2026 at 10:24:28AM +0100, Jiaxun Yang wrote:
> > > 
> > > 
> > > On Wed, 1 Jul 2026, at 6:49 PM, Tom Rini wrote:
> > > > On Wed, Jul 01, 2026 at 11:17:59AM +0000, Yao Zi wrote:
> > > >
> > > >> From: Jiaxun Yang <jiaxun.yang@flygoat.com>
> > > >> 
> > > >> Add some common library routines for the architecture.
> > > >> 
> > > >> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> > > >> Signed-off-by: Yao Zi <me@ziyao.cc>
> > > > [snip]
> > > >> +#define CACHE_MAX_LEVEL		3
> > > >> +#define CACHE_MAX_INDEX		6
> > > >> +#define CACHE_OP		GENMASK(4, 3)
> > > >> +#define  CACHE_INDEX_INVWB	0x1
> > > >> +#define  CACHE_HIT_INVWB	0x2
> > > >> +#define CACHE_INDEX		GENMASK(2, 0)
> > > >
> > > > I was expecting checkpatch.pl to catch the double space here, but it
> > > > didn't. It did warn about a few other things in macros, which should be
> > > > checked out at least. And that comment applies for the whole series,
> > > > along with a manual check for other spacing issues, thanks!
> > > 
> > > Those style issues are mostly copied over Linux kernel counterparts, should
> > > we leave them as is to ease kernel rebasing effort, or fix them for consistency
> > > with rest of the U-Boot?
> > 
> > Ah, OK then yes, we can leave those if it's a match-up with the kernel,
> > but should make note of that in the commit message when applicable, not
> > just the cover letter. It will make finding that reasoning easier in the
> > future.
> 
> Yes, most style issues are in files copied from the kernel side, before
> sending v2, I do have a brief look and fix some of them (for example,
> mixed TAB/space and multiple empty lines).
> 
> But the diff quoted here isn't copied from kernel side, it's written by
> myself. I consider the double space meaningful since these two macros
> are two possible values of CACHE_OP, and found similar styles in
> tools/zynqmqimage.h (PART_ATTR_*) and kernel side, do you think it's
> acceptable?

We have 178 other files doing this, so, it's not a NAK if it's really
helpful to you.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]