From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-pci@vger.kernel.org, netdev@vger.kernel.org,
Bjorn Helgaas <bhelgaas@google.com>,
Rob Herring <robh@kernel.org>,
Claudiu Manoil <claudiu.manoil@nxp.com>,
Michael Walle <michael@walle.cc>,
linux-kernel@vger.kernel.org, Liu Peibao <liupeibao@loongson.cn>,
Binbin Zhou <zhoubinbin@loongson.cn>,
Huacai Chen <chenhuacai@loongson.cn>
Subject: Re: [PATCH pci] PCI: don't skip probing entire device if first fn OF node has status = "disabled"
Date: Thu, 1 Jun 2023 11:11:56 +0300 [thread overview]
Message-ID: <20230601081156.zyymihd565fscuha@skbuf> (raw)
In-Reply-To: <ZHetDo5PozWdtrxP@bhelgaas>
On Wed, May 31, 2023 at 03:24:46PM -0500, Bjorn Helgaas wrote:
> I guess I should have asked "what bad things happen without this patch
> and without the DT 'disabled' status"?
Well, now that you put it this way, I do realize that things are not so
ideal for me.
Our drivers for the functions of this device were already checking for
of_device_is_available() during probe. So, reverting the core PCIe
patch, they would still not register a network interface, which is good.
However (and this is the bad part), multiple functions of this PCIe
device unfortunately share a common memory, which is not zeroized by
hardware, and so, to avoid multi-bit ECC errors, it must be zeroized by
software, using some memory space accesses from all functions that have
access to that shared memory (every function zeroizes its piece of it).
This, sadly, includes functions which have status = "disabled". See
commit 3222b5b613db ("net: enetc: initialize RFS/RSS memories for unused
ports too").
What we used to do was start probing a bit in enetc_pf_probe(), enable
the memory space, zeroize our part of the shared memory, then check
of_device_is_available() and finally, we disable the memory space again
and exit probing with -ENODEV.
That is not possible anymore with the core patch, because the PCIe core
will not probe our disabled functions at all anymore.
The ENETC is not a hot-pluggable PCIe device. It uses Enhanced Allocation
to essentially describe on-chip memory spaces, which are always present.
So presumably, a different system-level solution to initialize those
shared memories (U-Boot?) may be chosen, if implementing this workaround
in Linux puts too much pressure on the PCIe core and the way in which it
does things. Initially I didn't want to do this in prior boot stages
because we only enable the RCEC in Linux, nothing is broken other than
the spurious AER messages, and, you know.. the kernel may still run
indefinitely on top of bootloaders which don't have the workaround applied.
So working around it in Linux avoids one dependency.
next prev parent reply other threads:[~2023-06-01 8:12 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-21 11:51 [PATCH pci] PCI: don't skip probing entire device if first fn OF node has status = "disabled" Vladimir Oltean
2023-05-29 20:48 ` Vladimir Oltean
2023-05-30 21:58 ` Bjorn Helgaas
2023-05-30 22:04 ` Vladimir Oltean
2023-05-30 22:27 ` Bjorn Helgaas
2023-05-30 23:15 ` Vladimir Oltean
2023-05-31 16:56 ` Bjorn Helgaas
2023-05-31 16:58 ` Vladimir Oltean
2023-05-31 20:24 ` Bjorn Helgaas
2023-06-01 8:11 ` Vladimir Oltean [this message]
2023-06-01 15:44 ` Bjorn Helgaas
2023-06-01 16:33 ` Vladimir Oltean
2023-06-01 17:51 ` Bjorn Helgaas
2023-06-01 22:15 ` Vladimir Oltean
2023-06-02 4:06 ` 陈华才
2023-06-02 7:21 ` Liu Peibao
2023-06-02 7:36 ` Jianmin Lv
2023-06-02 10:16 ` Vladimir Oltean
2023-06-03 2:35 ` Jianmin Lv
2023-06-04 8:55 ` Vladimir Oltean
2023-06-05 0:59 ` Jianmin Lv
2023-06-05 9:34 ` Vladimir Oltean
2023-06-16 2:12 ` Jianmin Lv
2023-06-16 17:57 ` Rob Herring
2023-08-03 10:39 ` Vladimir Oltean
2023-08-03 11:34 ` Vladimir Oltean
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=20230601081156.zyymihd565fscuha@skbuf \
--to=vladimir.oltean@nxp.com \
--cc=bhelgaas@google.com \
--cc=chenhuacai@loongson.cn \
--cc=claudiu.manoil@nxp.com \
--cc=helgaas@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=liupeibao@loongson.cn \
--cc=michael@walle.cc \
--cc=netdev@vger.kernel.org \
--cc=robh@kernel.org \
--cc=zhoubinbin@loongson.cn \
/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