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 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.