All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Joerg Roedel <joro@8bytes.org>, Li Yang <leoyang.li@nxp.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	iommu@lists.linux.dev, linuxppc-dev@lists.ozlabs.org,
	Nicholas Piggin <npiggin@gmail.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Will Deacon <will@kernel.org>
Subject: Re: [PATCH v2 0/3] Remove iommu_group_remove_device() from fsl
Date: Wed, 31 May 2023 17:04:04 +1000	[thread overview]
Message-ID: <87leh5yobf.fsf@mail.lhotse> (raw)
In-Reply-To: <ZHX9nu234ehZWVwU@nvidia.com>

Jason Gunthorpe <jgg@nvidia.com> writes:
> On Tue, May 30, 2023 at 10:03:53PM +1000, Michael Ellerman wrote:
>> Jason Gunthorpe <jgg@nvidia.com> writes:
>> > On Tue, May 23, 2023 at 08:26:32AM +0200, Joerg Roedel wrote:
>> >> On Tue, May 16, 2023 at 09:35:25PM -0300, Jason Gunthorpe wrote:
>> >> > With POWER SPAPR now having a real iommu driver and using the normal group
>> >> > lifecycle stuff fixing FSL will leave only VFIO's no-iommu support as a
>> >> > user for the iommu_group_add/remove_device() calls. This will help
>> >> > simplify the understanding of what the core code should be doing for these
>> >> > functions.
>> >> > 
>> >> > Fix FSL to not need to call iommu_group_remove_device() at all.
>> >> > 
>> >> > v2:
>> >> >  - Change the approach to use driver_managed_dma
>> >> >  - Really simplify fsl_pamu_device_group() and just put everything in one
>> >> >    function
>> >> >  - New patch to make missing OF properties a probe failure
>> >> > v1: https://lore.kernel.org/r/0-v1-1421774b874b+167-ppc_device_group_jgg@nvidia.com
>> >> > 
>> >> > Jason Gunthorpe (3):
>> >> >   iommu/fsl: Always allocate a group for non-pci devices
>> >> >   iommu/fsl: Move ENODEV to fsl_pamu_probe_device()
>> >> >   iommu/fsl: Use driver_managed_dma to allow VFIO to work
>> >> > 
>> >> >  arch/powerpc/sysdev/fsl_pci.c   |   1 +
>> >> >  drivers/iommu/fsl_pamu_domain.c | 123 +++++++++-----------------------
>> >> >  2 files changed, 36 insertions(+), 88 deletions(-)
>> >> 
>> >> Any chance someone can test this on real hardware?
>> >
>> > There isn't even a MAINTAINERS entry for this, and the git log looks
>> > pretty dead for a long time. I tried to cc people who might care,
>> > but I'm not so optimistic - unless Li says something.
>> 
...
>
>> Anything else I can check easily?
>
> Wow Great, I think that is a Tested-by. :) Honestly booting at all is
> 99% of the battle..

Great, yep consider it:

Tested-by: Michael Ellerman <mpe@ellerman.id.au>

cheers

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Joerg Roedel <joro@8bytes.org>,
	Nicholas Piggin <npiggin@gmail.com>, Li Yang <leoyang.li@nxp.com>,
	iommu@lists.linux.dev, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 0/3] Remove iommu_group_remove_device() from fsl
Date: Wed, 31 May 2023 17:04:04 +1000	[thread overview]
Message-ID: <87leh5yobf.fsf@mail.lhotse> (raw)
In-Reply-To: <ZHX9nu234ehZWVwU@nvidia.com>

Jason Gunthorpe <jgg@nvidia.com> writes:
> On Tue, May 30, 2023 at 10:03:53PM +1000, Michael Ellerman wrote:
>> Jason Gunthorpe <jgg@nvidia.com> writes:
>> > On Tue, May 23, 2023 at 08:26:32AM +0200, Joerg Roedel wrote:
>> >> On Tue, May 16, 2023 at 09:35:25PM -0300, Jason Gunthorpe wrote:
>> >> > With POWER SPAPR now having a real iommu driver and using the normal group
>> >> > lifecycle stuff fixing FSL will leave only VFIO's no-iommu support as a
>> >> > user for the iommu_group_add/remove_device() calls. This will help
>> >> > simplify the understanding of what the core code should be doing for these
>> >> > functions.
>> >> > 
>> >> > Fix FSL to not need to call iommu_group_remove_device() at all.
>> >> > 
>> >> > v2:
>> >> >  - Change the approach to use driver_managed_dma
>> >> >  - Really simplify fsl_pamu_device_group() and just put everything in one
>> >> >    function
>> >> >  - New patch to make missing OF properties a probe failure
>> >> > v1: https://lore.kernel.org/r/0-v1-1421774b874b+167-ppc_device_group_jgg@nvidia.com
>> >> > 
>> >> > Jason Gunthorpe (3):
>> >> >   iommu/fsl: Always allocate a group for non-pci devices
>> >> >   iommu/fsl: Move ENODEV to fsl_pamu_probe_device()
>> >> >   iommu/fsl: Use driver_managed_dma to allow VFIO to work
>> >> > 
>> >> >  arch/powerpc/sysdev/fsl_pci.c   |   1 +
>> >> >  drivers/iommu/fsl_pamu_domain.c | 123 +++++++++-----------------------
>> >> >  2 files changed, 36 insertions(+), 88 deletions(-)
>> >> 
>> >> Any chance someone can test this on real hardware?
>> >
>> > There isn't even a MAINTAINERS entry for this, and the git log looks
>> > pretty dead for a long time. I tried to cc people who might care,
>> > but I'm not so optimistic - unless Li says something.
>> 
...
>
>> Anything else I can check easily?
>
> Wow Great, I think that is a Tested-by. :) Honestly booting at all is
> 99% of the battle..

Great, yep consider it:

Tested-by: Michael Ellerman <mpe@ellerman.id.au>

cheers

  reply	other threads:[~2023-05-31  7:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-17  0:35 [PATCH v2 0/3] Remove iommu_group_remove_device() from fsl Jason Gunthorpe
2023-05-17  0:35 ` [PATCH v2 1/3] iommu/fsl: Always allocate a group for non-pci devices Jason Gunthorpe
2023-05-17  0:35 ` [PATCH v2 2/3] iommu/fsl: Move ENODEV to fsl_pamu_probe_device() Jason Gunthorpe
2023-05-17  0:35 ` [PATCH v2 3/3] iommu/fsl: Use driver_managed_dma to allow VFIO to work Jason Gunthorpe
2023-05-23  6:26 ` [PATCH v2 0/3] Remove iommu_group_remove_device() from fsl Joerg Roedel
2023-05-23  6:26   ` Joerg Roedel
2023-05-29  0:46   ` Jason Gunthorpe
2023-05-29  0:46     ` Jason Gunthorpe
2023-05-30 12:03     ` Michael Ellerman
2023-05-30 12:03       ` Michael Ellerman
2023-05-30 13:43       ` Jason Gunthorpe
2023-05-30 13:43         ` Jason Gunthorpe
2023-05-31  7:04         ` Michael Ellerman [this message]
2023-05-31  7:04           ` Michael Ellerman
2023-06-01  9:48           ` Joerg Roedel
2023-06-01  9:48             ` Joerg Roedel

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=87leh5yobf.fsf@mail.lhotse \
    --to=mpe@ellerman.id.au \
    --cc=christophe.leroy@csgroup.eu \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=leoyang.li@nxp.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=npiggin@gmail.com \
    --cc=robin.murphy@arm.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.