On Tue, Mar 1, 2016 at 9:54 AM, Luis R. Rodriguez <[email protected]> wrote: > On Tue, Mar 01, 2016 at 08:10:24AM -0800, James Bottomley wrote: >> On Mon, 2016-02-29 at 10:12 +0000, David Woodhouse wrote: >> > On Fri, 2016-02-19 at 05:45 -0800, Luis R. Rodriguez wrote: >> > > This ports built-in firmware to use linker tables, >> > > this replaces the custom section solution with a >> > > generic solution. >> > > >> > > This also demos the use of the .rodata (SECTION_RO) >> > > linker tables. >> > > >> > > Tested with 0 built-in firmware, 1 and 2 built-in >> > > firmwares successfully. >> > >> > I think we'd do better to rip this support out entirely. It just >> > isn't needed; firmware can live in an initramfs and don't even need >> > *any* actual running userspace support to load it from there these >> > days, do we? >> >> We have lots of SCSI drivers with built in firmware. The obvious >> examples are 53c700, aic7xxx and aic79xx. For them, we actually have >> the firmware compilers in tree. The firmware model they use just isn't >> amenable to the firmware loader: they're not monolithic blobs, it's a >> set of firmware scripts we use to handle particular operations before >> giving control back to the host, so the firmware and the driver are >> very much symbiotic. > > I'm in the process of doing some other cleanups with the firmware_class > stuff so that odd requirements get supported but clean interfaces are > also not hampered by these odd requirements, so I'll take a look at > this later. If you have other oddball firmware requirements please > let me know so I can also keep in mind. > >> On the other hand, I don't think any of them uses firmware sections, so >> it's not an argument for not ripping out this type. > > Thanks for confirming. I'll rip this out.
Just a heads up, I've put the removal through 0-day without issues, I'll be folding the removal into another series of changes for the firmware API which should help compartmentalize the user mode helper stuff as well. Luis
