sound/isa: kill pnp_resource_change.

Hi Takashi.

This removes the pnp_resource_change use from the ALSA ISAPnP drivers. In 2.4 these were useful in providing an easy path to setting the resources, but in 2.6 they retain function as a layering violation only.

This makes for a nice cleanup (-550 lines) of ALSA but moreover, ALSA is the only remaining user of pnp_init_resource_table(), pnp_resource_change() and pnp_manual_config_dev() (and, in fact, of "struct pnp_resource_table") in the tree outide of drivers/pnp itself meaning it makes for more cleanup potential inside the PnP layer.

Thomas Renninger acked their removal from that side, you did from the ALSA side (CC list just copied from that thread).

Against current alsa-kernel HG. Many more potential cleanups in there, but this _only_ removes the pnp_resource_change code. Compile tested against current alsa-kernel HG and compile- and use-tested against 2.6.23.x (few offsets).

Signed-off-by Rene Herman <[email protected]>

This removes the pnp_resource_change use from the ALSA ISAPnP drivers. In 2.4 these were useful in providing an easy path to setting the resources, but in 2.6 they retain function as a layering violation only.

This makes for a nice cleanup (-550 lines) of ALSA but moreover, ALSA is the only remaining user of pnp_init_resource_table(), pnp_resource_change() and pnp_manual_config_dev() (and, in fact, of "struct pnp_resource_table") in the tree outide of drivers/pnp itself meaning it makes for more cleanup potential inside the PnP layer.

Quoted 9 lines · Rene Herman

This removes the pnp_resource_change use from the ALSA ISAPnP drivers. In 2.4 these were useful in providing an easy path to setting the resources, but in 2.6 they retain function as a layering violation only.

This makes for a nice cleanup (-550 lines) of ALSA but moreover, ALSA is the only remaining user of pnp_init_resource_table(), pnp_resource_change() and pnp_manual_config_dev() (and, in fact, of "struct pnp_resource_table") in the tree outide of drivers/pnp itself meaning it makes for more cleanup potential inside the PnP layer.

I think this is great and will certainly clean up the PNP interfaces.

But are you removing functionality that people need? I don't know anything about ALSA, but we have to assume that some BIOSes supply incorrect resource information. If you remove all these module parameters, is there still a way to workaround the BIOS defects?

Quoted 9 lines · Rene Herman

This removes the pnp_resource_change use from the ALSA ISAPnP drivers. In 2.4 these were useful in providing an easy path to setting the resources, but in 2.6 they retain function as a layering violation only.

This makes for a nice cleanup (-550 lines) of ALSA but moreover, ALSA is the only remaining user of pnp_init_resource_table(), pnp_resource_change() and pnp_manual_config_dev() (and, in fact, of "struct pnp_resource_table") in the tree outide of drivers/pnp itself meaning it makes for more cleanup potential inside the PnP layer.

I think this is great and will certainly clean up the PNP interfaces.

But are you removing functionality that people need? I don't know anything about ALSA, but we have to assume that some BIOSes supply incorrect resource information. If you remove all these module parameters, is there still a way to workaround the BIOS defects?

Quoted 12 lines · Bjorn Helgaas

Quoted 9 lines · Rene Herman

This removes the pnp_resource_change use from the ALSA ISAPnP drivers. In 2.4 these were useful in providing an easy path to setting the resources, but in 2.6 they retain function as a layering violation only.

This makes for a nice cleanup (-550 lines) of ALSA but moreover, ALSA is the only remaining user of pnp_init_resource_table(), pnp_resource_change() and pnp_manual_config_dev() (and, in fact, of "struct pnp_resource_table") in the tree outide of drivers/pnp itself meaning it makes for more cleanup potential inside the PnP layer.

Quoted 6 lines

I think this is great and will certainly clean up the PNP interfaces.

But are you removing functionality that people need? I don't know anything about ALSA, but we have to assume that some BIOSes supply incorrect resource information. If you remove all these module parameters, is there still a way to workaround the BIOS defects?

Yes, sure, by just echoing resource values into sysfs files as a direct replacement (ie, doing the same thing at the PnP layer directly) and possibly by adding quirks for any definite and standing issues. We already have a few of those in fact for SB16, AWE32 and CMI8330 chips, in drivers/pnp/quirks.c.

OK, good.

Anyone who relies on the manual settings will have to change the way it's done, so maybe the changelog and documentation update should include some text along the lines of:

- this removes module parameters for ISAPNP ALSA resources
- the drivers *should* work with no manual resource settings
- if you need manual resource settings (usually to work around a broken BIOS),

