Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp3531095iob; Tue, 17 May 2022 01:58:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz/V/VXnzP98ALnaF10GnSFjkiJHPRN7LlKqOq6B56u7oq5xHr6B8z7e1dBGaKn2i54i/H0 X-Received: by 2002:a63:7247:0:b0:3c1:a8ab:fc6 with SMTP id c7-20020a637247000000b003c1a8ab0fc6mr19149672pgn.602.1652777903430; Tue, 17 May 2022 01:58:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652777903; cv=none; d=google.com; s=arc-20160816; b=ig7ftSkRUe1cM8Q7ic67dtcdCg+AbPed6fSlX7lBsAWMktE4VyL3QRY8+So+GsSZXw IUOL7/DxggauPEx5nA9Dbar+8fOPy1BZ/fTe/meDjSDfNpHNmrAab8m8PRSI62EELs0H czPiRqu5z3sA3rq7QrNH8KmWkdcjNMPbn3z6/wn5jxchK/SrLzDWph1QzUdhc3nh/9Jo BNPqNxEW5MmhR2GSRm3ZIL2bY+zPwUGeRMIkaoYIfgFZN7BVvVQ3uE2kvLv4ycdM2Pyx XbFkkw33p4qurr0Pt5lUg6BnmVutQKZ2e7Uw4y5liYVEbo75lB8zAbzFUqfdNUI8DisL VfQA== 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; bh=iJgSIj5Vbgqm2lP3FwW0wvqzkGV+5Vch0R+WtavPeG0=; b=EV2xx4BU1cHiXsCgsSzGkZZbyh030sgDHP81K0P5Wo4MDlcEXqB8j0K3SBualjFsP+ /YmI19u7sxy/MxERV4z2gNkIkupGpNTNvpkV2iTyCexBJOm5qYB+e99ZcW4cusP3JBJ3 0vcvAG1/8dfWKbjlNYQvup4VkninprXACCskQtOP3rzrougknAhVGbjCYeWwdiElagC8 YyvTkZuwvHyKrBnK+yySIzmvXvk+I4L5K9/ReaRIhWtb62RbspFabonGGeJE7IndXkS2 Hoh1AdR5XCPc7Hl3gxcR+C2wT1PTTzzQ6VAcjIP1kRN/pkCWXHV7iMqSXI59PsKuL8+W +Hsw== ARC-Authentication-Results: i=1; mx.google.com; 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=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s15-20020a170902b18f00b0015d04ca90d7si15581409plr.18.2022.05.17.01.58.11; Tue, 17 May 2022 01:58:23 -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; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235526AbiEQArN (ORCPT + 99 others); Mon, 16 May 2022 20:47:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44466 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234427AbiEQArJ (ORCPT ); Mon, 16 May 2022 20:47:09 -0400 Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A00A13E29; Mon, 16 May 2022 17:47:07 -0700 (PDT) Received: by mail-oi1-f180.google.com with SMTP id r1so20666995oie.4; Mon, 16 May 2022 17:47:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=iJgSIj5Vbgqm2lP3FwW0wvqzkGV+5Vch0R+WtavPeG0=; b=W6Iaxo2tTFnThXN2NtnFkpzgiSOSvv5Irqvx6XBdsnSbQcR4kQ1Q2l/rO+o76W0Ky6 Ncv5M4w6c/XHLsbqcUbZkd9CJb1/y+awEgq/Dd06FPkUwbCoqJaIteTFNyAzUmbv3sJU AhPzCeQ0p8AThNuf8Epc7ax6dfQkKIlunk61k3ShWNTbs3oHQXuiaXzSjMj58o1qN4pb YyJ9fKLbxqDzmRgpqEpfeiKR2+XxU93/sJwuP4vtAp3c48qvTaO2tkjG3HRUR2h6hrwX yu8IAaz72LGJPRq/jEq/1Pec8LFVRFqi3tqtnNWZ/DZyng5jm7+oJc2fv6WNCGriPMxW C3kA== X-Gm-Message-State: AOAM531qgZP4KLzD2R3a+N1zBPKPTaHFp/obln92Vq8pKQaBeEzaY9Xt PFzxpn8zxYEuZpMNtjWKwQ== X-Received: by 2002:a05:6808:1585:b0:326:6477:64b2 with SMTP id t5-20020a056808158500b00326647764b2mr9172703oiw.173.1652748426873; Mon, 16 May 2022 17:47:06 -0700 (PDT) Received: from robh.at.kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id g9-20020a05683030a900b0060603221248sm4499696ots.24.2022.05.16.17.47.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 May 2022 17:47:06 -0700 (PDT) Received: (nullmailer pid 3682863 invoked by uid 1000); Tue, 17 May 2022 00:47:04 -0000 Date: Mon, 16 May 2022 19:47:04 -0500 From: Rob Herring To: Andrew Lunn Cc: Mark Brown , LABBE Corentin , alexandre.torgue@foss.st.com, calvin.johnson@oss.nxp.com, davem@davemloft.net, edumazet@google.com, hkallweit1@gmail.com, jernej.skrabec@gmail.com, joabreu@synopsys.com, krzysztof.kozlowski+dt@linaro.org, kuba@kernel.org, lgirdwood@gmail.com, linux@armlinux.org.uk, pabeni@redhat.com, peppe.cavallaro@st.com, samuel@sholland.org, wens@csie.org, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@lists.linux.dev Subject: Re: [PATCH 3/6] dt-bindings: net: Add documentation for phy-supply Message-ID: <20220517004704.GA3654797-robh@kernel.org> References: <20220509074857.195302-1-clabbe@baylibre.com> <20220509074857.195302-4-clabbe@baylibre.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no 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 On Mon, May 09, 2022 at 06:38:05PM +0200, Andrew Lunn wrote: > > No, that's not a thing - the supplies are individual, named properties > > and even if there were a list we'd still want them to be named so it's > > clear what's going on. > > So we have a collection of regulators, varying in numbers between > different PHYs, with different vendor names and purposes. In general, > they all should be turned on. Yet we want them named so it is clear > what is going on. In what order do we turn the supplies on? How much time in between each one? Does an external clock need to be running before or after (and how long after). Oh, and what about resets and the order and timing of them relative to everything else? This always happens in the same order. First, it's just one resource like a regulator or reset. Then one more. Then another device with some timing constraints. If we wanted a generic solution in DT, it would need to be able to describe any power sequencing waveform. But we don't have that because we don't want it. > Is there a generic solution here so that the phylib core can somehow > enumerate them and turn them on, without actually knowing what they > are called because they have vendor specific names in order to be > clear what they are? Other devices have specific compatibles so that the device can be identified and powered up. Once again, MDIO should not be special here. > There must be a solution to this, phylib cannot be the first subsystem > to have this requirement, so if you could point to an example, that > would be great. Well, no one seems to want to make non-discoverable devices on 'discoverable' buses work. Still an issue for PCI and USB. I thought MDIO had a solution here to probe any devices in the DT even if not discovered. Rob