+
+#ifndef __KERNEL__
+#define __KERNEL__
+#endif
uhhhhhhh
that's not needed.. if it's ever needed you have a very serious bug+
+/* IRQ handler notifies this wait queue on receipt of an IRQ */
+DECLARE_WAIT_QUEUE_HEAD(ar1520_IRQ_wq);
you really ought to just be using threaded interrupts
+static struct class *ar1520_class;
this makes me nervous to be honest.... drivers shouldn't be mucking with
classes
+ PPDEBUG(AR1520_DBG_INFO,
what is this PPDEBUG thing ?
I'm sure you're aware of our coding guidelines at
http://wiki.meego.com/images/Kernel_criteria.pdf
where criteria 2.6 is clear I hope...
the linux kernel has all kinds of debug print macros like this, and
you're not using them, which breaks
automated faulted collection tools.
+static int set_rts_flag(struct ar1520_data *data, int new_val)
+{
+ int ret;
+
+ PPDEBUG(AR1520_DBG_INFO, "set_rts_flag(%d)\n", new_val);
+ ret = mutex_lock_interruptible(&data->rts_flag_mutex);
+ if (ret == 0) {
+ data->rts_flag = new_val;
+ mutex_unlock(&data->rts_flag_mutex);
+ }
+ return ret;
+}
this construct really bothers me.
this is a "set yourself up for shooting you in the foot" function; you
ask it to set a flag, but it randomly does that or not, depending on if
you happen to hit lock contention or not.
maybe rename the function to set_rts_flag_sometimes() ?????
+
+static irqreturn_t gpsrts_irq_handler(int irq, void *devid)
+{
+ struct ar1520_data *data = devid;
+ PPDEBUG(AR1520_DBG_INFO, "%s start\n", __func__);
+ if (data->rts_irq_handling == IRQ_AND_POLL_RTS)
+ set_rts_flag(data, 1);
ehh didn't set_rts_flag_sometimes() use a mutex? You can't use mutexes
from interrupt handlers!
_______________________________________________
MeeGo-kernel mailing list
[email protected]
http://lists.meego.com/listinfo/meego-kernel
