From: Marc Zyngier <maz@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Frank Wunderlich <frank-w@public-files.de>,
Ryder Lee <ryder.lee@mediatek.com>,
linux-mediatek@lists.infradead.org,
Frank Wunderlich <linux@fw-web.de>,
linux-kernel@vger.kernel.org,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: Aw: Re: Re: [PATCH] pci: mediatek: fix warning in msi.h
Date: Fri, 06 Nov 2020 09:43:58 +0000 [thread overview]
Message-ID: <c63d8d7d966c1dda82884f361d4691c3@kernel.org> (raw)
In-Reply-To: <87blgbl887.fsf@nanos.tec.linutronix.de>
On 2020-11-05 23:00, Thomas Gleixner wrote:
> On Thu, Nov 05 2020 at 09:20, Marc Zyngier wrote:
>> On 2020-11-04 23:14, Thomas Gleixner wrote:
>>> /* Resource alignment requirements */
>>> resource_size_t (*align_resource)(struct pci_dev *dev,
>>
>> If that's the direction of travel, we also need something like this
>> for configuration where the host bridge relies on an external MSI
>> block
>> that uses MSI domains (boot-tested in a GICv3 guest).
>
> Some more context would be helpful. Brain fails to decode the logic
> here.
OK, let me try again.
The MSI controller, which is the thing that deals with MSIs in the
system
(GICv2m, GICv3-ITS, and a number of others), is optional, is not part of
the
host bridge (it has nothing to do with PCI at all), and the bridge
driver has
absolutely no idea whether:
- there is something that provides MSI or not
- that something has successfully been initialised or not (which
translates
into an MSI domain being present or not)
This is the case for most ARM systems, and all KVM/arm guests. Booting a
VM
without MSIs is absolutely trivial, and actually makes sense for some of
the
smaller guests.
In these conditions, your no_msi attribute doesn't work as is: we can't
decide
on its value at probe time without extracting all of the OF/ACPI logic
that
deals with MSI domains from the core code, and making it available to
the host
bridge drivers for systems that follow that model.
Using the flow you insist on requires parsing the topology twice:
- once to find out whether there is actually a MSI provider registered
for the host bridge in order to set the no_msi flag
- once to actually be able to store the domain into the pci_bus
structure,
as it isn't available at probe time.
My last suggestion is to indicate to the core code that there is a
*possible*
MSI controller available in the form of a MSI domain. This is still
suboptimal
compared to checking the presence an MSI domain in core code (my initial
suggestion), but the fallback stuff gets in the way (though I still
think it
can be made to work).
Anyway, this was my last attempt at addressing the problem. Most people
won't see it. The couple of drivers that require the fallback hack are
usually selected in distro kernels, and do a good job hiding the error.
M.
--
Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Ryder Lee <ryder.lee@mediatek.com>,
Frank Wunderlich <frank-w@public-files.de>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Bjorn Helgaas <bhelgaas@google.com>,
linux-mediatek@lists.infradead.org,
Matthias Brugger <matthias.bgg@gmail.com>,
Frank Wunderlich <linux@fw-web.de>
Subject: Re: Aw: Re: Re: [PATCH] pci: mediatek: fix warning in msi.h
Date: Fri, 06 Nov 2020 09:43:58 +0000 [thread overview]
Message-ID: <c63d8d7d966c1dda82884f361d4691c3@kernel.org> (raw)
In-Reply-To: <87blgbl887.fsf@nanos.tec.linutronix.de>
On 2020-11-05 23:00, Thomas Gleixner wrote:
> On Thu, Nov 05 2020 at 09:20, Marc Zyngier wrote:
>> On 2020-11-04 23:14, Thomas Gleixner wrote:
>>> /* Resource alignment requirements */
>>> resource_size_t (*align_resource)(struct pci_dev *dev,
>>
>> If that's the direction of travel, we also need something like this
>> for configuration where the host bridge relies on an external MSI
>> block
>> that uses MSI domains (boot-tested in a GICv3 guest).
>
> Some more context would be helpful. Brain fails to decode the logic
> here.
OK, let me try again.
The MSI controller, which is the thing that deals with MSIs in the
system
(GICv2m, GICv3-ITS, and a number of others), is optional, is not part of
the
host bridge (it has nothing to do with PCI at all), and the bridge
driver has
absolutely no idea whether:
- there is something that provides MSI or not
- that something has successfully been initialised or not (which
translates
into an MSI domain being present or not)
This is the case for most ARM systems, and all KVM/arm guests. Booting a
VM
without MSIs is absolutely trivial, and actually makes sense for some of
the
smaller guests.
In these conditions, your no_msi attribute doesn't work as is: we can't
decide
on its value at probe time without extracting all of the OF/ACPI logic
that
deals with MSI domains from the core code, and making it available to
the host
bridge drivers for systems that follow that model.
Using the flow you insist on requires parsing the topology twice:
- once to find out whether there is actually a MSI provider registered
for the host bridge in order to set the no_msi flag
- once to actually be able to store the domain into the pci_bus
structure,
as it isn't available at probe time.
My last suggestion is to indicate to the core code that there is a
*possible*
MSI controller available in the form of a MSI domain. This is still
suboptimal
compared to checking the presence an MSI domain in core code (my initial
suggestion), but the fallback stuff gets in the way (though I still
think it
can be made to work).
Anyway, this was my last attempt at addressing the problem. Most people
won't see it. The couple of drivers that require the fallback hack are
usually selected in distro kernels, and do a good job hiding the error.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
next prev parent reply other threads:[~2020-11-06 9:44 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-31 14:03 [PATCH] pci: mediatek: fix warning in msi.h Frank Wunderlich
2020-10-31 14:03 ` Frank Wunderlich
2020-10-31 21:49 ` Thomas Gleixner
2020-10-31 21:49 ` Thomas Gleixner
2020-11-01 9:25 ` Frank Wunderlich
2020-11-01 9:25 ` Frank Wunderlich
2020-11-01 11:17 ` Thomas Gleixner
2020-11-01 11:17 ` Thomas Gleixner
2020-11-01 11:43 ` Marc Zyngier
2020-11-01 11:43 ` Marc Zyngier
2020-11-01 15:58 ` Aw: " Frank Wunderlich
2020-11-01 15:58 ` Frank Wunderlich
2020-11-01 17:54 ` Ryder Lee
2020-11-01 17:54 ` Ryder Lee
2020-11-01 18:27 ` Aw: " Frank Wunderlich
2020-11-01 18:27 ` Frank Wunderlich
2020-11-01 21:47 ` Marc Zyngier
2020-11-01 21:47 ` Marc Zyngier
2020-11-01 22:27 ` Thomas Gleixner
2020-11-01 22:27 ` Thomas Gleixner
2020-11-02 11:30 ` Marc Zyngier
2020-11-02 11:30 ` Marc Zyngier
2020-11-02 11:56 ` Aw: " Frank Wunderlich
2020-11-02 11:56 ` Frank Wunderlich
2020-11-02 13:58 ` Marc Zyngier
2020-11-02 13:58 ` Marc Zyngier
2020-11-02 14:27 ` Aw: " Frank Wunderlich
2020-11-02 14:27 ` Frank Wunderlich
2020-11-02 16:16 ` Aw: " Thomas Gleixner
2020-11-02 16:16 ` Thomas Gleixner
2020-11-02 22:18 ` Thomas Gleixner
2020-11-02 22:18 ` Thomas Gleixner
2020-11-03 9:54 ` Marc Zyngier
2020-11-03 9:54 ` Marc Zyngier
2020-11-03 10:16 ` Thomas Gleixner
2020-11-03 10:16 ` Thomas Gleixner
2020-11-03 10:29 ` Marc Zyngier
2020-11-03 10:29 ` Marc Zyngier
2020-11-04 16:49 ` Aw: " Frank Wunderlich
2020-11-04 16:49 ` Frank Wunderlich
2020-11-04 23:14 ` Thomas Gleixner
2020-11-04 23:14 ` Thomas Gleixner
2020-11-05 9:20 ` Marc Zyngier
2020-11-05 9:20 ` Marc Zyngier
2020-11-05 13:59 ` Aw: " Frank Wunderlich
2020-11-05 13:59 ` Frank Wunderlich
2020-11-05 23:00 ` Aw: " Thomas Gleixner
2020-11-05 23:00 ` Thomas Gleixner
2020-11-06 9:43 ` Marc Zyngier [this message]
2020-11-06 9:43 ` Marc Zyngier
2020-11-21 16:12 ` Aw: " Frank Wunderlich
2020-11-21 16:12 ` Frank Wunderlich
2021-01-03 13:08 ` Frank Wunderlich
2021-01-03 13:08 ` Frank Wunderlich
2021-02-02 16:21 ` Frank Wunderlich
2021-02-02 16:21 ` Frank Wunderlich
2020-11-03 10:31 ` Aw: " Thomas Gleixner
2020-11-03 10:31 ` Thomas Gleixner
2020-11-03 11:41 ` Marc Zyngier
2020-11-03 11:41 ` Marc Zyngier
2020-11-03 14:23 ` Thomas Gleixner
2020-11-03 14:23 ` Thomas Gleixner
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=c63d8d7d966c1dda82884f361d4691c3@kernel.org \
--to=maz@kernel.org \
--cc=bhelgaas@google.com \
--cc=frank-w@public-files.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@fw-web.de \
--cc=matthias.bgg@gmail.com \
--cc=ryder.lee@mediatek.com \
--cc=tglx@linutronix.de \
/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.