Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/48829 )
Change subject: soc/intel/*: drop UART pad configuration from common code ......................................................................
Patch Set 6:
(1 comment)
https://review.coreboot.org/c/coreboot/+/48829/6//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/48829/6//COMMIT_MSG@9 PS6, Line 9: UART pad configuration should not be done in common code, because that : may cause short circuits, when the user sets a wrong UART index.
When new boards get ported, the pad configuration is expected to be tested at least.
I meant that it amounts to the same expectation that board developers/maintainers set the configurations.
That is right, but it is more likely that a wrong default for a usually harmless Kconfig like UART_FOR_CONSOLE slips than wrong, explicit pad configuration. We always urge people to check pad configuration before they try a new port because of the short circuit potential. If we allow pad configuration by other means, we'd have to make a list of things to check... probably a growing one if it becomes a pattern.
Pad configuration is *not* (and never was) SoC resposibility. That's why the pad config is on board level for all other pads.
Right, but here the pad configuration is entirely contingent upon LPSS_UART configuration, which is SoC functionality.
That depends on the board. The pads can be used for GPIO as well and when somebody uses one pad as input that is accidentally con- figured as UART TX, you might have two clashing drivers.
FIXED_UART_FOR_CONSOLE was just a workaround but does not fix the underlying issue.
I was unaware of that, but what is the underlying issue? There won't be any GPIO misconfiguration if the UART number is set correctly.
Nothing wrong per se. It's just inconistent and thereby more error-prone. Before we introduced FIXED_UART_FOR_CONSOLE, the defaults were almost always wrong btw.