Re: [PATCH] support for Cobalt Networks (x86 only) systems (for real this time)

[Tim Hockin <thockin@hockin.org>]

> 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