lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 2 Nov 2021 12:35:41 +0000 (GMT)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Pali Rohár <pali@...nel.org>
cc:     Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Russell King <linux@...linux.org.uk>,
        Andrew Lunn <andrew@...n.ch>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
        Gregory Clement <gregory.clement@...tlin.com>,
        Jason Gunthorpe <jgg@...dia.com>,
        linux-arm-kernel@...ts.infradead.org, linux-mips@...r.kernel.org,
        linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCI: Marvell: Update PCIe fixup

On Tue, 2 Nov 2021, Pali Rohár wrote:

> > > >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.

 Umm, PCIe is so different hardware-wise from PCI I doubt there's any 
chance for errata to be carried across.  Plus the MIPS SysAD bus is so 
different from other CPU buses.  And we're talking 20+ years old Galileo 
devices here.

 None of the Galileo system controllers I came across had the class code 
set incorrectly.

> > > 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.

 For the record here's one from a core card used with a Malta (as with 
arch/mips/pci/fixup-malta.c); it has a newer 64120A chip (marked as an 
engineering sample BTW):

00:00.0 Host bridge: Marvell Technology Group Ltd. GT-64120/64120A/64121A System Controller (rev 11)
00: ab 11 20 46 47 01 80 22 11 00 00 06 00 20 00 00
10: 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00
20: 00 00 e0 1b 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The lack of a quirk with a platform does not mean it cannot have a certain 
PCI/e device.

 As I recall various Atlas/Malta core cards had any of the three device 
variants covered by this vendor:device ID and later batches were actually 
indeed marked Marvell rather than Galileo.

  Maciej

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