From: <dan.j.williams@intel.com>
To: Alexey Kardashevskiy <aik@amd.com>, Bjorn Helgaas <helgaas@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>,
<linux-coco@lists.linux.dev>, <linux-pci@vger.kernel.org>,
<yilun.xu@linux.intel.com>, <aneesh.kumar@kernel.org>,
<bhelgaas@google.com>, <gregkh@linuxfoundation.org>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>
Subject: Re: [PATCH v7 2/9] PCI/IDE: Enumerate Selective Stream IDE capabilities
Date: Thu, 30 Oct 2025 17:34:12 -0700 [thread overview]
Message-ID: <6904040413093_58c1910054@dwillia2-mobl4.notmuch> (raw)
In-Reply-To: <96cba9e4-ad1d-4823-b30b-f693c05824d4@amd.com>
Alexey Kardashevskiy wrote:
[..]
> > 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,
It is a good catch. If it were not for me trying to calm down the
changes on this base set so that we can call it "done" I would go add
the XT bits now.
In this case it is purely incremental with no near term user, so let it
arrive post base series.
next prev parent reply other threads:[~2025-10-31 0:34 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-24 2:04 [PATCH v7 0/9] PCI/TSM: Core infrastructure for PCI device security (TDISP) Dan Williams
2025-10-24 2:04 ` [PATCH v7 1/9] coco/tsm: Introduce a core device for TEE Security Managers Dan Williams
2025-10-29 13:33 ` Jonathan Cameron
2025-10-29 23:47 ` dan.j.williams
2025-10-30 1:00 ` Alexey Kardashevskiy
2025-10-30 9:04 ` Carlos López
2025-10-30 23:16 ` dan.j.williams
2025-10-24 2:04 ` [PATCH v7 2/9] PCI/IDE: Enumerate Selective Stream IDE capabilities Dan Williams
2025-10-29 13:42 ` Jonathan Cameron
2025-10-29 23:55 ` dan.j.williams
2025-10-30 0:59 ` Alexey Kardashevskiy
2025-10-30 21:13 ` dan.j.williams
2025-10-30 21:37 ` Bjorn Helgaas
2025-10-30 23:56 ` Alexey Kardashevskiy
2025-10-31 0:34 ` dan.j.williams [this message]
2025-10-31 1:20 ` Bjorn Helgaas
2025-10-30 8:34 ` Aneesh Kumar K.V
2025-10-24 2:04 ` [PATCH v7 3/9] PCI: Introduce pci_walk_bus_reverse(), for_each_pci_dev_reverse() Dan Williams
2025-10-29 14:00 ` Jonathan Cameron
2025-10-29 16:05 ` dan.j.williams
2025-10-30 19:36 ` dan.j.williams
2025-10-24 2:04 ` [PATCH v7 4/9] PCI/TSM: Establish Secure Sessions and Link Encryption Dan Williams
2025-10-26 3:18 ` kernel test robot
2025-10-29 15:53 ` Jonathan Cameron
2025-10-30 19:56 ` dan.j.williams
2025-10-30 1:13 ` Alexey Kardashevskiy
2025-10-30 8:35 ` Aneesh Kumar K.V
2025-10-24 2:04 ` [PATCH v7 5/9] PCI: Add PCIe Device 3 Extended Capability enumeration Dan Williams
2025-10-24 2:04 ` [PATCH v7 6/9] PCI: Establish document for PCI host bridge sysfs attributes Dan Williams
2025-10-29 16:04 ` Jonathan Cameron
2025-10-24 2:04 ` [PATCH v7 7/9] PCI/IDE: Add IDE establishment helpers Dan Williams
2025-10-25 16:53 ` Aneesh Kumar K.V
2025-10-29 18:57 ` dan.j.williams
2025-10-29 16:25 ` Jonathan Cameron
2025-10-24 2:04 ` [PATCH v7 8/9] PCI/IDE: Report available IDE streams Dan Williams
2025-10-29 16:31 ` Jonathan Cameron
2025-10-30 20:48 ` dan.j.williams
2025-10-24 2:04 ` [PATCH v7 9/9] PCI/TSM: Report active " Dan Williams
2025-10-29 16:34 ` Jonathan Cameron
2025-10-30 21:03 ` dan.j.williams
2025-10-30 2:05 ` Alexey Kardashevskiy
2025-10-27 10:01 ` [PATCH v7 0/9] PCI/TSM: Core infrastructure for PCI device security (TDISP) Aneesh Kumar K.V
2025-10-29 5:20 ` Alexey Kardashevskiy
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=6904040413093_58c1910054@dwillia2-mobl4.notmuch \
--to=dan.j.williams@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=aik@amd.com \
--cc=aneesh.kumar@kernel.org \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=helgaas@kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-pci@vger.kernel.org \
--cc=yilun.xu@linux.intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).