Re: [RFC][PATCH linux-firmware] isci: Add firmware blob and sources

From: Dan Williams
Date: Sun Dec 18 2011 - 19:15:56 EST


On Sun, Dec 18, 2011 at 1:25 PM, Ben Hutchings <ben@xxxxxxxxxxxxxxx> wrote:
> On Sun, 2011-12-18 at 10:59 -0800, Dan Williams wrote:
>> On Sat, Dec 17, 2011 at 9:14 AM, Ben Hutchings <ben@xxxxxxxxxxxxxxx> wrote:
>> > isci requires a parameter blob which is usually found in NVRAM, but it
>> > can fall back to loading with request_firmware().  These files are
>> > taken from the Linux source tree where they were wrongly added in
>> > Linux 3.0.
>>
>> Oh, I was of the impression that the external firmware tree was for
>> license incompatible firmware images?
>
> firmware/README.AddingFirmware doesn't say that the licence makes a
> difference.

Sorry, missed that readme. Yes, should have been added to
firmware.git directly.

>> > ---
>> > I'm a bit unclear on the purpose and use of isci_firmware.bin.  Is it
>> > needed for production hardware?
>>
>> It's a stop gap for platforms with missing or broken oem parameters.
>> It is meant to become vestigial once the platform revisions quiet
>> down.
>>
>> > Does it need to be customised
>> > per-system, or are module parameters sufficient for that?  (If not, why
>> > isn't it built into the driver?)
>>
>> It is customized per system to meet EMI and signal integrity targets
>> of a given platform.
>
> Given this, does it make sense to distribute a binary at all?
>

It defaults to something that is reasonable for a reference platform
and if you end up needing to customize it is easier to distribute a
new binary then move all these settings to module parameters. That
said, the intent was to start using WARN_TAINT_ONCE() if it ever got
used and phase it out once the platform support stabilized. It was
certainly convenient to have it in the same tree in the early days of
the driver. Its use should be waning now.

--
Dan
--
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/