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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 5D890C433DB for ; Mon, 1 Mar 2021 09:19:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 254B564E22 for ; Mon, 1 Mar 2021 09:19:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233841AbhCAJT6 (ORCPT ); Mon, 1 Mar 2021 04:19:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233836AbhCAJT5 (ORCPT ); Mon, 1 Mar 2021 04:19:57 -0500 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 42EA8C061756 for ; Mon, 1 Mar 2021 01:19:17 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id m22so24314550lfg.5 for ; Mon, 01 Mar 2021 01:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tACmQpZqJbPVbrp6VhKqN/6XRGZrHClEhqKE2HVBdfg=; b=opsBlPquhp9ku3v6FhnXXhIlTleSnTTbxfQEpfPjkSRwStpTRV1ptxI2WO8jE9XclJ XpTIft0pxOEWXzAzTEN1YwlodgCUpQld8M4QqLyzFU4GSAZh804fQKpQUKEGYlDiZUXH nRwM9IZfr6VqS55oLHbzTDJgPZ4DqY2FGirB7ml74lO7vavhIm/nmqRJ4Z+3dHcsK22f llXZk6W2uS5bi3sUKVoujd0nz5OECf0lhOYspbTulnQwF6r7vCM8QSjjycf5Icwjchij OmiWFE/8ZS/xfjVD6fnZ3kqHBIp5p5HDWOjFrcRHzdSHji7RmCQ0JbSNy4NtCsX3l0gV SHHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tACmQpZqJbPVbrp6VhKqN/6XRGZrHClEhqKE2HVBdfg=; b=YWGSyFd5NPBMSJrABBgWp6dNDr7wsPXEPNwppMyfzfpDfgpZFyTjpraOajbrNQrNak dp0MWmRzoEG68/avPtnjbUkDqxV7QhbihvOPDPbTyu2u8jhieLbhRF2X5t+EcyUmlCSk igbIVxOg9sT51/Pliw7csHWR3PWsu8BbSqDcKlmDq6zxX4OR4ZNJuO06L8wjIJrhb/4S OY+zh2fHKT8ro6KtD+yYUhNq70tc2n6V4IjLTH/fc9hDYbj4Z8hN4qW+Qxi4KUnhXEdz q7t4nC7SuZ00SNnv32ByZBRNjHVUPrT6staxoAUThEOQ5qYx3w+dy8/5IL0YAvUFPZJf O0Vg== X-Gm-Message-State: AOAM532XkSD/s1DhSUpwBxg5AreUY/v/zMhgfaZNSpr47WjvFLSaWgxS Yks5d5xds+lL0VeZFmU9m1tQeHeN9CNzx8StROwizsug1cY= X-Google-Smtp-Source: ABdhPJzy2r3weDzNAYM/z+Ke1adpfXf0ceGI1xwHJ3MyTdEL/jEWXBZ0VDU6pmGkYMCP2JR0G2W6HwtndcKJHQUWt/k= X-Received: by 2002:ac2:5d21:: with SMTP id i1mr8597506lfb.649.1614590355682; Mon, 01 Mar 2021 01:19:15 -0800 (PST) MIME-Version: 1.0 References: <63d610ba-5f63-2be1-6215-f44bd88d94d2@xilinx.com> In-Reply-To: <63d610ba-5f63-2be1-6215-f44bd88d94d2@xilinx.com> From: Linus Walleij Date: Mon, 1 Mar 2021 10:19:04 +0100 Message-ID: Subject: Re: DT overlay applied via pinctrl description To: Michal Simek Cc: Linux Kernel Mailing List , "open list:GPIO SUBSYSTEM" , Sai Krishna Potthuri Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Tue, Feb 16, 2021 at 4:35 PM Michal Simek wrote: > I have a question about expectations when pinctrl setting is applied. In > DTS all nodes are described in the order available in DT. > > uart-default { > mux { > ... > }; > > conf { > ... > }; > }; > > I don't know if this standard description or not. I definitely see other > pinctrl drivers which are using different structure. > > Anyway when overlay is applied the order has changed to > uart-default { > conf { > ... > }; > > mux { > ... > }; > }; > > which is causing issue because pin is configured first via conf node > before it is requested via mux. This is something what firmware is > checking and error out. As Frank says the DT ordering has no semantic meaning, it is essentially a functional language, describes object relations not sequences. The Linux kernel applies the mux and conf in that order because of how the code is implemented (this order also makes a lot of sense for the hardware). I would recommend to trace the execution of an overlay being applied and try to find the reason conf goes before mux and fix the bug there. I think it is a bug in how pinctrl handles DT overlays. Yours, Linus Walleij