On Mon, 09 Apr 2018 15:57:55 +1000 Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote:
> On Mon, 2018-04-09 at 15:40 +1000, Nicholas Piggin wrote: > > The RAW console does not need writes to be atomic, so implement a > > _nonatomic variant which does not take a spinlock. This API is used > > in xmon, so the less locking thta's used, the better chance there is > > that a crash can be debugged. > > I find the term "nonatomic" confusing... I guess it is to go with the "atomic" comment for the hvsi console case -- all characters must get to the console together or not at all. > don't we have a problem if we > start hitting OPAL without a lock where we can't trust > opal_console_write_buffer_space anymore ? I think we need to handle > partial writes in that case. Maybe we should return how much was > written and leave the caller to deal with it. Yes, the _nonatomic variant doesn't use opal_console_write_buffer_space and it does handle partial writes by returning written bytes (although callers generally tend to loop at the moment, we might do something smarter with them later). > I was hoping (but that isn't the case) that by nonatomic you actually > meant calls that could be done in a non-atomic context, where we can do > msleep instead of mdelay. That would be handy for the console coming > from the hvc thread (the tty one). Ah right, no. However we no longer loop until everything is written, so the hvc console driver (or the console layer) should be able to deal with that with sleeping. I don't think we need to put it at this level of the driver, but I don't know much about the console code. Thanks, Nick