Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp833528ybl; Wed, 4 Dec 2019 11:38:28 -0800 (PST) X-Google-Smtp-Source: APXvYqy979SlhPhnUpTyNUTmhzAzFhra+VvaJbh6sQWG19LnCf0dIr16yXyuWInDwn9grXvxbyuL X-Received: by 2002:aca:568d:: with SMTP id k135mr4123932oib.45.1575488308728; Wed, 04 Dec 2019 11:38:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575488308; cv=none; d=google.com; s=arc-20160816; b=htdaJwNQeCfqbHGqRU08RzapdEDdRqBQYZpvVpJ62RtE6N4y5vbIpeym/XE2RLI7bP ZoRM74cINSAsbyUxGEBmbjnbDJGtZbK6Ku3ZZNh/gRTOmc1wjBipMJt++loruhWwDjhS /PI9sC9tUPzQxvRQXhzY3X8Fni2AsMjcRqmPUDkxmldzGpqLpj7TOPB0cdmaCCV2rVAf 8kN29USmSHa5GEE+CLTlf3hYzvOBTCUXdXJGxZxiqMC78U04HV+ufAgju8mTkpWi5egk qNHUDGyaqdt4RyIWUsZhoU3E46XiEuuTAmnE0usR3BkpD1x1PZ6jwW25TBd3je2T66lV LmYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=QEYmt+88G565IC6LTTQd0m6TuuMzboUhXwXWSfb6lpw=; b=ovmaMwuiCkzgG7GnUcKzGhITBxn5g3VA/HkLcxQpy+sZoEKu3vIuQcIl/B6IIkSGwr v2PG/Q1RRRy8VmsWG+O40QMaYNEWn0C+76dJ6OxanyqDBQ5Jf2h+k96xuwTbOoS3HY0C ucma8Giejje8O3RvnInaDhnQ7n9v3HlpSGfSQZZgWv0joWzCdG245P3n8iAR03NEVl0x +fgxXPgVLFe4AysEJJ0iD7dVmp3Dd1uE8E7n92rOXl0OFuVdxhDfpm3U8wAxhnuQU6dD O4QA9eWzYidhePmqPNNN8bYelFxphlxLjk4SFR+BwaFZM7oVcNQ5kvKMepYMFOrpYoXe UlEQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m4si3836388otq.42.2019.12.04.11.38.16; Wed, 04 Dec 2019 11:38:28 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729308AbfLDT0l (ORCPT + 99 others); Wed, 4 Dec 2019 14:26:41 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:35783 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728598AbfLDT0l (ORCPT ); Wed, 4 Dec 2019 14:26:41 -0500 Received: by mail-oi1-f193.google.com with SMTP id k196so360121oib.2; Wed, 04 Dec 2019 11:26:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=QEYmt+88G565IC6LTTQd0m6TuuMzboUhXwXWSfb6lpw=; b=Ds/6mX4b/TCRm55MXxF1S/v3hcAl6FGwQXgkCwnJTUrvQdxKHLhCs2fScgbXL07+QO qSUADZWJLlZwujUv7/qKjDoAV3w1XB63eB3peNqCvB7sqOEGGBJJuOpV3KwoerQH9pML OuJI7BsdV4kHJ6DS8MmByYt0eWd5e4uE++OQvrcBpsNl1m8+O5GYSeqlZn7fhJ6MCo20 QrBSb4gERhlCiEKlEwu3Az4qZdi+QNqSKnBCuLtaUQx+7+1MTc8rPWOWjrOQjjeHt11S CX+B1DqqaA7PmbnudA8kpIbW+fETdTdYOj9GTrhV7DQikx6oNXJKwf6xG+LIM+lJj4xI lUQg== X-Gm-Message-State: APjAAAXkLK99oA4lGiLVQh7Jtc05hT5KlRp3EaZWnSnavevCV+2ygFhY jIIylvtAEkOmEHqjf5kkmQ== X-Received: by 2002:aca:7583:: with SMTP id q125mr4218753oic.100.1575487600190; Wed, 04 Dec 2019 11:26:40 -0800 (PST) Received: from localhost (24-155-109-49.dyn.grandenetworks.net. [24.155.109.49]) by smtp.gmail.com with ESMTPSA id i25sm2499520oto.72.2019.12.04.11.26.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Dec 2019 11:26:39 -0800 (PST) Date: Wed, 4 Dec 2019 13:26:39 -0600 From: Rob Herring To: Arnd Bergmann Cc: Orson Zhai , Lee Jones , Mark Rutland , DTML , "linux-kernel@vger.kernel.org" , kevin.tang@unisoc.com, baolin.wang@unisoc.com, Chunyan Zhang Subject: Re: [PATCH V2 1/2] dt-bindings: syscon: Add syscon-names to refer to syscon easily Message-ID: <20191204192639.GA15786@bogus> References: <20191120154148.22067-1-orson.zhai@unisoc.com> <20191120154148.22067-2-orson.zhai@unisoc.com> <20191204163830.GA25135@bogus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 04, 2019 at 06:00:17PM +0100, Arnd Bergmann wrote: > On Wed, Dec 4, 2019 at 5:38 PM Rob Herring wrote: > > On Wed, Nov 20, 2019 at 11:41:47PM +0800, Orson Zhai wrote: > > > Make life easier when syscon consumer want to access multiple syscon > > > nodes with dozens of items. > > > Add syscon-names and relative properties to help to manage different > > > cases when accessing more than one syscon node even with arguments. > > > > > > Signed-off-by: Orson Zhai > > > --- > > > .../devicetree/bindings/mfd/syscon.txt | 43 +++++++++++++++++++ > > > 1 file changed, 43 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt b/Documentation/devicetree/bindings/mfd/syscon.txt > > > index 25d9e9c2fd53..4c7bdb74bb0a 100644 > > > --- a/Documentation/devicetree/bindings/mfd/syscon.txt > > > +++ b/Documentation/devicetree/bindings/mfd/syscon.txt > > > @@ -30,3 +30,46 @@ hwlock1: hwspinlock@40500000 { > > > reg = <0x40500000 0x1000>; > > > #hwlock-cells = <1>; > > > }; > > > + > > > + > > > + > > > +==Syscon Name== > > > + > > > +Syscon name is a helper to be used in consumer nodes who refer to system > > > +controller node. It provides a way to refer to syscon node by names with > > > +phandle args in syscon consumer node. It will help people who have a lot > > > +of syscon references to be managed. It is not a must feature and has no > > > +effect to syscon node itself at all. > > > + > > > +Required properties: > > > +- syscons: List of phandles and any number of arguments if needed. Arguments > > > + is specific to differnet vendors and its usage should be described at each > > > + vendor's bindings. For example: In Unisoc SoCs, the 1st arg will be treated > > > + as register address offset and the 2nd is bit mask. > > > + > > > +- syscon-names: List of syscon node name strings sorted in the same order as > > > + what it represents in property syscons. > > > + > > > +Optional property: > > > +- #.*-cells: Represents the number of arguments in single phandle in syscons > > > + list. ".*" is vendor specific. If this property is not set, default value > > > + will be 0. > > > > This breaks the normal pattern of how '#.*-cells' works. While Arnd > > suggests removing it, I don't think that works well either with having a > > generic 'syscons' property. That means every syscon in a system has to > > have the same number of cells. > > > > I don't really want to see syscon binding expanded. Really, I'd like > > 'syscon' to go away. It's nothing more than a flag to create a regmap. > > Not expanding the syscon binding is the point about not having a #*-cells: > In the examples that Orson listed, the cell count would always be > specific to the user of the syscon regmap, and not interpreted by the > syscon itself. > > > I think it is better to keep the property names specific to exactly what > > the functionality is for each syscon phandle rather than a generic > > binding. > > > > What are the eamples of where you want to use this? > > I think generally speaking this would be useful for random registers that > logically belong to one device but are grouped with other unrelated > registers in a syscon, and that are in a different register offset for > each chip that has them. Using named properties instead of a list > of phandle/arg tuples with names is clearly a simpler alternative > and more like we do it today, but I can also see some API simplification > with Orson's patch without the binding getting out of hand. I understand when a phandle to a syscon is used. That's nothing new. What's special about Unisoc SoC that needs something new/different? I saw there's a large number of syscons, but I don't understand what's in them. If the API is this: struct regmap *syscon_regmap_lookup_by_name(struct device_node *np, const char *name, int arg_count, __u32 *out_args) How is 'name' being an entry in syscon-names simpler than just being the property name? The implementation for the latter would certainly be simpler. It also makes the property unparseable without knowledge outside of the DT (i.e. in the driver). I suppose if the number of cells for each entry is fixed, we could count the number of syscon-names entries to figure out the stride. But then if one entry needs a lot of cells, then they all have to have padding cells. Rob