linux-kernel - RE: [PATCH] bus: fsl-mc: Add ACPI support for fsl-mc

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <VI1PR04MB513558BF77192255CBE12102B0110@VI1PR04MB5135.eurprd04.prod.outlook.com>
Date:   Tue, 18 Feb 2020 12:48:39 +0000
From:   "Pankaj Bansal (OSS)" <pankaj.bansal@....nxp.com>
To:     Hanjun Guo <guohanjun@...wei.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

> >>>>> 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.

Unfortunately this is not the same case as ours. As I see Hisilicon IORT table
Is using single id mapping with named components.

https://github.com/tianocore/edk2-platforms/blob/master/Silicon/Hisilicon/Hi1616/D05AcpiTables/D05Iort.asl#L300

while we are not:

https://source.codeaurora.org/external/qoriq/qoriq-components/edk2-platforms/tree/Platform/NXP/LX2160aRdbPkg/AcpiTables/Iort.aslc?h=LX2160_UEFI_ACPI_EAR1#n290

This is because as I said, we are trying to represent a bus in IORT via named components and
not individual devices connected to that bus.

> 
> Thanks
> Hanjun