mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Jarod Wilson <jwilson@redhat.com>
Cc: linux-kernel@vger.kernel.org, Jarod Wilson <jarod@redhat.com>,
	Janne Grunau <j@jannau.net>,
	Christoph Bartelmus <lirc@bartelmus.de>,
	Mario Limonciello <superm1@ubuntu.com>
Subject: Re: [PATCH 01/18] lirc core device driver infrastructure
Date: Tue, 9 Sep 2008 09:01:02 -0400	[thread overview]
Message-ID: <20080909130102.GB27837@infradead.org> (raw)
In-Reply-To: <1220933164-10160-2-git-send-email-jwilson@redhat.com>

> +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.

Anyone configuring the kernel should know he's on Linux, so strike the
Linux away :)

> +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 don't quite understand why this needs a different option from
INPUT_LIRC.

> +#define __KERNEL_SYSCALLS__

No need for this in any semi-recent kernel.

> +#include <linux/unistd.h>
> +#include <linux/kthread.h>
> +
> +/* SysFS header */
> +#include <linux/device.h>

That comment is not quite correct, just remove it.

> +/*  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.

> +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.

> +static inline int add_to_buf(struct irctl *ir)

The inline thing also applies here and in various other placez.

> +{
> +	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.  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".

> +	do {
> +		if (ir->open) {
> +			if (ir->jiffies_to_wait) {
> +				set_current_state(TASK_INTERRUPTIBLE);
> +				schedule_timeout(ir->jiffies_to_wait);
> +			} else {
> +				interruptible_sleep_on(
> +					ir->p.get_queue(ir->p.data));
> +			}

No sleep on, please.  But this one should be trivial to fix anyway, by
just changing this to a

	set_current_state(TASK_INTERRUPTIBLE);
	schedule();

and using wake_up_process in the wakeup path.

> +		} 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.

> +int lirc_register_plugin(struct lirc_plugin *p)
> +{

Please add a kerneldoc comments for exported functions like this,
instead of the comments in the header.

> +	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..

> +int lirc_unregister_plugin(int minor)

Why doesn't this one take a struct lirc_plugin pointer?

> +{
> +	struct irctl *ir;
> +	DECLARE_COMPLETION(tn);
> +	DECLARE_COMPLETION(tn2);

both completion seems unused.

> +	/* end up polling thread */
> +	if (ir->task) {
> +		wake_up_process(ir->task);
> +		kthread_stop(ir->task);
> +	}

kthread_stop already wakes the thread up. 

> +/*
> + * 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.

> +static int irctl_open(struct inode *inode, struct file *file)
> +{
> +	struct irctl *ir;
> +	int retval;
> +
> +	if (MINOR(inode->i_rdev) >= MAX_IRCTL_DEVICES) {

iminor.

> +	/* 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.

> +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.

> +/*
> + *
> + */

???

> +
> +void *lirc_get_pdata(struct file *file)
> +{
> +	void *data = NULL;
> +
> +	if (file && file->f_dentry && file->f_dentry->d_inode &&
> +	    file->f_dentry->d_inode->i_rdev) {
> +		struct irctl *ir;
> +		ir = &irctls[MINOR(file->f_dentry->d_inode->i_rdev)];
> +		data = ir->p.data;
> +	}
> +
> +	return data;
> +}
> +EXPORT_SYMBOL(lirc_get_pdata);

Yikes. All these should never really be null.  But once you have a
struct file you should just use file->private_data.


> +/* #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

??

> +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.

> +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.


  parent reply	other threads:[~2008-09-09 14:25 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 [this message]
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
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=20080909130102.GB27837@infradead.org \
    --to=hch@infradead.org \
    --cc=j@jannau.net \
    --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

all inboxes | Powered by JetHome®