At Thu, 29 Nov 2007 02:10:33 +0100,

Quoted 21 lines · Rene Herman

Hi Takashi.

This removes the pnp_resource_change use from the ALSA ISAPnP drivers. In 2.4 these were useful in providing an easy path to setting the resources, but in 2.6 they retain function as a layering violation only.

This makes for a nice cleanup (-550 lines) of ALSA but moreover, ALSA is the only remaining user of pnp_init_resource_table(), pnp_resource_change() and pnp_manual_config_dev() (and, in fact, of "struct pnp_resource_table") in the tree outide of drivers/pnp itself meaning it makes for more cleanup potential inside the PnP layer.

Thomas Renninger acked their removal from that side, you did from the ALSA side (CC list just copied from that thread).

Against current alsa-kernel HG. Many more potential cleanups in there, but this _only_ removes the pnp_resource_change code. Compile tested against current alsa-kernel HG and compile- and use-tested against 2.6.23.x (few offsets).

Quoted 1 line

Signed-off-by Rene Herman <[email protected]>

A good work. I'll merge this tomorrow to ALSA tree if no one raises objection now.

Quoted 10 lines · Bjorn Helgaas

OK, good.

Anyone who relies on the manual settings will have to change the way it's done, so maybe the changelog and documentation update should include some text along the lines of:

- this removes module parameters for ISAPNP ALSA resources
- the drivers *should* work with no manual resource settings
- if you need manual resource settings (usually to work around a broken BIOS),

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>...

Quoted 23 lines · Takashi Iwai

At Thu, 29 Nov 2007 02:10:33 +0100,

Quoted 21 lines · Rene Herman

Hi Takashi.

This removes the pnp_resource_change use from the ALSA ISAPnP drivers. In 2.4 these were useful in providing an easy path to setting the resources, but in 2.6 they retain function as a layering violation only.

This makes for a nice cleanup (-550 lines) of ALSA but moreover, ALSA is the only remaining user of pnp_init_resource_table(), pnp_resource_change() and pnp_manual_config_dev() (and, in fact, of "struct pnp_resource_table") in the tree outide of drivers/pnp itself meaning it makes for more cleanup potential inside the PnP layer.

Thomas Renninger acked their removal from that side, you did from the ALSA side (CC list just copied from that thread).

Against current alsa-kernel HG. Many more potential cleanups in there, but this _only_ removes the pnp_resource_change code. Compile tested against current alsa-kernel HG and compile- and use-tested against 2.6.23.x (few offsets).

Quoted 4 lines

Quoted 1 line

Signed-off-by Rene Herman <[email protected]>

A good work. I'll merge this tomorrow to ALSA tree if no one raises objection now.

Do we have a nice way to manually assign ISA resources at system level? Note that not all combinations work for all ISA PnP soundcards and we had bug reports that automatic PnP system failed in some cases.

At Fri, 30 Nov 2007 10:52:26 +0100 (CET),

Quoted 28 lines · Jaroslav Kysela

Quoted 25 lines · Takashi Iwai

At Thu, 29 Nov 2007 02:10:33 +0100,

Quoted 22 lines · Rene Herman

Hi Takashi.

This removes the pnp_resource_change use from the ALSA ISAPnP drivers. In 2.4 these were useful in providing an easy path to setting the resources, but in 2.6 they retain function as a layering violation only.

This makes for a nice cleanup (-550 lines) of ALSA but moreover, ALSA is the only remaining user of pnp_init_resource_table(), pnp_resource_change() and pnp_manual_config_dev() (and, in fact, of "struct pnp_resource_table") in the tree outide of drivers/pnp itself meaning it makes for more cleanup potential inside the PnP layer.

Thomas Renninger acked their removal from that side, you did from the ALSA side (CC list just copied from that thread).

Against current alsa-kernel HG. Many more potential cleanups in there, but this _only_ removes the pnp_resource_change code. Compile tested against current alsa-kernel HG and compile- and use-tested against 2.6.23.x (few offsets).

Signed-off-by Rene Herman <[email protected]>

Quoted 6 lines

Quoted 2 lines

A good work. I'll merge this tomorrow to ALSA tree if no one raises objection now.

Do we have a nice way to manually assign ISA resources at system level? Note that not all combinations work for all ISA PnP soundcards and we had bug reports that automatic PnP system failed in some cases.

You can adjust it via sysfs.

Quoted 33 lines · Takashi Iwai

At Fri, 30 Nov 2007 10:52:26 +0100 (CET),

Quoted 31 lines · Jaroslav Kysela

Quoted 27 lines · Takashi Iwai

