From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 631FAC43331 for ; Sat, 9 Nov 2019 10:02:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2D81A207FF for ; Sat, 9 Nov 2019 10:02:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="n+9KWcl8" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726383AbfKIKCP (ORCPT ); Sat, 9 Nov 2019 05:02:15 -0500 Received: from mail-il1-f193.google.com ([209.85.166.193]:36256 "EHLO mail-il1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726252AbfKIKCO (ORCPT ); Sat, 9 Nov 2019 05:02:14 -0500 Received: by mail-il1-f193.google.com with SMTP id s75so7389125ilc.3; Sat, 09 Nov 2019 02:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vs+X/P6W6GYH7cIsgTvFIxrJJ1RMCt8vlHBVN9YTrLQ=; b=n+9KWcl8vOdYRTmaJECL2uOdZwgNRwme1qf9MpQEwyNYP4PJCvqjxwN7vOxarol1dX FBLk4FKdm7GqK9IjJ8HsQlqR1JJPgO9L4B0LVxq2BLFCIJNm7oHtLm3OnFq8bC59aw6o H9/ueLtU9mhhfTeq9r9Fgq/HCeY1W4kLqPnjmKIyQqGWZ1pDgh/XmyC6KAM7SIs/bUYj CDLEI0BZ/VcF4cqycI/Raj6wNkTaxv/a6K9v0QS1WdwKRP2Q4SmPxlfDJh8tiXmJ8jAy IjXQ2Rcauv8Zkh/LALFHochpqrGxBUxt2ndhlSEukqPP/VVUgobKszDXP18I8hee+AeV 8yuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vs+X/P6W6GYH7cIsgTvFIxrJJ1RMCt8vlHBVN9YTrLQ=; b=CV2Nl7L1rlqDTqTsGmQv72WNE6DpPQoA4pBerzErzNgfIEqXXpjuB6Yxfw/LmRp7Da qPiNpYvNDLiomgXON7Kq6JzGJW6/r/r4QZ+IQqP5vyNjvnnJRFRoONHX42GErugAdY9f UjgLDD13D1PqxxKlYSPCvk+R0NdQJHvJESqyU+x3GUb7GkqomPvD0blOhKzUVfBhjuy2 t8C44sfp817g96ME5vHYN0StE/LYz7Z/JSUfa8HizSnkN/5qzsMlbk1e7B1HQ3dLvTDl esRx27mK6N6grCZlU8adBwB5a7H3tnBxMtf5yRgI/GQfVfvjehYRUyyhgsgAuDj6kBZ9 hqgw== X-Gm-Message-State: APjAAAVepCf2Kc6y+oe03Y67hCFhv2CgskUmUBs5pbpRcMspWecgyNJv Mx6JNuNkeAlM8GoZBmxsFYxaLh9KhkbAKYrbuDU= X-Google-Smtp-Source: APXvYqwianoJVEmtn2oB/9sgIxCrQXModFIIVSb6OLqRds94y5OawtkCJhr0dkaYju58pyUI6OozxaX3kdh3mBoWB0c= X-Received: by 2002:a92:5c4f:: with SMTP id q76mr18038660ilb.158.1573293731681; Sat, 09 Nov 2019 02:02:11 -0800 (PST) MIME-Version: 1.0 References: <4F6078BD-0759-4B47-933E-E29EE1D8AD18@goldelico.com> In-Reply-To: <4F6078BD-0759-4B47-933E-E29EE1D8AD18@goldelico.com> From: Adam Ford Date: Sat, 9 Nov 2019 04:02:00 -0600 Message-ID: Subject: Re: [PATCH v3 0/8] OMAP3: convert opp-v1 to opp-v2 and read speed binned / 720MHz grade bits To: "H. Nikolaus Schaller" Cc: Mark Rutland , devicetree , Discussions about the Letux Kernel , linux-pm@vger.kernel.org, Tony Lindgren , Viresh Kumar , "Rafael J. Wysocki" , Linux Kernel Mailing List , Enric Balletbo i Serra , Rob Herring , =?UTF-8?Q?Andr=C3=A9_Roth?= , =?UTF-8?Q?Beno=C3=AEt_Cousson?= , kernel@pyra-handheld.com, Teresa Remmet , Javier Martinez Canillas , Linux-OMAP , arm-soc , Roger Quadros Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 9, 2019 at 12:12 AM H. Nikolaus Schaller wrote: > > Hi Adam, > > > Am 08.11.2019 um 21:08 schrieb Adam Ford : > > > > > > Nikolaus, > > > > I am getting some notices sent to me when I apply your series. It > > works, but I want to clean up the notice. Can you suggest what might > > cause this: > > > > debugfs: Directory 'cpu0-cpu0' with parent > > '48070000.i2c:twl@48:regulator-vdd1-VDD1' already present! > > > > It wasn't present before your series. It's not a big deal, but I'd > > like to quiet down the messages if I can. > > Thanks. > > I have checked and can also see this message - and it should be removed. > > There is a debugfs node at: > > /sys/kernel/debug/regulator/48070000.i2c:twl@48:regulator-vdd1-VDD1/cpu0-cpu0 > > OMAP5 also has a similar node but no such debugfs warning: > > /sys/kernel/debug/regulator/smps123/cpu0-cpu0 > > So what I suspect is some bug in the twl4030 regulator driver which is > just revealed by my patch series for the first time. I was wondering that too. > > Could it be that the debugfs node is created and not cleaned up by deferred > probing? That would make sense to me. > > But this is not explicitly done in drivers/regulator/twl-regulator.c > > BTW: twl6030 and palmas (twl6037) have separate driver, so that mentioning > twl6030 in the comments in drivers/regulator/twl-regulator.c may be wrong. > It also mentions some "TW5030" which I have never heard of. > > To find out the call sequence I added a dump_stack to start_creating() > after the error message is printed: > > > [ 2.289947] debugfs: Directory 'cpu0-cpu0' with parent '48070000.i2c:twl@48:regulator-vdd1-VDD1' already present! > [ 2.301727] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc6-letux+ #1329 > [ 2.309112] Hardware name: Generic OMAP36xx (Flattened Device Tree) > [ 2.315734] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [ 2.323852] [] (show_stack) from [] (dump_stack+0x7c/0x9c) > [ 2.331420] [] (dump_stack) from [] (start_creating+0xa8/0x104) > [ 2.339477] [] (start_creating) from [] (debugfs_create_dir+0xc/0xc0) > [ 2.348052] [] (debugfs_create_dir) from [] (create_regulator+0xd0/0x1c8) > [ 2.356994] [] (create_regulator) from [] (_regulator_get+0x190/0x224) > [ 2.365661] [] (_regulator_get) from [] (dt_cpufreq_probe+0x80/0x108) > [ 2.374237] [] (dt_cpufreq_probe) from [] (platform_drv_probe+0x48/0x98) > [ 2.383087] [] (platform_drv_probe) from [] (really_probe+0x164/0x324) > [ 2.391754] [] (really_probe) from [] (driver_probe_device+0x10c/0x154) > [ 2.400512] [] (driver_probe_device) from [] (bus_for_each_drv+0x90/0xb8) > [ 2.409423] [] (bus_for_each_drv) from [] (__device_attach+0x90/0x120) > [ 2.418090] [] (__device_attach) from [] (bus_probe_device+0x28/0x80) > [ 2.426666] [] (bus_probe_device) from [] (device_add+0x2f0/0x55c) > [ 2.434967] [] (device_add) from [] (platform_device_add+0x12c/0x1b8) > [ 2.443542] [] (platform_device_add) from [] (platform_device_register_full+0xec/0x13c) > [ 2.453765] [] (platform_device_register_full) from [] (ti_cpufreq_probe+0x298/0x2fc) > [ 2.463775] [] (ti_cpufreq_probe) from [] (platform_drv_probe+0x48/0x98) > [ 2.472625] [] (platform_drv_probe) from [] (really_probe+0x164/0x324) > [ 2.481292] [] (really_probe) from [] (driver_probe_device+0x10c/0x154) > [ 2.490051] [] (driver_probe_device) from [] (bus_for_each_drv+0x90/0xb8) > [ 2.498992] [] (bus_for_each_drv) from [] (__device_attach+0x90/0x120) > [ 2.507629] [] (__device_attach) from [] (bus_probe_device+0x28/0x80) > [ 2.516204] [] (bus_probe_device) from [] (device_add+0x2f0/0x55c) > [ 2.524505] [] (device_add) from [] (platform_device_add+0x12c/0x1b8) > [ 2.533081] [] (platform_device_add) from [] (platform_device_register_full+0xec/0x13c) > [ 2.543304] [] (platform_device_register_full) from [] (ti_cpufreq_init+0x78/0xa8) > [ 2.553039] [] (ti_cpufreq_init) from [] (do_one_initcall+0xb4/0x268) > [ 2.561645] [] (do_one_initcall) from [] (kernel_init_freeable+0x11c/0x1ec) > [ 2.570770] [] (kernel_init_freeable) from [] (kernel_init+0x8/0x110) > [ 2.579345] [] (kernel_init) from [] (ret_from_fork+0x14/0x2c) > [ 2.587249] Exception stack(0xde0b1fb0 to 0xde0b1ff8) > [ 2.592559] 1fa0: 00000000 00000000 00000000 00000000 > [ 2.601135] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > [ 2.609680] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 > > > So the problem seems to be that ti_cpufreq_probe() tries to register the regulators > "vdd" and "vbb" without properly checking if they have been registered elsewhere. > > The second attempt to create the debugfs directory seems to come from resources_available() > which thinks that it has to create the regulator (again) [around line 1935 in drivers/regulator/core.c]. > > Hope this helps, although I have no idea why the vdd regulator already exists at that point. Thank you for the detailed analysis. > > BR, > Nikolaus > > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel