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=-4.6 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 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 8DE8DC41604 for ; Tue, 6 Oct 2020 17:00:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 349F420782 for ; Tue, 6 Oct 2020 17:00:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="TUIAHmCf" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726123AbgJFRAA (ORCPT ); Tue, 6 Oct 2020 13:00:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725925AbgJFRAA (ORCPT ); Tue, 6 Oct 2020 13:00:00 -0400 Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3AA99C061755 for ; Tue, 6 Oct 2020 10:00:00 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id d23so1505096pll.7 for ; Tue, 06 Oct 2020 10:00: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=W+OwvA2XgottYqNbj2m2Re63qow6EKIPKlH3dYZhaIo=; b=TUIAHmCfa2ApU50+62vetEj4FJKpNKzLypA4i9rbCzgaXdTbMbdRYyWxgn2IVyarya 5x3/C3Yi3bBsbRSj6p4s6lVWOVqK0vD2QiR5QLaB1SRy4DfpWziqXBRb5xHjSHOXP5Zm FQDevgm9fnFhCdpf+lBod5gAPIcXrbeV/XMlU= 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=W+OwvA2XgottYqNbj2m2Re63qow6EKIPKlH3dYZhaIo=; b=F7pkMcE4HwYUm8KcMc6JmQ+MEjQa3rDfoO9f5vQ1IifCdHZvekIO3ROddJ1VxkFwn3 N7hKeXE948gu4AcWgsFoXwrsixfhxZWcqwoTLrD8ynNHi3SPqOKHszHu9s9OkpQ4HtFl QSC4/KDbxoAou9tCImrNuGKeUDbZ+EgfsFmDTGa0AgLANHqkDuelNegK8YcSsoMt2zwK trioMBGIPH1Pf12XA6r5i6SHxacAzsrIWJqRI2wXEfVBaLozvlTqGabCjTH5CdU42kZ1 nyja3jKmGM2nyPAoKhZ5zWUya/P+lCRp/HLmhrUbiVCl5rZDr3vZUkqjieII78K1adqO IX7A== X-Gm-Message-State: AOAM533HaSN+0Q/4AZf4oqd4KukBe1YWGBK7NUYl4uF4eDAZoQcKuBQt +pVVbZ4cXyN1/c4XGj/T2I2/vg== X-Google-Smtp-Source: ABdhPJyXK9tnuldrWA9ft1+RbKXTOVvB4cSKziqBem1JndW/z49Cbi82Gcv89qsl0Sf8CbQwswqecw== X-Received: by 2002:a17:902:ab88:b029:d3:b2d3:5708 with SMTP id f8-20020a170902ab88b02900d3b2d35708mr4029517plr.70.1602003599755; Tue, 06 Oct 2020 09:59:59 -0700 (PDT) Received: from localhost ([2620:15c:202:1:f693:9fff:fef4:e70a]) by smtp.gmail.com with ESMTPSA id a11sm3332141pju.22.2020.10.06.09.59.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2020 09:59:59 -0700 (PDT) Date: Tue, 6 Oct 2020 09:59:57 -0700 From: Matthias Kaehlcke To: Alan Stern Cc: Doug Anderson , Rob Herring , 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: <20201006165957.GA191572@google.com> References: <20200930013229.GB194665@rowland.harvard.edu> <20200930124915.GA1826870@google.com> <20201006004510.GD4135817@google.com> <20201006141820.GA416765@rowland.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20201006141820.GA416765@rowland.harvard.edu> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Tue, Oct 06, 2020 at 10:18:20AM -0400, Alan Stern wrote: > On Mon, Oct 05, 2020 at 05:45:10PM -0700, Matthias Kaehlcke wrote: > > I did some prototyping, it seems a binding like this would work for > > case a) or b): > > > > &usb_1_dwc3 { > > hub_2_0: hub@1 { > > compatible = "usbbda,5411"; > > reg = <1>; > > }; > > > > hub_3_0: hub@2 { > > compatible = "usbbda,411"; > > reg = <2>; > > vdd-supply = <&pp3300_hub>; > > companion-hubs = <&hub_2_0>; > > }; > > }; > > > > It still requires specifying both hubs (which reflects the actual wiring). > > Supporting something like "reg = <1 2>" seems more complex due to the need to > > obtain the hub USB device at runtime (a DT node makes that trivial), possibly > > this could be solved by adding new APIs. > > > > In terms of implementation would I envision to keep a platform driver. This > > would keep the hubby parts out of xhci-plat (except for populating the platform > > devices), support systems with cascaded hubs and provide a device for the sysfs > > attribute. > > What will you do if a system has more than one of these power-regulated > hubs? That is, how will the user know which platform device handles the > power control for a particular hub (and vice versa)? You'd probably > have to create a pair of symlinks going back and forth in the sysfs > directories. The platform device would use the same DT node as the USB device, hence the sysfs path of the platform device could be derived from the DT. > Wouldn't it be easier to put the power-control attribute directly in the > hub's sysfs directory (or .../power subdirectory)? Not sure. In terms of implementation it would be more complex (but not rocket science either), from a userspace perspective there are pros and cons. A platform driver (or some other control instance) is needed anyway, to check the connected devices on both hubs and cut power only after the USB devices are suspended. With the sysfs attribute associated with the platform device it wouldn't even be necessary to have a separate USB driver. The platform driver would have to evaluate the sysfs attribute of the USB device(s), which can be done but is a bit odd. For a user it might be slightly simpler if they don't have to care about the existence of a platform device (but it's just a matter of knowing). The attribute must only be associated with one of the USB devices, which might be confusing, however it would be messy if each hub had an attribute. The attribute could be only associated with the 'primary hub', i.e. the one that specifies 'vdd-supply' or other attributes needed by the driver.