From: Greg KH <gregkh@linuxfoundation.org>
To: Joshua Peraza <jperaza@google.com>
Cc: baolu.lu@linux.intel.com, bhelgaas@google.com, dtor@google.com,
dwmw2@infradead.org, helgaas@kernel.org,
iommu@lists.linux-foundation.org, jean-philippe@linaro.org,
joro@8bytes.org, jsbarnes@google.com, lenb@kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, mika.westerberg@linux.intel.com,
oohall@gmail.com, pavel@denx.de, rafael.j.wysocki@intel.com,
rafael@kernel.org, rajatja@google.com, rajatxjain@gmail.com,
will@kernel.org
Subject: Re: [v8 PATCH 0/2] PCI/ACPI: Support Microsoft's "DmaProperty"
Date: Thu, 20 Feb 2025 09:27:13 +0100 [thread overview]
Message-ID: <2025022053-circulate-pamphlet-a718@gregkh> (raw)
In-Reply-To: <CAFRSFxLF-i9Yvcf653-5gThV6PS_USqM3C5C8AaWrXuFaj8EZg@mail.gmail.com>
On Wed, Feb 19, 2025 at 01:53:48PM -0800, Joshua Peraza wrote:
> On Mon, Nov 18, 2024 at 11:43 AM Greg KH <gregkh@linuxfoundation.org> wrote:
Wow this is a slow discussion :)
> > On Mon, Nov 18, 2024 at 07:30:22PM +0000, Joshua Peraza wrote:
> > > This patchset rebases two previously posted patches supporting
> > > recognition of Microsoft's DmaProperty.
> > >
> > > v8: Joshua renames untrusted_dma to requires_dma_protection and updates
> > > some comments, reducing use of the word "trust" to refer to PCI devices
> > > and matching the word choice in Microsoft's documentation.
> >
> > So this is the "clarity"? I'm not sold, sorry. Again, did you look at
> > the previous discussions we had about this name? We don't have to use
> > Microsoft's term here as it is used differently by Linux today, right?
> > If you really want to support the DmaProperty, why not just support that
> > with a new bit as that's something different here, right?
> >
> > Again, look at what this is supposed to be conveying. They ability to
> > DMA to anywhere isn't really the root issue here, or is it? What is the
> > threat model you are trying to mitigate?
> >
> > > v7: Rajat updates a comment with Robin's suggestion. Joshua re-sends and
> > > Greg requests clarity and documentation on why untrusted_dma is the
> > > right name.
> > >
> > > v6: Rajat renames pci_dev_has_dma_property and links to Microsoft's
> > > documentation in the commit message. Robin suggests clarifying a
> > > comment.
> > >
> > > v5: Rajat changes the name to untrusted_dma. Bjorn suggesting changing
> > > another function's name pci_acpi_check_for_dma_protection to
> > > pci_dev_has_dma_property and seeks clarified documentation.
> > >
> > > v4: Rajat changes the name to poses_dma_risk. Christoph suggests this
> > > name doesn't capture the intent as well as untrusted_dma and Rafael
> > > agrees.
> > >
> > > v1,v2,v3: Greg suggests that (un)trusted is the wrong word for referring
> > > to PCI devices, recommending a name something like "platform wants to
> > > protect dma access for this device."
> >
> > Or is it? I said this when? Just how old is this patch series?
> >
> > confused,
> >
> > greg k-h
>
> (sorry if you're getting this again; re-sending as plain text)
>
> Sorry for the confusion! What do you think about the following for a
> new cover letter?
I really don't remember anymore, sorry. Try submitting the whole series
again as I don't know what you wrote the first time here.
thanks,
greg "I get 1000 emails a day" k-h
prev parent reply other threads:[~2025-02-20 8:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-18 19:30 [v8 PATCH 0/2] PCI/ACPI: Support Microsoft's "DmaProperty" Joshua Peraza
2024-11-18 19:30 ` [PATCH 1/2] " Joshua Peraza
2024-11-18 19:30 ` [PATCH 2/2] PCI: Rename pci_dev->untrusted to pci_dev->requires_dma_protection Joshua Peraza
2024-11-18 19:43 ` [v8 PATCH 0/2] PCI/ACPI: Support Microsoft's "DmaProperty" Greg KH
2025-02-19 21:53 ` Joshua Peraza
2025-02-20 8:27 ` Greg KH [this message]
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=2025022053-circulate-pamphlet-a718@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=baolu.lu@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=dtor@google.com \
--cc=dwmw2@infradead.org \
--cc=helgaas@kernel.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jean-philippe@linaro.org \
--cc=joro@8bytes.org \
--cc=jperaza@google.com \
--cc=jsbarnes@google.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=oohall@gmail.com \
--cc=pavel@denx.de \
--cc=rafael.j.wysocki@intel.com \
--cc=rafael@kernel.org \
--cc=rajatja@google.com \
--cc=rajatxjain@gmail.com \
--cc=will@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 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).