On Sun, 2011-12-18 at 16:15 -0800, Dan Williams wrote: > 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: [...] > >> > --- > >> > 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. I have now applied and pushed this addition to linux-firmware.git. Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it.
Attachment:
signature.asc
Description: This is a digitally signed message part
