Re: [PATCH v7 2/9] PCI/IDE: Enumerate Selective Stream IDE capabilities

[Bjorn Helgaas <helgaas@kernel.org>]

On Fri, Oct 31, 2025 at 10:56:27AM +1100, Alexey Kardashevskiy wrote:
> On 31/10/25 08:37, Bjorn Helgaas wrote:
> > On Thu, Oct 30, 2025 at 11:59:30AM +1100, Alexey Kardashevskiy wrote:
> > > On 24/10/25 13:04, Dan Williams wrote:
> > > > Link encryption is a new PCIe feature enumerated by "PCIe r7.0 section
> > > > 7.9.26 IDE Extended Capability".
> > > ...
> > 
> > > > +#define PCI_IDE_CAP			0x04
> > > > +#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 */
> > > > +#define  PCI_IDE_CAP_SEL_CFG		0x80 /* Selective IDE for Config Request Support */
> > > > +#define  PCI_IDE_CAP_ALG		__GENMASK(12, 8) /* 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	__GENMASK(15, 13) /* Link IDE TCs */
> > > > +#define  PCI_IDE_CAP_SEL_NUM		__GENMASK(23, 16) /* Supported Selective IDE Streams */
> > > > +#define  PCI_IDE_CAP_TEE_LIMITED	0x1000000 /* TEE-Limited Stream Supported */
> > > 
> > > Since you are referring to PCIe r7.0 (instead of my proposal to use
> > > r6.1 ;) ), it has XT now here and in the stream control registers.
> > 
> > I haven't been following this, but is there an advantage to referring
> > to r6.1 instead of r7.0?  I assume newer revisions of the spec only
> > add useful things and don't remove anything.
> 
> We are adding here a bunch of macros for all the flags defined in
> the spec but we are not using many of them yet (or ever). And we are
> not adding the XT _support_ (which came in r7.0) right now, only the
> flags.
> 
> So what is the rule -
> 1) we add only bare minimum of the flags which we have the user for right now?
> 2) we add everything defined by the spec which the commit log refers to?
> 
> Right now it is neither but if the commit log said "r6.1" - then
> this patch is a complete set of flags.
>
> I do not care all that much, just noticed some inconsistency when I
> recently touched "lspci" so feel free to ignore the above :) Thanks,

I don't see a need to add #defines for things we don't use.

lspci is a little different because it should be able to decode
everything defined by the spec, whether somebody uses it or not.

My rule of thumb is to cite the most recent revision of the spec or
at least the most recent major version.  It's not as important as it
once was because the PCI-SIG has been trying hard not to change
section numbers in new revisions, but I don't really see the point of
citing an old revision unless there's something useful in it that
isn't in the current revision.