Re: [patch 2.6.12-rc3] Adds persistent entryies using request_firmware_nowait

[Abhay Salunke <Abhay_Salunke@dell.com>]

On Wed, Jun 15, 2005 at 11:01:48PM -0500, Dmitry Torokhov wrote:
> On Wednesday 15 June 2005 19:34, Abhay Salunke wrote:
> > This is a patch to make the /sys/class/firmware entries persistent. 
> > This has been tested with dell_rbu; dell_rbu was modified to not call
> > request_firmware_nowait again form the callback function. 
> > 
> > The new mechanism to make the entries persistent is as follows
> > 1> echo 0 > /sys/class/firmware/timeout
> > 2> echo 2 > /sys/class/firmware/xxx/loading
> > 
> > step 1 prevents timeout to occur , step 2 makes the entry xxx persistent
> > 
> > if we want to remove persistence then do this
> > ech0 -2 > /sys/class/firmware/xxx/loading
> > 
> 
> Hi,
> 
> I have the following issues with the patch:
> 
> - since "persistency" (or rather repeat loading) is controlled from
>   userspace, drivers don't have control over it. This way every user
>   of request_firmware_nowait has to be ready to process more than one
>   firmware load.
The user has knowingly choosen to be persistent and it will be responsible
for handling multiple requests. I understand the concern here is that if by 
accident the user writes 2 to loading...I am working on the next patch
which will address this issue.
> 
> - There is no way to "cancel" firmware request from the driver. You
>   will not be able to safely unload users of request_firmware_nowait().
>   Since loader is rearming you can't use firmware handler function to
>   signal when request has been processed.
> 
This is a valid concern and it is also true with the current code. 
Calling request_firmware_nowait for the current code the driver is 
at mercy of the user to send a cancel request to loading. Any driver
unload will fail till the user cancles it.
I realized that while playing with dell_rbu ( which uses request_firmware_nowait)

> I think that such re-arming reqests are much better implemented in
> individual drivers.

I respecfully disagree ; I think the request_firmware_nowait is not complete
if we dont have a way to make it persistent. Also if the other drivers are 
required to do the re-arming they will still end up in the same situation 
of not being able to unload unless the user chooses to cancel firmware.
The best fix is to fix this in frimware_class.c. 
I had experienced this exact thing with dell_rbu driver.I will address these 
issues in my next patch. 

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