Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2772110ybt; Mon, 22 Jun 2020 06:42:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx39UBb2TRuqNKuqtCxGFbkwypy8aKEdbA2qOv+6NqxLt1AZMLxY3gb1Nlk6ZCK1o+sJlWL X-Received: by 2002:a17:906:8393:: with SMTP id p19mr7404729ejx.210.1592833324551; Mon, 22 Jun 2020 06:42:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592833324; cv=none; d=google.com; s=arc-20160816; b=sTu5z4cw7T6/VrHbILdUp9W78a0kzLomMll22P8k3Y+5qbT8NuWVDfVbTzxESww7g5 Qgpb8L8cMuiEHIFgC4C0tulekMI36mivSmdFe/fwGnpIqYwqMzFRpPnRnAeFkZmvLido XzqmP2qTc5kzhAkNJR8fEi0TlUG+1FYHLFBvU3IY9Zl9BbuKmy+wWYT3fSu+C+GRH1iR 8bzLRkJIgA1iNiKCCULwdqQYwaaHTejJdCHRSSoOglL45z/qM68i9MbjyrFNxbXW5/TP Ic5AYOwyi0E8Vib7gYhQUPecVOJHj5PJEP2guJIY0eLUTbmiOD+fKWvkO3IKMW8NhDnK unJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=NnSvfKmAv2GhrYATnboAIcT5zMlzro7HyMNlPciTHZc=; b=xjyToVG8bWTRQAGJ1X96U0NrVTgk8oREnMPEdaI0T7BGhiSja4O0JS/y4597cPVgbt iwVuqB9t32OM9HwHI00QW/95tPTOPPJ88N3RSFxj7DIU6gGQeYz3NNlUWHBRbXkAv9kb JJI3Cp2NX4plxwU/EbAsqOE2uPAhz7GH2j6qaGDbdvio1HysE7tafT3vSz8DxRtrtoEt OLiPbaXMk+bwD8qdbvl5gM1nqmuFDcf7E1KinlTLp72eJQw3hNG+CYAzGejk0yx1uO5Y IYhRrSjMviy9nQqjdw2//DMuZBEtPoT2LAiGEI2dXUDmWdBm61eBIXAWe45Fmy5IEjoH 2/Kw== 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 x22si9066049eje.542.2020.06.22.06.41.41; Mon, 22 Jun 2020 06:42:04 -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 S1729146AbgFVNj6 (ORCPT + 99 others); Mon, 22 Jun 2020 09:39:58 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:52158 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728212AbgFVNj6 (ORCPT ); Mon, 22 Jun 2020 09:39:58 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1jnMfk-001fUc-RW; Mon, 22 Jun 2020 15:39:40 +0200 Date: Mon, 22 Jun 2020 15:39:40 +0200 From: Andrew Lunn To: Bartosz Golaszewski Cc: Florian Fainelli , Heiner Kallweit , Russell King , "David S . Miller" , Jakub Kicinski , Rob Herring , Matthias Brugger , Microchip Linux Driver Support , Vladimir Oltean , Claudiu Manoil , Alexandre Belloni , Vivien Didelot , Tom Lendacky , Yisen Zhuang , Salil Mehta , Jassi Brar , Ilias Apalodimas , Iyappan Subramanian , Keyur Chudgar , Quan Nguyen , Frank Rowand , Philipp Zabel , Liam Girdwood , Mark Brown , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Fabien Parent , Stephane Le Provost , Pedro Tsai , Andrew Perepech , Bartosz Golaszewski Subject: Re: [PATCH 09/15] net: phy: delay PHY driver probe until PHY registration Message-ID: <20200622133940.GL338481@lunn.ch> References: <20200622093744.13685-1-brgl@bgdev.pl> <20200622093744.13685-10-brgl@bgdev.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200622093744.13685-10-brgl@bgdev.pl> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 22, 2020 at 11:37:38AM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Currently the PHY ID is read without taking the PHY out of reset. This > can only work if no resets are defined. This change delays the ID read > until we're actually registering the PHY device - this is needed because > earlier (when creating the device) we don't have a struct device yet > with resets already configured. > > While we could use the of_ helpers for GPIO and resets, we will be adding > PHY regulator support layer on and there are no regulator APIs that work > without struct device. The PHY subsystem cannot be the first to run into this problem, that you need a device structure to make use of the regulator API, but you need the regulator API to probe the device. How do other subsystems work around this? Maybe it is time to add a lower level API to the regulator framework? Andrew