linux-kernel - Re: [PATCH 3/6] pci, thunder: Add PCIe host controller devicetree 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: <CAErSpo5rhL7pLha-yWt7sZUBmAnwA6FkacL+sWXBKkSzsuC7Sg@mail.gmail.com>
Date:	Thu, 25 Sep 2014 14:10:33 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Sunil Kovvuri <sunil.kovvuri@...il.com>,
	LAKML <linux-arm-kernel@...ts.infradead.org>,
	Robert Richter <rric@...nel.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	linux-pci <linux-pci@...r.kernel.org>,
	Liviu Dudau <liviu.dudau@....com>,
	LKML <linux-kernel@...r.kernel.org>,
	Robert Richter <rrichter@...ium.com>,
	Sunil Goutham <sgoutham@...ium.com>
Subject: Re: [PATCH 3/6] pci, thunder: Add PCIe host controller devicetree bindings

On Thu, Sep 25, 2014 at 1:26 PM, Arnd Bergmann <arnd@...db.de> wrote:
> On Thursday 25 September 2014, Bjorn Helgaas wrote:
>> On Thu, Sep 25, 2014 at 1:31 AM, Arnd Bergmann <arnd@...db.de> wrote:
>> > On Thursday 25 September 2014 00:37:00 Sunil Kovvuri wrote:
>> >> On Thu, Sep 25, 2014 at 12:04 AM, Arnd Bergmann <arnd@...db.de> wrote:
>> >> > On Wednesday 24 September 2014 23:34:04 Sunil Kovvuri wrote:
>>
>> >> >> All on-board PCI devices connected to this PCI controller have fixed resources
>> >> >> and doesn't have to be allocated/reassigned. Some of these devices are
>> >> >> SRIOV based.
>> >> >
>> >> > I think you need to mark the ones that are nonrelocatable with flag
>> >> > 0x80000000, otherwise the PCI core might decide to reassign them.
>> >>
>> >> Is this flag part of DT pci node properties ?
>> >> I am using IORESOURCE_PCI_FIXED flag. Its there in other patches of
>> >> the same series.
>> >
>> > Ah, right. I checked the source code again and it seems that we don't handle
>> > this right at the moment. I think a range that has the nonrelocatable
>> > flag set should be used for IORESOURCE_PCI_FIXED mappings without any
>> > host specific code, but that needs to be implemented in common code.
>>
>> What connection do you envision between nonrelocatable ranges and
>> IORESOURCE_PCI_FIXED?  I don't know what a nonrelocatable range is,
>> but for IORESOURCE_PCI_FIXED, all I intend is that the PCI core should
>> not try to assign a different address, e.g., because the BAR is
>> read-only or because it's a legacy IDE/VGA/etc. range for which there
>> is no BAR at all.
>
> I think that is exactly the definition of the nonrelocatable flag
> in http://www.openfirmware.org/1275/bindings/pci/pci2_1.pdf
>
> The example given in section 11.1.2 is for a VGA device that has some
> relocatable BARs and some nonrelocatable BARs.

OK.  You said "a range that has the nonrelocatable flag set should be
used for IORESOURCE_PCI_FIXED mappings."  I thought you meant that the
range was a bridge window, and somehow PCI_FIXED BARs should be put in
that window.

But maybe you meant that nonrelocatable ranges should have the
IORESOURCE_PCI_FIXED bit set in their struct resources.  That would
mean we couldn't move the window, but we could put relocatable BARs
inside the window.

What needs to be implemented?  Just the code that would set
IORESOURCE_PCI_FIXED for nonrelocatable ranges?

Bjorn
--
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/