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,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 85413C4363A for ; Mon, 5 Oct 2020 23:29:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 407A6206B5 for ; Mon, 5 Oct 2020 23:29:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="S3+AkSBW" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727031AbgJEX3Y (ORCPT ); Mon, 5 Oct 2020 19:29:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38198 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726841AbgJEX3X (ORCPT ); Mon, 5 Oct 2020 19:29:23 -0400 Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C0927C0613A8 for ; Mon, 5 Oct 2020 16:29:23 -0700 (PDT) Received: by mail-pg1-x541.google.com with SMTP id h6so6249648pgk.4 for ; Mon, 05 Oct 2020 16:29:23 -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=LDiL+GXcnPC606XYr7MZfMGhMR75HAM4qMR2Sb0HfTA=; b=S3+AkSBWwtsQFNLy3uqVSP4lipkdUBVRg1fZvuI5ASskDWc2bz8zQcXURV/gyyVd2i vCCJ0EkMb4ZYUbTCpoPqKRx371Np+eC+HrxiMq7wW4K1kmXE0czvamT2Y1iSPvlqtZgk 79ARQ2WII4davW3ztGI790WmwW24Xb6hWeYug= 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=LDiL+GXcnPC606XYr7MZfMGhMR75HAM4qMR2Sb0HfTA=; b=sUyYnD/uj9EFsf9a+AKAMgTr/1GTzW7EDR/D+RCMikSkbMn669SfNzP0IbfjsWUiqY Rm/gcvAwYIprwrq8z3DiCYgO0T73ktyp5N2FfMky5YYoaPJrt4RmVyLwIE4x7D517zwL KLqMYQV2Z0X7QW4y7KnSWQ+u/mqosZblAsuNKPr67tqTyrgdM7DPkZ3W9Klhq9YxdduO 9x5lAUSnHp96iTjkQiVQ9m/CJoEyR7IJ0xVfGTKyXOE+9uTH0qT9ZteTd8NvDYxTU8L3 OAAy9wKtpYiFUfWTxp6uWtH51UTMmDtgK4bIOmnsSVOZjbU6xE7eGzcm/WZuJd1Eb+4c O9ZA== X-Gm-Message-State: AOAM530zRmDSFKfZQ7NxSyaabv/SoscHtWAzoATd9hk9V5rNmrV4Q7Q2 UNwozB6I5jc2A2gI3y9X+Gi0gQ== X-Google-Smtp-Source: ABdhPJyHXUS9zry6LcXRyAaCbYLpYGpFNBPTbVuTG6k/SbIPOaAgrcWVQ8ab7Gkxqq+liezZAWv4XQ== X-Received: by 2002:aa7:9823:0:b029:150:a96f:c8b7 with SMTP id q3-20020aa798230000b0290150a96fc8b7mr1883651pfl.34.1601940563110; Mon, 05 Oct 2020 16:29:23 -0700 (PDT) Received: from localhost ([2620:15c:202:1:f693:9fff:fef4:e70a]) by smtp.gmail.com with ESMTPSA id y16sm1105109pfb.154.2020.10.05.16.29.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Oct 2020 16:29:22 -0700 (PDT) Date: Mon, 5 Oct 2020 16:29:21 -0700 From: Matthias Kaehlcke To: Rob Herring Cc: Alan Stern , Doug Anderson , 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: <20201005232921.GC4135817@google.com> References: <20201002183633.GA296334@rowland.harvard.edu> <20201003124142.GA318272@rowland.harvard.edu> <20201005160655.GA4135817@google.com> <20201005161527.GI376584@rowland.harvard.edu> <20201005191812.GB4135817@google.com> <20201005193611.GA389867@rowland.harvard.edu> 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 Mon, Oct 05, 2020 at 02:59:04PM -0500, Rob Herring wrote: > On Mon, Oct 5, 2020 at 2:36 PM Alan Stern wrote: > > > > On Mon, Oct 05, 2020 at 12:18:12PM -0700, Matthias Kaehlcke wrote: > > > On Mon, Oct 05, 2020 at 12:15:27PM -0400, Alan Stern wrote: > > > > The conclusion is that we need to have code that is aware of some > > > > detailed needs of a specific device but is not part of the device's > > > > driver. I'm not sure what the best way to implement this would be. > > > > > > Wouldn't it be possible to load the module when the DT specifies that > > > the device exists? For USB the kernel would need the VID/PID to identify > > > the module, these could be extracted from the compatible string. > > > > Loading a driver module whenever DT says a device exists? Not a bad > > idea. I don't know what would be involved, but no doubt it is possible. > > MODULE_DEVICE_TABLE mostly as I mentioned in my other reply. > > > Note that, except for a few special cases, the kernel identifies the > > appropriate driver for USB hubs not by the VID/PID but instead by the > > device class or interface class. I suppose the compatible string could > > include that information too? > > We can go back to 1998 OpenFirmware and it's already there[1]. > 'usb,class9' for a hub. There's a few other variations defined. That should work if the initialization is simple enough that the info in the device tree is sufficient (e.g. switching a single regulator on), otherwise a device specific compatible string would be needed. > > > Having the initialization code outside of the driver could lead to code > > > duplication, since the driver might want to power the device down in > > > certain situations (e.g. system suspend). > > > > True. On the other hand, how common do you think it would be for > > drivers not to want to mess with the power settings? > > I think in that case you'd generally want firmware to enable things > and the kernel then does no power control. > > We have ~1500 boards using DT and maybe ~10 with USB devices described > in DT. So the whole thing is not common to begin with. It's probably not very common, but might be more common than the DT suggests. Many devices probably don't specify their hub(s) or other USB devices explicitly when the initialization is done in firmware. In case a generic solution for all types of devices and busses is not required we would still need a driver to address at least the conditional power down of a hub during system suspend. Doug summarized the state of the discussion about the bindings for hubs (https://lore.kernel.org/patchwork/patch/1313000/#1511757) maybe we should continue from there?