Received: by 2002:ac8:156:0:b0:3e0:cd10:60c8 with SMTP id f22csp525647qtg; Wed, 5 Apr 2023 13:41:09 -0700 (PDT) X-Google-Smtp-Source: AKy350ZxAMiU2evrB1vjWEKffhUD73LDOTlH65GB5K7SwdvDFrqhcYGSbWYVbD+32AsioOjtvmz0 X-Received: by 2002:a17:906:2cc5:b0:930:ca4d:f2bf with SMTP id r5-20020a1709062cc500b00930ca4df2bfmr3915213ejr.54.1680727268876; Wed, 05 Apr 2023 13:41:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680727268; cv=none; d=google.com; s=arc-20160816; b=rR9U5oGtFcGQNyluRmxZ8NPOXi994Ivf1W2zm/wVzoyYo+jNkUZaMaY4dla52n5z90 PqltkCBVXSATt7D5rlz+/hNlMtc1BtjywKLVOsP3m+KKprJxYUtMnC/bbKJ/7Lr2gmIW 70Ijm+RIavJk/mC/K0szCXqmzvDukqOdoYpmtXjH8VHXGswJlinRPAekDp4Lezwc1iws RQJcw8iLdizyzbw3yy0esW/JGtQpUoCQXN4bPcznrR01DVkK9Dl4tNjAccvncZB0ZCTz JtnsivYxkXX23+xXu+GPxZihdxWDDpcmPo5D8OMnygrPjAqcBLdRKsjJkCWGhnqcuNiO rw6w== 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=ir96PDQ5DPUpeJhDM1v4BrKeIYiu1Z8SXvc8ylqyxe8=; b=xw9rc4PUZXqEkHX27ujuKPGK723cZPU45ynlN+qlaJSQ5PU7sNyEhcNpZHHMFiDxug JWiToYnC4y3YInT+MwiSCDzDyZbKKUEfcfM72VEr+8L4xpdKFlEl0p36YkOc8AkyXah1 QbqPojfRFfLiSs9IGJJjAHw2syuxWH5zfR9KeUHEdUdtZGc0Oebn2QDBghyWDeI3QJ/A Xfshqge26pFf+lTww/bnuGWv6AEKOi3zubZ+7ImP2Nfi4IDWl/6xhXPoApSoccOT26xO m7b8lJH4ibCHvSum6/eHmCNCpMA6/bZSuUXB4lY0TaAViTsxYdAA8zveJhV+M05hPtK4 oyaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=APgRQZvM; 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=lunn.ch Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id vm8-20020a170907b68800b00947bf527c17si586423ejc.374.2023.04.05.13.40.42; Wed, 05 Apr 2023 13:41:08 -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=@lunn.ch header.s=20171124 header.b=APgRQZvM; 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=lunn.ch Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233497AbjDEUfF (ORCPT + 99 others); Wed, 5 Apr 2023 16:35:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51910 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233076AbjDEUeu (ORCPT ); Wed, 5 Apr 2023 16:34:50 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 067455249; Wed, 5 Apr 2023 13:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=ir96PDQ5DPUpeJhDM1v4BrKeIYiu1Z8SXvc8ylqyxe8=; b=APgRQZvMhXqYui/jKYMbnzPcry LwxJoMiLuXafar1R6r/+lEB3JLt42me4gaqh6MGXxrXsQ6JG3htDZ3ri3it2ZFxJD0F8SqAGkxhGt bfKq52f5ibdbLODUbWeZf3ogeFu8emiFcDv2gGhCOEdfH2DoKuMoP6K0+I0YvK45vtrU=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1pk9po-009Yke-Nq; Wed, 05 Apr 2023 22:34:24 +0200 Date: Wed, 5 Apr 2023 22:34:24 +0200 From: Andrew Lunn To: Marco Felsch Cc: Heiner Kallweit , Russell King , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Florian Fainelli , Broadcom internal kernel review list , Richard Cochran , Radu Pirea , Shyam Sundar S K , Yisen Zhuang , Salil Mehta , Jassi Brar , Ilias Apalodimas , Iyappan Subramanian , Keyur Chudgar , Quan Nguyen , "Rafael J. Wysocki" , Len Brown , Rob Herring , Frank Rowand , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, devicetree@vger.kernel.org, kernel@pengutronix.de Subject: Re: [PATCH 06/12] net: phy: add phy_device_atomic_register helper Message-ID: <34e22343-fb11-4a85-bade-492fcbcfb436@lunn.ch> References: <20230405-net-next-topic-net-phy-reset-v1-0-7e5329f08002@pengutronix.de> <20230405-net-next-topic-net-phy-reset-v1-6-7e5329f08002@pengutronix.de> <20230405152225.tu3wmbcvchuugs5u@pengutronix.de> <20230405194353.pwuk7e6rxnha3uqi@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230405194353.pwuk7e6rxnha3uqi@pengutronix.de> X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS 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 > Currently we have one API which creates/allocates the 'struct > phy_device' and intialize the state which is: > - phy_device_create() > > This function requests a driver based on the phy_id/c45_ids. The ID have > to come from somewhere if autodection is used. For autodetection case > - get_phy_device() > > is called. This function try to access the phy without taken possible > hardware dependencies into account. These dependecies can be reset-lines > (in my case), clocks, supplies, ... > > For taking fwnode (and possible dependencies) into account fwnode_mdio.c > was written which provides two helpers: > - fwnode_mdiobus_register_phy() > - fwnode_mdiobus_phy_device_register(). > > The of_mdio.c and of_mdiobus_register_phy() is just a wrapper around > fwnode_mdiobus_register_phy(). It seems to me that the real problem is that mdio_device_reset() takes an mdio_device. mdiobus_register_gpiod() and mdiobus_register_reset() also take an mdio_device. These are the functions you want to call before calling of_mdiobus_register_phy() in __of_mdiobus_register() to ensure the PHY is out of reset. But you don't have an mdio_device yet. So i think a better solution is to refactor this code. Move the resources into a structure of their own, and make that a member of mdio_device. You can create a stack version of this resource structure in __of_mdiobus_register(), parse DT to fill it out by calling mdiobus_register_gpiod() and mdiobus_register_reset() taking this new structure, take it out of reset by calling mdio_device_reset(), and then call of_mdiobus_register_phy(). If a PHY is found, copy the values in the resulting mdio_device. If not, release the resources. Doing it like this means there is no API change. Andrew