linux-kernel - Re: [PATCH leds v1 10/10] leds: ns2: refactor and use struct led_init

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20200918191405.516b51ff@nic.cz>
Date:   Fri, 18 Sep 2020 19:14:05 +0200
From:   Marek Behun <marek.behun@....cz>
To:     Simon Guinot <simon.guinot@...uanux.org>
Cc:     linux-leds@...r.kernel.org, Pavel Machek <pavel@....cz>,
        Dan Murphy <dmurphy@...com>,
        Ondřej Jirman <megous@...ous.com>,
        linux-kernel@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
        devicetree@...r.kernel.org, Simon Guinot <sguinot@...ie.com>,
        Vincent Donnefort <vdonnefort@...il.com>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH leds v1 10/10] leds: ns2: refactor and use struct
 led_init_data

On Fri, 18 Sep 2020 15:02:06 +0200
Simon Guinot <simon.guinot@...uanux.org> wrote:

> On Thu, Sep 17, 2020 at 01:16:50AM +0200, Marek Behún wrote:
> 
> Hi Marek,
> 
> > By using struct led_init_data when registering we do not need to parse
> > `label` DT property nor `linux,default-trigger` property.
> > 
> > Also, move forward from platform data to device tree only:
> > since commit c7896490dd1a ("leds: ns2: Absorb platform data") the
> > platform data structure is absorbed into the driver, because nothing
> > else in the source tree used it. Since nobody complained and all usage  
> 
> Well, I probably should have...
> 
> I am using this driver on the Seagate Superbee NAS devices. This devices
> are based on a x86 SoC. Since I have been unable to get from the ODM the
> LED information written in the ACPI tables, then platform data are used
> to pass the LED description to the driver.
> 
> The support of this boards is not available mainline yet but it is still
> on my todo list. So that's why I am complaining right now :) If it is
> not too much trouble I'd like to keep platform data support in this
> driver.
> 
> Thanks in advance.
> 
> Simon
> 

Simon, what if we refactored the driver to use fwnode API instead of OF
API? Then if it is impossible for you to write DTS for that device,
instead of platform data you could implement your device via swnode
fwnodes. :)

static const struct property_entry entries[] = {
	PROPERTY_ENTRY_STRING("compatible", "lacie,ns2-leds"),
	...
};

Look at
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/platform/chrome/chromeos_laptop.c?h=v5.9-rc5
search for PROPERTY_ENTRY.

I am willing to work on this with you, but I would really like to rid
the LED drivers of platform data.

Marek