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.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,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 5043DC47095 for ; Sat, 3 Oct 2020 12:41:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1FF59206CD for ; Sat, 3 Oct 2020 12:41:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725816AbgJCMln (ORCPT ); Sat, 3 Oct 2020 08:41:43 -0400 Received: from netrider.rowland.org ([192.131.102.5]:56145 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1725777AbgJCMln (ORCPT ); Sat, 3 Oct 2020 08:41:43 -0400 Received: (qmail 318963 invoked by uid 1000); 3 Oct 2020 08:41:42 -0400 Date: Sat, 3 Oct 2020 08:41:42 -0400 From: Alan Stern To: Rob Herring Cc: Doug Anderson , Matthias Kaehlcke , 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: <20201003124142.GA318272@rowland.harvard.edu> References: <20200929201701.GA1080459@bogus> <20200929220912.GF1621304@google.com> <20200930013229.GB194665@rowland.harvard.edu> <20200930124915.GA1826870@google.com> <20201002183633.GA296334@rowland.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 02, 2020 at 05:58:22PM -0500, Rob Herring wrote: > On Fri, Oct 2, 2020 at 1:36 PM Alan Stern wrote: > > Regardless of how the situation is represented in DT, there remains the > > issue of where (i.e., in which driver module) the appropriate code > > belongs. This goes far beyond USB. In general, what happens when one > > sort of device normally isn't hooked up through a power regulator, so > > its driver doesn't have any code to enable a regulator, but then some > > system does exactly that? > > > > Even worse, what if the device is on a discoverable bus, so the driver > > doesn't get invoked at all until the device is discovered, but on the > > new system it can't be discovered until the regulator is enabled? > > Yep, it's the same issue here with USB, MDIO which just came up a few > weeks ago, MMC/SD which hacked around it with 'mmc-pwrseq' binding > (not something I want to duplicate) and every other discoverable bus. > What do they all have in common? The kernel's driver model being > unable to cope with this situation. We really need a common solution > here and not bus or device specific hack-arounds. To me this doesn't seem quite so much to be a weakness of the kernel's driver model. It's a platform-specific property, one that is not discoverable and therefore needs to be represented somehow in DT or ACPI or something similar. Something that says "Device A cannot operate or be discovered until power regulator B is enabled", for example. The decision to enable the power regulator at system startup would be kernel policy, not a part of the DT description. But there ought to be a standard way of recognizing which resource requirements of this sort should be handled at startup. Then there could be a special module (in the driver model core? -- that doesn't really seem appropriate) which would search through the whole DT database for resources of this kind and enable them. The case that Matthias is working on is even more complicated because he wants to add a platform-specific sysfs attribute for controlling the power resource. But I think that would be relatively easy to set up, if only we could guarantee that the power regulator would be enabled initially so that the hub can be discovered. Alan Stern