[PATCH] lib: utils/serial: Modify uart_getc to a blocking function

Jessica Clarke jrtc27 at jrtc27.com
Sat Nov 13 16:31:19 PST 2021


On 14 Nov 2021, at 00:23, Xiang W <wxjstz at 126.com> wrote:
> 在 2021-11-13星期六的 22:11 +0000,Jessica Clarke写道:
>> On 13 Nov 2021, at 07:06, Xiang W <wxjstz at 126.com> wrote:
>>> 
>>> If uart_getc is non-blocking, if the sending end is faster than the
>>> receiving end, the data received by some functions(sbi_gets) is
>>> incomplete
>> 
>> Without hardware flow control this is always going to be true. Making
>> getc blocking does not change that. Moreover, making it blocking
>> means
>> there is no longer a way to poll, whereas having it be non-blocking
>> means you can poll, and if you want to make it blocking you can
>> always
>> put a loop in the caller (which also avoids putting it in every
>> single
>> driver).
>> 
>> Also, this breaks the SBI getchar call; it’s supposed to be
>> non-blocking, but this makes it blocking, so it is impossible for an
>> OS
>> to poll the SBI console.
> 
> uart get does not support and returns the same value without receiving
> data. So polling will also cause problems
> 
> int sbi_getc(void)
> {
> 	if (console_dev && console_dev->console_getc)
> 		// Return -1 without valid data
> 		return console_dev->console_getc();
> 	return -1;
> }

I do not understand what you are saying. There is no problem here. If
there is no character available, either because there is no UART or
because the UART’s receive buffer has been drained, the OS is told
there is no character. What’s wrong with that?

The only problem I can see is that BBL returns 0 when there is no UART
and -1 when there’s a UART but no character available, so this is not a
correct implementation of the legacy SBI, but probably a more sensible
interface given 0 is a valid character.

Jess




More information about the opensbi mailing list