From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C5A87470E8F for ; Wed, 22 Jul 2026 19:49:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784749769; cv=none; b=Ze6iqsXHwhJuXbp/+HQTp4U1fsX/KNwM+e/O1HBj7mMGl9B1iSMHO83zcNJff1jAC/gv21IVTVkfMNsiIcedgKa3BALr8+Cvio/cHgPCKAb57uQJX9DRosr3MklRUHzBqkai+CU3iMN8MlwD9iK79GZdu+tVfAqD05OM7yQ4Kjk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784749769; c=relaxed/simple; bh=DIypUq1aJTPaT29le8aCgDPQ3iCMvwD2dB3kusCe9rY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=QAHbrwD1VF6Ri+aAIa5IeTxMv5bOek+HKRR00tz7UciAFpPXvRHjOzfY5kMnBYV7uvZvGwTQ7JRkos6Jbw1Tb9n3l7G5VNJkO4XI+N4uFctZhABcnfopMDc+uf58fbQcfZ4ibcDf8CkvhEZwLBj7OFPMvO2xTJnm3t84Tt4c6xc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=elwoGOhJ; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="elwoGOhJ" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-49548e01d02so27716435e9.0 for ; Wed, 22 Jul 2026 12:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784749766; x=1785354566; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=jxGkMmrfkSCmCjSyz4Fz4f0WolkDFwEimPgOqfycITM=; b=elwoGOhJmTy7zCjxXnKHVj+k3Ey0M+VMBNSZRSsRqlh5s0Sspj4e9KDlXzbobtWwfr A/Tq6JpFU4LQnqdnfoptoFO7LP0syEslbLJAFx2/rxpo4N9TAbEMp0CTLevIx6k9hiwQ /e3OukE/OO3Q8+JJpB9xZu0ASnJzmQYYCckcdYdq7IP+ZX2y54+h16vZ7Q3kQMMhww1t GQmcE9USUxS/zyAUO4f2V5/A8FEKwcJT6LcyNNssIYI3XeO8bq1rkpIe/6OOQT4W76ZB ZLFNpPrxjZCusVj2E8mOR5sHfiBW28RFeJghuffObCnWlGLL23dzOwIcNw46iVrZUf0S dSfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784749766; x=1785354566; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=jxGkMmrfkSCmCjSyz4Fz4f0WolkDFwEimPgOqfycITM=; b=qSbBo0vmyuRs7Tow7c+M5mHW2KPjjuUXU4gjjoQv3IGWXQR/lB33tz2S4d55PMLRBc eb6nwwCBHOFeSNP98P8u6IciP6VlAZms82DhLsPhQEvq5E4v53UhOfICINPyvrDDBQnm MBjY0UK5zom1MFxhFOon/TXxfdJQmlCcc4oSr338yO3amfmFMh2GoWvNo/NNyn6/m6re wYxr6rlaJI4vZTeJP7X4HFH/u0hYGGqa6vchcmwfyxGXMXKsOCqxJzzeYdlQAeZTaoza VXY7U93iPjybXRhyd2sVugtIziFwC+mEkCnHdYMbX/y6hEx3PUYhdrpaQhxaZSYtS06n nqCA== X-Forwarded-Encrypted: i=1; AHgh+RoCmv0egQymcc+p2bX1iavmn+RACT8XMXOIHkCDPR81QO+4HsG/OcT0TyD86lfEz7HFVjqQ5gsx4lg+Gms=@vger.kernel.org X-Gm-Message-State: AOJu0Ywn3puID4ZqULvCQxwCJsjfQfaMtLLwV7szKgXhFPeFVVkmTNjV LAevQm7Dl0MI9OVBmoI6v5r3Ca2RpjJs+XC/LyEUvneoXCQY55VOgPyQ X-Gm-Gg: AR+sD1210CXcB/Yn64+cct17UUkxf1K6nhokrsf0HYwOAmleZhbY+LW+5XKYoXJSMlr PtZGesPMzvxf1AQCgdibdYKCdmxlbJZVRqYsCuUcP0RLq+F7EHDHCkFX1Nkdh+DNn8vn4WOSGT/ dZweZ1Xwx5c6XDooTK4uZFvB58oOmtysjKkmiKH2gtHbfXK6+NeMvX1cfUebeLKtwbEwND6oglD t/iLllDlabWKpjSFOUsJqj/oLtROrfUrBCd90KDfG0z3sTENJ687Q7hbScWcpUmZ/8hkc0mjOnS +YmtPpWbpIk1GEwjGPwMMMmLdBXuA+7WCPjZ4AZs7fb43O94dUfmuNXnXUXXbTdhWvHPfS101t4 +yMKniFRZ/JBJ92/7h91EgZcRrQqKblLuige/rM9EanvzOjOcCLPcljv5BdCIY4d8jGzG7wEmHZ wh0YhEaUQKfvdGMjveSCWLDBOtgqRvzK9AzTsdaipXGonAVCBXuLuWm6NsekG5mpPzpVOgLG7rY Ow0 X-Received: by 2002:a05:600c:2211:b0:495:6b78:6f4 with SMTP id 5b1f17b1804b1-49573cc2102mr920475e9.8.1784749765825; Wed, 22 Jul 2026 12:49:25 -0700 (PDT) Received: from ?IPV6:2001:9e8:f117:4301:646f:5fa9:4c84:901e? ([2001:9e8:f117:4301:646f:5fa9:4c84:901e]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f85b9a64dsm9204964f8f.1.2026.07.22.12.49.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Jul 2026 12:49:25 -0700 (PDT) Message-ID: <3f71640b-9f22-4d0b-9c4d-dc64c397d286@gmail.com> Date: Wed, 22 Jul 2026 21:49:24 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v8 1/4] dt-bindings: net: pse-pd: add bindings for Realtek PSE MCU Content-Language: en-US To: Sander Vanheule , Oleksij Rempel , Kory Maincent , Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Daniel Golle , =?UTF-8?Q?Bj=C3=B8rn_Mork?= , Conor Dooley References: <20260715075530.2491534-1-jelonek.jonas@gmail.com> <20260715075530.2491534-2-jelonek.jonas@gmail.com> From: Jonas Jelonek In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, On 22.07.26 19:49, Sander Vanheule wrote: > [...] > >> +  power-supply: >> +    description: Regulator supplying the PoE power rail. > As I reported to Jonas earlier [1], I used this property to define a power > supply for the 54V rail. While everything was working nicely, I still got this > warning for the missing vpwr-supply property on the PSE-PI nodes: > > regulator regulator.2: supply vpwr not found, using dummy regulator > Of course I don't like seeing warnings when everything is seemingly working > fine, but I was also wondering if this duplicated way of providing the PoE power > rail is a good way to go forward and if the generic pse-pi@n/vpwr-supply > shouldn't just be used instead. The latter is admittedly more verbose, with a > property on every node, but going forward offers a few advantages IMHO: > * Being able to reserve "power-supply" on the main node for the MCU's actual > 3.3V regulator (not needed anywhere at the moment AFAIK) I would probably rename this, mirroring the PD692x0 naming. "power" is actually too blurry, leaving too much room for interpretation. Still keeping its purpose to reference the supply that serves the PoE rail for this MCU with its downstream PSE. Reasoning below. > * Being able to take advantage of the generic pse-pi framework evolving to take > into account more properties of the parent regulator, such as requesting more > power, or ensuring the parent supply is not overdrawn by the combined PSE-PI > outputs. Correct me if I'm wrong but from what I see, most of that budgeting machinery isn't used in dynamic budget evaluation strategy, which is used here because the MCU does budgeting on it's own. Using vpwr-supply on each PI still buys that the supply is enabled and ref-counted by PSE-PD core, and keeps potential for what might come. But no requesting, allocation or deallocation of power. Given that, I had a closer look at PD692x0 and it seems, this has a similar setup. The difference here being just that there's no multi-manager concept. There is also a manager-level supply reference "vmain-supply" which the driver reads and applies to the hardware, which does budgeting also in hardware. Based on that, I would just adjust the binding to more suitable name for the supply. Implementing the power budget application to the MCU is fine for a follow-up. All boards I've worked with so far already have a pre-set safe budget in their default configuration, avoiding any potential issues or physical damage due to overload. > [1] https://github.com/openwrt/openwrt/pull/23222#issuecomment-5032841546 > > Best, > Sander Best, Jonas