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.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 92D8EC41604 for ; Tue, 6 Oct 2020 17:15:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 562D62075A for ; Tue, 6 Oct 2020 17:15:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726362AbgJFRP0 (ORCPT ); Tue, 6 Oct 2020 13:15:26 -0400 Received: from netrider.rowland.org ([192.131.102.5]:48761 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726267AbgJFRPZ (ORCPT ); Tue, 6 Oct 2020 13:15:25 -0400 Received: (qmail 424636 invoked by uid 1000); 6 Oct 2020 13:15:24 -0400 Date: Tue, 6 Oct 2020 13:15:24 -0400 From: Alan Stern To: Matthias Kaehlcke 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: <20201006171524.GB423499@rowland.harvard.edu> References: <20200930124915.GA1826870@google.com> <20201006004510.GD4135817@google.com> <20201006141820.GA416765@rowland.harvard.edu> <20201006165957.GA191572@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201006165957.GA191572@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 06, 2020 at 09:59:57AM -0700, Matthias Kaehlcke wrote: > 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. That doesn't do the user (or a program the user is running) any good. You can't expect them to go searching through the system's DT description looking for this information. All they know is the hub's location in sysfs. > > 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. You don't need a platform device or a new driver to do this. The code can go in the existing hub driver. > 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. Okay. Or you could always put it in the USB-2 hub. Incidentally, the peering information is already present in sysfs, although it is associated with a device's port on its upstream hub rather than with the device itself. Alan Stern