Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp394953ybg; Tue, 28 Jul 2020 08:36:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzESsisKynqxRqXrws9IeUB1QFGUYg4x5H1n94UacATwTf5l1TCd0rTfo5MQl/4pXUpgQF2 X-Received: by 2002:a17:906:a081:: with SMTP id q1mr24789302ejy.499.1595950588224; Tue, 28 Jul 2020 08:36:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595950588; cv=none; d=google.com; s=arc-20160816; b=mGBaimOsynp4mFKDAvYhetOhfpMUNxMvJQavOpQOPgDbRJ+jv5DoT6SwLFhUrExbXv C5uvwbzTEE0xdbd7z95g3c/jWyhOn1z3Wp0QnHhvnvBl9vbCvOH65zGeFHEwLHPjEXQ/ p1Vw5Z/wMXrbdcGdjWxceuE0PBZ+oXetipizgOyqJvxspJU7P18sQOAPJKVP8kLpUVI6 85C/icwaxwvf3q2lUPyTPfaU5fJpshKcwhwu5st3o+9d5cMQb8TV3cJa7tNyk/hinMia w+V3zPr19Wwvj5Vk7A4zWU5MFqyh4+fy3SWhsFumkJu4svhL3Q0rsrZIbfl97TrGbPQ2 Nsqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=Y3bdMy0j6b+YSB/57qC4aT+9PUXNDrMIyX5k/Gdanh8=; b=O2kBn6EkjGe0ezo2KqiB8Xh8MGMUK9fQTQhIWlpGRSMX6jom9vExG/+cwbsKRyjKt/ jW7EDKXfdfJ+ysYnNnCJ1TYEKaWru4JK6+aPApuLol/MezXwWAFV2zz6IwlBZgyC6Pb8 NvUGVwjyYL25RV8GpdtSUUyKY5vsb7AzBpgAOYvZRcSsPiJmRfd+4oVtPkC/+Fm6bOXi Z6xee7cxpq5uBWBs9Rq4ipuyzErqHmR9dA9tWQi+wGNnyV6NuAC4HMablccph5Wtkpz7 gLGgDcaqZbBfs5WQLn/bUPpXKhTFX/Q3iZTfjB2Elukx6xqwuWEkJPgtuw20vBt63El4 BfRw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=e0cYw271; 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=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h18si8675028eds.431.2020.07.28.08.36.05; Tue, 28 Jul 2020 08:36:28 -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=@ti.com header.s=ti-com-17Q1 header.b=e0cYw271; 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=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730914AbgG1PfH (ORCPT + 99 others); Tue, 28 Jul 2020 11:35:07 -0400 Received: from lelv0143.ext.ti.com ([198.47.23.248]:55120 "EHLO lelv0143.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730701AbgG1PfG (ORCPT ); Tue, 28 Jul 2020 11:35:06 -0400 Received: from fllv0035.itg.ti.com ([10.64.41.0]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id 06SFYGl8078735; Tue, 28 Jul 2020 10:34:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1595950456; bh=Y3bdMy0j6b+YSB/57qC4aT+9PUXNDrMIyX5k/Gdanh8=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=e0cYw271xm0WRqWGklcW02kIWJhdHY3bU5qTLX7OFrf6eOyTH+mM19LVILV7SHm0t Aj9P5gMz4nzyMF+kSPl+S0rAemWwNhdR0RF2el7mJUYxQLr9STVyvm/ISZf90vtey0 U6PtHR/PCDo0PIQJd0LlfeS3GFKasATjNye8V4rQ= Received: from DLEE111.ent.ti.com (dlee111.ent.ti.com [157.170.170.22]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTP id 06SFYGYX015577; Tue, 28 Jul 2020 10:34:16 -0500 Received: from DLEE107.ent.ti.com (157.170.170.37) by DLEE111.ent.ti.com (157.170.170.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Tue, 28 Jul 2020 10:34:16 -0500 Received: from fllv0039.itg.ti.com (10.64.41.19) by DLEE107.ent.ti.com (157.170.170.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3 via Frontend Transport; Tue, 28 Jul 2020 10:34:16 -0500 Received: from [10.250.34.248] (ileax41-snat.itg.ti.com [10.172.224.153]) by fllv0039.itg.ti.com (8.15.2/8.15.2) with ESMTP id 06SFYFBW097281; Tue, 28 Jul 2020 10:34:15 -0500 Subject: Re: [RESEND PATCH v2] mfd: syscon: Use a unique name with regmap_config To: Arnd Bergmann CC: Lee Jones , Grzegorz Jaszczyk , David Lechner , Tony Lindgren , Roger Quadros , "linux-kernel@vger.kernel.org" , Linux ARM , linux-omap References: <20200727211008.24225-1-s-anna@ti.com> From: Suman Anna Message-ID: <2dc0dd51-2ded-996c-3b93-ad463b52582d@ti.com> Date: Tue, 28 Jul 2020 10:34:15 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/28/20 2:44 AM, Arnd Bergmann wrote: > On Mon, Jul 27, 2020 at 11:10 PM Suman Anna wrote: >> >> The DT node full name is currently being used in regmap_config >> which in turn is used to create the regmap debugfs directories. >> This name however is not guaranteed to be unique and the regmap >> debugfs registration can fail in the cases where the syscon nodes >> have the same unit-address but are present in different DT node >> hierarchies. Replace this logic using the syscon reg resource >> address instead (inspired from logic used while creating platform >> devices) to ensure a unique name is given for each syscon. >> >> Signed-off-by: Suman Anna >> --- >> Hi Arnd, >> Lee is looking for your review on this patch. Can you please >> review and provide your comments. > > Sorry for missing this earlier. I think this makes sense, and I don't > expect the name change to cause problems, so > > Reviewed-by: Arnd Bergmann Thanks Arnd. > >> --- a/drivers/mfd/syscon.c >> +++ b/drivers/mfd/syscon.c >> @@ -101,12 +101,14 @@ static struct syscon *of_syscon_register(struct device_node *np, bool check_clk) >> } >> } >> >> - syscon_config.name = of_node_full_name(np); >> + syscon_config.name = kasprintf(GFP_KERNEL, "%pOFn@%llx", np, >> + (u64)res.start); > > Note that you could avoid the cast by using "%pOFn@%pa", and > passing res.start by reference. Not important though, the result should > be similar, and you might not like the '0x' that this adds. Yeah, preference was not to add the leading 0x or any leading 0s. We did discuss about this on the original v2 submission [1]. regards Suman [1] https://patchwork.kernel.org/comment/23129393/