[coreboot] [PATCH] [3/7] Roda RK886EX support: SMSC LPC47N227

[Stefan Reinauer]

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