Dear Cristi,
Is this SuperIO chip very different from the generic SMSC ones whose support code can be found in src/superio/smscsuperio? For avoiding code duplication it would be nice to move it there if it's not too hard.
Unfortunately, the generic SMSC driver is not suitable, as it assumes a SuperI/O chip with logical devices, which the LPC47N227 does not have.
I'm generally not a big fan of the accumulative drivers in coreboot, such as the smscsuperio or the i82801xx driver.
While the approach definitely makes sense on the OS level, certain revisions of certain chips may need other workarounds than other chips. Look at the i945 and i82801gx driver for some examples: A lot of work coreboot drivers have to do these days is to cope with such pecularities of hardware and supporting such errata workarounds and fixes is quite hard for a all revisions of a given chip. If we have to take care of cross dependencies for certain groups of chips, the code will become unmaintainable, and buggy. I think the 82801xx driver is an excellent example of the problems such a driver can bring.
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.
I guess in the end this is a matter of where you draw the line between unification and specialization. In my experience, using the same driver for many revisions of a chip worked pretty well while using the same driver for several generations of chips from a given vendor introduced breakage of some kind or another.
Best regards, Stefan