On 2/16/22 11:45 AM, Tian, Kevin wrote:
From: Christoph Hellwig
Sent: Monday, February 14, 2022 3:34 PM
On Mon, Feb 14, 2022 at 10:57:02AM +0800, Lu Baolu wrote:
This removes unnecessary commented code.
Removing dead code is always good:
Reviewed-by: Christoph Hellwig
But someone might reall
On 2/15/22 5:51 PM, Andy Shevchenko wrote:
On Tue, Feb 15, 2022 at 09:31:37AM +0800, Lu Baolu wrote:
On 2/14/22 9:27 PM, Joerg Roedel wrote:
On Mon, Feb 07, 2022 at 04:12:40PM +0200, Andy Shevchenko wrote:
...
+extern const struct iommu_ops intel_iommu_ops;
The intel_iommu_ops symbol is
On 2/15/22 9:47 PM, Jason Gunthorpe via iommu wrote:
On Tue, Feb 15, 2022 at 09:58:13AM +0100, Joerg Roedel wrote:
On Mon, Feb 14, 2022 at 11:46:26AM -0400, Jason Gunthorpe wrote:
On Mon, Feb 14, 2022 at 03:18:31PM +, Robin Murphy wrote:
Arguably, iommu_attach_device() could be renamed so
On Wed, Feb 16, 2022 at 2:55 PM Yong Wu wrote:
>
> On Thu, 2022-01-27 at 12:08 +0100, AngeloGioacchino Del Regno wrote:
> > Il 25/01/22 09:56, Yong Wu ha scritto:
> > > No need zero for the protect buffer that is only accessed by the
> > > IOMMU HW
> > > translation fault happened.
> > >
> > > Sig
On Thu, 2022-01-27 at 12:08 +0100, AngeloGioacchino Del Regno wrote:
> Il 25/01/22 09:56, Yong Wu ha scritto:
> > No need zero for the protect buffer that is only accessed by the
> > IOMMU HW
> > translation fault happened.
> >
> > Signed-off-by: Yong Wu
>
> I would rather keep this a devm_kzall
> From: Christoph Hellwig
> Sent: Monday, February 14, 2022 3:34 PM
>
> On Mon, Feb 14, 2022 at 10:57:02AM +0800, Lu Baolu wrote:
> > This removes unnecessary commented code.
>
> Removing dead code is always good:
>
> Reviewed-by: Christoph Hellwig
>
> But someone might really want to take a
On 2/15/22 5:17 PM, Joerg Roedel wrote:
Hi Baolu,
On Tue, Feb 15, 2022 at 10:05:42AM +0800, Lu Baolu wrote:
Do you want me to send a new version with below changes:
- Remove WARN_ON() in dev_iommu_ops();
- Merge above two patches.
Or, you can change above yourself?
Please make the changes a
Move the domain specific operations out of struct iommu_ops into a new
structure that only has domain specific operations. This solves the
problem of needing to know if the method vector for a given operation
needs to be retrieved from the device or the domain. Logically the domain
ops are the ones
The is_attach_deferred iommu_ops callback is a device op. The domain
argument is unnecessary and never used. Remove it to make code clean.
Suggested-by: Robin Murphy
Signed-off-by: Lu Baolu
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
include/linux/iommu.h | 2 +-
The common iommu_ops is hooked to both device and domain. When a helper
has both device and domain pointer, the way to get the iommu_ops looks
messy in iommu core. This sorts out the way to get iommu_ops. The device
related helpers go through device pointer, while the domain related ones
go through
The supported page sizes of an iommu_domain are saved in the pgsize_bitmap
field. Retrieve the value from the right place.
Signed-off-by: Lu Baolu
Reviewed-by: Robin Murphy
Link:
https://lore.kernel.org/r/20211218074546.1772553-1-baolu...@linux.intel.com
Reviewed-by: Christoph Hellwig
Reviewed
The apply_resv_region callback in iommu_ops was introduced to reserve an
IOVA range in the given DMA domain when the IOMMU driver manages the IOVA
by itself. As all drivers converted to use dma-iommu in the core, there's
no driver using this anymore. Remove it to avoid dead code.
Suggested-by: Rob
The aux-domain related interfaces and iommu_ops are not referenced
anywhere in the tree. We've also reached a consensus to redesign it
based the new iommufd framework. Remove them to avoid dead code.
Signed-off-by: Lu Baolu
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
includ
The aux-domain related callbacks are not called in the tree. Remove them
to avoid dead code.
Signed-off-by: Lu Baolu
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
include/linux/intel-iommu.h | 17 --
drivers/iommu/intel/debugfs.c | 3 +-
drivers/iommu/intel/iommu.c | 3
The guest pasid related callbacks are not called in the tree. Remove them
to avoid dead code.
Signed-off-by: Lu Baolu
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
include/linux/intel-iommu.h | 10 --
include/linux/intel-svm.h | 12 ---
drivers/iommu/intel/pasid.h | 4 -
The guest pasid related uapi interfaces and definitions are not referenced
anywhere in the tree. We've also reached a consensus to replace them with
a new iommufd design. Remove them to avoid dead code.
Signed-off-by: Lu Baolu
Reviewed-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
inc
Hi,
The guest pasid and aux-domain related code are dead code in current
iommu subtree. As we have reached a consensus that all these features
should be based on the new iommufd framework (which is under active
development), the first part of this series removes and cleanups all
the dead code.
Th
Some platforms might define the same memory region to be suitable for
used by a kernel supporting CONFIG_DMA_RESTRICTED_POOL while maintaining
compatibility with older kernels that do not support that. This is
achieved by declaring the node this way;
cma@4000 {
compatib
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 for-next branch.
Thanks!
Helge
> drivers/video/fbdev/omap2/omapfb/dss/dss.c |
On Mon, Feb 14, 2022 at 11:42 AM David Hildenbrand wrote:
>
> Let's factor out determining the minimum alignment requirement for CMA
> and add a helpful comment.
>
> No functional change intended.
>
> Signed-off-by: David Hildenbrand
> ---
> arch/powerpc/include/asm/fadump-internal.h | 5 -
Paul,
Apologies for missing your follow-up questions. Hopefully, the below
answers will help.
On 1/21/22 16:39, Paul Moore wrote:
> On Mon, Dec 6, 2021 at 3:56 PM Paul Moore wrote:
>> On Thu, Dec 2, 2021 at 11:11 AM Daniel P. Smith
>> wrote:
>>> Hi Paul!
>>
>> /me waves
>>
>>> On 11/30/21 8:06
On 2/14/2022 9:58 PM, Christoph Hellwig wrote:
On Mon, Feb 14, 2022 at 07:28:40PM +0800, Tianyu Lan wrote:
On 2/14/2022 4:19 PM, Christoph Hellwig wrote:
Adding a function to set the flag doesn't really change much. As Robin
pointed out last time you should fine a way to just call
swiotlb_init
On Tue, Feb 15, 2022 at 10:11:01AM +0100, Joerg Roedel wrote:
> > But, then, the requirement is that nobody is using the dma API when we
> > make this change?
>
> That is the tricky part. DMA-API keeps working after the change is made,
> because the new domain is also direct mapped. The new domai
On 2022-02-15 13:42, Will Deacon wrote:
On Tue, Feb 15, 2022 at 01:30:26PM +, Robin Murphy wrote:
On 2022-02-15 13:00, Will Deacon wrote:
On Mon, Feb 14, 2022 at 08:55:20PM +0800, Yicong Yang wrote:
On 2022/1/24 21:11, Yicong Yang wrote:
The DMA of HiSilicon PTT device can only work with
On Tue, Feb 15, 2022 at 09:58:13AM +0100, Joerg Roedel wrote:
> On Mon, Feb 14, 2022 at 11:46:26AM -0400, Jason Gunthorpe wrote:
> > On Mon, Feb 14, 2022 at 03:18:31PM +, Robin Murphy wrote:
> >
> > > Arguably, iommu_attach_device() could be renamed something like
> > > iommu_attach_group_for_
On Tue, Feb 15, 2022 at 01:30:26PM +, Robin Murphy wrote:
> On 2022-02-15 13:00, Will Deacon wrote:
> > On Mon, Feb 14, 2022 at 08:55:20PM +0800, Yicong Yang wrote:
> > > On 2022/1/24 21:11, Yicong Yang wrote:
> > > > The DMA of HiSilicon PTT device can only work with identical
> > > > mapping.
On 2022-02-15 13:00, Will Deacon wrote:
On Mon, Feb 14, 2022 at 08:55:20PM +0800, Yicong Yang wrote:
On 2022/1/24 21:11, Yicong Yang wrote:
The DMA of HiSilicon PTT device can only work with identical
mapping. So add a quirk for the device to force the domain
passthrough.
Signed-off-by: Yicong
On 2022-02-15 09:11, Joerg Roedel wrote:
On Mon, Feb 14, 2022 at 11:00:59AM -0400, Jason Gunthorpe wrote:
On Mon, Feb 14, 2022 at 03:23:07PM +0100, Joerg Roedel wrote:
Device drivers calling into iommu_attach_device() is seldom a good
idea. In this case the sound device has some generic hardw
On Mon, Feb 14, 2022 at 08:55:20PM +0800, Yicong Yang wrote:
> On 2022/1/24 21:11, Yicong Yang wrote:
> > The DMA of HiSilicon PTT device can only work with identical
> > mapping. So add a quirk for the device to force the domain
> > passthrough.
> >
> > Signed-off-by: Yicong Yang
> > ---
> > dr
On Mon, Feb 07, 2022 at 03:02:48PM -0800, Fenghua Yu wrote:
> PASIDs are process wide. It was attempted to use refcounted PASIDs to
> free them when the last thread drops the refcount. This turned out to
> be complex and error prone. Given the fact that the PASID space is 20
> bits, which allows up
On Tue, Feb 15, 2022 at 09:31:37AM +0800, Lu Baolu wrote:
> On 2/14/22 9:27 PM, Joerg Roedel wrote:
> > On Mon, Feb 07, 2022 at 04:12:40PM +0200, Andy Shevchenko wrote:
...
> > > +extern const struct iommu_ops intel_iommu_ops;
> > The intel_iommu_ops symbol is only used in drivers/iommu/intel, s
Hi Baolu,
On Tue, Feb 15, 2022 at 10:05:42AM +0800, Lu Baolu wrote:
> Do you want me to send a new version with below changes:
>
> - Remove WARN_ON() in dev_iommu_ops();
> - Merge above two patches.
>
> Or, you can change above yourself?
Please make the changes and send a new version. I will ap
On Mon, Feb 14, 2022 at 11:00:59AM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 14, 2022 at 03:23:07PM +0100, Joerg Roedel wrote:
>
> > Device drivers calling into iommu_attach_device() is seldom a good
> > idea. In this case the sound device has some generic hardware
> > interface so that an exis
On Mon, Feb 14, 2022 at 11:46:26AM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 14, 2022 at 03:18:31PM +, Robin Murphy wrote:
>
> > Arguably, iommu_attach_device() could be renamed something like
> > iommu_attach_group_for_dev(), since that's effectively the semantic that all
> > the existing A
34 matches
Mail list logo
