Message-Id: <20200916231650.11484-1-marek.behun@nic.cz>
Date:   Thu, 17 Sep 2020 01:16:40 +0200
From:   Marek Behún <marek.behun@....cz>
To:     linux-leds@...r.kernel.org
Cc:     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,
        Marek Behún <marek.behun@....cz>,
        Álvaro Fernández Rojas 
        <noltari@...il.com>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        David Rivshin <drivshin@...worx.com>,
        "H . Nikolaus Schaller" <hns@...delico.com>,
        Jaedon Shin <jaedon.shin@...il.com>,
        John Crispin <john@...ozen.org>,
        Kevin Cernekee <cernekee@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Ryder Lee <ryder.lee@...iatek.com>,
        Sean Wang <sean.wang@...iatek.com>,
        Simon Guinot <sguinot@...ie.com>,
        Simon Guinot <simon.guinot@...uanux.org>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        Vincent Donnefort <vdonnefort@...il.com>
Subject: [PATCH leds v1 00/10] Start moving parsing of `linux,default-trigger` to LED core (a cleanup of LED drivers)

Hi,

this series is also available at
  https://git.kernel.org/pub/scm/linux/kernel/git/kabel/linux.git/log/?h=leds-cleanup-for-pavel

this is a cleanup of some LED subsystem drivers. The main reason behind
this is that I wanted to avoid code repetition by moving the parsing
of `linux,default-trigger` DT property from specific drivers to LED
core. Before this series 32 drivers parse this property (31 in
drivers/leds and one in drivers/input/keyboard/cap11xx.c).
After applying this series only 10 drivers are parsing this property.

The reason is that in discussion [1] Rob Herring says that
`linux,default-trigger` DT property is deprecated in favor of the
`function` DT property. This makes sense in a way since DT should not
be Linux specific.

After all drivers are converted we can maybe start work on slow
deprecation of this property. I do realize that we can't take it away,
but we can at least convert device trees in Linux repository to stop
using it in favor of `function` (and for default-on trigger in favor
of the `default-state` DT property), and print a deprecation warning
to the user when this `linux,default-trigger` property is present.

I wanted to prepare the way for slow deprecation of the DT property,
but it turns out that it is more difficult.

The first thing I wanted to do was to move the parsing of the
`linux,default-trigger` property to LED core. Currently many drivers
do this themselves. But it can't be moved that simply.

The first patch in this series adds the parsing of this DT property
into led_classdev_register_ext. If fwnode is given in init_data, the
property is read. This patch also removes the parsing of this property
from drivers where led_classdev_register_ext is already called. These
are:
  an30259a, aw2013, cr0014114, el15203000, gpio, lm3532, lm3692x,
  lp8860, lt3593, tlc591xx and turris-omnia.

Patches 2 to 6 do a simple conversion of some drivers to use
led_classdev_register_ext. These drivers are:
  bcm6328, bcm6358, lm3697, max77650, mt6323 and pm8058.

In patches 7 to 10 I did a bigger refactor: either they first parsed
all LED nodes and only after that started registering them, or they
used too deep nesting or were weird in some other ways:
  is31fl32xx, is31fl319x, lm36274 and ns2.

There is still a long way to go: some drivers still use the old
platform_data framework (which has a different structure for every
driver) instead of device properties via fwnode_* functions or OF).

Some of these can be changed to use device tree only, since they
already support it and the platform_data isn't used by anything in
the kernel (for example tca6507 can work with platform_data but
there is no board definition using it, all usage is via DT).

Some will be harder, because the platform_data code is still used
(pca9532 is used in arch/arm/mach-iop32x/n2100.c). Even this can
be done by converting the drivers to use fwnode_* API and converting
the mach code to use swnodes. I shall look into this later.

This series is compile tested on top of Pavel's tree. Since I
obviously don't have the various hardware that this code touches,
I am unable to test it. I therefore add maintainers and authors of
these drivers to Cc.

Marek

[1] https://lore.kernel.org/linux-leds/20200909235819.0b0fe7ce@nic.cz/T/#m3b6c154f49d0467a707c0f9a552ec87bcbd89df2

Cc: Álvaro Fernández Rojas <noltari@...il.com>
Cc: Bartosz Golaszewski <bgolaszewski@...libre.com>
Cc: Bjorn Andersson <bjorn.andersson@...aro.org>
Cc: Dan Murphy <dmurphy@...com>
Cc: David Rivshin <drivshin@...worx.com>
Cc: H. Nikolaus Schaller <hns@...delico.com>
Cc: Jaedon Shin <jaedon.shin@...il.com>
Cc: John Crispin <john@...ozen.org>
Cc: Kevin Cernekee <cernekee@...il.com>
Cc: Linus Walleij <linus.walleij@...aro.org>
Cc: Ryder Lee <ryder.lee@...iatek.com>
Cc: Sean Wang <sean.wang@...iatek.com>
Cc: Simon Guinot <sguinot@...ie.com>
Cc: Simon Guinot <simon.guinot@...uanux.org>
Cc: Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Cc: Vincent Donnefort <vdonnefort@...il.com>

Marek Behún (10):
  leds: parse linux,default-trigger DT property in LED core
  leds: bcm6328, bcm6358: use struct led_init_data when registering
  leds: lm3697: use struct led_init_data when registering
  leds: max77650: use struct led_init_data when registering
  leds: mt6323: use struct led_init_data when registering
  leds: pm8058: use struct led_init_data when registering
  leds: is31fl32xx: use struct led_init_data when registering
  leds: is31fl319x: use struct led_init_data when registering
  leds: lm36274: use struct led_init_data when registering
  leds: ns2: refactor and use struct led_init_data

 drivers/leds/Kconfig             |   2 +-
 drivers/leds/led-class.c         |   5 +
 drivers/leds/leds-an30259a.c     |   3 -
 drivers/leds/leds-aw2013.c       |   3 -
 drivers/leds/leds-bcm6328.c      |  10 +-
 drivers/leds/leds-bcm6358.c      |  10 +-
 drivers/leds/leds-cr0014114.c    |   3 -
 drivers/leds/leds-el15203000.c   |   3 -
 drivers/leds/leds-gpio.c         |   3 -
 drivers/leds/leds-is31fl319x.c   | 204 ++++++++---------
 drivers/leds/leds-is31fl32xx.c   |  95 +++-----
 drivers/leds/leds-lm3532.c       |   3 -
 drivers/leds/leds-lm36274.c      | 100 +++++----
 drivers/leds/leds-lm3692x.c      |   3 -
 drivers/leds/leds-lm3697.c       |  18 +-
 drivers/leds/leds-lp8860.c       |   4 -
 drivers/leds/leds-lt3593.c       |   3 -
 drivers/leds/leds-max77650.c     |  24 +-
 drivers/leds/leds-mt6323.c       |  13 +-
 drivers/leds/leds-ns2.c          | 361 ++++++++++---------------------
 drivers/leds/leds-pm8058.c       |  38 ++--
 drivers/leds/leds-tlc591xx.c     |   2 -
 drivers/leds/leds-turris-omnia.c |   2 -
 23 files changed, 337 insertions(+), 575 deletions(-)

-- 
2.26.2

Powered by blists - more mailing lists