On Wed, May 22, 2024 at 01:51:06PM -0700, Bao D. Nguyen wrote: > On 5/22/2024 11:16 AM, Bart Van Assche wrote: > > On 5/22/24 00:01, Bao D. Nguyen wrote: > > > interrupt starvations happen occasionally because the uart may > > > print long debug messages from different modules in the system. > > > > I think that's a bug in the UART driver that should be fixed in the > > UART driver. > > Thanks Bart. > I am not familiar with the UART drivers. I looked at some UART code and it > could be interpreted as their choice of implementation. > During product development, the UART may be used. However, when the > development completes, most likely the UART logging is disabled due to > performance reason. > > This change is to give flexibility to the SoCs to use the UART > implementation of their choice and to choose the desired UIC command timeout > without affecting the system stability or the default hardcoded UIC timeout > value of 500ms that others may be using. > If UART runs in atomic context for 500ms, then it is doomed. But for increasing the UIC timeout, I agree that the flexibility is acceptable. In that case, please use a user configurable option like cmdline etc... instead of hardcoding the value in glue drivers. - Mani -- மணிவண்ணன் சதாசிவம்
