[PATCH 1/1] riscv: fix building with CONFIG_SPL_SMP=n

Andy Shevchenko andy.shevchenko at gmail.com
Wed Aug 5 09:17:28 CEST 2020


On Wed, Aug 5, 2020 at 3:11 AM Bin Meng <bmeng.cn at gmail.com> wrote:
> On Tue, Aug 4, 2020 at 10:58 PM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> > On 04.08.20 15:15, Bin Meng wrote:
> > > On Tue, Aug 4, 2020 at 7:02 PM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> > >> On 04.08.20 03:46, Bin Meng wrote:
> > >>> On Tue, Aug 4, 2020 at 5:26 AM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:

...

> > >>>> Fixes: 191636e44898 ("riscv: Introduce SPL_SMP Kconfig option for U-Boot
> > >>>> SPL")
> > >>>
> > >>> This should be on the same line

The rule of thumb is one tag == one line. Otherwise it breaks a lot of
scripting here and there.
The reason why is that actually Unix tools are not designed (yes, I
know it's possible to do in some cases) to handle multi-line
processing (like multi-line grep). So, 100% Fixes should be one line.
Also this is applicable to URLs.

> > >> Commit messages should not exceed 75 characters. See scripts/checkpatch.pl:
> > >
> > > True, for normal commit messages.
> > >
> > >>
> > >> WARN("COMMIT_LOG_LONG_LINE",
> > >> "Possible unwrapped commit description (prefer a maximum 75 chars per
> > >> line)\n" . $herecurr);

This warning is bogus. Fix your tools.

> > > But this Fixes tag is special. I suspect 2 lines will break some
> > > scripts that is handling this "Fixes" tag.

Precisely!

> > checkpatch.pl and patchstream.py are the only U-Boot scripts containing
> > the string "Fixes".
> >
> > * checkpatch.pl does not complain.
> > * I don't use patman. So I don't care if it has a bug.

You don't but maintainers tell you what to do. And yes, tools
sometimes wrong or false positive, feel free to complain about them.

> > We already have patches like this by other developers and nobody complained:
>
> IIRC, last time Andy raised the same concern.
>
> Andy, would you share some examples or best practices?
>
> >
> > dcdea292d9f3
> > 4fb2264b2848
> > 00160cf32e6e
> >
> > So why should I worry?

I hope above clarifies. And it's generally a weak argument to point to
bad examples in the past.

-- 
With Best Regards,
Andy Shevchenko


More information about the U-Boot mailing list