diff mbox series

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

Message ID 20230322102258.27390-2-andriy.shevchenko@linux.intel.com
State New
Headers show
Series [v1,1/2] ACPI: SPCR: Prefix error messages with FW_BUG | expand

Commit Message

Andy Shevchenko March 22, 2023, 10:22 a.m. UTC 
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

Rafael J. Wysocki March 23, 2023, 8:31 p.m. UTC | #1 
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.
diff mbox series

Patch

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
 		 */