From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Pavel Machek <pavel@suse.cz>
Cc: rpurdie@rpsys.net, lenz@cs.wisc.edu,
kernel list <linux-kernel@vger.kernel.org>,
vojtech@suse.cz
Subject: Re: [patch 1/2] Touchscreen support for sharp sl-5500
Date: Mon, 25 Jul 2005 10:16:05 -0500 [thread overview]
Message-ID: <d120d500050725081664cd73fe@mail.gmail.com> (raw)
In-Reply-To: <20050725045607.GA1851@elf.ucw.cz>
Hi Pavel,
On 7/24/05, Pavel Machek <pavel@suse.cz> wrote:
>
> I have made quite a lot of cleanups to touchscreen part, and it seems
> to be acceptable by input people. I think it should go into
> drivers/input/touchscreen/collie_ts.c... Also it looks to me like
> mcp.h should go into asm/arch-sa1100, so that other drivers can use it...
I have couple of nitpicks (below) and one bigger concern - I am
surprised that a driver for a physical device is implemented as an
interface to a class device. This precludes implementing any kind of
power management in the driver and pushes it into the parent and is
generally speaking is a wrong thing to do (IMHO).
If the problem is that you have a single piece of hardware you need to
bind several drivers to - I guess you will have to create a new
sub-device bus for that. Or just register sub-devices on the same bus
the parent device is registered on - I am not sure what is best in
this particular case - I am not familiar with the arch. It is my
understanding that the purpose of interfaces to to present different
"views" to userspace and therefore they are not quie suited for what
you are trying to do...
> +static int ucb1x00_thread(void *_ts)
> +{
> + struct ucb1x00_ts *ts = _ts;
> + struct task_struct *tsk = current;
> + int valid;
> +
> + ts->rtask = tsk;
Just move that assignment into ucb1x00_input_open and kill all this
"current" stuff.
> +
> + /*
> + * We run as a real-time thread. However, thus far
> + * this doesn't seem to be necessary.
> + */
> + tsk->policy = SCHED_FIFO;
> + tsk->rt_priority = 1;
> +
> + valid = 0;
> + for (;;) {
Can we change this to "while (!kthread_should_stop())" to make me
completely happy?
Thanks!
--
Dmitry
next prev parent reply other threads:[~2005-07-25 15:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-22 18:01 [patch 1/2] Touchscreen support for sharp sl-5500 Pavel Machek
2005-07-24 16:47 ` Russell King
2005-07-24 17:01 ` Richard Purdie
2005-07-24 17:07 ` randy_dunlap
2005-07-25 4:56 ` Pavel Machek
2005-07-25 15:16 ` Dmitry Torokhov [this message]
2005-07-25 15:50 ` Russell King
2005-07-25 16:02 ` Dmitry Torokhov
2005-07-25 16:13 ` Russell King
2005-07-25 16:47 ` Dmitry Torokhov
2005-07-25 16:57 ` Russell King
2005-07-25 22:07 ` Pavel Machek
2005-07-25 21:39 ` Pavel Machek
2005-07-25 21:36 ` Pavel Machek
2005-07-25 16:04 ` Russell King
2005-07-25 22:06 ` Pavel Machek
2005-07-25 23:03 ` Russell King
2005-07-26 6:28 ` Pavel Machek
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=d120d500050725081664cd73fe@mail.gmail.com \
--to=dmitry.torokhov@gmail.com \
--cc=dtor_core@ameritech.net \
--cc=lenz@cs.wisc.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@suse.cz \
--cc=rpurdie@rpsys.net \
--cc=vojtech@suse.cz \
/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