From: Dave Hansen <dave.hansen@intel.com>
To: Brent Spillner <spillner@acm.org>,
bhelgaas@google.com, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arch:x86:pci:irq.c: Improve log message when IRQ cannot be identified
Date: Fri, 28 Jan 2022 10:00:23 -0800 [thread overview]
Message-ID: <a7ef2455-ede5-2238-639b-b3a66842a04b@intel.com> (raw)
In-Reply-To: <YfQpy5yGGqY8T0wW@jupiter.dyndns.org>
Please fix up that subject. We don't tend to use ":" to separate
things. Second, the prefix isn't a filename. It's really a subsystem.
Take a look at:
git log arch/x86/pci/irq.c
for some other examples.
On 1/28/22 09:37, Brent Spillner wrote:
> The existing code always suggests trying the pci=biosirq kernel
> parameter, but this option is only recognized when CONFIG_PCI_BIOS is
> set, which in turn depends on CONFIG_X86_32, so it is never appropriate
> on x86_64.
>
> The new version tries to form a more useful message when pci=biosirq is
> not available, including by suggesting different acpi= options if
> appropriate (probably the most common cause of failed IRQ discovery).
>
> See arch/x86/pci/common.c:535 for the interpretation of pci=biosirq, and
> arch/x86/Kconfig:2633 for the dependencies of CONFIG_PCI_BIOS.
Shockingly enough, that parameter is in the documentation:
Documentation/admin-guide/kernel-parameters.txt
and double-shockingly, it's even called out as X86-32-only:
biosirq [X86-32] Use PCI BIOS calls to get the interrupt
Given that, do we really need to refer to the line numbers of the
implementation which will probably be stale by the time this is merged
anyway?
> arch/x86/pci/irq.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
> index 97b63e35e152..bc4aaaa74832 100644
> --- a/arch/x86/pci/irq.c
> +++ b/arch/x86/pci/irq.c
> @@ -1522,7 +1522,21 @@ static int pirq_enable_irq(struct pci_dev *dev)
> } else if (pci_probe & PCI_BIOS_IRQ_SCAN)
> msg = "";
> else
> +#ifdef CONFIG_PCI_BIOS
> msg = "; please try using pci=biosirq";
> +#else
> + /* pci=biosirq is not a valid option */
> +#ifdef CONFIG_ACPI
> + if (acpi_noirq)
> + msg = "; consider removing acpi=noirq";
> + else
> +#endif
> + msg = "; recommend verifying UEFI/BIOS IRQ options"
> +#ifndef CONFIG_ACPI
> + " or enabling ACPI"
> +#endif
> + ;
> +#endif
Any chance you could make that, um, a bit more readable? It's OK to add
brackets to the else{} for readability even if they're not *strictly*
necessary.
It might also be nice to use
if (IS_ENABLED(CONFIG_FOO))
...
rather than the #ifdefs.
I'd also be perfectly OK having two different strings rather than
relying on string concatenation and the #ifdefs.
Is the "or enabling ACPI" message really necessary?
next prev parent reply other threads:[~2022-01-28 18:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-28 17:37 [PATCH] arch:x86:pci:irq.c: Improve log message when IRQ cannot be identified Brent Spillner
2022-01-28 18:00 ` Dave Hansen [this message]
2022-01-28 20:48 ` Brent Spillner
2022-01-28 21:36 ` Dave Hansen
2022-01-31 21:22 ` Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a7ef2455-ede5-2238-639b-b3a66842a04b@intel.com \
--to=dave.hansen@intel.com \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=spillner@acm.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).