At Thu, 29 Nov 2007 02:10:33 +0100,

Quoted 16 lines · Rene Herman

Hi Takashi.

This removes the pnp_resource_change use from the ALSA ISAPnP drivers. In 2.4 these were useful in providing an easy path to setting the resources, but in 2.6 they retain function as a layering violation only.

This makes for a nice cleanup (-550 lines) of ALSA but moreover, ALSA is the only remaining user of pnp_init_resource_table(), pnp_resource_change() and pnp_manual_config_dev() (and, in fact, of "struct pnp_resource_table") in the tree outide of drivers/pnp itself meaning it makes for more cleanup potential inside the PnP layer.

Thomas Renninger acked their removal from that side, you did from the ALSA side (CC list just copied from that thread).

Quoted 6 lines

Against current alsa-kernel HG. Many more potential cleanups in there, but this _only_ removes the pnp_resource_change code. Compile tested against current alsa-kernel HG and compile- and use-tested against 2.6.23.x (few offsets).

Signed-off-by Rene Herman <[email protected]>

A good work. I'll merge this tomorrow to ALSA tree if no one raises objection now.

Quoted 5 lines

Quoted 3 lines

Do we have a nice way to manually assign ISA resources at system level? Note that not all combinations work for all ISA PnP soundcards and we had bug reports that automatic PnP system failed in some cases.

You can adjust it via sysfs.

Ok, then we need to document this way properly in our documentation before feature removal.

Probably using 'install' commmand in modprobe.conf. Also note that user must probably know exact sysfs path (PnP ID) making PnP stuff more complicated in this case. It is different from current behaviour.

At Fri, 30 Nov 2007 13:25:22 +0100 (CET),

Quoted 36 lines · Jaroslav Kysela

Quoted 33 lines · Takashi Iwai

At Fri, 30 Nov 2007 10:52:26 +0100 (CET),

Quoted 31 lines · Jaroslav Kysela

Quoted 27 lines · Takashi Iwai

At Thu, 29 Nov 2007 02:10:33 +0100,

Quoted 16 lines · Rene Herman

Hi Takashi.

This removes the pnp_resource_change use from the ALSA ISAPnP drivers. In 2.4 these were useful in providing an easy path to setting the resources, but in 2.6 they retain function as a layering violation only.

This makes for a nice cleanup (-550 lines) of ALSA but moreover, ALSA is the only remaining user of pnp_init_resource_table(), pnp_resource_change() and pnp_manual_config_dev() (and, in fact, of "struct pnp_resource_table") in the tree outide of drivers/pnp itself meaning it makes for more cleanup potential inside the PnP layer.

Thomas Renninger acked their removal from that side, you did from the ALSA side (CC list just copied from that thread).

Quoted 6 lines

Against current alsa-kernel HG. Many more potential cleanups in there, but this _only_ removes the pnp_resource_change code. Compile tested against current alsa-kernel HG and compile- and use-tested against 2.6.23.x (few offsets).

Signed-off-by Rene Herman <[email protected]>

A good work. I'll merge this tomorrow to ALSA tree if no one raises objection now.

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

Do we have a nice way to manually assign ISA resources at system level? Note that not all combinations work for all ISA PnP soundcards and we had bug reports that automatic PnP system failed in some cases.

You can adjust it via sysfs.

Ok, then we need to document this way properly in our documentation before feature removal.

Yes, see Bjorn's previous post.

Quoted 4 lines

Probably using 'install' commmand in modprobe.conf. Also note that user must probably know exact sysfs path (PnP ID) making PnP stuff more complicated in this case. It is different from current behaviour.

Such a device requring the manual configuration is basically broken. It should be fixed, e.g. by adding a quirk to pnp driver.

Quoted 49 lines · Takashi Iwai

At Fri, 30 Nov 2007 13:25:22 +0100 (CET),

Quoted 36 lines · Jaroslav Kysela

Quoted 33 lines · Takashi Iwai

At Fri, 30 Nov 2007 10:52:26 +0100 (CET),

Quoted 31 lines · Jaroslav Kysela

Quoted 27 lines · Takashi Iwai

At Thu, 29 Nov 2007 02:10:33 +0100,

Quoted 16 lines · Rene Herman

Hi Takashi.

This removes the pnp_resource_change use from the ALSA ISAPnP drivers. In 2.4 these were useful in providing an easy path to setting the resources, but in 2.6 they retain function as a layering violation only.

This makes for a nice cleanup (-550 lines) of ALSA but moreover, ALSA is the only remaining user of pnp_init_resource_table(), pnp_resource_change() and pnp_manual_config_dev() (and, in fact, of "struct pnp_resource_table") in the tree outide of drivers/pnp itself meaning it makes for more cleanup potential inside the PnP layer.

