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=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 23C94C4727E for ; Thu, 1 Oct 2020 21:40:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CFDC0207DE for ; Thu, 1 Oct 2020 21:40:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="WTnFo6h7" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727124AbgJAVkA (ORCPT ); Thu, 1 Oct 2020 17:40:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39686 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726626AbgJAVkA (ORCPT ); Thu, 1 Oct 2020 17:40:00 -0400 Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 29DB3C0613D0 for ; Thu, 1 Oct 2020 14:40:00 -0700 (PDT) Received: by mail-pj1-x1042.google.com with SMTP id i3so72774pjz.4 for ; Thu, 01 Oct 2020 14:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ip4I9Zi92cmMy48EZDjEqPXg+PzOqP4wFP+0NOc0leE=; b=WTnFo6h7qTDLtJzYjwKVAtNU/occKNeoida7yMLlmzoxLe2fzaVVWqANDfs1zj7PTO l60FsvpvT6bTSvVsvd55fbacf4g+a/Rwpi1mLXQW40gO6w1Vl5ySDrXRBQC5+mAbKquH 2SKHIZocesnNABZLexOctr5c/hPDP6/0m1Fj0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ip4I9Zi92cmMy48EZDjEqPXg+PzOqP4wFP+0NOc0leE=; b=gG4niAtEhAytxX/+FODoaDehGAm22rSZc327oictGzVYaRvT3xESUxvuxzjwIEX6v3 uPPY3gBNEnezUux6fG+xoxLpF/HNeWDnhsDv4ug1J2YIntb7OuraWGpN/JDWb/Zk+8Ok IxyU2ezdqCaNDapLtE4P2NjgAVWbg10FY04G0de+snAg9932wjYpAhM/7hTl18W1ZeIL inkcRcSXI3f/fQ4cNE5y2Js0Y0XL+ITViSF+yijFzpEXlE6Uqwe6AB33mnnmrMGdM6jF YnJGDJ5oI1QjobAAwuaMi+17I0rRENDVQtYTfXfdT3VjOjUKc3M0Ug7UmHQl+08Smj5J U7TQ== X-Gm-Message-State: AOAM531NdM3blvUqbV/cBN75UZT+dFwOMWBX9Yc+f5ub7dSaJ7a7ckvU Shh2nioNrDGYkVLTBq3OCZvQwQ== X-Google-Smtp-Source: ABdhPJwsFXq6zSWxUWlEvb8LGWzKnUYFfTMmDFpm+t6KJ1yD7cy92p01ZXNxTyikGyl26sHg5FwE/Q== X-Received: by 2002:a17:90b:891:: with SMTP id bj17mr1876241pjb.11.1601588399703; Thu, 01 Oct 2020 14:39:59 -0700 (PDT) Received: from localhost ([2620:15c:202:1:f693:9fff:fef4:e70a]) by smtp.gmail.com with ESMTPSA id k7sm788262pjs.9.2020.10.01.14.39.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2020 14:39:58 -0700 (PDT) Date: Thu, 1 Oct 2020 14:39:57 -0700 From: Matthias Kaehlcke To: Rob Herring Cc: Doug Anderson , Alan Stern , Greg Kroah-Hartman , Frank Rowand , "linux-kernel@vger.kernel.org" , Linux USB List , Bastien Nocera , Stephen Boyd , Ravi Chandra Sadineni , Krzysztof Kozlowski , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Peter Chen Subject: Re: [PATCH v4 1/2] dt-bindings: usb: Add binding for discrete onboard USB hubs Message-ID: <20201001213957.GA2362632@google.com> References: <20200928101326.v4.1.I248292623d3d0f6a4f0c5bc58478ca3c0062b49a@changeid> <20200929201701.GA1080459@bogus> <20200929220912.GF1621304@google.com> <20200930013229.GB194665@rowland.harvard.edu> <20200930124915.GA1826870@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Wed, Sep 30, 2020 at 02:19:32PM -0500, Rob Herring wrote: > On Wed, Sep 30, 2020 at 1:00 PM Doug Anderson wrote: > > > > Hi, > > > > > On Wed, Sep 30, 2020 at 7:44 AM Rob Herring wrote: > > > > > > > > We already have hubs in DT. See [1][2][3][4]. What's new here? > > > > After I sent my response I kept thinking about this and I realized > > that I have prior art I can point out too! :-) Check out > > "smsc,usb3503a". That is describing a USB hub too and, at least on > > "exynos5250-spring.dts" is is a top level node. Since "smsc,usb3503a" > > can be optionally connected to an i2c bus too, it could be listed > > under an i2c controller as well (I believe it wasn't hooked up to i2c > > on spring). > > > > Interestingly enough, the USB Hub that Matthias is trying to add > > support for can _also_ be hooked up to i2c. We don't actually have > > i2c hooked up on our board, but conceivably it could be. Presumably, > > if i2c was hooked up, we would have no other choice but to represent > > this chip as several device tree nodes: at least one under the i2c > > controller and one (or two) under the USB controller. Just because > > (on this board) i2c isn't hooked up doesn't change the fact that there > > is some extra control logic that could be represented in its own > > device tree node. To me, this seems to give extra evidence that the > > correct way to model this device in device tree is with several nodes. > > > > I'll point out that on "exynos5250-spring.dts" we didn't have to solve > > the problem that Matthias is trying to solve here because we never > > actually supported waking up from USB devices there. Thus the > > regulator for the hub on spring can be unconditionally powered off in > > suspend. On newer boards we'd like to support waking up from USB > > devices but also to save power if no wakeup devices are plugged into > > USB. In order to achieve this we need some type of link from the > > top-level hub device to the actual USB devices that were enumerated. > > Yes, in a prior version I mentioned we already had 2 ways to describe > hubs. I view this as a 3rd way. The description of the onboard hub driver is essentially the same as that for the 'smsc,usb3503a'. Ths driver doesn't require the USB device nodes, but they could as well exist, they are only omitted most of the time because USB does discovery, some DT files include these implicit nodes though. It would be possible to rewrite the onboard_usb_hub driver in a way that it wouldn't require phandles of the 'usb_hub' (or whatever) node, and instead provide the 'usb_hub' with phandles of the USB devices. The hub would be specified exactly once: { usb_hub: usb-hub { compatible = "realtek,rts5411", "onboard-usb-hub"; usbdevs = <&usb_1_udev1>, <&usb_1_udev2>; vdd-supply = <&pp3300_hub>; }; &usb_1_dwc3 { usb_1_udev1: usb@1 { reg = <1>; }; usb_1_udev2: usb@2 { reg = <2>; }; }; } The only difference with the 'smsc,usb3503a' would be that the nodes of the (existing!) USB devices would be specified (without any custom properties). I'm not convinced that 'pre-probes' can solve the entire problem on the driver side and keep thinking that there needs to be a single non-USB instance that controls the power state, particularly for the suspend/resume case. I will provide some more details in another reply to this thread.