Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp1811930iog; Thu, 16 Jun 2022 14:31:58 -0700 (PDT) X-Google-Smtp-Source: AGRyM1ulgBJ8FYFxI79h8d4hbUgy37tT+DWWycMNm7+k7lDcpMgxoeCDwHPL+eQa7v0Pi2atkiB6 X-Received: by 2002:a63:358e:0:b0:408:c0fe:6799 with SMTP id c136-20020a63358e000000b00408c0fe6799mr6112493pga.145.1655415117839; Thu, 16 Jun 2022 14:31:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655415117; cv=none; d=google.com; s=arc-20160816; b=PI9hWqmhF+rANy2Txq/qS1wYVzIGRFdCzZaCv5m2ew0dlg/tOW69DBSxu94m74AiDo jeMcEEeylFIyu+E+zdICvq35ec1bIcpD8uc9EwrmMNb+oxz+ryfMCLhtbrISHZpiPuOK 1vOCRRoHqIWfYG2SRKqND9HCUolJyukHltCwhVh2WUeKMJTIhXZenmK/ezn/QwGqTNvO 0znOQd3H+MXNFLrdUf8BFoykXgTnsnIm/qj0MjfUeaLuOZcFC1MudTOBi1t9B7zrRjg/ tjHfnfIzXTUIGcSLdXsrrQcI+H9qEovn5ZwT+zOFuBKh3PfqGetZYrUFc1uRHLJk+kQw oEcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=HwbgezfQwk0Xu1pd/5zyik8R0QppWmV3ImE0Oh/38WA=; b=tRYtvLms/DnlosttWDbVfYfJwY66n3DfFxx+R56atXwGKTWtiTGnpftdxpqwBTYgS9 Ycd3qKdBw0FOfW2vi5Ov99Cc4jrFlQIA1ZQnnysIjAC9MqfrZgwg22QGc7banJ2I8Rng yRs/rhCdQ7H5h/KhNVa/wtqBUZV/p56QnH0+vF0KzsOUsNZaW3gbFJhsB6QSxIxwjWTD jlgC/+KS5Tj6Bn7PEQcHmlmgL6iLL8xOXJQO5nlo8L8YeJzPmLptN8XDLI9FDCSoe2PE onaNpPYMmPq3lQVqenXuw2SZp40QLL1PdL6oWEbCM/SjiQnm+5/Imj2usFvWL7j6hCc8 9xLA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=TlNoPzPn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u7-20020a626007000000b0051b95f36eacsi3653124pfb.274.2022.06.16.14.31.44; Thu, 16 Jun 2022 14:31:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=TlNoPzPn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379050AbiFPVIq (ORCPT + 99 others); Thu, 16 Jun 2022 17:08:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59508 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378976AbiFPVIn (ORCPT ); Thu, 16 Jun 2022 17:08:43 -0400 Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 492CA606FD for ; Thu, 16 Jun 2022 14:08:41 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id b12-20020a17090a6acc00b001ec2b181c98so1272144pjm.4 for ; Thu, 16 Jun 2022 14:08:41 -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=HwbgezfQwk0Xu1pd/5zyik8R0QppWmV3ImE0Oh/38WA=; b=TlNoPzPnoqLcG8glyixDbYt4HuvHv1RJUrpBYBd26D/AENq5Lr2UaRi+x5RiPhoQG+ QIc0APs6AnViZ/1aS6T9H37/g52R3nd3wFk0eHws+3wm4G03m1d69G5YUgEEHh/pIjOv I1a0qgibONul/Ujsu2SA/nAu2q1VPG7DyvkyI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=HwbgezfQwk0Xu1pd/5zyik8R0QppWmV3ImE0Oh/38WA=; b=XHAr3pD2hMnaeah2SH5Gk0JSw6wf1JzNtjsgmkh+9eOm1LK3tX1kMpg1wpawIxv+k0 Q5u0BVHy4mfBhlUEuZNxMTzHqIw3w1aTBh8NXPJqNT9Yl8LrId8HIM1CYy34G95Yxn2V c/9xets9FhQCwJYWP0ZxqeYCZYdnWk80u5/rJ0/DG8+rzalsXaAcPs9mFih8PkFFhEpc t41A2MWYfsSDhIW8/W0HsA37bekr6VePHWgx0L+07HWPwV/WXjCyBAYAX+IY2G+gWldS dt+9PfJheKDGsE/oWl4SseteNVs6RTAzp5dFyQU49qf/mWDpJUoj0Z+JDQ/AD1/e50IX AZZg== X-Gm-Message-State: AJIora991qt4yLb0p6jp7qg8+mwq7JxIfKKFJ1yEAew3JyzXTwugmICJ n/C2X8vb1GtCSolSJogg92Ytng== X-Received: by 2002:a17:90b:341:b0:1e0:cf43:df4f with SMTP id fh1-20020a17090b034100b001e0cf43df4fmr7041722pjb.126.1655413721353; Thu, 16 Jun 2022 14:08:41 -0700 (PDT) Received: from localhost ([2620:15c:11a:202:4ef5:7e3b:63ba:fc4]) by smtp.gmail.com with UTF8SMTPSA id g30-20020aa79dde000000b0050dc76281b8sm2215073pfq.146.2022.06.16.14.08.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jun 2022 14:08:40 -0700 (PDT) Date: Thu, 16 Jun 2022 14:08:39 -0700 From: Matthias Kaehlcke To: Doug Anderson Cc: Greg Kroah-Hartman , Alan Stern , Rob Herring , Frank Rowand , Mathias Nyman , Felipe Balbi , Michal Simek , LKML , Krzysztof Kozlowski , Stephen Boyd , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Bastien Nocera , Peter Chen , Ravi Chandra Sadineni , Roger Quadros , Linux USB List , Geert Uytterhoeven , Souradeep Chowdhury Subject: Re: [PATCH v22 2/3] usb: misc: Add onboard_usb_hub driver Message-ID: References: <20220609192000.990763-1-mka@chromium.org> <20220609121838.v22.2.I7c9a1f1d6ced41dd8310e8a03da666a32364e790@changeid> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 16, 2022 at 01:12:32PM -0700, Doug Anderson wrote: > Hi, > > On Wed, Jun 15, 2022 at 4:22 PM Matthias Kaehlcke wrote: > > > > > > +void onboard_hub_create_pdevs(struct usb_device *parent_hub, struct list_head *pdev_list) > > > > +{ > > > > + int i; > > > > + struct usb_hcd *hcd = bus_to_hcd(parent_hub->bus); > > > > + struct device_node *np, *npc; > > > > + struct platform_device *pdev = NULL; > > > > + struct pdev_list_entry *pdle; > > > > + > > > > + if (!parent_hub->dev.of_node) > > > > + return; > > > > + > > > > + for (i = 1; i <= parent_hub->maxchild; i++) { > > > > + np = usb_of_get_device_node(parent_hub, i); > > > > + if (!np) > > > > + continue; > > > > + > > > > + if (!of_is_onboard_usb_hub(np)) > > > > + goto node_put; > > > > + > > > > + npc = of_parse_phandle(np, "companion-hub", 0); > > > > + if (npc) { > > > > + /* > > > > + * Hubs with companions share the same platform device. > > > > + * Create the plaform device only for the hub that is > > > > + * connected to the primary HCD (directly or through > > > > + * other hubs). > > > > + */ > > > > + if (!usb_hcd_is_primary_hcd(hcd)) { > > > > + of_node_put(npc); > > > > + goto node_put; > > > > + } > > > > + > > > > + pdev = of_find_device_by_node(npc); > > > > + of_node_put(npc); > > > > + } else { > > > > + /* > > > > + * For root hubs this function can be called multiple times > > > > + * for the same root hub node (the HCD node). Make sure only > > > > + * one platform device is created for this hub. > > > > + */ > > > > + if (!parent_hub->parent && !usb_hcd_is_primary_hcd(hcd)) > > > > + goto node_put; > > > > > > I don't understand the "else" case above. What case exactly are we > > > handling again? This is when: > > > * the hub is presumably just a 2.0 hub since there is no companion. > > > * our parent is the root hub and the USB 2.0 hub we're looking at is > > > not the primary > > > > The 'else' case can be entered for hubs connected to a root hub or to another > > hub further down in the tree, but we bail out only for first level hubs. > > > > > ...but that doesn't make a lot of sense to me? I must have missed something... > > > > It's not super-obvious, this bit is important: "this function can be called > > multiple times for the same root hub node". For any first level hub we only > > create a pdev if this function is called on behalf of the primary HCD. That > > is also true of a hub connected to the secondary HCD. We only want to create > > one pdev and there is supposedly always a primary HCD. > > > > Maybe it would be slightly clearer if the function returned before the loop > > if this condition is met. > > I guess I'm still pretty confused. You say "For root hubs this > function can be called multiple times for the same root hub node". > Does that mean that the function will be called multiple times with > the same "parent_hub", or something else. It is called with a different "parent_hub", however for root hubs the DT node is the same for both root hubs (it's the DT node of the controller since there are no dedicated nodes for the root hubs). Just to make sure this isn't the source of the confusion: the root hubs are part of the USB controller, not 'external' hubs which are directly connected to the controller. I call the latter 'first level hubs'. > Unless it's called with the same "parent_hub" then it seems like if > the USB device has a device tree node and that device tree node is for > a onboard_usb_hub and there's no companion node then we _always_ want > to create the platform device, don't we? If it is called with the same > "parent_hub" then I'm confused how your test does something different > the first time the function is called vs. the 2nd. Let's use an adapted trogdor DT with only a USB 2.x hub as an example: usb_1_dwc3 { dr_mode = "host"; #address-cells = <1>; #size-cells = <0>; /* 2.x hub on port 1 */ usb_hub_2_x: hub@1 { compatible = "usbbda,5411"; reg = <1>; vdd-supply = <&pp3300_hub>; }; }; 1st call: the 'parent_hub' corresponds to the USB 3.x root hub of usb_1_dwc3, the DT node of the hub is 'usb_1_dwc3'. The function iterates over the ports, finds usb_hub_2_x, enters the else branch (no companion hub), checks that the function was called on behalf of the primary controller and creates the pdev. 2nd call: the 'parent_hub' corresponds to the USB 2.x root hub of usb_1_dwc3, the DT node of the hub is also 'usb_1_dwc3'. The function iterates over the ports, finds usb_hub_2_x, enters the else branch (no companion hub), sees that it is not called on behalf of the primary controller and does not create a second (unnecessary) pdev. Is it clearer now?