mbox series

[v2,00/10] Collection of DOE material

Message ID cover.1674468099.git.lukas@wunner.de (mailing list archive)
Headers show
Series Collection of DOE material | expand

Message

Lukas Wunner Jan. 23, 2023, 10:10 a.m. UTC
Collection of DOE material, v2:

* Fix WARN splat reported by Gregory Price
* Migrate to synchronous API
* Create DOE mailboxes in PCI core instead of in drivers
* No longer require request and response size to be multiple of 4 bytes

This is in preparation for CMA device authentication (PCIe r6.0, sec 6.31),
which performs DOE exchanges of irregular size and is going to be handled
in the PCI core.  The synchronous API reduces code size for DOE users.

Link to CMA development branch:
https://github.com/l1k/linux/commits/doe


Changes v1 -> v2:
* [PATCH v2 01/10] PCI/DOE: Silence WARN splat with CONFIG_DEBUG_OBJECTS=y 
  * Add note in kernel-doc of pci_doe_submit_task() that pci_doe_task must
    be allocated on the stack (Jonathan)
* [PATCH v2 05/10] PCI/DOE: Make asynchronous API private
  * Deduplicate note in kernel-doc of struct pci_doe_task that caller need
    not initialize certain fields (Jonathan)

Link to v1:
https://lore.kernel.org/linux-pci/cover.1669608950.git.lukas@wunner.de/


Lukas Wunner (10):
  PCI/DOE: Silence WARN splat with CONFIG_DEBUG_OBJECTS=y
  PCI/DOE: Fix memory leak with CONFIG_DEBUG_OBJECTS=y
  PCI/DOE: Provide synchronous API and use it internally
  cxl/pci: Use synchronous API for DOE
  PCI/DOE: Make asynchronous API private
  PCI/DOE: Allow mailbox creation without devres management
  PCI/DOE: Create mailboxes on device enumeration
  cxl/pci: Use CDAT DOE mailbox created by PCI core
  PCI/DOE: Make mailbox creation API private
  PCI/DOE: Relax restrictions on request and response size

 .clang-format           |   1 -
 drivers/cxl/core/pci.c  |  89 ++++--------
 drivers/cxl/cxlmem.h    |   3 -
 drivers/cxl/pci.c       |  49 -------
 drivers/pci/doe.c       | 315 ++++++++++++++++++++++++++++++----------
 drivers/pci/pci.h       |  10 ++
 drivers/pci/probe.c     |   1 +
 drivers/pci/remove.c    |   2 +
 include/linux/pci-doe.h |  62 +-------
 include/linux/pci.h     |   3 +
 10 files changed, 283 insertions(+), 252 deletions(-)

Comments

Bjorn Helgaas Jan. 23, 2023, 10:30 p.m. UTC | #1
On Mon, Jan 23, 2023 at 11:10:00AM +0100, Lukas Wunner wrote:
> Collection of DOE material, v2:
> 
> * Fix WARN splat reported by Gregory Price
> * Migrate to synchronous API
> * Create DOE mailboxes in PCI core instead of in drivers
> * No longer require request and response size to be multiple of 4 bytes
> 
> This is in preparation for CMA device authentication (PCIe r6.0, sec 6.31),
> which performs DOE exchanges of irregular size and is going to be handled
> in the PCI core.  The synchronous API reduces code size for DOE users.
> 
> Link to CMA development branch:
> https://github.com/l1k/linux/commits/doe
> 
> 
> Changes v1 -> v2:
> * [PATCH v2 01/10] PCI/DOE: Silence WARN splat with CONFIG_DEBUG_OBJECTS=y 
>   * Add note in kernel-doc of pci_doe_submit_task() that pci_doe_task must
>     be allocated on the stack (Jonathan)
> * [PATCH v2 05/10] PCI/DOE: Make asynchronous API private
>   * Deduplicate note in kernel-doc of struct pci_doe_task that caller need
>     not initialize certain fields (Jonathan)
> 
> Link to v1:
> https://lore.kernel.org/linux-pci/cover.1669608950.git.lukas@wunner.de/
> 
> 
> Lukas Wunner (10):
>   PCI/DOE: Silence WARN splat with CONFIG_DEBUG_OBJECTS=y
>   PCI/DOE: Fix memory leak with CONFIG_DEBUG_OBJECTS=y
>   PCI/DOE: Provide synchronous API and use it internally
>   cxl/pci: Use synchronous API for DOE
>   PCI/DOE: Make asynchronous API private
>   PCI/DOE: Allow mailbox creation without devres management
>   PCI/DOE: Create mailboxes on device enumeration
>   cxl/pci: Use CDAT DOE mailbox created by PCI core
>   PCI/DOE: Make mailbox creation API private
>   PCI/DOE: Relax restrictions on request and response size

