Re: ALSA and isapnp cards

[Adam Belay]

On Fri, Jan 17, 2003 at 07:56:44PM +0300, Ruslan U. Zakirov wrote:
> Hello Adam and other.
> I've just posted another patch that works for PnP cards to you and Samium.
> During the work on it, i've found some bugs, but I can't solve them.
> At the end of patch there is hack for drivers/pnp/driver.c look at it.
> devs -  member of pnp_card_device_id struct have got more then one id for
> awe32 cards and when we request first device with 
> const char *id=devs[0].id it contains "CTL0031CTL0021" instead "CTL0031"
> and compare_pnp_id fails on it.
> This bug can be solved in other way with allocation tmp buffer in driver,
> copy id from table to buffer, add to the end \0 then request for device,
> but I think that it's bad way. 
> Any suggestions?

Could you please try this patch.  I think the lenght should be 8, not 7. Yep
that should do the trick.  Thanks for finding this bug.

--- a/include/linux/pnp.h	Tue Jan 14 05:59:30 2003
+++ b/include/linux/pnp.h	Fri Jan 17 14:02:33 2003
@@ -23,6 +23,7 @@
 #define DEVICE_COUNT_IO		8
 #define DEVICE_COUNT_MEM	4
 #define MAX_DEVICES		8
+#define PNP_ID_LEN		8
 
 struct pnp_resource;
 struct pnp_protocol;
@@ -148,7 +149,7 @@
 }
 
 struct pnp_fixup {
-	char id[7];
+	char id[PNP_ID_LEN];
 	void (*quirk_function)(struct pnp_dev *dev);	/* fixup function */
 };
 
@@ -180,20 +181,20 @@
  */
 
 struct pnp_id {
-	char id[7];
+	char id[PNP_ID_LEN];
 	struct pnp_id * next;
 };
 
 struct pnp_device_id {
-	char id[7];
+	char id[PNP_ID_LEN];
 	unsigned long driver_data;	/* data private to the driver */
 };
 
 struct pnp_card_device_id {
-	char id[7];
+	char id[PNP_ID_LEN];
 	unsigned long driver_data;	/* data private to the driver */
 	struct {
-		char id[7];
+		char id[PNP_ID_LEN];
 	} devs[MAX_DEVICES];		/* logical devices */
 };
 

> And next:
> if probe function fails for some reasons. PnP layer does not do all clean
> ups as i think. Because just after it I do the same command and ko loads
> with oops. Some points on it:

Could you please give me more details on this, such as what driver you are
using.

>    1) pnpc_driver has been registered, but after drv->probe fail, it's not
> been unregistered.

Hmm, I don't think the driver should be unregistered on a probe failure, it
should be registered on a module unload.  It's the driver's job to clean
things up so it can accept another match if one comes up.

>    2) There is was some patch in 2.5.59 to driver-model that changed
> something and it's may be a reason, I don't know exactly. 

A lot of things have changed, I'll take a look.

Regards,
Adam