[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2dc0dd51-2ded-996c-3b93-ad463b52582d@ti.com>
Date: Tue, 28 Jul 2020 10:34:15 -0500
From: Suman Anna <s-anna@...com>
To: Arnd Bergmann <arnd@...db.de>
CC: Lee Jones <lee.jones@...aro.org>,
Grzegorz Jaszczyk <grzegorz.jaszczyk@...aro.org>,
David Lechner <david@...hnology.com>,
Tony Lindgren <tony@...mide.com>,
Roger Quadros <rogerq@...com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
linux-omap <linux-omap@...r.kernel.org>
Subject: Re: [RESEND PATCH v2] mfd: syscon: Use a unique name with
regmap_config
On 7/28/20 2:44 AM, Arnd Bergmann wrote:
> On Mon, Jul 27, 2020 at 11:10 PM Suman Anna <s-anna@...com> 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 <s-anna@...com>
>> ---
>> 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 <arnd@...db.de>
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@...x", 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/
Powered by blists - more mailing lists