linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiaxun Yang <jiaxun.yang@flygoat.com>
To: Bjorn Helgaas <helgaas@kernel.org>, Huacai Chen <chenhuacai@gmail.com>
Cc: "Huacai Chen" <chenhuacai@loongson.cn>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	linux-pci <linux-pci@vger.kernel.org>,
	"Xuefeng Li" <lixuefeng@loongson.cn>
Subject: Re: [PATCH V13 3/6] PCI: loongson: Don't access unexisting devices
Date: Thu, 2 Jun 2022 21:00:54 +0100	[thread overview]
Message-ID: <22d1d8af-27b2-dce3-c832-8a95adf04b36@flygoat.com> (raw)
In-Reply-To: <20220602162324.GA21622@bhelgaas>


在 2022/6/2 17:23, Bjorn Helgaas 写道:
> On Thu, Jun 02, 2022 at 12:28:40PM +0800, Huacai Chen wrote:
>> Hi, Bjorn,
>>
>> On Wed, Jun 1, 2022 at 7:14 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
>>> On Sat, Apr 30, 2022 at 04:48:43PM +0800, Huacai Chen wrote:
>>>> On LS2K/LS7A, some unexisting devices don't return 0xffffffff when
>>>> scanning. This is a hardware flaw but we can only avoid it by software
>>>> now.
>>> What happens in other situations that normally cause Unsupported
>>> Request or similar errors?  For example, memory reads/writes to a
>>> device in D3hot should cause an Unsupported Request error.  I'm
>>> wondering whether other error handling assumptions might be broken
>>> on LS2K/LS7A.
>> Hardware engineers told me that the problem is due to pin
>> multiplexing, under some configurations, a PCI device is unusable but
>> the read request doesn't return 0xffffffff.
> What happens if a driver does a mem read to a device that's in D3hot?
Just did experiment on my hardware (which is a MIPS-era LS3A4000 with
LS7A).

It turns out that the hardware simply returns 0xffffffff for all reads and
ignore writes.

The PCIe controller of LS7A is a customized dwc and it should response
with a SLVERR transaction on LS7A's internalAXI bus. However the bus
we used to connect LS7A with CPU is incapable to pass this SLVERR
information to CPU and thus it just provides a false result.

All LS7A's on-chip devices connected on PCI bus don't expose any
PCI power management capability. Though they have power management
registers elsewhere  and generally we won't touch them when kernel
is running.

Thanks
- Jiaxun


  reply	other threads:[~2022-06-02 20:01 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-30  8:48 [PATCH V13 0/6] PCI: Loongson pci improvements and quirks Huacai Chen
2022-04-30  8:48 ` [PATCH V13 1/6] PCI: loongson: Use generic 8/16/32-bit config ops on LS2K/LS7A Huacai Chen
2022-06-01  2:08   ` Bjorn Helgaas
2022-06-02  4:18     ` Huacai Chen
2022-04-30  8:48 ` [PATCH V13 2/6] PCI: loongson: Add ACPI init support Huacai Chen
2022-05-31 23:04   ` Bjorn Helgaas
2022-06-02  7:09     ` Huacai Chen
2022-04-30  8:48 ` [PATCH V13 3/6] PCI: loongson: Don't access unexisting devices Huacai Chen
2022-05-31 23:14   ` Bjorn Helgaas
2022-06-02  4:28     ` Huacai Chen
2022-06-02 16:23       ` Bjorn Helgaas
2022-06-02 20:00         ` Jiaxun Yang [this message]
2022-04-30  8:48 ` [PATCH V13 4/6] PCI: loongson: Improve the MRRS quirk for LS7A Huacai Chen
2022-06-01  2:22   ` Bjorn Helgaas
2022-06-01 11:59     ` Jiaxun Yang
2022-06-02  4:17       ` Huacai Chen
2022-06-02 16:20       ` Bjorn Helgaas
2022-06-03 12:13         ` Krzysztof Hałasa
2022-06-03 22:57         ` Jiaxun Yang
2022-06-04  0:07           ` Bjorn Helgaas
2022-06-08  8:29             ` Huacai Chen
2022-04-30  8:48 ` [PATCH V13 5/6] PCI: Add quirk for LS7A to avoid reboot failure Huacai Chen
2022-05-31 23:35   ` Bjorn Helgaas
2022-06-02 12:48     ` Huacai Chen
2022-06-02 16:29       ` Bjorn Helgaas
2022-06-08  9:34         ` Huacai Chen
2022-06-08 19:31           ` Bjorn Helgaas
2022-06-16  8:39             ` Huacai Chen
2022-06-16 22:57               ` Bjorn Helgaas
2022-06-17  2:21                 ` Huacai Chen
2022-06-17 11:37                   ` Bjorn Helgaas
2022-06-17 12:14                     ` Huacai Chen
2022-04-30  8:48 ` [PATCH V13 6/6] PCI: Add quirk for multifunction devices of LS7A Huacai Chen
2022-06-01  2:07   ` Bjorn Helgaas
2022-06-01  7:36     ` Jianmin Lv

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=22d1d8af-27b2-dce3-c832-8a95adf04b36@flygoat.com \
    --to=jiaxun.yang@flygoat.com \
    --cc=bhelgaas@google.com \
    --cc=chenhuacai@gmail.com \
    --cc=chenhuacai@loongson.cn \
    --cc=helgaas@kernel.org \
    --cc=kw@linux.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lixuefeng@loongson.cn \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=robh@kernel.org \
    /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).