Continue with the next one on error from device registration.
This would seem the correct thing to do, even if it's not the probe()
error that we're getting.
Signed-off-by: Rene Herman <rene.herman@keyaccess.nl>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Remove the assumption that pnp_register_driver() returns the number of devices
claimed.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Adam Belay <ambx1@neo.rr.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Fix the check of enable module option in probe of platform_device drivers.
It shouldn't break the loop but just ignore if enable[i] is false.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
I noticed on 2.6.16-rc4 that my MPU-401 wasn't functional, due to a simple
copy & paste error in sound/isa/cs423x/cs4236.c.
Acked-by: Takashi Iwai <tiwai@suse.de>
Cc: Jaroslav Kysela <perex@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Modules: CS4236+ driver
PnP ids for Netfinity 3000 builtin soundcard.
This one works for me.
This patch was submitted through kernel Bugzilla #4214.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
- Remove vmalloc wrapper
- Add release_and_free_resource() to remove kfree_nocheck() from each driver
and simplify the code
Signed-off-by: Takashi Iwai <tiwai@suse.de>
CS4236+ driver
Background: The card/chipset supports an external MIDI interrupt. By
default, this interrupt isn't used (because the isapnp mechanism chooses a
configuration without an assigned interrupt). If the user wishes to
explicitly select an interrupt via the mpu_irq parameter for such a
configured device, it doesn't work: The driver always shows:
isapnp MPU: port=0x330, irq=-1
(note the 'irq=-1')
Problem: The driver only allows to set the irq if pnp_irq_valid returns
true for this particular pnp device. This, however, is only true if an
interrupt has already been assigned (pnp_valid_irq returns true if the flag
IORESOURCE_IRQ is set and IORESOURCE_UNSET is not set). If no interrupt
has been assigned so far, IORESOURCE_UNSET is set and pnp_irq_valid returns
false, thereby inhibiting the selection of a valid irq.
Solution: Don't check for a valid (= already assigned) irq at the point of
calling pnp_resource_change.
Tested successfully on Linux 2.6.11.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jaroslav Kysela <perex@suse.cz>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!