linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH v1 0/3] VMD add PCH rootbus support
@ 2024-10-25 15:01 Szymon Durawa
  2024-10-25 15:01 ` [RFC PATCH v1 1/3] PCI: vmd: Clean up vmd_enable_domain function Szymon Durawa
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Szymon Durawa @ 2024-10-25 15:01 UTC (permalink / raw)
  To: helgaas
  Cc: Szymon Durawa, Dan Williams, Lukas Wunner, linux-pci,
	Nirmal Patel, Mariusz Tkaczyk

This patch series implements the Intel VMD PCH rootbus support inside VMD
module. Current implementation allows VMD to take ownership of devices only on
IOC (Rootbus0). Starting from Intel Arrow Lake VMD exposes PCH rootbus to
allow VMD to own devices on PCH bus (Rootbus1) as well.

Patch 3 : WA for PCH bus enumeration. VMD PCH primary bus number is 0x80 and
          it is correct value. Unfortunately, pci_scan_bridge_extend() function
          assigns setup as broken for bus primary number different than zero.
          Until VMD was limited to IOC, rootbus primary was always set to 0 and
          therfore bus->number was irrelevant. With PCH rootbus primary bus is
          different than 0 (set to 0x80) and pci_scan_bridge_extend() code marks
          setup as broken and restarts enumeration.

I don't know whether pci_scan_bridge_extend() implementation is correct and
whether it can be safety reworked. I propse WA which does not impact on PCI
stack. It updates bus->number to the same number as primary bus value which
allows to pass check for sensible setup in pci_scan_bridge_extend().
From lspci tool perspective this WA is irrelevant:

# lspci -s 10000:80:1d.4 -v
10000:80:1d.4 PCI bridge: Intel Corporation Device 7f34 (rev 10) (prog-if 00 [Normal decode])
    Flags: bus master, fast devsel, latency 0, IRQ 213
    Bus: primary=80, secondary=f1, subordinate=f1, sec-latency=0

lspci tree presentation:
# lspci -tv
-+-[10000:e0]---01.0-[e2]----00.0  Sandisk Corp Western Digital WD Black SN850X NVMe SSD
 +-[10000:80]-+-1d.0  Intel Corporation RST VMD Managed Controller
 |            \-1d.4-[f1]----00.0  Sandisk Corp PC SN735 NVMe SSD (DRAM-less)
 +-[0000:80]-+-12.0  Intel Corporation Device 7f78
[...]
 |           +-1f.5  Intel Corporation Device 7f24
 |           \-1f.6  Intel Corporation Device 550d
 \-[0000:00]-+-00.0  Intel Corporation Device 7d1a
             +-01.0  Intel Corporation RST VMD Managed Controller

This workaround is a main reason it is send as RFC. To move this forward I need
to get maintainer decision whether it is acceptable or not. If not,
it would be great if you can take a look and propose a better solution.

Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: linux-pci@vger.kernel.org
Suggested-by: Nirmal Patel <nirmal.patel@linux.intel.com>
Reviewed-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
Signed-off-by: Szymon Durawa <szymon.durawa@linux.intel.com>

Szymon Durawa (3):
  PCI: vmd: Clean up vmd_enable_domain function
  PCI: vmd: Add VMD PCH rootbus support
  PCI: vmd: Add WA for VMD PCH rootbus support

 drivers/pci/controller/vmd.c | 446 +++++++++++++++++++++++++++--------
 1 file changed, 343 insertions(+), 103 deletions(-)
 mode change 100644 => 100755 drivers/pci/controller/vmd.c

-- 
2.39.3


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2024-10-28 21:53 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-10-25 15:01 [RFC PATCH v1 0/3] VMD add PCH rootbus support Szymon Durawa
2024-10-25 15:01 ` [RFC PATCH v1 1/3] PCI: vmd: Clean up vmd_enable_domain function Szymon Durawa
2024-10-28 21:27   ` Bjorn Helgaas
2024-10-25 15:01 ` [RFC PATCH v1 2/3] PCI: vmd: Add VMD PCH rootbus support Szymon Durawa
2024-10-28 21:50   ` Bjorn Helgaas
2024-10-25 15:01 ` [RFC PATCH v1 3/3] PCI: vmd: Add WA for " Szymon Durawa
2024-10-28 21:53   ` Bjorn Helgaas

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).