From patchwork Tue Mar 6 16:30:35 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Brown X-Patchwork-Id: 10262223 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 9F3146055D for ; Tue, 6 Mar 2018 16:32:05 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 857A2290C1 for ; Tue, 6 Mar 2018 16:32:05 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8413F290CE; Tue, 6 Mar 2018 16:32:05 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 753D92936E for ; Tue, 6 Mar 2018 16:31:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Ei9rSwEbB+d931GnFt3lD9kZi8N+0vrWPJquJd4roCg=; b=djehMw/2U4LfMKRgvLUiQLrtx a91GZTIwY668BvnkSi89cEecwTJgTmpo/oM9fA5IR+4kTVcaxACd+mPC9kWa9VT1E0jDKSNzj5OcI sFsTU+GJOrT2zwZnLjdP/bZFMSqoG9jYHMAY4MtZfe+DvJYJtJQRx7W6gyL+vYnqLPoYrGVRTpTsr NppAOzLPr1SbFMW6x5m14yX8bCjSZJKJNHo6hUUI3tDLTzGY8MTNtSIXOHj/FUPoAj/XRc2vXiV05 5laWS5/6FaakOUACEjEQuDP4T5NSMjZ2FzPsyLPMh7qJZubllcqMeHyLYeHWkc689YkMCL/cXtFrE 1oJrI/uaA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.89 #1 (Red Hat Linux)) id 1etFUP-0007Tq-UX; Tue, 06 Mar 2018 16:30:57 +0000 Received: from heliosphere.sirena.org.uk ([2a01:7e01::f03c:91ff:fed4:a3b6]) by bombadil.infradead.org with esmtps (Exim 4.89 #1 (Red Hat Linux)) id 1etFUL-0007Sj-MU for linux-arm-kernel@lists.infradead.org; Tue, 06 Mar 2018 16:30:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SSoEvgFx/9J1ocRfEYG56i976MRy3u50A91drCkwo8U=; b=IMijV7PB05xFVEWVWTJzDzUA+ qNgWl3VwfiQp27BFB1W/dUDGh7T1ieiNy7PK47ZBu0lPXgXCpvkOTfrIZ0wM7w+7p9fkPxTffjNU1 yP45HyFaBzbgefWzrWA8VDyGmuKZdFv6Cd1KM1wKKzb0DPlxhbRY6gMGUO9ojrrcSqm2k=; Received: from debutante.sirena.org.uk ([2001:470:1f1d:6b5::3] helo=debutante) by heliosphere.sirena.org.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1etFU4-0007KG-1S; Tue, 06 Mar 2018 16:30:36 +0000 Received: from broonie by debutante with local (Exim 4.90_1) (envelope-from ) id 1etFU3-00011O-Ck; Tue, 06 Mar 2018 16:30:35 +0000 Date: Tue, 6 Mar 2018 16:30:35 +0000 From: Mark Brown To: Fabio Estevam Subject: Re: Regulator regression in next-20180305 Message-ID: <20180306163035.GE13586@sirena.org.uk> References: <20180305231246.GB5799@atomide.com> MIME-Version: 1.0 In-Reply-To: X-Cookie: DYSLEXICS OF THE WORLD, UNTIE! User-Agent: Mutt/1.9.3 (2018-01-21) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180306_083053_895736_2B8E256B X-CRM114-Status: GOOD ( 17.29 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tony Lindgren , Maciej Purski , linux-omap@vger.kernel.org, linux-kernel , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, Mar 05, 2018 at 08:22:26PM -0300, Fabio Estevam wrote: > On Mon, Mar 5, 2018 at 8:12 PM, Tony Lindgren wrote: > > Looks like with next-20180305 there's a regulator regression > > where mmc0 won't show any cards or produces errors: > > mmcblk0: error -110 requesting status > > mmc1: new high speed SDIO card at address 0001 > > mmcblk0: error -110 requesting status > > mmcblk0: recovery failed! > > print_req_error: I/O error, dev mmcblk0, sector 0 > > Buffer I/O error on dev mmcblk0, logical block 0, async page read > > mmcblk0: error -110 requesting status > > mmcblk0: recovery failed! No other error messages? That seems like there's something going on that's very different to what Fabio was reporting... I'm guessing some voltage application didn't go through but it's hard to tell with so little data. dra7 does seem to have what Fabio had though so there's definitely some effect on the OMAP platforms. > I have also seen regulator issues due to this series: > https://lkml.org/lkml/2018/3/5/731 Looking at your stuff I'm having trouble figuring out what's going on - we're getting double locking of a parent regulator during enable according to your backtraces but it's not clear to me what took that lock already. regulator_enable() walks the supplies before it takes the lock on the regulator it's immediately being called on, not holding any locks on supplies while enabling. regulator_balance_voltage() then tries to lock the supplies again but lockdep says the lock is already held by regulator_enable(). It's also weird that this doesn't seem to be showing up on other boards in kernelci, the regulator setup on those i.MX boards looks to be quite simple so I'd expect a much wider impact. I'm wondering if your case is more pain from mutex_lock_nested(), both regulator_lock_coupled() and regulator_lock_supply() will end up using indexes starting at 0 for the locking classes. That doesn't smell right though, but in case my straw clutching works: If we can't figure it out I'll just drop the series but I'd prefer to at least understand what's going on. diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index e685f8b94acf..2c5b20a97f51 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -159,7 +159,7 @@ static void regulator_lock_supply(struct regulator_dev *rdev) { int i; - for (i = 0; rdev; rdev = rdev_get_supply(rdev), i++) + for (i = 1000; rdev; rdev = rdev_get_supply(rdev), i++) mutex_lock_nested(&rdev->mutex, i); }