linux-kernel - Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

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: <20150907175643.GB18079@leverpostej>
Date:	Mon, 7 Sep 2015 18:56:43 +0100
From:	Mark Rutland <mark.rutland@....com>
To:	Marc Zyngier <marc.zyngier@....com>
Cc:	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Will Deacon <Will.Deacon@....com>,
	Robin Murphy <Robin.Murphy@....com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	"arnd@...db.de" <arnd@...db.de>,
	"treding@...dia.com" <treding@...dia.com>,
	"ddaney@...iumnetworks.com" <ddaney@...iumnetworks.com>,
	"majun258@...wei.com" <majun258@...wei.com>,
	"thunder.leizhen@...wei.com" <thunder.leizhen@...wei.com>,
	"tirumalesh.chalamarla@...iumnetworks.com" 
	<tirumalesh.chalamarla@...iumnetworks.com>,
	"laurent.pinchart@...asonboard.com" 
	<laurent.pinchart@...asonboard.com>
Subject: Re: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

> > +PCI root complex
> > +================
> > +
> > +Optional properties
> > +-------------------
> > +
> > +- msi-map: Maps a Requester ID to an MSI controller and associated
> > +  msi-specifier data. The property is an arbitrary number of tuples of
> > +  (rid-base,msi-controller,msi-base,length), where:
> > +
> > +  * rid-base is a single cell describing the first RID matched by the entry.
> > +
> > +  * msi-controller is a single phandle to an MSI controller
> > +
> > +  * msi-base is an msi-specifier describing the msi-specifier produced for the
> > +    first RID matched by the entry.
> > +
> > +  * length is a single cell describing how many consecutive RIDs are matched
> > +    following the rid-base.
> > +
> > +  Any RID r in the interval [rid-base, rid-base + length) is associated with
> > +  the listed msi-controller, with the msi-specifier (r - rid-base + msi-base).
> > +
> > +- msi-map-mask: A mask to be applied to each Requester ID prior to being mapped
> > +  to an msi-specifier per the msi-map property.
> > +
> > +- msi-parent: Describes the MSI parent of the root complex itself. Where
> > +  the root complex and MSI controller do not pass sideband data with MSI
> > +  writes, this property may be used to describe the MSI controller(s)
> > +  used by PCI devices under the root complex, if defined as such in the
> > +  binding for the root complex.
> 
> Right, this is where I'd expect some details about #msi-cells. Is it
> meant to be ignored? The lack of symmetry between the PCI and non-PCI
> use cases feels a bit inelegant (not to mention that it precludes having
> an unified parser for both cases).

I would expect that the msi-parent's #msi-cells could be non-zero.

As I see it, there are three possible interpretations (and the choice
between these would be specific to a PCI root complex):

(1) Devices under the root complex generate MSIs via the MSI parent,
    using common sideband data described in the msi cells (and therefore
    cannot be distingushed from each other).

(2) The root complex itself generates MSIs via the MSI parent, with any
    sideband data described in the msi cells.

(3) Both the root complex and devices underneath it generate MSIs via
    the MSI parent, using common sideband data described in the msi
    cells (and therefore cannot be distinguished from each other).

Of these, (1) is the common case today, though (2) would be more in
keeping with how this style of property usually works.

I'm not sure how to capture that.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/