Remove some stuff from lirc_dev.h which is not used anywhere.
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Every caller of lirc_register_driver() passes their own fops and there
are no users of lirc_dev_fop_write() in the kernel tree. Thus we can
make fops mandatory and remove lirc_dev_fop_write().
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
There are no drivers which use this functionality.
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Since there are no users of this functionality, it can be removed
altogether.
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The kernel-doc script is now broken if it doesn't find all
exported symbols documented.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The struct lirc_driver is already documented, but on some
internal format. Convert it to Kernel doc-nano format and
add documentation for some additional parameters that are
also present at the structure.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
We can use kfifo_initialized() to check if the fifo in lirc_buffer is
initialized or not. There's no need to have a dedicated fifo status
variable in lirc_buffer.
[m.chehab@samsung.com: add the same change to lirc_zilog, to avoid
breaking compilation of staging drivers]
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The use case is simple, if any rc device has allowed protocols =
RC_TYPE_LIRC and map_name = RC_MAP_LIRC set, the driver open will be never
called. The reason for this is, all of the key maps except lirc have some
KEYS in there map, so during rc_register_device process these keys are
matched against the input drivers and open is performed, so for the case
of RC_MAP_EMPTY, a vt/keyboard is matched and the driver open is
performed.
In case of lirc, there is no match and result is that there is no open
performed, however the lirc-dev will go ahead and create a /dev/lirc0
node. Now when lircd/mode2 opens this device, no data is available
because the driver was never opened.
Other case pointed by Sean Young, As rc device gets opened via the
input interface. If the input device is never opened (e.g. embedded with
no console) then the rc open is never called and lirc will not work
either. So that's another case.
lirc_dev seems to have no link with actual rc device w.r.t open/close.
This patch adds rc_dev pointer to lirc_driver structure for cases like
this, so that it can do the open/close of the real driver in accordance
to lircd/mode2 open/close.
Without this patch its impossible to open a rc device which has
RC_TYPE_LIRC ad RC_MAP_LIRC set.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Store the cdev pointer in struct irctl, allocated dynamically as needed,
rather than having a static array. At the same time, recycle some of the
saved memory to nudge the maximum number of lirc devices supported up a
ways -- its not that uncommon these days, now that we have the rc-core
lirc bridge driver, to see a system with at least 4 raw IR receivers.
(consider a mythtv backend with several video capture devices and the
possible need for IR transmit hardware).
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro 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: Joris van Rantwijk <jorispubl@xs4all.nl>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
struct file_operations was made const in the drivers, but not in struct
lirc_driver:
drivers/staging/lirc/lirc_it87.c:365: warning: initialization discards qualifiers from pointer target type
drivers/staging/lirc/lirc_parallel.c:571: warning: initialization discards qualifiers from pointer target type
drivers/staging/lirc/lirc_serial.c:1073: warning: initialization discards qualifiers from pointer target type
drivers/staging/lirc/lirc_sir.c:482: warning: initialization discards qualifiers from pointer target type
drivers/staging/lirc/lirc_zilog.c:1284: warning: assignment discards qualifiers from pointer target type
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro 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: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
