Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3306897pxv; Mon, 26 Jul 2021 00:38:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxmRko2YsNwLnNJbyF05ZktfH0kmtbIsBhcMYlFvKW9rtGj6b+yM59q2Lb2b3KRjhGmz82Q X-Received: by 2002:a92:dc4a:: with SMTP id x10mr11960617ilq.166.1627285105692; Mon, 26 Jul 2021 00:38:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627285105; cv=none; d=google.com; s=arc-20160816; b=TKmBZR+3+rlFjjGSpOyWuBHMkGQweJ2iTnlGhlH6Hth4tYAKTAHkh+CdxytpNtIqS3 j2tvVuRGtKHTdi1CVrP8NPmvoS1anem+bN+gpWqF7ONjabL9q6cmMlvYLywfEgVwpjQ1 GLt8WATyj7GMNlKG1+9+HN8Vpq+oBDOmLRKMs01tCYXxYwGpOlEIVFQYAw0AUowME51L oXaGWoNfqbW/pdQVucvmr18Ylcudw0N9ysRrIXph8WQkDfzzDJlTdCkpxI4SQYHlfS/V LRceCaXciTEXkJhZhnRb6NP1a16tYZyD7fq3kIHS9Rq41vooQXjs6qjXKu/ybTqGW3hv s+/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from :dkim-signature:dkim-signature; bh=Lh2f00DCc0ETiBTHPeQX7NKdVsdgCnvj5dVGpBGcjVU=; b=uFxMdv7OET5rJVAoZLkgHk2T+uWXNU3U7Zqd3DpIZ4kzN3Jcvm/Nj/mx92TJsVYk/7 w3Q5KOYJIMf8AZ2qpnHZSJmABNG50wsl89Mm/qFXeXsWpO9KzZcUUP2e5f73Iy+MQVIG 2f995ueFUKmdtaP5z4xqCTezOooN4fIUmbQrVq+ZYnY68qPLSJ7b336IhV6gz2ztk5ex a8fljCepr0hvaRgDOWBAridot0nD/6wUAR3sk/aEzAgBAn0O/ErqhFZ5Y0MiXbAeUcu4 M6ZCO6BnDnDlhUqbddD8Q2VUQvQVWkZdqw0HBfiIXoOV1cmg2jp8bQXhEMgUj6QlRpvo 91Mg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@tq-group.com header.s=key1 header.b=XiL5aUr7; dkim=pass header.i=@tq-group.com header.s=key1 header.b=KSEDPBK1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=tq-group.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r9si33909909jap.26.2021.07.26.00.38.13; Mon, 26 Jul 2021 00:38:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@tq-group.com header.s=key1 header.b=XiL5aUr7; dkim=pass header.i=@tq-group.com header.s=key1 header.b=KSEDPBK1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=tq-group.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232483AbhGZG5B (ORCPT + 99 others); Mon, 26 Jul 2021 02:57:01 -0400 Received: from mx1.tq-group.com ([93.104.207.81]:64579 "EHLO mx1.tq-group.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232215AbhGZG5A (ORCPT ); Mon, 26 Jul 2021 02:57:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1627285049; x=1658821049; h=from:to:cc:subject:date:message-id; bh=Lh2f00DCc0ETiBTHPeQX7NKdVsdgCnvj5dVGpBGcjVU=; b=XiL5aUr7t7Z4zd+r2TRAoNPvQyI1fo+zxoXRjafcjF+LlsY6D7UFYDQ0 MqwRYPPL7TKgUbTW6A2t2whGVPanQBM0E8FKLiA25QcJTWHdh5JNgd4OG lNni82ZzBhJlSAfznS/q4w1I3+oCHyUcs0IAytv0UFDMxI0OskbWq5i9B K7zc/OiY0fqXu/EODxAfslH/yV8ByC0ocdncoZSK+7YBl6S1NM/bxiJMg DTJvJdgO98AITKIed2aPOs8cJLm8ZMxupGAK6wuFfnwyWYl4xmrGRcipw rag56GxDIzPVltipzoMGXscGEihHNDm0GQHjNYBhn5W6SrZ88YXgEKUQP w==; X-IronPort-AV: E=Sophos;i="5.84,270,1620684000"; d="scan'208";a="18631660" Received: from unknown (HELO tq-pgp-pr1.tq-net.de) ([192.168.6.15]) by mx1-pgp.tq-group.com with ESMTP; 26 Jul 2021 09:37:28 +0200 Received: from mx1.tq-group.com ([192.168.6.7]) by tq-pgp-pr1.tq-net.de (PGP Universal service); Mon, 26 Jul 2021 09:37:28 +0200 X-PGP-Universal: processed; by tq-pgp-pr1.tq-net.de on Mon, 26 Jul 2021 09:37:28 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1627285048; x=1658821048; h=from:to:cc:subject:date:message-id; bh=Lh2f00DCc0ETiBTHPeQX7NKdVsdgCnvj5dVGpBGcjVU=; b=KSEDPBK1x5qZlk4SBr4Re9qZsohG9L9ksXoXFp2N/ERqMSPOLyza5P05 7NjGfUAxK+10PEFdOhrD9DSi1hHf/oXRVSyAefGK+F4zmrcS2dzhVZMnL mHrEVp4yEDTZ35d1A7dK+HUgpAsjskMvRh4SIuSphU927jOLEfhQw3nKl FYUC6UTbWLEDVVtBl7YDrOMHseDDiELOyTUGQEEVECJ81kijh3tpo6VTW t459InA0t3ayDqIWgoytCEPZ5wbAxtHUbyPuhMTvAJj7AlW8gSFhKrsAf qfCW2GXV0skBrHmPfOvWCPSYHJXN4La0XIurIR9sQndtqV9tDLIQ5CLvo g==; X-IronPort-AV: E=Sophos;i="5.84,270,1620684000"; d="scan'208";a="18631659" Received: from vtuxmail01.tq-net.de ([10.115.0.20]) by mx1.tq-group.com with ESMTP; 26 Jul 2021 09:37:28 +0200 Received: from schifferm-ubuntu4.tq-net.de (schifferm-ubuntu4.tq-net.de [10.121.48.12]) by vtuxmail01.tq-net.de (Postfix) with ESMTPA id 0BDE1280070; Mon, 26 Jul 2021 09:37:28 +0200 (CEST) From: Matthias Schiffer To: Mark Brown , Greg Kroah-Hartman , "Rafael J. Wysocki" Cc: David Lechner , linux-kernel@vger.kernel.org, Matthias Schiffer Subject: [PATCH] regmap: do not call regmap_debugfs_init() from regmap_attach_dev() Date: Mon, 26 Jul 2021 09:36:27 +0200 Message-Id: <20210726073627.31589-1-matthias.schiffer@ew.tq-group.com> X-Mailer: git-send-email 2.17.1 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org regmap_debugfs_init() should never be called twice for the same regmap, as it initializes various fields of the regmap struct, including list heads and mutices. A visible symptom are messages like: debugfs: Directory 'dummy-iomuxc-gpr@20e4000' with parent 'regmap' already present! This happened whenever regmap_attach_dev() was called for an existing regmap. Remove the call from regmap_attach_dev() and change __regmap_init() so that regmap_debugfs_init() is called exactly once. Signed-off-by: Matthias Schiffer Fixes: 9b947a13e7f6 ("regmap: use debugfs even when no device") --- drivers/base/regmap/regmap.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) As mentioned in my previous mail [1], I believe that the duplicate call to regmap_debugfs_init() is not the only issue with regmap_attach_dev(). Every single user of regmap_attach_dev() outside of __regmap_init() is using it to attach a device to a syscon regmap obtained using one of the syscon_*() functions. AIUI, syscon regmaps do not belong to a single device, so calling regmap_attach_dev() seems wrong to me. My (possibly lacking) understanding of the semantics aside, the fact that regmap_attach_dev() is setting fields on the shared regmap without any kind of locking is at least suspicious. Maybe regmap_attach_dev() shouldn't be exported from the regmap code at all, removing all calls to the functions from drivers? [1] https://lkml.org/lkml/2021/7/19/500 diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c index fe3e38dd5324..27625a1330ac 100644 --- a/drivers/base/regmap/regmap.c +++ b/drivers/base/regmap/regmap.c @@ -630,8 +630,6 @@ int regmap_attach_dev(struct device *dev, struct regmap *map, if (ret) return ret; - regmap_debugfs_init(map); - /* Add a devres resource for dev_get_regmap() */ m = devres_alloc(dev_get_regmap_release, sizeof(*m), GFP_KERNEL); if (!m) { @@ -1192,10 +1190,10 @@ struct regmap *__regmap_init(struct device *dev, ret = regmap_attach_dev(dev, map, config); if (ret != 0) goto err_regcache; - } else { - regmap_debugfs_init(map); } + regmap_debugfs_init(map); + return map; err_regcache: -- 2.17.1