[alsa-devel] [PATCH] sound/isa: kill pnp_resource_change.

[Takashi Iwai]

At Fri, 30 Nov 2007 18:07:27 +0100,
Rene Herman wrote:
> 
> On 30-11-07 10:07, Takashi Iwai wrote:
> 
> > At Fri, 30 Nov 2007 01:49:00 +0100,
> > Rene Herman wrote:
> 
> >> Actually, the ALSA drivers with PnPBIOS support (snd-cs4232, snd-es18xx and 
> >> snd-opl3sa2) do not in fact loose any parameters and the few known trouble 
> >> spots there are using
> >>
> >> 	modprobe snd-foo isapnp=0 port=...
> >>
> >> as their workaround, bypassing all of PnP, and this still works completely 
> >> the same as before.
> >>
> >> I do not expect any trouble. A few users might have _mistakingly_ added 
> >> parameters to an ISAPnP only (as in, not also PnPBIOS) driver due to 
> >> googling up your generic bad-advice webforum that said that worked for 
> >> someone with a heavy sounding nickname, but we can deal with that.
> >>
> >> Moreover, as I've been experiencing on the ALSA list for a while now (where 
> >> I've been somewhat responsive to ISA related issues) basically anything but 
> >> PnPBIOS/ACPI ISA is mostly dead and as said, with an isapnp=0 in the drivers 
> >> there which known issues are using, there's no difference.
> >>
> >> Advice is always good, but I'd not put in the ALSA documentation (wrong 
> >> place) and even in the changelog it sounds a bit overly alarming in my own 
> >> opinion. The expected fall-out is... <crickets>...
> > 
> > Hm, but still some notes are needed for ALSA-Configuration.txt
> > mentioning that the resource parameters like port, io, etc can be used
> > only when isapnp=no on some drivers.  The parameters are still there,
> > so people may wonder if it has no use.
> 
> Okay, something like this? Incremental...
> 
> By the way, eventually I'd in fact probably like to move some of the drivers 
> that now still support legacy ISA over to PnP only. After all, chips such as 
> the CMI8330, CS4232+, ES1869+ and OPL3SA2 _are_ PnP only chips.
> 
> Certainly for CS4232+ and ES1869+ that can't be done currently as we know 
> people are in fact using isapnp=0 to work around PnPBIOS issues but from the 
> previous report there it seemed that might actually just consist of the BIOS 
> claiming no resource change is possible, which pnp_activate_dev (through 
> pnp_autoconfig_dev) insist on anyway. This would be something to fix inside 
> PnP instead...

Well, I'm not sure about that.  Certainly there are some users that
use isapnp=no with explicit parameters.

> Anyways, here's just a further Documentation update. You once told me to 
> start new threads for patches, but that seems clumsy now... :-|

Thanks.  It seems that people do care more on explanations about the
removal of options.  Could you add that, too?
Just mention about sysfs as alternative way to change the
parameters...


Thanks,

Takashi