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 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C1164C433E1 for ; Mon, 22 Jun 2020 13:51:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9DBD32073E for ; Mon, 22 Jun 2020 13:51:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592833870; bh=efQ2lDxw4orBAR8yTf7yEpmQfUZp69/5ULtJyw6nOzY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=sVJJu1BghriQI+5gH6ipUcv1Z5EVFYkK8RV+8VZD74OKPB0UjPHL+WvPr9EhVpQo1 bv5S3/qDECIz9jFvJRluIbc9FGFiWNvBvnHcNJiNnaMPRB4STWRQwb/7WYzTB4MZ0A OZ8pw5fyiHnAcFrBqaeoHIKUg9cKjxogHvu6etuw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729146AbgFVNvJ (ORCPT ); Mon, 22 Jun 2020 09:51:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:54208 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728070AbgFVNvI (ORCPT ); Mon, 22 Jun 2020 09:51:08 -0400 Received: from localhost (fw-tnat.cambridge.arm.com [217.140.96.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B123520716; Mon, 22 Jun 2020 13:51:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592833868; bh=efQ2lDxw4orBAR8yTf7yEpmQfUZp69/5ULtJyw6nOzY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=A1SH9hNwY8l0W0enC1ZspWW73Xl3Z/4jfvlMzVwkHsFnR94Y8iuHVe1FJcqjzhO6+ Ryexj938pdk0R5DqvqwXjfBilF4TLbOzNkNEH/8nk/Wez9GQ8g787O8Na/WsD35mXT kac8fNojgV4pwdCt5XeO8Y3C0EXooEWHoILZjvA4= Date: Mon, 22 Jun 2020 14:51:06 +0100 From: Mark Brown To: Andrew Lunn Cc: Bartosz Golaszewski , 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 , 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: <20200622135106.GK4560@sirena.org.uk> References: <20200622093744.13685-1-brgl@bgdev.pl> <20200622093744.13685-10-brgl@bgdev.pl> <20200622133940.GL338481@lunn.ch> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8kI7hWEHMS8Z+7/0" Content-Disposition: inline In-Reply-To: <20200622133940.GL338481@lunn.ch> X-Cookie: laser, n.: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --8kI7hWEHMS8Z+7/0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jun 22, 2020 at 03:39:40PM +0200, Andrew Lunn wrote: > 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? If the bus includes power management for the devices on the bus the controller is generally responsible for that rather than the devices, the devices access this via facilities provided by the bus if needed. If the device is enumerated by firmware prior to being physically enumerable then the bus will generally instantiate the device model device and then arrange to wait for the physical device to appear and get joined up with the device model device, typically in such situations the physical device might appear and disappear dynamically at runtime based on what the driver is doing anyway. > Maybe it is time to add a lower level API to the regulator framework? I don't see any need for that here, this is far from the only thing that's keyed off a struct device and having the device appear and disappear at runtime can make things like runtime PM look really messy to userspace. We could use a pre-probe stage in the device model for hotpluggable buses in embedded contexts where you might need to bring things out of reset or power them up before they'll appear on the bus for enumeration but buses have mostly handled that at their level. --8kI7hWEHMS8Z+7/0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl7wt0kACgkQJNaLcl1U h9DojAgAg2xKTg4gIiJrHsBsTywL4IZkKlRMbm2PDJ5+lsXLkRzZ+JOxic+SS0U8 uHnzeaqi/Yk+hMYR/7U8rZSS9zznj/fnnr62B3jCi2m2kfLlhzELzITMLYAw7a2x LEjxS/xad/vvPekNstKWQ8UDXDvfXJ0rrpvRF4S2XoJnoAd+LWoPwSZwmEdVuWWi RwVjPihfj16iMUsIGjWk+po1ac0U9CLeszltaxsk0l4xpp4AVfPLOyhgph5usA32 1BIpHC1jyP8OBeHCFFPaokc7KmL1u+gxL5MyYlsZJ2Uw7bBdtPI844oXVYy3/fFQ rDS4EhjpcMeQGFZ1a3DJHlIFu7xs6Q== =Itk7 -----END PGP SIGNATURE----- --8kI7hWEHMS8Z+7/0--