RE: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc

From: Pankaj Bansal <pankaj.bansal@nxp.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Makarand Pawagi <makarand.pawagi@nxp.com>,
	Calvin Johnson <calvin.johnson@nxp.com>,
	"stuyoder@gmail.com" <stuyoder@gmail.com>,
	"nleeder@codeaurora.org" <nleeder@codeaurora.org>,
	Ioana Ciornei <ioana.ciornei@nxp.com>,
	Cristi Sovaiala <cristian.sovaiala@nxp.com>,
	Hanjun Guo <guohanjun@huawei.com>, Will Deacon <will@kernel.org>,
	"jon@solid-run.com" <jon@solid-run.com>,
	Russell King <linux@armlinux.org.uk>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Len Brown <lenb@kernel.org>, Jason Cooper <jason@lakedaemon.net>,
	Andy Wang <Andy.Wang@arm.com>, Varun Sethi <V.Sethi@nxp.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Laurentiu Tudor <laurentiu.tudor@nxp.com>,
	Paul Yang <Paul.Yang@arm.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Shameerali Kolothum Thodi  <shameerali.kolothum.thodi@huawei.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Robin Murphy <robin.murphy@arm.com>
Subject: RE: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
Date: Fri, 14 Feb 2020 16:35:10 +0000	[thread overview]
Message-ID: <VI1PR0401MB2496800C88A3A2CF912959E6F1150@VI1PR0401MB2496.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <20200214161957.GA27513@e121166-lin.cambridge.arm.com>

> -----Original Message-----
> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Sent: Friday, February 14, 2020 9:50 PM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>
> Cc: Marc Zyngier <maz@kernel.org>; Ard Biesheuvel
> <ard.biesheuvel@linaro.org>; Makarand Pawagi <makarand.pawagi@nxp.com>;
> Calvin Johnson <calvin.johnson@nxp.com>; stuyoder@gmail.com;
> nleeder@codeaurora.org; Ioana Ciornei <ioana.ciornei@nxp.com>; Cristi
> Sovaiala <cristian.sovaiala@nxp.com>; Hanjun Guo <guohanjun@huawei.com>;
> Will Deacon <will@kernel.org>; jon@solid-run.com; Russell King
> <linux@armlinux.org.uk>; ACPI Devel Maling List <linux-acpi@vger.kernel.org>;
> Len Brown <lenb@kernel.org>; Jason Cooper <jason@lakedaemon.net>; Andy
> Wang <Andy.Wang@arm.com>; Varun Sethi <V.Sethi@nxp.com>; Thomas
> Gleixner <tglx@linutronix.de>; linux-arm-kernel <linux-arm-
> kernel@lists.infradead.org>; Laurentiu Tudor <laurentiu.tudor@nxp.com>; Paul
> Yang <Paul.Yang@arm.com>; netdev@vger.kernel.org; Rafael J. Wysocki
> <rjw@rjwysocki.net>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>;
> Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>;
> Sudeep Holla <sudeep.holla@arm.com>; Robin Murphy
> <robin.murphy@arm.com>
> Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc
> 
> On Fri, Feb 14, 2020 at 03:58:14PM +0000, Pankaj Bansal wrote:
> 
> [...]
> 
> > > Why should the device know about its own ID? That's a bus/interconnect
> thing.
> > > And nothing should be passed *to* IORT. IORT is the source.
> >
> > IORT is translation between Input IDs <-> Output IDs. The Input ID is still
> expected to be passed to parse IORT table.
> 
> Named components use an array of single mappings (as in entries with single
> mapping flag set) - Input ID is irrelevant.
> 
> Not sure what your named component is though and what you want to do with
> it, the fact that IORT allows mapping for named components do not necessarily
> mean that it can describe what your system really is, on that you need to
> elaborate for us to be able to help.

Details about MC bus can be read from here:
https://elixir.bootlin.com/linux/latest/source/Documentation/networking/device_drivers/freescale/dpaa2/overview.rst#L324

As stated above, in Linux MC is a bus (just like PCI bus, AMBA bus etc)
There can be multiple devices attached to this bus. Moreover, we can dynamically create/destroy these devices.
Now, we want to represent this BUS (not individual devices connected to bus) in IORT table.
The only possible way right now we see is that we describe it as Named components having a pool of ID mappings.
As and when devices are created and attached to bus, we sift through this pool to correctly determine the output ID for the device.
Now the input ID that we provide, can come from device itself.
Then we can use the Platform MSI framework for MC bus devices.

> 
> Lorenzo