Re: [PATCH 3/3] PNP: add AD1815 and AD1816 quirks

[Bjorn Helgaas <bjorn.helgaas@hp.com>]

On Monday 05 May 2008 07:08:19 pm Rene Herman wrote:
> The AD181x chip doesn't support an IRQ-less MPU401 option but works
> fine without one. This adds (priority: functional) IRQ-less options
> for each port option to help systems with few available IRQs.
> 
> The AD1815 quirk can't use pnp_register_irq_resource() due to doubly
> penalizing the IRQ. Also, while not a practical issue due to no IRQ
> option being present for the dependents, this needs to add in front,
> not back.
> 
> Doesn't use pnp_register_port_resource() for symetry with above.
> 
> This does not delete the AD1815 independent option even though it
> should be empty after the IRQ transfer due to AD1816 coming with an
> empty but still present independent option by default.
> 
> Was tested on AD1815 and AD1816. The ALSA driver also support the
> AZT2002 ID for MPU401 but this doesn't as I was unable to test it.
> 
> Signed-off-by: Rene Herman <rene.herman@gmail.com>

I'm not opposed to this in principle, but I don't understand
it well enough to really have an informed opinion.

IIRC, we give up some seldom-used functionality when running
the MPU401 without an IRQ.  Does the driver mention the fact
that there's something it can't do because we don't have an IRQ?
The user might like to know in case he needs that functionality
and wants to fiddle with other devices to free up IRQs.

I'm vaguely uncomfortable because this quirk isn't really working
around a hardware/firmware issue; it's stepping around the fact
that Linux doesn't know how to allocate IRQs between ISA and PCI.
Does anybody know how Windows handles this?  If Windows can do it
without user intervention, maybe we can too.

If we continue down the quirk path, would you mind using dev_info()
instead of plain printk()?

Bjorn