On Tue, Dec 13, 2016 at 08:04:29PM +0100, Pavel Machek wrote:
> Hi!
>
> > We need to ensure that when driver developers use the custom firmware
> > fallback mechanism it was not a copy and paste bug. These use cases on
> > upstream drivers are rare, we only have 2 upstream users and its for
> > really old drivers. Since valid uses are rare but possible enable a
> > white-list for its use, and use this same white-list annotation to refer
> > to the documentation covering the custom use case.
>
> > --- a/drivers/leds/leds-lp55xx-common.c
> > +++ b/drivers/leds/leds-lp55xx-common.c
> > @@ -219,6 +219,7 @@ static void lp55xx_firmware_loaded(const struct
> > firmware *fw, void *context)
> > release_firmware(chip->fw);
> > }
> >
> > +DECLARE_FW_CUSTOM_FALLBACK("Documentation/leds/leds-lp55xx.txt");
> > static int lp55xx_request_firmware(struct lp55xx_chip *chip)
> > {
> > const char *name = chip->cl->name;
>
> The driver does:
>
> static void lp55xx_firmware_loaded(const struct firmware *fw, void
> *context)
> {
> struct lp55xx_chip *chip = context;
> struct device *dev = &chip->cl->dev;
> enum lp55xx_engine_index idx =
> chip->engine_idx;
>
> if (!fw) {
> dev_err(dev, "firmware request failed\n");
> goto out;
> }
> ...
> out:
> /* firmware should be released for other channel use */
> release_firmware(chip->fw);
> }
>
>
> Does that match the "custom fallback" definition?
Refer to the documentation I supplied, and also to the grammar rule, in
particular the patch "firmware: add SmPL report for custom fallback mechanism",
it captures the SmPL form for the custom fallback mechanism as:
@ r1 depends on report || context @
expression mod, name, dev, gfp, drv, cb;
position p;
@@
(
*request_firmware_nowait@p(mod, false, name, dev, gfp, drv, cb)
|
*request_firmware_nowait@p(mod, 0, name, dev, gfp, drv, cb)
|
*request_firmware_nowait@p(mod, FW_ACTION_NOHOTPLUG, name, dev, gfp, drv, cb)
)
