On Mon, 2018-02-19 at 09:49 -0500, David Miller wrote:
> From: David Woodhouse <dwmw@xxxxxxxxxxxx>
> 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@xxxxxxxxxxxx>
>
> 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.Attachment:
smime.p7s
Description: S/MIME cryptographic signature
