Messages in this thread | | | Date | Thu, 16 Jun 2005 10:26:55 -0500 | From | Abhay Salunke <> | Subject | Re: [patch 2.6.12-rc3] Adds persistent entryies using request_firmware_nowait |
| |
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/
| |