From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (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 116773A7F50 for ; Fri, 24 Jul 2026 07:18:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784877531; cv=none; b=gKPzpTkmPVIpwtl2FDu3O+OWNGpf+7T+GHDXsroq0a3WO0wxasiC13hCndfu9QjJyGzuOD2pBeuA5jZX8h2i9qWiAGQzrt0tY93t4ZQmSFhc5eHomP1EcXNGK06reSa8I2h629o7Y3g72+Bzp7vu/Mk35lsaXEbXvZonlovBiQ4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784877531; c=relaxed/simple; bh=OADtKjXuEnpdtdROI1zJm6WD/sxOV8pEklUgAu6sTVg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=D30iRG9Ry/i1OTBsmDJVOGtiQkA8Uvy0m75rQSrU30DqU19aOy3g2qpp09ksoeY9KKxN8A1Nst8pqAa+A55JVYruhlwTJemsiwg6VHzSZK2ukOnK47hP0SSVs5E9rEa7Y5RKdpF+8MSwPhwyw9U+EhmES4z1h5NmFro/rdBxdkw= 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=Ln9NDP0F; arc=none smtp.client-ip=209.85.221.51 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="Ln9NDP0F" Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-47c2b362ee2so109395f8f.1 for ; Fri, 24 Jul 2026 00:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784877527; x=1785482327; 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=iPrcNCAFpSMjvRTC4lqNm690NiiTuf14UlgUWIGL5FM=; b=Ln9NDP0FaONqFLTD6DllOHERZPAg5Po96u7+FatW66FAQmqVeavjGktq2vmKqqJbLO wv1W1gy2Ksjp+YqbDPbJiAK4pLSCp3/CKZ3mIzz0CSEJm0CuTv1Q5yX6SCCWnHveHBA/ RI2TzBm1O5dCkiE5bXgT6xo5FVrVFGjsThpzdsE+DRB76VqlkbhGVtxARm7GaEMVHgQM i2LQzTgW3b2mOvJL9I+EWHn6O29kaF+Bcbp65O4sLf6XVoZhAKV1QuReojB8I0Mfoe+8 UR/g/8kCImM0dA53EdARexpXnrjYJ5VdeDJ9qXc+SJniyq6s3YDEj+itTHlwRTID08Mg s+BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784877527; x=1785482327; 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=iPrcNCAFpSMjvRTC4lqNm690NiiTuf14UlgUWIGL5FM=; b=hGJsY//hd1AP7qHRiwlNTOgmS/Bw88PWnT0hOH/Gfa87kIgujvKIkQQ3gysoWKnFWU vEY0/PW8qu8u+IVSX+MV5h8PEFImFrA3zRgzC8Lub/eA8iCoIOWRq44YdOHiiIHTY4C5 39K3dcoFH/ML0SFG49J8rLSBHgwTl3fx9ct6QnIfG9bRsEWzX401QW3Ga5e/fEhqV2Af wemJ83b8DcTjQrtRdp+zY/Ai54/aFPuX+LN4Ef7EmV4LlRPiyCIG+2O7tFiHuP0QAwn8 6cypI8zUnfEWyiP2bxWD7YyHzac0KZIGS77vB8bvIQqy7j+7ee6HE6KJY9es3/OeYAoF uUqg== X-Forwarded-Encrypted: i=1; AHgh+RrCpZE3MYj3rYNMUDXmhVzRxukL1DnhIEpzWHM5YHLOIBYaxsDa7joOrX6DBSW1KJpKPP1o3loukfVTNHE=@vger.kernel.org X-Gm-Message-State: AOJu0Yw4EJqSHexQ8MTqdnSMgw45AEFwLCOHsQ1AuFP9HuPHguScPwKH z23j5SFzSHOlErpISYnVRbgRq4mmV6A5Srqx5SITUXIXp8XS72sE9BDZ X-Gm-Gg: AR+sD13BMa4btW0eKOm2qHKBY1wIYulBEKn5GNrg2lqHqaFo1F+QeuROfafBj67h8eU 0lvYx/9U1RvsMR5zEr3AoB6jJ0iBbu5tnQ0IM7QxkvmxU5+o+CVd8nwm3r7VBf19vYoWkq0fIEQ Jrk4wIGg7v8GUO0fY5FAtzSYUKyklXrqOM1mvNKnJDVXiKGPmOoKaBulNnKmADdcdemZfLuRRUr LhM8ehH/Juz1C6QPOJCsniEwA1LfbuNkGg/EhqMJ7A6YrWgjmvVcsD6s+i52AMCIhn7cD3Rm+KB duIfKmNhuEXw1pPyjvPES5d4KOAJWCtYqWvX0O6ixzA89HGkz0TTOd5uNCxkLHJLD1WER3EPEjJ Vrf9/eaVpdakv4lY/5EbcaED/08ib+Pl9NdUz4LT+BujARv0/AtGMB1xLP6STpZRPvIMYs+WW5e +Yg/8apBppr7pv3sDMzotT0p0Pgc2xgAoBmsG6lrSZcqWu5Nw+gHm77BnzPL5WD540n/nzeXnTG REn6WbK7Q++ X-Received: by 2002:a05:6000:4a17:b0:47f:5c33:5eb9 with SMTP id ffacd0b85a97d-47f8d7702d1mr7536638f8f.52.1784877526867; Fri, 24 Jul 2026 00:18:46 -0700 (PDT) Received: from ?IPV6:2001:9e8:f123:1f01:c8e:3904:f911:945d? ([2001:9e8:f123:1f01:c8e:3904:f911:945d]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f85b9a596sm22254724f8f.4.2026.07.24.00.18.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Jul 2026 00:18:46 -0700 (PDT) Message-ID: Date: Fri, 24 Jul 2026 09:18:45 +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: Oleksij Rempel Cc: Sander Vanheule , Kory Maincent , Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , 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> <3f71640b-9f22-4d0b-9c4d-dc64c397d286@gmail.com> From: Jonas Jelonek In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Oleksij, On 23.07.26 12:20, Oleksij Rempel wrote: > On Thu, Jul 23, 2026 at 11:45:20AM +0200, Jonas Jelonek wrote: >> [...] >> What do you suggest? I would like to avoid doing any half-grounded claims >> or assumptions here while not fully overviewing the whole picture. At the same >> time, I have the feeling the datasheet and host command guide from Realtek >> are genuinely trying to fool me. >> >> The setup seems to be very similar to PD692x0, we have multiple managers, >> managed by a controller (the MCU). The MCU mostly does runtime discovery >> of the downstream managers, so right now there is no apparent need to >> have the same manager + port definitions in DT as PD692x0. >> >> In reality I haven't seen a board which has different power rails for different >> managers. So there's usually a single wire from the PSU going to the PoE >> daughterboard where everything lands on a single supply PCB trace. The MCU >> has a multi-bank concept, however it's usage right now is rather confusing. >> Managers seem to have strapping pins which tell which bank they use, and on >> the MCU side one can set power limit for each bank. > Current PSE framework already has a concept of power domain. Depending > on implementation, the "manger" can be the weakest point in the chain. > For example: one manager has 8 ports and can handle 200W, we have > devices with 2 managers each 200W max and PSU providing 500W. If we > attach 3 devices 100W each to ports 1, 2, 3 - will not work for the last > one. If we attache them to ports 1, 2 + 9, will work just fine. Because > it is attached to different power domain/manger. > > Even if this information is hidden in the MCU. It is usable for admins, > to understand what combination of ports should be used for optimal power > delivery. It is not hidden, but I see two ways to surface this right now: (1) Someone figures is out once per board and puts that topology in the DT. (2) Runtime topology detection, the MCU tells us how many managers we      have, which downstream addresses they have and which port lives on      which manager. I'm not sure what is preferred, having it in DT or using runtime detection if possible. >>> Since we already talk about power budgeting - all of this make sense if >>> we have port priorities. For example PD692x0 firmware has default prios >>> bound to port numbers. Is it the same with this firmware? >> Looking at several switches, by default all ports have a priority of 0 assigned. >> Thus, no pre-defined prioritisation, it's up to the user to set this. > Do this switches have PSU covering all port at max load or it is over > provisioning by design. In most cases it's overprovisioned by design, the PSU budget is usually lower than what would be needed for all ports at max load. Even one of my switches, having a PoE budget of 400W, has 8 ports with 32W and 16 ports with 60 W, managed by 5 managers. Usually a manager is not overprovisioned but the system PSU is. > Haw it behave in reality If we attach more > consumer then it is able to handle - all ports go off, or only some of > them? That's a good question ^^. Unfortunately, I do not have enough PoE-powered devices here to test this scenario, or at least it takes a bit of time to get enough devices. > > PD692x0 firmware has user configurable prios - but if many ports share > same prios it has internal prios based on port number. > At least I'm not aware of that but since the firmware on the MCU is a blackbox, in the end this could be the case too. But it's not an obvious feature. I'd like to slightly adjust the bindings, given the confusion about the naming that came up with Sander. Is there anything else that should be changed? Or is everything else in terms of supply, budgeting, etc. fine for follow-ups? Best regards, Jonas