linux-kernel - Re: [PATCH v8 3/9] pci: Introduce pci_register_io

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: <5997020.x4BWezXjnq@wuerfel>
Date:	Wed, 02 Jul 2014 16:58:58 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Liviu Dudau <Liviu.Dudau@....com>
Cc:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Liviu Dudau <liviu@...au.co.uk>,
	Sinan Kaya <okaya@...eaurora.org>,
	linaro-kernel <linaro-kernel@...ts.linaro.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Device Tree ML <devicetree@...r.kernel.org>,
	linux-pci <linux-pci@...r.kernel.org>,
	Jingoo Han <jg1.han@...sung.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Will Deacon <Will.Deacon@....com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Tanmay Inamdar <tinamdar@....com>,
	Suravee Suthikulanit <suravee.suthikulpanit@....com>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: [PATCH v8 3/9] pci: Introduce pci_register_io_range() helper function.

On Wednesday 02 July 2014 15:23:03 Liviu Dudau wrote:
> > 
> > Your solution looks correct to me, just using different
> > tradeoffs to what I was expecting: You get a working pci_address_to_pio()
> > function, which is probably never needed, but in turn you need to
> > keep the state of each host bridge in a global list.
> 
> Just a reminder that with my patchset I *do* start using pci_address_to_pio()
> in order to correctly parse the IO ranges from DT.

Yes, what I meant is that it would be easier not to do that. All existing
drivers expect of_pci_range_to_resource() to return the CPU address for
an I/O space register, not the Linux I/O port number that we want to 
pass to the PCI core. This is suboptimal because it's not obvious how
it works, but it lets us get away without an extra registration step.
Once all probe functions in PCI host drivers have been changed to the
of_create_pci_host_bridge, that should not matter any more, because
there is only one place left that calls it and we only have to get it
right once.

Also, when you change that of_pci_range_to_resource, you also have to 
audit all callers of that function and ensure they can deal with the new
behavior.

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