Re: [RFC PATCH v2 1/3] resource: Request IO port regions from children of ioport_resource

[Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>]

On Fri, Mar 29, 2019 at 10:42:17AM +0000, John Garry wrote:
> On 28/03/2019 17:46, Lorenzo Pieralisi wrote:
> >On Tue, Mar 26, 2019 at 05:48:10PM -0500, Bjorn Helgaas wrote:
> >
> >[...]
> >
> 
> Hi Lorenzo,
> 
> 
> >>I'm not convinced about this last sentence.
> >>
> >>It's true that on most modern systems, including that Intel PCH, the
> >>Super I/O controller is attached via an LPC bridge on a PCI bus.
> >>
> >>But I don't think it's an actual requirement that PCI be involved.
> >>There certainly once were systems, e.g., PC/104, that had ISA devices
> >>but no PCI.  Maybe Super I/O attached via ISA is obsolete enough that
> >>we don't care any more, but I really don't know.
> >>
> >>>>On x86, I think inb/inw/inl from a port where nothing responds
> >>>>probably just returns ~0, and outb/outw/outl just get dropped.
> >>>>Shouldn't arm64 do the same, without crashing?
> >>>
> >>>That would be ideal and we're doing something similar in patch 2/3.
> >>>
> >>>So on ARM64 we have to IO remap the PCI IO resource. If this mapping is not
> >>>done (due to no PCI host), then any inb/inw/inl calls will crash the system.
> >>
> >>My take is that ARM64 is responsible for implementing inb/inw/inl in
> >>such a way that they don't crash.  I don't think it's practical to
> >>update all the old ISA drivers or even the core code to work around
> >>that.
> >
> >The problem is that those drivers are accessing a resource that does not
> >exist in practice, it is taken for granted on x86 systems (and on IA64)
> >because that was an actual bus (actual or emulated) and was made part of
> >the architecture. The ISA space is not necessarily tied to PCI,
> >at least not always.
> >
> >Side note: these drivers can't be compiled on PPC, it would be
> >good to understand why, I have a hunch it can be related.
> 
> I mentioned this earlier:
> 
> I saw that in commits like 746cdfbf01c0 ("hwmon: Avoid building drivers
> forpowerpc that read/write ISA addresses"), PPC would not build these
> drivers, as, like arm, it has no native ISA.
> 
> However I still don't think just avoiding compiling these drivers for
> certain archs solves the problem.

No it does not but I would like to understand how relevant is fixing
those drivers (that should not use ISA IO space without first claiming
their resources, for the records) given that PPC did not even try and
apparently that's not a problem.

> 
> [...]
> 
> >>>>>[1] https://www.spinics.net/lists/linux-pci/msg49821.html
> >>>>
> >>>>Please use a https://lore.kernel.org/ URL instead of spinics.net.
> >>>
> >>>ok, I hope that I can find this old thread.
> >>
> >>The beauty of lore.kernel.org is that the URL contains the Message-ID, so
> >>it's easy build the URL and it would contain useful information even if
> >>lore.kernel.org disappeared:
> >>
> >>https://lore.kernel.org/linux-pci/56F209A9.4040304@huawei.com
> >
> >Yes, the bottom line is what Arnd outlined in the thread above.
> >
> >ISA IO port space is not necessarily PCI but it does not exist
> >architecturally on ARM systems.
> >
> >Taking the example of IA64, the ISA space is memory mapped (like any
> >other arch except for x86) but IIUC the virtual mapping for the ISA
> >port space _always_ exists on IA64 so this issue won't happen.
> >
> >Arnd pointed out a solution in the thread above but I need to check
> >if that's feasible.
> 
> I doubt that it can work now.
> 
> Since we when introduced the concept of logical PIO space, this IO space
> became sparely populated by 2 regions - MMIO and indirect IO - so we cannot
> grow it as we map in regions. I also don't think it works for when we IO
> unmap regions.

I do not have the full picture but I suspect that, apart from x86/IA64,
this is a common issue across architectures, I am trying to untangle
how ARM 32-bit deals with this (if it does).

Lorenzo