linux-toradex.git/drivers/pci/doe.c, branch v6.14-rc2

PCI/DOE: Poll DOE Busy bit for up to 1 second in pci_doe_send_req()

2024-10-13T15:55:39+00:00

During initial device probe, the PCI DOE busy bit for some CXL devices may
be left set for a longer period than expected by the current driver logic.
Despite local comments stating DOE Busy is unlikely to be detected, it
appears commonly specifically during boot when CXL devices are being
probed.

The symptom was messages like this:

  endpoint6: DOE failed -EBUSY

produced by cxl_cdat_get_length() or cxl_cdat_read_table().

This was observed on a single socket AMD platform with 2 CXL memory
expanders attached to the single socket. It was not the case that
concurrent accesses were being made, as validated by monitoring mailbox
commands on the device side.

This behavior has been observed with multiple CXL memory expanders from
different vendors - so it appears unrelated to the model.

In all observed tests, only a small period of the retry window is actually
used - typically only a handful of loop iterations.

Polling on the PCI DOE Busy Bit for (at max) one PCI DOE timeout interval
(1 second), resolves this issue cleanly.

Per PCIe r6.2 sec 6.30.3, the DOE Busy Bit being cleared does not raise an
interrupt, so polling is the best option in this scenario.

Subsequent code in doe_statemachine_work() and abort paths also wait for up
to 1 PCI DOE timeout interval, so this order of (potential) additional
delay is presumed acceptable.

Suggested-by: Lukas Wunner 
Link: https://lore.kernel.org/r/20241004162828.314-1-gourry@gourry.net
Signed-off-by: Gregory Price 
[bhelgaas: fix nits and add error message to commit log]
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Lukas Wunner 
Reviewed-by: Jonathan Cameron

PCI/DOE: Support discovery version 2

2024-04-09T14:33:15+00:00

PCIe r6.1, sec 6.30.1.1 defines a "DOE Discovery Version" field in
the DOE Discovery Request Data Object Contents (3rd DW) as:

15:8 DOE Discovery Version – must be 02h if the Capability Version in
the Data Object Exchange Extended Capability is 02h or greater.

Add support for the version on devices with the DOE v2 capability.

Link: https://lore.kernel.org/r/20240307022006.3657433-1-aik@amd.com
Signed-off-by: Alexey Kardashevskiy 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Kuppuswamy Sathyanarayanan

PCI/DOE: Fix destroy_work_on_stack() race

2023-07-27T20:20:47+00:00

