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 E593AC433DB for ; Mon, 15 Mar 2021 15:58:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BC4A064ED2 for ; Mon, 15 Mar 2021 15:58:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230409AbhCOP5z (ORCPT ); Mon, 15 Mar 2021 11:57:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42068 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232366AbhCOP5q (ORCPT ); Mon, 15 Mar 2021 11:57:46 -0400 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD278C06174A for ; Mon, 15 Mar 2021 08:57:45 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id e7so57713673lft.2 for ; Mon, 15 Mar 2021 08:57:45 -0700 (PDT) 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=Y05LxKqxHARRJz9b41KUmPJQO8MgmeiKWNfuMrL5SJk=; b=sg+CBQyG0EjOu0RLfrShAXMw/eoMGUCyFdU3ApyPzUZVu1ZoUxTbmz/aGui6ivYpXH kvuF8su3Y4ap3MPR3845uPRC9oASkjOYntE5efRPKCwArsq1lC02nJEyQpC/3isyQgr0 5tgBmSz/41MgYy+cPQB6z1GWEv5ltp+lMmGj6QMmJVJSPFnV3y8IY4S8hdJkMEHccjD0 KxLbqpfobp9IGnahjh1O/qkoqsimBu61rQWnWo4iHOPmxfk0QgyQVD81jDbdUHJRqKHN Sbv0uJJnNq0QyR6kR93rH6ylHh6X//AGKnrCt3UTJuSffK7yNbT1xQ0FBT/p997oWOFF o+qA== 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=Y05LxKqxHARRJz9b41KUmPJQO8MgmeiKWNfuMrL5SJk=; b=UIyA6TFHdLtw/8x/FdVy48JHVxYwCMncirzCG+jFfIYMZnQ+xtKUmlEZVBT3+eXOA3 ZL6sEDQG19Kjvdz66Cm9I48nV5S6Koxy6xZlInBceoZp5FOtrVDhx5obSsINghnlMbHZ oZIdiFHWZbtjvA/ZbTG0ewfOVlrGDkA2agKswDoxr2K3lXvldOFW/nw7F1kr0c3i8Udh U5jAqx/i67vpnyL8iJONri85gDTBKn/94odkpZ2YxnlBwYoAnwPq7OBBU2adIRQKmqrV Hk/p2YTGJ3WW4ol9sWKNnHcQMBu1aJGf0fiUBu/Ij5pViWo4K7CXlRtjsuDfaReeDk2H lunQ== X-Gm-Message-State: AOAM530PKwsb22pNcvEW6xvYUZfevaGs/FVYM8MlNmRMJypt4D1lyzLx fHi0DmYIyRYCbHZqjqn40YPW082i7kMmkeLLSgFhUQ== X-Google-Smtp-Source: ABdhPJxRhR8dLQ9brlpYFBH8NsT25ShjMtXNo8KXS6U7zOznqlJQR3PVgtOqbNDaDQFjsxiQnxKHDxYzuKLrzXEmuS8= X-Received: by 2002:a05:6512:74a:: with SMTP id c10mr8496071lfs.586.1615823864353; Mon, 15 Mar 2021 08:57:44 -0700 (PDT) MIME-Version: 1.0 References: <20210310125504.31886-1-noltari@gmail.com> <20210310125504.31886-5-noltari@gmail.com> <693A763C-14D1-47A2-A87E-2358E69DC993@gmail.com> <90994df6-9d7d-686f-8668-a1cf5267aa16@gmail.com> In-Reply-To: From: Linus Walleij Date: Mon, 15 Mar 2021 16:57:33 +0100 Message-ID: Subject: Re: [PATCH v6 04/15] dt-bindings: add BCM6328 pincontroller binding documentation To: Rob Herring Cc: =?UTF-8?B?w4FsdmFybyBGZXJuw6FuZGV6IFJvamFz?= , Michael Walle , Bartosz Golaszewski , Florian Fainelli , "maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE" , Jonas Gorski , Necip Fazil Yildiran , Andy Shevchenko , "open list:GPIO SUBSYSTEM" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "linux-kernel@vger.kernel.org" , linux-arm-kernel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 11, 2021 at 7:14 PM Rob Herring wrote: > > Or this way (2): > > syscon { > > compatible = "brcm,bcm6328-gpio-regs", "syscon", "simple-mfd"; > > reg = <0x10000080 0x80>; > > ranges = <0 0x10000080 0x80>; > > > > pinctrl: pinctrl@18 { > > compatible = "brcm,bcm6328-pinctrl"; > > reg = <0x0 0x28>; > > > > gpio: gpio@0 { > > This doesn't make sense IMO because GPIO is not a sub-function of the > pinctrl h/w. They are peers. This becomes an ontological discussion, as in "what does the world consist of and what are the proper definitions of the things in it". A couple of years back I had this presentation: https://dflund.se/~triad/papers/pincontrol.pdf where I try to investigate how hardware engineers build these blocks. TL;DR: it depends on what the hardware engineer did. A HW block can be pin controller, GPIO controller and interrupt chip at the same time, that case is straight-forward. One compatible, lots of properties. . A second case is when the pin controller and the GPIO+irqchip are two completely different HW entities, and then they also get two different device nodes on the same level in the device tree. (We usually see this when the different blocks live in totally different memory locations.) However in the third case HW can also be bolted with a front-end pin controller (facing the pins) with several GPIO+interrupt controller back-ends. Then it gets the structure in this patch, subnodes for each GPIO controller. Our current bindings have all three examples and it simply reflects the different ways HW engineers have chosen to integrate their stuff. Yours, Linus Walleij