Good day. Quite some time ago by now I announced I would be transferring ALSA ISA drivers to the new isa_bus infrastructure. All sorts of crap intervened but I'm finding some time currently. I will be submitting them one or a few drivers at a time... As a reminder; as a general principle in the driver model, drivers load even if they can't immediately bind to their hardware -- it's generally possible to bind the driver to some specific hardware later by echoing a device id into the driver's "bind" sysfs-attribute. Due to old non-pnp ISA devices not being generically discoverable, the isa_bus keeps all device creation internal and distributes the bus's .match() method up to the driver, allowing the driver to decide whether or not to load. Following the above mentioned general principle of loading even if the driver can't immediately bind to the hardware, the suggested use of the .match() method in these ALSA drivers is only for the prerequisites. Ie, check that the user wants the card enabled (the "enable" param) and that values such as port, irq and dma have been passed in so that a later bind could conceivably succeed. With this setup for example things such as loading multiple drivers for one card and binding and unbinding them alternately works nicely. You'd do things such as echo -n ad1848.0 >/sys/bus/isa/drivers/ad1848/unbind where "ad1848.0" is the device id existing under /sys/devices/isa and under that same driver directory when it's bound (and where "ad1848" is the same as the ALSA card->driver, bringing some consistency to the name strings) to have the driver "let go" of the hardware so that you can try to drive the same hardware with sns-cs4232 for example. If you'd later want to bind the driver again, a echo -n ad1848.0 >/sys/bus/isa/drivers/ad1848/bind should do it. Attched is the first one for ad1848. It's a straightforward transfer from the old platform devices and has been tested. It contains one unrelated change; s/dma1/dma/ since this driver only accepts one dma channel. Rene.