linux-kernel - Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

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 for Android: free password hash cracker in your pocket

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

Message-ID: <b3750d7918712f6035ea875d90c25471.squirrel@www.codeaurora.org>
Date:	Mon, 21 Dec 2015 15:26:14 -0000
From:	Okaya@...eaurora.org
To:	"Arnd Bergmann" <arnd@...db.de>
Cc:	"Tomasz Nowicki" <tn@...ihalf.com>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@....com>,
	okaya@...eaurora.org, bhelgaas@...gle.com, will.deacon@....com,
	catalin.marinas@....com, rjw@...ysocki.net, hanjun.guo@...aro.org,
	jiang.liu@...ux.intel.com, stefano.stabellini@...citrix.com,
	robert.richter@...iumnetworks.com, mw@...ihalf.com,
	liviu.dudau@....com, ddaney@...iumnetworks.com, tglx@...utronix.de,
	wangyijing@...wei.com, suravee.suthikulpanit@....com,
	msalter@...hat.com, linux-pci@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org, linaro-acpi@...ts.linaro.org,
	jchandra@...adcom.com, jcm@...hat.com
Subject: Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI
 hostbridge init based on ACPI

> On Monday 21 December 2015, Tomasz Nowicki wrote:
>> On 21.12.2015 13:10, Lorenzo Pieralisi wrote:
>> > On Fri, Dec 18, 2015 at 06:56:39PM +0000, okaya@...eaurora.org wrote:
>
>> >> I have multiple root ports with the same IO port configuration in the
>> >> current ACPI table.
>> >>
>> >> Root port 0 = IO range 0x1000-0x10FFF
>> >> Root port 1 = IO range 0x1000-0x10FFF
>> >> Root port 2 = IO range 0x1000-0x10FFF
>> >
>> > It is fine. You end up mapping for each of those a 4k window of the
>> > virtual address space allocated to IO and that's what you will have in
>> > the kernel PCI resources (not in the HW BARs though). If that was a
>> problem
>> > it would be even for the current DT host controllers eg:
>> >
>> > arch/arm64/boot/dts/apm/apm-storm.dtsi
>> >
>> > it should not be (again I will let Arnd comment on this since he may
>> be
>> > aware of issues encountered on other arches/platforms).
>> >
>>
>> Root port 0 = IO range 0x1000-0x10FFF
>> Root port 1 = IO range 0x1000-0x10FFF
>> Root port 2 = IO range 0x1000-0x10FFF
>>
>> If above ranges are mapped into different CPU windows, then yes, it is
>> fine.
>
> Ideally, they should all be the same CPU address so we only have to map
> the window
> once, each device gets an address below 64K, and you can have legacy port
> numbers
> (below 4K) on any bus, which is required to make certain GPUs work.
>
> I haven't actually seen anyone do that on ARM though, every implementation
> so
> far has a separate mapping per host bridge, and we can cope with that too,
> and we can live with either overlapping bus addresses or unique bus
> addresses,
> any of them can be expressed by the PCI core in Linux, we just have to
> make sure
> that we correctly translate the firmware tables into our internal
> structures.
>
> 	Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Thanks, I won't be touching the acpi tables then and I will assume the
hack had a problem. It was trying to remap the io range of the second root
port  to the first port io address map.

I was getting a warning from resource.c

Btw, when I tested the io ranges before, kernel didn't accept anything
below 1k like 0. That is why my range starts at 1k.

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