Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp42939pxu; Tue, 6 Oct 2020 18:10:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzl5hQnEp1Anj/4Jh9oGW+kuuUdNLh1+W20bSfuYfHebK8UL0LVF7d+afmHqkVXv4dKPj2C X-Received: by 2002:a17:906:3ca2:: with SMTP id b2mr825246ejh.460.1602033017351; Tue, 06 Oct 2020 18:10:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602033017; cv=none; d=google.com; s=arc-20160816; b=Mo/LEFVgkzS7D7NzIFIi4BOnD2xuTHglDugfWc1vApoV1RvWMk9UuUSc1ksI5MiwVa 6ShGOnC8wle9rsCJxkqBaPRTRINmzlP5GuiXtR+Ywpwn0/VdHz5sFiPSNlnnkDc4ueic IbtXqsFPMeF2RJsdnpoCHA21GsKbkA6LbFTQPdJ5LhF/56pvgkHKU1PxeXHSY71GxBPb RfWDW9pM81dimnUSC7RVO+ZDekEMcNAJ3MyMMY+nG4Yi9RiyTOPkYUB8qG6f/u6KLdS4 ODVyQLbNd8vTLsuBAVGoQ185KsoNnrnr/FaBK3TxgL/MguiYi/BS2iLbNwOL0R23SS8U NmPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=+ELPe9V41L0MM6p9KdoYqCNg8Mn7brzMYOnZH4mkITg=; b=Eox8VZjqF/hHOTKAz4Aphz7xyv/45DGkZVC8njARfyIIwlNiwnqvml2IG4/s1FQfh0 YnV2BYQDmAWYeRB2NfIe7aEdoH7x0NlDOCJPW/Ae/iIm79I7D/H7+jz0GwA1oISCmp5D VHTMfiurdLSOAxthhfbyIDgCBCx5qj6Ymr9i6Oj5cPJAStTN2qDY+Y2otwWzvpHNwWQJ hFvNxm/QQoXZjQNnsDvyYaQRN8vPO5ty/jSNjLEyGjWikP12R5JApgpkFr/nPv3agsdj zE5wUfcNpgqs/maNW534ZijxWEKpVkfldXICzn4rzs0kHk0hGRzYioFIep8Jh8IZZhVQ QYmw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b11si427502ejz.700.2020.10.06.18.09.55; Tue, 06 Oct 2020 18:10:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726919AbgJGBAZ (ORCPT + 99 others); Tue, 6 Oct 2020 21:00:25 -0400 Received: from netrider.rowland.org ([192.131.102.5]:55839 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726860AbgJGBAY (ORCPT ); Tue, 6 Oct 2020 21:00:24 -0400 Received: (qmail 438874 invoked by uid 1000); 6 Oct 2020 21:00:23 -0400 Date: Tue, 6 Oct 2020 21:00:23 -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: <20201007010023.GA438733@rowland.harvard.edu> References: <20201006004510.GD4135817@google.com> <20201006141820.GA416765@rowland.harvard.edu> <20201006165957.GA191572@google.com> <20201006171524.GB423499@rowland.harvard.edu> <20201006192536.GB191572@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201006192536.GB191572@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 12:25:36PM -0700, Matthias Kaehlcke wrote: > On Tue, Oct 06, 2020 at 01:15:24PM -0400, Alan Stern wrote: > > You don't need a platform device or a new driver to do this. The code > > can go in the existing hub driver. > > Maybe. IIUC currently USB drivers don't support/use suspend_late. Could that > be added? It would simplify matters, otherwise all hubs need to know their > peers and check in suspend if they are the last hub standing, only then the > power can be switched off. It would be simpler if a single instance (e.g. the > hub with the DT entries) is in control. Adding suspend_late would be a little painful. But you don't really need it; you just need to make the "master" hub wait for its peer to suspend, which is easy to do. And hubs would need to know their peers in any case, because you have to check if any devices attached to the peer have wakeup enabled. > > 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. > > That might also help the hub driver to determine its peers without needing the > 'companion-hubs' property. It wouldn't hurt to have that property anyway. The determination of peer ports doesn't always work right, because it depends on information provided by the firmware and that information isn't always correct. Alan Stern