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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 30 Aug 2022 15:14:33 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
Cc:     Bjorn Helgaas <bhelgaas@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RESEND^2][PATCH v3] x86/PCI: Add support for the Intel
 82378ZB/82379AB (SIO/SIO.A) PIRQ router

On Mon, Aug 29, 2022 at 07:23:32PM +0100, Maciej W. Rozycki wrote:
> The Intel 82378ZB System I/O (SIO) and 82379AB System I/O APIC (SIO.A) 
> ISA bridges implement PCI interrupt steering with a PIRQ router[1][2] 
> that is exactly the same as that of the PIIX and ICH southbridges (or 
> actually the other way round, given that the SIO ASIC was there first).
> 
> An earlier version of the SIO, the 82378IB[3][4], does not implement PCI 
> interrupt steering however, so we need to exclude it by checking the low 
> nibble of the PCI Revision Identification Register[5][6] for being at 
> least 3.
> 
> There is a note in the 82379AB specification update[7] saying that the 
> device ID for that chip is 0x7, rather than 0x484 as stated in the 
> datasheet[8].  It looks like a red herring however, for no report has 
> been ever seen with that value quoted and it matches the documented 
> default value of the PCI Command Register, which comes next after the 
> PCI Device Identification Register, so it looks like a copy-&-paste 
> editorial mistake.
> 
> NB the 82378ZB has been commonly used with smaller DEC Alpha systems 
> with the contents of the Revision Identification Register reported as 
> one of 0x3, 0x43, or 0x84, so the masking of the high nibble seems 
> indeed right by empirical observation.  The value in the high nibble 
> might be either random, or depend on the batch, or correspond to some 
> other state such as reset straps.
> 
> References:
> 
> [1] "82378 System I/O (SIO)", Intel Corporation, Order Number: 
>     290473-004, December 1994, Section 4.1.26 "PIRQ[3:0]#--PIRQ Route 
>     Control Registers"
> 
> [2] "82378ZB System I/O (SIO) and 82379AB System I/O APIC (SIO.A)",
>     Intel Corporation, Order Number: 290571-001, March 1996, Section 
>     3.1.25. "PIRQ[3:0]#--PIRQ Route Control Registers", p. 48
> 
> [3] "82378IB System I/O (SIO)", Intel Corporation, Order Number:
>     290473-002, April 1993, Section 5.8.7.7 "Edge and Level Triggered
>     Modes"
> 
> [4] "82378IB to 82378ZB Errata Fix and Feature Enhancement Conversion
>     FOL933002-01",
>     <https://web.archive.org/web/19990421045433/http://support.intel.com/support/chipsets/420/8511.htm>
> 
> [5] "82378 System I/O (SIO)", Intel Corporation, Order Number: 
>     290473-004, December 1994, Section 4.1.5. "RID--Revision 
>     Identification Register"
> 
> [6] "82378ZB System I/O (SIO) and 82379AB System I/O APIC (SIO.A)",
>     Intel Corporation, Order Number: 290571-001, March 1996, Section 
>     3.1.5. "RID--Revision Identification Register", p. 34
> 
> [7] "Intel 82379AB (SIO.A) System I/O Component Specification Update", 
>     Intel Corporation, Order Number: 297734-001, May, 1996, "Component 
>     Identification via Programming Interface", p. 5
> 
> [8] "82378ZB System I/O (SIO) and 82379AB System I/O APIC (SIO.A)",
>     Intel Corporation, Order Number: 290571-001, March 1996, Section 
>     3.1.2. "DID--Device Identification Register", p. 33
> 
> Signed-off-by: Maciej W. Rozycki <macro@...am.me.uk>
> ---
> Hi,
> 
>  This patch was dropped from x86/irq due to a bug in a follow-up patch and 
> when resent it was not re-picked up along with the other patches for some 
> reason, so resending verbatim again after another re-verification, against 
> 6.0-rc2 as at yesterday (just before Linus's version bump).

I don't know anything about these IRQ routers, and Thomas has applied 
recent similar patches, so I assume he'll handle this.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