From patchwork Mon Feb 17 09:43:49 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Frederic Barrat X-Patchwork-Id: 1239080 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 48LfFf0JJQz9sPk for ; Mon, 17 Feb 2020 20:44:06 +1100 (AEDT) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 48LfFd5lTrzDqDc for ; Mon, 17 Feb 2020 20:44:05 +1100 (AEDT) X-Original-To: skiboot-stable@lists.ozlabs.org Delivered-To: skiboot-stable@lists.ozlabs.org Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=linux.ibm.com (client-ip=148.163.158.5; helo=mx0a-001b2d01.pphosted.com; envelope-from=fbarrat@linux.ibm.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 48LfFV4YcdzDq63 for ; Mon, 17 Feb 2020 20:43:57 +1100 (AEDT) Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01H9dCBW039933 for ; Mon, 17 Feb 2020 04:43:55 -0500 Received: from e06smtp02.uk.ibm.com (e06smtp02.uk.ibm.com [195.75.94.98]) by mx0a-001b2d01.pphosted.com with ESMTP id 2y6dh3p1t4-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 17 Feb 2020 04:43:55 -0500 Received: from localhost by e06smtp02.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 17 Feb 2020 09:43:53 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp02.uk.ibm.com (192.168.101.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 17 Feb 2020 09:43:51 -0000 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 01H9hn2q20185300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 17 Feb 2020 09:43:49 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6FAE1A4064; Mon, 17 Feb 2020 09:43:49 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4359AA405C; Mon, 17 Feb 2020 09:43:49 +0000 (GMT) Received: from pic2.home (unknown [9.145.20.186]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 17 Feb 2020 09:43:49 +0000 (GMT) From: Frederic Barrat To: skiboot-stable@lists.ozlabs.org Date: Mon, 17 Feb 2020 10:43:49 +0100 X-Mailer: git-send-email 2.21.1 MIME-Version: 1.0 X-TM-AS-GCONF: 00 x-cbid: 20021709-0008-0000-0000-00000353B484 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 20021709-0009-0000-0000-00004A74B9F1 Message-Id: <20200217094349.18146-1-fbarrat@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-17_05:2020-02-14, 2020-02-17 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=1 priorityscore=1501 mlxscore=0 bulkscore=0 phishscore=0 adultscore=0 mlxlogscore=727 clxscore=1015 malwarescore=0 lowpriorityscore=0 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002170084 Subject: [Skiboot-stable] [PATCH] npu2-opencapi: Don't drive reset signal permanently X-BeenThere: skiboot-stable@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Patches, review, and discussion for stable releases of skiboot" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: clombard@linux.ibm.com, andrew.donnellan@au1.ibm.com Errors-To: skiboot-stable-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org Sender: "Skiboot-stable" [ Upstream commit 53408440edb30de7ad18f12db285f15a0863fbc3 ] A problem was found with the way we manage the I2C signal to reset adapters. Skiboot currently always drives the value of the opencapi reset signal. We set the I2C pin for reset in output mode and keep it in output mode permanently. And since the reset signal is inverted, it is explicitly set to high by the I2C controller pretty much all the time. When the opencapi card is powered off, for example on a reboot, actively driving the I2C reset pin to high keeps applying a voltage to part of the FPGA, which can leak current, send the FPGA in a bad state since it's unexpected or even damage the card. To prevent damaging adapters, the recommendation from the hardware team is to switch back the pin to input mode at the end of a reset cycle. There are pull-up resistors on the planar of all the platforms to make sure the reset signal is high "naturally". When the slot is powered off, the reset pin won't be kept high by the i2c controller any more. Signed-off-by: Frederic Barrat Signed-off-by: Oliver O'Halloran --- hw/npu2-opencapi.c | 46 ++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 40 insertions(+), 6 deletions(-) diff --git a/hw/npu2-opencapi.c b/hw/npu2-opencapi.c index f855cdfc..4d15240e 100644 --- a/hw/npu2-opencapi.c +++ b/hw/npu2-opencapi.c @@ -918,19 +918,53 @@ err: static void deassert_adapter_reset(struct npu2_dev *dev) { uint8_t pin, data; - int rc; + int rc, rc2; pin = get_reset_pin(dev); + /* + * All we need to do here is deassert the reset signal by + * setting the reset pin to high. However, we cannot leave the + * pin in output mode, as it can cause troubles with the + * opencapi adapter: when the slot is powered off (on a reboot + * for example), if the i2c controller is actively setting the + * reset signal to high, it maintains voltage on part of the + * fpga and can leak current. It can lead the fpga to be in an + * unspecified state and potentially cause damage. + * + * The circumvention is to set the pin back to input + * mode. There are pullup resistors on the planar on all + * platforms to make sure the signal will "naturally" be high, + * without the i2c controller actively setting it, so we won't + * have problems when the slot is powered off. And it takes + * the adapter out of reset. + * + * To summarize: + * 1. set the pin to input mode. That is enough to raise the + * signal + * 2. set the value of the pin to high. The pin is input mode, + * so it won't really do anything. But it's more coherent + * and avoids bad surprises on the next call to + * assert_adapter_reset() + */ lock(&dev->npu->i2c_lock); - dev->npu->i2c_pin_wr_state |= pin; - data = dev->npu->i2c_pin_wr_state; + dev->npu->i2c_pin_mode |= pin; + data = dev->npu->i2c_pin_mode; rc = i2c_request_send(dev->npu->i2c_port_id_ocapi, - platform.ocapi->i2c_reset_addr, SMBUS_WRITE, - 0x1, 1, - &data, sizeof(data), 120); + platform.ocapi->i2c_reset_addr, SMBUS_WRITE, + 0x3, 1, + &data, sizeof(data), 120); + + dev->npu->i2c_pin_wr_state |= pin; + data = dev->npu->i2c_pin_wr_state; + rc2 = i2c_request_send(dev->npu->i2c_port_id_ocapi, + platform.ocapi->i2c_reset_addr, SMBUS_WRITE, + 0x1, 1, + &data, sizeof(data), 120); unlock(&dev->npu->i2c_lock); + if (!rc) + rc = rc2; if (rc) { /** * @fwts-label OCAPIDeviceResetFailed