On Mon, Mar 22, 2021 at 04:33:14PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 22, 2021 at 04:18:23PM +0100, Christoph Hellwig wrote:
> > On Mon, Mar 22, 2021 at 03:15:03PM +0000, Russell King - ARM Linux admin wrote:
> > > It gets worse than that though - due to a change to remove
> > > pcibios_min_io from the generic code, moving it into the ARM
> > > architecture code, this has caused a regression that prevents the
> > > legacy resources being registered against the bus resource. So even
> > > if they are there, they cause probe failures. I haven't found a
> > > reasonable way to solve this yet, but until there is, there is no
> > > way that the PATA driver can be used as the "legacy mode" support
> > > is effectively done via the PCI code assigning virtual IO port
> > > resources.
> > >
> > > I'm quite surprised that the CY82C693 even works on Alpha - I've
> > > asked for a lspci for that last week but nothing has yet been
> > > forthcoming from whoever responded to your patch for Alpha - so I
> > > can't compare what I'm seeing with what's happening with Alpha.
> >
> > That sounds like something we could fix with a quirk for function 2
> > in the PCI resource assignment code. Can you show what vendor and
> > device ID function 2 has so that I could try to come up with one?
>
> Something like this:
That solves the problem for the IDE driver, which knows how to deal
with legacy mode, but not the PATA driver, which doesn't. The PATA
driver needs these resources.
As I say, having these resources presents a problem on ARM. A previous
commit (3c5d1699887b) changed the way the bus resources are setup which
results in /proc/ioports containing:
00000000-0000000f : dma1
00000020-0000003f : pic1
00000060-0000006f : i8042
00000070-00000073 : rtc_cmos
00000070-00000073 : rtc0
00000080-0000008f : dma low page
000000a0-000000bf : pic2
000000c0-000000df : dma2
00000213-00000213 : ISAPnP
000002f8-000002ff : serial8250.0
000002f8-000002ff : serial
000003c0-000003df : vga+
000003f8-000003ff : serial8250.0
000003f8-000003ff : serial
00000480-0000048f : dma high page
00000a79-00000a79 : isapnp write
00001000-0000ffff : PCI0 I/O
00001000-0000107f : 0000:00:08.0
00001000-0000107f : 3c59x
00001080-0000108f : 0000:00:06.1
00001090-0000109f : 0000:00:07.0
00001090-0000109f : pata_it821x
000010a0-000010a7 : 0000:00:07.0
000010a0-000010a7 : pata_it821x
000010a8-000010af : 0000:00:07.0
000010a8-000010af : pata_it821x
000010b0-000010b3 : 0000:00:07.0
000010b0-000010b3 : pata_it821x
000010b4-000010b7 : 0000:00:07.0
000010b4-000010b7 : pata_it821x
The "PCI0 I/O" resource is the bus level resource, and the legacy
resources can not be claimed against that.
Without these resources, the PATA cypress driver doesn't work.
As I said previously, the reason this regression was not picked up
earlier is because I don't upgrade the kernel on this machine very
often; the machine has had uptimes into thousands of days.
I need to try reverting Rob's commit to find out if anything breaks
on this platform - it's completely wrong from a technical point of
view for any case where we have a PCI southbridge, since the
southbridge provides ISA based resources. I'm not entirely sure
what the point of it was, since we still have the PCIBIOS_MIN_IO
macro which still uses pcibios_min_io.
I'm looking at some of the other changes Rob made back at that time
which also look wrong, such as 8ef6e6201b26 which has the effect of
locating the 21285 IO resources to PCI address 0, over the top of
the ISA southbridge resources. I've no idea what Rob was thinking
when he removed the csrio allocation code in that commit, but
looking at it to day, it's soo obviously wrong even to a casual
glance.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
