Michael Niewöhner 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.
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.
Well each NF is "SoC functionality" but configuration of these is board's obligation. UART doesn't differ here.
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.
There are boards that have more than one UART output (see RVP boards for example, which have 2-3). In the current way they are unusable and would require dropping FIXED_UART_FOR_CONSOLE. This raises the user config problem again
If the issue is board developers/maintainers not configuring UART_FOR_CONSOLE/a bad default, that should be addressed instead.