Re: 2.5.20 - Xircom PCI Cardbus doesn't work

Kai Germaschewski
2002-06-15T22:51:34Z

On Sat, 15 Jun 2002, Jeff Garzik wrote:

> That seems ok to me. Note that we still want
> pci_{enable,disable}_device to exist (as mentioned in the mail to
> Kai)... I'm fine with moving a lot of pci_enable_device's duties to
> pci_{assign,request,release}_{irq,io,mem} as long as we don't kill it
> completely.

I'm aware that something like pci_enable_device() still is necessary, but
I moved this part of the functionality into pci_request_*.

pci_enable_device() does the equivalent of
{ pci_assign_irq(); pci_assign_mmio(); pci_assign_io() }
where these again internally do pci_set_power_state() (and could extended
to do whatever else necessary).

The main reason against pci_enable_device() is that it makes a smooth
transition impossible - We cannot change pci_enable_device()'s behavior in
a way that relies on all drivers using pci_request_*() already. And
introducing a new function under a new name seems pointless when it can be
hidden inside the new API as well.

What's not so nice is that it destroys the symmetry between
pci_enable_device() and pci_disable_device().

But I think I have an idea for that one as well: This new API will be used
in conjunction with the new-style pci_register_driver() etc interface,
where the PCI layer knows when we call ::probe() and ::remove(). So it'd
be actually even nicer to do the pci_set_power_state() etc before
::probe() is called, and pci_disable_device after::remove() has finished
(and on ::probe() error path)

How does that sound?

> When ia32 PCI irq routing messes up, or some other random reason why an
> irq is not available for a PCI device, pdev->irq==0. So I test for that
> in my code. Then DaveM bitches at me for my test (pdev->irq < 2) not
> being cross-platform.
>
> My suggested solution, if you like Kai's proposal, is to have
> pci_assign_irq() or pci_request_irq() return an error if PCI IRQ routing
> fails.

Yes, makes sense. Actually currently pci_enable_device() should return
an error when the IRQ routing fails - it does so when using ACPI routing,
but not when doing PIRQ routing, so I think that's a bug to be fixed in
arch/i386/pci/irq.c.

I decided to return an int from pci_*_irq, where < 0 means error. The
number returned otherwise shell only be used for printk("IRQ %d", ret),
anyway - pci_dev->irq stays opaque to the driver.

Proposed patch to follow in a minute.

--Kai