The attached fixes the MCA version of the 3c509 and updates it to the
new MCA API.
Someone who knows PNP-ISA should migrate it to a probing API for that
too.
I've put the el3_probe back into Space.c for ISA only otherwise the
driver won't work for ISA (could someone with an ISA card test this).
James
On Fri, Feb 14, 2003 at 11:16:24AM +0100, Marc Zyngier wrote:
> # - Add driver for i82375 PCI/EISA bridge.
I believe this driver will work for any PCI/EISA bridge without
any changes, not only for i82375. Probably we need to look for a
class code rather than a device id.
Also, to get rid of that x86-ism I'd suggest something like
i82375_root.dev = &pdev->dev;
i82375_root.dev->driver_data = &i82375_root;
- i82375_root.bus_base_addr = 0; /* Warning, this is a x86-ism */
- i82375_root.res = &ioport_resource;
+ i82375_root.res = pdev->bus->resource[0];
+ i82375_root.bus_base_addr = pdev->bus->resource[0]->start;
i82375_root.slots = EISA_MAX_SLOTS;
Without that you'll have resource conflicts on multi-hose alphas.
Otherwise, the patch looks good to me.
Ivan.
>>>>> "Ivan" == Ivan Kokshaysky <[email protected]> writes:
Ivan> On Fri, Feb 14, 2003 at 11:16:24AM +0100, Marc Zyngier wrote:
>> # - Add driver for i82375 PCI/EISA bridge.
Ivan> I believe this driver will work for any PCI/EISA bridge without
Ivan> any changes, not only for i82375. Probably we need to look for a
Ivan> class code rather than a device id.
Unfortunately, the i82375 appears to be unclassified :
00:07.0 Non-VGA unclassified device: Intel Corp. 82375EB (rev 03)
I'll had PCI_CLASS_BRIDGE_EISA anyway, just in case.
Ivan> Also, to get rid of that x86-ism I'd suggest something like
Ivan> - i82375_root.bus_base_addr = 0; /* Warning, this is a x86-ism */
Ivan> - i82375_root.res = &ioport_resource;
Ivan> + i82375_root.res = pdev->bus->resource[0];
Ivan> + i82375_root.bus_base_addr = pdev->bus->resource[0]->start;
Ivan> i82375_root.slots = EISA_MAX_SLOTS;
Ivan> Without that you'll have resource conflicts on multi-hose alphas.
Applied, thanks.
M.
--
Places change, faces change. Life is so very strange.
On Fri, Feb 14, 2003 at 04:32:50PM +0100, Marc Zyngier wrote:
> Ivan> I believe this driver will work for any PCI/EISA bridge without
> Ivan> any changes, not only for i82375. Probably we need to look for a
> Ivan> class code rather than a device id.
>
> Unfortunately, the i82375 appears to be unclassified :
>
> 00:07.0 Non-VGA unclassified device: Intel Corp. 82375EB (rev 03)
We have this code in arch/alpha/kernel/pci.c for ages:
...
static void __init
quirk_eisa_bridge(struct pci_dev *dev)
{
dev->class = PCI_CLASS_BRIDGE_EISA << 8;
}
...
struct pci_fixup pcibios_fixups[] __initdata = {
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82375,
quirk_eisa_bridge },
...
I think it belongs in drivers/pci/quirks.c.
> I'll had PCI_CLASS_BRIDGE_EISA anyway, just in case.
Actually I thought of replacing "i82375" with "pci_eisa" everywhere
in your driver and
static struct pci_device_id pci_eisa_pci_tbl[] = {
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_BRIDGE_EISA << 8, 0xffff00, 0 },
{ 0, }
};
Ivan.
>>>>> "Ivan" == Ivan Kokshaysky <[email protected]> writes:
Ivan> We have this code in arch/alpha/kernel/pci.c for ages:
[...]
Ivan> I think it belongs in drivers/pci/quirks.c.
Indeed, this would be a good thing for x86 boxes.
Ivan> Actually I thought of replacing "i82375" with "pci_eisa" everywhere
Ivan> in your driver and
[..]
Ok, I'll update the patch tonight, and will repost it.
Thanks,
M.
--
Places change, faces change. Life is so very strange.
On Fri, Feb 14, 2003 at 11:16:24AM +0100, Marc Zyngier wrote:
> James, LKML,
>
> Here is the latest round of EISA/sysfs hacking.
BTW, could you fix eisa_driver_register to properly return 0 on
sucess instead of 1?
>>>>> "Christoph" == Christoph Hellwig <[email protected]> writes:
Christoph> BTW, could you fix eisa_driver_register to properly return
Christoph> 0 on sucess instead of 1?
Huhhh... Nice catch.
Thanks,
M.
--
Places change, faces change. Life is so very strange.