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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6DD32C43334 for ; Sat, 25 Jun 2022 01:21:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230013AbiFYBVU (ORCPT ); Fri, 24 Jun 2022 21:21:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44456 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229450AbiFYBVT (ORCPT ); Fri, 24 Jun 2022 21:21:19 -0400 Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com [IPv6:2001:4860:4864:20::2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A129D27B3A for ; Fri, 24 Jun 2022 18:21:18 -0700 (PDT) Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-1048b8a38bbso5963176fac.12 for ; Fri, 24 Jun 2022 18:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:user-agent:date:message-id :subject:to:cc; bh=BRJxtK7by35Zc8QH/nnvKQKs9hK/8AIEzJouUPpaTpA=; b=ipnQNOEUKRMUQtRZdBO/Uv8XHyRCyACkN75EaXH9G5TIYduaIi6Fs3ClcaZUdqHlQ/ +azX+aM5vTZ05ypVs97hsPIGZ6MeiRi0gG49Mkz0HiH4qpW09CVB+6Nr2tzBDQpHvTYT AgDl0IMUAOBERWThy7J32xiYX4nq4ZwFo2lak= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from :user-agent:date:message-id:subject:to:cc; bh=BRJxtK7by35Zc8QH/nnvKQKs9hK/8AIEzJouUPpaTpA=; b=onpZNA6dvIGGckgcZcecOCp1hAtuUpNFF8aH4eZdXTm3p7HmPIL3/oliHAq3NZootY HEKjNYJUXIAscsEpRm1g6D4JXYrT4NskdtT1ov4ZZLHZ7BuI3j+7LKsyVl9f1/bPrZth L6Vq6P3mPHsRNp/qG+cBOOOIeSPoNYuf4zNrkBJ8D8LluNHFOiWqQLRP5hOTElLSIPJS 11yFQTFaSbJbmpIUvzyg/dIlhKwhRLj39ADIgHKNlx1K804kaUa7ea8Fkw1Bx3Suk5RQ tOxKuFkUzBWY1CqTXSQTo3qYxskH20fX3/TGT93sYkeo37dSlH4LTRuXVX1pY1xYxaYc KJgw== X-Gm-Message-State: AJIora8C6R8j/NWPxr2BCU+jYh4ZpWVI+CfmGBmPGJKrCC/pFjCDGSgu BL83+m6ueplWCRFrTjaSym1CbREPWQM/ksI3QzSpsA== X-Google-Smtp-Source: AGRyM1u6/T+WcVjOW9N89LEkv92dI1MrVPLEX2x3G21Lc4IDCSUfjTNLNtnwWFOb4IiXjzG08Co3TRX9cSNHdNMmXMo= X-Received: by 2002:a05:6870:b381:b0:fe:2004:b3b5 with SMTP id w1-20020a056870b38100b000fe2004b3b5mr1223058oap.63.1656120078008; Fri, 24 Jun 2022 18:21:18 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 24 Jun 2022 18:21:17 -0700 MIME-Version: 1.0 In-Reply-To: References: <20220622173605.1168416-1-pmalani@chromium.org> <20220622173605.1168416-2-pmalani@chromium.org> From: Stephen Boyd User-Agent: alot/0.10 Date: Fri, 24 Jun 2022 18:21:17 -0700 Message-ID: Subject: Re: [PATCH v5 1/9] dt-bindings: usb: Add Type-C switch binding To: Prashant Malani Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, bleung@chromium.org, heikki.krogerus@linux.intel.com, Krzysztof Kozlowski , AngeloGioacchino Del Regno , =?UTF-8?B?TsOtY29sYXMgRiAuIFIgLiBBIC4gUHJhZG8=?= , Allen Chen , Andrzej Hajda , Daniel Vetter , David Airlie , devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, Greg Kroah-Hartman , Hsin-Yi Wang , Jernej Skrabec , Jonas Karlman , =?UTF-8?B?Sm9zw6kgRXhww7NzaXRv?= , Krzysztof Kozlowski , Laurent Pinchart , Maxime Ripard , Neil Armstrong , Pin-Yen Lin , Robert Foss , Rob Herring , Sam Ravnborg , Thomas Zimmermann , Xin Ji Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Quoting Prashant Malani (2022-06-24 14:41:36) > On Fri, Jun 24, 2022 at 12:50 PM Stephen Boyd wrote: > > > > Quoting Prashant Malani (2022-06-23 19:48:04) > > > On Thu, Jun 23, 2022 at 7:13 PM Stephen Boyd wrote: > > > > > > > > Quoting Prashant Malani (2022-06-23 17:35:38) > > > > > On Thu, Jun 23, 2022 at 4:14 PM Stephen Boyd wrote: > > > > > > > > > > > > I'm not aware of any documentation for the dos and don'ts here. Are > > > > > > there any examples in the bindings directory that split up a device into > > > > > > subnodes that isn't in bindings/mfd? > > > > > > > > > > usb-c-connector [3] and its users is an example. > > > > > > > > What are the subnodes? The graph ports? That is not what I meant. > > > > > > cros-ec-typec [4] uses subnodes of usb-c-connector. Chrome OS DTs > > > use the ports from the included usb-c-connector to switching hardware. > > > > Ok, got it. usb-c-connector nodes are children of the typec controller > > (in this case cros-ec-typec) because otherwise we would need to make a > > phandle link from the usb-c-connector node(s) under the root node / to > > the typec controller. The phandle link may need to be done in both > > directions, so it makes more sense to put the usb-c-connector nodes > > underneath the typec controller to express the direct relationship > > between the typec controller and the usb-c-connectors. > > > > Furthermore, the usb-c-connector is not integrated as part of the EC in > > the same package. There is a discrete part placed on the board that > > corresponds to the usb-c-connector and that is separate from the EC. The > > connectors are in essence only controllable through the EC because > > that's the typec controller. > > From the perspective of the AP, the `usb-c-connector` *is* an integrated part of > the Chrome EC; there is no alternative way to control it except > through the Chrome EC. > So the above example reinforces the usage model for typec-switch (which is > also an "integrated" component). No the usb-c-connector is not an integrated part of the EC. It is a discrete part with a part number that gets placed on the PCB. From the perspective of the AP it is controlled via the EC, but it is not integrated into the same package that the EC is packaged in to be soldered down to the PCB. So the example of usb-c-connector as a subnode doesn't reinforce the argument for a typec-switch binding. It highlights the difference that I've been trying to explain. The difference between internal vs. external components of a device. In the EC case the usb-c-connector is an external component from the EC, hence the two nodes. In the anx or ite case the typec switch is an internal component, hence the single node for the anx or ite part. > > This really is a limited binding change that helps describe connections > between Type-C components, helps these components integrate with > the kernel Type-C framework, and consolidates the associated properties. > I believe it works for most current use cases in the upstream kernel. > > I'm happy to discuss more theoretical use cases further, but > respectfully, I prefer to do > so off-list. I'm happy to move the discussion to the anx or ite bindings if you'd prefer to discuss more concrete bindings. > > If the maintainer is OK with it (Krzysztof has reviewed it, but I > don't want to presume > what the protocol is for patches in this subsystem), and we've > provided 2 users as asked for > in v4 [5], then I request its consideration for submission. > If the maintainers have further concerns, we'd be happy to address them. > Rob?