From: Robin Murphy <robin.murphy@arm.com> To: Pankaj Bansal <pankaj.bansal@nxp.com>, Marc Zyngier <maz@kernel.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, 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> Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc Date: Fri, 14 Feb 2020 16:29:40 +0000 [thread overview] Message-ID: <7e1ab651-1eb5-b461-1d21-6fd5c8f3ade8@arm.com> (raw) In-Reply-To: <VI1PR0401MB2496373E0C6D1097F22B3026F1150@VI1PR0401MB2496.eurprd04.prod.outlook.com> On 14/02/2020 3:58 pm, Pankaj Bansal wrote: [...] >> I don't understand what you mean. Platform MSI using IORT uses the DevID of >> end-points. How could the ITS could work without specifying a DevID? >> See for example how the SMMUv3 driver uses platform MSI. > > DevID is input ID for PCIe devices. BUT what would be the input ID for platform device? Are we saying that Platform devices can't specify an Input ID ? No, from the IORT perspective, the input for the ID mappings belonging to a root complex is the PCI requester ID. The (ITS) DevID is the ultimate *output* of a root complex mapping. Whilst you can indeed represent the MC as a black-box Named Component with an ID mapping range not using the "single mapping" flag, that means your input IDs come from some device-specific domain beyond the scope of IORT. That's why you can't easily get away from your special bus integration code. >>> While, IORT spec doesn't specify any such limitation. >>> >>> we can easily update iort.c to remove this limitation. >>> But, I am not sure how the input id would be passed from platform MSI >>> GIC layer to IORT. >>> Most obviously, the input id should be supplied by dev itself. >> >> 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. ...except for single mappings, where the input ID is ignored and the output ID is the "source", which is exactly what iort_node_get_id() deals with for devices represented in IORT. With what you're talking about, "the device" is *not* represented in IORT, but is something beyond the MC 'bridge'. Now it probably is technically possible to handle that somehow, but it's definitely not something that the existing code was ever designed to anticipate. Robin.
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com> To: Pankaj Bansal <pankaj.bansal@nxp.com>, Marc Zyngier <maz@kernel.org> Cc: 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>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, "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>, Makarand Pawagi <makarand.pawagi@nxp.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>, Ard Biesheuvel <ard.biesheuvel@linaro.org>, "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> Subject: Re: [EXT] Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc Date: Fri, 14 Feb 2020 16:29:40 +0000 [thread overview] Message-ID: <7e1ab651-1eb5-b461-1d21-6fd5c8f3ade8@arm.com> (raw) In-Reply-To: <VI1PR0401MB2496373E0C6D1097F22B3026F1150@VI1PR0401MB2496.eurprd04.prod.outlook.com> On 14/02/2020 3:58 pm, Pankaj Bansal wrote: [...] >> I don't understand what you mean. Platform MSI using IORT uses the DevID of >> end-points. How could the ITS could work without specifying a DevID? >> See for example how the SMMUv3 driver uses platform MSI. > > DevID is input ID for PCIe devices. BUT what would be the input ID for platform device? Are we saying that Platform devices can't specify an Input ID ? No, from the IORT perspective, the input for the ID mappings belonging to a root complex is the PCI requester ID. The (ITS) DevID is the ultimate *output* of a root complex mapping. Whilst you can indeed represent the MC as a black-box Named Component with an ID mapping range not using the "single mapping" flag, that means your input IDs come from some device-specific domain beyond the scope of IORT. That's why you can't easily get away from your special bus integration code. >>> While, IORT spec doesn't specify any such limitation. >>> >>> we can easily update iort.c to remove this limitation. >>> But, I am not sure how the input id would be passed from platform MSI >>> GIC layer to IORT. >>> Most obviously, the input id should be supplied by dev itself. >> >> 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. ...except for single mappings, where the input ID is ignored and the output ID is the "source", which is exactly what iort_node_get_id() deals with for devices represented in IORT. With what you're talking about, "the device" is *not* represented in IORT, but is something beyond the MC 'bridge'. Now it probably is technically possible to handle that somehow, but it's definitely not something that the existing code was ever designed to anticipate. Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-02-14 16:30 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-28 8:08 [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc Makarand Pawagi 2020-01-28 8:08 ` Makarand Pawagi 2020-01-28 10:58 ` Marc Zyngier 2020-01-28 10:58 ` Marc Zyngier 2020-01-28 11:09 ` Lorenzo Pieralisi 2020-01-28 11:09 ` Lorenzo Pieralisi 2020-01-31 10:35 ` [EXT] " Makarand Pawagi 2020-01-31 10:35 ` Makarand Pawagi 2020-01-31 11:06 ` Lorenzo Pieralisi 2020-01-31 11:06 ` Lorenzo Pieralisi 2020-01-31 11:06 ` Marc Zyngier 2020-01-31 11:06 ` Marc Zyngier 2020-01-31 12:01 ` Ard Biesheuvel 2020-01-31 12:01 ` Ard Biesheuvel 2020-01-31 12:28 ` Jon Nettleton 2020-01-31 12:28 ` Jon Nettleton 2020-01-31 12:48 ` Robin Murphy 2020-01-31 12:48 ` Robin Murphy 2020-01-31 13:11 ` Jon Nettleton 2020-01-31 13:11 ` Jon Nettleton 2020-01-31 13:29 ` Ard Biesheuvel 2020-01-31 13:29 ` Ard Biesheuvel 2020-01-31 13:39 ` Robin Murphy 2020-01-31 13:39 ` Robin Murphy 2020-01-31 14:29 ` Andrew Lunn 2020-01-31 14:29 ` Andrew Lunn 2020-01-31 14:47 ` Will Deacon 2020-01-31 14:47 ` Will Deacon 2020-01-31 15:09 ` Andrew Lunn 2020-01-31 15:09 ` Andrew Lunn 2020-01-31 15:14 ` Jon Nettleton 2020-01-31 15:14 ` Jon Nettleton 2020-01-31 15:41 ` Andrew Lunn 2020-01-31 15:41 ` Andrew Lunn 2020-01-31 15:39 ` Russell King - ARM Linux admin 2020-01-31 15:39 ` Russell King - ARM Linux admin 2020-01-31 15:15 ` Russell King - ARM Linux admin 2020-01-31 15:15 ` Russell King - ARM Linux admin 2020-01-31 15:40 ` Jakub Kicinski 2020-01-31 15:40 ` Jakub Kicinski 2020-02-01 11:49 ` Russell King - ARM Linux admin 2020-02-01 11:49 ` Russell King - ARM Linux admin 2020-02-01 17:36 ` Jakub Kicinski 2020-02-01 17:36 ` Jakub Kicinski 2020-02-14 15:05 ` Pankaj Bansal 2020-02-14 15:05 ` Pankaj Bansal 2020-02-14 15:54 ` Marc Zyngier 2020-02-14 15:54 ` Marc Zyngier 2020-02-14 15:58 ` Pankaj Bansal 2020-02-14 15:58 ` Pankaj Bansal 2020-02-14 16:19 ` Lorenzo Pieralisi 2020-02-14 16:19 ` Lorenzo Pieralisi 2020-02-14 16:35 ` Pankaj Bansal 2020-02-14 16:35 ` Pankaj Bansal 2020-02-14 17:49 ` Lorenzo Pieralisi 2020-02-14 17:49 ` Lorenzo Pieralisi 2020-02-17 12:35 ` Pankaj Bansal 2020-02-17 12:35 ` Pankaj Bansal 2020-02-17 15:25 ` Lorenzo Pieralisi 2020-02-17 15:25 ` Lorenzo Pieralisi 2020-02-17 15:35 ` Marc Zyngier 2020-02-17 15:35 ` Marc Zyngier 2020-02-17 16:26 ` Lorenzo Pieralisi 2020-02-17 16:26 ` Lorenzo Pieralisi 2020-02-18 8:02 ` Pankaj Bansal (OSS) 2020-02-18 8:02 ` Pankaj Bansal (OSS) 2020-02-14 16:29 ` Robin Murphy [this message] 2020-02-14 16:29 ` Robin Murphy
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=7e1ab651-1eb5-b461-1d21-6fd5c8f3ade8@arm.com \ --to=robin.murphy@arm.com \ --cc=Andy.Wang@arm.com \ --cc=Paul.Yang@arm.com \ --cc=V.Sethi@nxp.com \ --cc=ard.biesheuvel@linaro.org \ --cc=calvin.johnson@nxp.com \ --cc=cristian.sovaiala@nxp.com \ --cc=guohanjun@huawei.com \ --cc=ioana.ciornei@nxp.com \ --cc=jason@lakedaemon.net \ --cc=jon@solid-run.com \ --cc=laurentiu.tudor@nxp.com \ --cc=lenb@kernel.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=lorenzo.pieralisi@arm.com \ --cc=makarand.pawagi@nxp.com \ --cc=maz@kernel.org \ --cc=netdev@vger.kernel.org \ --cc=nleeder@codeaurora.org \ --cc=pankaj.bansal@nxp.com \ --cc=rjw@rjwysocki.net \ --cc=shameerali.kolothum.thodi@huawei.com \ --cc=stuyoder@gmail.com \ --cc=sudeep.holla@arm.com \ --cc=tglx@linutronix.de \ --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: linkBe 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.