All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 5/6] powerpc/powernv: implement opal_put_chars_nonatomic
Date: Mon, 09 Apr 2018 18:24:46 +1000	[thread overview]
Message-ID: <1523262286.11062.16.camel@kernel.crashing.org> (raw)
In-Reply-To: <20180409162314.20e486c3@roar.ozlabs.ibm.com>

On Mon, 2018-04-09 at 16:23 +1000, Nicholas Piggin wrote:
> On Mon, 09 Apr 2018 15:57:55 +1000
> Benjamin Herrenschmidt <benh@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.

Yeah ok, it's just that in Linux "atomic" usually means something else
:-) Why not just call it "unlocked" which is what it's about and
matches existing practices thorough the kernel ?

> > 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.

Ok, so hopefully we shouldn't be hitting the delay..

Cheers,
Ben.

  reply	other threads:[~2018-04-09  8:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-09  5:40 [PATCH 0/6] improve OPAL cosole flushing and locking Nicholas Piggin
2018-04-09  5:40 ` [PATCH 1/6] powerpc/powernv: opal-kmsg use flush fallback from console code Nicholas Piggin
2018-04-10  5:01   ` Russell Currey
2018-04-09  5:40 ` [PATCH 2/6] powerpc/powernv: Implement and use opal_flush_console Nicholas Piggin
2018-04-10  5:02   ` Russell Currey
2018-04-09  5:40 ` [PATCH 3/6] powerpc/powernv: Remove OPALv1 support from opal console driver Nicholas Piggin
2018-04-09  5:40 ` [PATCH 4/6] powerpc/powernv: move opal console flushing to udbg Nicholas Piggin
2018-04-09  5:40 ` [PATCH 5/6] powerpc/powernv: implement opal_put_chars_nonatomic Nicholas Piggin
2018-04-09  5:57   ` Benjamin Herrenschmidt
2018-04-09  6:23     ` Nicholas Piggin
2018-04-09  8:24       ` Benjamin Herrenschmidt [this message]
2018-04-09  9:02         ` Nicholas Piggin
2018-04-09  5:40 ` [PATCH 6/6] drivers/tty/hvc: remove unexplained "just in case" spin delay Nicholas Piggin
2018-04-09  6:03   ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1523262286.11062.16.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=npiggin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.