From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 53CFA2D634; Fri, 5 Jan 2024 14:43:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="E3vBmpO5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 977C1C433C8; Fri, 5 Jan 2024 14:43:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1704465838; bh=z3+vBIA5iLpiSpmUz7MO9Qp1v+1CIzBwYeaoscUTob4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=E3vBmpO5qwLToSGUP9zmheWeru1e/PFnWi37RDwkfSDOJaDBD9o4q5MELKNsNIFzd BTiEHR8GsPqxEg65LB+XWyIQI7ifMY+OLP/0gSY3uckoDyYvmGGgn03fxq3soA71r2 tl8OEIjiFZxSclPvAmUie9tkyw7g5QNMBZdkLtN4= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Tony Lindgren , Sasha Levin Subject: [PATCH 5.4 45/47] bus: ti-sysc: Flush posted write only after srst_udelay Date: Fri, 5 Jan 2024 15:39:32 +0100 Message-ID: <20240105143817.392006907@linuxfoundation.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240105143815.541462991@linuxfoundation.org> References: <20240105143815.541462991@linuxfoundation.org> User-Agent: quilt/0.67 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 5.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tony Lindgren [ Upstream commit f71f6ff8c1f682a1cae4e8d7bdeed9d7f76b8f75 ] Commit 34539b442b3b ("bus: ti-sysc: Flush posted write on enable before reset") caused a regression reproducable on omap4 duovero where the ISS target module can produce interconnect errors on boot. Turns out the registers are not accessible until after a delay for devices needing a ti,sysc-delay-us value. Let's fix this by flushing the posted write only after the reset delay. We do flushing also for ti,sysc-delay-us using devices as that should trigger an interconnect error if the delay is not properly configured. Let's also add some comments while at it. Fixes: 34539b442b3b ("bus: ti-sysc: Flush posted write on enable before reset") Cc: stable@vger.kernel.org Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin --- drivers/bus/ti-sysc.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c index 8d82752c54d40..8ad389ebd77a9 100644 --- a/drivers/bus/ti-sysc.c +++ b/drivers/bus/ti-sysc.c @@ -1837,13 +1837,23 @@ static int sysc_reset(struct sysc *ddata) sysc_val = sysc_read_sysconfig(ddata); sysc_val |= sysc_mask; sysc_write(ddata, sysc_offset, sysc_val); - /* Flush posted write */ + + /* + * Some devices need a delay before reading registers + * after reset. Presumably a srst_udelay is not needed + * for devices that use a rstctrl register reset. + */ + if (ddata->cfg.srst_udelay) + fsleep(ddata->cfg.srst_udelay); + + /* + * Flush posted write. For devices needing srst_udelay + * this should trigger an interconnect error if the + * srst_udelay value is needed but not configured. + */ sysc_val = sysc_read_sysconfig(ddata); } - if (ddata->cfg.srst_udelay) - fsleep(ddata->cfg.srst_udelay); - if (ddata->post_reset_quirk) ddata->post_reset_quirk(ddata); -- 2.43.0