Hi, Simon and everybody!
Since PCMCIA devices are not devices for the kernel, atmel_cs uses a fake
device for calling request_firmware(). The fake device has .bus_id
initialized, but it's not enough for Linux 2.6.6-rc3. The kernel would
oops while trying to create a link from /sys/class/firmware/pcmcia/device
to the location of the device in sysfs.
To work around this problem, .kobj.k_name should be defined in the fake
device. I know, it's ugly as hell, but I don't see a better solution
until PCMCIA device drivers are converted to the device model.
The patch has been compile tested only, but I have tested a similar patch
with another driver, which is not in the kernel yet (spectrum_cs). I'm
quite sure that atmel_cs is affected by this problem.
=============================
--- linux.orig/drivers/net/wireless/atmel_cs.c
+++ linux/drivers/net/wireless/atmel_cs.c
@@ -350,6 +350,9 @@ static struct {
/* This is strictly temporary, until PCMCIA devices get integrated into the device model. */
static struct device atmel_device = {
.bus_id = "pcmcia",
+ .kobj = {
+ .k_name = "atmel_cs"
+ }
};
static void atmel_config(dev_link_t *link)
=============================
--
Regards,
Pavel Roskin
Pavel Roskin wrote:
> Hi, Simon and everybody!
>
> Since PCMCIA devices are not devices for the kernel, atmel_cs uses a fake
> device for calling request_firmware(). The fake device has .bus_id
> initialized, but it's not enough for Linux 2.6.6-rc3. The kernel would
> oops while trying to create a link from /sys/class/firmware/pcmcia/device
> to the location of the device in sysfs.
>
> To work around this problem, .kobj.k_name should be defined in the fake
> device. I know, it's ugly as hell, but I don't see a better solution
> until PCMCIA device drivers are converted to the device model.
>
> The patch has been compile tested only, but I have tested a similar patch
> with another driver, which is not in the kernel yet (spectrum_cs). I'm
> quite sure that atmel_cs is affected by this problem.
>
Thanks for that: I've followed the conversation about this and is seems
that a patch like this is the best short-term fix. I'm happy to do this
and leave the device people to progress their final vision on their own
time. I'll check that the patch fixes things tomorrow sometime and give
a final OK then.
Cheers,
Simon.
C