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=-3.9 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 2871EC43457 for ; Fri, 9 Oct 2020 23:13:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CF056223AB for ; Fri, 9 Oct 2020 23:13:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="SvBHuBUE" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726103AbgJIXNr (ORCPT ); Fri, 9 Oct 2020 19:13:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725973AbgJIXNr (ORCPT ); Fri, 9 Oct 2020 19:13:47 -0400 Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F1B30C0613D6 for ; Fri, 9 Oct 2020 16:13:46 -0700 (PDT) Received: by mail-pg1-x543.google.com with SMTP id 7so8442407pgm.11 for ; Fri, 09 Oct 2020 16:13:46 -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=R6gKWk0XgYJ+bRnJwNiMBZzjtd7hCRQG5lPlBLNpIXg=; b=SvBHuBUELCUejxiMecoCCc4s6g/H5gNRiExeY5Is+T+5LzTbZxIEgmCj9P6gp9rWzN /kVobTkY+otVFfZ6XhrktP3GuZVzkcodQU4FnXs464qkoOVPELG4L9FfHo1yk42cjJk5 EnMK8Oympvig2CRehaT+Oium1B2tLhdyhCa3Y= 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=R6gKWk0XgYJ+bRnJwNiMBZzjtd7hCRQG5lPlBLNpIXg=; b=Ry9cN0OsYKhRRB9QXOURz5paW11VuNnJ+FPz74Fgfo2bjqNBVoL2MYn6ka4+XQmcu2 fIz7Cdq4sAyXbDCHEyorMB0iyPjBFv6pZlTybpL8iBtLkfPjE8u0YoEUHO/kGu7xh/9L v6aNOKMHPxk9j/DevVuJrDhKnSa9UcuU8OeeQ3Dk2OJJDVtprzVjzMzTm2g9xnLWEhKk aFfUTRcwyoy+blQhlVREgjYRyNPl3VVqCuFYhIzTpQqGZo1dd7P8y1NCwgYx67sL+R8z 6zw0j+v3u6cuDaUiH6YHvVDV2Q6HkbTvjLx5zJHi0Ejy9Hm5+o7DQMcpOF8n29E+LUZy Lvow== X-Gm-Message-State: AOAM530N6HrGyL7fvjsLWaqnwhdWhMxGifUMBFVUsJ/aq2/D8buSpgD2 6jx/kZCooJYYxOBgfIZ8EEff3w== X-Google-Smtp-Source: ABdhPJzy8dpSt4depYawxqjmWVuoIHMAgsxXHG0jJxI96tFDpbhg+3/cQEJxcqVr55/jRvbazfFHrQ== X-Received: by 2002:a63:dd4e:: with SMTP id g14mr5038012pgj.44.1602285226319; Fri, 09 Oct 2020 16:13:46 -0700 (PDT) Received: from localhost ([2620:15c:202:1:f693:9fff:fef4:e70a]) by smtp.gmail.com with ESMTPSA id y5sm13316996pge.62.2020.10.09.16.13.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Oct 2020 16:13:45 -0700 (PDT) Date: Fri, 9 Oct 2020 16:13:43 -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: <20201009231343.GC1292413@google.com> References: <20201006192536.GB191572@google.com> <20201007010023.GA438733@rowland.harvard.edu> <20201007160336.GA620323@google.com> <20201007163838.GA457977@rowland.harvard.edu> <20201007172847.GB620323@google.com> <20201007192542.GA468921@rowland.harvard.edu> <20201007194229.GC620323@google.com> <20201007201732.GE468921@rowland.harvard.edu> <20201007214226.GA669360@google.com> <20201008140927.GB495091@rowland.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20201008140927.GB495091@rowland.harvard.edu> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Thu, Oct 08, 2020 at 10:09:27AM -0400, Alan Stern wrote: > On Wed, Oct 07, 2020 at 02:42:26PM -0700, Matthias Kaehlcke wrote: > > On Wed, Oct 07, 2020 at 04:17:32PM -0400, Alan Stern wrote: > > > The peering relation goes both ways, so it should be included in the > > > hub_2_0 description too. Given that, the driver could check hub_2_0's > > > peer's DT description for the appropriate resources. > > > > That mitigates the issue somewhat, however we still have to convince Rob that > > both references are needed. > > Strictly speaking, the peering relation applies to ports, not > devices. The representation in DT doesn't have to be symmetrical; as > long as the kernel understands it, the kernel can set up its own > internal symmetrical respresentation. > > > > > All this mess can be avoided by having a single instance in control of the > > > > resources which is guaranteed to suspend after the USB devices. > > > > > > Yes. At the cost of registering, adding a driver for, and making users > > > aware of a fictitious platform device. > > > > Registration is trivial and the driver code will be needed anyway, I'm > > pretty convinced that a separate platform driver will be simpler than > > plumbing things into the hub driver, with the additional checks of who is > > suspended or not, etc. If other resources like resets are involved there > > could be further possible race conditions at probe time. Another issue is > > the sysfs attribute. We said to attach it to the primary hub. What happens > > when the primary hub goes away? I guess we could force unbinding the peers > > as we did in the driver under discussion to avoid confusion/inconsistencies, > > but it's another tradeoff. > > > > My view of the pros and cons of extending the hub driver vs. having a platform > > driver: > > > > - pros > > - sysfs attribute is attached to a USB hub device > > - no need to register a platform device (trivial) > > - potentially more USB awareness (not clear if needed) > > > > - cons > > - possible races involving resources between peer hubs during initialization > > - increased complexity from keeping track of peers, checking suspend order > > and avoiding races > > - peers are forced to unbind when primary goes away > > - need DT links to peers for all USB hubs, not only in the primary > > - pollution of the generic hub code with device specific stuff instead > > of keeping it in a self contained driver > > - sysfs attribute is attached to only one of the hubs, which is better than > > having it on both, but not necessarily better than attaching it to the > > platform device with the 'control logic' > > > > So yes, there are tradeoffs, IMO balance isn't as clear as your comment > > suggests. > > Well, I guess I'm okay with either approach. Thanks for being flexible. I'm also open to the other approach, if you or others are convinced that a platform device is a really bad idea. > One more thing to keep in mind, though: With the platform device, > there should be symlinks from the hubs' sysfs directories to the > platform device (and possibly symlinks going the other way as well). Ok, I hoped we could get away with no USB driver at all, but I think it will be needed to create the symlinks (on its own the platform driver wouldn't notice when the USB devices come and go). Anyway, it's a relatively thin layer of code, so it's not too bad. With the new binding the USB devices still should be able to find the platform device if it uses the same DT node as the primary USB hub.