Wim Vervoorn has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/38748 )
Change subject: soc/intel/common/block/lpc: Add support to allow all UART options ......................................................................
Patch Set 1:
(1 comment)
https://review.coreboot.org/c/coreboot/+/38748/1/src/soc/intel/common/block/... File src/soc/intel/common/block/lpc/Kconfig:
https://review.coreboot.org/c/coreboot/+/38748/1/src/soc/intel/common/block/... PS1, Line 17: prompt "Index for COMA UART"
Right now this information is not in the device tree so we would have to add it. […]
I think this depends on the way you look at the code. In my view, the generic support code included in the chipset directories (like north/south bride soc, etc) should be as generic as possible and should not make assumptions on the use by mainboards. Because this limits the usability of the code and encourages board implementors to implement the same functionality in a non-standard way.
In this case, it would mean that this code should support all possible options in the LPC bridge that we want to support. Right now only the 2 com port ranges are handled. The FDD and LPT range are not. The FDD makes sense I can't imagine somebody is still using this. There may still boards that want to support LPT I guess. Another one is the IO enables register. I had a look at this and the handling is different for each chipset and there is no way to configure on the board level other than by changing the chipset code.
The IO enables register offers 6 options: 2E, 4E, KBC, EC, LGE and HGA. If I look at the implementation for cnl, icl, skl and tgl I get the following results: cnl enables all but HGA. icl and tgl all but 4E and HGA and skl only enables 2E, KBC and EC.
If we want to fully configure the lpc forwarding from the device tree. I would suggest to add a 16 lpc_io_enables item that overrides the chipset default and a 16 bit lpc_io_decode item that allows control over the io decode ranges.
The SOC_INTEL_COMMON_BLOCK_LPC_COMB_UART item can be dropped in this case.
The advantage of the above is that addresses that aren't used are not forwarded to the lpc bus.
To answer your last question, yes we've seen cases where the 2nd UART couldn't be configured to the 2f8 default. Reasons have been custom hardware occupying the same address or legacy software requiring another address.
It's a long story but I hope this clarifies my earlier remarks.