From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-kernel@vger.kernel.org, rdunlap@xenotime.net,
arve@android.com, kernel-team@android.com,
john.stultz@linaro.org
Subject: Re: [PATCH v2] drivers/tty: Folding Android's keyreset driver in sysRQ
Date: Tue, 04 Sep 2012 15:53:01 -0600 [thread overview]
Message-ID: <5046783D.4020702@linaro.org> (raw)
In-Reply-To: <20120831232234.GB22142@core.coreip.homeip.net>
On 12-08-31 05:22 PM, Dmitry Torokhov wrote:
> On Fri, Aug 31, 2012 at 04:57:04PM -0600, Mathieu Poirier wrote:
>> On 12-08-31 04:41 PM, Dmitry Torokhov wrote:
>>> On Fri, Aug 31, 2012 at 11:02:27PM +0100, Alan Cox wrote:
>>>>>> Why do we need to involve a platform device and not use, for example, a module
>>>>>> parameter, that could be set up from userspace?
>>>>>
>>>>> The platform device comes from the original design and was included to
>>>>> minimise the amount of changes in code that make use of the current
>>>>> keyreset driver.
>>>>
>>>> The platform device is IMHO the right answer. In this class of devices
>>>> the stuff is compiled in, the userspace is Android, there are no modules
>>>> and there is no reason for it to be configurable.
>>>
>>> It does not matter if it is built in or not, /sys/module/XXX/parameters
>>> is still there, and while havig it in kernel is "easy" you could as
>>> easily stuff needed data into a sysfs attribute during booting.
>>>
>>> And we should be able to get this from DT even without the platform
>>> device (this was the next step, wasn't it?).
>>
>> Correct - my hope was to get the main functionality accepted before
>> adding DT support. Do you think the lack of DT support is a blocker for
>> acceptance ? Please confirm.
>>
>
> No, lack of DT is not a blocker, but I am unconvinced that we need
> platform device.
>
> Thanks,
>
A platform device is really easy to spin-off in a board file and once it
is there you don't have to worry about other loose ends to tie in before
the solution is functional.
I don't mind supplementing the current proposition with a module
parameter interface to get the "key_down" and "key_up" sequences.
Which brings us to the "reset_fn()" function - in my opinion it offers
significant advantages and should be kept in the design. What I'm not
so clear about is on the implementation. Should it be kept as part of a
platform data or be implemented as a notifier as suggested by Alan. I
am looking for guidance here and suggestions are encouraged.
Regards,
Mathieu.
next prev parent reply other threads:[~2012-09-04 21:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-30 22:30 [PATCH v2] drivers/tty: Folding Android's keyreset driver in sysRQ mathieu.poirier
2012-08-30 23:01 ` Dmitry Torokhov
2012-08-31 21:52 ` Mathieu Poirier
2012-08-31 22:02 ` Alan Cox
2012-08-31 22:41 ` Dmitry Torokhov
2012-08-31 22:57 ` Mathieu Poirier
2012-08-31 23:22 ` Dmitry Torokhov
2012-09-04 21:53 ` Mathieu Poirier [this message]
2012-09-04 22:01 ` Alan Cox
2012-08-31 22:51 ` Mathieu Poirier
2012-09-01 19:18 ` Colin Cross
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=5046783D.4020702@linaro.org \
--to=mathieu.poirier@linaro.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arve@android.com \
--cc=dmitry.torokhov@gmail.com \
--cc=john.stultz@linaro.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@xenotime.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.