[v1,2/2] ACPI: SPCR: Amend indentation

  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(-)
  

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.