From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c06::241; helo=mail-io0-x241.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 212CD20954CBF for ; Wed, 21 Feb 2018 02:38:07 -0800 (PST) Received: by mail-io0-x241.google.com with SMTP id e7so1674159ioj.1 for ; Wed, 21 Feb 2018 02:44:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3FKrlEJIDikKyEd0GOsLFPurDFUbHKshHg810/GzyoQ=; b=OXIurXhydYRHhib7EScYOeETuqI8ba7J7wtk2Xq2DFhEH4TfMWk9uXJqrBxnALyxqB UiaqpK5Q3XWzzEJf7mo/Jo5LLlbsWcJc+PGxQyAvwE58h5vMgiEjf3+d/OGnkdmUCM4I aoErmYYm6nKxHESbHs5T2BSTrR6KAMLyM3c1k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3FKrlEJIDikKyEd0GOsLFPurDFUbHKshHg810/GzyoQ=; b=rsbyUt52n4MaHJ1D01gWAhjQx+d+Jz0GiMF970oVupX/MPglrAe+lf6zA4p6F1S8uV RYcOSaSeSBaivlMZVB6KNXF8cINoE3XJRQIresDgVbSOFSnSO8bm0B0hr1gfBx7ye7Gz 2DCHZigapzGFkY5WHb69bcLGX4uqrdLv99zdAwzjZSNxLXQ34OfsDXkELem4g4kI9hif 7q+nB7TLPxJEiXvuYGbfhx8pBtvHOfCdvO6/3fd6gphAIZlOixWeVgiuRzUTOeW6sEh1 Vw0bxXOU7uBeXrtw5OsGtJR9NT3weIQ+NmRXyjcVDhFmTXnJV/2hM7WAEzwWDlAOq7/m xoZg== X-Gm-Message-State: APf1xPDFlgbnOeCNeyKKJEPxLDa8KvhtgTDC/ih13KFMm6TYtjKigFR9 /eBTJu1H9ptyc+KDg1/Xwh9BrjqiOiuFZrC4iaaPjw== X-Google-Smtp-Source: AG47ELsqb/1wj3KovYmFJ0nSojWQWbiGh/2HFR/pYoVJ5eYdNj8NAx5/Idep+fTItmFLSphAuJAFggLC2Id/cbDRaaM= X-Received: by 10.107.41.16 with SMTP id p16mr3539788iop.173.1519209846246; Wed, 21 Feb 2018 02:44:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.138.209 with HTTP; Wed, 21 Feb 2018 02:44:05 -0800 (PST) In-Reply-To: <20180221102448.d5liacahtcofcbm7@bivouac.eciton.net> References: <20180221101918.16088-1-ard.biesheuvel@linaro.org> <20180221102448.d5liacahtcofcbm7@bivouac.eciton.net> From: Ard Biesheuvel Date: Wed, 21 Feb 2018 10:44:05 +0000 Message-ID: To: Leif Lindholm Cc: "edk2-devel@lists.01.org" 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:38:08 -0000 Content-Type: text/plain; charset="UTF-8" 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.