All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.