All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maciek Borzecki <maciek.borzecki@gmail.com>
To: Josh Cartwright <joshc@ni.com>
Cc: linux-kernel@vger.kernel.org, Richard Purdie <rpurdie@rpsys.net>,
	Jacek Anaszewski <j.anaszewski@samsung.com>,
	linux-leds@vger.kernel.org, linux-doc@vger.kernel.org,
	Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH v2 1/3] leds: add device activity LED triggers
Date: Fri, 2 Oct 2015 21:09:13 +0200	[thread overview]
Message-ID: <20151002190913.GA2264@corsair.lan> (raw)
In-Reply-To: <20151002170854.GA10631@jcartwri.amer.corp.natinst.com>

On 10/02 12:08, Josh Cartwright wrote:
<snip>
>
> Hmm, maybe we're bikeshedding at this point, but LEDs with those names
> seem much more straightfoward to me than a "dev-<maj>:<min>" name, for
> devices which have done dynamic dev_t allocation.
>
> > Also, if I'm not mistaken, using this approach the partitions on MMC
> > card or SATA drive would end up with the same trigger name, as it is a
> > single device.
>
> This would only be true if you used _just_ the struct device.  I was
> imagining that you'd specify a (struct device, unsigned index) pair.
> Better, you could do a (struct device, const char *) pair.
>
> Also, from a lifetime management perspective, it starts to feel like
> something that might integrate better as a managed resource (devm_*).
>
> [..]
> > Multiple dev nodes will already have different minor numbers, so
> > their dev_t is different anyway.
>
> Okay, backing up I don't really see what this API really buys the
> consumer.  The dev_t -> struct led_trigger mapping just seems like a
> total waste.  Why not just make your ledtrig_dev_add() function return
> the struct led_trigger * that the consumer keeps track of?
>
> Maybe seeing an example consumer would provide some clarification.
>
> > As for devices that do not have a dev_t assigned to them one can still
> > pass a custom tag in ledtrig_dev_add(). It's just a number so as long as
> > there's no collision in numbering things should be fine.
>
> Ensuring no collision will be difficult, especially given that it's most
> common that the dynamic allocator is used.  In order to guarantee no
> collisions, a user who doesn't expose any device nodes would need to do
> their own dev_t allocation...to use this interface.  And that seems
> silly to me.

Thanks, I really appreciate your feedback.

--
Maciek Borzecki

  reply	other threads:[~2015-10-02 19:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-01 14:04 [PATCH v2 0/3] leds: add device trigger Maciek Borzecki
2015-10-01 14:04 ` [PATCH v2 1/3] leds: add device activity LED triggers Maciek Borzecki
2015-10-01 14:47   ` Josh Cartwright
2015-10-02  7:45     ` Maciek Borzecki
2015-10-02 17:08       ` Josh Cartwright
2015-10-02 19:09         ` Maciek Borzecki [this message]
2015-10-01 14:04 ` [PATCH v2 2/3] leds: add debugfs to device trigger Maciek Borzecki
2015-10-01 14:04 ` [PATCH v2 3/3] Documentation: leds: document ledtrig-device trigger Maciek Borzecki
2015-10-02 14:27 ` [PATCH v2 0/3] leds: add device trigger Jacek Anaszewski
2015-10-02 16:26   ` Maciek Borzecki

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=20151002190913.GA2264@corsair.lan \
    --to=maciek.borzecki@gmail.com \
    --cc=corbet@lwn.net \
    --cc=j.anaszewski@samsung.com \
    --cc=joshc@ni.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=rpurdie@rpsys.net \
    /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.