From: Marek Vasut <marek.vasut@gmail.com>
To: "Pali Rohár" <pali@kernel.org>
Cc: linux-pci@vger.kernel.org, "Arnd Bergmann" <arnd@arndb.de>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
"Wolfram Sang" <wsa@the-dreams.de>,
"Yoshihiro Shimoda" <yoshihiro.shimoda.uh@renesas.com>,
linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH v3 2/2] PCI: rcar: Return all Fs from read which triggered an exception
Date: Sun, 23 Jan 2022 17:31:28 +0100 [thread overview]
Message-ID: <7ced7370-1853-b52d-7e04-062d1bf3334c@gmail.com> (raw)
In-Reply-To: <20220123153147.sv6eoayxqvqbaa66@pali>
On 1/23/22 16:31, Pali Rohár wrote:
> On Saturday 22 January 2022 23:15:54 marek.vasut@gmail.com wrote:
>> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>>
>> In case the controller is transitioning to L1 in rcar_pcie_config_access(),
>> any read/write access to PCIECDR triggers asynchronous external abort. This
>> is because the transition to L1 link state must be manually finished by the
>> driver. The PCIe IP can transition back from L1 state to L0 on its own.
>
> Hello!
>
> I must admit that this patch from its initial version evolved into giant hack...
> https://lore.kernel.org/linux-pci/20210514200549.431275-1-marek.vasut@gmail.com/
>
> During review of the previous patch I have asked some important
> questions but I have not got any answer to them. So I'm reminding it:
> https://lore.kernel.org/linux-pci/20210805183024.ftdwknkttfwwogks@pali/
>
> So could please answer what happens when PCIe controller is in some
> non-L* state and either MMIO happen or config read happens or config
> write happens?
What kind of non-L state ?
Do you have some specific test which fails ?
This patch addresses the case where the link transition to L1 state has
to be completed manually. If the CPU accesses the config space before
that happened, you get an imprecise data abort.
> It is really important to know this fact.
>
> I'm in impression that this patch still is not enough as similar issues
> are also in other PCIe controllers which I know...
Do you have a suggestion for a patch which would be enough on this
hardware ?
next prev parent reply other threads:[~2022-01-23 16:31 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-22 22:15 [PATCH v3 1/2] PCI: rcar: Finish transition to L1 state in rcar_pcie_config_access() marek.vasut
2022-01-22 22:15 ` [PATCH v3 2/2] PCI: rcar: Return all Fs from read which triggered an exception marek.vasut
2022-01-23 14:12 ` Arnd Bergmann
2022-01-23 16:02 ` Marek Vasut
2022-01-23 15:31 ` Pali Rohár
2022-01-23 16:31 ` Marek Vasut [this message]
2022-01-23 16:49 ` Pali Rohár
2022-01-24 5:46 ` Marek Vasut
2022-01-24 9:37 ` Pali Rohár
2022-01-29 4:39 ` Marek Vasut
2022-01-31 12:53 ` Pali Rohár
2022-02-17 11:29 ` Pali Rohár
2022-02-17 12:59 ` Marek Vasut
2022-02-17 13:04 ` Pali Rohár
2022-02-18 1:53 ` Marek Vasut
2022-02-18 16:17 ` Pali Rohár
2022-01-23 15:39 ` Bjorn Helgaas
2022-01-28 2:47 ` kernel test robot
2022-02-16 11:50 ` Pali Rohár
2022-02-17 3:24 ` Marek Vasut
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=7ced7370-1853-b52d-7e04-062d1bf3334c@gmail.com \
--to=marek.vasut@gmail.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=geert+renesas@glider.be \
--cc=kw@linux.com \
--cc=linux-pci@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=pali@kernel.org \
--cc=wsa@the-dreams.de \
--cc=yoshihiro.shimoda.uh@renesas.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;
as well as URLs for NNTP newsgroup(s).