Received: by 10.192.165.148 with SMTP id m20csp4772608imm; Tue, 1 May 2018 03:38:06 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpm/Ocu2NHXA6/zAz1RTkLLv6v4z+BtEyr5+9khwPb4goYG9D+RZRRt/fmr0eIZjPQIWnj2 X-Received: by 10.98.171.16 with SMTP id p16mr15009749pff.211.1525171086186; Tue, 01 May 2018 03:38:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525171086; cv=none; d=google.com; s=arc-20160816; b=rLRInJVOR3eHS5wnU1mSHQx49d6iTIOXIJecISXikmSC7wuwQAf/yUHN8TRg518LlY 3Pk0565XMYjBAHBt0vOrUisgScn1DnexhGsrWREXW00IOrodpcCsgLSRNaqkZaZCUMr6 kiTbIwGiEs+HH4sRaLT7Zr5k2EtnvLkjQFWzeSUlvmbqjBi7cuwq8mSoMS7TzoWnB3um 9UD/xsc4AOdXpBpPXVgkZVcfo62v5qMnn08H4EIA2dsskE3zrvEZfLsnji8NdtmUcmpo 6FuSdNjKZNEiVkyjSQossRAmfDNtWrM1VnEVRWOcFK2yDz6YljJWhTZ5Hc9DdL/MWmHs jZlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:dkim-signature:arc-authentication-results; bh=qqM9Ix5uTMTIrOp+o+dk0Yu4umfgT+/g2cubkx4MCKU=; b=pRPmdWYrkcVG3v0FUmEaQe27prhuQHfMaerL7FNdA1fgDP6MWXM/WI++V0lrjSmuJI iHyq88zqMiwpiFmpRxG9QLHlqWZCAkplf63PztmuoU+OZIve3V6DdviIe2i6OMNS3E6n w7Mfp1KoH8bm17+jw71P/8TyUpjUCUFQGbtxKaF+Om0g93pX/8B4DJbvbCvlonhr6Bt8 5zS9pOyOuOClly+xCrxHDjwNrxDIVTGZEv0uDR043DdoZnaRbO9KBD8HngYk2pBhfptg 8NW9RJbnFtSVuEKpVCxTUVaN4Ln03aPRlAb7nmcQ5zq5IpnAULSTaZAnhVpir5BUSfaL DMkg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=gCsacTxT; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m1-v6si7718492pgm.413.2018.05.01.03.37.51; Tue, 01 May 2018 03:38:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=gCsacTxT; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754571AbeEAKhf (ORCPT + 99 others); Tue, 1 May 2018 06:37:35 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:35743 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754340AbeEAKhd (ORCPT ); Tue, 1 May 2018 06:37:33 -0400 Received: by mail-pf0-f193.google.com with SMTP id j5so8879126pfh.2 for ; Tue, 01 May 2018 03:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=qqM9Ix5uTMTIrOp+o+dk0Yu4umfgT+/g2cubkx4MCKU=; b=gCsacTxTOv3UaOoj16KX8FZqALt30m/63hJGsQRZMIF92NFoCa79sWrOwVtPBjTP+7 I4qbISPClfxjC+s4XRTwZbeRYK6cMYyCZBlzSYChTwRmTCQVbv9w7n3WyZFYiNwWfYjo L+9Hm6QG+7Ee3DyUM7NxRNrpECQZp2YMxjdDeSn3nimhBNJ/bt2CxvN+TdrYYCe1fdvQ 2TxH4DQ2b9kLj7yzPkv7iqYETxp2BGEN6TZpmNh9DnSAj7t6J1WIntenRVHZp75xsc5h dkWVs28gdXEBFFH/EA5qXUcN2uKS27XaQiB3dtw+yWSC0tqWY/x0WMG+Ddn9lydxJMbX lsUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=qqM9Ix5uTMTIrOp+o+dk0Yu4umfgT+/g2cubkx4MCKU=; b=c6qgcCcLA+cZfCRt9Cr/zLa7p9xMnGkzE0BkPxReWEIrqorczFGIpqgPaPeWO+DAl5 UiROJzcEsYJwi/LnfsDEpsLA06FX+/C3/bh+E9Zshumj14arBvLEA/hsOZDAxpRzV0Jp uW3xS4TIK+70DgaWnxP7FU++SRSYr0T3uC8b9joi3f45HcvejdiaP9ciXZgL3Bu0qUl8 Hie6i+983dCtkd9ch5OxTImFajLgF44vJdWXvDFvxL6kSqwn3eT8yyamHYYVNPBaUTfU y9w5bxRd2+B4nlZsuWAE0Lbw58grPdvTuP4jyzbAllw6iGJM1BObGjp1IJlSsxBmAN6H zGSQ== X-Gm-Message-State: ALQs6tBFDUAjjSr4GzhAww3F1xgqnDgxy+dJyhjfNiNi7/w2UtMp25XC mZieBFFem2M9ZNZ/f7dTf056PA== X-Received: by 10.98.166.206 with SMTP id r75mr15252746pfl.82.1525171053282; Tue, 01 May 2018 03:37:33 -0700 (PDT) Received: from roar.ozlabs.ibm.com (59-102-70-78.tpgi.com.au. [59.102.70.78]) by smtp.gmail.com with ESMTPSA id u4sm16478420pfh.120.2018.05.01.03.37.29 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 01 May 2018 03:37:32 -0700 (PDT) Date: Tue, 1 May 2018 20:37:21 +1000 From: Nicholas Piggin To: Benjamin Herrenschmidt Cc: linuxppc-dev@lists.ozlabs.org, Greg Kroah-Hartman , Jiri Slaby , linux-kernel@vger.kernel.org Subject: Re: [PATCH 08/15] powerpc/powernv: implement opal_put_chars_atomic Message-ID: <20180501203721.7b60fcd8@roar.ozlabs.ibm.com> In-Reply-To: <1525168138.2325.100.camel@kernel.crashing.org> References: <20180430145558.4308-1-npiggin@gmail.com> <20180430145558.4308-9-npiggin@gmail.com> <1525168138.2325.100.camel@kernel.crashing.org> Organization: IBM X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 01 May 2018 19:48:58 +1000 Benjamin Herrenschmidt wrote: > On Tue, 2018-05-01 at 00:55 +1000, Nicholas Piggin wrote: > > The RAW console does not need writes to be atomic, so relax > > opal_put_chars to be able to do partial writes, and implement an > > _atomic variant which does not take a spinlock. This API is used > > in xmon, so the less locking that is used, the better chance there > > is that a crash can be debugged. > > Same comment I already had :-) "atomic" in Linux tends to mean > something else (ie, atomic context), so I'd rather have something > like opal_put_chars_sync() or such... Oh yeah, I didn't ignore you, just... I thought atomic was okay. atomic *also* tends to mean happens atomically. I think the in atomic context meaning actually tends to be inatomic. Sync I actually thought could be more easily confused with synchronous vs asynchronous here. > > > Cc: Benjamin Herrenschmidt > > Signed-off-by: Nicholas Piggin > > --- > > arch/powerpc/include/asm/opal.h | 1 + > > arch/powerpc/platforms/powernv/opal.c | 37 +++++++++++++++++++-------- > > drivers/tty/hvc/hvc_opal.c | 18 +++++++++---- > > 3 files changed, 41 insertions(+), 15 deletions(-) > > > > diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h > > index bbff49fab0e5..5d7072411561 100644 > > --- a/arch/powerpc/include/asm/opal.h > > +++ b/arch/powerpc/include/asm/opal.h > > @@ -303,6 +303,7 @@ extern void opal_configure_cores(void); > > > > extern int opal_get_chars(uint32_t vtermno, char *buf, int count); > > extern int opal_put_chars(uint32_t vtermno, const char *buf, int total_len); > > +extern int opal_put_chars_atomic(uint32_t vtermno, const char *buf, int total_len); > > extern int opal_flush_console(uint32_t vtermno); > > > > extern void hvc_opal_init_early(void); > > diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c > > index 55d4b1983110..bcdb90ada938 100644 > > --- a/arch/powerpc/platforms/powernv/opal.c > > +++ b/arch/powerpc/platforms/powernv/opal.c > > @@ -344,9 +344,9 @@ int opal_get_chars(uint32_t vtermno, char *buf, int count) > > return 0; > > } > > > > -int opal_put_chars(uint32_t vtermno, const char *data, int total_len) > > +static int __opal_put_chars(uint32_t vtermno, const char *data, int total_len, bool atomic) > > { > > - unsigned long flags; > > + unsigned long flags = 0 /* shut up gcc */; > > int written; > > __be64 olen; > > s64 rc; > > @@ -354,11 +354,8 @@ int opal_put_chars(uint32_t vtermno, const char *data, int total_len) > > if (!opal.entry) > > return -ENODEV; > > > > - /* We want put_chars to be atomic to avoid mangling of hvsi > > - * packets. To do that, we first test for room and return > > - * -EAGAIN if there isn't enough. > > - */ > > - spin_lock_irqsave(&opal_write_lock, flags); > > + if (atomic) > > + spin_lock_irqsave(&opal_write_lock, flags); > > rc = opal_console_write_buffer_space(vtermno, &olen); > > if (rc || be64_to_cpu(olen) < total_len) { > > /* Closed -> drop characters */ > > @@ -391,14 +388,18 @@ int opal_put_chars(uint32_t vtermno, const char *data, int total_len) > > > > written = be64_to_cpu(olen); > > if (written < total_len) { > > - /* Should not happen */ > > - pr_warn("atomic console write returned partial len=%d written=%d\n", total_len, written); > > + if (atomic) { > > + /* Should not happen */ > > + pr_warn("atomic console write returned partial " > > + "len=%d written=%d\n", total_len, written); > > + } > > if (!written) > > written = -EAGAIN; > > } > > > > out: > > - spin_unlock_irqrestore(&opal_write_lock, flags); > > + if (atomic) > > + spin_unlock_irqrestore(&opal_write_lock, flags); > > > > /* In the -EAGAIN case, callers loop, so we have to flush the console > > * here in case they have interrupts off (and we don't want to wait > > @@ -412,6 +413,22 @@ int opal_put_chars(uint32_t vtermno, const char *data, int total_len) > > return written; > > } > > > > +int opal_put_chars(uint32_t vtermno, const char *data, int total_len) > > +{ > > + return __opal_put_chars(vtermno, data, total_len, false); > > +} > > + > > +/* > > + * opal_put_chars_atomic will not perform partial-writes. Data will be > > + * atomically written to the terminal or not at all. This is not strictly > > + * true at the moment because console space can race with OPAL's console > > + * writes. > > + */ > > +int opal_put_chars_atomic(uint32_t vtermno, const char *data, int total_len) > > +{ > > + return __opal_put_chars(vtermno, data, total_len, true); > > +} > > + > > int opal_flush_console(uint32_t vtermno) > > { > > s64 rc; > > diff --git a/drivers/tty/hvc/hvc_opal.c b/drivers/tty/hvc/hvc_opal.c > > index af122ad7f06d..0a72f98ee082 100644 > > --- a/drivers/tty/hvc/hvc_opal.c > > +++ b/drivers/tty/hvc/hvc_opal.c > > @@ -183,9 +183,15 @@ static int hvc_opal_probe(struct platform_device *dev) > > return -ENOMEM; > > pv->proto = proto; > > hvc_opal_privs[termno] = pv; > > - if (proto == HV_PROTOCOL_HVSI) > > - hvsilib_init(&pv->hvsi, opal_get_chars, opal_put_chars, > > + if (proto == HV_PROTOCOL_HVSI) { > > + /* > > + * We want put_chars to be atomic to avoid mangling of > > + * hvsi packets. > > + */ > > + hvsilib_init(&pv->hvsi, > > + opal_get_chars, opal_put_chars_atomic, > > termno, 0); > > + } > > > > /* Instanciate now to establish a mapping index==vtermno */ > > hvc_instantiate(termno, termno, ops); > > @@ -376,8 +382,9 @@ void __init hvc_opal_init_early(void) > > else if (of_device_is_compatible(stdout_node,"ibm,opal-console-hvsi")) { > > hvc_opal_boot_priv.proto = HV_PROTOCOL_HVSI; > > ops = &hvc_opal_hvsi_ops; > > - hvsilib_init(&hvc_opal_boot_priv.hvsi, opal_get_chars, > > - opal_put_chars, index, 1); > > + hvsilib_init(&hvc_opal_boot_priv.hvsi, > > + opal_get_chars, opal_put_chars_atomic, > > + index, 1); > > /* HVSI, perform the handshake now */ > > hvsilib_establish(&hvc_opal_boot_priv.hvsi); > > pr_devel("hvc_opal: Found HVSI console\n"); > > @@ -409,7 +416,8 @@ void __init udbg_init_debug_opal_hvsi(void) > > hvc_opal_privs[index] = &hvc_opal_boot_priv; > > hvc_opal_boot_termno = index; > > udbg_init_opal_common(); > > - hvsilib_init(&hvc_opal_boot_priv.hvsi, opal_get_chars, opal_put_chars, > > + hvsilib_init(&hvc_opal_boot_priv.hvsi, > > + opal_get_chars, opal_put_chars_atomic, > > index, 1); > > hvsilib_establish(&hvc_opal_boot_priv.hvsi); > > }