| Message ID | cover.1674468099.git.lukas@wunner.de |
|---|---|
| Headers | show |
| Series | Collection of DOE material | expand |
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
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
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.
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(-)