Message ID | 20180504174356.13227-1-mcgrof@kernel.org |
---|---|
Headers | show |
Series | firmware_loader: cleanups for v4.18 | expand |
"Luis R. Rodriguez" <mcgrof@kernel.org> writes: > * CONFIG_WANXL --> CONFIG_WANXL_BUILD_FIRMWARE > * CONFIG_SCSI_AIC79XX --> CONFIG_AIC79XX_BUILD_FIRMWARE > > To this day both of these drivers are building driver *firmwares* when > the option CONFIG_PREVENT_FIRMWARE_BUILD is disabled, and they don't > even make use of the firmware API at all. Don't know for sure about Adaptec, but wanXL firmware fits every definition of "stable". BTW it's a 1997 or so early PCI card, built around the PLX PCI9060 bus mastering PCI bridge and Motorola 68360 (the original QUICC) processor. Maximum bit rate of 2 Mb/s on each sync serial port. It's more about delivering the .S source for the firmware, I guess. Nobody is expected to build it. The fw is about 2.5 KB and is directly linked with the driver.
On Fri, May 04, 2018 at 09:17:08PM +0200, Krzysztof Halasa wrote: > "Luis R. Rodriguez" <mcgrof@kernel.org> writes: > > > * CONFIG_WANXL --> CONFIG_WANXL_BUILD_FIRMWARE > > * CONFIG_SCSI_AIC79XX --> CONFIG_AIC79XX_BUILD_FIRMWARE > > > > To this day both of these drivers are building driver *firmwares* when > > the option CONFIG_PREVENT_FIRMWARE_BUILD is disabled, and they don't > > even make use of the firmware API at all. > > Don't know for sure about Adaptec, but wanXL firmware fits every > definition of "stable". BTW it's a 1997 or so early PCI card, built > around the PLX PCI9060 bus mastering PCI bridge and Motorola 68360 > (the original QUICC) processor. Maximum bit rate of 2 Mb/s on each sync > serial port. So we can nuke CONFIG_WANXL_BUILD_FIRMWARE now? > It's more about delivering the .S source for the firmware, I guess. > Nobody is expected to build it. The fw is about 2.5 KB and is directly > linked with the driver. :P Future work I guess would be to just use the firmware API and stuff it into linux-firmware? Luis
"Luis R. Rodriguez" <mcgrof@kernel.org> writes: > So we can nuke CONFIG_WANXL_BUILD_FIRMWARE now? I'm uncertain I understand why do you want it, or maybe what are you trying to do at all. And what use would wanxlfw.S (the assembly source) have if the option is removed? >> It's more about delivering the .S source for the firmware, I guess. >> Nobody is expected to build it. The fw is about 2.5 KB and is directly >> linked with the driver. > > :P Future work I guess would be to just use the firmware API and stuff > it into linux-firmware? Who's going to make it happen? The last time I checked (several years ago), wanXL worked. Who's going to test it after the change? I assume linux-firmware could include fw source and there would be means to build the binary. Just to be sure: the wanXL firmware has exactly nothing to do with FW loader, nothing depends on it (nor the other way around), it's just (with the rest of the wanXL code) an old piece of a driver for an old card. The question is, what do we gain by messing with it?
On Fri, May 04, 2018 at 10:43:49AM -0700, Luis R. Rodriguez wrote: > Greg, > > I've reviewed the pending patches for the firmware_laoder and as for > v4.18, the following 3 patches from Andres have been iterated enough > that they're ready after I made some final minor changes, mostly just > style fixes and re-arrangements in terms of order. The new API he was > suggesting to add requires just a bit more review. We're done with review of the new API for the sync no warn call, so I'll just re-issue another patch series with those patches in a new series. Coming right up. Luis