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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAA9_cmdSE7njUQgEZkA+WKP=0is3fRiaxCMvPxg7i=vgn1Auuw@mail.gmail.com>
Date:	Sun, 18 Dec 2011 16:15:53 -0800
From:	Dan Williams <dan.j.williams@...el.com>
To:	Ben Hutchings <ben@...adent.org.uk>
Cc:	Intel SCU Linux support <intel-linux-scu@...el.com>,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [RFC][PATCH linux-firmware] isci: Add firmware blob and sources

On Sun, Dec 18, 2011 at 1:25 PM, Ben Hutchings <ben@...adent.org.uk> 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@...adent.org.uk> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/