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: <aa4ec16a-b35f-41b0-92f7-40b3eb64124a@kernel.org>
Date: Sun, 9 Feb 2025 21:50:37 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Mike Rapoport <rppt@...nel.org>
Cc: linux-kernel@...r.kernel.org, Alexander Graf <graf@...zon.com>,
 Andrew Morton <akpm@...ux-foundation.org>, Andy Lutomirski
 <luto@...nel.org>, Anthony Yznaga <anthony.yznaga@...cle.com>,
 Arnd Bergmann <arnd@...db.de>, Ashish Kalra <ashish.kalra@....com>,
 Benjamin Herrenschmidt <benh@...nel.crashing.org>,
 Borislav Petkov <bp@...en8.de>, Catalin Marinas <catalin.marinas@....com>,
 Dave Hansen <dave.hansen@...ux.intel.com>,
 David Woodhouse <dwmw2@...radead.org>, Eric Biederman
 <ebiederm@...ssion.com>, Ingo Molnar <mingo@...hat.com>,
 James Gowans <jgowans@...zon.com>, Jonathan Corbet <corbet@....net>,
 Mark Rutland <mark.rutland@....com>, Paolo Bonzini <pbonzini@...hat.com>,
 Pasha Tatashin <pasha.tatashin@...een.com>, "H. Peter Anvin"
 <hpa@...or.com>, Peter Zijlstra <peterz@...radead.org>,
 Pratyush Yadav <ptyadav@...zon.de>, Rob Herring <robh+dt@...nel.org>,
 Rob Herring <robh@...nel.org>, Saravana Kannan <saravanak@...gle.com>,
 Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com>,
 Steven Rostedt <rostedt@...dmis.org>, Thomas Gleixner <tglx@...utronix.de>,
 Tom Lendacky <thomas.lendacky@....com>, Usama Arif
 <usama.arif@...edance.com>, Will Deacon <will@...nel.org>,
 devicetree@...r.kernel.org, kexec@...ts.infradead.org,
 linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
 linux-mm@...ck.org, x86@...nel.org
Subject: Re: [PATCH v4 14/14] Documentation: KHO: Add memblock bindings

On 09/02/2025 21:49, Krzysztof Kozlowski wrote:
>>>>  
>>>> These are not devicetree binding for communicating data from firmware to
>>>> the kernel. These bindings are specific to KHO which is perfectly
>>>> reflected by the subject.
>>>
>>> No, it is not. None of the bindings use above subject prefix.
>>>
>>>>
>>>> Just a brief reminder from v2 discussion:
>>>> (https://lore.kernel.org/linux-mm/20231222193607.15474-1-graf@amazon.com/)
>>>>
>>>> "For quick reference: KHO is a new mechanism this patch set introduces 
>>>> which allows Linux to pass arbitrary memory and metadata between kernels 
>>>> on kexec. I'm reusing FDTs to implement the hand over protocol, as 
>>>> Linux-to-Linux boot communication holds very similar properties to 
>>>> firmware-to-Linux boot communication. So this binding is not about 
>>>> hardware; it's about preserving Linux subsystem state across kexec.
>>>
>>> does not matter. You added file to ABI documentation so you must follow
>>> that ABI documentation rules. One rule is proper subject prefix.
>>  
>> No, it does not. It's a different ABI.
>>
>> FDT is a _data structure_ that provides cross platform unified, versioned,
>> introspectable data format.
>>
>> Documentation/devicetree/bindings standardizes it's use for describing
>> hardware, but KHO uses FDT _data structure_ to describe state of the kernel
>> components that will be reused by the kexec'ed kernel.
>>
>> KHO is a different namespace from Open Firmware Device Tree, with different
>> requirements and different stakeholders. Putting descriptions of KHO data
>> formats in Documentation/kho rather than in
>> Documentation/devicetree/bindings was not done to evade review of Open
>> Firmware Device Tree maintainers, but rather to emphasize that KHO FDT _is
>> not_ Open Firmware Device Tree.
> 
> 
> Ah, neat, that would almost solve the problem but you wrote:
> 
> +$id: http://devicetree.org/schemas/memblock/reserve_mem.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> 
> so no, this does not work like that. You use devicetree here namespace
> and ignore its rules.


... and that obviously is barely parseable, so maybe one more try:
"You use here devicetree namespace but ignore its rules."

> 
> You cannot pretend this is not devicetree if you put it into devicetree
> schemas.

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