Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3596324pxk; Mon, 21 Sep 2020 19:18:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy8udNcp+wE47pN3/5coPP0xrB5vPzwiigQdrq6J6xuAC1qZnon25fMbDgWH0BeUwlkucpJ X-Received: by 2002:a17:906:a3d0:: with SMTP id ca16mr2481737ejb.455.1600741112464; Mon, 21 Sep 2020 19:18:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600741112; cv=none; d=google.com; s=arc-20160816; b=B0oehu6mjO3Co9XymZdRUHGWjQdSeaa10reInW4RdimYD8Bx92gDj0eMJfCcepkKkY GJCWFym3amVCWNQKivQzZ9meWmsI3Ocy4uBXFBHvy2nQdq98aptwGSl3iqeJF+S8d/qK db4omL6f/g4sZ4ECmw29X4Z2Aof3RAqbDa8PnGxfITkAk+eNhfzuDF99AtWST76iDgdy 43pjGW9BH8EdHM9RMMPycU/ujaKc1TO4noOE5fwniU+pJzNny+X4zZG6yOmQovHWZlTp biBsmuoqBcknkqbHAGBY1v/+40S7FGhPPfAEskFUtd2jjCYNkfA2MyUwoXP0ECqUoGbT BBZA== 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=thaNqPBBKQIhrLb25qaWs1VwsCKWNtH0Sa1kze80IiA=; b=rbFNu4f+g4JsYhTTmU3R+CTNlUGxCdsYkxe2zRH+trePLZF2ZH86XgR15phBfTrCC/ NKvNcikW/wSGPiEB7yWuxvnu9kgFbfk8y2NBniDjbYXDw0gTpTQfH/QNM9/Dn4v2DolK 8Caa1sV9E2Vbbp4SJqjY++lXuex3lY4NyTeASJsedE+dvqFlFnJQj1LW0rDKlJAOa26P r4pCojzAi6d+AisgksLaM1laFqLCt0INuRZuHXfQNOsAdEJjltAX4h+EE+yMFtEvTn6H ny1sOoUJzD88Yd3vSuTrDhlGCN9MQ6+Y3Qr6eQHiA8a45YOiZWRYvk9b48+u0+n9RuHx nGKA== 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 d10si9486804edp.364.2020.09.21.19.18.09; Mon, 21 Sep 2020 19:18:32 -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 S1728816AbgIVBIN (ORCPT + 99 others); Mon, 21 Sep 2020 21:08:13 -0400 Received: from netrider.rowland.org ([192.131.102.5]:47571 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1728854AbgIVBIN (ORCPT ); Mon, 21 Sep 2020 21:08:13 -0400 Received: (qmail 1238377 invoked by uid 1000); 21 Sep 2020 21:08:12 -0400 Date: Mon, 21 Sep 2020 21:08:12 -0400 From: Alan Stern To: Matthias Kaehlcke Cc: Greg Kroah-Hartman , Rob Herring , Frank Rowand , linux-kernel@vger.kernel.org, Douglas Anderson , linux-usb@vger.kernel.org, Bastien Nocera , Krzysztof Kozlowski , devicetree@vger.kernel.org, Ravi Chandra Sadineni , Peter Chen , Stephen Boyd , "Alexander A. Klimov" , Masahiro Yamada Subject: Re: [PATCH v2 2/2] USB: misc: Add onboard_usb_hub driver Message-ID: <20200922010812.GA1238082@rowland.harvard.edu> References: <20200917114600.v2.1.I248292623d3d0f6a4f0c5bc58478ca3c0062b49a@changeid> <20200917114600.v2.2.I7c9a1f1d6ced41dd8310e8a03da666a32364e790@changeid> <20200917195416.GA1099735@rowland.harvard.edu> <20200922004158.GC21107@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200922004158.GC21107@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 21, 2020 at 05:41:58PM -0700, Matthias Kaehlcke wrote: > > > + put_device(hub->dev); > > > > Is there a matching get_device somewhere (like in _find_onboard_hub)? > > If so, I didn't see it. And I don't see any reason for it. > > Yes, implicitly, of_find_device_by_node() "takes a reference to the > embedded struct device which needs to be dropped after use." Okay. In that case it probably would be better to do the put_device() right away, at the end of _find_onboard_hub(). There would be no danger of the platform device getting freed too soon if you make onboard_hub_remove unbind the associated USB hub devices. But there would still be a danger of those devices somehow getting rebound again at the wrong time; this suggests that you should add a flag to the onboard_hub structure saying that the platform device is about to go away. Alan Stern