I have a board with a ServerWorks CIOB-X2 bridge on it (2 in fact) that
is not having the secondary buses off it correctly discovered with
2.6.38. There seems to have been some discussion about this back in
2001, when a patch very similar to the below was being discussed about
2.4. As far as I can tell the opinion was that the PCI BIOS should be
providing this information, and I can't see this quirk in git history at
all.
My board does not have a standard BIOS, so pcibios_last_bus is not
appropriately updated by the PCI BIOS routines. This quirk allows the
detection of the 8 buses that are behind the 2 bridges on my board.
Without it none of them are discovered.
(Unfortunately the unique PCI device I could potentially use as a more
specific quirk hook is behind one of these bridges, and the only useful
identifying info from the BIOS is in the MPTABLE, which doesn't appear
to be easily usable for quirks. This quirk could be tightened up to just
the CIOB-X2 entry and suit my needs, but I left the fuller table as
that's what the original patch I found had associated with it.)
Signed-Off-By: Jonathan McDowell <[email protected]>
-----
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 6dd8955..12a0305f 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -521,3 +521,35 @@ static void sb600_disable_hpet_bar(struct pci_dev *dev)
}
}
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_ATI, 0x4385, sb600_disable_hpet_bar);
+
+/*
+ * ServerWorks host bridges -- Find and scan all secondary buses.
+ * Register 0x44 contains first, 0x45 last bus number routed there.
+ *
+ */
+static void __init pci_fixup_serverworks(struct pci_dev *dev)
+{
+ u8 busno1, busno2;
+
+ pci_read_config_byte(dev, 0x44, &busno1);
+ pci_read_config_byte(dev, 0x45, &busno2);
+ if (busno2 < busno1)
+ busno2 = busno1;
+ if (busno2 > pcibios_last_bus) {
+ pcibios_last_bus = busno2;
+ dev_info(&dev->dev, "ServerWorks host bridge: last bus %02x\n",
+ pcibios_last_bus);
+ }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SERVERWORKS,
+ PCI_DEVICE_ID_SERVERWORKS_HE, pci_fixup_serverworks);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SERVERWORKS,
+ /* CIOB */ 0x006, pci_fixup_serverworks);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SERVERWORKS,
+ PCI_DEVICE_ID_SERVERWORKS_LE, pci_fixup_serverworks);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SERVERWORKS,
+ /* CMIC_HE */ 0x0011, pci_fixup_serverworks);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SERVERWORKS,
+ /* CMIC_LE_IMBB */ 0x0000, pci_fixup_serverworks);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SERVERWORKS,
+ /* CIOBX2 */ 0x0101, pci_fixup_serverworks);
-----
J.
--
Most people are descended from apes. Redheads are descended from cats.
On Wed, Mar 23, 2011 at 9:36 PM, Jonathan McDowell <[email protected]> wrote:
> I have a board with a ServerWorks CIOB-X2 bridge on it (2 in fact) that
> is not having the secondary buses off it correctly discovered with
> 2.6.38.
Is this a regression? If so, what is the newest kernel that still
worked? Can you include a dmesg log? I assume that since you don't
have a standard BIOS, you don't have ACPI?
Bjorn
On Wed, Mar 23, 2011 at 10:50:20PM -0700, Bjorn Helgaas wrote:
> On Wed, Mar 23, 2011 at 9:36 PM, Jonathan McDowell <[email protected]> wrote:
> > I have a board with a ServerWorks CIOB-X2 bridge on it (2 in fact) that
> > is not having the secondary buses off it correctly discovered with
> > 2.6.38.
>
> Is this a regression? If so, what is the newest kernel that still
> worked?
No, it's not strictly a regression; it's never worked without a patch
similar to this under 2.6. I'm trying to get us moved to a more recent
2.6 and working out what the minimal set patches are necessary against
mainline for that to work.
> Can you include a dmesg log?
Sure, attached.
> I assume that since you don't have a standard BIOS, you don't have
> ACPI?
Nope. Nor DMI. As previously mentioned there is a custom ASIC, but it's
hidden behind these bridges.
J.
--
xmpp:[email protected]
"A real revolution begins at learning. If you're not angry, you're
not paying attention." -- Tim McGrath
On Thu, Mar 24, 2011 at 05:58:30PM -0700, Bjorn Helgaas wrote:
> On Thu, Mar 24, 2011 at 11:27 AM, Jonathan McDowell
> <[email protected]>wrote:
>
> > On Wed, Mar 23, 2011 at 10:50:20PM -0700, Bjorn Helgaas wrote:
>
> > > I assume that since you don't have a standard BIOS, you don't have
> > > ACPI?
> >
> > Nope. Nor DMI. As previously mentioned there is a custom ASIC, but
> > it's hidden behind these bridges.
> >
>
> Thanks. Looks like your box doesn't even have PCI BIOS, so
> pcibios_last_bus == -1 until pci_fixup_serverworks() updates it, so we
> only scan bus 00.
>
> Another option would be to boot with "pci=lastbus=0xff". If you just
> have a box or two, that might be the easiest solution, but I guess I'm
> not opposed to a quirk like this. It's a firmware workaround, not a
> hardware bug, and the message is irrelevant and possibly distracting
> on machines with decent firmware, but it's not terrible.
I've managed to get detection of the non-standard BIOS working, so I can
actually quirk much more specifically now for my purposes. I don't
believe there's any need to take this upstream if no one else is
reporting problems.
J.
--
"This sentence no verb." -- Robin Stevens, ox.talk
This .sig brought to you by the letter T and the number 42
Product of the Republic of HuggieTag