[PATCH v1 1/2] ACPI: SPCR: Prefix error messages with FW_BUG

[PATCH v1 1/2] ACPI: SPCR: Prefix error messages with FW_BUG

[Andy Shevchenko]

The table values that are not defined in the specification are
considered non-fatal errors in the code. However, they are for
sure the bugs in the firmware. Point this out in the message by
prefixing them with FW_BUG.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/acpi/spcr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
index 1eabfcd122ee..01d29ebdb9c2 100644
--- a/drivers/acpi/spcr.c
+++ b/drivers/acpi/spcr.c
@@ -110,12 +110,12 @@ int __init acpi_parse_spcr(bool enable_earlycon, bool enable_console)
 		u32 bit_width = table->serial_port.access_width;
 
 		if (bit_width > ACPI_ACCESS_BIT_MAX) {
-			pr_err("Unacceptable wide SPCR Access Width.  Defaulting to byte size\n");
+			pr_err(FW_BUG "Unacceptable wide SPCR Access Width. Defaulting to byte size\n");
 			bit_width = ACPI_ACCESS_BIT_DEFAULT;
 		}
 		switch (ACPI_ACCESS_BIT_WIDTH((bit_width))) {
 		default:
-			pr_err("Unexpected SPCR Access Width.  Defaulting to byte size\n");
+			pr_err(FW_BUG "Unexpected SPCR Access Width. Defaulting to byte size\n");
 			fallthrough;
 		case 8:
 			iotype = "mmio";
-- 
2.40.0.1.gaa8946217a0b

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

[Andy Shevchenko]

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

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

Re: [PATCH v1 2/2] ACPI: SPCR: Amend indentation

[Rafael J. Wysocki]

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
>

Re: [PATCH v1 2/2] ACPI: SPCR: Amend indentation

[Andy Shevchenko]

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.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 2/2] ACPI: SPCR: Amend indentation

[Rafael J. Wysocki]

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.

Re: [PATCH v1 2/2] ACPI: SPCR: Amend indentation

[Andy Shevchenko]

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.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 2/2] ACPI: SPCR: Amend indentation

[Rafael J. Wysocki]

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.