support for Cobalt Networks (x86 only) systems (for real this time)
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines
Aattached is a (large, but self contained) patch for Cobalt Networks suport for x86 systems (RaQ3, RaQ4, Qube3, RaQXTR). Please let me know if there is anything that would prevent this from general inclusion in the next release.
Looks interesting. Seemingly literate use of spinlocks.
Off-hand I see old style initialization. Is it right for new driver?
i2c framework is not used, I wonder why. Someone thought that it was too heavy perhaps? If so, I disagree.
Also, I am curious
if any alignment with lm-sensors is possible, for the sake of common userland tools? If we managed that, PSARC would eat their hearts out - they tried to do it since E-250 shipped.
lcd_read bounces reads with -EINVAL when another read is in progress. Gross.
Nitpicking:
1.:
p = head;
while (p) {
p = p->next;
}It is what for(;;) does.
2. Spaces and tabs are mixed in funny ways, makes to cute effects when quoting diffs.
-- Pete
Quoted 1 line
Looks interesting. Seemingly literate use of spinlocks.
thanks - I gave it lots of thought.
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 2 lines
lcd_readbounces reads with-EINVALwhen 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)
Quoted 7 lines
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".
Quoted 2 lines
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
Quoted 4 lines
Quoted 1 line
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.
New-style init by itself shouldn't be hard to do, independent of a full re-work...
Quoted 5 lines
Quoted 2 lines
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.
Why not just run indent over the source before submitting. That will regularize this stuff, and ensure that you are close to Documentation/CodingStyle.
Here is the command I use. The first two options are the only really importants ones...
indent -kr -i8 -npsl -pcs -l100 -lc120
(line length is 100 because line length 72/75/80 winds up wrapping long printk and logic lines when typically the programmer didn't want them to be wrapped)
Signature · 3 lines
Jeff Garzik | Disbelief, that's why you fail. Building 1024 | MandrakeSoft |
Quoted 8 lines
From: Tim Hockin <[email protected]>
Date: Thu, 31 May 2001 23:57:48 -0700 (PDT)Quoted 2 lines
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.
I am puzzled by this comment. Did you look into drivers/i2c/? It certainly is a part of a stock kernel. The main user is the V4L, in drivers/media/video, but I think LM sensors use it too.
-- Pete
Quoted 6 lines · Pete Zaitcev
Quoted 2 lines
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.
I am puzzled by this comment. Did you look into
drivers/i2c/? It certainly is a part of a stock kernel. The main user is the V4L, indrivers/media/video, but I think LM sensors use it too.
sorry, I meant to say: The core is in, but the drivers for the adapters in question are not. They are part of lm_sensors, and as such, make it very hard for us to maintain. I have encouraged the lm_sensors crew to get at LEAST the adapters/algorithms submitted for general inclusion. Once that is in, I will make cobalt_i2c go away.
Tim
Signature · 4 lines
Tim Hockin Systems Software Engineer Sun Microsystems, Cobalt Server Appliances [email protected]