On Tue, Jul 01, 2008 at 04:05:17PM +0300, Adrian Bunk wrote:
On Tue, Jul 01, 2008 at 08:46:54AM -0400, Dmitry Torokhov wrote:
On Tue, Jul 01, 2008 at 01:55:25PM +0200, Geert Uytterhoeven wrote:
commit 656acd2bbc4ce7f224de499ee255698701396c48
Author: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
Date: Thu Jun 26 11:30:02 2008 -0400
Input: fix locking in force-feedback core
The newly added event_lock spinlock in the input core disallows sleeping
and therefore using mutexes in event handlers. Convert force-feedback
core to rely on event_lock instead of mutex to protect slots allocated
for fore-feedback effects. The original mutex is still used to serialize
uploading and erasing of effects.
causes the following regression on m68k:
| linux/drivers/input/ff-core.c: In function 'input_ff_upload':
| linux/drivers/input/ff-core.c:172: error: dereferencing pointer to incomplete type
| linux/drivers/input/ff-core.c: In function 'erase_effect':
| linux/drivers/input/ff-core.c:197: error: dereferencing pointer to incomplete type
| linux/drivers/input/ff-core.c:204: error: dereferencing pointer to incomplete type
| make[4]: *** [drivers/input/ff-core.o] Error 1
Argh! Sorry about it.
As the incomplete type is `struct task_struct', including <linux/sched.h> fixes
it.
Not linux/spinlock.h? I wonder if I need to include linux/spinlock.h and
linux/mutex.h directly from linux/input.h... What is the current
policy on headers - do they need to include everything to be
functional or it is responsibility of the user?
Theoretically it's the responsibility of the header to include
everything it needs.
In practice we are after -rc8 and even thinking of this kind of #include
changes under include/linux/ makes me nervous - like the fact that the
ff-core.c problem occured _only_ on m68k our headers are too fragile for
expecting such changes to simply work.
Can we go with Geert's patch for 2.6.26 and if you want to fix it
properly you can send a patch for 2.6.27?
No, no, I am totally fine with Geert's fix, I am talking about later of
course.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
