[U-Boot] White space cleanup
Hi Tom,
the recent issue with CR / CRLF sequences in a shell script tiggered me to hae a closer look at such issues in other areas, and I dicovered a lot of formal coding style issues like C++ comments, trailing white space, leading white space (indentation not by TABs), excessive blank lines, trailing blank lines which I would like to clean up.
However, this affects more than 500 files, so it might cause a large number of mege conflicts with other changes.
When would be a good point of time in the release cycle to submit such a patch series?
Best regards,
Wolfgang Denk
On Fri, Nov 08, 2019 at 09:39:44AM +0100, Wolfgang Denk wrote:
Hi Tom,
the recent issue with CR / CRLF sequences in a shell script tiggered me to hae a closer look at such issues in other areas, and I dicovered a lot of formal coding style issues like C++ comments, trailing white space, leading white space (indentation not by TABs), excessive blank lines, trailing blank lines which I would like to clean up.
However, this affects more than 500 files, so it might cause a large number of mege conflicts with other changes.
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.
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!
Dear Tom,
In message 20191108151810.GY19317@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?
Best regards,
Wolfgang Denk
On Fri, Nov 08, 2019 at 05:55:03PM +0100, Wolfgang Denk wrote:
Dear Tom,
In message 20191108151810.GY19317@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!
participants (2)
-
Tom Rini -
Wolfgang Denk