RE: [patch 2.6.12-rc3] dell_rbu: Resubmitting patch for new DellBIOS update driver

Abhay_Salunke_at_Dell.com
Date: 06/03/05

  • Next message: Dag Nygren: "Re: OHCI driver have problems with USB 2.0 memory devices"
    Date:	Fri, 3 Jun 2005 14:57:23 -0500
    To: <greg@kroah.com>
    
    

    > > At what point I should be calling request_firmware?
    >
    > Never, you should call request_firmware_nowait() instead. And do it
    > from your module init function.
    >
    > > As my driver does
    > > not have any entry points. In this driver it is called when the user
    is
    > > ready to download the firmware image (when it echoes the firmware
    image
    > > name). Also the driver needs to be resident for handling multiple
    such
    > > requests; that's why cannot do this at driver init time.
    >
    > That's what request_firmware_nowait() is for.
    >
    But isn't request_firmware_nowait a one time deal. It creates a kernel
    thread which will call the cont function once and end it. In that case I
    will have to unload and reload the driver every time before doing an
    update.
    Also driver's unload has to free the allocated memory; this will not
    serve the purpose of this driver.
    > > When ever the user echoes the file name, it gets passed on to
    > > request_firmware and the $FIRMWARE env gets populated with the file
    > > name. thus making the hotplug code to automatically load the image
    which
    > > is passed back as fw->data and fw->size.
    >
    > It's easier for the user to just copy the firmware to the sysfs file
    > whenever they want to. No messing with hotplug events or filenames.
    >
    I must be missing some things here. Can copying the data to the sysfs
    file with normal attributes work? Don't we need to have a sysfs file
    with bin attribute? Could you please elaborate on this...I am quoting
    you from one of your earlier response "I can understand having the data
    use the sysfs binary attribute, but do not do this for the size files.
    Please just use a normal attribute for them, the binary ones are _only_
    for blobs of data that are not interpreted by the kernel"

    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/


  • Next message: Dag Nygren: "Re: OHCI driver have problems with USB 2.0 memory devices"

    Relevant Pages

    • [PATCH] I2C: Kill i2c_client.id (5/5)
      ... * [Sysctl] All sysctl stuff is of course gone (defines, ... existing 2.6 driver for details. ... sysfs file creation. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [GIT PATCH] PCI patches for 2.6.15 - retry
      ... or driver core. ... the bottom of the barrier/md bug and just before I hit this with -mm3 which I believe is the same bug. ... last sysfs file: ... To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ...
      (Linux-Kernel)
    • Re: pktcdvd -> sysfs warning with 2.6.27
      ... Where does that sysfs file ... forgot) was to build in the CMOS RTC driver, ... hades:~# pktsetup cdrw /dev/cdrw ... to break some non-udev setups:( ...
      (Linux-Kernel)
    • Re: usb sysfs intf files no longer created when probe fails
      ... > to the previous failure to create the sysfs file: ... Sounds like a bug in that driver, care to ask the authors of it about ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: pktcdvd -> sysfs warning with 2.6.27
      ... Where does that sysfs file ... forgot) was to build in the CMOS RTC driver, ... The pktcdvd driver once had static numbers, ... pktdev_major = ret; ...
      (Linux-Kernel)