Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp47320pxb; Thu, 2 Sep 2021 18:54:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxudNt8IGQzt58JJYoFfRUUSnY/oyt2BcALjOVbzwofQKxx9gTfYdaKW3llL5x9Kjh+3z1/ X-Received: by 2002:a17:906:c18c:: with SMTP id g12mr1412298ejz.458.1630634058883; Thu, 02 Sep 2021 18:54:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630634058; cv=none; d=google.com; s=arc-20160816; b=ZHU3SRY8Bqjfa0wl6UEwUhNR/7+WOSIlQY3mwv76qkTlyMsk/JcA9s6c38d0rGCb5u Q/4+99fztXVbcZTIrsuN4VLZ7Hw8LCSmXgR0btxjRkyXTKYgowfjkqYAW1OJoZ+/7FOj vj7SO4Q7SHt3rmfUQUooA5GpfkhwqeACdTCMSPSU2MTUdAo2o79KKs5tS/7pAruoYTUj xcE4Oa68lc8SwWe7KGAB/ApkC7C77PmCXK7N6wO+G20/vMXvu3KYYIZj27xDR7eYePYd leuBSQQTn4Wzs8DRWpPrbeNEwhbTlddTd+Ux/jm5QTiEB//mdkrX38yaXSLtxqDR/XUz lMfQ== 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=FNx7Sjs58HqrySL8o4+QAe25L07gbXmuCz3/vApGk7Y=; b=tG3yiiabnGSYUOOlb2DCPtI7ZOHWOu6mCuEDCLrmwp/mLJfvxiwDfK9a4Ogem2qY03 AInabUr6fPY2WPQ5xqcnBj5FOmxYFDBt+IL4+8pJLXJoKVGbiGGobkb/9XKzzNfK5zWQ Fizn7AQj2CvRYu5/dWAO4hC/aT3JdAPnSvha8gILXlPZC9fTLQmQB1rrtn8CM2Yxfi68 5k42jYU9jIP754l72W7J0oy6k8Cs/nu1icxqjrS6+uA9tAeM3h4NxiFzLFK+eUi6tVpE /K8Rdyu72o7u+ZB5uhY3vajtIG5SZR8Aj6dCikFgzYxOVhxn9yOClm/FfWpw2KZQJGF4 0bNw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=lBiICCZR; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h14si4317013eje.410.2021.09.02.18.53.55; Thu, 02 Sep 2021 18:54:18 -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=@gmail.com header.s=20210112 header.b=lBiICCZR; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344423AbhIBX1K (ORCPT + 99 others); Thu, 2 Sep 2021 19:27:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234244AbhIBX1J (ORCPT ); Thu, 2 Sep 2021 19:27:09 -0400 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 963B1C061575; Thu, 2 Sep 2021 16:26:10 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id s25so5405567edw.0; Thu, 02 Sep 2021 16:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=FNx7Sjs58HqrySL8o4+QAe25L07gbXmuCz3/vApGk7Y=; b=lBiICCZRjBf/OK7sQs6cVKMmw/fUWFI1zrzgaaT1YuVEoR18CCz8mCCHmnHnJYyl1Y yb+5JPy17dcSk1eQlWTQEqfkDKth2iGOaNaZSh7XoIJ9iCxfq2ni5BmvE/3ZnOVG9vHL olRznZ+PIkR7suR5NM/WRirhSFMyKmyUKh6esj1HlxkQV5/b41m+vecS4IHh88w+Cpxu PMorH6Mz1PhAqRzb1gpt8uLBsIssdB3u5qGw4Yy1cyeqrhQBkFTc/MAEaaVno3YWJY14 GvbrdgrAmglBJyOoiVvqLDdZ6MphTXVbsIWZziadsi/RHE0MtpkGou+KcmEiBv4D8EIl wi4g== 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=FNx7Sjs58HqrySL8o4+QAe25L07gbXmuCz3/vApGk7Y=; b=B7eErm2HGHAYqOPPcMIxacnlYmCEFxCU4/BNlhmE+Y6DgIbDV+16x+gtsmN49RhsC/ CkM3Q6t0AErGaB7kJdlf6iAOdp0nbiuwb+WABJNpE0u+UxRA5RUUxD//9YChPyR+n4Gx B/DXxcsgKBioC4fvItOLzfctiI1gCQ0u7mhpjNlNKUv8jL/loxwwtTH1EPQb50KC8nqD 3er+mGVkoJ84E+7IrRpAKte+Ue9UmOg0hVVJkzK2kDCd69Kl+IyPzzFNEjDJDDFaFv/A waOY6dG7E5IIkgG2ZYs7DRxFx0Pj62GTVcC0RofkzFlxyM2NQAmROVyQqloBtIGgppSA 8SPw== X-Gm-Message-State: AOAM532098iGIsnj01L0/3jB6iXpp099MZuHmSy09Bpc6ke2PABoR/zn JwzQyrSwOQazqm2QXhX/n1s= X-Received: by 2002:a05:6402:8c6:: with SMTP id d6mr876206edz.30.1630625169182; Thu, 02 Sep 2021 16:26:09 -0700 (PDT) Received: from skbuf ([82.78.148.104]) by smtp.gmail.com with ESMTPSA id c10sm1858710eje.37.2021.09.02.16.26.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Sep 2021 16:26:08 -0700 (PDT) Date: Fri, 3 Sep 2021 02:26:07 +0300 From: Vladimir Oltean To: Andrew Lunn Cc: "Russell King (Oracle)" , Florian Fainelli , Vladimir Oltean , netdev@vger.kernel.org, Greg Kroah-Hartman , "Rafael J. Wysocki" , Heiner Kallweit , "David S. Miller" , Jakub Kicinski , Vivien Didelot , linux-kernel@vger.kernel.org, Linus Walleij , Alvin =?utf-8?Q?=C5=A0ipraga?= , ACPI Devel Maling List , kernel-team , Len Brown Subject: Re: [RFC PATCH net-next 1/3] net: phy: don't bind genphy in phy_attach_direct if the specific driver defers probe Message-ID: <20210902232607.v7uglvpqi5hyoudq@skbuf> References: <20210901225053.1205571-1-vladimir.oltean@nxp.com> <20210901225053.1205571-2-vladimir.oltean@nxp.com> <20210902185016.GL22278@shell.armlinux.org.uk> <20210902213303.GO22278@shell.armlinux.org.uk> <20210902213949.r3q5764wykqgjm4z@skbuf> <20210902222439.GQ22278@shell.armlinux.org.uk> <20210902224506.5h7bnybjbljs5uxz@skbuf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 03, 2021 at 01:02:06AM +0200, Andrew Lunn wrote: > We should try to keep phylink_create and phylink_destroy symmetrical: > > /** > * phylink_create() - create a phylink instance > * @config: a pointer to the target &struct phylink_config > * @fwnode: a pointer to a &struct fwnode_handle describing the network > * interface > * @iface: the desired link mode defined by &typedef phy_interface_t > * @mac_ops: a pointer to a &struct phylink_mac_ops for the MAC. > * > * Create a new phylink instance, and parse the link parameters found in @np. > * This will parse in-band modes, fixed-link or SFP configuration. > * > * Note: the rtnl lock must not be held when calling this function. > > Having different locking requirements will catch people out. > > Interestingly, there is no ASSERT_NO_RTNL(). Maybe we should add such > a macro. In this case, the easiest might be to just take a different mutex in dpaa2 which serializes all places that access the priv->mac references. I don't know exactly why the SFP bus needs the rtnl_mutex, I've removed those locks and will see what fails tomorrow, but I don't think dpaa2 has a good enough justification to take the rtnl_mutex just so that it can connect and disconnect to the MAC freely at runtime.