lkml.org 
[lkml]   [2004]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [OOPS/HACK] atmel_cs and the latest changes in sysfs/symlink.c
From
Date
Hi Dmitry,

> This is wrong... What if you have several devices that are needed firmware?
> You are not only loading a specific firmware but do it for a specific device.
> You may also want to do something else with it...
>
> I think until pcmcia either provides or allows to create devices on pcmcia
> bus you can just fixup the name breakage like I did for atmel driver and
> leave it be. The device is not registered and not used in any way except to
> provide "unique" name for fimrware loader, at list in atmel_cs that is the
> case.

as you said the only real goal of the device in request_firmware() is to
provide us with a unique path to the "loading" and "data" files. The
advantage of having the device linked is currently not used by the
firmware.agent script and I don't think that it ever will be used.
However you can take a look at 2.4, where the device parameter is only a
string. So what is wrong with letting request_firmware() create a dummy
and temporary device that is not related to any hardware?

Regards

Marcel


-
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/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.084 / U:2.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site