* [PATCH v1 1/2] ACPI: SPCR: Prefix error messages with FW_BUG
@ 2023-03-22 10:22 Andy Shevchenko
2023-03-22 10:22 ` [PATCH v1 2/2] ACPI: SPCR: Amend indentation Andy Shevchenko
0 siblings, 1 reply; 7+ messages in thread
From: Andy Shevchenko @ 2023-03-22 10:22 UTC (permalink / raw)
To: Andy Shevchenko, linux-acpi, linux-kernel; +Cc: Rafael J. Wysocki, Len Brown
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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH v1 2/2] ACPI: SPCR: Amend indentation
2023-03-22 10:22 [PATCH v1 1/2] ACPI: SPCR: Prefix error messages with FW_BUG Andy Shevchenko
@ 2023-03-22 10:22 ` Andy Shevchenko
2023-03-22 18:50 ` Rafael J. Wysocki
0 siblings, 1 reply; 7+ messages in thread
From: Andy Shevchenko @ 2023-03-22 10:22 UTC (permalink / raw)
To: Andy Shevchenko, linux-acpi, linux-kernel; +Cc: Rafael J. Wysocki, Len Brown
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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH v1 2/2] ACPI: SPCR: Amend indentation
2023-03-22 10:22 ` [PATCH v1 2/2] ACPI: SPCR: Amend indentation Andy Shevchenko
@ 2023-03-22 18:50 ` Rafael J. Wysocki
2023-03-23 12:24 ` Andy Shevchenko
0 siblings, 1 reply; 7+ messages in thread
From: Rafael J. Wysocki @ 2023-03-22 18:50 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: linux-acpi, linux-kernel, Rafael J. Wysocki, Len Brown
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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v1 2/2] ACPI: SPCR: Amend indentation
2023-03-22 18:50 ` Rafael J. Wysocki
@ 2023-03-23 12:24 ` Andy Shevchenko
2023-03-23 20:31 ` Rafael J. Wysocki
0 siblings, 1 reply; 7+ messages in thread
From: Andy Shevchenko @ 2023-03-23 12:24 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-acpi, linux-kernel, Len Brown
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v1 2/2] ACPI: SPCR: Amend indentation
2023-03-23 12:24 ` Andy Shevchenko
@ 2023-03-23 20:31 ` Rafael J. Wysocki
2023-03-24 9:05 ` Andy Shevchenko
0 siblings, 1 reply; 7+ messages in thread
From: Rafael J. Wysocki @ 2023-03-23 20:31 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: Rafael J. Wysocki, linux-acpi, linux-kernel, Len Brown
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v1 2/2] ACPI: SPCR: Amend indentation
2023-03-23 20:31 ` Rafael J. Wysocki
@ 2023-03-24 9:05 ` Andy Shevchenko
2023-03-24 11:55 ` Rafael J. Wysocki
0 siblings, 1 reply; 7+ messages in thread
From: Andy Shevchenko @ 2023-03-24 9:05 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-acpi, linux-kernel, Len Brown
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v1 2/2] ACPI: SPCR: Amend indentation
2023-03-24 9:05 ` Andy Shevchenko
@ 2023-03-24 11:55 ` Rafael J. Wysocki
0 siblings, 0 replies; 7+ messages in thread
From: Rafael J. Wysocki @ 2023-03-24 11:55 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: Rafael J. Wysocki, linux-acpi, linux-kernel, Len Brown
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-03-24 11:55 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-22 10:22 [PATCH v1 1/2] ACPI: SPCR: Prefix error messages with FW_BUG Andy Shevchenko
2023-03-22 10:22 ` [PATCH v1 2/2] ACPI: SPCR: Amend indentation Andy Shevchenko
2023-03-22 18:50 ` Rafael J. Wysocki
2023-03-23 12:24 ` Andy Shevchenko
2023-03-23 20:31 ` Rafael J. Wysocki
2023-03-24 9:05 ` Andy Shevchenko
2023-03-24 11:55 ` Rafael J. Wysocki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).