From: Dan Williams <dan.j.williams@intel.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Dan Williams <dan.j.williams@intel.com>
Cc: <linux-coco@lists.linux.dev>, Alexey Kardashevskiy <aik@amd.com>,
<linux-pci@vger.kernel.org>, <gregkh@linuxfoundation.org>
Subject: Re: [PATCH 04/11] PCI/IDE: Selective Stream IDE enumeration
Date: Tue, 25 Feb 2025 16:21:58 -0800 [thread overview]
Message-ID: <67be5ea65e96c_1a7729453@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <20250130104507.00004446@huawei.com>
Jonathan Cameron wrote:
> On Thu, 05 Dec 2024 14:23:39 -0800
> Dan Williams <dan.j.williams@intel.com> wrote:
>
> > Link encryption is a new PCIe capability defined by "PCIe 6.2 section
> > 6.33 Integrity & Data Encryption (IDE)". While it is a standalone port
> > and endpoint capability, it is also a building block for device security
> > defined by "PCIe 6.2 section 11 TEE Device Interface Security Protocol
> > (TDISP)". That protocol coordinates device security setup between the
> > platform TSM (TEE Security Manager) and device DSM (Device Security
> > Manager). While the platform TSM can allocate resources like stream-ids
> > and manage keys, it still requires system software to manage the IDE
> > capability register block.
> >
> > Add register definitions and basic enumeration for a "selective-stream"
> > IDE capability, a follow on change will select the new CONFIG_PCI_IDE
> > symbol. Note that while the IDE specifications defines both a
> > point-to-point "Link" stream and a root-port-to-endpoint "Selective"
> > stream, only "Selective" is considered for now for platform TSM
> > coordination.
> >
> > Co-developed-by: Alexey Kardashevskiy <aik@amd.com>
> > Signed-off-by: Alexey Kardashevskiy <aik@amd.com>
> > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> Some overlap in here with other reviews probably...
>
> Jonathan
>
> > ---
> > drivers/pci/Kconfig | 3 +
> > drivers/pci/Makefile | 1
> > drivers/pci/ide.c | 73 ++++++++++++++++++++++++++++++++++++
> > drivers/pci/pci.h | 6 +++
> > drivers/pci/probe.c | 1
> > include/linux/pci.h | 5 ++
> > include/uapi/linux/pci_regs.h | 84 +++++++++++++++++++++++++++++++++++++++++
> > 7 files changed, 172 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/pci/ide.c
> >
[..]
> > diff --git a/drivers/pci/ide.c b/drivers/pci/ide.c
> > new file mode 100644
> > index 000000000000..a0c09d9e0b75
> > --- /dev/null
> > +++ b/drivers/pci/ide.c
> > @@ -0,0 +1,73 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/* Copyright(c) 2024 Intel Corporation. All rights reserved. */
> > +
> > +/* PCIe 6.2 section 6.33 Integrity & Data Encryption (IDE) */
> > +
> > +#define dev_fmt(fmt) "PCI/IDE: " fmt
> > +#include <linux/pci.h>
> > +#include "pci.h"
> > +
> > +static int sel_ide_offset(u16 cap, int stream_id, int nr_ide_mem)
> > +{
> > + return cap + stream_id * PCI_IDE_SELECTIVE_BLOCK_SIZE(nr_ide_mem);
>
> I'd be tempted to have a define to go from base of the IDE extended cap
> directly to the sel_ide_offset rather than this use of a block based
> offset. Maybe it ends up too complex though.
Considering other feedback below, I will make this change.
> > +}
> > +
> > +void pci_ide_init(struct pci_dev *pdev)
> > +{
> > + u16 ide_cap, sel_ide_cap;
> > + int nr_ide_mem = 0;
> > + u32 val = 0;
> > +
> > + if (!pci_is_pcie(pdev))
> > + return;
> > +
> > + ide_cap = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_IDE);
> > + if (!ide_cap)
> > + return;
> > +
> > + /*
> > + * Check for selective stream capability from endpoint to root-port, and
> > + * require consistent number of address association blocks
>
> on the EP.
> (for avoidance of confusion).
>
> Also, from here just seems to mean at the RP and the EP. Not seting a bus
> walk here to check anything else. Note I'm not sure we need to but this
> comment is implying a 'from/to' aspect that this code doesn't seem to check.
The from/to aspect is that the ide_cap of endpoints is ignored if the
device's root-port does not have IDE capability.
I will move the comment next to the "if (!rp->ide_cap)" check to make
this clearer.
> > + */
> > + pci_read_config_dword(pdev, ide_cap + PCI_IDE_CAP, &val);
> > + if ((val & PCI_IDE_CAP_SELECTIVE) == 0)
> > + return;
> > +
> > + if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ENDPOINT) {
> > + struct pci_dev *rp = pcie_find_root_port(pdev);
> > +
> > + if (!rp->ide_cap)
> > + return;
> > + }
> > +
> > + if (val & PCI_IDE_CAP_LINK)
> > + sel_ide_cap = ide_cap + PCI_IDE_LINK_STREAM +
> > + (PCI_IDE_CAP_LINK_TC_NUM(val) + 1) *
> > + PCI_IDE_LINK_BLOCK_SIZE;
> > + else
> > + sel_ide_cap = ide_cap + PCI_IDE_LINK_STREAM;
> Maybe cleaner as
> int link_tc_count = 0;
> if (val & PCI_IDE_CAP_LINK)
> //see suggestion in header to make macro include +1.
> link_tc_count = PCI_IDE_CAP_LINK_TC_NUM(val) + 1;
>
> sel_ide_cap = ide_cap + PCI_IDE_LINK_STREAM +
> link_tc_count * PCI_IDE_LINK_BLOCK_SIZE;
> I'm not that bothered either way. Just didn't like that
> ide_cap + PIC_IDE_LINK_STREAM is in both legs.
Makes sense, fixed.
> Or have a macro that always gets you to the selective part without
> using a zero length PCI_IDE_LINK_STREAM block.
Unless it gets multiple use I would open code it in ide.c.
> > +
> > + for (int i = 0; i < PCI_IDE_CAP_SELECTIVE_STREAMS_NUM(val); i++) {
> > + if (i == 0) {
> > + pci_read_config_dword(pdev, sel_ide_cap, &val);
> > + nr_ide_mem = PCI_IDE_SEL_CAP_ASSOC_NUM(val);
>
> Yank out and index from 1 for the loop?
> Note though that PCI_IDE_CAP_SELECTIVE_STREAMS_NUM(val) of 1
> means 2 streams so you want <= or just +1 in the macro so the PCI
> header gets to deal with that!
In other review feedback the discussion settled on only shipping offset + masks
in include/uapi/linux/pci_regs.h [1], and put any other logic related to
bitfield.h in ide.c.
[1]: http://lore.kernel.org/67b91d86a48aa_1c530f29431@dwillia2-xfh.jf.intel.com.notmuch
[..]
> > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > index db9b47ce3eef..50811b7655dd 100644
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -530,6 +530,11 @@ struct pci_dev {
> > #endif
> > #ifdef CONFIG_PCI_NPEM
> > struct npem *npem; /* Native PCIe Enclosure Management */
> > +#endif
> > +#ifdef CONFIG_PCI_IDE
> > + u16 ide_cap; /* Link Integrity & Data Encryption */
> > + u16 sel_ide_cap; /* - Selective Stream register block */
>
> I'd not call it cap as people will go looking for a selective IDE extended capability.
> I'm a little dubious about it being necessary vs a helper function that grabs
> the necessary count info directly from the device.
I was trying to avoid extra config cycles in the common case, but there
is no precedent for caching extra offsets in 'struct pci_dev'.
I am ok to drop sel_ide_cap.
>
> > + int nr_ide_mem; /* - Address range limits for streams */
> > #endif
> > u16 acs_cap; /* ACS Capability offset */
> > u8 supported_speeds; /* Supported Link Speeds Vector */
> > diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> > index 1601c7ed5fab..9635b27d2485 100644
> > --- a/include/uapi/linux/pci_regs.h
> > +++ b/include/uapi/linux/pci_regs.h
> > @@ -748,7 +748,8 @@
> > #define PCI_EXT_CAP_ID_NPEM 0x29 /* Native PCIe Enclosure Management */
> > #define PCI_EXT_CAP_ID_PL_32GT 0x2A /* Physical Layer 32.0 GT/s */
> > #define PCI_EXT_CAP_ID_DOE 0x2E /* Data Object Exchange */
> > -#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_DOE
> > +#define PCI_EXT_CAP_ID_IDE 0x30 /* Integrity and Data Encryption */
> > +#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_IDE
> >
> > #define PCI_EXT_CAP_DSN_SIZEOF 12
> > #define PCI_EXT_CAP_MCAST_ENDPOINT_SIZEOF 40
> > @@ -1213,4 +1214,85 @@
> > #define PCI_DVSEC_CXL_PORT_CTL 0x0c
> > #define PCI_DVSEC_CXL_PORT_CTL_UNMASK_SBR 0x00000001
> >
> > +/* Integrity and Data Encryption Extended Capability */
> > +#define PCI_IDE_CAP 0x4
> > +#define PCI_IDE_CAP_LINK 0x1 /* Link IDE Stream Supported */
> > +#define PCI_IDE_CAP_SELECTIVE 0x2 /* Selective IDE Streams Supported */
> > +#define PCI_IDE_CAP_FLOWTHROUGH 0x4 /* Flow-Through IDE Stream Supported */
> > +#define PCI_IDE_CAP_PARTIAL_HEADER_ENC 0x8 /* Partial Header Encryption Supported */
> > +#define PCI_IDE_CAP_AGGREGATION 0x10 /* Aggregation Supported */
> > +#define PCI_IDE_CAP_PCRC 0x20 /* PCRC Supported */
> > +#define PCI_IDE_CAP_IDE_KM 0x40 /* IDE_KM Protocol Supported */
>
> Looks like 3.2 has a bit 7 defined as well. Selective IDE for configuration requests supported.
> Probably worth adding that.
Might as well.
>
> > +#define PCI_IDE_CAP_ALG(x) (((x) >> 8) & 0x1f) /* Supported Algorithms */
> > +#define PCI_IDE_CAP_ALG_AES_GCM_256 0 /* AES-GCM 256 key size, 96b MAC */
> > +#define PCI_IDE_CAP_LINK_TC_NUM(x) (((x) >> 13) & 0x7) /* Link IDE TCs */
> Maybe add 1 here as the macro name kind of implies it is returning the number of link IDE TCs
> rather than 1 less that that. It is a little tricky given the spec calls this field "Number of"
>
> > +#define PCI_IDE_CAP_SELECTIVE_STREAMS_NUM(x) (((x) >> 16) & 0xff) /* Selective IDE Streams */
>
> Similar here. I'm not sure what precedence we have int his file. I can't immediately see any
> either way.
>
> > +#define PCI_IDE_CAP_SELECTIVE_STREAMS_MASK 0xff0000
> Why have the mask if you are providing the macro above to get the value?
A mix of copying from the SEV-TIO vs TDX Connect RFCs. Per other
feedback, I have now resolved to only defines masks and offsets and drop
the decorated helpers that are open coding bitmask.h.
It turns out that __GENMASK is available in uapi/linux/bits.h, so I will
switch to that.
> > +#define PCI_IDE_CAP_TEE_LIMITED 0x1000000 /* TEE-Limited Stream Supported */
> > +#define PCI_IDE_CTL 0x8
> > +#define PCI_IDE_CTL_FLOWTHROUGH_IDE 0x4 /* Flow-Through IDE Stream Enabled */
> > +#define PCI_IDE_LINK_STREAM 0xc
> I couldn't find specific precedence for this but my gut would say add a _0 postfix
> to indicate it's the first of a number of these.
> All the similar cases seem to explicitly enumerate _0, _1 etc which makes little
> sense here.
>
> > +#define PCI_IDE_LINK_BLOCK_SIZE 8
> > +/* Link IDE Stream block, up to PCI_IDE_CAP_LINK_TC_NUM */
> > +/* Link IDE Stream Control Register */
> I'd expect a _0 define for the first ctrl and one for the first status.
>
> Then index each register via
> PCI_IDE_LINK_CTL_0 + i * PCIE_IDE_LINK_BLOCK_SIZE
> PCI_IDE_LINK_STS_0 + i * PCIE_IDE_LINK_BLOCK_SIZE
>
> Again, not immediately seeing precedence, but having register field defines without
> a register address define (even a constructed one as will be relevant
> for the selective IDE stream blocks) seems odd to me.
I will add the _0, but skip the rest for now. There is no precedence I
can see for the amount of degrees of freedom in this IDE register block for
the location of the selective registers, and Linux does not currently
have a use case for Link IDE. I imagine any Link Register Block walking
will live in ide.c. I.e. given Selective Stream block offset calculation
lives in ide.c might as well do the same for Link IDE when/if needed.
>
> > +#define PCI_IDE_LINK_CTL_EN 0x1 /* Link IDE Stream Enable */
> > +#define PCI_IDE_LINK_CTL_TX_AGGR_NPR(x) (((x) >> 2) & 0x3) /* Tx Aggregation Mode NPR */
> > +#define PCI_IDE_LINK_CTL_TX_AGGR_PR(x) (((x) >> 4) & 0x3) /* Tx Aggregation Mode PR */
> > +#define PCI_IDE_LINK_CTL_TX_AGGR_CPL(x) (((x) >> 6) & 0x3) /* Tx Aggregation Mode CPL */
> > +#define PCI_IDE_LINK_CTL_PCRC_EN 0x100 /* PCRC Enable */
> > +#define PCI_IDE_LINK_CTL_PART_ENC(x) (((x) >> 10) & 0xf) /* Partial Header Encryption Mode */
> > +#define PCI_IDE_LINK_CTL_ALG(x) (((x) >> 14) & 0x1f) /* Selected Algorithm */
> Perhaps nice to throw in a reference to the supported algs list above.
Ok
>
> > +#define PCI_IDE_LINK_CTL_TC(x) (((x) >> 19) & 0x7) /* Traffic Class */
> > +#define PCI_IDE_LINK_CTL_ID(x) (((x) >> 24) & 0xff) /* Stream ID */
> > +#define PCI_IDE_LINK_CTL_ID_MASK 0xff000000
> > +
> > +
> > +/* Link IDE Stream Status Register */
> > +#define PCI_IDE_LINK_STS_STATUS(x) ((x) & 0xf) /* Link IDE Stream State */
> > +#define PCI_IDE_LINK_STS_RECVD_INTEGRITY_CHECK 0x80000000 /* Received Integrity Check Fail Msg */
>
>
> I'd put some white space here.
Ok
>
> > +/* Selective IDE Stream block, up to PCI_IDE_CAP_SELECTIVE_STREAMS_NUM */
> > +#define PCI_IDE_SELECTIVE_BLOCK_SIZE(x) (20 + 12 * (x))
>
> Probably want a better name than 'x' for that parameter as it's not
> immediately obvious what it is. (number of IDE address association
> register blocks).
> Also that 12 probably wants a define. It's used a few times.
Ok
>
> > +/* Selective IDE Stream Capability Register */
> > +#define PCI_IDE_SEL_CAP 0
> > +#define PCI_IDE_SEL_CAP_ASSOC_NUM(x) ((x) & 0xf) /* Address Association Register Blocks Number */
> > +#define PCI_IDE_SEL_CAP_ASSOC_MASK 0xf
>
> If the mask make sense to keep at all would be good to build
> the macro above using it.
Dropped the macro, kept the mask.
>
> > +/* Selective IDE Stream Control Register */
> > +#define PCI_IDE_SEL_CTL 4
> > +#define PCI_IDE_SEL_CTL_EN 0x1 /* Selective IDE Stream Enable */
> > +#define PCI_IDE_SEL_CTL_TX_AGGR_NPR(x) (((x) >> 2) & 0x3) /* Tx Aggregation Mode NPR */
> > +#define PCI_IDE_SEL_CTL_TX_AGGR_PR(x) (((x) >> 4) & 0x3) /* Tx Aggregation Mode PR */
> > +#define PCI_IDE_SEL_CTL_TX_AGGR_CPL(x) (((x) >> 6) & 0x3) /* Tx Aggregation Mode CPL */
> > +#define PCI_IDE_SEL_CTL_PCRC_EN 0x100 /* PCRC Enable */
> > +#define PCI_IDE_SEL_CTL_CFG_EN 0x200 /* Selective IDE for Configuration Requests */
> > +#define PCI_IDE_SEL_CTL_PART_ENC(x) (((x) >> 10) & 0xf) /* Partial Header Encryption Mode */
> This is a control register. Seems likely we'll mostly be writing these.
> So how useful is it to provide just a read macro?
> Maybe I'm missing something!
I agree and this matches other feedback prompting the "masks only"
stance.
> > +#define PCI_IDE_SEL_CTL_ALG(x) (((x) >> 14) & 0x1f) /* Selected Algorithm */
> > +#define PCI_IDE_SEL_CTL_TC(x) (((x) >> 19) & 0x7) /* Traffic Class */
> > +#define PCI_IDE_SEL_CTL_DEFAULT 0x400000 /* Default Stream */
> > +#define PCI_IDE_SEL_CTL_TEE_LIMITED (1 << 23) /* TEE-Limited Stream */
>
> Why this one as a shift and all the rest as explicit hex values?
Fixed.
>
> > +#define PCI_IDE_SEL_CTL_ID_MASK 0xff000000
> > +#define PCI_IDE_SEL_CTL_ID_MAX 255
> > +/* Selective IDE Stream Status Register */
> > +#define PCI_IDE_SEL_STS 8
> > +#define PCI_IDE_SEL_STS_STATUS(x) ((x) & 0xf) /* Selective IDE Stream State */
> > +#define PCI_IDE_SEL_STS_RECVD_INTEGRITY_CHECK 0x80000000 /* Received Integrity Check Fail Msg */
> > +/* IDE RID Association Register 1 */
> > +#define PCI_IDE_SEL_RID_1 12
> > +#define PCI_IDE_SEL_RID_1_LIMIT_MASK 0xffff00
> > +/* IDE RID Association Register 2 */
> > +#define PCI_IDE_SEL_RID_2 16
> > +#define PCI_IDE_SEL_RID_2_VALID 0x1
> > +#define PCI_IDE_SEL_RID_2_BASE_MASK 0x00ffff00
>
> Why leading zeros on this one?
Fixed.
>
> > +#define PCI_IDE_SEL_RID_2_SEG_MASK 0xff000000
> > +/* Selective IDE Address Association Register Block, up to PCI_IDE_SEL_CAP_ASSOC_NUM */
> > +#define PCI_IDE_SEL_ADDR_1(x) (20 + (x) * 12)
> > +#define PCI_IDE_SEL_ADDR_1_VALID 0x1
> > +#define PCI_IDE_SEL_ADDR_1_BASE_LOW_MASK 0x000fff0
>
> more leading zeros which doesn't seem consistent. Also, as Alexey
> pointed out value is wrong as that's 4 bits in not 8.
>
>
> > +#define PCI_IDE_SEL_ADDR_1_BASE_LOW_SHIFT 20
> 8?
This was defining how much to shift the lower 32-bits of an address to
feed this value. Moved all that detail to ide.c
>
> > +#define PCI_IDE_SEL_ADDR_1_LIMIT_LOW_MASK 0xfff0000
> > +#define PCI_IDE_SEL_ADDR_1_LIMIT_LOW_SHIFT 20
> Also missing a zero (Alexey got this one as well I see)
Got it, thanks for going through all that!
next prev parent reply other threads:[~2025-02-26 0:22 UTC|newest]
Thread overview: 125+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-05 22:23 [PATCH 00/11] PCI/TSM: Core infrastructure for PCI device security (TDISP) Dan Williams
2024-12-05 22:23 ` [PATCH 01/11] configfs-tsm: Namespace TSM report symbols Dan Williams
2024-12-10 6:08 ` Alexey Kardashevskiy
2024-12-11 13:55 ` Suzuki K Poulose
2024-12-05 22:23 ` [PATCH 02/11] coco/guest: Move shared guest CC infrastructure to drivers/virt/coco/guest/ Dan Williams
2024-12-10 6:09 ` Alexey Kardashevskiy
2024-12-05 22:23 ` [PATCH 03/11] coco/tsm: Introduce a class device for TEE Security Managers Dan Williams
2025-01-28 12:17 ` Jonathan Cameron
2025-02-25 21:08 ` Dan Williams
2024-12-05 22:23 ` [PATCH 04/11] PCI/IDE: Selective Stream IDE enumeration Dan Williams
2024-12-10 3:08 ` Aneesh Kumar K.V
2024-12-12 6:32 ` Xu Yilun
2025-02-22 0:42 ` Dan Williams
2025-02-20 3:17 ` Dan Williams
2024-12-10 6:18 ` Alexey Kardashevskiy
2025-02-20 3:59 ` Dan Williams
2024-12-10 7:05 ` Alexey Kardashevskiy
2024-12-12 6:06 ` Xu Yilun
2024-12-18 10:35 ` Alexey Kardashevskiy
2025-02-22 0:30 ` Dan Williams
2025-02-20 18:07 ` Dan Williams
2025-02-21 0:53 ` Alexey Kardashevskiy
2025-02-27 23:46 ` Dan Williams
2024-12-10 19:24 ` Bjorn Helgaas
2025-02-22 0:13 ` Dan Williams
2025-01-30 10:45 ` Jonathan Cameron
2025-02-26 0:21 ` Dan Williams [this message]
2024-12-05 22:23 ` [PATCH 05/11] PCI/TSM: Authenticate devices via platform TSM Dan Williams
2024-12-10 10:18 ` Alexey Kardashevskiy
2025-02-21 8:13 ` Aneesh Kumar K.V
2025-02-25 7:17 ` Xu Yilun
2025-02-26 12:10 ` Aneesh Kumar K.V
2025-02-26 12:13 ` [RFC PATCH 1/7] tsm: Select PCI_DOE which is required for PCI_TSM Aneesh Kumar K.V (Arm)
2025-02-26 12:13 ` [RFC PATCH 2/7] tsm: Move tsm core outside the host directory Aneesh Kumar K.V (Arm)
2025-02-26 12:13 ` [RFC PATCH 3/7] tsm: vfio: Add tsm bind/unbind support Aneesh Kumar K.V (Arm)
2025-02-26 12:13 ` [RFC PATCH 4/7] tsm: Allow tsm ops function to be called for multi-function devices Aneesh Kumar K.V (Arm)
2025-02-26 12:13 ` [RFC PATCH 5/7] tsm: Don't error out for doe mailbox failure Aneesh Kumar K.V (Arm)
2025-02-26 12:13 ` [RFC PATCH 6/7] tsm: Allow tsm connect ops to be used for multiple operations Aneesh Kumar K.V (Arm)
2025-02-26 12:13 ` [RFC PATCH 7/7] tsm: Add secure SPDM support Aneesh Kumar K.V (Arm)
2025-02-27 6:50 ` Xu Yilun
2025-02-27 6:35 ` [PATCH 05/11] PCI/TSM: Authenticate devices via platform TSM Xu Yilun
2025-02-27 13:57 ` Aneesh Kumar K.V
2025-02-28 1:26 ` Xu Yilun
2025-02-28 9:48 ` Aneesh Kumar K.V
2025-03-01 7:50 ` Xu Yilun
2025-03-07 3:07 ` Alexey Kardashevskiy
2025-02-27 19:53 ` Dan Williams
2025-02-28 10:06 ` Aneesh Kumar K.V
2025-02-21 20:42 ` Dan Williams
2025-02-25 4:45 ` Alexey Kardashevskiy
2025-02-28 3:09 ` Dan Williams
2024-12-10 18:52 ` Bjorn Helgaas
2025-02-21 22:32 ` Dan Williams
2024-12-12 9:50 ` Xu Yilun
2025-02-22 1:15 ` Dan Williams
2025-02-24 11:02 ` Xu Yilun
2025-02-28 0:15 ` Dan Williams
2025-02-28 9:39 ` Xu Yilun
2025-01-30 11:45 ` Jonathan Cameron
2025-02-26 0:50 ` Dan Williams
2024-12-05 22:23 ` [PATCH 06/11] samples/devsec: PCI device-security bus / endpoint sample Dan Williams
2024-12-06 4:23 ` kernel test robot
2024-12-09 3:40 ` kernel test robot
2025-01-30 13:21 ` Jonathan Cameron
2025-02-26 2:00 ` Dan Williams
2024-12-05 22:23 ` [PATCH 07/11] PCI: Add PCIe Device 3 Extended Capability enumeration Dan Williams
2024-12-09 13:17 ` Ilpo Järvinen
2025-02-20 3:05 ` Dan Williams
2025-02-20 3:09 ` Dan Williams
2024-12-10 19:21 ` Bjorn Helgaas
2024-12-11 13:22 ` Ilpo Järvinen
2025-02-22 0:15 ` Dan Williams
2025-02-24 15:09 ` Ilpo Järvinen
2025-02-28 0:29 ` Dan Williams
2025-02-21 23:34 ` Dan Williams
2025-02-25 2:25 ` Alexey Kardashevskiy
2024-12-05 22:24 ` [PATCH 08/11] PCI/IDE: Add IDE establishment helpers Dan Williams
2024-12-10 3:19 ` Aneesh Kumar K.V
2024-12-10 3:37 ` Aneesh Kumar K.V
2025-02-20 3:39 ` Dan Williams
2025-02-21 15:53 ` Aneesh Kumar K.V
2025-02-25 0:46 ` Dan Williams
2025-01-07 20:19 ` Xu Yilun
2025-01-10 13:25 ` Aneesh Kumar K.V
2025-02-24 22:31 ` Dan Williams
2025-02-25 2:29 ` Alexey Kardashevskiy
2025-02-20 3:28 ` Dan Williams
2024-12-10 7:07 ` Alexey Kardashevskiy
2025-02-20 21:44 ` Dan Williams
2024-12-10 18:47 ` Bjorn Helgaas
2025-02-21 22:02 ` Dan Williams
2024-12-12 10:50 ` Xu Yilun
2024-12-19 7:25 ` Alexey Kardashevskiy
2024-12-19 10:05 ` Alexey Kardashevskiy
2025-01-07 20:00 ` Xu Yilun
2025-01-09 2:35 ` Alexey Kardashevskiy
2025-01-09 21:28 ` Xu Yilun
2025-01-15 0:20 ` Alexey Kardashevskiy
2025-02-25 0:06 ` Dan Williams
2025-02-25 3:39 ` Alexey Kardashevskiy
2025-02-28 2:26 ` Dan Williams
2025-03-04 0:03 ` Alexey Kardashevskiy
2025-03-04 0:57 ` Dan Williams
2025-03-04 1:31 ` Alexey Kardashevskiy
2025-03-04 17:59 ` Dan Williams
2025-02-20 4:19 ` Alexey Kardashevskiy
2025-02-24 22:24 ` Dan Williams
2025-02-25 2:45 ` Xu Yilun
2025-02-24 20:28 ` Dan Williams
2025-02-26 1:54 ` Alexey Kardashevskiy
2025-02-24 20:24 ` Dan Williams
2025-02-25 5:01 ` Xu Yilun
2024-12-05 22:24 ` [PATCH 09/11] PCI/IDE: Report available IDE streams Dan Williams
2024-12-06 0:12 ` kernel test robot
2024-12-06 0:43 ` kernel test robot
2025-02-11 6:10 ` Alexey Kardashevskiy
2025-02-27 23:35 ` Dan Williams
2024-12-05 22:24 ` [PATCH 10/11] PCI/TSM: Report active " Dan Williams
2024-12-10 18:49 ` Bjorn Helgaas
2025-02-21 22:28 ` Dan Williams
2024-12-05 22:24 ` [PATCH 11/11] samples/devsec: Add sample IDE establishment Dan Williams
2025-01-30 13:39 ` Jonathan Cameron
2025-02-27 23:27 ` Dan Williams
2024-12-06 6:05 ` [PATCH 00/11] PCI/TSM: Core infrastructure for PCI device security (TDISP) Greg KH
2024-12-06 8:44 ` Dan Williams
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=67be5ea65e96c_1a7729453@dwillia2-xfh.jf.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=aik@amd.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-pci@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.