Searched hist:82375 (Results 1 - 2 of 2) sorted by relevance
| /linux-master/drivers/eisa/ | ||
| H A D | pci_eisa.c | diff 2cfda637 Mon Apr 01 11:48:59 MDT 2013 Yinghai Lu <yinghai@kernel.org> EISA/PCI: Fix bus res reference Matthew found that 3.8.3 is having problems with an old (ancient) PCI-to-EISA bridge, the Intel 82375. It worked with the 3.2 kernel. He identified the 82375, but doesn't assign the struct resource *res pointer inside the struct eisa_root_device, and panics. pci_eisa_init() was using bus->resource[] directly instead of pci_bus_resource_n(). The bus->resource[] array is a PCI-internal implementation detail, and after commit 45ca9e97 (PCI: add helpers for building PCI bus resource lists) and commit 0efd5aab (PCI: add struct pci_host_bridge_window with CPU/bus address offset), bus->resource[] is not used for PCI root buses any more. The 82375 is a subtractive-decode PCI device, so handle it the same way we handle PCI-PCI bridges in subtractive-decode mode in pci_read_bridge_bases(). [bhelgaas: changelog] Reported-by: Matthew Whitehead <mwhitehe@redhat.com> Tested-by: Matthew Whitehead <mwhitehe@redhat.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v3.3+ diff 2cfda637 Mon Apr 01 11:48:59 MDT 2013 Yinghai Lu <yinghai@kernel.org> EISA/PCI: Fix bus res reference Matthew found that 3.8.3 is having problems with an old (ancient) PCI-to-EISA bridge, the Intel 82375. It worked with the 3.2 kernel. He identified the 82375, but doesn't assign the struct resource *res pointer inside the struct eisa_root_device, and panics. pci_eisa_init() was using bus->resource[] directly instead of pci_bus_resource_n(). The bus->resource[] array is a PCI-internal implementation detail, and after commit 45ca9e97 (PCI: add helpers for building PCI bus resource lists) and commit 0efd5aab (PCI: add struct pci_host_bridge_window with CPU/bus address offset), bus->resource[] is not used for PCI root buses any more. The 82375 is a subtractive-decode PCI device, so handle it the same way we handle PCI-PCI bridges in subtractive-decode mode in pci_read_bridge_bases(). [bhelgaas: changelog] Reported-by: Matthew Whitehead <mwhitehe@redhat.com> Tested-by: Matthew Whitehead <mwhitehe@redhat.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v3.3+ diff 2cfda637 Mon Apr 01 11:48:59 MDT 2013 Yinghai Lu <yinghai@kernel.org> EISA/PCI: Fix bus res reference Matthew found that 3.8.3 is having problems with an old (ancient) PCI-to-EISA bridge, the Intel 82375. It worked with the 3.2 kernel. He identified the 82375, but doesn't assign the struct resource *res pointer inside the struct eisa_root_device, and panics. pci_eisa_init() was using bus->resource[] directly instead of pci_bus_resource_n(). The bus->resource[] array is a PCI-internal implementation detail, and after commit 45ca9e97 (PCI: add helpers for building PCI bus resource lists) and commit 0efd5aab (PCI: add struct pci_host_bridge_window with CPU/bus address offset), bus->resource[] is not used for PCI root buses any more. The 82375 is a subtractive-decode PCI device, so handle it the same way we handle PCI-PCI bridges in subtractive-decode mode in pci_read_bridge_bases(). [bhelgaas: changelog] Reported-by: Matthew Whitehead <mwhitehe@redhat.com> Tested-by: Matthew Whitehead <mwhitehe@redhat.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org # v3.3+ |
| /linux-master/arch/x86/pci/ | ||
| H A D | irq.c | diff 6b79164f Mon Jul 19 21:27:59 MDT 2021 Maciej W. Rozycki <macro@orcam.me.uk> x86/PCI: Add support for the Intel 82374EB/82374SB (ESC) PIRQ router The Intel 82374EB/82374SB EISA System Component (ESC) devices implement PCI interrupt steering with a PIRQ router[1] in the form of four PIRQ Route Control registers, available in the port I/O space accessible indirectly via the index/data register pair at 0x22/0x23, located at indices 0x60/0x61/0x62/0x63 for the PIRQ0/1/2/3# lines respectively. The semantics is the same as with the PIIX router, however it is not clear if BIOSes use register indices or line numbers as the cookie to identify PCI interrupts in their routing tables and therefore support either scheme. Accesses to the port I/O space concerned here need to be unlocked by writing the value of 0x0f to the ESC ID Register at index 0x02 beforehand[2]. Do so then and then lock access after use for safety. This locking could possibly interfere with accesses to the Intel MP spec IMCR register, implemented by the 82374SB variant of the ESC only as the PCI/APIC Control Register at index 0x70[3], for which leaving access to the configuration space concerned unlocked may have been a requirement for the BIOS to remain compliant with the MP spec. However we only poke at the IMCR register if the APIC mode is used, in which case the PIRQ router is not, so this arrangement is not going to interfere with IMCR access code. The ESC is implemented as a part of the combined southbridge also made of 82375EB/82375SB PCI-EISA Bridge (PCEB) and does itself appear in the PCI configuration space. Use the PCEB's device identification then for determining the presence of the ESC. References: [1] "82374EB/82374SB EISA System Component (ESC)", Intel Corporation, Order Number: 290476-004, March 1996, Section 3.1.12 "PIRQ[0:3]#--PIRQ Route Control Registers", pp. 44-45 [2] same, Section 3.1.1 "ESCID--ESC ID Register", p. 36 [3] same, Section 3.1.17 "PAC--PCI/APIC Control Register", p. 47 Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2107192023450.9461@angie.orcam.me.uk diff 6b79164f Mon Jul 19 21:27:59 MDT 2021 Maciej W. Rozycki <macro@orcam.me.uk> x86/PCI: Add support for the Intel 82374EB/82374SB (ESC) PIRQ router The Intel 82374EB/82374SB EISA System Component (ESC) devices implement PCI interrupt steering with a PIRQ router[1] in the form of four PIRQ Route Control registers, available in the port I/O space accessible indirectly via the index/data register pair at 0x22/0x23, located at indices 0x60/0x61/0x62/0x63 for the PIRQ0/1/2/3# lines respectively. The semantics is the same as with the PIIX router, however it is not clear if BIOSes use register indices or line numbers as the cookie to identify PCI interrupts in their routing tables and therefore support either scheme. Accesses to the port I/O space concerned here need to be unlocked by writing the value of 0x0f to the ESC ID Register at index 0x02 beforehand[2]. Do so then and then lock access after use for safety. This locking could possibly interfere with accesses to the Intel MP spec IMCR register, implemented by the 82374SB variant of the ESC only as the PCI/APIC Control Register at index 0x70[3], for which leaving access to the configuration space concerned unlocked may have been a requirement for the BIOS to remain compliant with the MP spec. However we only poke at the IMCR register if the APIC mode is used, in which case the PIRQ router is not, so this arrangement is not going to interfere with IMCR access code. The ESC is implemented as a part of the combined southbridge also made of 82375EB/82375SB PCI-EISA Bridge (PCEB) and does itself appear in the PCI configuration space. Use the PCEB's device identification then for determining the presence of the ESC. References: [1] "82374EB/82374SB EISA System Component (ESC)", Intel Corporation, Order Number: 290476-004, March 1996, Section 3.1.12 "PIRQ[0:3]#--PIRQ Route Control Registers", pp. 44-45 [2] same, Section 3.1.1 "ESCID--ESC ID Register", p. 36 [3] same, Section 3.1.17 "PAC--PCI/APIC Control Register", p. 47 Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2107192023450.9461@angie.orcam.me.uk |
Completed in 238 milliseconds