On Sun, Jan 17, 2010 at 3:51 PM, Stefan Reinauer stepan@coresystems.de wrote:
I'm generally not a big fan of the accumulative drivers in coreboot, such as the smscsuperio or the i82801xx driver.
I agree.
What it boils down to is that at time X the driver works for hardware A and then someone sends a patch for hardware B and at time Y only hardware B will be operational. Testing this on one chip is hard but possible. Especially if the maintainer of that component has access to that system. But if I were to update an errata for the LPC47N227, how could I possibly make sure it won't break 25 other SuperIO chips that I don't have? I could be very careful when writing the driver, and guard every line with if (hw_id == XX && hw_revision == YY) { ... } but then that's just two drivers in one, increasing code that has to be loaded at boot time from slow flashes and a decision that I can easily and safely take at compile time has to be redone every time at run time while increasing the burden on the code maintainer with every change, making improvements to the code very hard.
This has actually happened on coreboot. Older boards with older via NB or SB parts stopped working when those chips were modified with newer boards. It's very easy to break chip support with innocent-looking changes that "can't hurt". Chips are prone to change from rev to rev or part to part. Chips are not software.
I think for chip support forking the support software may look bad from a "software engineering" point of view, but is at times the only practical option because (to be as polite as possible) the implementation of many of these chips is not that great.
thanks ron