Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

As pointed out (and tested) by Joris van Rantwijk, we do actually need
to wire up .compat_ioctl for 32-bit lirc userspace to work with 64-bit
lirc kernelspace. Do it. And add a check to make sure we get a valid
irctl in the ioctl handler.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

>From Joris van Rantwijk <jorispubl@xs4all.nl>:

	I tested lirc_serial and found that it works fine.
	Except the LIRC ioctls do not work in my 64-bit-kernel/32-bit-user
	setup. I added compat_ioctl entries in the drivers to fix this.

	While doing so, I noticed inconsistencies in the argument type of
	the LIRC ioctls. All ioctls are declared in lirc.h as having argument
	type __u32, however there are a few places where the driver calls
	get_user/put_user with an unsigned long argument.

	The patch below changes lirc_dev and lirc_serial to use __u32 for all
	ioctl arguments, and adds compat_ioctl entries.
	It should probably also be done in the other low-level drivers,
	but I don't have hardware to test those.

I've dropped the .compat_ioctl addition from Joris' original patch,
as I swear the non-compat definition should now work for both 32-bit
and 64-bit userspace. Technically, I think we still need/want a
in getting a reply to you).
Reported-by: NJoris van Rantwijk <jorispubl@xs4all.nl>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Prompted by Red Hat bugzilla #633023
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The lirc userspace needs all the current ioctls defined, and we need to
put the header files in places out-of-tree and/or staging lirc drivers
(which I plan to prep soon) can easily build with. I've actually tested this
in a tree w/all the lirc drivers queued up to be submitted for staging. I'm
also reasonably sure that Andy Walls is going to need most of the ioctls
anyway for his cx23888 IR driver work.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

New code should not rely on the big kernel lock,
so use the unlocked_ioctl file operation in lirc.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Tested-by: NJarod Wilson <jarod@redhat.com>
Acked-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

On Wed, Jul 07, 2010 at 02:52:58PM +0200, Jiri Slaby wrote:
> Hi,
>
> stanse found a locking error in lirc_dev_fop_read:
> if (mutex_lock_interruptible(&ir->irctl_lock))
>   return -ERESTARTSYS;
> ...
> while (written < length && ret == 0) {
>   if (mutex_lock_interruptible(&ir->irctl_lock)) {    #1
>     ret = -ERESTARTSYS;
>     break;
>   }
>   ...
> }
>
> remove_wait_queue(&ir->buf->wait_poll, &wait);
> set_current_state(TASK_RUNNING);
> mutex_unlock(&ir->irctl_lock);                        #2
>
> If lock at #1 fails, it beaks out of the loop, with the lock unlocked,
> but there is another "unlock" at #2.

This should do the trick. Completely untested beyond compiling, but its
not exactly a complicated fix, and in practice, I'm not aware of anyone
ever actually tripping that locking bug, so there's zero functional change
in typical use here.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

v2: currently unused ioctls are included, but #if 0'd out
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>