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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A786EC4332F for ; Tue, 20 Dec 2022 07:55:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233057AbiLTHzO (ORCPT ); Tue, 20 Dec 2022 02:55:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33984 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229690AbiLTHzL (ORCPT ); Tue, 20 Dec 2022 02:55:11 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 822B92629; Mon, 19 Dec 2022 23:55:10 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 3DBA7B8105C; Tue, 20 Dec 2022 07:55:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6CD7C433EF; Tue, 20 Dec 2022 07:55:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1671522907; bh=Tyff5dKkJUEMJgpOCplHCQLNFPV2khvh5mON+5VPI9w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=L1jWkxqZy7WM77o3a+22gS5N/twe7BP74DnPzl0gynYuF9JdkfQB+FkmLu4HajH0m JmBWY6bDKaLO6pQB/eAZfrQBsPD9zfZK0vxFkkWG17qCI/wLHoGAdh9qSvlM8Rxt/T ZOVpPUFKhd/e362JjgZdarddkMfsb2jiDW6pL36tNXagoE/TdSmocusVZdozAk2p1J BwYU1lo8gzDApn5TlvHgTAxWYg/zFZT0zxS7mZXMnTKO1RtdOywql0lwv+eRKKJe9M umOYeL/zAvN1t5FEL6SOPucJSMA+Ri3/uOp/eod+tDzFnoeuJzBi6WrZQhe79pmIEZ 9VZA+bySEvXSw== Received: from johan by xi.lan with local (Exim 4.94.2) (envelope-from ) id 1p7XTc-00015F-D2; Tue, 20 Dec 2022 08:55:52 +0100 Date: Tue, 20 Dec 2022 08:55:52 +0100 From: Johan Hovold To: Matthias Kaehlcke , Rob Herring Cc: Greg Kroah-Hartman , Douglas Anderson , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, Stefan Wahren , Ravi Chandra Sadineni Subject: Re: [PATCH] usb: misc: onboard_usb_hub: Don't defer probing for 'incomplete' DT nodes Message-ID: References: <20221220004427.1.If5e7ec83b1782e4dffa6ea759416a27326c8231d@changeid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221220004427.1.If5e7ec83b1782e4dffa6ea759416a27326c8231d@changeid> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 20, 2022 at 12:45:01AM +0000, Matthias Kaehlcke wrote: > Some boards have device tree nodes for USB hubs supported by the > onboard_usb_hub driver, but the nodes don't have all properties > needed for the driver to work properly (which is not necessarily > an error in the DT). Currently _find_onboard_hub() returns > -EPROBE_DEFER in such cases, which results in an unusable USB hub, > since successive probes fail in the same way. Use the absence of > the "vdd" supply as an indicator of such 'incomplete' DT nodes > and return -ENODEV. > > Fixes: 8bc063641ceb ("usb: misc: Add onboard_usb_hub driver") > Reported-by: Stefan Wahren > Signed-off-by: Matthias Kaehlcke > --- > > drivers/usb/misc/onboard_usb_hub.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/drivers/usb/misc/onboard_usb_hub.c b/drivers/usb/misc/onboard_usb_hub.c > index d63c63942af1..2968da515016 100644 > --- a/drivers/usb/misc/onboard_usb_hub.c > +++ b/drivers/usb/misc/onboard_usb_hub.c > @@ -363,6 +363,15 @@ static struct onboard_hub *_find_onboard_hub(struct device *dev) > hub = dev_get_drvdata(&pdev->dev); > put_device(&pdev->dev); > > + /* > + * Some boards have device tree nodes for USB hubs supported by this > + * driver, but the nodes don't have all properties needed for the driver > + * to work properly. Use the absence of the "vdd" supply as an indicator > + * of such nodes. > + */ > + if (!of_get_property(pdev->dev.of_node, "vdd", NULL)) > + return ERR_PTR(-ENODEV); Does this not break your original use case? Don't you want "vdd-supply" here? That said, this seems like the wrong property to look for both in principle and as it is described as optional by the binding: Documentation/devicetree/bindings/usb/realtek,rts5411.yaml It seems that you should use the compatible property and check that it holds one of the expected values: - usbbda,5411 - usbbda,411 rather than treat every hub node as describing a realtek hub (AFAIK, there is no generic binding for this yet). > + > /* > * The presence of drvdata ('hub') indicates that the platform driver > * finished probing. This handles the case where (conceivably) we could Johan