On 2020-01-28 at 09:47:37, Arend Van Spriel wrote: > On 1/27/2020 12:00 AM, brian m. carlson wrote: > > There is also precedent for users acquiring firmware themselves via the > > b43 and b43legacy drivers, where users have to use a script to extract > > the firmware from other drivers. > > > > I wish I had a better answer to this, but I don't work for Broadcom or > > anyone associated with it and am just trying to get the Mac I was given > > for $DAYJOB to work with Linux. Perhaps since you do you'd be willing > > to ask them to release the firmware. > > > > The alternative is that the chip doesn't work at all (and can't be added > > via the new_id sysfs entry because of the rambase setting) and users > > have to compile a custom patched kernel to make their wireless card work > > at all. I'd really prefer to avoid that if possible, since it's > > a strictly worse experience in every way. > > How about putting this device under some Kconfig flag. If distro kernel > start probing the device and fail, most users will probably turn to their > distro for help. Having a Kconfig with a good description could avoid that. > It would mean an extra step of building the driver though. I can certainly do that. I don't think it provides a lot of value, since the only benefit I see is that it avoids warning about missing firmware that the distro can't ship. A typical Debian system currently warns about missing firmware for numerous other drivers (e.g., i915) at the moment without ill consequences. But if you'd prefer it that way, I can provide a v3 that does that. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
