On Mon, 1 Aug 2005, Pavel Machek wrote:
> >
> > Why do it _ever_? There is _zero_ upside to doing it, I don't see why you
> > want to.
>
> Being able to turn off your soundcard at runtime when you are not
> using it was one of examples...
I meant the "ACPI restores irq controller state" thing.
Just leave it in. There's never any downside. If all the drivers end up
doing free_irq/request_irq(), restoring the irq controller state still
won't have any negative effect, and it solves the case where you have
drivers that don't do it.
> > Just make ACPI restore the dang thing. It's the right thing to do.
>
> Requires interpretter running with interrupts disabled => ugly :-(.
I don't see that. What's ugly? I agree that ACPI is ugly, but I do _not_
agree that it's ugly to restore irq controller state with interrupts
disabled. It MakesSense(tm) to do so.
The fact that ACPI was designed by a group of monkeys high on LSD, and is
some of the worst designs in the industry obviously makes running it at
_any_ point pretty damn ugly. And the fact that MB vendors don't test it
with anything else than Windows (and sometimes you wonder whether they do
even that) doesn't help. So hell yes, it's ugly, and nasty. But interrupts
disabled has nothing to do with any of it.
Besides, there's no real reason why you'd even have to do it with
interrupts disabled. I personally think that it makes _sense_ to try to
restore the irq controller state with irq's off, but as I made clear
earlier in this flame-fest, there's no real reason why you couldn't just
run with interrupts on.
If an interrupt is screaming due to lack of initialization and gets turned
off, just make sure it gets re-enabled when it is being initialized.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
