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
next prev parent 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).