linux-kernel - Re: [PATCH RESEND v1 1/2] ACPI/PCI: Make

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0hWm5_zwY9z10dTg4K0Skz-bGc8ABH7C0j_=Vu+Z8zqpQ@mail.gmail.com>
Date:   Tue, 5 Jul 2022 19:52:46 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Pierre Gondois <pierre.gondois@....com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Linux PCI <linux-pci@...r.kernel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH RESEND v1 1/2] ACPI/PCI: Make _SRS optional for link device

On Fri, Jul 1, 2022 at 6:17 PM Pierre Gondois <pierre.gondois@....com> wrote:
>
> From: Pierre Gondois <Pierre.Gondois@....com>
>
> In ACPI 6.4, s6.2.13 "_PRT (PCI Routing Table)", PCI legacy
> interrupts can be described though a link device (first model).
> From s6.2.16 "_SRS (Set Resource Settings)":
> "This optional control method [...]"
>
> Make it optional to have a _SRS method for link devices.

Note that if _DIS is present, _SRS is necessary to enable the link and
acpi_pci_link_add() evaluates _DIS for all links.  So you need to
check both, not just one.

Moreover, it doesn't make much sense to provide _PRS without _SRS and
arguably _PRS is needed if _SRS is present, so this needs to be taken
into account too.

AFAICS, the only valid configuration in which _SRS and _PRS are not
present is when _DIS is not present too, so only _CRS is present and
the IRQ listed by it is actually in use.  However, in that case it is
hardly necessary to add a device object for the PCI link device at
all.

> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215560
> Signed-off-by: Pierre Gondois <pierre.gondois@....com>
> ---
>  drivers/acpi/pci_link.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 58647051c948..129e3e7e80ee 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -288,6 +288,13 @@ static int acpi_pci_link_set(struct acpi_pci_link *link, int irq)
>         if (!irq)
>                 return -EINVAL;
>
> +       if (!acpi_has_method(handle, METHOD_NAME__SRS)) {
> +               if (link->irq.active == irq)
> +                       return 0;
> +               acpi_handle_err(handle, "Unable to set IRQ %d: No _SRS.\n", irq);
> +               return -ENODEV;
> +       }
> +
>         resource = kzalloc(sizeof(*resource) + 1, irqs_disabled() ? GFP_ATOMIC: GFP_KERNEL);
>         if (!resource)
>                 return -ENOMEM;
> --
> 2.25.1
>