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 X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5115EC433E0 for ; Mon, 15 Mar 2021 16:10:51 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E1B6F64E0C for ; Mon, 15 Mar 2021 16:10:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E1B6F64E0C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=utk/s1wjlyA3JULpVRQ1LNRLmyfyrPw/za8YX4VEiNQ=; b=cEN/OkwEZllU7svlUDWU6+eF7 CktrSaG9L9dYzTY2+UTdS3yfLx4FqRexlcEJri7TaNixmQwvXHBhBKkmbN3oO0+8fQAoIAVLqzFwN wimrdiLvz4dUVZEgz60HkPl7Tsh1QWp5A2UPf8o4LRyTiH4Swa602ICfGz0QM3iWAbWYNBB7pY7L2 G8NcSw5/N9/RfnlAFudzoQGbmql+jAiSwh5CDTKmvCpjne/sJbByMBq8pOZZfKcrkICM2h6sk/+tK /Z+yF7eHf7dYOnYXkJTOj2BK7r8g0LVv9qRTXrxmGdnMBwHGSm4qM2iTL7iQvVzEa2EhMMNsTlGIC HG8H2EENA==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lLpmE-00GK2k-JQ; Mon, 15 Mar 2021 16:09:06 +0000 Received: from mail-out.m-online.net ([2001:a60:0:28:0:1:25:1]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lLpm8-00GK1p-2O for linux-arm-kernel@lists.infradead.org; Mon, 15 Mar 2021 16:09:02 +0000 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4DzhDp2f9Hz1s0CD; Mon, 15 Mar 2021 17:08:58 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4DzhDp1KRPz1qqkT; Mon, 15 Mar 2021 17:08:58 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id TYWZ9wWsrO-H; Mon, 15 Mar 2021 17:08:56 +0100 (CET) X-Auth-Info: H1HQvUVis0A8yzgMAJBGUa5JREK6fjIxg2KuYp9qcRc= Received: from [127.0.0.1] (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Mon, 15 Mar 2021 17:08:56 +0100 (CET) Subject: Re: [Linux-stm32] [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96 To: Ahmad Fatoum , Christoph Niedermaier , "linux-arm-kernel@lists.infradead.org" , "linus.walleij@linaro.org" Cc: Maxime Coquelin , "linux-stm32@st-md-mailman.stormreply.com" , Alexandre Torgue , Patrick Delaunay , Patrice Chotard , Frank Rowand References: <20200724101610.146403-1-marex@denx.de> <495b2f6b-04b7-c1eb-7aed-cd55636bef46@denx.de> <4530980295044f8ab9c1cfe14e02f90f@dh-electronics.com> <6616e8b0-2b7d-a157-c24f-0493ce03c45b@denx.de> <86beeb51e9594b14ac0f449495b46736@dh-electronics.com> <7504da89-63a7-1b80-3159-a0346535137e@denx.de> <788d7d182b13448c8afc4b99518daa34@dh-electronics.com> <34769f70-c7e2-984c-fd86-b82aaf38ba57@denx.de> <42dad6a8-9a68-360f-3308-11194d256900@pengutronix.de> From: Marek Vasut Message-ID: <92c2c718-ab60-9938-80e6-8c5c950f4e71@denx.de> Date: Mon, 15 Mar 2021 17:08:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <42dad6a8-9a68-360f-3308-11194d256900@pengutronix.de> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210315_160900_544868_7E5134CD X-CRM114-Status: GOOD ( 21.05 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 3/15/21 4:05 PM, Ahmad Fatoum wrote: > Hello, > > On 15.03.21 15:29, Marek Vasut wrote: >> On 3/15/21 1:05 PM, Ahmad Fatoum wrote: >>> On 15.03.21 12:41, Christoph Niedermaier wrote: >>>>> So I'll pose another question here to the GPIO maintainers. >>>>> >>>>> Is it OK to define gpio-line-names in SoM DTSI even for pins which will >>>>> not be used as GPIOs e.g. because they are muxed differently in the >>>>> carrier board DTS ? >>>>> >>>>> If that is OK, then the above approach is then also OK. >>>> >>>> In our case, we cannot mux the GPIO pins in the carrier board DTS >>>> to another functions, because then we break our SOM standard (DHCOM). >>>> So in the case we relabel a GPIO in the carrier board e.g. "DHCOM-I" >>>> becomes "LED1" the mux function have to be GPIO. >>> >>> For standards like SMARC, where the interface is predefined, I think it makes >>> much sense to have the SoM dtsi contain not only the line-names, but also >>> ready-to-use, pinmuxing settings. >>> >>> Base boards can then either enable peripherals with just a status = "okay" >>> if they follow the standard or just override it if they choose to do >>> stuff differently. >> >> Sadly, I think I have to remind you of the discussion around pinctrl groups we have in stm32mp15-pinctrl.dtsi and how that does not scale. This is a very similar situation here, since the SoM is rather universal. > > I don't think this is directly comparable. A SoC has _lots_ of possible way to mux and > conf pads. A SMARC, AFAIU, has exactly one official pinout. That one you can add into > the dtsi and the bast board either extends that or overrides it if it diverges. That's not the case here. >> And the other thing I would like to point out here are the discussions around DT connector. What you described above is exactly that, except the implementation is still not finished. Let's CC Frank. > Thanks for the pointer. I'll check it out. Sure _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel