linux-kernel - Re: [PATCH v10 3/4] firmware: ti_sci: Introduce Power Management Ops

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] [day] [month] [year] [list]

Message-ID: <20240829180519.bftb7qxh4oj65oew@postnasal>
Date: Thu, 29 Aug 2024 13:05:19 -0500
From: Nishanth Menon <nm@...com>
To: Markus Schneider-Pargmann <msp@...libre.com>
CC: Kevin Hilman <khilman@...libre.com>, Tero Kristo <kristo@...nel.org>,
        Santosh Shilimkar <ssantosh@...nel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        Vibhore Vardhan <vibhore@...com>, Dhruva Gole <d-gole@...com>,
        Akashdeep Kaur
	<a-kaur@...com>
Subject: Re: [PATCH v10 3/4] firmware: ti_sci: Introduce Power Management Ops

On 10:47-20240829, Markus Schneider-Pargmann wrote:
[...]
> Thanks for explaining. So should I add the header already with this
> series although it is unused right now, or should we add it together
> with the first actual user later on, so there is no unused header in the
> meantime?

Thinking deeper: we have two options:
a) dt bindings update with the property without knowing how the driver
  changes will be accepted or not.
b) drop the header changes for the macros.

I think (a) at this point is risky given the driver usage model is
un-clear - the APIs are abstract enough to be used in any way of choice,
but we do not want to be stuck with binding that then has to be
backward-forward compatible fixup..

So. (b) is better approach, IMHO..

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D