Messages in this thread Patch in this message |  | | Date | Fri, 17 Jan 2003 14:13:15 +0000 | From | Adam Belay <> | Subject | Re: ALSA and isapnp cards |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |