From: Marc Zyngier <firstname.lastname@example.org>
To: Gustavo Pimentel <Gustavo.Pimentel@synopsys.com>,
Alan Mikhak <email@example.com>
Cc: firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
Subject: Re: [PATCH] genirq/msi: Check null pointer before copying struct msi_msg
Date: Mon, 20 Apr 2020 10:14:33 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
On 2020-04-18 16:19, Gustavo Pimentel wrote:
> Hi Marc and Alan,
>> I'm not convinced by this. If you know that, by construction, these
>> interrupts are not associated with an underlying MSI, why calling
>> get_cached_msi_msg() the first place?
>> There seem to be some assumptions in the DW EDMA driver that the
>> signaling would be MSI based, so maybe someone from Synopsys
>> could clarify that. From my own perspective, running on an endpoint
>> device means that it is *generating* interrupts, and I'm not sure what
>> the MSIs represent here.
> Giving a little context to this topic.
> The eDMA IP present on the Synopsys DesignWare PCIe Endpoints can be
> configured and triggered *remotely* as well *locally*.
> For the sake of simplicity let's assume for now the eDMA was
> on the EP and that is the IP that we want to configure and use.
> When I say *remotely* I mean that this IP can be configurable through
> RC/CPU side, however, for that, it requires the eDMA registers to be
> exposed through a PCIe BAR on the EP. This will allow setting the SAR,
> DAR and other settings, also need(s) the interrupt(s) address(es) to be
> set as well (MSI or MSI-X only) so that it can signal through PCIe (to
> the RC and consecutively the associated EP driver) if the data transfer
> has been completed, aborted or if the Linked List consumer algorithm
> passed in some linked element marked with a watermark.
> It was based on this case that the eDMA driver was exclusively
> However, Alan, wants to expand a little more this, by being able to use
> this driver on the EP side (through
> pcitest/pci_endpoint_test/pci_epf_test) so that he can configure this
> In fact, when doing this, he doesn't need to configure the interrupt
> address (MSI or MSI-X), because this IP provides a local interrupt line
> so that be connected to other blocks on the EP side.
Right, so this confirms my hunch that the driver is being used in
a way that doesn't reflect the expected use case. Rather than
papering over the problem by hacking the core code, I'd rather see
the eDMA driver be updated to support both host and endpoint cases.
This probably boils down to a PCI vs non-PCI set of helpers.
Alan, could you confirm whether we got it right?
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2020-04-20 9:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-17 18:48 [PATCH] genirq/msi: Check null pointer before copying struct msi_msg Alan Mikhak
2020-04-18 11:21 ` Marc Zyngier
2020-04-18 15:19 ` Gustavo Pimentel
2020-04-20 9:14 ` Marc Zyngier [this message]
2020-04-20 16:08 ` Alan Mikhak
2020-04-20 19:20 ` Alan Mikhak
2020-04-21 8:39 ` Marc Zyngier
2020-04-21 23:44 ` Alan Mikhak
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).