[U-Boot] White space cleanup

[Tom Rini]

On Fri, Nov 08, 2019 at 05:55:03PM +0100, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20191108151810.GY19317 at bill-the-cat> you wrote:
> > 
> > > When would be a good point of time in the release cycle to submit
> > > such a patch series?
> >
> > Lets see.  For '//' style comments, while I personally can't bring
> > myself to use them, most of what we have today is generated files or
> > external project files.  Given that the Linux kernel no longer complains
> > about it (and per the last thread about them, they're C99 comments, and
> > that's 20 years ago now), it's probably best to just say they're
> > discouraged but also that:
> > 	writel(1, DDRPHY_CONFIG_BASE + 0x134); // DATA0_REG_PHY_USE_RANK0_DELAYS
> > is at least as readable if not more so than:
> > 	writel(1, DDRPHY_CONFIG_BASE + 0x134); /* DATA0_REG_PHY_USE_RANK0_DELAYS */
> >
> > which goes past 80 chars wide, rather than sticking to 80.
> 
> Agreed.  I guess age brings that I also feel less fanatic here ;-)
> 
> > For the whitespace stuff, whenever is fine, being careful of stuff we
> > sync from elsewhere rather than is our own.  Whitespace changes there
> > make future resync harder.  Thanks!
> 
> Sure.  But you did not answer my key question:
> 
> When would be a good point of time in the release cycle to submit
> such a patch series?

Ah, I wasn't clear enough.  Whenever you post them, I'll integrate them.
We shouldn't be getting new problems here as I think they're mostly
historical.  I do try and look at everything checkpatch tells me and
that in turn should keep new whitespace problems from coming in.
Assuming you do it with a git grep | xargs sed, dropping that below the
'---' in the patch will make any re-fixing up easier too.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191108/218ed49b/attachment.sig>