Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1454820pxb; Fri, 22 Oct 2021 00:59:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJww4uqJ2DVvdcaplDZchO0stnJP2XSRtSxHbXLSpYVukkOyKZTzO/cEP8T/+NOgBDlPN5Gg X-Received: by 2002:a05:6a00:1148:b0:44d:2798:b08a with SMTP id b8-20020a056a00114800b0044d2798b08amr10936462pfm.2.1634889547064; Fri, 22 Oct 2021 00:59:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634889547; cv=none; d=google.com; s=arc-20160816; b=hz0NQa3b0q1CH5pkIKnMyOk/nXLYDnMgr34aNrH83+GR0HU1/lQkdPwGYm3d+DpRwd GDipdCcxs9/S2wvpbiF1dvYxQiGqosTBMmVmNz3Oifqs4n2b1vDwyxpG78JRWj1/Xhzj QCUVhW3y2DQVdmnOW5wiVm8C2R+nEjCX0hPhP+F12zD6cjBGBpbVixivqQQKTdyU7DFo XEVWyXBmeBouic4RLSk1tbnVYBMAPGoYQOEf5XFeMl+dfRXpG4XO9Cn8ebopBomWTL3E 4iWr5hMNdK2SuafB0JEh65+HX0IlfZkSg3hnKhiBdSvN9fs7AeG3QwqiVl75NmH2FwSz OFxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature:dkim-signature; bh=tdPdMXT5NI9kQCZLp2Ql9uP6lZACsG/bkmj55NJvKW4=; b=p+aJYklTNp6hYsCw0gxngygKpE9XrlRmf/o5jLZTO4XiV6hE/4JBBCTUMVG8tsgmku +74atLiwKUbfryFVav5C6cT9qFxUgEkO1PB/n90wXb1SuA0OVyFoEqM97hWXw1Hzaf4o 7FTw76mphb2ZdA3l52JFROnfXjLHD+JYWQK0FoKdPlEL+cY1F0vMPSdcyrRq/IEW/zeh 7Ff3F0u3i3H1BCux4ZviuN8yynCI7D4BaXeQTdk3lFGWwyUILoIW+/HfnS563St6cqz0 ZgAEOCfn3qgeel/CHN+U15sAeRbt7UVRrsKbL/rJo6SztGA2iHGOsJeR3xx9ZvX6Q+2q wZUw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@tq-group.com header.s=key1 header.b=INlnzkMv; dkim=pass header.i=@tq-group.com header.s=key1 header.b="i6W/kdtk"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=tq-group.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w6si10931197plg.188.2021.10.22.00.58.52; Fri, 22 Oct 2021 00:59:07 -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; dkim=pass header.i=@tq-group.com header.s=key1 header.b=INlnzkMv; dkim=pass header.i=@tq-group.com header.s=key1 header.b="i6W/kdtk"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=tq-group.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232099AbhJVIAQ (ORCPT + 99 others); Fri, 22 Oct 2021 04:00:16 -0400 Received: from mx1.tq-group.com ([93.104.207.81]:27014 "EHLO mx1.tq-group.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231846AbhJVIAP (ORCPT ); Fri, 22 Oct 2021 04:00:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1634889478; x=1666425478; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=tdPdMXT5NI9kQCZLp2Ql9uP6lZACsG/bkmj55NJvKW4=; b=INlnzkMv+VZhCwn7piK1ge28acEFfMzkflPcUlwdEE8Xn38vY6vCxF/F UMN5+/U3BoXYPo4BqGDNyHYTEJyf3H/4gEEU1Xw2XywYhH2KTwmrh+quU gAWHSb4d19aD0GvAnJOGWBq+/TAOJphYN/QgVqJIkQMt0SQvWXndAC1PD MMZOttNVE3Z1coen43y8F7kTlGcaV8q30ZEJxbjmrtKdwkDMCLbIIstKX paEpuRlNjJWXjgs+/8HOdwSLNnyZjP4X0YWy8vNmg5YJGcSXxuk24FHSs IKYO+PVSH7Zwsp4Gdfuv4u6ZY6szWozoUyJDzIQG6L9CkF9S+M/DlPsxQ g==; X-IronPort-AV: E=Sophos;i="5.87,172,1631570400"; d="scan'208";a="20184798" Received: from unknown (HELO tq-pgp-pr1.tq-net.de) ([192.168.6.15]) by mx1-pgp.tq-group.com with ESMTP; 22 Oct 2021 09:57:57 +0200 Received: from mx1.tq-group.com ([192.168.6.7]) by tq-pgp-pr1.tq-net.de (PGP Universal service); Fri, 22 Oct 2021 09:57:57 +0200 X-PGP-Universal: processed; by tq-pgp-pr1.tq-net.de on Fri, 22 Oct 2021 09:57:57 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1634889477; x=1666425477; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=tdPdMXT5NI9kQCZLp2Ql9uP6lZACsG/bkmj55NJvKW4=; b=i6W/kdtk6giP9ry+WTZw1yXlvurTjWCVEXvxUJBTvBdu+AVc0uGm0giT dv4Du9DaanZIECqN08O9yYr4ZWhPlxg0EBCQ7weNOfrgi2Clxxn6NelD1 ps7vnSu3cQhjW06RIcFSBPz6Gl6uqXCvCXZPhGD78eRuhhQbIECDNVm83 Tf/Big1x1arCTt5/ZiAgillNQfj5PwB5kBCaJnSRpvJ0zqr1yfakZElQZ LtEwt+jfTCtdL0LlsI5IbXoVMxL9a1jx1jPHr25Oi4qJD4LiSusgItRYR q62FIQcUMJ9/ZbN28BFCyMpRYQff7uePI+1VSJjICSuUmyrQyYr7wXHsS g==; X-IronPort-AV: E=Sophos;i="5.87,172,1631570400"; d="scan'208";a="20184797" Received: from vtuxmail01.tq-net.de ([10.115.0.20]) by mx1.tq-group.com with ESMTP; 22 Oct 2021 09:57:57 +0200 Received: from schifferm-ubuntu4.tq-net.de (schifferm-ubuntu4.tq-net.de [10.121.48.12]) by vtuxmail01.tq-net.de (Postfix) with ESMTPA id DB892280065; Fri, 22 Oct 2021 09:57:56 +0200 (CEST) Message-ID: <7a478c1f25d2ea96ff09cee77d648e9c63b97dcf.camel@ew.tq-group.com> Subject: Re: [PATCH] net: fec: defer probe if PHY on external MDIO bus is not available From: Matthias Schiffer To: Andrew Lunn Cc: Joakim Zhang , "David S. Miller" , Jakub Kicinski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Date: Fri, 22 Oct 2021 09:57:54 +0200 In-Reply-To: References: <20211014113043.3518-1-matthias.schiffer@ew.tq-group.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2021-10-21 at 14:50 +0200, Andrew Lunn wrote: > > I would love to do this, but driver-api/driver-model/driver.rst > > contains the following warning: > > > > -EPROBE_DEFER must not be returned if probe() has already created > > child devices, even if those child devices are removed again > > in a cleanup path. If -EPROBE_DEFER is returned after a child > > device has been registered, it may result in an infinite loop of > > .probe() calls to the same driver. > > > > My understanding of this is that there is simply no way to return > > -EPROBE_DEFER after fec_enet_mii_init(pdev). > > It might say that, but lots of network drivers actually do this. I've > not seen an endless loop. > > Andrew Hmm, lots of network drivers? I tried to find an example, but all drivers that generate -EPROBE_DEFER for missing PHYs at all don't have an internal MDIO bus and thus avoid the circular dependency. Matthias