From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Jarod Wilson <jarod@redhat.com>
Cc: linux-kernel@vger.kernel.org,
Mario Limonciello <superm1@ubuntu.com>,
linux-input@vger.kernel.org, linux-media@vger.kernel.org,
Janne Grunau <j@jannau.net>,
Christoph Bartelmus <lirc@bartelmus.de>
Subject: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Date: Mon, 23 Nov 2009 09:47:43 -0200 [thread overview]
Message-ID: <4B0A765F.7010204@redhat.com> (raw)
In-Reply-To: <200910200958.50574.jarod@redhat.com>
Hi Jarod,
Jarod Wilson wrote:
> Core Linux Infrared Remote Control driver and infrastructure
>
> -Add Kconfig and Makefile bits
> -Add device driver interface and headers
>
> The initial Kconfig and Makefile bits were done by Mario Limonciello for
> the Ubuntu kernel, but have been tweaked a bit since then. Any errors are
> probably my doing.
>
> Changes from prior submission:
> - Now uses dev_dbg instead of its own dprintk
> - Dynamic device numbers used
> - sleep_on() ripped out in favor of wake bits
> - Kconfig text improved and simplified
> - All inline keywords removed where possible
> - Obfuscating #defines and wrapper functions removed
> - We call 'em lirc drivers now instead of lirc plugins
Sorry to not analyze the code before. -ETOOBUSY here...
Some generic comments first:
1) As I said before, this code adds a new input API. So, you should
get input people's ack about it. It seems fine for me;
2) It would be really cool if you could submit a patch for DocBook as
well, in order to describe the API. IMO, the better is to put it together
with media infrastructure docbook, since, although it is possible to use
lirc code with other hardware (and were originally designed for it), the
current wider usage is together with V4L/DVB devices. The Docbooks are
at kernel Documentation/DocBook/ directory. Also, we have a copy of it
at our development tree (http://linuxtv.org/hg/v4l-dvb) at media-specs/
directory.
3) In general, the code looks sane for me. I have just a few small sugestions
for improvements:
> Index: b/drivers/input/lirc/lirc.h
> ===================================================================
> --- /dev/null
> +++ b/drivers/input/lirc/lirc.h
Hmm... as you're defining the kernel userspace interface, it would
be better to put the header under include/linux.
> +#define LIRC_GET_FEATURES _IOR('i', 0x00000000, unsigned long)
> +
> +#define LIRC_GET_SEND_MODE _IOR('i', 0x00000001, unsigned long)
> +#define LIRC_GET_REC_MODE _IOR('i', 0x00000002, unsigned long)
> +#define LIRC_GET_SEND_CARRIER _IOR('i', 0x00000003, unsigned int)
> +#define LIRC_GET_REC_CARRIER _IOR('i', 0x00000004, unsigned int)
> +#define LIRC_GET_SEND_DUTY_CYCLE _IOR('i', 0x00000005, unsigned int)
> +#define LIRC_GET_REC_DUTY_CYCLE _IOR('i', 0x00000006, unsigned int)
> +#define LIRC_GET_REC_RESOLUTION _IOR('i', 0x00000007, unsigned int)
> +
> +/* code length in bits, currently only for LIRC_MODE_LIRCCODE */
> +#define LIRC_GET_LENGTH _IOR('i', 0x0000000f, unsigned long)
> +
> +#define LIRC_SET_SEND_MODE _IOW('i', 0x00000011, unsigned long)
> +#define LIRC_SET_REC_MODE _IOW('i', 0x00000012, unsigned long)
> +/* Note: these can reset the according pulse_width */
> +#define LIRC_SET_SEND_CARRIER _IOW('i', 0x00000013, unsigned int)
> +#define LIRC_SET_REC_CARRIER _IOW('i', 0x00000014, unsigned int)
> +#define LIRC_SET_SEND_DUTY_CYCLE _IOW('i', 0x00000015, unsigned int)
> +#define LIRC_SET_REC_DUTY_CYCLE _IOW('i', 0x00000016, unsigned int)
> +#define LIRC_SET_TRANSMITTER_MASK _IOW('i', 0x00000017, unsigned int)
> +
Hmm... unsigned int/unsigned long are not portable between different architectures.
It would be better to use instead __u16/__u32/__u64. This way, you won't need
a 32 bits compat layer.
> +
> +int lirc_register_driver(struct lirc_driver *d)
> +{
> + struct irctl *ir;
> + int minor;
> + int bytes_in_key;
> + unsigned int chunk_size;
> + unsigned int buffer_size;
> + int err;
> +
> + if (!d) {
> + printk(KERN_ERR "lirc_dev: lirc_register_driver: "
> + "driver pointer must be not NULL!\n");
> + err = -EBADRQC;
> + goto out;
> + }
> +
> + if (MAX_IRCTL_DEVICES <= d->minor) {
> + dev_err(d->dev, "lirc_dev: lirc_register_driver: "
> + "\"minor\" must be between 0 and %d (%d)!\n",
> + MAX_IRCTL_DEVICES-1, d->minor);
> + err = -EBADRQC;
> + goto out;
> + }
> +
> + if (1 > d->code_length || (BUFLEN * 8) < d->code_length) {
> + dev_err(d->dev, "lirc_dev: lirc_register_driver: "
> + "code length in bits for minor (%d) "
> + "must be less than %d!\n",
> + d->minor, BUFLEN * 8);
> + err = -EBADRQC;
> + goto out;
> + }
> +
> + dev_dbg(d->dev, "lirc_dev: lirc_register_driver: sample_rate: %d\n",
> + d->sample_rate);
> + if (d->sample_rate) {
> + if (2 > d->sample_rate || HZ < d->sample_rate) {
> + dev_err(d->dev, "lirc_dev: lirc_register_driver: "
> + "sample_rate must be between 2 and %d!\n", HZ);
> + err = -EBADRQC;
> + goto out;
> + }
> + if (!d->add_to_buf) {
> + dev_err(d->dev, "lirc_dev: lirc_register_driver: "
> + "add_to_buf cannot be NULL when "
> + "sample_rate is set\n");
> + err = -EBADRQC;
> + goto out;
> + }
> + } else if (!(d->fops && d->fops->read) && !d->rbuf) {
> + dev_err(d->dev, "lirc_dev: lirc_register_driver: "
> + "fops->read and rbuf cannot all be NULL!\n");
> + err = -EBADRQC;
> + goto out;
> + } else if (!d->rbuf) {
> + if (!(d->fops && d->fops->read && d->fops->poll &&
> + d->fops->ioctl)) {
> + dev_err(d->dev, "lirc_dev: lirc_register_driver: "
> + "neither read, poll nor ioctl can be NULL!\n");
> + err = -EBADRQC;
> + goto out;
> + }
> + }
> +
> + mutex_lock(&lirc_dev_lock);
> +
> + minor = d->minor;
> +
> + if (minor < 0) {
> + /* find first free slot for driver */
> + for (minor = 0; minor < MAX_IRCTL_DEVICES; minor++)
> + if (!irctls[minor])
> + break;
> + if (MAX_IRCTL_DEVICES == minor) {
> + dev_err(d->dev, "lirc_dev: lirc_register_driver: "
> + "no free slots for drivers!\n");
> + err = -ENOMEM;
> + goto out_lock;
> + }
> + } else if (irctls[minor]) {
> + dev_err(d->dev, "lirc_dev: lirc_register_driver: "
> + "minor (%d) just registered!\n", minor);
> + err = -EBUSY;
> + goto out_lock;
> + }
> +
> + ir = kzalloc(sizeof(struct irctl), GFP_KERNEL);
> + if (!ir) {
> + err = -ENOMEM;
> + goto out_lock;
> + }
> + init_irctl(ir);
> + irctls[minor] = ir;
> + d->minor = minor;
> +
> + if (d->sample_rate) {
> + ir->jiffies_to_wait = HZ / d->sample_rate;
> + } else {
> + /* it means - wait for external event in task queue */
> + ir->jiffies_to_wait = 0;
> + }
> +
> + /* some safety check 8-) */
> + d->name[sizeof(d->name)-1] = '\0';
> +
> + bytes_in_key = BITS_TO_LONGS(d->code_length) +
> + (d->code_length % 8 ? 1 : 0);
> + buffer_size = d->buffer_size ? d->buffer_size : BUFLEN / bytes_in_key;
> + chunk_size = d->chunk_size ? d->chunk_size : bytes_in_key;
> +
> + if (d->rbuf) {
> + ir->buf = d->rbuf;
> + } else {
> + ir->buf = kmalloc(sizeof(struct lirc_buffer), GFP_KERNEL);
For security reasons, wouldn't be better to use kzalloc here?
> +#ifdef CONFIG_COMPAT
> +#define LIRC_GET_FEATURES_COMPAT32 _IOR('i', 0x00000000, __u32)
> +
> +#define LIRC_GET_SEND_MODE_COMPAT32 _IOR('i', 0x00000001, __u32)
> +#define LIRC_GET_REC_MODE_COMPAT32 _IOR('i', 0x00000002, __u32)
> +
> +#define LIRC_GET_LENGTH_COMPAT32 _IOR('i', 0x0000000f, __u32)
> +
> +#define LIRC_SET_SEND_MODE_COMPAT32 _IOW('i', 0x00000011, __u32)
> +#define LIRC_SET_REC_MODE_COMPAT32 _IOW('i', 0x00000012, __u32)
You wouldn't need those code, if you declare the ioctl's as __u32 at the
first place.
Also, the compat layer is needed not only for x86_64, but some other architectures
like sparc64 needs it, since userspace is 32 bits and kernelspace is 64 bits.
With V4L ioctls, we needed to do some adjustments for sparc, since the sizes there
are different for other types as well. Unfortunately, I can't remember what were
the difference (maybe int size?).
So, IMO, it would be a way better if you just declare everything using __u16/__u32/__u64
at the original ioctl definition and just remove all compat code.
> +EXPORT_SYMBOL(lirc_register_driver);
> +EXPORT_SYMBOL(lirc_unregister_driver);
> +EXPORT_SYMBOL(lirc_dev_fop_close);
> +EXPORT_SYMBOL(lirc_dev_fop_poll);
> +EXPORT_SYMBOL(lirc_dev_fop_ioctl);
> +EXPORT_SYMBOL(lirc_dev_fop_compat_ioctl);
> +EXPORT_SYMBOL(lirc_dev_fop_read);
> +EXPORT_SYMBOL(lirc_get_pdata);
> +EXPORT_SYMBOL(lirc_dev_fop_write);
I would declare everything as EXPORT_SYMBOL_GPL instead.
next prev parent reply other threads:[~2009-11-23 11:47 UTC|newest]
Thread overview: 196+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-20 13:56 [PATCH 0/3 v2] linux infrared remote control drivers Jarod Wilson
2009-10-20 13:58 ` [PATCH 1/3 v2] lirc core device driver infrastructure Jarod Wilson
2009-11-23 11:47 ` Mauro Carvalho Chehab [this message]
2009-11-23 12:36 ` [RFC] Should we create a raw input interface for IR's ? - Was: " Mauro Carvalho Chehab
2009-11-23 14:14 ` Krzysztof Halasa
2009-11-23 15:20 ` Devin Heitmueller
2009-11-23 16:53 ` James Mastros
2009-11-23 20:09 ` Krzysztof Halasa
2009-11-23 17:05 ` James Mastros
2009-11-23 17:12 ` Devin Heitmueller
2009-11-23 17:50 ` Mauro Carvalho Chehab
2009-11-23 20:14 ` Krzysztof Halasa
2009-11-23 16:19 ` Stefan Richter
2009-11-23 17:39 ` Mauro Carvalho Chehab
2009-11-23 20:23 ` Krzysztof Halasa
2009-11-26 12:16 ` Mauro Carvalho Chehab
2009-11-26 18:18 ` Krzysztof Halasa
2009-11-26 19:06 ` Mauro Carvalho Chehab
2009-11-28 2:39 ` Mauro Carvalho Chehab
2009-11-28 2:54 ` Dmitry Torokhov
2009-11-28 9:43 ` Mauro Carvalho Chehab
2009-11-28 10:31 ` Stefan Richter
2009-11-28 10:43 ` Arnd Bergmann
2009-11-23 17:29 ` Mauro Carvalho Chehab
2009-11-23 19:17 ` Jarod Wilson
2009-11-23 20:46 ` Krzysztof Halasa
2009-11-23 21:10 ` Christoph Bartelmus
2009-11-24 4:18 ` Jarod Wilson
2009-11-23 20:41 ` Krzysztof Halasa
2009-11-26 12:36 ` Mauro Carvalho Chehab
2009-11-26 13:22 ` Andy Walls
2009-11-26 18:24 ` Krzysztof Halasa
2009-11-26 19:08 ` Mauro Carvalho Chehab
2009-11-26 20:33 ` Krzysztof Halasa
2009-11-26 21:05 ` Mauro Carvalho Chehab
2009-11-26 21:27 ` Krzysztof Halasa
2009-11-26 22:07 ` Mauro Carvalho Chehab
2009-11-27 0:19 ` Krzysztof Halasa
2009-11-27 0:34 ` Arnd Bergmann
2009-11-26 23:14 ` Dmitry Torokhov
2009-11-26 23:10 ` Dmitry Torokhov
2009-11-26 22:59 ` Trent Piepho
2009-11-27 0:45 ` Krzysztof Halasa
2009-11-27 2:50 ` hermann pitton
2009-11-26 20:37 ` Christoph Bartelmus
2009-11-26 20:59 ` Mauro Carvalho Chehab
2009-11-26 22:05 ` Christoph Bartelmus
2009-11-26 22:14 ` Mauro Carvalho Chehab
2009-11-26 23:09 ` Trent Piepho
2009-11-23 17:37 ` Dmitry Torokhov
2009-11-23 20:51 ` Krzysztof Halasa
2009-11-26 5:21 ` Dmitry Torokhov
2009-11-26 17:46 ` Krzysztof Halasa
2009-11-26 17:50 ` Mauro Carvalho Chehab
2009-11-26 21:39 ` Dmitry Torokhov
2009-11-27 0:13 ` Krzysztof Halasa
2009-11-27 0:26 ` Dmitry Torokhov
2009-11-27 0:37 ` Krzysztof Halasa
2009-11-24 4:37 ` Jarod Wilson
2009-11-24 23:32 ` IR raw input is not sutable for input system Maxim Levitsky
2009-11-25 3:32 ` Trent Piepho
2009-11-25 13:28 ` Maxim Levitsky
2009-11-25 21:32 ` Sean Young
2009-11-25 22:30 ` Krzysztof Halasa
2009-11-25 22:52 ` Maxim Levitsky
2009-11-26 18:36 ` Krzysztof Halasa
2009-11-25 17:18 ` Krzysztof Halasa
2009-11-26 5:41 ` Dmitry Torokhov
2009-11-25 17:12 ` Krzysztof Halasa
2009-11-26 5:38 ` Dmitry Torokhov
2009-11-26 5:31 ` [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure Dmitry Torokhov
2009-11-26 6:16 ` Jarod Wilson
2009-11-26 16:07 ` Mauro Carvalho Chehab
2009-11-26 23:23 ` Dmitry Torokhov
2009-11-27 2:28 ` Jarod Wilson
2009-11-27 3:08 ` Jon Smirl
2009-11-27 4:33 ` Dmitry Torokhov
2009-11-27 5:06 ` Jon Smirl
2009-11-27 7:33 ` Christoph Bartelmus
2009-11-27 15:33 ` Jon Smirl
2009-11-30 5:01 ` Jarod Wilson
2009-11-27 4:30 ` Dmitry Torokhov
2009-11-23 21:11 ` Christoph Bartelmus
2009-11-23 21:46 ` Krzysztof Halasa
2009-11-23 21:54 ` Devin Heitmueller
2009-11-23 22:31 ` Krzysztof Halasa
2009-11-23 22:37 ` Devin Heitmueller
2009-11-23 22:53 ` Krzysztof Halasa
2009-12-12 22:04 ` david
2009-11-24 1:14 ` Andy Walls
2009-11-26 13:25 ` Mauro Carvalho Chehab
2009-11-26 13:48 ` Andy Walls
2009-11-26 16:35 ` Mauro Carvalho Chehab
2009-11-24 0:53 ` Andy Walls
2009-11-24 13:32 ` Jarod Wilson
2009-11-25 16:53 ` Krzysztof Halasa
2009-11-25 17:20 ` Christoph Bartelmus
2009-11-25 17:40 ` Krzysztof Halasa
2009-11-25 18:07 ` Jarod Wilson
2009-11-25 18:20 ` Devin Heitmueller
2009-11-25 18:43 ` [RFC] Should we create a raw input interface for IR's ? Jarod Wilson
2009-11-25 20:49 ` Krzysztof Halasa
2009-11-26 5:53 ` Dmitry Torokhov
2009-11-26 18:40 ` Krzysztof Halasa
2009-11-26 23:28 ` Dmitry Torokhov
2009-11-27 0:28 ` Krzysztof Halasa
2009-11-25 20:47 ` [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure Krzysztof Halasa
2009-11-25 21:58 ` Gerd Hoffmann
2009-11-25 22:31 ` Christoph Bartelmus
2009-11-25 23:22 ` Gerd Hoffmann
2009-11-26 7:28 ` Christoph Bartelmus
2009-11-26 8:39 ` Gerd Hoffmann
2009-11-26 16:41 ` Krzysztof Halasa
2009-11-26 4:26 ` Andy Walls
2009-11-26 14:45 ` Mauro Carvalho Chehab
2009-11-26 15:48 ` Jon Smirl
2009-11-26 16:03 ` Jon Smirl
2009-11-26 23:45 ` Dmitry Torokhov
2009-11-26 3:50 ` Andy Walls
2009-11-25 20:44 ` Krzysztof Halasa
2009-11-26 3:31 ` Andy Walls
2009-11-26 4:00 ` hermann pitton
2009-11-26 5:41 ` Jarod Wilson
2009-11-26 14:28 ` Mauro Carvalho Chehab
2009-11-25 17:44 ` Jarod Wilson
2009-11-25 19:27 ` Krzysztof Halasa
2009-11-26 4:46 ` Jarod Wilson
2009-11-26 8:01 ` Christoph Bartelmus
2009-11-26 8:08 ` Dmitry Torokhov
2009-11-26 16:25 ` Mauro Carvalho Chehab
2009-11-26 18:13 ` Krzysztof Halasa
2009-11-26 18:55 ` Mauro Carvalho Chehab
2009-11-26 20:28 ` Krzysztof Halasa
2009-11-26 21:28 ` Mauro Carvalho Chehab
2009-11-27 7:45 ` Christoph Bartelmus
2009-11-26 13:54 ` Mauro Carvalho Chehab
2009-11-26 17:32 ` Jarod Wilson
2009-11-26 17:49 ` Mauro Carvalho Chehab
2009-11-26 23:50 ` Dmitry Torokhov
2009-11-27 1:45 ` Mauro Carvalho Chehab
2009-11-25 16:45 ` Krzysztof Halasa
2009-11-26 14:05 ` Mauro Carvalho Chehab
2009-11-26 19:43 ` Andy Walls
2009-12-07 18:19 ` Jarod Wilson
2009-12-07 23:02 ` Mauro Carvalho Chehab
2009-12-08 2:42 ` Andy Walls
2009-12-08 4:22 ` Dmitry Torokhov
2009-12-08 11:44 ` Mauro Carvalho Chehab
2009-12-08 14:13 ` Krzysztof Halasa
2009-12-08 14:25 ` Mauro Carvalho Chehab
2009-12-08 17:06 ` Dmitry Torokhov
2009-12-08 12:35 ` Andy Walls
2009-12-08 12:52 ` Jon Smirl
2009-12-08 13:40 ` Mauro Carvalho Chehab
2009-12-08 14:01 ` Jon Smirl
2009-12-08 14:16 ` Mauro Carvalho Chehab
2009-12-08 14:31 ` Jon Smirl
2009-12-08 14:40 ` Mauro Carvalho Chehab
2009-12-08 16:19 ` Jon Smirl
2009-12-08 23:30 ` Krzysztof Halasa
2009-12-09 0:04 ` Mauro Carvalho Chehab
2009-12-08 17:16 ` Dmitry Torokhov
2009-12-08 13:30 ` Mauro Carvalho Chehab
2009-12-08 13:47 ` Jon Smirl
2009-12-08 13:59 ` Mauro Carvalho Chehab
2009-12-08 14:19 ` Jon Smirl
2009-12-08 14:34 ` Mauro Carvalho Chehab
2009-12-08 15:56 ` Jon Smirl
2009-12-08 16:27 ` Mauro Carvalho Chehab
2009-12-08 18:15 ` Jon Smirl
2009-12-09 0:28 ` Mauro Carvalho Chehab
2009-12-08 16:22 ` Ferenc Wagner
2009-12-08 11:32 ` Mauro Carvalho Chehab
2009-12-08 12:46 ` Andy Walls
2009-12-08 17:19 ` Dmitry Torokhov
2009-12-09 0:07 ` Mauro Carvalho Chehab
2009-11-26 5:49 ` Dmitry Torokhov
2009-11-26 6:23 ` Jarod Wilson
2009-11-26 9:14 ` Gerd Hoffmann
2009-11-26 17:15 ` Jarod Wilson
2009-11-26 12:28 ` Andy Walls
2009-11-26 13:17 ` Mauro Carvalho Chehab
2009-11-23 22:25 ` Krzysztof Halasa
2009-11-24 23:23 ` Matthieu CASTET
2009-10-20 14:00 ` [PATCH 2/3 v2] lirc driver for Windows MCE IR transceivers Jarod Wilson
2009-11-13 20:43 ` Stefan Lippers-Hollmann
2009-11-15 6:55 ` Jarod Wilson
2009-11-23 12:46 ` Mauro Carvalho Chehab
2009-10-20 14:00 ` [PATCH 3/3 v2] lirc driver for SoundGraph iMON IR receivers and displays Jarod Wilson
2009-11-23 12:58 ` Mauro Carvalho Chehab
2009-11-24 4:31 ` Jarod Wilson
2009-11-04 22:56 ` [PATCH 0/3 v2] linux infrared remote control drivers Jarod Wilson
2009-11-05 0:07 ` Andy Walls
2009-11-05 3:28 ` Jarod Wilson
2009-11-05 0:31 ` Mauro Carvalho Chehab
2009-11-05 3:41 ` Jarod Wilson
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=4B0A765F.7010204@redhat.com \
--to=mchehab@redhat.com \
--cc=j@jannau.net \
--cc=jarod@redhat.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=lirc@bartelmus.de \
--cc=superm1@ubuntu.com \
/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;
as well as URLs for NNTP newsgroup(s).