[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250721214004.GA2756360@bhelgaas>
Date: Mon, 21 Jul 2025 16:40:04 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Colin Ian King <colin.i.king@...il.com>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Len Brown <lenb@...nel.org>, linux-pci@...r.kernel.org,
linux-acpi@...r.kernel.org, kernel-janitors@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH][next] ACPI: pci_link: Remove space before \n newline
On Mon, Jul 21, 2025 at 03:59:52PM +0100, Colin Ian King wrote:
> There is an extraneous space before a newline in an acpi_handle_debug
> message. Remove it.
>
> Signed-off-by: Colin Ian King <colin.i.king@...il.com>
FWIW,
Acked-by: Bjorn Helgaas <bhelgaas@...gle.com>
Fixes for more ACPI-related typos below, feel free to squash or I can
send separately.
> ---
> drivers/acpi/pci_link.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 08e10b6226dc..e4560b33b8ad 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -268,7 +268,7 @@ static int acpi_pci_link_get_current(struct acpi_pci_link *link)
>
> link->irq.active = irq;
>
> - acpi_handle_debug(handle, "Link at IRQ %d \n", link->irq.active);
> + acpi_handle_debug(handle, "Link at IRQ %d\n", link->irq.active);
>
> end:
> return result;
diff --git a/Documentation/ABI/testing/sysfs-firmware-acpi b/Documentation/ABI/testing/sysfs-firmware-acpi
index f4de60c4134d..72e7c9161ce7 100644
--- a/Documentation/ABI/testing/sysfs-firmware-acpi
+++ b/Documentation/ABI/testing/sysfs-firmware-acpi
@@ -108,15 +108,15 @@ Description:
number of a "General Purpose Events" (GPE).
A GPE vectors to a specified handler in AML, which
- can do a anything the BIOS writer wants from
+ can do anything the BIOS writer wants from
OS context. GPE 0x12, for example, would vector
to a level or edge handler called _L12 or _E12.
The handler may do its business and return.
- Or the handler may send send a Notify event
+ Or the handler may send a Notify event
to a Linux device driver registered on an ACPI device,
such as a battery, or a processor.
- To figure out where all the SCI's are coming from,
+ To figure out where all the SCIs are coming from,
/sys/firmware/acpi/interrupts contains a file listing
every possible source, and the count of how many
times it has triggered::
diff --git a/Documentation/firmware-guide/acpi/gpio-properties.rst b/Documentation/firmware-guide/acpi/gpio-properties.rst
index db0c0b1f3700..1e603189b5b1 100644
--- a/Documentation/firmware-guide/acpi/gpio-properties.rst
+++ b/Documentation/firmware-guide/acpi/gpio-properties.rst
@@ -92,8 +92,8 @@ and polarity settings. The table below shows the expectations:
| | Low | as low, assuming active |
+-------------+-------------+-----------------------------------------------+
-That said, for our above example the both GPIOs, since the bias setting
-is explicit and _DSD is present, will be treated as active with a high
+That said, for our above example, since the bias setting is explicit and
+_DSD is present, both GPIOs will be treated as active with a high
polarity and Linux will configure the pins in this state until a driver
reprograms them differently.
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index c2ab2783303f..a984ccd4a2a0 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -1406,7 +1406,7 @@ static int __init acpi_bus_init(void)
goto error1;
/*
- * Register the for all standard device notifications.
+ * Register for all standard device notifications.
*/
status =
acpi_install_notify_handler(ACPI_ROOT_OBJECT, ACPI_SYSTEM_NOTIFY,
Powered by blists - more mailing lists