Re: [alsa-devel] [PATCH 2/3] PNP cleanups - Unify the pnp macros to access resources in the pnp resource table
On 20-11-07 15:19, Thomas Renninger wrote:
At the end is some example code how things could get even more cleaned up. It shows how I think pnp layer and one example driver would get adjusted. There are not that much drivers making use of pnp_resource_change...
The ALSA ISA-PnP drivers do in what I personally consider a bad layering violation. Brought up not doing that a while ago on alsa-devel, but no discussion ensued. If the PnP maintainer(s) agree with me though, I'd be more than happy to rip all of that out of ALSA.
(added alsa-devel)
Rene.
On Tue, 2007-11-20 at 15:31 +0100, Rene Herman wrote:
On 20-11-07 15:19, Thomas Renninger wrote:
At the end is some example code how things could get even more cleaned up. It shows how I think pnp layer and one example driver would get adjusted. There are not that much drivers making use of pnp_resource_change...
The ALSA ISA-PnP drivers do in what I personally consider a bad layering violation. Brought up not doing that a while ago on alsa-devel, but no discussion ensued. If the PnP maintainer(s) agree with me though, I'd be more than happy to rip all of that out of ALSA.
(added alsa-devel)
The pnp_resource_change is really ugly..., these are making use of it: sound/isa/sb/es968.c sound/isa/sb/sb16.c sound/isa/gus/interwave.c sound/isa/es18xx.c sound/isa/cs423x/cs4236.c sound/isa/wavefront/wavefront.c sound/isa/ad1816a/ad1816a.c sound/isa/cmi8330.c sound/isa/opl3sa2.c sound/isa/opti9xx/opti92x-ad1848.c sound/isa/als100.c sound/isa/azt2320.c sound/isa/dt019x.c
Thomas
At Tue, 20 Nov 2007 15:31:26 +0100, Rene Herman wrote:
On 20-11-07 15:19, Thomas Renninger wrote:
At the end is some example code how things could get even more cleaned up. It shows how I think pnp layer and one example driver would get adjusted. There are not that much drivers making use of pnp_resource_change...
The ALSA ISA-PnP drivers do in what I personally consider a bad layering violation. Brought up not doing that a while ago on alsa-devel, but no discussion ensued. If the PnP maintainer(s) agree with me though, I'd be more than happy to rip all of that out of ALSA.
I'm fine with removal of that stuff now. It was implemented in that way because there was no proper way to re-assign ISA PnP resources on 2.4 kernel time. On 2.6, it makes no longer any sense (except for compatibility, but this is almost no problem for PnP boards).
thanks,
Takashi
On Wed, 2007-11-21 at 10:53 +0100, Takashi Iwai wrote:
At Tue, 20 Nov 2007 15:31:26 +0100, Rene Herman wrote:
On 20-11-07 15:19, Thomas Renninger wrote:
At the end is some example code how things could get even more cleaned up. It shows how I think pnp layer and one example driver would get adjusted. There are not that much drivers making use of pnp_resource_change...
The ALSA ISA-PnP drivers do in what I personally consider a bad layering violation. Brought up not doing that a while ago on alsa-devel, but no discussion ensued. If the PnP maintainer(s) agree with me though, I'd be more than happy to rip all of that out of ALSA.
Rene: Could you do that, pls.
I'm fine with removal of that stuff now. It was implemented in that way because there was no proper way to re-assign ISA PnP resources on 2.4 kernel time. On 2.6, it makes no longer any sense (except for compatibility, but this is almost no problem for PnP boards).
I wasted some time on thinking about how this pnp_resource_change and pnp_manual_config_dev could get workarounded..., but it's impossible without changing the (more a workaround than an) interface.
If you worked on this already, would you mind ripping these out?
If I understand Takashi correctly, the driver code using pnp_resource_change and pnp_manual_config_dev can simply be removed and devices could get resources assigned via sysfs "set" interface.
Thanks,
Thomas
On 27-11-07 17:34, Thomas Renninger wrote:
On Wed, 2007-11-21 at 10:53 +0100, Takashi Iwai wrote:
At Tue, 20 Nov 2007 15:31:26 +0100, Rene Herman wrote:
On 20-11-07 15:19, Thomas Renninger wrote:
At the end is some example code how things could get even more cleaned up. It shows how I think pnp layer and one example driver would get adjusted. There are not that much drivers making use of pnp_resource_change...
The ALSA ISA-PnP drivers do in what I personally consider a bad layering violation. Brought up not doing that a while ago on alsa-devel, but no discussion ensued. If the PnP maintainer(s) agree with me though, I'd be more than happy to rip all of that out of ALSA.
Rene: Could you do that, pls.
Yes, I will do this, In fact, I've done a few already but ofcourse a few other things intervened again...
I'm fine with removal of that stuff now. It was implemented in that way because there was no proper way to re-assign ISA PnP resources on 2.4 kernel time. On 2.6, it makes no longer any sense (except for compatibility, but this is almost no problem for PnP boards).
I wasted some time on thinking about how this pnp_resource_change and pnp_manual_config_dev could get workarounded..., but it's impossible without changing the (more a workaround than an) interface.
If you worked on this already, would you mind ripping these out?
If I understand Takashi correctly, the driver code using pnp_resource_change and pnp_manual_config_dev can simply be removed and devices could get resources assigned via sysfs "set" interface.
Exactly. ISA-PnP is with respect to the interface it provides exactly as PCI and other sane busses. You just ask the system what resources to use -- it provides a method for actually changing them as well, but doing so belongs isolated in the PnP layer, not anywhere else IMHYUO (*).
Wasn't aware of the original reason for this setup, but yes, in 2.6 it certainly isn't needed for anything anymore and in fact just makes for inconsistency, especially for the mixed legacy/isapnp drivers where module parameters change meaning from "this is where it's at to "_put_ it there" between the two card types.
Jaroslav Kysela will have to ack any patches as well, but sound/isa is the only user of
- pnp_init_resource_table() - pnp_resource_change() - pnp_manual_config_dev()
which eventually then might also want to be unexported and/or deleted.
Rene.
(*) In My Humble Yet Unwavering Opinion...
participants (3)
-
Rene Herman -
Takashi Iwai -
Thomas Renninger