Re: [RFC PATCH v3 4/7] bus/cdx: add cdx-MSI domain with gic-its domain as parent

From: Marc Zyngier <maz@kernel.org>
To: "Gupta, Nipun" <Nipun.Gupta@amd.com>
Cc: "robh+dt@kernel.org" <robh+dt@kernel.org>,
	"krzysztof.kozlowski+dt@linaro.org"
	<krzysztof.kozlowski+dt@linaro.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"cohuck@redhat.com" <cohuck@redhat.com>,
	"Gupta, Puneet (DCG-ENG)" <puneet.gupta@amd.com>,
	"song.bao.hua@hisilicon.com" <song.bao.hua@hisilicon.com>,
	"mchehab+huawei@kernel.org" <mchehab+huawei@kernel.org>,
	"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
	"jeffrey.l.hugo@gmail.com" <jeffrey.l.hugo@gmail.com>,
	"saravanak@google.com" <saravanak@google.com>,
	"Michael.Srba@seznam.cz" <Michael.Srba@seznam.cz>,
	"mani@kernel.org" <mani@kernel.org>,
	"yishaih@nvidia.com" <yishaih@nvidia.com>,
	"jgg@ziepe.ca" <jgg@ziepe.ca>, "jgg@nvidia.com" <jgg@nvidia.com>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>,
	"will@kernel.org" <will@kernel.org>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"masahiroy@kernel.org" <masahiroy@kernel.org>,
	"ndesaulniers@google.com" <ndesaulniers@google.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kbuild@vger.kernel.org" <linux-kbuild@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"okaya@kernel.org" <okaya@kernel.org>,
	"Anand, Harpreet" <harpreet.anand@amd.com>,
	"Agarwal, Nikhil" <nikhil.agarwal@amd.com>,
	"Simek,\ Michal" <michal.simek@amd.com>,
	"Radovanovic, Aleksandar" <aleksandar.radovanovic@amd.com>,
	"git (AMD-Xilinx)" <git@amd.com>
Subject: Re: [RFC PATCH v3 4/7] bus/cdx: add cdx-MSI domain with gic-its domain as parent
Date: Thu, 08 Sep 2022 15:29:44 +0100	[thread overview]
Message-ID: <87a67aueg7.wl-maz@kernel.org> (raw)
In-Reply-To: <DM6PR12MB30821367EC37FDE33DC47A25E8409@DM6PR12MB3082.namprd12.prod.outlook.com>

On Thu, 08 Sep 2022 15:13:31 +0100,
"Gupta, Nipun" <Nipun.Gupta@amd.com> wrote:
> 
>
> > > +             return;
> > > +
> > > +     msi_domain_free_irqs(msi_domain, dev);
> > > +}
> > > +EXPORT_SYMBOL(cdx_msi_domain_free_irqs);
> > 
> > This feels like a very pointless helper, and again a copy/paste from
> > the FSL code. I'd rather you change msi_domain_free_irqs() to only
> > take a device and use the implicit MSI domain.
> 
> I agree with other comments except this one.
> 
> In current implementation we have an API "cdx_msi_domain_alloc_irqs()",
> so having "cdx_msi_domain_free_irqs()" seems legitimate, as the caller
> would allocate and free MSI's using a similar APIs (cdx_msi_domain*).

Why would that be a problem? Using generic functions when they apply
should be the default, and "specialised" helpers are only here as a
reminder that our MSI API still needs serious improvement.

> Changing msi_domain_free_irqs() to use implicit msi domain in case
> msi_domain is not provided by the caller seems appropriate, Ill change the
> same for "msi_domain_alloc_irqs()" too.

What I'm asking is that there is no explicit msi_domain anymore. We
always use the one referenced by the device. And if that can be done
on the allocation path too, great.

> <..>
> 
> > > diff --git a/drivers/bus/cdx/mcdi_stubs.c b/drivers/bus/cdx/mcdi_stubs.c
> > > index cc9d30fa02f8..2c8db1f5a057 100644
> > > --- a/drivers/bus/cdx/mcdi_stubs.c
> > > +++ b/drivers/bus/cdx/mcdi_stubs.c
> > > @@ -45,6 +45,7 @@ int cdx_mcdi_get_func_config(struct cdx_mcdi_t
> > *cdx_mcdi,
> > >       dev_params->res_count = 2;
> > >
> > >       dev_params->req_id = 0x250;
> > > +     dev_params->num_msi = 4;
> > 
> > Why the hardcoded 4? Is that part of the firmware emulation stuff?
> 
> Yes, this is currently part of emulation, and would change with proper
> emulation support.

What "proper emulation support"? I expect no emulation at all, but
instead a well defined probing method.

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel