linux-kernel - Re: [RFC PATCH 0/5] leds: Add DT node finding and parsing to core

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <946f091e79242b9e71d5ce8ad12c899feefa22cd.camel@fi.rohmeurope.com>
Date:   Mon, 18 Nov 2019 10:38:16 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "mazziesaccount@...il.com" <mazziesaccount@...il.com>,
        "info@...ux.net" <info@...ux.net>
CC:     "dmurphy@...com" <dmurphy@...com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "pavel@....cz" <pavel@....cz>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
        "jacek.anaszewski@...il.com" <jacek.anaszewski@...il.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>
Subject: Re: [RFC PATCH 0/5] leds: Add DT node finding and parsing to core

Hello Enrico & All,

First of all - thanks for showing the interest :] I am happy knowing
someone actually was interested about the RFC :)

On Mon, 2019-11-18 at 10:21 +0100, Enrico Weigelt, metux IT consult
wrote:
> Hi,
> 
> 
> > The thing is that
> > this approach requires the LED controller binding to dictate
> > allowed
> > LED node names - which may or may not be doable. I need your help
> > to
> > evaluate this and suggest better options :)
> 
> even though I like the idea of convention-over-code, but if that's
> changing allowed LED names that would risk breaking things, eg:
> 
> a) existing DT's (in the field) become incompatible with newer
>    kernel versions

This was my main concern. This of course would not mean that we could
not take this approach for new LED controller drivers - but that would
(probably) lead to dual led registration interface - one for current
approach where LED drivers do all the dirty work themself - and parse
the DT - one for new drivers which could leave DT parsing to LED core.

> b) existing userlands that rely on speicific LED names become
>    incomatible with newer kernel versions.

I didn't even think this far, but yes, I see... LED node name might be
reflected in user-space LED name. I won't start arguing if this is sane
or not - this is what we seem to be living with today :)

Anyways, I did send out a LED core change patch which allows one to add
either the node-name, or a property-value pair in init_data. LED core
can then use either of these to do LED node lookup. If none of these is
given, then we can fall-back to existing logic. That way we won't
change existing stuff.
Here:
https://lore.kernel.org/lkml/258b5c9934e2b31a5f433a7dbb908dfe5da3d30c.1574059625.git.matti.vaittinen@fi.rohmeurope.com/T/#u

I didn't invest too much of time on this yet - but at first glimpse it
seemed that at least some of the drivers did use reg - property with
fixed value to do the matching. Those could set the property name to
'reg' and value to 'X' and leave the DT node lookup and common property
parsing to the LED core. If my patch won't get too big objection (and
if no fatal flaws are found from the idea) - then I might try and find
the time to do some follow-up patches simplifying existing LED
drivers...

> 
> 
> 
> --mtx
>