From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: Dmitry Torokhov <dtor@chromium.org>,
linux-input@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] input: keyboard: gpio-keys-polled: use input name from pdata if available
Date: Thu, 14 Feb 2019 09:01:14 +0100 [thread overview]
Message-ID: <089b2db5-50bc-e180-e39e-1e791bf6e044@metux.net> (raw)
Dmitry Torokhov wrote:
sorry for the late reply - lost your mail by broken filter :(
(just picked it out now of the archive ...)
> > Instead of hardcoding the input name to the driver name
('gpio-keys-polled'),
> > allow the passing a name via platform data ('name' field was already
present),
> > but default to old behaviour in case of NULL.
> I thought the world is moving away from platform data and towards
> OF/ACPI systems. What device are you targeting with this change?
Well, it that only would be available everywhere :o
I've written an platform driver for the APUv2 board, which has an
gpio-attached button and LEDs on the front. It's an x86 machine,
(= no OF), and no usable ACPI information (no, I won't patch up
the bios for that, unless somebody inserts enough coins ;-))
Therefore, I need to pass everything via platform data.
By the way: I've also added support for gpio lookup table.
(sending it w/ the next patch queue)
> I would want to convert gpio-keys[-polled] to generic device
> properties and away form platform data...
I'd like to see that too, but it's not that easy. Not all platforms
support proper generic configuration mechanisms.
Maybe it would be easier, if we had oftree everywhere, and drivers
for composite devices could directly inject (locally scoped) oftree
nodes.For example, a PCI-based GPU board which has lots of sub-devices
like regulators, sensors, fans, etc. The driver then would be probed via
PCI, declare it's own bus and probe the individual devices by it's
own of subtree. Well, that's gonna take a lot more discussions ...
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
next reply other threads:[~2019-02-14 8:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-14 8:01 Enrico Weigelt, metux IT consult [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-06-06 22:43 repost: input: keyboard: gpio-keys-polled: use input name from pdata Enrico Weigelt, metux IT consult
2019-06-06 22:43 ` [PATCH] input: keyboard: gpio-keys-polled: use input name from pdata if available Enrico Weigelt, metux IT consult
2019-02-11 11:19 Enrico Weigelt, metux IT consult
2019-02-07 17:05 Enrico Weigelt, metux IT consult
2019-02-08 7:35 ` Dmitry Torokhov
2019-01-22 12:00 Enrico Weigelt, metux IT consult
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=089b2db5-50bc-e180-e39e-1e791bf6e044@metux.net \
--to=lkml@metux.net \
--cc=dtor@chromium.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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