> Looks interesting. Seemingly literate use of spinlocks.
thanks - I gave it lots of thought.
> Off-hand I see old style initialization. Is it right for new driver?
the old-style init is because it is an old driver. I want to do a full-on
rework, but haven't had the time.
> i2c framework is not used, I wonder why. Someone thought that
> it was too heavy perhaps? If so, I disagree.
i2c is only in our stuff because the i2c core is not in the standard kernel
yet. As soon as it is, I will make cobalt_i2c* go away.
> if any alignment with lm-sensors is possible, for the sake of
yes - I have communicated with the lm-sensors crew. It is very high on my
wishlist.
> lcd_read bounces reads with -EINVAL when another read is in
> progress. Gross.
as I said - I didn't write the LCD driver, I just had to port it up :) I
want to re-do the whole paradigm of it (it has been ported forward since
2.0.3x)
> 1.:
> p = head;
> while (p) {
> p = p->next;
> }
>
> It is what for(;;) does.
I don't get it - are you saying you do or don't like the while (p)
approach? I think it is clearer because it is more true ot the heuristic -
"start at the beginning and walk down the list".
> 2. Spaces and tabs are mixed in funny ways, makes to cute effects
> when quoting diffs.
I've tried to eliminate that when I see it - I'll give the diff a close
examination.
thanks for the feedback - it will be nice to not have to constantly port
all our changes to each kernel release. There are still some patches (of
course) but I didn't submit them because they are VERY specific to cobalt -
for example in the ide probing calling cobalt_ruler_register(). Ifdefs
protect, but the overall appearance would be rejected, I suspect - no?
Tim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