Looks nice.  Do you envision getting acks from the CXL folks and
merging via the PCI tree, or the reverse?

Bjorn
Lukas Wunner Feb. 10, 2023, 9:39 p.m. UTC | #2
On Mon, Jan 23, 2023 at 04:30:53PM -0600, Bjorn Helgaas wrote:
> On Mon, Jan 23, 2023 at 11:10:00AM +0100, Lukas Wunner wrote:
> > Collection of DOE material, v2:
> 
> Do you envision getting acks from the CXL folks and
> merging via the PCI tree, or the reverse?

I do not have a strong preference myself.

I've just submitted v3 and based that on pci/next.

The patches apply equally well to cxl/next, save for a trivial conflict
in patch [13/16] due to a context change in drivers/cxl/cxlmem.h.
(I'm removing "struct xarray doe_mbs" and an adjacent new line was
added in cxl/next for "struct cxl_event_state event".)

I recognize that it might be too late to squeeze the full series into 6.3.
However, the first 6 patches are fixes tagged for stable, so at least
those should still be fine for 6.3.

I believe Dave Jiang is basing his in-kernel CDAT parsing on this series,
hence needs it merged during the next cycle.  So if you do not want to
apply the full series for 6.3, then the last 10 patches should probably
be picked up by Dan for 6.4 early during the next cycle in support of
Dave.

All of those ruminations are moot of couse if there are objections
requiring another respin.

Dan, what do you think?

Thanks,

Lukas
Dan Williams Feb. 11, 2023, 12:04 a.m. UTC | #3
Lukas Wunner wrote:
> On Mon, Jan 23, 2023 at 04:30:53PM -0600, Bjorn Helgaas wrote:
> > On Mon, Jan 23, 2023 at 11:10:00AM +0100, Lukas Wunner wrote:
> > > Collection of DOE material, v2:
> > 
> > Do you envision getting acks from the CXL folks and
> > merging via the PCI tree, or the reverse?
> 
> I do not have a strong preference myself.
> 
> I've just submitted v3 and based that on pci/next.
> 
> The patches apply equally well to cxl/next, save for a trivial conflict
> in patch [13/16] due to a context change in drivers/cxl/cxlmem.h.
> (I'm removing "struct xarray doe_mbs" and an adjacent new line was
> added in cxl/next for "struct cxl_event_state event".)
> 
> I recognize that it might be too late to squeeze the full series into 6.3.
> However, the first 6 patches are fixes tagged for stable, so at least
> those should still be fine for 6.3.
> 
> I believe Dave Jiang is basing his in-kernel CDAT parsing on this series,
> hence needs it merged during the next cycle.  So if you do not want to
> apply the full series for 6.3, then the last 10 patches should probably
> be picked up by Dan for 6.4 early during the next cycle in support of
> Dave.
> 
> All of those ruminations are moot of couse if there are objections
> requiring another respin.
> 
> Dan, what do you think?

I am ok for this to go through PCI. I will go review v3.