Linux ACPI
 help / color / mirror / Atom feed
From: Pierre Gondois <pierre.gondois@arm.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Alex Hung <alex.hung@canonical.com>,
	Marc Zyngier <maz@kernel.org>
Subject: Re: [Bug 215560] New: _PRS/_SRS methods should be optional
Date: Thu, 3 Feb 2022 18:12:10 +0100	[thread overview]
Message-ID: <e2ae06ba-de8f-2cae-60fa-fe9a215d779b@arm.com> (raw)
In-Reply-To: <20220203163214.GA98384@bhelgaas>


On 2/3/22 5:32 PM, Bjorn Helgaas wrote:
> [+cc Rafael, Alex, Marc]
> 
> On Thu, Feb 03, 2022 at 10:10:19AM +0100, Pierre Gondois wrote:
>> On 2/2/22 6:42 PM, Bjorn Helgaas wrote:
>>> On Wed, Feb 02, 2022 at 10:20:44AM +0000, bugzilla-daemon@kernel.org wrote:
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=215560
>>>>
>>>> The PCI legacy interrupts can be described with link devices, cf ACPI 6.4,
>>>> s6.2.13 "_PRT (PCI Routing Table)".
>>>> Link devices can have optional _SRS/_PRS methods to set the interrupt.
>>>> ...
> 
>>>> However, _PRS/_SRS methods are checked in drivers/acpi/pci_link.c, and the
>>>> driver aborts if they are absent.
>>>> E.g.: When _PRS is missing:
>>>> ACPI: \_SB_.PCI0.LNKA: _CRS 36 not found in _PRS
>>>> ACPI: \_SB_.PCI0.LNKA: No IRQ available. Try pci=noacpi or acpi=off
>>>
>>> I assume this bug report is because something isn't working.  Can
>>> you update the bugzilla with a note about what specifically isn't
>>> working and also attach a complete dmesg log and acpidump?
>>
>> The question arose while writing link devices code, so there is no
>> platform with missing _PRS/_SRS methods that I know.
>>
>> The question was more about spec compliance and the necessity to
>> have these methods when legacy interrupts are not configurable.  The
>> message above (_CRS XXX not found in _PRS) can be generated for a
>> Juno for instance, and the ACPI tables are at:
>> https://github.com/tianocore/edk2-platforms/blob/master/Platform/ARM/JunoPkg/AcpiTables/AcpiSsdtRootPci.asl
>> The ACPI table need to be modified (remove _PRS and set _CRS
>> correctly).
>>
>> If the conclusion is that _PRS/_SRS are mandatory, even for
>> hard-wired interrupts, then the bugzilla can be closed.
> 
> OK, so if I understand correctly, you're using Interrupt Link devices
> not because it's possible to connect a PCI interrupt to one of several
> inputs on the interrupt controller, but because the PCI default of
> "level triggered, active low" is not compatible with GICv2.
> 
> The Interrupt Link device gives you a chance to specify "level
> triggered, active *high*".  If you used a Source of 0 (where there
> is no Interrupt Link), there would be no way to specify that.
> 
> Since this use of Interrupt Links only conveys triggering information
> and nothing is configurable, I think the OS should get that info from
> _CRS, and _PRS and _SRS should not be required.
> 
> Alex made a change [1] along that line a while ago, but maybe there's
> more we should do.
> 
> Bjorn
> 
> [1] https://git.kernel.org/linus/92d1b381f677
> 

Yes, this is exactly the situation.

The interrupt advertised in _CRS is checked to be in _PRS at:
https://github.com/torvalds/linux/blob/26291c54e111ff6ba87a164d85d4a4e134b7315c/drivers/acpi/pci_link.c#L549
and the _SRS method is also evaluated.

I can submit a patch if necessary,
Pierre

  reply	other threads:[~2022-02-03 17:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-215560-41252@https.bugzilla.kernel.org/>
2022-02-02 17:42 ` [Bug 215560] New: _PRS/_SRS methods should be optional Bjorn Helgaas
2022-02-03  9:10   ` Pierre Gondois
2022-02-03 16:32     ` Bjorn Helgaas
2022-02-03 17:12       ` Pierre Gondois [this message]
2022-02-03 17:50         ` 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=e2ae06ba-de8f-2cae-60fa-fe9a215d779b@arm.com \
    --to=pierre.gondois@arm.com \
    --cc=alex.hung@canonical.com \
    --cc=helgaas@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    /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