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. > > --- > > 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? Ben. > > probe_roms.h is labelled with a dual BSD/GPLv2 licence but the other > > files had no licence header so I've treated them as GPLv2 by default. > > The latest version of probe_roms.h [1] supports the v1.3 oem parameter > format, this patch appears to be v1.0 based. > > Regards, > Dan > > [1]: http://git.kernel.org/?p=linux/kernel/git/djbw/isci.git;a=blob;f=drivers/scsi/isci/probe_roms.h;hb=refs/heads/fixes -- Ben Hutchings Teamwork is essential - it allows you to blame someone else.
Attachment:
signature.asc
Description: This is a digitally signed message part
