Re: [PATCH v7 4/8] firmware: Add new platform fallback mechanism and firmware_request_platform()

[Hans de Goede]

Hi Dmitry,

On 05-10-2019 01:17, Dmitry Torokhov wrote:
> Hi Hans,
>
> On Fri, Oct 04, 2019 at 04:50:52PM +0200, Hans de Goede wrote:
> > In some cases the platform's main firmware (e.g. the UEFI fw) may contain
> > an embedded copy of device firmware which needs to be (re)loaded into the
> > peripheral. Normally such firmware would be part of linux-firmware, but in
> > some cases this is not feasible, for 2 reasons:
> >
> > 1) The firmware is customized for a specific use-case of the chipset / use
> > with a specific hardware model, so we cannot have a single firmware file
> > for the chipset. E.g. touchscreen controller firmwares are compiled
> > specifically for the hardware model they are used with, as they are
> > calibrated for a specific model digitizer.
> >
> > 2) Despite repeated attempts we have failed to get permission to
> > redistribute the firmware. This is especially a problem with customized
> > firmwares, these get created by the chip vendor for a specific ODM and the
> > copyright may partially belong with the ODM, so the chip vendor cannot
> > give a blanket permission to distribute these.
> >
> > This commit adds a new platform fallback mechanism to the firmware loader
> > which will try to lookup a device fw copy embedded in the platform's main
> > firmware if direct filesystem lookup fails.
> >
> > Drivers which need such embedded fw copies can enable this fallback
> > mechanism by using the new firmware_request_platform() function.
>
> Why would drivers not want to fetch firmware from system firmware if it
> is not present on disk? I would say let driver to opt-out of this
> fallback, but default request_firmware() should do it by default.

Only few devices / device-drivers have / need firmware which is
embedded in the system-fw. Checking for this introduces an extra call
in the firmware-loader path and the firmware-loader maintainer have
requested to make this opt-in, rather then opt-out, so that these changes
do not impact the many many other drivers which do not need this.

To be precise so far only the 2 touchscreen drivers for which patches
are in this series are known to benefit from this approach. So since this
is somewhat of a special case opt-in makes more sense then opt-out.

Regards,

Hans