linux-kernel - Re: Concerns with em.yaml YNL spec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <081e0ba7-055c-4243-8b39-e2c0cb9a8c5a@lunn.ch>
Date: Thu, 11 Dec 2025 18:01:52 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Donald Hunter <donald.hunter@...il.com>
Cc: Changwoo Min <changwoo@...lia.com>, Lukasz Luba <lukasz.luba@....com>,
	linux-pm@...r.kernel.org, sched-ext@...ts.linux.dev,
	Jakub Kicinski <kuba@...nel.org>,
	Network Development <netdev@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Concerns with em.yaml YNL spec

On Thu, Dec 11, 2025 at 03:54:53PM +0000, Donald Hunter wrote:
> Hi,
> 
> I just spotted the new em.yaml YNL spec that got merged in
> bd26631ccdfd ("PM: EM: Add em.yaml and autogen files") as part of [1]
> because it introduced new yamllint reports:
> 
> make -C tools/net/ynl/ lint
> make: Entering directory '/home/donaldh/net-next/tools/net/ynl'
> yamllint ../../../Documentation/netlink/specs
> ../../../Documentation/netlink/specs/em.yaml
>   3:1       warning  missing document start "---"  (document-start)
>   107:13    error    wrong indentation: expected 10 but found 12  (indentation)
> 
> I guess the patch series was never cced to netdev or the YNL
> maintainers so this is my first opportunity to review it.
> 
> Other than the lint messages, there are a few concerns with the
> content of the spec:
> 
> - pds, pd and ps might be meaningful to energy model experts but they
> are pretty meaningless to the rest of us. I see they are spelled out
> in the energy model header file so it would be better to use
> perf-domain, perf-table and perf-state here.

We also need to watch out for other meaning of these letters. In the
context of networking and Power over Ethernet, PD means Powered
Device. We generally don't need to enumerate the PD, we are more
interested in the Power Sourcing Equipment, PSE.

And a dumb question. What is an energy model? A PSE needs some level
of energy model, it needs to know how much energy each PD can consume
in order that it is not oversubscribed. Is the energy model generic
enough that it could be used for this? Or should this energy model get
a prefix to limit its scope to a performance domain? The suggested
name of this file would then become something like
performance-domain-energy-model.yml?

	Andrew