[v1,2/2] ACPI: SPCR: Amend indentation
Commit Message
1) Remove unnecessary blank lines.
2) Remove double spaces for consistency.
3) Reformat one comment for consistency.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/acpi/spcr.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
Comments
On Wed, Mar 22, 2023 at 11:26 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> 1) Remove unnecessary blank lines.
> 2) Remove double spaces for consistency.
I don't quite agree with this.
Double spaces after a period are recognized as end-of-sentence markers
by some editors (notably vi), so if they have been used intentionally,
I see no reason to replace them.
> 3) Reformat one comment for consistency.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> drivers/acpi/spcr.c | 15 ++++++---------
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
> index 01d29ebdb9c2..3d242c746d10 100644
> --- a/drivers/acpi/spcr.c
> +++ b/drivers/acpi/spcr.c
> @@ -71,18 +71,16 @@ static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
>
> /**
> * acpi_parse_spcr() - parse ACPI SPCR table and add preferred console
> - *
> * @enable_earlycon: set up earlycon for the console specified by the table
> * @enable_console: setup the console specified by the table.
> *
> * For the architectures with support for ACPI, CONFIG_ACPI_SPCR_TABLE may be
> - * defined to parse ACPI SPCR table. As a result of the parsing preferred
> + * defined to parse ACPI SPCR table. As a result of the parsing preferred
> * console is registered and if @enable_earlycon is true, earlycon is set up.
> * If @enable_console is true the system console is also configured.
> *
> * When CONFIG_ACPI_SPCR_TABLE is defined, this function should be called
> * from arch initialization code as soon as the DT/ACPI decision is made.
> - *
> */
> int __init acpi_parse_spcr(bool enable_earlycon, bool enable_console)
> {
> @@ -97,9 +95,7 @@ int __init acpi_parse_spcr(bool enable_earlycon, bool enable_console)
> if (acpi_disabled)
> return -ENODEV;
>
> - status = acpi_get_table(ACPI_SIG_SPCR, 0,
> - (struct acpi_table_header **)&table);
> -
> + status = acpi_get_table(ACPI_SIG_SPCR, 0, (struct acpi_table_header **)&table);
> if (ACPI_FAILURE(status))
> return -ENOENT;
>
> @@ -184,10 +180,10 @@ int __init acpi_parse_spcr(bool enable_earlycon, bool enable_console)
> *
> * If the user specifies "traditional" earlycon, the qdf2400_e44
> * console name matches the EARLYCON_DECLARE() statement, and
> - * SPCR is not used. Parameter "earlycon" is false.
> + * SPCR is not used. Parameter "earlycon" is false.
> *
> * If the user specifies "SPCR" earlycon, then we need to update
> - * the console name so that it also says "qdf2400_e44". Parameter
> + * the console name so that it also says "qdf2400_e44". Parameter
> * "earlycon" is true.
> *
> * For consistency, if we change the console name, then we do it
> @@ -202,7 +198,8 @@ int __init acpi_parse_spcr(bool enable_earlycon, bool enable_console)
> if (xgene_8250_erratum_present(table)) {
> iotype = "mmio32";
>
> - /* for xgene v1 and v2 we don't know the clock rate of the
> + /*
> + * For xgene v1 and v2 we don't know the clock rate of the
> * UART so don't attempt to change to the baud rate state
> * in the table because driver cannot calculate the dividers
> */
> --
> 2.40.0.1.gaa8946217a0b
>
On Wed, Mar 22, 2023 at 07:50:55PM +0100, Rafael J. Wysocki wrote:
> On Wed, Mar 22, 2023 at 11:26 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
...
> > 2) Remove double spaces for consistency.
>
> I don't quite agree with this.
>
> Double spaces after a period are recognized as end-of-sentence markers
> by some editors (notably vi), so if they have been used intentionally,
> I see no reason to replace them.
For the sake of consistency. There places in very same file which do not
follow this. I can invert and add a space to the rest. Do you prefer that?
The reasoning will be kept the same, though.
On Thu, Mar 23, 2023 at 1:24 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, Mar 22, 2023 at 07:50:55PM +0100, Rafael J. Wysocki wrote:
> > On Wed, Mar 22, 2023 at 11:26 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
>
> ...
>
> > > 2) Remove double spaces for consistency.
> >
> > I don't quite agree with this.
> >
> > Double spaces after a period are recognized as end-of-sentence markers
> > by some editors (notably vi), so if they have been used intentionally,
> > I see no reason to replace them.
>
> For the sake of consistency. There places in very same file which do not
> follow this. I can invert and add a space to the rest. Do you prefer that?
Not really. I just don't think that this is worth the churn.
> The reasoning will be kept the same, though.
Is the lack of consistency in this particular respect really an issue?
I guess you can argue that if there are mixed sentence ending styles
in one and the same comment, it is better to make them consistent,
which I can agree with. Otherwise I'm not convinced.
On Thu, Mar 23, 2023 at 09:31:11PM +0100, Rafael J. Wysocki wrote:
> On Thu, Mar 23, 2023 at 1:24 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Wed, Mar 22, 2023 at 07:50:55PM +0100, Rafael J. Wysocki wrote:
> > > On Wed, Mar 22, 2023 at 11:26 AM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
...
> > > > 2) Remove double spaces for consistency.
> > >
> > > I don't quite agree with this.
> > >
> > > Double spaces after a period are recognized as end-of-sentence markers
> > > by some editors (notably vi), so if they have been used intentionally,
> > > I see no reason to replace them.
> >
> > For the sake of consistency. There places in very same file which do not
> > follow this. I can invert and add a space to the rest. Do you prefer that?
>
> Not really. I just don't think that this is worth the churn.
Ah, that's fine.
> > The reasoning will be kept the same, though.
>
> Is the lack of consistency in this particular respect really an issue?
>
> I guess you can argue that if there are mixed sentence ending styles
> in one and the same comment, it is better to make them consistent,
> which I can agree with. Otherwise I'm not convinced.
Okay, do you agree with the first patch in the series?
Then I can redo this one by dropping these particular
changes.
On Fri, Mar 24, 2023 at 10:05 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Thu, Mar 23, 2023 at 09:31:11PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Mar 23, 2023 at 1:24 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
>
> > > On Wed, Mar 22, 2023 at 07:50:55PM +0100, Rafael J. Wysocki wrote:
> > > > On Wed, Mar 22, 2023 at 11:26 AM Andy Shevchenko
> > > > <andriy.shevchenko@linux.intel.com> wrote:
>
> ...
>
> > > > > 2) Remove double spaces for consistency.
> > > >
> > > > I don't quite agree with this.
> > > >
> > > > Double spaces after a period are recognized as end-of-sentence markers
> > > > by some editors (notably vi), so if they have been used intentionally,
> > > > I see no reason to replace them.
> > >
> > > For the sake of consistency. There places in very same file which do not
> > > follow this. I can invert and add a space to the rest. Do you prefer that?
> >
> > Not really. I just don't think that this is worth the churn.
>
> Ah, that's fine.
>
> > > The reasoning will be kept the same, though.
> >
> > Is the lack of consistency in this particular respect really an issue?
> >
> > I guess you can argue that if there are mixed sentence ending styles
> > in one and the same comment, it is better to make them consistent,
> > which I can agree with. Otherwise I'm not convinced.
>
> Okay, do you agree with the first patch in the series?
I do. In fact, I've applied it already.
> Then I can redo this one by dropping these particular
> changes.
Yes, please.
@@ -71,18 +71,16 @@ static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
/**
* acpi_parse_spcr() - parse ACPI SPCR table and add preferred console
- *
* @enable_earlycon: set up earlycon for the console specified by the table
* @enable_console: setup the console specified by the table.
*
* For the architectures with support for ACPI, CONFIG_ACPI_SPCR_TABLE may be
- * defined to parse ACPI SPCR table. As a result of the parsing preferred
+ * defined to parse ACPI SPCR table. As a result of the parsing preferred
* console is registered and if @enable_earlycon is true, earlycon is set up.
* If @enable_console is true the system console is also configured.
*
* When CONFIG_ACPI_SPCR_TABLE is defined, this function should be called
* from arch initialization code as soon as the DT/ACPI decision is made.
- *
*/
int __init acpi_parse_spcr(bool enable_earlycon, bool enable_console)
{
@@ -97,9 +95,7 @@ int __init acpi_parse_spcr(bool enable_earlycon, bool enable_console)
if (acpi_disabled)
return -ENODEV;
- status = acpi_get_table(ACPI_SIG_SPCR, 0,
- (struct acpi_table_header **)&table);
-
+ status = acpi_get_table(ACPI_SIG_SPCR, 0, (struct acpi_table_header **)&table);
if (ACPI_FAILURE(status))
return -ENOENT;
@@ -184,10 +180,10 @@ int __init acpi_parse_spcr(bool enable_earlycon, bool enable_console)
*
* If the user specifies "traditional" earlycon, the qdf2400_e44
* console name matches the EARLYCON_DECLARE() statement, and
- * SPCR is not used. Parameter "earlycon" is false.
+ * SPCR is not used. Parameter "earlycon" is false.
*
* If the user specifies "SPCR" earlycon, then we need to update
- * the console name so that it also says "qdf2400_e44". Parameter
+ * the console name so that it also says "qdf2400_e44". Parameter
* "earlycon" is true.
*
* For consistency, if we change the console name, then we do it
@@ -202,7 +198,8 @@ int __init acpi_parse_spcr(bool enable_earlycon, bool enable_console)
if (xgene_8250_erratum_present(table)) {
iotype = "mmio32";
- /* for xgene v1 and v2 we don't know the clock rate of the
+ /*
+ * For xgene v1 and v2 we don't know the clock rate of the
* UART so don't attempt to change to the baud rate state
* in the table because driver cannot calculate the dividers
*/