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 EA05FC433F5 for ; Thu, 19 May 2022 20:19:26 +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=a8jtaup+PWCJSCi6BeDqb3ZfnAp2wtf92zzy57+1S0Y=; b=snhGN2LqgKFPCe PHQPJbBmK1V4gWP+stK4dToFEckE2YWe7WSCbbUYi1fJ3YhnTG3AhQYwRCysO0/tEHa4kq+MrCUpS 9qnKW2h/DF8L7vjeCeefpNuf+VdGtsQ8IsS6EvO7Ya/knbtP3DI64raAWgk2zQsYxyy6t3gNS+mIx yEHy00jHTxuPIsS9+R1SDpAz/2Nt1A2c11Y5KI2Naze1GPqwblZ0a4DZ9B3zfbdXNEUQRiMre+25G etqcpEl1itO+3JJkc0tfqAPXkoBCrtTh8L0498GvuBF92Zy5wqu242hZMWtaFuRngMFXohZFL7ZB8 LQa1DVOP1cLGHCqtGFVQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nrmb0-009DYg-5f; Thu, 19 May 2022 20:18:06 +0000 Received: from mail-oi1-f181.google.com ([209.85.167.181]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nrmax-009DXk-KV for linux-arm-kernel@lists.infradead.org; Thu, 19 May 2022 20:18:05 +0000 Received: by mail-oi1-f181.google.com with SMTP id t144so4529138oie.7 for ; Thu, 19 May 2022 13:18:01 -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=cpK/mxaaT61izHttPyCO54/paPZjEWsIdeOzJUvSPcc=; b=c/1kBORx6MKGklIQV+GSMkAtLshj0OyXaB+50Ol1pn/r7dMlwhLUxhCwu6iP4mrAmn FLbFJHnbU6pN7NIIRjNx2ULaU9141WyvpEoPU/r3a/tlHMfXTYT036ZB9aPaokYXmX8f tSnDEraBwDQzshahsSyTy2eoAkewrnu2KKREMPyDpCKAZqntVXy+FbSOxzKMWN/ceTJx mP+rDaTRV7aDVOPeQXUZVmaClelCI3v5cEHXO7GpsOVBZDIfKL2/ojkQADSQO5VetFPM a3HBrkOrxkFbjHDEkyeZqWLn1Uo1IJpL8VOqpitKn3+HZzrCs6xedIPFm+LkrtnxZY/2 Nh8Q== X-Gm-Message-State: AOAM531RRVe4KOoK1eo4iMa9hzfnomawL8MzT269bUu/8dZeb39SOhvv b5CFyuP2H1e72W4DrV3Fvg== X-Google-Smtp-Source: ABdhPJy2uy9qx4ESthKjZkWWf/xwQRdL3or4oVwIkBE3FEdvEGXq0yBS6KMNDhB9omyT6IZBbAg1Tw== X-Received: by 2002:a05:6808:1b13:b0:326:8545:bc60 with SMTP id bx19-20020a0568081b1300b003268545bc60mr3747171oib.286.1652991481217; Thu, 19 May 2022 13:18:01 -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 l63-20020aca3e42000000b00326e6ac9f79sm106147oia.46.2022.05.19.13.17.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 May 2022 13:18:00 -0700 (PDT) Received: (nullmailer pid 2122452 invoked by uid 1000); Thu, 19 May 2022 20:17:59 -0000 Date: Thu, 19 May 2022 15:17:59 -0500 From: Rob Herring To: Andrew Lunn Cc: Krzysztof Kozlowski , Mark Brown , Corentin Labbe , calvin.johnson@oss.nxp.com, davem@davemloft.net, edumazet@google.com, hkallweit1@gmail.com, jernej.skrabec@gmail.com, krzysztof.kozlowski+dt@linaro.org, kuba@kernel.org, lgirdwood@gmail.com, linux@armlinux.org.uk, pabeni@redhat.com, samuel@sholland.org, wens@csie.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@lists.linux.dev, netdev@vger.kernel.org Subject: Re: [PATCH v2 4/5] dt-bindings: net: Add documentation for optional regulators Message-ID: <20220519201759.GC2071376-robh@kernel.org> References: <20220518200939.689308-1-clabbe@baylibre.com> <20220518200939.689308-5-clabbe@baylibre.com> <95f3f0a4-17e6-ec5f-6f2f-23a5a4993a44@linaro.org> 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-20220519_131803_728656_42292A32 X-CRM114-Status: GOOD ( 34.19 ) 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 Thu, May 19, 2022 at 01:58:18PM +0200, Andrew Lunn wrote: > On Thu, May 19, 2022 at 01:33:21PM +0200, Krzysztof Kozlowski wrote: > > On 19/05/2022 13:31, Mark Brown wrote: > > > On Thu, May 19, 2022 at 11:55:28AM +0200, Krzysztof Kozlowski wrote: > > >> On 18/05/2022 22:09, Corentin Labbe wrote: > > > > > >>> + regulators: > > >>> + description: > > >>> + List of phandle to regulators needed for the PHY > > > > > >> I don't understand that... is your PHY defining the regulators or using > > >> supplies? If it needs a regulator (as a supply), you need to document > > >> supplies, using existing bindings. > > > > > > They're trying to have a generic driver which works with any random PHY > > > so the binding has no idea what supplies it might need. > > > > OK, that makes sense, but then question is why not using existing > > naming, so "supplies" and "supply-names"? > > I'm not saying it is not possible, but in general, the names are not > interesting. All that is needed is that they are all on, or > potentially all off to save power on shutdown. We don't care how many > there are, or what order they are enabled. > > Ethernet PHY can have multiple supplies. For example there can be two > digital voltages and one analogue. Most designs just hard wire them > always on. It would not be unreasonable to have one GPIO which > controls all three. Or there could be one GPIO for the two digital > supplies, and one for the analogue. Or potentially, three GPIOs. Again, it's not just supplies... > > Given all the different ways the board could be designed, i doubt any > driver is going to want to control its supplies in an way other than > all on, or all off. 802.3 clause 22 defines a standardized way to put > a PHY into a low power mode. Using that one bit is much simpler than > trying to figure out how a board is wired. > > However, the API/binding should be generic, usable for other use > cases. The binding should not be generic as I explained here and many times before... > Nobody has needed an API like this before, but it is not to say > it might have other uses in the future. So maybe "supplies" and > "supply-names" is useful, but we still need a way to enumerate them as > a list without caring how many there are, or what their names are. There's 2 standard patterns for how producer/consumer bindings work There's how gpio and regulators are done and then there's the foo/foo-names style. Regulators when with the former and we're not going to do both. You can still do what you want by retrieving all properties ending with '-supply'. Not as easy to implement, but works for existing users. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel