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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 771E3C433EF for ; Tue, 17 May 2022 00:48:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=XwVZd9JmqeCur8pJfxQNgUKjKlTVdokuPONYnV8Hnrc=; b=BnZjligfLi5On6 ZcCTHif18J006t0a2tcBFRPrAVfk9KXrOAlYtSKQgrrEVwjd+q1MbHDh/3+GDaU2rG1in9nRz0ll4 A+9IMGuPNI8Z0rnnaeGt6dWF9dvrQ1yqT/ihxxib2fdyyOuX3x/2BL6LoRsBRxpfzSCr56EvG7llR +If8WD1sSLDWks2fM7qnYX7eSzXOqY0zi9rtB0rIhrsOkMhu8xaaquKZffrsOBd3D/mdIGQutoZVU cXcix/amo96ep9Q/0Rq8FOVB4fTftSM+uw8WxZatJLZ1j4C5bRxnu+cxQtT82sY243Mr+M881lr2O JcZ7TX+9H0Mcz17rmYRw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nqlMj-00B247-VV; Tue, 17 May 2022 00:47:10 +0000 Received: from mail-oi1-f172.google.com ([209.85.167.172]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nqlMh-00B23J-KJ for linux-arm-kernel@lists.infradead.org; Tue, 17 May 2022 00:47:08 +0000 Received: by mail-oi1-f172.google.com with SMTP id e189so20652212oia.8 for ; 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=XJQ5OXp9Rg+E+vsTjm/gTgzr9pKsc+q4vCf3vH5/D9qaqG2idSIxbnonPqGLXf+mbc 6EVJ9lMe0DuSeh6lKVNuaXOHExSHBqn7VpCzssMNP9NqSZT2LrDtP7Lp6LRWvZP8Ky7X +RWpP6VdSJkB3U16OhADKV6Kl2sTEz5NSWnxPKTd6LibVcm9SaD2YyMF0D6hTcfHQQiO b4QFIqDbDu3Sei1XvU/K50BVir5Dx7iGq3EfV4jx3Z7GoDHi41WwA4M0deH+nQ063Nr4 2M7/ugl+9LWpqOg41Q4SQFiDCASoLtdIG8jpV0MqqR2WsLS/wPYq1F765hKS3GktB3T1 62eQ== X-Gm-Message-State: AOAM532eNsaF0BVgRhbMxGaAO4n/Ht4GufapEkKmTYiZu3dkyh5Jn5BS AiMk3iBNX6FyUZyam5G4xA== X-Google-Smtp-Source: ABdhPJzxUe7lRWwSsk4LYTIlf0trAXfo6l1O3t5y3u2IE0dc+3FfnlSJCRjFtF4GffGFbK7487ochw== 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-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220516_174707_705573_2D6149CE X-CRM114-Status: GOOD ( 21.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel