linux-kernel.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).