See patch.
I used the name stage2.c for the code (not i82371xx.c) for now.
Shall we do that for all our chipsets and devices? A stage1.c file for early init stuff, and stage2.c for the "normal" code?
Uwe.
On Thu, Jul 12, 2007 at 03:24:12AM +0200, Uwe Hermann wrote:
I used the name stage2.c for the code (not i82371xx.c) for now.
Shall we do that for all our chipsets and devices? A stage1.c file for early init stuff, and stage2.c for the "normal" code?
Does it scale? Will we be able to tell different stage2.o files from each other when linking etc?
//Peter
Peter Stuge wrote:
On Thu, Jul 12, 2007 at 03:24:12AM +0200, Uwe Hermann wrote:
I used the name stage2.c for the code (not i82371xx.c) for now.
Shall we do that for all our chipsets and devices? A stage1.c file for early init stuff, and stage2.c for the "normal" code?
Does it scale? Will we be able to tell different stage2.o files from each other when linking etc?
Good point. Should we go with stage2-82371xx.c or similar? Also, with stuff like SMBus where in v2 we have a header that stores a bunch of functions used in both "stage1" and "stage2" (example: nvidia mcp55, intel i82801xx, etc), how do we define naming of those?
-Corey
On Wed, Jul 11, 2007 at 11:27:26PM -0400, Corey Osgood wrote:
Peter Stuge wrote:
On Thu, Jul 12, 2007 at 03:24:12AM +0200, Uwe Hermann wrote:
I used the name stage2.c for the code (not i82371xx.c) for now.
Shall we do that for all our chipsets and devices? A stage1.c file for early init stuff, and stage2.c for the "normal" code?
Does it scale? Will we be able to tell different stage2.o files from each other when linking etc?
Good point. Should we go with stage2-82371xx.c or similar? Also, with
I don't think that's needed, the individual stage2.c and resulting stage2.o files are in different directories.
stuff like SMBus where in v2 we have a header that stores a bunch of functions used in both "stage1" and "stage2" (example: nvidia mcp55, intel i82801xx, etc), how do we define naming of those?
I don't understand. Can you elaborate?
Putting code in header files is probably a thing of the past in v3, I don't see much reason why we should do that.
stage1.c will usually only contain very small pieces of code, and there won't be much overlap with what's in stage2.c, I guess.
Uwe.
On 7/11/07, Corey Osgood corey.osgood@gmail.com wrote:
Good point. Should we go with stage2-82371xx.c or similar?
I don't see the need, since the stage2 will all be in seperate directories.
ron
* Peter Stuge peter@stuge.se [070712 04:29]:
On Thu, Jul 12, 2007 at 03:24:12AM +0200, Uwe Hermann wrote:
I used the name stage2.c for the code (not i82371xx.c) for now.
Shall we do that for all our chipsets and devices? A stage1.c file for early init stuff, and stage2.c for the "normal" code?
Does it scale? Will we be able to tell different stage2.o files from each other when linking etc?
yes, by the path they are located in.
On Thu, Jul 12, 2007 at 11:17:30AM +0200, Stefan Reinauer wrote:
Shall we do that for all our chipsets and devices? A stage1.c file for early init stuff, and stage2.c for the "normal" code?
Does it scale? Will we be able to tell different stage2.o files from each other when linking etc?
yes, by the path they are located in.
Also once linking is done? Any problem with two identical southbridges or superios?
If no problems, it's great to know what the file does! :)
//Peter
* Peter Stuge peter@stuge.se [070712 11:26]:
On Thu, Jul 12, 2007 at 11:17:30AM +0200, Stefan Reinauer wrote:
Shall we do that for all our chipsets and devices? A stage1.c file for early init stuff, and stage2.c for the "normal" code?
Does it scale? Will we be able to tell different stage2.o files from each other when linking etc?
yes, by the path they are located in.
Also once linking is done?
I am sure I miss your point,.. When linking is done, the .o files are usually not needed anymore?
Any problem with two identical southbridges or superios?
No.
Stefan
On 7/11/07, Peter Stuge peter@stuge.se wrote:
On Thu, Jul 12, 2007 at 03:24:12AM +0200, Uwe Hermann wrote:
I used the name stage2.c for the code (not i82371xx.c) for now.
Shall we do that for all our chipsets and devices? A stage1.c file for early init stuff, and stage2.c for the "normal" code?
Does it scale? Will we be able to tell different stage2.o files from each other when linking etc?
They're in different directories, is that sufficient?
ron
On Thu, Jul 12, 2007 at 04:33:37PM -0700, ron minnich wrote:
Does it scale? Will we be able to tell different stage2.o files from each other when linking etc?
They're in different directories, is that sufficient?
According to others it'll be fine. I was not sure if it would be a problem but I guess not. :)
My worry was that for debugging only the filename would not make much sense, and that's usually the only identifier readily available. Ie.
stage2.c: thisnthat error
doesn't mean much when two different southbridges or superios can produce the same error in the same stage.
//Peter
On Thu, Jul 12, 2007 at 03:24:12AM +0200, Uwe Hermann wrote:
See patch.
I used the name stage2.c for the code (not i82371xx.c) for now.
Shall we do that for all our chipsets and devices? A stage1.c file for early init stuff, and stage2.c for the "normal" code?
Uwe.
http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
A new 'i82371xx' southbridge driver supporting (at least) the Intel 82371FB/SB/AB/EB/MB southbridges.
Drop the old 'i82371eb' driver and use 'i82371xx' for QEMU now.
Signed-off-by: Uwe Hermann uwe@hermann-uwe.de
Apart from the stageX.c naming, does the patch look good? Can it be committed?
Thanks, Uwe.