The following debug object splat was observed in testing:

  ODEBUG: free active (active state 0) object: 0000000097d23782 object type: work_struct hint: doe_statemachine_work+0x0/0x510
  WARNING: CPU: 1 PID: 71 at lib/debugobjects.c:514 debug_print_object+0x7d/0xb0
  ...
  Workqueue: pci 0000:36:00.0 DOE [1 doe_statemachine_work
  RIP: 0010:debug_print_object+0x7d/0xb0
  ...
  Call Trace:
   ? debug_print_object+0x7d/0xb0
   ? __pfx_doe_statemachine_work+0x10/0x10
   debug_object_free.part.0+0x11b/0x150
   doe_statemachine_work+0x45e/0x510
   process_one_work+0x1d4/0x3c0

This occurs because destroy_work_on_stack() was called after signaling
the completion in the calling thread.  This creates a race between
destroy_work_on_stack() and the task->work struct going out of scope in
pci_doe().

Signal the work complete after destroying the work struct.  This is safe
because signal_task_complete() is the final thing the work item does and
the workqueue code is careful not to access the work struct after.

Fixes: abf04be0e707 ("PCI/DOE: Fix memory leak with CONFIG_DEBUG_OBJECTS=y")
Link: https://lore.kernel.org/r/20230726-doe-fix-v1-1-af07e614d4dd@intel.com
Signed-off-by: Ira Weiny 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Lukas Wunner 
Acked-by: Dan Williams

PCI/DOE: Relax restrictions on request and response size

2023-04-18T17:36:58+00:00

An upcoming user of DOE is CMA (Component Measurement and Authentication,
PCIe r6.0 sec 6.31).

It builds on SPDM (Security Protocol and Data Model):
https://www.dmtf.org/dsp/DSP0274

SPDM message sizes are not always a multiple of dwords.  To transport
them over DOE without using bounce buffers, allow sending requests and
receiving responses whose final dword is only partially populated.

To be clear, PCIe r6.0 sec 6.30.1 specifies the Data Object Header 2
"Length" in dwords and pci_doe_send_req() and pci_doe_recv_resp()
read/write dwords.  So from a spec point of view, DOE is still specified
in dwords and allowing non-dword request/response buffers is merely for
the convenience of callers.

Tested-by: Ira Weiny 
Signed-off-by: Lukas Wunner 
Reviewed-by: Ming Li 
Reviewed-by: Jonathan Cameron 
Acked-by: Bjorn Helgaas 
Link: https://lore.kernel.org/r/151b1a6a1794afb65d941287ecbc032c5b8004b9.1678543498.git.lukas@wunner.de
Signed-off-by: Dan Williams

PCI/DOE: Make mailbox creation API private

2023-04-18T17:36:58+00:00

The PCI core has just been amended to create a pci_doe_mb struct for
every DOE instance on device enumeration.  CXL (the only in-tree DOE
user so far) has been migrated to use those mailboxes instead of
creating its own.

That leaves pcim_doe_create_mb() and pci_doe_for_each_off() without any
callers, so drop them.

pci_doe_supports_prot() is now only used internally, so declare it
static.

pci_doe_destroy_mb() is no longer used as callback for
devm_add_action(), so refactor it to accept a struct pci_doe_mb pointer
instead of a generic void pointer.

Because pci_doe_create_mb() is only called on device enumeration, i.e.
before driver binding, the workqueue name never contains a driver name.
So replace dev_driver_string() with dev_bus_name() when generating the
workqueue name.

Tested-by: Ira Weiny 
Signed-off-by: Lukas Wunner 
Reviewed-by: Ming Li 
Reviewed-by: Ira Weiny 
Reviewed-by: Jonathan Cameron 
Acked-by: Bjorn Helgaas 
Link: https://lore.kernel.org/r/64f614b6584982986c55d2c6229b4ee2b276dd59.1678543498.git.lukas@wunner.de
Signed-off-by: Dan Williams

PCI/DOE: Create mailboxes on device enumeration

2023-04-18T17:36:58+00:00

Currently a DOE instance cannot be shared by multiple drivers because
each driver creates its own pci_doe_mb struct for a given DOE instance.
For the same reason a DOE instance cannot be shared between the PCI core
and a driver.

Moreover, finding out which protocols a DOE instance supports requires
creating a pci_doe_mb for it. If a device has multiple DOE instances,
a driver looking for a specific protocol may need to create a pci_doe_mb
for each of the device's DOE instances and then destroy those which
do not support the desired protocol. That's obviously an inefficient
way to do things.

Overcome these issues by creating mailboxes in the PCI core on device
enumeration.

Provide a pci_find_doe_mailbox() API call to allow drivers to get a
pci_doe_mb for a given (pci_dev, vendor, protocol) triple. This API is
modeled after pci_find_capability() and can later be amended with a
pci_find_next_doe_mailbox() call to iterate over all mailboxes of a
given pci_dev which support a specific protocol.

On removal, destroy the mailboxes in pci_destroy_dev(), after the driver
is unbound. This allows drivers to use DOE in their ->remove() hook.

On surprise removal, cancel ongoing DOE exchanges and prevent new ones
from being scheduled. Thereby ensure that a hot-removed device doesn't
needlessly wait for a running exchange to time out.

Tested-by: Ira Weiny
Signed-off-by: Lukas Wunner
Reviewed-by: Ming Li
Reviewed-by: Ira Weiny
Reviewed-by: Jonathan Cameron
Acked-by: Bjorn Helgaas
Link: https://lore.kernel.org/r/40a6f973f72ef283d79dd55e7e6fddc7481199af.1678543498.git.lukas@wunner.de
Signed-off-by: Dan Williams

PCI/DOE: Allow mailbox creation without devres management

2023-04-18T17:36:58+00:00

DOE mailbox creation is currently only possible through a devres-managed
API.  The lifetime of mailboxes thus ends with driver unbinding.

An upcoming commit will create DOE mailboxes upon device enumeration by
the PCI core.  Their lifetime shall not be limited by a driver.

Therefore rework pcim_doe_create_mb() into the non-devres-managed
pci_doe_create_mb().  Add pci_doe_destroy_mb() for mailbox destruction
on device removal.

Provide a devres-managed wrapper under the existing pcim_doe_create_mb()
name.

The error path of pcim_doe_create_mb() previously called xa_destroy() if
alloc_ordered_workqueue() failed.  That's unnecessary because the xarray
is still empty at that point.  It doesn't need to be destroyed until
it's been populated by pci_doe_cache_protocols().  Arrange the error
path of the new pci_doe_create_mb() accordingly.

pci_doe_cancel_tasks() is no longer used as callback for
devm_add_action(), so refactor it to accept a struct pci_doe_mb pointer
instead of a generic void pointer.

Tested-by: Ira Weiny 
Signed-off-by: Lukas Wunner 
Reviewed-by: Ming Li 
Reviewed-by: Jonathan Cameron 
Acked-by: Bjorn Helgaas 
Link: https://lore.kernel.org/r/7c9a63867d70233c5e9d26cd8bf956742cd6d650.1678543498.git.lukas@wunner.de
Signed-off-by: Dan Williams

PCI/DOE: Deduplicate mailbox flushing

2023-04-18T17:36:58+00:00

When a DOE mailbox is torn down, its workqueue is flushed once in
pci_doe_flush_mb() through a call to flush_workqueue() and subsequently
flushed once more in pci_doe_destroy_workqueue() through a call to
destroy_workqueue().

Deduplicate by dropping flush_workqueue() from pci_doe_flush_mb().

Rename pci_doe_flush_mb() to pci_doe_cancel_tasks() to more aptly
describe what it now does.

Tested-by: Ira Weiny 
Signed-off-by: Lukas Wunner 
Reviewed-by: Ming Li 
Reviewed-by: Jonathan Cameron 
Acked-by: Bjorn Helgaas 
Link: https://lore.kernel.org/r/1f009f60b326d1c6d776641d4b20aff27de0c234.1678543498.git.lukas@wunner.de
Signed-off-by: Dan Williams

PCI/DOE: Make asynchronous API private

2023-04-18T17:36:58+00:00

A synchronous API for DOE has just been introduced.  CXL (the only
in-tree DOE user so far) was converted to use it instead of the
asynchronous API.

Consequently, pci_doe_submit_task() as well as the pci_doe_task struct
are only used internally, so make them private.

Tested-by: Ira Weiny 
Signed-off-by: Lukas Wunner 
Reviewed-by: Ming Li 
Reviewed-by: Ira Weiny 
Reviewed-by: Jonathan Cameron 
Acked-by: Bjorn Helgaas 
Link: https://lore.kernel.org/r/cc19544068483681e91dfe27545c2180cd09f931.1678543498.git.lukas@wunner.de
Signed-off-by: Dan Williams

PCI/DOE: Provide synchronous API and use it internally

2023-04-18T17:36:58+00:00

The DOE API only allows asynchronous exchanges and forces callers to
provide a completion callback.  Yet all existing callers only perform
synchronous exchanges.  Upcoming commits for CMA (Component Measurement
and Authentication, PCIe r6.0 sec 6.31) likewise require only
synchronous DOE exchanges.

Provide a synchronous pci_doe() API call which builds on the internal
asynchronous machinery.

Convert the internal pci_doe_discovery() to the new call.

The new API allows submission of const-declared requests, necessitating
the addition of a const qualifier in struct pci_doe_task.

Tested-by: Ira Weiny 
Signed-off-by: Lukas Wunner 
Reviewed-by: Ming Li 
Reviewed-by: Ira Weiny 
Reviewed-by: Davidlohr Bueso 
Reviewed-by: Dan Williams 
Reviewed-by: Jonathan Cameron 
Acked-by: Bjorn Helgaas 
Link: https://lore.kernel.org/r/0f444206da9615c56301fbaff459c0f45d27f122.1678543498.git.lukas@wunner.de
Signed-off-by: Dan Williams