Re: broadcom proposed firmware licence, please comment ...
Andres Salomon wrote:
> Yes, that's what I was thinking. Vendors will be taking care of
> firmware file installation; kbuild should be handling it when running
> modules_install. Perhaps a firmware_install target that takes care of
> the various firmware blobs?
Sounds good.
> I can do that, if necessary. What form was broadcom supplying firmware
> in in the first place? If it's a binary firmware file, there's no need
> to have a hex code converter; we can just throw the binary firmware file
> in the directory tree.
Hex. I have the files from the Broadcom-released driver. :-)
>>If anyone's volunteering to do so :-), I believe we'd decided that the "right
>>place" was:
>>/usr/lib/hotplug/firmware/tg3/5701_a0-0.0.0
>>/usr/lib/hotplug/firmware/tg3/tso-1.4.0
>>/usr/lib/hotplug/firmware/tg3/tso_5705-1.1.0
>>(This forms the beginnings of a namespace and conventions for loadable
>>firmware files, and is where my existing code puts them.)
>>
>
>
> I haven't bothered looking at other drivers in the tree that support
> firmware loading; are paths hardcoded in there, or is the firmware
> location simply a module/kernel arg?
Hardcoded, consistently. The few present have erratically chosen names
hardcoded. Indeed I have no idea where to find the firmware files to go
with some of those names, which is an issue.
I think the feeling was that the file in that location can be replaced
rather than changing the name searched for, and that that was simpler.
I'm not doctrinaire about it or anything though!
>>Oh, what I was thinking was this:
>>> (1) reorganize the upstream kernel driver so that the included firmware was in
>>> a separate file (#included, for instance), as is done in most such drivers
>
>
> This alone would go a long way towards making my life easier, if
> upstream accepted it.
Well, maybe I should do that first. :-)
Reply to: