From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-170.mta1.migadu.com (out-170.mta1.migadu.com [95.215.58.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0D72216F8E9 for ; Tue, 28 May 2024 14:28:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716906540; cv=none; b=Oa/6X+az0OeQLFIGKbMco9dqGTPf+uMWBOK0ajlOSXV9Ba962OOL8jp1ttnoEFdllT5hP7ipouxdI7sFnvYgVgGK2L5NCBbcQ0yr5PLrfvtqDZsuwcnaMAdTTctKqjDLbeDl/uVBLHWk5zHQoLkv1h/TSX3QL2kT9Oy052uFKec= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716906540; c=relaxed/simple; bh=FClqH09kFsd0iJr0uhESR8yNfB2UKFuPfOCCTn5CTg4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kFnuGvKlIqgzDUXwJVZZ7kJQHTnieUL0KtFcRUjm3QDJ+9j1B3FM4J8AW5YrVLPojMgs1ykVjW1fjzTXGZ1POMpIzwFfVm1/eB5pBbm9sgu9JdkQyrA6P1zLPc4dqmGJ0E6Naae+WAhLaJJTddwfZXAwg9r2B8wpOdjrX9xD34k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=xpc1jwBV; arc=none smtp.client-ip=95.215.58.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="xpc1jwBV" X-Envelope-To: linus.walleij@linaro.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1716906537; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mdB+sx7IWTFnAhjbj+baTMUPxCF5GwKzeCFXC4SL+3o=; b=xpc1jwBVSkzLSfSMm7f9IyrlIQIkooum+19LabhFqqwFkbprzvbE4RSTHOBJ2maohRR1P/ QAZTmxoKaissSwhvHa5u+7QppSJbIogAtvgmSW0LUlOpg34hn9Nhx/FoYy1dbXzmFVtw0+ JIckkiL1APVFja1ma8Is89ZN/cfA0Pc= X-Envelope-To: michal.simek@amd.com X-Envelope-To: linux-gpio@vger.kernel.org X-Envelope-To: sai.krishna.potthuri@amd.com X-Envelope-To: linux-kernel@vger.kernel.org X-Envelope-To: linux-arm-kernel@lists.infradead.org X-Envelope-To: conor+dt@kernel.org X-Envelope-To: krzk+dt@kernel.org X-Envelope-To: robh@kernel.org X-Envelope-To: devicetree@vger.kernel.org Message-ID: <51d984f5-896e-469f-914d-2c902be91748@linux.dev> Date: Tue, 28 May 2024 10:28:51 -0400 Precedence: bulk X-Mailing-List: linux-gpio@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 0/2] pinctrl: zynqmp: Support muxing individual pins To: Linus Walleij Cc: Michal Simek , linux-gpio@vger.kernel.org, Krishna Potthuri , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Conor Dooley , Krzysztof Kozlowski , Rob Herring , devicetree@vger.kernel.org References: <20240503162217.1999467-1-sean.anderson@linux.dev> <06a4e5fd-3d26-4923-bcbf-0bdd66d756c4@linux.dev> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Sean Anderson In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 5/27/24 09:15, Linus Walleij wrote: > On Mon, May 6, 2024 at 4:45 PM Sean Anderson wrote: > >> > Then we realize that not everyone need all the modem >> > control signals provided. What to do. Well this: >> > >> > uart0_rxtx_grp = pin_rx, pin_tx: >> > uart0_modem_grp = pin_cts, pin_dts, pin_dcd; >> > >> > mux0: >> > function = "uart0"; >> > groups = "uart0_rxtx_grp"; >> > >> > Now the CTS, DTS, DCD pins can be reused for something >> > else such as GPIO. >> > >> > I *know* that this breaks ABI: the driver group definitions change >> > and the device tree needs to be changed too. > > Actually I didn't think that over, it is possible to add new groups > and retain the old ones. > > I.e. retain uart0_grp, but additionally add and use > uart0_rxtx and uart0_modem_grp and use one or the > other approach. That is what this patch does. >> Well, the pin groups are actually defined in the PMU firmware. > > Is that firmware written in such an helpful way that the groups > can be extracted from the firmware then, as with SCMI? Or is it > a matter of duplicating the info from the PMU in the software-defined > groups. Fundamentally, the pin muxings are known a priori from the reference manual. Because pinmuxing itself has been delegated to the PMU firmware, we defer to it when determining what muxings are available. The PMU firmware describes muxings in terms of pins and functions; groups are a Linux-only concept. >> And >> frankly, I don't see the point of pin "groups" when there are not actual >> pin groups at the hardware level. The pins can all be muxed >> individually, so there's no point in adding artificial groups on top. >> Just mux the pins like the hardware allows and everything is easy. Cuts >> down on the absurd number of strings too. > > So are you going to switch all of Xilinx devicetrees over to using exclusively > the new method (muxing individual pins)? No. We have to support it anyway for compatibility, so there is no point in changing everything for no reason. > I'm fine with one (string identified groups) which I encourage, but I > let individual pin control pass as well on several occasions. > > What I don't want to see is a Franken-solution that mixes the two > approaches, even less so on the same system. Someone is going to > have to maintain the resulting mess. And this looks like exactly that. Well, perhaps you should have reviewed the original driver more closely. > If you want to mux individual pins instead of groups and functions, by > all means, but please do not mix the two approaches in the same > driver, I'm just trying to save Xilinx from themselves here. I see no point in creating thousands of groups for every combination of pin muxings when we could just switch to the solution in this (or v2 of) patch. For compatibility we cannot be rid of the old situation, but we can at least fix it. There is no technical problem with them coexisting. --Sean From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 27A3EC25B78 for ; Tue, 28 May 2024 14:29:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Uwlsb+ZYZgrn9cPOAqTrlnVhCmTcYYMag3aMmjA9VHQ=; b=Dy7AnrRMGRrCHh 8AigXTZ0bwZUu/+S4pNh/pqfATbU+3XJ5nSDU7gTS0jGmIGr+1w9M6DO6+/77rk2tOr7XeoYzznQc dltqKqqUKE86UE29qQL1Nhip31HpXk3QHjbw84xDiQvJ6/N3V/dHsTOPvKWV2yliUywZ+2NHslI83 cbZQS7J+VCl8j79RWoY7BioL/ixBoaOJ7vKAoai9HWe7HVkLJGuI60vue1tUvoYDOUqjxC3BQb4So 4ZvX3KbQM6x5T6Ay8FR7pcOcgJRASWdhUQuhLE2Ylkn/eeMYsdM8i2uO/3MawrHjRdr+uCr4ZYboQ x5Gmm0c9fRwLkedJVJIg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sBxp8-000000011jf-0or7; Tue, 28 May 2024 14:29:10 +0000 Received: from out-183.mta1.migadu.com ([95.215.58.183]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sBxp5-000000011iB-0MwY for linux-arm-kernel@lists.infradead.org; Tue, 28 May 2024 14:29:09 +0000 X-Envelope-To: linus.walleij@linaro.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1716906537; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mdB+sx7IWTFnAhjbj+baTMUPxCF5GwKzeCFXC4SL+3o=; b=xpc1jwBVSkzLSfSMm7f9IyrlIQIkooum+19LabhFqqwFkbprzvbE4RSTHOBJ2maohRR1P/ QAZTmxoKaissSwhvHa5u+7QppSJbIogAtvgmSW0LUlOpg34hn9Nhx/FoYy1dbXzmFVtw0+ JIckkiL1APVFja1ma8Is89ZN/cfA0Pc= X-Envelope-To: michal.simek@amd.com X-Envelope-To: linux-gpio@vger.kernel.org X-Envelope-To: sai.krishna.potthuri@amd.com X-Envelope-To: linux-kernel@vger.kernel.org X-Envelope-To: linux-arm-kernel@lists.infradead.org X-Envelope-To: conor+dt@kernel.org X-Envelope-To: krzk+dt@kernel.org X-Envelope-To: robh@kernel.org X-Envelope-To: devicetree@vger.kernel.org Message-ID: <51d984f5-896e-469f-914d-2c902be91748@linux.dev> Date: Tue, 28 May 2024 10:28:51 -0400 MIME-Version: 1.0 Subject: Re: [PATCH 0/2] pinctrl: zynqmp: Support muxing individual pins To: Linus Walleij Cc: Michal Simek , linux-gpio@vger.kernel.org, Krishna Potthuri , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Conor Dooley , Krzysztof Kozlowski , Rob Herring , devicetree@vger.kernel.org References: <20240503162217.1999467-1-sean.anderson@linux.dev> <06a4e5fd-3d26-4923-bcbf-0bdd66d756c4@linux.dev> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Sean Anderson In-Reply-To: X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240528_072907_294925_9918396C X-CRM114-Status: GOOD ( 29.87 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gNS8yNy8yNCAwOToxNSwgTGludXMgV2FsbGVpaiB3cm90ZToKPiBPbiBNb24sIE1heSA2LCAy MDI0IGF0IDQ6NDXigK9QTSBTZWFuIEFuZGVyc29uIDxzZWFuLmFuZGVyc29uQGxpbnV4LmRldj4g d3JvdGU6Cj4gCj4+ID4gVGhlbiB3ZSByZWFsaXplIHRoYXQgbm90IGV2ZXJ5b25lIG5lZWQgYWxs IHRoZSBtb2RlbQo+PiA+IGNvbnRyb2wgc2lnbmFscyBwcm92aWRlZC4gV2hhdCB0byBkby4gV2Vs bCB0aGlzOgo+PiA+Cj4+ID4gdWFydDBfcnh0eF9ncnAgPSBwaW5fcngsIHBpbl90eDoKPj4gPiB1 YXJ0MF9tb2RlbV9ncnAgPSBwaW5fY3RzLCBwaW5fZHRzLCBwaW5fZGNkOwo+PiA+Cj4+ID4gbXV4 MDoKPj4gPiAgICAgZnVuY3Rpb24gPSAidWFydDAiOwo+PiA+ICAgICBncm91cHMgPSAidWFydDBf cnh0eF9ncnAiOwo+PiA+Cj4+ID4gTm93IHRoZSBDVFMsIERUUywgRENEIHBpbnMgY2FuIGJlIHJl dXNlZCBmb3Igc29tZXRoaW5nCj4+ID4gZWxzZSBzdWNoIGFzIEdQSU8uCj4+ID4KPj4gPiBJICpr bm93KiB0aGF0IHRoaXMgYnJlYWtzIEFCSTogdGhlIGRyaXZlciBncm91cCBkZWZpbml0aW9ucyBj aGFuZ2UKPj4gPiBhbmQgdGhlIGRldmljZSB0cmVlIG5lZWRzIHRvIGJlIGNoYW5nZWQgdG9vLgo+ IAo+IEFjdHVhbGx5IEkgZGlkbid0IHRoaW5rIHRoYXQgb3ZlciwgaXQgaXMgcG9zc2libGUgdG8g YWRkIG5ldyBncm91cHMKPiBhbmQgcmV0YWluIHRoZSBvbGQgb25lcy4KPiAKPiBJLmUuIHJldGFp biB1YXJ0MF9ncnAsIGJ1dCBhZGRpdGlvbmFsbHkgYWRkIGFuZCB1c2UKPiB1YXJ0MF9yeHR4IGFu ZCB1YXJ0MF9tb2RlbV9ncnAgYW5kIHVzZSBvbmUgb3IgdGhlCj4gb3RoZXIgYXBwcm9hY2guCgpU aGF0IGlzIHdoYXQgdGhpcyBwYXRjaCBkb2VzLgoKPj4gV2VsbCwgdGhlIHBpbiBncm91cHMgYXJl IGFjdHVhbGx5IGRlZmluZWQgaW4gdGhlIFBNVSBmaXJtd2FyZS4KPiAKPiBJcyB0aGF0IGZpcm13 YXJlIHdyaXR0ZW4gaW4gc3VjaCBhbiBoZWxwZnVsIHdheSB0aGF0IHRoZSBncm91cHMKPiBjYW4g YmUgZXh0cmFjdGVkIGZyb20gdGhlIGZpcm13YXJlIHRoZW4sIGFzIHdpdGggU0NNST8gT3IgaXMg aXQKPiBhIG1hdHRlciBvZiBkdXBsaWNhdGluZyB0aGUgaW5mbyBmcm9tIHRoZSBQTVUgaW4gdGhl IHNvZnR3YXJlLWRlZmluZWQKPiBncm91cHMuCgpGdW5kYW1lbnRhbGx5LCB0aGUgcGluIG11eGlu Z3MgYXJlIGtub3duIGEgcHJpb3JpIGZyb20gdGhlIHJlZmVyZW5jZQptYW51YWwuIEJlY2F1c2Ug cGlubXV4aW5nIGl0c2VsZiBoYXMgYmVlbiBkZWxlZ2F0ZWQgdG8gdGhlIFBNVSBmaXJtd2FyZSwK d2UgZGVmZXIgdG8gaXQgd2hlbiBkZXRlcm1pbmluZyB3aGF0IG11eGluZ3MgYXJlIGF2YWlsYWJs ZS4gVGhlIFBNVQpmaXJtd2FyZSBkZXNjcmliZXMgbXV4aW5ncyBpbiB0ZXJtcyBvZiBwaW5zIGFu ZCBmdW5jdGlvbnM7IGdyb3VwcyBhcmUgYQpMaW51eC1vbmx5IGNvbmNlcHQuCgo+PiBBbmQKPj4g ZnJhbmtseSwgSSBkb24ndCBzZWUgdGhlIHBvaW50IG9mIHBpbiAiZ3JvdXBzIiB3aGVuIHRoZXJl IGFyZSBub3QgYWN0dWFsCj4+IHBpbiBncm91cHMgYXQgdGhlIGhhcmR3YXJlIGxldmVsLiBUaGUg cGlucyBjYW4gYWxsIGJlIG11eGVkCj4+IGluZGl2aWR1YWxseSwgc28gdGhlcmUncyBubyBwb2lu dCBpbiBhZGRpbmcgYXJ0aWZpY2lhbCBncm91cHMgb24gdG9wLgo+PiBKdXN0IG11eCB0aGUgcGlu cyBsaWtlIHRoZSBoYXJkd2FyZSBhbGxvd3MgYW5kIGV2ZXJ5dGhpbmcgaXMgZWFzeS4gQ3V0cwo+ PiBkb3duIG9uIHRoZSBhYnN1cmQgbnVtYmVyIG9mIHN0cmluZ3MgdG9vLgo+IAo+IFNvIGFyZSB5 b3UgZ29pbmcgdG8gc3dpdGNoIGFsbCBvZiBYaWxpbnggZGV2aWNldHJlZXMgb3ZlciB0byB1c2lu ZyBleGNsdXNpdmVseQo+IHRoZSBuZXcgbWV0aG9kIChtdXhpbmcgaW5kaXZpZHVhbCBwaW5zKT8K Ck5vLiBXZSBoYXZlIHRvIHN1cHBvcnQgaXQgYW55d2F5IGZvciBjb21wYXRpYmlsaXR5LCBzbyB0 aGVyZSBpcyBubyBwb2ludAppbiBjaGFuZ2luZyBldmVyeXRoaW5nIGZvciBubyByZWFzb24uCgo+ IEknbSBmaW5lIHdpdGggb25lIChzdHJpbmcgaWRlbnRpZmllZCBncm91cHMpIHdoaWNoIEkgZW5j b3VyYWdlLCBidXQgSQo+IGxldCBpbmRpdmlkdWFsIHBpbiBjb250cm9sIHBhc3MgYXMgd2VsbCBv biBzZXZlcmFsIG9jY2FzaW9ucy4KPiAKPiBXaGF0IEkgZG9uJ3Qgd2FudCB0byBzZWUgaXMgYSBG cmFua2VuLXNvbHV0aW9uIHRoYXQgbWl4ZXMgdGhlIHR3bwo+IGFwcHJvYWNoZXMsIGV2ZW4gbGVz cyBzbyBvbiB0aGUgc2FtZSBzeXN0ZW0uIFNvbWVvbmUgaXMgZ29pbmcgdG8KPiBoYXZlIHRvIG1h aW50YWluIHRoZSByZXN1bHRpbmcgbWVzcy4gQW5kIHRoaXMgbG9va3MgbGlrZSBleGFjdGx5IHRo YXQuCgpXZWxsLCBwZXJoYXBzIHlvdSBzaG91bGQgaGF2ZSByZXZpZXdlZCB0aGUgb3JpZ2luYWwg ZHJpdmVyIG1vcmUKY2xvc2VseS4KCj4gSWYgeW91IHdhbnQgdG8gbXV4IGluZGl2aWR1YWwgcGlu cyBpbnN0ZWFkIG9mIGdyb3VwcyBhbmQgZnVuY3Rpb25zLCBieQo+IGFsbCBtZWFucywgYnV0IHBs ZWFzZSBkbyBub3QgbWl4IHRoZSB0d28gYXBwcm9hY2hlcyBpbiB0aGUgc2FtZQo+IGRyaXZlciwg SSdtIGp1c3QgdHJ5aW5nIHRvIHNhdmUgWGlsaW54IGZyb20gdGhlbXNlbHZlcyBoZXJlLgoKSSBz ZWUgbm8gcG9pbnQgaW4gY3JlYXRpbmcgdGhvdXNhbmRzIG9mIGdyb3VwcyBmb3IgZXZlcnkgY29t YmluYXRpb24gb2YKcGluIG11eGluZ3Mgd2hlbiB3ZSBjb3VsZCBqdXN0IHN3aXRjaCB0byB0aGUg c29sdXRpb24gaW4gdGhpcyAob3IgdjIgb2YpCnBhdGNoLiBGb3IgY29tcGF0aWJpbGl0eSB3ZSBj YW5ub3QgYmUgcmlkIG9mIHRoZSBvbGQgc2l0dWF0aW9uLCBidXQgd2UKY2FuIGF0IGxlYXN0IGZp eCBpdC4gVGhlcmUgaXMgbm8gdGVjaG5pY2FsIHByb2JsZW0gd2l0aCB0aGVtIGNvZXhpc3Rpbmcu CgotLVNlYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5m cmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xp bnV4LWFybS1rZXJuZWwK