Re: [PATCH 4/5] firmware: add SmPL report for custom fallback mechanism

[Luis R. Rodriguez]

On Fri, Dec 16, 2016 at 10:29:52AM +0100, Luis R. Rodriguez wrote:
> On Wed, Dec 14, 2016 at 10:48:37AM +0900, Milo Kim wrote:
> > Hi Jacek,
> > 
> > On 12/13/2016 06:44 PM, Jacek Anaszewski wrote:
> > > 
> > > Could you please verify if leds-lp55xx-common.c driver
> > > really needs a custom firmware loading fallback mechanism?
> > 
> > Thanks for sharing this. The lp55xx-common uses this mechanism to load and
> > run LED effect manually, so this could be a misuse case.
> > I think the right solution is providing device attributes.
> 
> Run LED manually using request_firmware()? What the.. yes this sounds odd.
> 
> > At this moment, four drivers use lp55xx-common code.
> > 
> > - lp5521, lp5523: OK if we do not support FW loading fallback mechanism
> > - lp5562, lp8501: need to create additional sysfs alternatively.
> 
> Phew!
> 
> > However, we should be careful because I'm not sure this modification will
> > generate the regression (breaking the user-space) or not.
> 
> Right so not breaking old userspace is critical.

So to recap:

What you can do is add support for the new interface and recommend folks
to use it. We just cannot break old userspace relying on the same module.

So the currently proposed DECLARE_FW_CUSTOM_FALLBACK() is still justified
for this driver. As stupid as the original implementation may have been
its there.. and we just have to deal with it. I would seriously appreciate
a revamp update on the Documentation/leds/leds-lp55xx.txt documentation though
with everything that we have discussed.

  Luis