Thomas Renninger acked their removal from that side, you did from the ALSA side (CC list just copied from that thread).

Quoted 6 lines

Against current alsa-kernel HG. Many more potential cleanups in there, but this _only_ removes the pnp_resource_change code. Compile tested against current alsa-kernel HG and compile- and use-tested against 2.6.23.x (few offsets).

Signed-off-by Rene Herman <[email protected]>

A good work. I'll merge this tomorrow to ALSA tree if no one raises objection now.

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

Do we have a nice way to manually assign ISA resources at system level? Note that not all combinations work for all ISA PnP soundcards and we had bug reports that automatic PnP system failed in some cases.

You can adjust it via sysfs.

Ok, then we need to document this way properly in our documentation before feature removal.

Yes, see Bjorn's previous post.

Quoted 7 lines

Quoted 4 lines

Probably using 'install' commmand in modprobe.conf. Also note that user must probably know exact sysfs path (PnP ID) making PnP stuff more complicated in this case. It is different from current behaviour.

Such a device requring the manual configuration is basically broken. It should be fixed, e.g. by adding a quirk to pnp driver.

Note that in some cases, it's not about a device, but about motherboard and device interoperability. I've seen some ISA motherboards with some unusable DMA channels.

Anyway, it's true that ISA PnP stuff is quite obsolete current days. If manual settings is supported and described, I've no objections to reduce code, too.

At Fri, 30 Nov 2007 01:49:00 +0100,

Quoted 8 lines · Rene Herman

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.

Quoted 3 lines

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.

Quoted 22 lines · Takashi Iwai

At Fri, 30 Nov 2007 01:49:00 +0100,

Quoted 19 lines · Rene Herman

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.

Quoted 8 lines

Quoted 3 lines

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...

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

Anyway, it's true that ISA PnP stuff is quite obsolete current days. If manual settings is supported and described, I've no objections to reduce code, too.

At Fri, 30 Nov 2007 18:07:27 +0100,

Quoted 10 lines · Rene Herman

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.

Quoted 2 lines

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...

Quoted 3 lines · Jaroslav Kysela

Anyway, it's true that ISA PnP stuff is quite obsolete current days. If manual settings is supported and described, I've no objections to reduce code, too.

Okay. I've just submitted a further upadet to ALSA-Configuration.txt and I'll look into being a bit more verbose about how to set resources in Documentation/pnp.txt and possibly defer users from ALSA-Configuration.txt there.

Thomas Renninger is making some haste with the deprecation of the removed functions by the way -- I just saw a patch of his entering my mailbox where he says he'd in fact like them deprecated in 2.6.24 already. The ALSA removal would not seem likely to be scheduled to go to 2.6.24 yet, so I guess that won't do?

I have no opinion on the schedule -- but Thomas, if you do, I guess you'd need to convince Jaroslav to withstand The Wrath Of Linus and ask him to push it. We can't have it deprecated (on the "spew warnings" level) with ALSA still using them in 2.6.24.

Quoted 3 lines · Rene Herman

Thomas Renninger is making some haste with the deprecation of the removed functions by the way -- I just saw a patch of his entering my mailbox where he says he'd in fact like them deprecated in 2.6.24 already. The ALSA removal would not seem likely to be scheduled to go to 2.6.24 yet, so I guess that won't do?

I have no opinion on the schedule -- but Thomas, if you do, I guess you'd need to convince Jaroslav to withstand The Wrath Of Linus and ask him to push it. We can't have it deprecated (on the "spew warnings" level) with ALSA still using them in 2.6.24.

Why not?
The intend of __deprecated is to throw some compile warnings? In this case it would warn on the official 2.6.24 on functions which are known to be reverted already for the next cycle (this should not hurt?),

it's more for drivers building against kernel headers getting noticed as soon as possible...

If this is not added to 2.6.24, the funcs should live there for another kernel cycle just to not print some irrelevant warnings at compile time things are slowed down...

This is also in vanilla and lives there for some time?:
kernel/power/pm.c:205: warning: ‘pm_register’ is deprecated (declared at kernel/power/pm.c:64) kernel/power/pm.c:205: warning: ‘pm_register’ is deprecated (declared at kernel/power/pm.c:64) kernel/power/pm.c:206: warning: ‘pm_send_all’ is deprecated (declared at kernel/power/pm.c:180) kernel/power/pm.c:206: warning: ‘pm_send_all’ is deprecated (declared at kernel/power/pm.c:180)