From: Janne Grunau <j@jannau.net>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jarod Wilson <jwilson@redhat.com>,
linux-kernel@vger.kernel.org, Jarod Wilson <jarod@redhat.com>,
Christoph Bartelmus <lirc@bartelmus.de>,
Mario Limonciello <superm1@ubuntu.com>,
Janne Grunau <j@jannau.net>
Subject: Re: [PATCH 01/18] lirc core device driver infrastructure
Date: Fri, 12 Sep 2008 02:16:30 +0200 [thread overview]
Message-ID: <200809120216.31153.j@jannau.net> (raw)
In-Reply-To: <20080909130102.GB27837@infradead.org>
On Tuesday 09 September 2008 15:01:02 Christoph Hellwig wrote:
> > +menuconfig INPUT_LIRC
> > + bool "Linux Infrared Remote Control IR receiver/transmitter
> > drivers" + default n
>
> n is the default, no needed add a "default n" line for it.
removed
> > +if INPUT_LIRC
> > +
> > +config LIRC_DEV
> > + tristate "LIRC device loadable module support"
> > + default n
> > + help
> > + LIRC device loadable module support, required for most LIRC
> > drivers
>
> Obviously this can be built in, so it should be named better. Also I
> don't think LIRC means anything to a user, so use Infrared Remote
> Control support or something similar instead.
I'm pretty sure LIRC will be recognized by its current users, it is
probably enough if it is in the help text though.
> > +#define __KERNEL_SYSCALLS__
>
> No need for this in any semi-recent kernel.
already gone
> > +#include <linux/unistd.h>
> > +#include <linux/kthread.h>
> > +
> > +/* SysFS header */
> > +#include <linux/device.h>
>
> That comment is not quite correct, just remove it.
removed
> > +/* helper function
> > + * initializes the irctl structure
> > + */
> > +static inline void init_irctl(struct irctl *ir)
> > +{
> > + memset(&ir->p, 0, sizeof(struct lirc_plugin));
> > + mutex_init(&ir->buffer_lock);
> > + ir->p.minor = NOPLUG;
> > +
> > + ir->task = NULL;
> > + ir->jiffies_to_wait = 0;
> > +
> > + ir->open = 0;
> > + ir->attached = 0;
> > +}
>
> Please don't mark funtion inline unless there's a very good reason
> for it.
all inlines (65 in drivers/inpu/lirc) removed
> > +static void cleanup(struct irctl *ir)
> > +{
> > + dprintk(LOGHEAD "cleaning up\n", ir->p.name, ir->p.minor);
> > +
> > + device_destroy(lirc_class, MKDEV(IRCTL_DEV_MAJOR, ir->p.minor));
> > +
> > + if (ir->buf != ir->p.rbuf) {
> > + lirc_buffer_free(ir->buf);
> > + kfree(ir->buf);
> > + }
> > + ir->buf = NULL;
> > +
> > + init_irctl(ir);
> > +}
>
> What's the init doing in a cleanup routine? Oh, you initialize it
> again becaus of the static array. I think the right approach is to
> dynamically allocate struct irctl.
agree, it's done dynamically now
> > +{
> > + if (lirc_buffer_full(ir->buf)) {
> > + dprintk(LOGHEAD "buffer overflow\n",
> > + ir->p.name, ir->p.minor);
> > + return -EOVERFLOW;
> > + }
> > +
> > + if (ir->p.add_to_buf) {
> > + int res = -ENODATA;
> > + int got_data = 0;
> > +
> > + /* service the device as long as it is returning
> > + * data and we have space
> > + */
> > + while (!lirc_buffer_full(ir->buf)) {
> > + res = ir->p.add_to_buf(ir->p.data, ir->buf);
> > + if (res == SUCCESS)
> > + got_data++;
> > + else
> > + break;
> > + }
> > +
> > + if (res == -ENODEV)
> > + kthread_stop(ir->task);
> > +
> > + return got_data ? SUCCESS : res;
> > + }
> > +
> > + return SUCCESS;
>
> I guess success is a #define for 0? Just user 0 directly.
yes, already removed. also removed custom TRUE/FALSE defines
> Also the
> kthread_stop here looks odd. The normal way to use kthreads is to
> start them when bringing up an interface of some sorts, and call
> kthread_stop when the interface is brought down. Doing it in a
> routine like this screams "unclear lifetime rules".
>
> > + } else {
> > + /* if device not opened so we can sleep half a second */
> > + set_current_state(TASK_INTERRUPTIBLE);
> > + schedule_timeout(HZ/2);
> > + }
>
> Yikes. This should use some form of more fine-grained wakeus.
added a waitqueue and wait_event
> > + struct irctl *ir;
> > + int minor;
> > + int bytes_in_key;
> > + int err;
> > + DECLARE_COMPLETION(tn);
> > +
> > + if (!p) {
> > + printk(KERN_ERR "lirc_dev: lirc_register_plugin: "
> > + "plugin pointer must be not NULL!\n");
> > + err = -EBADRQC;
> > + goto out;
> > + }
>
> No need for this, a null pointer derference should be a clear enough
> warning for the writer of the broken pluging..
ok
> > +int lirc_unregister_plugin(int minor)
>
> Why doesn't this one take a struct lirc_plugin pointer?
I don't know, It doesn't really help though since the struct lirc_plugin
is copied by value to irctl.p in lirc_register_plugin.
> > +{
> > + struct irctl *ir;
> > + DECLARE_COMPLETION(tn);
> > + DECLARE_COMPLETION(tn2);
>
> both completion seems unused.
the one in lirc_register_plugin too, removed
> > + /* end up polling thread */
> > + if (ir->task) {
> > + wake_up_process(ir->task);
> > + kthread_stop(ir->task);
> > + }
>
> kthread_stop already wakes the thread up.
removed
> > +/*
> > + * Recent kernels should handle this autmatically by
> > increasing/decreasing + * use count when a dependant module is
> > loaded/unloaded.
> > + */
> > +
> > + return SUCCESS;
>
> The comment above looks superflous.
already removed.
> > +static int irctl_open(struct inode *inode, struct file *file)
> > +{
> > + struct irctl *ir;
> > + int retval;
> > +
> > + if (MINOR(inode->i_rdev) >= MAX_IRCTL_DEVICES) {
>
> iminor.
replaced in all occurances
> > + /* if the plugin has an open function use it instead */
> > + if (ir->p.fops && ir->p.fops->open)
> > + return ir->p.fops->open(inode, file);
>
> in which case this 'plugin' should just install it's own fops.
> Thanks to cdev_add we can install fops at minor number granularity.
done
> > +static unsigned int irctl_poll(struct file *file, poll_table
> > *wait) +{
> > + struct irctl *ir =
> > &irctls[MINOR(file->f_dentry->d_inode->i_rdev)]; + unsigned int
> > ret;
> > +
> > + dprintk(LOGHEAD "poll called\n", ir->p.name, ir->p.minor);
> > +
> > + /* if the plugin has a poll function use it instead */
> > + if (ir->p.fops && ir->p.fops->poll)
> > + return ir->p.fops->poll(file, wait);
> > +
> > + mutex_lock(&ir->buffer_lock);
>
> ->poll ust not sleep.
I don't see why poll has to hold the lock, removed
> > +/* #define LIRC_BUFF_POWER_OF_2 */
> > +#ifdef LIRC_BUFF_POWER_OF_2
> > +#define mod(n, div) ((n) & ((div) - 1))
> > +#else
> > +#define mod(n, div) ((n) % (div))
> > +#endif
removed
> > +static inline void _lirc_buffer_clear(struct lirc_buffer *buf)
> > +{
> > + buf->head = 0;
> > + buf->tail = 0;
> > + buf->fill = 0;
> > +}
> > +static inline int lirc_buffer_init(struct lirc_buffer *buf,
> > + unsigned int chunk_size,
> > + unsigned int size)
> > +{
> > + /* Adjusting size to the next power of 2 would allow for
> > + * inconditional LIRC_BUFF_POWER_OF_2 optimization */
> > + init_waitqueue_head(&buf->wait_poll);
> > + spin_lock_init(&buf->lock);
> > + _lirc_buffer_clear(buf);
> > + buf->chunk_size = chunk_size;
> > + buf->size = size;
> > + buf->data = kmalloc(size*chunk_size, GFP_KERNEL);
> > + if (buf->data == NULL)
> > + return -1;
> > + memset(buf->data, 0, size*chunk_size);
> > + return 0;
> > +}
> > +static inline void lirc_buffer_free(struct lirc_buffer *buf)
> > +{
> > + kfree(buf->data);
> > + buf->data = NULL;
> > + buf->head = 0;
> > + buf->tail = 0;
> > + buf->fill = 0;
> > + buf->chunk_size = 0;
> > + buf->size = 0;
> > +}
>
> Please move these out of line. And please document all the
> functions. Or switch to a kfifo or the existing tty buffering
> helpers.
I'll look at it.
> > +static inline void lirc_buffer_lock(struct lirc_buffer *buf,
> > + unsigned long *flags)
> > +{
> > + spin_lock_irqsave(&buf->lock, *flags);
> > +}
> > +static inline void lirc_buffer_unlock(struct lirc_buffer *buf,
> > + unsigned long *flags)
> > +{
> > + spin_unlock_irqrestore(&buf->lock, *flags);
> > +}
>
> Please don't do you own spinlock wrappers.
removed
Thanks for the review.
Janne
next prev parent reply other threads:[~2008-09-12 0:17 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-09 4:05 [PATCH 0/18] linux infrared remote control drivers Jarod Wilson
2008-09-09 4:05 ` [PATCH 01/18] lirc core device driver infrastructure Jarod Wilson
2008-09-09 4:05 ` [PATCH 02/18] lirc serial port receiver/transmitter device driver Jarod Wilson
2008-09-09 4:05 ` [PATCH 03/18] lirc driver for 1st-gen Media Center Ed. USB IR transceivers Jarod Wilson
2008-09-09 4:05 ` [PATCH 04/18] lirc driver for 2nd-gen and later " Jarod Wilson
2008-09-09 4:05 ` [PATCH 05/18] lirc driver for i2c-based IR receivers Jarod Wilson
2008-09-09 4:05 ` [PATCH 06/18] lirc driver for the ATI USB RF remote receiver Jarod Wilson
2008-09-09 4:05 ` [PATCH 07/18] lirc driver for the CommandIR USB Transceiver Jarod Wilson
2008-09-09 4:05 ` [PATCH 08/18] lirc driver for the Soundgraph IMON IR Receivers Jarod Wilson
2008-09-09 4:05 ` [PATCH 09/18] lirc driver for the Streamzap PC Receiver Jarod Wilson
2008-09-09 4:05 ` [PATCH 10/18] lirc driver for Igor Cesko's USB IR receiver Jarod Wilson
2008-09-09 4:05 ` [PATCH 11/18] lirc driver for the Technotrend " Jarod Wilson
2008-09-09 4:05 ` [PATCH 12/18] lirc driver for the Sasem OnAir and Dign HV5 receivers Jarod Wilson
2008-09-09 4:05 ` [PATCH 13/18] lirc driver for ITE8709 CIR port receiver Jarod Wilson
2008-09-09 4:05 ` [PATCH 14/18] lirc driver for the ITE IT87xx CIR Port receivers Jarod Wilson
2008-09-09 4:06 ` [PATCH 15/18] lirc driver for the SIR IrDA port Jarod Wilson
2008-09-09 4:06 ` [PATCH 16/18] lirc driver for the IR interface on BT829-based hardware Jarod Wilson
2008-09-09 4:06 ` [PATCH 17/18] lirc driver for homebrew parallel port receivers Jarod Wilson
2008-09-09 4:06 ` [PATCH 18/18] lirc driver for the zilog/haupauge IR transceiver Jarod Wilson
2008-09-09 4:06 ` Jarod Wilson
2008-09-11 15:22 ` [PATCH 09/18] lirc driver for the Streamzap PC Receiver Jonathan Corbet
2008-09-10 21:02 ` [PATCH 08/18] lirc driver for the Soundgraph IMON IR Receivers Jonathan Corbet
2008-09-10 21:23 ` Janne Grunau
2008-09-11 3:22 ` Jarod Wilson
2008-09-22 21:47 ` Jarod Wilson
2008-09-24 20:21 ` Jarod Wilson
2008-09-10 17:09 ` [PATCH 07/18] lirc driver for the CommandIR USB Transceiver Jonathan Corbet
2008-09-11 18:24 ` Christoph Bartelmus
[not found] ` <1221159005.13683.34.camel@minimatt>
2008-09-11 19:03 ` Jarod Wilson
2008-09-11 19:14 ` Janne Grunau
2008-09-25 15:21 ` Jarod Wilson
2008-09-10 9:58 ` [PATCH 06/18] lirc driver for the ATI USB RF remote receiver Ville Syrjälä
2008-09-10 13:05 ` Jarod Wilson
2008-09-10 13:14 ` Christoph Hellwig
2008-09-10 13:37 ` Jon Smirl
2008-09-10 14:30 ` Dmitry Torokhov
2008-09-10 13:44 ` Janne Grunau
2008-09-10 14:13 ` Jarod Wilson
2008-09-10 14:19 ` Christoph Hellwig
2008-09-10 14:08 ` Ville Syrjälä
2008-09-10 14:37 ` Dmitry Torokhov
2008-09-09 4:13 ` [PATCH 05/18] lirc driver for i2c-based IR receivers Jarod Wilson
2008-09-10 15:42 ` Jonathan Corbet
2008-09-09 23:30 ` [PATCH 04/18] lirc driver for 2nd-gen and later Media Center Ed. USB IR transceivers Jonathan Corbet
2008-09-10 0:36 ` Janne Grunau
2008-09-11 9:21 ` Adrian Bunk
2008-09-09 19:21 ` [PATCH 03/18] lirc driver for 1st-gen " Jonathan Corbet
2008-09-09 23:59 ` Janne Grunau
2008-09-10 1:39 ` Jarod Wilson
2008-09-10 0:04 ` Janne Grunau
2008-09-09 16:14 ` [PATCH 02/18] lirc serial port receiver/transmitter device driver Jonathan Corbet
2008-09-09 19:51 ` Stefan Lippers-Hollmann
2008-09-09 19:56 ` Jarod Wilson
2008-09-10 17:40 ` Jarod Wilson
2008-09-09 7:40 ` [PATCH 01/18] lirc core device driver infrastructure Sebastian Siewior
2008-09-09 9:53 ` Janne Grunau
2008-09-09 12:33 ` Sebastian Siewior
2008-09-09 13:10 ` Janne Grunau
2008-09-11 16:41 ` Christoph Bartelmus
2008-09-09 11:13 ` Alan Cox
2008-09-09 13:27 ` Stefan Richter
2008-09-09 17:03 ` Jarod Wilson
2008-09-11 18:30 ` Christoph Bartelmus
2008-09-11 19:09 ` Jarod Wilson
2008-09-13 7:21 ` Christoph Bartelmus
2008-09-09 9:46 ` Andi Kleen
2008-09-09 11:35 ` Janne Grunau
2008-09-09 13:03 ` Andi Kleen
2008-09-09 13:20 ` Janne Grunau
2008-09-12 16:46 ` Greg KH
2008-09-09 13:01 ` Christoph Hellwig
2008-09-10 12:24 ` Janne Grunau
2008-09-10 12:29 ` Christoph Hellwig
2008-09-10 12:45 ` Janne Grunau
2008-09-11 18:03 ` Christoph Bartelmus
2008-09-11 19:18 ` Janne Grunau
2008-09-12 0:16 ` Janne Grunau [this message]
2008-09-12 8:33 ` Christoph Hellwig
2008-09-12 14:51 ` Jarod Wilson
2008-09-09 15:33 ` Jonathan Corbet
2008-09-12 0:12 ` Janne Grunau
2008-09-10 13:08 ` Dmitry Torokhov
2008-09-11 8:47 ` Gerd Hoffmann
2008-09-11 21:28 ` Maxim Levitsky
2008-09-13 7:20 ` Christoph Bartelmus
2008-09-12 4:44 ` Dmitry Torokhov
2008-09-09 4:36 ` [PATCH 0/18] linux infrared remote control drivers Chris Wedgwood
2008-09-09 7:06 ` Alexey Dobriyan
2008-09-09 8:32 ` Janne Grunau
2008-09-09 12:46 ` Christoph Hellwig
2008-09-09 15:23 ` Jarod Wilson
2008-09-09 18:27 ` Lennart Sorensen
2008-09-09 18:34 ` Jarod Wilson
2008-09-09 15:34 ` Jon Smirl
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=200809120216.31153.j@jannau.net \
--to=j@jannau.net \
--cc=hch@infradead.org \
--cc=jarod@redhat.com \
--cc=jwilson@redhat.com \
--cc=linux-kernel@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
Powered by JetHome