Messages in this thread | | | Subject | Re: [PATCH] sparc: Use generic pci_mmap_resource_range() | From | David Woodhouse <> | Date | Mon, 19 Feb 2018 15:24:18 +0000 |
| |
On Mon, 2018-02-19 at 09:49 -0500, David Miller wrote: > From: David Woodhouse <dwmw@amazon.co.uk> > Date: Mon, 19 Feb 2018 13:04:12 +0000 > > > > > Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for > > ARM64") added this generic function with the intent of using it > > everywhere and ultimately killing the old arch-specific implementations. > > > > Let's get on with that eradication... > > > > Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> > > David, the generic code is definitely doing different things.
Note that this is new "generic" code that I added last year, specifically to be able to obsolete all the old arch-specific code. The main reason for the change was to take host physical addresses, instead of converting to via legacy "pci_resource_to_user()" even for the new sysfs API.
The details are hazy right now — I deliberately held back the "fun" architectures and sent only the no-brainers in the first batch via Bjorn's PCI tree, and then promptly forgot about it for a year.
But I definitely *attempted* to ensure that the new code would cover all the requirements of SPARC and the various architectures that have lifted and modified the SPARC PCI code over the years.
> For one, the sparc specific code allows mmap'ing any address range > within a PCI bus device. The generic code does not allow that.
You mean any address range in a given PCI bus even if there is no actual device with a BAR at the corresponding address?
Would I be right to assume this was only available through the legacy procfs API? I think it should be possible to accommodate it, and it does look like I'd missed this requirement the first time round; thanks for pointing it out.[unhandled content-type:application/x-pkcs7-signature] | |