From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:400c:c0c::242; helo=mail-wr0-x242.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 6F9BE20954CAA for ; Wed, 21 Feb 2018 02:48:27 -0800 (PST) Received: by mail-wr0-x242.google.com with SMTP id s5so3204557wra.0 for ; Wed, 21 Feb 2018 02:54:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=yUidLcXYRVGPL0m6yDrVDDyx5Y3/MmDJ0mJx1Zjhhw4=; b=ORzdY9LJzV7dg8aHT0ZjeAW4v5hjRwlH26OdW9DES0k+Tk4smVr24pShQXCCUO1fu/ pkHn8LCHFEEDRTuT0f1rTbF2vPSxl4IxfdR/CZLJc5O4oy6nnlHE7hflPM1w/WNb8oID 3AmwW1enx3wKsXW+ikPGf3B9H5w6mlMI5ijJk= 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:references :mime-version:content-disposition:in-reply-to:user-agent; bh=yUidLcXYRVGPL0m6yDrVDDyx5Y3/MmDJ0mJx1Zjhhw4=; b=NTitzKKYeMUQyVTIWaHPeyQqPrOarC049/gQCeqzUzmdESMNW2u5aoztYeU5zdZCRC +yrFDFdttWsyvsvZ4FgmE/sIH3joBhNraHmBa7Z1EiXE7qWpwddb+yGOFZN9Uk4lnhxR U/o02ojuY4hluAWHo/nQO9d+2uWg0L6BYLbCnOZnLBFEtMum3jjGBZWB0vuoVP0vWLot OYSbUq8jNuU+TxtG605aY0GebWlzeB7ZiZMz01+sWcU5xAu+uEM5qVg0erEn/iI+GVuJ bdO6shOFITcQC/q3gO2WoWbWa27yXMxI9qRetpYEo6J3z6u7vKuKw3xbSq7rNv9rtUYI T3hg== X-Gm-Message-State: APf1xPAs1P9QOCK0WX2ptauP6KHGGIuWHumUozp2umBCoKOyntht5KiB e+u/pi36NshKccA8UDp7AQVcvMSh1JU= X-Google-Smtp-Source: AH8x226ym+ExWJr/fPBkDkifpCHpWJPwfVoQtcmEAiqZ7JDtyrzsU6/9pBYmlqKHEQmNI5W3+4X7OA== X-Received: by 10.28.225.66 with SMTP id y63mr1676860wmg.148.1519210465224; Wed, 21 Feb 2018 02:54:25 -0800 (PST) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id l17sm24906458wrh.67.2018.02.21.02.54.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 21 Feb 2018 02:54:24 -0800 (PST) Date: Wed, 21 Feb 2018 10:54:22 +0000 From: Leif Lindholm To: Ard Biesheuvel Cc: "edk2-devel@lists.01.org" Message-ID: <20180221105422.pwnwieugy6tsdp7z@bivouac.eciton.net> References: <20180221101918.16088-1-ard.biesheuvel@linaro.org> <20180221102448.d5liacahtcofcbm7@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [PATCH edk2-platforms] Silicon/Socionext/SynQuacerI2cDxe: fix TPL handling bug X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 10:48:28 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Feb 21, 2018 at 10:44:05AM +0000, Ard Biesheuvel wrote: > On 21 February 2018 at 10:24, Leif Lindholm wrote: > > On Wed, Feb 21, 2018 at 10:19:18AM +0000, Ard Biesheuvel wrote: > >> Currently, SynQuacerI2cStartRequest() increases the TPL to TPL_HIGH_LEVEL > >> while accessing the I2C controller hardware, but fails to restore the TPL > >> to the original level if the call to SynQuacerI2cMasterStart() fails, and > >> returns right away. Given the TPL_HIGH_LEVEL implies that interrupts are > >> disabled, this results in a complete system hang. So instead, break out > >> of the loop, so that the TPL restore will occur before leaving the function. > >> > >> Contributed-under: TianoCore Contribution Agreement 1.1 > >> Signed-off-by: Ard Biesheuvel > >> --- > >> Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c b/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c > >> index 46c512a20151..b2318a6f5a8c 100644 > >> --- a/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c > >> +++ b/Silicon/Socionext/SynQuacer/Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.c > >> @@ -324,7 +324,7 @@ SynQuacerI2cStartRequest ( > >> > >> Status = SynQuacerI2cMasterStart (I2c, SlaveAddress, Op); > >> if (EFI_ERROR (Status)) { > >> - return Status; > >> + break; > >> } > >> > >> Status = WaitForInterrupt (I2c); > > > > This change also causes > > > > // Stop the transfer > > MmioWrite8 (I2c->MmioBase + F_I2C_REG_BCR, 0); > > > > to be executed in the faulting case. > > > > Which at the very least looks quirky. > > > > I don't think it is unreasonable in general to stop any ongoing > transfer no matter how we leave this function. And in this particular > case, one of the failure modes is F_I2C_BCR_MSS being set without the > bus being busy as a result, and so clearing BCR is actually rather > appropriate here. So stopping an ongoing transfer even if none have been started (as is possible here) is a non-issue? If so, I have no objection (but would appreciate that mentioned where the "// Stop the transfer" comment currently is). (("// Force bus state to idle, terminating any ongoing transfer"))? And could commit message mention this change in behaviour please? / Leif