Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp4304541pxk; Tue, 29 Sep 2020 22:16:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwDjWr4LDtEmJAjmF9tU2ASTmDynT5AG+AXHk0RLA0Mp8NG4tLHmmql88B/tfcfvPUAGveZ X-Received: by 2002:a50:8e17:: with SMTP id 23mr861766edw.31.1601443012302; Tue, 29 Sep 2020 22:16:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601443012; cv=none; d=google.com; s=arc-20160816; b=WRR+2L5aAwbmfJqVTp/GKe62nlzs7vvS2yjORw79mPv/cuZhnc06L50qJpg/RocKmg f1QR/MvVRrPrDQZPAaQxaFRaR9sroB/WVUA77eZFz1+UEkPk1TJ+s9JmQKUYPCxkJcoX 1qaySLTIrvIqD9XJDv+T7MYbDuYpAPQcEP++deZWvvZoTOY8GwwjTyYvaI9vzkHAiCXF JxIZzfPkx7kSGOQb5mt2fkaXtd4G4ekuPnhQ/qciVPEy4pz+5/W53nKj/hyigTtY52oU z/ggB19slXfh/M14LwH9Z6fFakHNILrshs6EQyhQZOpsk46ejUZX/fFtBWFE91R1fGwt g+gg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=H3ubtL/dgJPqgwgQmmmQR/ol62Byi6UXTTb7mXVdAs0=; b=zW/BajMy7K888veYl0OEZIDNYMVz4gcwGd1x2ZcyVrq6HWyrZJb/KJOAN8DUOPEPiC uPQ0AjtwGpJPi8fUi4MPz0WA8T1qYVtTzWGucQXAGYzaFXJugL9x9CzozYDUpzINSSuG VrlQqAheFEeL7i0Z0snSnYIuSJr4PRxG4J0PNCXvK+dBMXomrd+Qhu0KcSil4gv9Mg18 GylLnlLD0pcyApffhxGITC/IZGoOK41JY0xJM1osUdtg4W5RTJDVz0DxVGgmcV6z/8jG LLLVnRDder7HYed4yGUxzZKHH+wOXOZl/Oq94mcruWicyL2AQsntpncC1LnN5AivvnZ2 pSxg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j11si313101edy.393.2020.09.29.22.16.29; Tue, 29 Sep 2020 22:16:52 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725776AbgI3FP1 (ORCPT + 99 others); Wed, 30 Sep 2020 01:15:27 -0400 Received: from muru.com ([72.249.23.125]:45674 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725320AbgI3FP1 (ORCPT ); Wed, 30 Sep 2020 01:15:27 -0400 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id D6B1580BF; Wed, 30 Sep 2020 05:15:27 +0000 (UTC) Date: Wed, 30 Sep 2020 08:15:21 +0300 From: Tony Lindgren To: Trent Piepho Cc: Drew Fustini , Rob Herring , Linus Walleij , Jason Kridner , Robert Nelson , linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-gpio , Christina Quast Subject: Re: [PATCH] ARM: dts: document pinctrl-single,pins when #pinctrl-cells = 2 Message-ID: <20200930051521.GN9471@atomide.com> References: <20200917103942.GA2477958@x1> <20200923065755.GR7101@atomide.com> <20200924054324.GB9471@atomide.com> <20200924060645.GD9471@atomide.com> <20200924070443.GF9471@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Trent Piepho [200929 20:16]: > On Thu, Sep 24, 2020 at 12:04 AM Tony Lindgren wrote: > > Certainly different compatible strings can be used as needed. > > But pinctrl-single is not going to be am335x specific though :) > > We have quite a few SoCs using it: > > So what doesn't make sense to me, is to put something am335x specific > like two cells for conf and mux, into a generic driver like pinctrl > single. Treating conf and mux separately is not am335x specific. Linux treats them separately because the conf options typically can be described in a generic way while the mux is just signal routing. Sure the conf values are currently not generic, but that could be done if wanted to and added some property to specify that the controller uses generic conf values. > This series adds two cells ORed into one. Ok, that's generic, other > platforms could use it. But it also accomplishes nothing, so what's > the point? You've hinted there is more to come, which will accomplish > something, but what is it? That can be: > Used by platforms other than am335x > Can't already be done with the pinctrl single pinconf features > Needs more than one data cell per pin For SoCs using #pinctrl-cells = <2> we now have conf and mux values separated in the dtb. Certainly that's a better place to be compared to earlier for any further pinconf changes. > Interrupt controllers have different numbers of cells, but they are > all platform specific, and the cells have defined platform specific > meanings. pci-host-cam-generic is a somewhat generic interrupt > controller and it uses 1 cell, since it lacks device specific fields > to put into additional cells. With interrupts the IRQ_TYPE flags are generic and separate from the hardware specific cells. If we wanted to, we could have something similar for pinctrl framework. > Consider also that any future changes to the pinctrl-single bindings > would need to be backward compatible with a device tree binary where > two cells get combined. So if the bindings being added here aren't > done, then adding them now creates an unnecessary additional version > to deal with for backward compatibility. I don't see issues with backward compabilty. If we specify that the controller uses #pinctrl-cells = <2>, and some additional property for specifying generic conf flags, we'd have a similar generic binding to the interrupt binding. Regards, Tony