lkml.org 
[lkml]   [2005]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 00/04] Load keyspan firmware with hotplug
    From
    On Tue, Apr 05, 2005 at 04:36:31PM +0200, Marcel Holtmann wrote:
    > > > I agree with Dmitry on this point. The IHEX parser should not be inside
    > > > firmware_class.c. What about using keyspan_ihex.[ch] for it?
    > >
    > > That's what I had originally, actually called firmware_ihex.ko, since
    > > the IHEX format parser is not in any way keyspan specific and there are
    > > several usb-serial converters that seem to use the same IHEX->.h trick
    > > which could trivially be modified to use this loader.
    > >
    > > But the compiled parser fairly small (< 2KB) and adding it to the
    > > existing module didn't effectively add any size to the firmware_class
    > > module since things are rounded to a page boundary anyways.
    >
    > so it seems that this is usb-serial specific at the moment. Then I would

    I really don't see the point you are trying to argue. I said, sure it is
    possible to make it a separate module, that is what my initial
    implementation was. Why do you want to pigeon-hole it with anything but
    the existing firmware loading code?

    It is _not_ usb-serial specific, in fact once the device is initialized
    this isn't even needed. And the initialization as far as I can see uses
    little or no usb-serial code.

    It happens that many usb-serial devices are built around the ezusb
    chipset, which in turn seems to be a 8051-based microcontroller. The
    compilers for such microcontrollers seem to generate IHEX formatted
    output possibly because eprom burners generally support the format.

    > it up at the moment. People are also working on a replacement for the
    > current request_firmware(), because the needs are changing. Try to keep
    > it close with the usb-serial for now.

    What? I find the existing request_firmware fairly simple and
    straightforward, it has a very KISS-like quality to it, it is nice and
    small and even the userspace support is trivial. I only saw a mention
    about 'replacing' it in the current thread which mostly involved
    complaints but didn't actually see anyone volunteering to start working
    on such a replacement.

    If a driver wants to load 5 different chunks, just call request_firmware
    5 times (i.e. drivers/bluetooth/bcm203x.c). If the data is a single
    binary blob, just ask for the single binary blob. In this case there
    seems to be some structure to the blob that I wanted to preserve, and
    that would either be some custom binary format that contains
    [<address><length><data>]... tuples, which ofcourse causes problems for
    our big-endian brothers, or a similar ascii format, where the IHEX is
    not only pretty much standardized, it is trivial to parse and even adds
    checksum information.

    The only thing that I see missing right now is a change to the makefiles
    to have in-tree firmware files get installed in /lib/modules/`uname
    -r`/firmware or some similar place. Ideally people would add a line
    like,

    fw-$(CONFIG_FOO) = foo-firmware-blob.fw

    And make install could drop it a place where hotplug can find it.

    Jan

    -
    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-04-06 13:31    [W:4.435 / U:0.484 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site