lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 18 Feb 2020 20:24:56 +0800 From: Hanjun Guo <guohanjun@...wei.com> To: "Pankaj Bansal (OSS)" <pankaj.bansal@....nxp.com>, Lorenzo Pieralisi <lorenzo.pieralisi@....com> CC: Marc Zyngier <maz@...nel.org>, Ard Biesheuvel <ard.biesheuvel@...aro.org>, Makarand Pawagi <makarand.pawagi@....com>, Calvin Johnson <calvin.johnson@....com>, "stuyoder@...il.com" <stuyoder@...il.com>, "nleeder@...eaurora.org" <nleeder@...eaurora.org>, Ioana Ciornei <ioana.ciornei@....com>, Cristi Sovaiala <cristian.sovaiala@....com>, "Will Deacon" <will@...nel.org>, "jon@...id-run.com" <jon@...id-run.com>, "Russell King" <linux@...linux.org.uk>, ACPI Devel Maling List <linux-acpi@...r.kernel.org>, Len Brown <lenb@...nel.org>, Jason Cooper <jason@...edaemon.net>, Andy Wang <Andy.Wang@....com>, Varun Sethi <V.Sethi@....com>, Thomas Gleixner <tglx@...utronix.de>, linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>, Laurentiu Tudor <laurentiu.tudor@....com>, Paul Yang <Paul.Yang@....com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Rafael J. Wysocki" <rjw@...ysocki.net>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Shameerali Kolothum Thodi <shameerali.kolothum.thodi@...wei.com>, Sudeep Holla <sudeep.holla@....com>, Robin Murphy <robin.murphy@....com> Subject: Re: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc Hi Pankaj, On 2020/2/18 16:00, Pankaj Bansal (OSS) wrote: [...] >>>> Side note: would you mind removing the email headers (as above) in your >>>> replies please ? >> >> Read the question above please. >> >> [...] >> >>>>> 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. >>>> >>>> So are you asking me if that's OK ? Or there is something you can't >>>> describe with IORT ? >>> >>> I am asking if that would be acceptable? >>> i.e. we represent MC bus as Named component is IORT table with a pool of IDs >> (without single ID mapping flag) >>> and then we use the Platform MSI framework for all children devices of MC >> bus. >>> Note that it would require the Platform MSI layer to correctly pass an input id >> for a platform device to IORT layer. >> >> How is this solved in DT ? You don't seem to need any DT binding on top >> of the msi-parent property, which is equivalent to IORT single mappings >> AFAICS so I would like to understand the whole DT flow (so that I >> understand how this FSL bus works) before commenting any further. > > In DT case, we create the domain DOMAIN_BUS_FSL_MC_MSI for MC bus and it's children. > And then when MC child device is created, we search the "msi-parent" property from the MC > DT node and get the ITS associated with MC bus. Then we search DOMAIN_BUS_FSL_MC_MSI > on that ITS. Once we find the domain, we can call msi_domain_alloc_irqs for that domain. > > This is exactly what we tried to do initially with ACPI. But the searching DOMAIN_BUS_FSL_MC_MSI > associated to an ITS, is something that is part of drivers/acpi/arm64/iort.c. > (similar to DOMAIN_BUS_PLATFORM_MSI and DOMAIN_BUS_PCI_MSI) Can you have a look at mbigen driver (drivers/irqchip/irq-mbigen.c) to see if it helps you? mbigen is an irq converter to convert device's wired interrupts into MSI (connecting to ITS), which will alloc a bunch of MSIs from ITS platform MSI domain at the setup. Thanks Hanjun
Powered by blists - more mailing lists