[LinuxBIOS] string comparison with macros?

[Corey Osgood]

Warning: long reply, as usual. BTW,this is Uwe's fault, he's the one
that suggested I merge the i82801aa with some other version :p

Anyways, if you hadn't figured out, I'm trying to expand on that some
and merge the code for all of the i82801 (aka ICH) models, to create one
generic set that works with all of them, and (hopefully) more. It seems
that there's very little difference between models of the i82801, and
the biggest difference is device IDs. So, I'm essentially taking the
best of each port and merging them together, and also going over the
datasheets to confirm that whats being done is correct for all of them.
 And don't worry, I won't be trying to force everyone to use this or
remove other models prematurely, when its done I'll only use this for
the stuff I'm working on. Other folks can see if it works for their
model/board and go from there.

Stefan Reinauer wrote:
> * Corey Osgood <corey_osgood at verizon.net> [070530 21:45]:
>> i82801 models by using a config option, in Options.lb. The config option
>> is "I82801_MODEL", and it would expect some short string (AA, AB, CA,
> 
> Why is that a config option? That's simply different components, but
> nothing a user would configure.

At the time, it was the simplest way to do it, it guarantees that
everything is defined through the entire compile, but can be set only
once in the mainboard code. I'm willing and hoping to change it if
there's a better way. I82801AA, etc (I'm using the full name instead of
just AA now) need to be defined somewhere that they're accessible to
both the mainboard and southbridge code, and are defined before
I82801_MODEL is set. Then I82801_MODEL needs to be defined in the
mainboard code, before auto.c calls enable_smbus, and needs to stay
defined through the compiling of the rest of the southbridge code. This
is what I've currently done in src/config/Options.lb:

###############################################
# Options for I82801 Generic driver
###############################################

define I82801_MODEL
	default 0
	export used
	comment "Select model of i82801 southbridge for generic code"
end
define I82801AA
	default 0xff00
	export always
	comment "Dummy value for i82801aa"
end
define I82801AB
	default 0xff01
	export always
	comment "Dummy value for i82801ab"
end
define I82801BA
[...]

The values themselves are meaningless, but are ordered somewhat
chronologically so if a fix-up is required for, say, i82801db and newer,
it's easy to do.

>> #if I82801_MODEL == "AA"
>> #define I82801_PCI    0x2418    /* D30:F0, PCI Interface Hub */
>> #define I82801_LPC    0x2410    /* D31:F0, LPC Interface Bridge */
>> #define I82801_IDE    0x2411    /* D31:F1, IDE Controller */
>> #define I82801_USB1    0x2412    /* D31:F2, USB Controller */
>> #define I82801_SMBUS    0x2413    /* D31:F3, SMBUS Controller */
>> #define I82801_AC97    0x2415    /* D31:F5, AC'97 Audio Controller */
>> #define I82801_MC97    0x2416    /* D31:F6, AC'97 Modem Controller */
>> #endif
> 
> What about 
> #define I82801AA_PCI 0x2418
> #define I82801AA_LPC 0x2410
> [..]
> 

Guess I wasn't very clear, sorry. Along with the quoted set of defines
would be other sets, each one defining the device IDs for different
variants of the i82801. The device code then does something like this:

static struct pci_driver ide_driver __pci_driver = {
	.ops    = &ide_ops,
	.vendor = PCI_VENDOR_ID_INTEL,
	.device = I82801_IDE,
};

If a function (like SATA or EHCI) is only present on some versions of
the i82801, then it uses the presence of a device ID to determine what
code should be built.

The only real problem with this whole thing is the possibility of having
two different i82801 versions on the same board, but would/could that
ever happen?

Thanks for the help!
-Corey