All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Behun <marek.behun@nic.cz>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Robin van der Gracht <robin@protonic.nl>,
	Rob Herring <robh+dt@kernel.org>, Miguel Ojeda <ojeda@kernel.org>,
	Paul Burton <paulburton@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Pavel Machek <pavel@ucw.cz>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	linux-leds <linux-leds@vger.kernel.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 18/18] auxdisplay: ht16k33: Add segment display LED support
Date: Mon, 28 Jun 2021 12:15:51 +0200	[thread overview]
Message-ID: <20210628121551.185ce0f4@thinkpad> (raw)
In-Reply-To: <CAMuHMdV5fywjF63MqE_SqfumwN3EY=jBTEiMfqbjFO12c_nj0Q@mail.gmail.com>

On Mon, 28 Jun 2021 11:21:04 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> Hi Marek,
> 
> On Fri, Jun 25, 2021 at 10:39 PM Marek Behun <marek.behun@nic.cz> wrote:
> > On Fri, 25 Jun 2021 14:59:02 +0200
> > Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >  
> > > Instantiate a single LED for a segment display.  This allows the user to
> > > control display brightness and blinking through the LED class API and
> > > triggers, and exposes the display color.
> > > The LED will be named "auxdisplay:<color>:backlight".  
> >
> > What if there are multiple "auxdisplay"s ?  
> 
> I understand the LED core will just add a suffix on a name collision.
> 
> > Doesn't this subsystem have IDs? So that you can use auxdisplayN for
> > device name, for example?  
> 
> Auxdisplay does not have IDs, as there is no subsystem to register
> with.  It's just a collection of drivers for auxiliary displays with
> no common API.  Some drivers use fbdev, others use a chardev, or an
> attribute file in sysfs.
> 
> BTW, I just followed Pavel's advice in naming.

Very well.

> > > +     of_property_read_u32(node, "color", &color);
> > > +     seg->led.name = devm_kasprintf(dev, GFP_KERNEL,
> > > +                     "auxdisplay:%s:" LED_FUNCTION_BACKLIGHT,
> > > +                     color < LED_COLOR_ID_MAX ? led_colors[color] : "");  
> >
> > If you use devm_led_classdev_register_ext and pass struct
> > led_init_data, LED core will generate name of the LED itself.  
> 
> Will that make any difference, except for adding more code?

You are hardcoding the backlight function. Using the _ext() registering
function will make it so that the function and color are parsed from
fwnode by LED core. I understand that the function will always be
"backlight" in this case, but this should be specified in the
device-tree anyway, so why not use it?

> Looking at the implementation, I still have to use devm_kasprintf()
> to combine color and function for led_init_data.default_label?

AFAIK you don't have to fill in default_label. (If the needed OF
properties are not present so that default_label is tried, it means the
device-tree does not correctly specify the device. In that case I don't
think it is a problem if the default_label is not present and LED
core will use the OF node name as the LED name.)

The code could look like this

  struct led_init_data init_data = {};

  init_data.fwnode = of_fwnode_handle(node);
  init_data.devicename = "auxdisplay";
  init_data.devname_mandatory = true;

  ...register_ext();

But if you still don't want to do this then ignore me :)

Marek

  reply	other threads:[~2021-06-28 10:15 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-25 12:58 [PATCH v2 00/18] auxdisplay: ht16k33: Add character display support Geert Uytterhoeven
2021-06-25 12:58 ` [PATCH v2 01/18] uapi: Add <linux/map_to_14segment.h> Geert Uytterhoeven
2021-06-25 12:58 ` [PATCH v2 02/18] dt-bindings: auxdisplay: ht16k33: Document Adafruit segment displays Geert Uytterhoeven
2021-07-14 20:36   ` Rob Herring
2021-07-15  7:12     ` Geert Uytterhoeven
2021-07-15 14:32       ` Rob Herring
2021-07-15 15:06         ` Geert Uytterhoeven
2021-06-25 12:58 ` [PATCH v2 03/18] auxdisplay: img-ascii-lcd: Fix lock-up when displaying empty string Geert Uytterhoeven
2021-06-25 12:58 ` [PATCH v2 04/18] auxdisplay: img-ascii-lcd: Add helper variable dev Geert Uytterhoeven
2021-06-25 12:58 ` [PATCH v2 05/18] auxdisplay: img-ascii-lcd: Convert device attribute to sysfs_emit() Geert Uytterhoeven
2021-06-25 12:58 ` [PATCH v2 06/18] auxdisplay: Extract character line display core support Geert Uytterhoeven
2021-06-25 23:35   ` kernel test robot
2021-06-25 23:35     ` kernel test robot
2021-06-28 10:17     ` Geert Uytterhoeven
2021-06-28 10:17       ` Geert Uytterhoeven
2021-06-25 12:58 ` [PATCH v2 07/18] auxdisplay: linedisp: Use kmemdup_nul() helper Geert Uytterhoeven
2021-06-25 12:58 ` [PATCH v2 08/18] auxdisplay: linedisp: Add support for changing scroll rate Geert Uytterhoeven
2021-06-25 12:58 ` [PATCH v2 09/18] auxdisplay: ht16k33: Connect backlight to fbdev Geert Uytterhoeven
2021-06-25 12:58 ` [PATCH v2 10/18] auxdisplay: ht16k33: Use HT16K33_FB_SIZE in ht16k33_initialize() Geert Uytterhoeven
2021-06-25 12:58 ` [PATCH v2 11/18] auxdisplay: ht16k33: Remove unneeded error check in keypad probe() Geert Uytterhoeven
2021-06-25 12:58 ` [PATCH v2 12/18] auxdisplay: ht16k33: Convert to simple i2c probe function Geert Uytterhoeven
2021-06-25 12:58 ` [PATCH v2 13/18] auxdisplay: ht16k33: Add helper variable dev Geert Uytterhoeven
2021-06-25 12:58 ` [PATCH v2 14/18] auxdisplay: ht16k33: Move delayed work Geert Uytterhoeven
2021-06-25 12:58 ` [PATCH v2 15/18] auxdisplay: ht16k33: Extract ht16k33_brightness_set() Geert Uytterhoeven
2021-06-25 12:59 ` [PATCH v2 16/18] auxdisplay: ht16k33: Extract frame buffer probing Geert Uytterhoeven
2021-06-25 12:59 ` [PATCH v2 17/18] auxdisplay: ht16k33: Add support for segment displays Geert Uytterhoeven
2021-06-25 12:59 ` [PATCH v2 18/18] auxdisplay: ht16k33: Add segment display LED support Geert Uytterhoeven
2021-06-25 20:39   ` Marek Behun
2021-06-25 20:40     ` Marek Behun
2021-06-28  9:21       ` Geert Uytterhoeven
2021-06-28  9:21     ` Geert Uytterhoeven
2021-06-28 10:15       ` Marek Behun [this message]
2021-06-28 15:33         ` Geert Uytterhoeven

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=20210628121551.185ce0f4@thinkpad \
    --to=marek.behun@nic.cz \
    --cc=devicetree@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=paulburton@kernel.org \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    --cc=robin@protonic.nl \
    /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.