On Thu, Jul 07, 2022 at 06:58:40AM +0200, Christoph Hellwig wrote:
> On Wed, Jun 29, 2022 at 08:41:32AM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Jun 29, 2022 at 08:28:37AM +0200, Christoph Hellwig wrote:
> > > Any comments or additional testing? It would be really great to
On Wed, Jul 06, 2022 at 08:51:27AM +0200, Christoph Hellwig wrote:
> On Tue, Jul 05, 2022 at 12:16:45PM -0600, Logan Gunthorpe wrote:
> > The current version does it through a char device, but that requires
> > creating a simple_fs and anon_inode for teardown on driver removal, plus
> > a bunch of
On Tue, Jul 05, 2022 at 11:32:23AM -0600, Logan Gunthorpe wrote:
>
>
> On 2022-07-05 11:21, Greg Kroah-Hartman wrote:
> > On Tue, Jul 05, 2022 at 06:50:39PM +0200, Christoph Hellwig wrote:
> >> [note for the newcomers, this is about allowing mmap()ing the PCIe
> >
On Tue, Jul 05, 2022 at 06:50:39PM +0200, Christoph Hellwig wrote:
> [note for the newcomers, this is about allowing mmap()ing the PCIe
> P2P memory from the generic PCI P2P code through sysfs, and more
> importantly how to revoke it on device removal]
We allow mmap on PCIe config space today,
On Wed, Jun 29, 2022 at 08:28:37AM +0200, Christoph Hellwig wrote:
> Any comments or additional testing? It would be really great to get
> this off the table.
For the USB bits:
Acked-by: Greg Kroah-Hartman
___
iommu mailing list
iommu@lists
On Wed, Jun 22, 2022 at 04:14:45PM +0800, Zhangfei Gao wrote:
> Hi, Greg
>
> On 2022/6/21 下午3:44, Greg Kroah-Hartman wrote:
> > On Tue, Jun 21, 2022 at 03:37:31PM +0800, Zhangfei Gao wrote:
> > >
> > > On 2022/6/20 下午9:36, Greg Kroah-Hartman wrote:
> >
On Tue, Jun 21, 2022 at 03:37:31PM +0800, Zhangfei Gao wrote:
>
>
> On 2022/6/20 下午9:36, Greg Kroah-Hartman wrote:
> > On Mon, Jun 20, 2022 at 02:24:31PM +0100, Jean-Philippe Brucker wrote:
> > > On Fri, Jun 17, 2022 at 02:05:21PM +0800, Zhangfei Gao wrote:
> > &
On Mon, Jun 20, 2022 at 02:24:31PM +0100, Jean-Philippe Brucker wrote:
> >From c7c2b051ec19285bbb973f8a2a5e58bb5326e00e Mon Sep 17 00:00:00 2001
> From: Jean-Philippe Brucker
> Date: Mon, 20 Jun 2022 10:10:41 +0100
> Subject: [PATCH] uacce: Tidy up locking
>
> The uacce driver must deal with a
On Mon, Jun 20, 2022 at 02:24:31PM +0100, Jean-Philippe Brucker wrote:
> On Fri, Jun 17, 2022 at 02:05:21PM +0800, Zhangfei Gao wrote:
> > > The refcount only ensures that the uacce_device object is not freed as
> > > long as there are open fds. But uacce_remove() can run while there are
> > >
On Mon, Jun 06, 2022 at 10:41:03AM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The virt_to_bus/bus_to_virt interface has been deprecated for
> decades. After Jakub Kicinski put a lot of work into cleaning out the
> network drivers using them, there are only a couple of other drivers
>
From: Randy Dunlap
[ Upstream commit 80e4390981618e290616dbd06ea190d4576f219d ]
When valid kernel command line parameters
dma_debug=off dma_debug_entries=100
are used, they are reported as Unknown parameters and added to init's
environment strings, polluting it.
Unknown kernel command line
From: Randy Dunlap
[ Upstream commit 80e4390981618e290616dbd06ea190d4576f219d ]
When valid kernel command line parameters
dma_debug=off dma_debug_entries=100
are used, they are reported as Unknown parameters and added to init's
environment strings, polluting it.
Unknown kernel command line
From: Randy Dunlap
[ Upstream commit 80e4390981618e290616dbd06ea190d4576f219d ]
When valid kernel command line parameters
dma_debug=off dma_debug_entries=100
are used, they are reported as Unknown parameters and added to init's
environment strings, polluting it.
Unknown kernel command line
From: Randy Dunlap
[ Upstream commit 80e4390981618e290616dbd06ea190d4576f219d ]
When valid kernel command line parameters
dma_debug=off dma_debug_entries=100
are used, they are reported as Unknown parameters and added to init's
environment strings, polluting it.
Unknown kernel command line
From: Randy Dunlap
[ Upstream commit 80e4390981618e290616dbd06ea190d4576f219d ]
When valid kernel command line parameters
dma_debug=off dma_debug_entries=100
are used, they are reported as Unknown parameters and added to init's
environment strings, polluting it.
Unknown kernel command line
From: Randy Dunlap
[ Upstream commit 80e4390981618e290616dbd06ea190d4576f219d ]
When valid kernel command line parameters
dma_debug=off dma_debug_entries=100
are used, they are reported as Unknown parameters and added to init's
environment strings, polluting it.
Unknown kernel command line
On Tue, Feb 15, 2022 at 09:46:24PM +0100, Helge Deller wrote:
> On 2/14/22 07:08, Yong Wu wrote:
> > Use the common compare helper from component.
> >
> > Cc: Helge Deller
> > Cc: linux-o...@vger.kernel.org
> > Cc: linux-fb...@vger.kernel.org
> > Signed-off-by: Yong Wu
>
> Applied to the fbdev
On Wed, Feb 23, 2022 at 05:05:23PM +, Robin Murphy wrote:
> On 2022-02-23 16:03, Greg Kroah-Hartman wrote:
> > On Wed, Feb 23, 2022 at 10:30:11AM -0400, Jason Gunthorpe wrote:
> > > On Wed, Feb 23, 2022 at 10:09:01AM -0400, Jason Gunthorpe wrote:
> > > > On W
On Wed, Feb 23, 2022 at 10:30:11AM -0400, Jason Gunthorpe wrote:
> On Wed, Feb 23, 2022 at 10:09:01AM -0400, Jason Gunthorpe wrote:
> > On Wed, Feb 23, 2022 at 03:06:35PM +0100, Greg Kroah-Hartman wrote:
> > > On Wed, Feb 23, 2022 at 09:46:27AM -0400, Jason Gunthorpe wrote:
>
On Wed, Feb 23, 2022 at 09:46:27AM -0400, Jason Gunthorpe wrote:
> On Wed, Feb 23, 2022 at 01:04:00PM +, Robin Murphy wrote:
>
> > 1 - tmp->driver is non-NULL because tmp is already bound.
> > 1.a - If tmp->driver->driver_managed_dma == 0, the group must currently be
> > DMA-API-owned as a
assumption that the drivers know what they are
> doing with the device DMA.
>
> With the IOMMU layer knowing DMA ownership of each device, above problem
> can be solved.
>
> Cc: Greg Kroah-Hartman
> Cc: Bjorn Helgaas
> Cc: Stuart Yoder
> Cc: Laurentiu Tudor
> Signed
On Mon, Feb 14, 2022 at 09:11:17AM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 14, 2022 at 01:51:06PM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Feb 14, 2022 at 08:38:42AM -0400, Jason Gunthorpe wrote:
> > > On Mon, Feb 14, 2022 at 11:03:42AM +0100, Greg Kroah-Hartman wrote:
&
On Mon, Feb 14, 2022 at 09:18:53AM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 14, 2022 at 10:59:50AM +0100, Greg Kroah-Hartman wrote:
>
> > > + if (ret && !drv->no_kernel_api_dma)
> > > + iommu_device_unuse_dma_api(dev);
> >
> > So yo
On Mon, Feb 14, 2022 at 08:38:42AM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 14, 2022 at 11:03:42AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 04, 2022 at 09:56:37AM +0800, Lu Baolu wrote:
> > > Multiple PCI devices may be placed in the same IOMMU group because
On Tue, Jan 04, 2022 at 09:56:37AM +0800, Lu Baolu wrote:
> Multiple PCI devices may be placed in the same IOMMU group because
> they cannot be isolated from each other. These devices must either be
> entirely under kernel control or userspace control, never a mixture. This
> checks and sets DMA
rocess and fail on ownership conflicts. The DMA ownership
> should be released during driver unbinding.
>
> Signed-off-by: Lu Baolu
Reviewed-by: Greg Kroah-Hartman
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Tue, Jan 04, 2022 at 09:56:34AM +0800, Lu Baolu wrote:
> Multiple platform devices may be placed in the same IOMMU group because
> they cannot be isolated from each other. These devices must either be
> entirely under kernel control or userspace control, never a mixture. This
> checks and sets
On Tue, Jan 04, 2022 at 02:08:36AM -0800, Christoph Hellwig wrote:
> All these bus callouts still looks horrible and just create tons of
> boilerplate code.
I can't remember anymore what one vs. the other looks like. Having an
explicit "opt-in" for a bus is good, in that no code breaks and only
On Tue, Feb 08, 2022 at 01:55:29PM +0800, Lu Baolu wrote:
> Hi Greg,
>
> On 1/4/22 9:04 PM, Greg Kroah-Hartman wrote:
> > On Tue, Jan 04, 2022 at 08:39:11AM -0400, Jason Gunthorpe wrote:
> > > On Tue, Jan 04, 2022 at 02:08:36AM -0800, Christoph Hellwig wrote:
> > &g
: Kishon Vijay Abraham I
> Cc: Linus Walleij
> Cc: "Rafael J. Wysocki"
> Cc: Kevin Hilman
> Cc: Ulf Hansson
> Cc: Sebastian Reichel
> Cc: Mark Brown
> Cc: Mathieu Poirier
> Cc: Daniel Lezcano
> Cc: Zhang Rui
> Cc: Greg Kroah-Hartman
> Cc:
On Tue, Jan 04, 2022 at 08:39:11AM -0400, Jason Gunthorpe wrote:
> On Tue, Jan 04, 2022 at 02:08:36AM -0800, Christoph Hellwig wrote:
> > All these bus callouts still looks horrible and just create tons of
> > boilerplate code.
>
> Yes, Lu - Greg asked questions then didn't respond to their
On Thu, Dec 23, 2021 at 11:02:54AM +0800, Lu Baolu wrote:
> Hi Greg,
>
> On 12/22/21 8:47 PM, Greg Kroah-Hartman wrote:
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static void device_dma_cleanup(struct device *dev, struct dev
On Fri, Dec 17, 2021 at 02:36:57PM +0800, Lu Baolu wrote:
> This extends really_probe() to allow checking for dma ownership conflict
> during the driver binding process. By default, the DMA_OWNER_DMA_API is
> claimed for the bound driver before calling its .probe() callback. If this
> operation
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
errupts.
>
> Remove the MSI[-X] teardown from pcim_release() and add an explicit action
> to be installed on the attempt of enabling PCI/MSI[-X].
>
> This allows the MSI core data allocation to be ordered correctly in a
> subsequent step.
>
> Reported-by: Nishanth Men
On Fri, Dec 10, 2021 at 11:18:47PM +0100, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> instead of fiddling with MSI descriptors.
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
___
iommu mailing list
io
On Mon, Dec 06, 2021 at 11:39:25PM +0100, Thomas Gleixner wrote:
> Add a properties field which allows core code to store information for easy
> retrieval in order to replace MSI descriptor fiddling.
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Greg K
On Mon, Dec 06, 2021 at 11:39:41PM +0100, Thomas Gleixner wrote:
> Use msi_get_vector() and handle the return value to be compatible.
>
> No functional change intended.
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
__
On Mon, Dec 06, 2021 at 11:39:26PM +0100, Thomas Gleixner wrote:
> Store the properties which are interesting for various places so the MSI
> descriptor fiddling can be removed.
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Greg K
On Mon, Dec 06, 2021 at 11:39:33PM +0100, Thomas Gleixner wrote:
> instead of fiddling with MSI descriptors.
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
___
iommu mailing list
iommu@lists.linux-foundation.
On Mon, Dec 06, 2021 at 11:39:37PM +0100, Thomas Gleixner wrote:
> Set the domain info flag and remove the check.
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
___
iommu mailing list
iommu@lists.linux-foundation.
given MSI index.
>
> Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Mon, Dec 06, 2021 at 06:13:01AM -0800, Christoph Hellwig wrote:
> On Mon, Dec 06, 2021 at 08:53:07AM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Dec 06, 2021 at 09:58:48AM +0800, Lu Baolu wrote:
> > > The platform_dma_configure() is shared between platform and amba bus
>
On Mon, Dec 06, 2021 at 09:58:49AM +0800, Lu Baolu wrote:
> Multiple platform devices may be placed in the same IOMMU group because
> they cannot be isolated from each other. These devices must either be
> entirely under kernel control or userspace control, never a mixture. This
> checks and sets
On Mon, Dec 06, 2021 at 09:58:48AM +0800, Lu Baolu wrote:
> The platform_dma_configure() is shared between platform and amba bus
> drivers. Rename the common helper to firmware_dma_configure() so that
> both platform and amba bus drivers could customize their dma_configure
> callbacks.
Please, if
On Thu, Dec 02, 2021 at 09:55:02AM -0400, Jason Gunthorpe wrote:
> Further, there is no reason why IMS should be reserved exclusively for
> VFIO! Why shouldn't the cdev be able to use IMS vectors too? It is
> just a feature of the PCI device like MSI. If the queue has a PASID it
> can use IDXD's
On Sun, Nov 28, 2021 at 07:15:09PM -0400, Jason Gunthorpe wrote:
> On Sun, Nov 28, 2021 at 09:10:14AM +0100, Greg Kroah-Hartman wrote:
> > On Sun, Nov 28, 2021 at 10:50:38AM +0800, Lu Baolu wrote:
> > > Multiple platform devices may be placed in the same IOMMU group because
On Sun, Nov 28, 2021 at 10:50:34AM +0800, Lu Baolu wrote:
> The original post and intent of this series is here.
> https://lore.kernel.org/linux-iommu/2025020552.2378167-1-baolu...@linux.intel.com/
Please put the intent in the message, dont make us go and dig it up
again.
thanks,
greg k-h
On Sun, Nov 28, 2021 at 10:50:38AM +0800, Lu Baolu wrote:
> Multiple platform devices may be placed in the same IOMMU group because
> they cannot be isolated from each other. These devices must either be
> entirely under kernel control or userspace control, never a mixture. This
> checks and sets
On Sun, Nov 28, 2021 at 10:50:36AM +0800, Lu Baolu wrote:
> The bus_type structure defines dma_configure() callback for bus drivers
> to configure DMA on the devices. This adds the paired dma_unconfigure()
> callback and calls it during driver unbinding so that bus drivers can do
> some cleanup
include/linux/device.h |2 --
> 3 files changed, 1 insertion(+), 4 deletions(-)
Reviewed-by: Greg Kroah-Hartman
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
c
> parts are going to be removed from struct device in later steps.
>
> Signed-off-by: Thomas Gleixner
> Cc: Greg Kroah-Hartman
> Cc: Will Deacon
> Cc: Santosh Shilimkar
> Cc: iommu@lists.linux-foundation.org
> Cc: dmaeng...@vger.kernel.org
> ---
> drivers/bas
t;
> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git
> msi-v1-part-1
>
> and also available from git:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git
> msi-v1-part-2
>
Instead of respo
t;
> Signed-off-by: Thomas Gleixner
> ---
> include/linux/device.h |5 +
> include/linux/msi.h| 12 +++-
> kernel/irq/msi.c | 33 +
> 3 files changed, 49 insertions(+), 1 deletion(-)
R
On Mon, Nov 15, 2021 at 10:05:43AM +0800, Lu Baolu wrote:
> This extends really_probe() to allow checking for dma ownership conflict
> during the driver binding process. By default, the DMA_OWNER_KERNEL is
> claimed for the bound driver before calling its .probe() callback. If this
> operation
On Wed, Jul 21, 2021 at 10:24:01AM -0700, John Stultz wrote:
> On Wed, Jul 21, 2021 at 4:54 AM Greg Kroah-Hartman
> wrote:
> >
> > On Wed, Jul 07, 2021 at 04:53:20AM +, John Stultz wrote:
> > > Allow the qcom_scm driver to be loadable as a permenent modu
On Wed, Jul 07, 2021 at 04:53:20AM +, John Stultz wrote:
> Allow the qcom_scm driver to be loadable as a permenent module.
This feels like a regression, it should be allowed to be a module.
> This still uses the "depends on QCOM_SCM || !QCOM_SCM" bit to
> ensure that drivers that call into
tems' and 'maxItems' are equal to the 'items' length.
> An improved meta-schema is pending.
>
> Cc: Stephen Boyd
> Cc: Joerg Roedel
> Cc: Will Deacon
> Cc: Krzysztof Kozlowski
> Cc: Miquel Raynal
> Cc: Richard Weinberger
> Cc: Vignesh Raghavendra
> Cc: Alessandro Zu
From: Alexander Monakov
[ Upstream commit 4b21a503adf597773e4b37db05db0e9b16a81d53 ]
print_iommu_info prints the EFR register and then the decoded list of
features on a separate line:
pci :00:00.2: AMD-Vi: Extended features (0x206d73ef22254ade):
PPR X2APIC NX GT IA GA PC GA_vAPIC
The
From: Alexander Monakov
[ Upstream commit 4b21a503adf597773e4b37db05db0e9b16a81d53 ]
print_iommu_info prints the EFR register and then the decoded list of
features on a separate line:
pci :00:00.2: AMD-Vi: Extended features (0x206d73ef22254ade):
PPR X2APIC NX GT IA GA PC GA_vAPIC
The
From: Alexander Monakov
[ Upstream commit 4b21a503adf597773e4b37db05db0e9b16a81d53 ]
print_iommu_info prints the EFR register and then the decoded list of
features on a separate line:
pci :00:00.2: AMD-Vi: Extended features (0x206d73ef22254ade):
PPR X2APIC NX GT IA GA PC GA_vAPIC
The
Cc: Bjorn Helgaas
> Cc: Kishon Vijay Abraham I
> Cc: Linus Walleij
> Cc: "Uwe Kleine-König"
> Cc: Lee Jones
> Cc: Ohad Ben-Cohen
> Cc: Mathieu Poirier
> Cc: Philipp Zabel
> Cc: Paul Walmsley
> Cc: Palmer Dabbelt
> Cc: Albert Ou
> Cc: Alessandro Zum
Cc: Kalle Valo
> Cc: Maulik Shah
> Cc: Lina Iyer
> Cc: Saravana Kannan
> Cc: Todd Kjos
> Cc: Greg Kroah-Hartman
> Cc: linux-arm-...@vger.kernel.org
> Cc: iommu@lists.linux-foundation.org
> Cc: linux-g...@vger.kernel.org
> Acked-by: Kalle Valo
> Acked-by: Gr
Marc Zyngier
> Cc: Linus Walleij
> Cc: Maulik Shah
> Cc: Lina Iyer
> Cc: Saravana Kannan
> Cc: Todd Kjos
> Cc: Greg Kroah-Hartman
> Cc: linux-arm-...@vger.kernel.org
> Cc: iommu@lists.linux-foundation.org
> Cc: linux-g...@vger.kernel.org
> Signed-off-
From: Paul Menzel
[ Upstream commit 304c73ba69459d4c18c2a4b843be6f5777b4b85c ]
Currently, on the Dell OptiPlex 5055 the EFR mismatch warning looks like
below.
[1.479774] smpboot: CPU0: AMD Ryzen 5 PRO 1500 Quad-Core Processor
(family: 0x17, model: 0x1, stepping: 0x1)
[…]
[
From: Paul Menzel
[ Upstream commit 304c73ba69459d4c18c2a4b843be6f5777b4b85c ]
Currently, on the Dell OptiPlex 5055 the EFR mismatch warning looks like
below.
[1.479774] smpboot: CPU0: AMD Ryzen 5 PRO 1500 Quad-Core Processor
(family: 0x17, model: 0x1, stepping: 0x1)
[…]
[
From: Paul Menzel
[ Upstream commit 304c73ba69459d4c18c2a4b843be6f5777b4b85c ]
Currently, on the Dell OptiPlex 5055 the EFR mismatch warning looks like
below.
[1.479774] smpboot: CPU0: AMD Ryzen 5 PRO 1500 Quad-Core Processor
(family: 0x17, model: 0x1, stepping: 0x1)
[…]
[
On Tue, Feb 09, 2021 at 01:28:47PM +0530, Sumit Garg wrote:
> Thanks Greg for your response.
>
> On Tue, 9 Feb 2021 at 12:28, Greg Kroah-Hartman
> wrote:
> >
> > On Tue, Feb 09, 2021 at 11:39:25AM +0530, Sumit Garg wrote:
> > > Hi Christoph, Greg,
>
On Tue, Feb 09, 2021 at 11:39:25AM +0530, Sumit Garg wrote:
> Hi Christoph, Greg,
>
> Currently we are observing an incorrect address translation
> corresponding to DMA direct mapping methods on 5.4 stable kernel while
> sharing dmabuf from one device to another where both devices have
> their
> for DMA noncoherent device. By allowing device_initialize to ѕet the
> ->dma_coherent field to this default the amount of arch hooks required
> for this behavior can be greatly reduced.
>
> Signed-off-by: Christoph Hellwig
A
On Mon, Jan 25, 2021 at 04:34:56PM +0800, Zhou Wang wrote:
> +static int uacce_pin_page(struct uacce_pin_container *priv,
> + struct uacce_pin_address *addr)
> +{
> + unsigned int flags = FOLL_FORCE | FOLL_WRITE;
> + unsigned long first, last, nr_pages;
> + struct
From: John Stultz
[ Upstream commit 72b55c96f3a5ae6e486c20b5dacf5114060ed042 ]
Robin Murphy pointed out that if the arm-smmu driver probes before
the qcom_scm driver, we may call qcom_scm_qsmmu500_wait_safe_toggle()
before the __scm is initialized.
Now, getting this to happen is a bit
> Cc: Lina Iyer
> Cc: Saravana Kannan
> Cc: Todd Kjos
> Cc: Greg Kroah-Hartman
> Cc: linux-arm-...@vger.kernel.org
> Cc: iommu@lists.linux-foundation.org
> Cc: linux-g...@vger.kernel.org
> Signed-off-by: John Stultz
> ---
Reviewed-by: Greg Kroah-Hartman
late_bounce_limits
> functions wasn't going through the proper driver interface to query
> DMA information, but that function was removed in commit 21e07dba9fb1
> ("scsi: reduce use of block bounce buffers") years ago.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Greg
On Mon, Aug 17, 2020 at 12:46:17PM +0200, Mauro Carvalho Chehab wrote:
> The main reason of submitting via staging is that I need to preserve
> the patch that added this driver as-is, in order to preserve its
> SoB and not causing legal issues.
>
> It it is OK for iommu to accept a submission
On Mon, Aug 17, 2020 at 11:27:25AM +0200, Mauro Carvalho Chehab wrote:
> Hi Christoph,
>
> Em Mon, 17 Aug 2020 09:21:06 +0100
> Christoph Hellwig escreveu:
>
> > On Mon, Aug 17, 2020 at 09:49:59AM +0200, Mauro Carvalho Chehab wrote:
> > > Add a driver for the Kirin 960/970 iommu.
> > >
> > >
rtially reverts:
> commit ab1a187bba5c ("PCI: Check device_attach() return value always")
>
> Signed-off-by: Rajat Jain
> Reviewed-by: Greg Kroah-Hartman
> ---
> Resending to stable, independent from other patches per Greg's suggestion
> v2: Add Greg's reviewed by,
On Mon, Jul 06, 2020 at 11:41:26AM -0500, Bjorn Helgaas wrote:
> On Tue, Jun 30, 2020 at 09:55:54AM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Jun 29, 2020 at 09:49:38PM -0700, Rajat Jain wrote:
> > > The "ExternalFacing" devices (root ports) are still int
nus Walleij
> Cc: Maulik Shah
> Cc: Lina Iyer
> Cc: Saravana Kannan
> Cc: Todd Kjos
> Cc: Greg Kroah-Hartman
> Cc: linux-arm-...@vger.kernel.org
> Cc: iommu@lists.linux-foundation.org
> Cc: linux-g...@vger.kernel.org
> S
On Thu, Jul 02, 2020 at 10:52:12AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 02, 2020 at 06:40:09PM +1000, Oliver O'Halloran wrote:
> > On Thu, 2020-07-02 at 09:32 +0200, Greg Kroah-Hartman wrote:
> > > On Thu, Jul 02, 2020 at 03:23:23PM +1000, Oliver O'Halloran wrote:
&
On Thu, Jul 02, 2020 at 06:40:09PM +1000, Oliver O'Halloran wrote:
> On Thu, 2020-07-02 at 09:32 +0200, Greg Kroah-Hartman wrote:
> > On Thu, Jul 02, 2020 at 03:23:23PM +1000, Oliver O'Halloran wrote:
> > > Yep, that's a problem. If we want to provide a useful mechanism
On Thu, Jul 02, 2020 at 03:23:23PM +1000, Oliver O'Halloran wrote:
> On Thu, Jul 2, 2020 at 4:07 AM Rajat Jain wrote:
> >
> > *snip*
> >
> > > > I guess it would make sense to have an attribute for user space to
> > > > write to in order to make the kernel reject device plug-in events
> > > >
On Tue, Jun 30, 2020 at 06:08:31PM +0200, Rafael J. Wysocki wrote:
> On Tue, Jun 30, 2020 at 5:38 PM Greg Kroah-Hartman
> wrote:
> >
> > On Tue, Jun 30, 2020 at 03:00:34PM +0200, Rafael J. Wysocki wrote:
> > > On Tue, Jun 30, 2020 at 2:52 PM Greg Kroah-Hartman
> >
On Tue, Jun 30, 2020 at 03:00:34PM +0200, Rafael J. Wysocki wrote:
> On Tue, Jun 30, 2020 at 2:52 PM Greg Kroah-Hartman
> wrote:
> >
> > On Tue, Jun 30, 2020 at 01:49:48PM +0300, Heikki Krogerus wrote:
> > > On Mon, Jun 29, 2020 at 09:49:41PM -0700, Rajat Jain wrote:
On Tue, Jun 30, 2020 at 01:49:48PM +0300, Heikki Krogerus wrote:
> On Mon, Jun 29, 2020 at 09:49:41PM -0700, Rajat Jain wrote:
> > Add a new (optional) field to denote the physical location of a device
> > in the system, and expose it in sysfs. This was discussed here:
> >
rtially reverts:
> commit ab1a187bba5c ("PCI: Check device_attach() return value always")
>
> Signed-off-by: Rajat Jain
> Reviewed-by: Greg Kroah-Hartman
> ---
> v2: Cosmetic change in commit log.
> Add Greg's "reviewed-by"
>
> drivers/pci/b
On Mon, Jun 29, 2020 at 09:49:41PM -0700, Rajat Jain wrote:
> Add a new (optional) field to denote the physical location of a device
> in the system, and expose it in sysfs. This was discussed here:
> https://lore.kernel.org/linux-acpi/20200618184621.ga446...@kroah.com/
>
> (The primary choice
On Mon, Jun 29, 2020 at 09:49:38PM -0700, Rajat Jain wrote:
> The "ExternalFacing" devices (root ports) are still internal devices that
> sit on the internal system fabric and thus trusted. Currently they were
> being marked untrusted.
>
> This patch uses the platform flag to identify the
On Fri, Jun 26, 2020 at 11:53:34AM -0700, Rajat Jain wrote:
> a) I think what was decided was introducing a device core "location"
> property that can be exposed to userspace to help it to decide whether
> or not to attach a driver to a device. Yes, that is still the plan.
Great, but this patch
On Thu, Jun 25, 2020 at 05:27:10PM -0700, Rajat Jain wrote:
> Introduce a PCI parameter that disables the automatic attachment of
> untrusted devices to their drivers.
>
> Signed-off-by: Rajat Jain
> ---
> Context:
>
> I set out to implement the approach outlined in
>
return;
> - }
Nice catch, sysfs stuff shouldn't be dependant if a driver is bound to a
device or not.
Reviewed-by: Greg Kroah-Hartman
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Thu, Jun 25, 2020 at 05:27:10PM -0700, Rajat Jain wrote:
> Introduce a PCI parameter that disables the automatic attachment of
> untrusted devices to their drivers.
You didn't document this new api anywhere :(
___
iommu mailing list
On Thu, Jun 18, 2020 at 10:23:38AM -0700, Rajat Jain wrote:
> Thanks Greg and Andy for your continued inputs, and thanks Ashok for chiming
> in.
>
> On Thu, Jun 18, 2020 at 9:23 AM Raj, Ashok wrote:
> >
> > Hi Greg,
> >
> >
> > On Thu, Jun 18, 2020 at
On Thu, Jun 18, 2020 at 08:03:49AM -0700, Rajat Jain wrote:
> Hello,
>
> On Thu, Jun 18, 2020 at 2:14 AM Andy Shevchenko
> wrote:
> >
> > On Thu, Jun 18, 2020 at 11:36 AM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Thu, Jun 18, 2020 at 11:12:5
On Thu, Jun 18, 2020 at 12:14:41PM +0300, Andy Shevchenko wrote:
> On Thu, Jun 18, 2020 at 11:36 AM Greg Kroah-Hartman
> wrote:
> >
> > On Thu, Jun 18, 2020 at 11:12:56AM +0300, Andy Shevchenko wrote:
> > > On Wed, Jun 17, 2020 at 10:56 PM Rajat Jain wrote:
> >
On Thu, Jun 18, 2020 at 11:12:56AM +0300, Andy Shevchenko wrote:
> On Wed, Jun 17, 2020 at 10:56 PM Rajat Jain wrote:
> > On Wed, Jun 17, 2020 at 12:31 AM Christoph Hellwig
> > wrote:
>
> ...
>
> > (and likely call it "external" instead of "untrusted".
>
> Which is not okay. 'External' to
On Wed, Jun 17, 2020 at 12:53:03PM -0700, Rajat Jain wrote:
> Hi Greg, Christoph,
>
> On Wed, Jun 17, 2020 at 12:31 AM Christoph Hellwig wrote:
> >
> > On Tue, Jun 16, 2020 at 12:27:35PM -0700, Rajat Jain wrote:
> > > Need clarification. The flag "untrusted" is currently a part of
> > > pci_dev
On Mon, Jun 15, 2020 at 06:17:42PM -0700, Rajat Jain wrote:
> This is needed to allow the userspace to determine when an untrusted
> device has been added, and thus allowing it to bind the driver manually
> to it, if it so wishes. This is being done as part of the approach
> discussed at
On Tue, May 26, 2020 at 11:09:57PM +0800, Zhangfei Gao wrote:
> Hi, Christoph
>
> On 2020/5/26 下午10:46, Christoph Hellwig wrote:
> > On Tue, May 26, 2020 at 07:49:08PM +0800, Zhangfei Gao wrote:
> > > Some platform devices appear as PCI but are actually on the AMBA bus,
> > > and they need fixup
On Tue, May 26, 2020 at 07:49:09PM +0800, Zhangfei Gao wrote:
> Calling pci_fixup_iommu in iommu_fwspec_init, which alloc
> iommu_fwnode. Some platform devices appear as PCI but are
> actually on the AMBA bus, and they need fixup in
> drivers/pci/quirks.c handling iommu_fwnode.
> So calling
1 - 100 of 199 matches
Mail list logo
