On Tuesday 02 November 2021 10:47:00 Thomas Bogendoerfer wrote:
> On Tue, Nov 02, 2021 at 10:02:46AM +0100, Pali Rohár wrote:
> > On Tuesday 02 November 2021 09:42:41 Thomas Bogendoerfer wrote:
> > > On Mon, Nov 01, 2021 at 04:04:05PM +0100, Pali Rohár wrote:
> > > > - The code relies on rc_pci_fixup being called, which only happens
> > > > when CONFIG_PCI_QUIRKS is enabled, so add that to Kconfig. Omitting
> > > > this causes a booting failure with a non-obvious cause.
> > > > - Update rc_pci_fixup to set the class properly, copying the
> > > > more modern style from other places
> > > > - Correct the rc_pci_fixup comment
> > > >
> > > > This patch just re-applies commit 1dc831bf53fd ("ARM: Kirkwood: Update
> > > > PCI-E fixup") for all other Marvell platforms which use same buggy PCIe
> > > > controller.
> > > > [..]
> > >
> > > > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> > > > index 771ca53af06d..c8d51bd20b84 100644
> > > > --- a/arch/mips/Kconfig
> > > > +++ b/arch/mips/Kconfig
> > > > @@ -346,6 +346,7 @@ config MIPS_COBALT
> > > > select CEVT_GT641XX
> > > > select DMA_NONCOHERENT
> > > > select FORCE_PCI
> > > > + select PCI_QUIRKS
> > > > select I8253
> > > > select I8259
> > > > select IRQ_MIPS_CPU
> > >
> > > this is enabled by default, via drivers/pci/Kconfig
> >
> > IIRC 'default y' can be disabled but 'select' not.
>
> overruled only if CONFIG_EXPERT is enabled, which IMHO sounds good enough.
Well, if you think this is not needed (anymore), I can drop it. I just
reapplied original fix 1dc831bf53fd.
> > > config PCI_QUIRKS
> > > default y
> > > bool "Enable PCI quirk workarounds" if EXPERT
> > > help
> > > This enables workarounds for various PCI chipset bugs/quirks.
> > > Disable this only if your target machine is unaffected by PCI
> > > quirks.
> > >
> > > > diff --git a/arch/mips/pci/fixup-cobalt.c b/arch/mips/pci/fixup-cobalt.c
> > > > index 44be65c3e6bb..202f3a0bd97d 100644
> > > > --- a/arch/mips/pci/fixup-cobalt.c
> > > > +++ b/arch/mips/pci/fixup-cobalt.c
> > > > @@ -36,6 +36,12 @@
> > > > #define VIA_COBALT_BRD_ID_REG 0x94
> > > > #define VIA_COBALT_BRD_REG_to_ID(reg) ((unsigned char)(reg) >> 4)
> > > >
> > > > +/*
> > > > + * The root complex has a hardwired class of PCI_CLASS_MEMORY_OTHER, when it
> > > > + * is operating as a root complex this needs to be switched to
> > > > + * PCI_CLASS_BRIDGE_HOST or Linux will errantly try to process the BAR's on
> > > > + * the device. Decoding setup is handled by the orion code.
> > > > + */
> > > > static void qube_raq_galileo_early_fixup(struct pci_dev *dev)
> > > > {
> > > > if (dev->devfn == PCI_DEVFN(0, 0) &&
> > >
> > > this is not a PCIe controller, so how is this patch related ?
> >
> > I put that comment into all quirk code which is related to Marvell PCIe
> > device XX:00.0 and changes PCI class type from PCI_CLASS_MEMORY_OTHER to
> > PCI_CLASS_BRIDGE_HOST.
> >
> > >From all what I saw, I'm sure that this device with this specific
> > characteristics is really (non-compliant) Marvell PCIe controller.
>
> just nitpicking, it's a Galileo PCI bridge and not PCIe.
Marvell acquired Galileo Technology in the past, so it is possible that
this bad design is originated in Galileo. And maybe same for PCIe from
PCI. At least PCI vendor id for all (new) PCIe controllers is this one.
> > But I do not have this hardware to verify it.
>
> I still have a few Cobalt systems here.
Perfect! It would help if you could provide 'lspci -nn -vv' output from
that system. In case you have very old version of lspci on that system
you could try to run it with '-xxxx' (or '-xxx') which prints hexdump
and I can parse it with local lspci.
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea. [ RFC1925, 2.3 ]
