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 80ABCC433EF for ; Mon, 9 May 2022 16:39:40 +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=lT90GW0KluwkOt8oGlXx2zg2QLnREtel1qmzTJqMOok=; b=473/JJWFcpck+Z YNgRhMTqh1Xu3Z2OyvMx8IPo+U4fYwHUTfxwUiC0BMbhUuBhZISnDE0CGQXg1mfffAN8TngicC40z 3eQA/WbhJB7LBZ7jlSEkf3SRlG4sPXs/prvUrB+6DA0KZjDNALnQJXo1NT/AiLkVhB0BfkjTlWmZu CDcpMxDRLH12skriNwFngUMJA8Xka5vjlzSSjPJyoXI9aq9Ehku6Km6xmS0cgwegKKAgumdbpEUoR 5Yy97ss7orxEumeWrxxSH/VcXR49hf3fzhze3ERD2x7zTUHtHoOkjjRH60OiV6Uo9ywBE745g43m7 6BYMcx9XdaJBL+pD5iUA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1no6P3-00FSFO-D5; Mon, 09 May 2022 16:38:33 +0000 Received: from vps0.lunn.ch ([185.16.172.187]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1no6Oz-00FSEa-QV for linux-arm-kernel@lists.infradead.org; Mon, 09 May 2022 16:38:31 +0000 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=OMlL5sJMjzT5uQRcMqiBjPCY3eHb3CrezL2DCRa3GHM=; b=LX6v0B4l2dCWZCYAohU+v4FKmO FzwWZPEXm0jIfusbne39tuxb6d5HiYw1ga1u5oXBRwEhd9oWTnETsWrfh/Gw9GG+TgJOZeMCS27Ky Sp4gFtHFwhyAdgrebE4RbqdiS3AQQOmntmol1hcB4K624/Zkhk527rv16yCKJ68JTD98=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1no6Ob-001yY5-My; Mon, 09 May 2022 18:38:05 +0200 Date: Mon, 9 May 2022 18:38:05 +0200 From: Andrew Lunn To: Mark Brown Cc: 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, robh+dt@kernel.org, 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: 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-20220509_093829_897279_3E2AB218 X-CRM114-Status: GOOD ( 10.18 ) 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 > 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. 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? 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. Thanks Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel