From: Marek Behun <marek.behun@nic.cz>
To: Simon Guinot <simon.guinot@sequanux.org>
Cc: linux-leds@vger.kernel.org, "Pavel Machek" <pavel@ucw.cz>,
"Dan Murphy" <dmurphy@ti.com>,
"Ondřej Jirman" <megous@megous.com>,
linux-kernel@vger.kernel.org, "Rob Herring" <robh+dt@kernel.org>,
devicetree@vger.kernel.org, "Simon Guinot" <sguinot@lacie.com>,
"Vincent Donnefort" <vdonnefort@gmail.com>,
"Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>,
"Linus Walleij" <linus.walleij@linaro.org>
Subject: Re: [PATCH leds v1 10/10] leds: ns2: refactor and use struct led_init_data
Date: Mon, 21 Sep 2020 15:02:08 +0200 [thread overview]
Message-ID: <20200921150208.6a296bc7@nic.cz> (raw)
In-Reply-To: <20200921125343.GA4828@kw.sim.vm.gnt>
On Mon, 21 Sep 2020 14:53:43 +0200
Simon Guinot <simon.guinot@sequanux.org> wrote:
> On Fri, Sep 18, 2020 at 07:14:05PM +0200, Marek Behun wrote:
> > On Fri, 18 Sep 2020 15:02:06 +0200
> > Simon Guinot <simon.guinot@sequanux.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. :)
>
> Yes. That would be perfect.
>
> Simon
BTW if you have access to device schematics I could try to write DTS,
with schematics and the current board source file it should not be that
hard. But I can't test it, since I don't have the board.
Marek
next prev parent reply other threads:[~2020-09-21 13:02 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-16 23:16 [PATCH leds v1 00/10] Start moving parsing of `linux,default-trigger` to LED core (a cleanup of LED drivers) Marek Behún
2020-09-16 23:16 ` [PATCH leds v1 01/10] leds: parse linux,default-trigger DT property in LED core Marek Behún
2020-09-16 23:16 ` [PATCH leds v1 02/10] leds: bcm6328, bcm6358: use struct led_init_data when registering Marek Behún
2020-09-16 23:16 ` [PATCH leds v1 03/10] leds: lm3697: " Marek Behún
2020-09-17 3:45 ` kernel test robot
2020-09-17 11:39 ` Dan Murphy
2020-09-17 15:24 ` Marek Behun
2020-09-16 23:16 ` [PATCH leds v1 04/10] leds: max77650: " Marek Behún
2020-09-17 10:09 ` Bartosz Golaszewski
2020-09-16 23:16 ` [PATCH leds v1 05/10] leds: mt6323: " Marek Behún
2020-09-16 23:16 ` [PATCH leds v1 06/10] leds: pm8058: " Marek Behún
2020-09-17 0:46 ` Bjorn Andersson
2020-09-17 15:24 ` Marek Behun
2020-09-16 23:16 ` [PATCH leds v1 07/10] leds: is31fl32xx: " Marek Behún
2020-09-17 15:23 ` Marek Behun
2020-09-16 23:16 ` [PATCH leds v1 08/10] leds: is31fl319x: " Marek Behún
2020-09-16 23:16 ` [PATCH leds v1 09/10] leds: lm36274: " Marek Behún
2020-09-17 15:28 ` Dan Murphy
2020-09-17 15:54 ` Marek Behun
2020-09-16 23:16 ` [PATCH leds v1 10/10] leds: ns2: refactor and use struct led_init_data Marek Behún
2020-09-18 13:02 ` Simon Guinot
2020-09-18 17:14 ` Marek Behun
2020-09-21 12:53 ` Simon Guinot
2020-09-21 13:02 ` Marek Behun [this message]
2020-09-21 14:03 ` Simon Guinot
2020-09-21 14:31 ` Marek Behun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200921150208.6a296bc7@nic.cz \
--to=marek.behun@nic.cz \
--cc=devicetree@vger.kernel.org \
--cc=dmurphy@ti.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=megous@megous.com \
--cc=pavel@ucw.cz \
--cc=robh+dt@kernel.org \
--cc=sguinot@lacie.com \
--cc=simon.guinot@sequanux.org \
--cc=thomas.petazzoni@free-electrons.com \
--cc=vdonnefort@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.