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

[John Garry]

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.

[...]

> > > > > [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@xxxxxxxxxx
>
> 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.

Thanks,
John

> Lorenzo
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> .