Re: [PATCH 00/04] Load keyspan firmware with hotplug

[Marcel Holtmann <marcel@holtmann.org>]

Hi Jan,

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

the existing request_firmware() has nothing in common with IHEX parser
and such a parser should not belong there. So either make it a separate
module or add it to the module that is using it. In this case this is
the keyspan module or the usb-serial core.

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

Then make it at separate module.

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

I am not going to repeat the current arguments and it is not about
loading multiple firmware files (btw I wrote the bcm203x). Check the
mailing list archives for the details. I still need to catch up with the
discussion, but there is some ongoing work.

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

This is another approach and if you want something like that, then send
a patch for it and let Sam and others comment on it.

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/