Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1556844 > unrolled thread

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

Started by"Luis R. Rodriguez" <mcgrof@kernel.org>
First post2017-01-11 20:00 +0100
Last post2017-01-11 20:00 +0100
Articles 1 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 4/5] firmware: add SmPL report for custom fallback  mechanism "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-01-11 20:00 +0100

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

From"Luis R. Rodriguez" <mcgrof@kernel.org>
Date2017-01-11 20:00 +0100
SubjectRe: [PATCH 4/5] firmware: add SmPL report for custom fallback mechanism
Message-ID<sYwhP-21a-27@gated-at.bofh.it>
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

[toc] | [standalone]


Back to top | Article view | linux.kernel


csiph-web