cederom commented on PR #18837: URL: https://github.com/apache/nuttx/pull/18837#issuecomment-4963101928
I am moving discussion about PL011 UART init between @linguini1 and @xiaoxiang781216 here, as in code comments will disappear as soon as code is changed. Here we will preserve discussion history :-) This PL011 is kind of special case where more complex configuration is necessary and goes beyond current Kconfig design because it requires underlying hw knowledge that only Arch/Board has.. and as more hw shows up the more Kconfig gets complicated.. thus new approach proposed by @linguini1 as more versatile, less confusing, cleaner, better in maintenance, thus more elegant? I understand that @xiaoxiang781216 proposes to keep the old way for compatibility.. but each hw has its own parameters that are board specific rather than system specific this why it needs a switch to a new design as proposed by @linguini1? When keeping the Kconfig it should rather go Arch/Board wide rather than System wide? Or just init the PL011 in the Arch/Board code? And it may be a good time for a switch while there are still not many boards/users impacted? How about we just select how many PL011 uarts we want in the Kconfig (the "old" generic system wide way) and the rest would be done by the board setup code (the "new" way)? If we want no uart then Kconfig selects `0`, if we want one uart then Kconfig selects `1`, if we want five then Kconfig selects `5`. Board code would then perform build-time-check if requested uart count is valid (i.e. for rPI-4B selecting `6` would cause build error because only 5 is possible). Also the board would initialize underlying hardware in the way that is the best for that specific hardware. Would that create a compromise for board-aware-initialization as proposed by @linguini1 and Kconfig selectable PL011 UART count as proposed by @xiaoxiang781216 ? :-) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
