Re: [PATCH v8 03/10] dt-bindings: reserved-memory: Wakeup Mailbox for Intel processors

[Ricardo Neri <ricardo.neri-calderon@linux.intel.com>]

On Wed, Jan 07, 2026 at 05:23:51PM -0600, Rob Herring (Arm) wrote:
> 
> On Wed, 07 Jan 2026 13:44:39 -0800, Ricardo Neri wrote:
> > Add DeviceTree bindings to enumerate the wakeup mailbox used in platform
> > firmware for Intel processors.
> > 
> > x86 platforms commonly boot secondary CPUs using an INIT assert, de-assert
> > followed by Start-Up IPI messages. The wakeup mailbox can be used when this
> > mechanism is unavailable.
> > 
> > The wakeup mailbox offers more control to the operating system to boot
> > secondary CPUs than a spin-table. It allows the reuse of the same wakeup
> > vector for all CPUs while maintaining control over which CPUs to boot and
> > when. While it is possible to achieve the same level of control using a
> > spin-table, it would require specifying a separate `cpu-release-addr` for
> > each secondary CPU.
> > 
> > The operation and structure of the mailbox are described in the
> > Multiprocessor Wakeup Structure defined in the ACPI specification. Note
> > that this structure does not specify how to publish the mailbox to the
> > operating system (ACPI-based platform firmware uses a separate table). No
> > ACPI table is needed in DeviceTree-based firmware to enumerate the mailbox.
> > 
> > Nodes that want to refer to the reserved memory usually define
> > a `memory-region` property. /cpus/cpu* nodes would want to refer to the
> > mailbox, but they do not have such property defined in the DeviceTree
> > specification. Moreover, it would imply that there is a memory region per
> > CPU. Instead, add a `compatible` property that the operating system can use
> > to discover the mailbox.
> > 
> > Reviewed-by: Dexuan Cui <decui@microsoft.com>
> > Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> > Acked-by: Rafael J. Wysocki (Intel) <rafael.j.wysocki@intel.com>
> > Co-developed-by: Yunhong Jiang <yunhong.jiang@linux.intel.com>
> > Signed-off-by: Yunhong Jiang <yunhong.jiang@linux.intel.com>
> > Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> > ---
> > Changes in v8:
> >  - None
> > 
> > Changes in v7:
> >  - Fixed Acked-by tag from Rafael to include the "(Intel)" suffix.
> > 
> > Changes in v6:
> >  - Reworded the changelog for clarity.
> >  - Added Acked-by tag from Rafael. Thanks!
> >  - Added Reviewed-by tag from Rob. Thanks!
> >  - Added Reviewed-by tag from Dexuan. Thanks!
> > 
> > Changes in v5:
> >  - Specified the version and section of the ACPI spec in which the
> >    wakeup mailbox is defined. (Rafael)
> >  - Fixed a warning from yamllint about line lengths of URLs.
> > 
> > Changes in v4:
> >  - Removed redefinitions of the mailbox and instead referred to ACPI
> >    specification as per discussion on LKML.
> >  - Clarified that DeviceTree-based firmware do not require the use of
> >    ACPI tables to enumerate the mailbox. (Rob)
> >  - Described the need of using a `compatible` property.
> >  - Dropped the `alignment` property. (Krzysztof, Rafael)
> >  - Used a real address for the mailbox node. (Krzysztof)
> > 
> > Changes in v3:
> >  - Implemented the mailbox as a reserved-memory node. Add to it a
> >    `compatible` property. (Krzysztof)
> >  - Explained the relationship between the mailbox and the `enable-mehod`
> >    property of the CPU nodes.
> >  - Expanded the documentation of the binding.
> > 
> > Changes in v2:
> >  - Added more details to the description of the binding.
> >  - Added requirement a new requirement for cpu@N nodes to add an
> >    `enable-method`.
> > ---
> >  .../reserved-memory/intel,wakeup-mailbox.yaml      | 50 ++++++++++++++++++++++
> >  1 file changed, 50 insertions(+)
> > 
> 
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> ./Documentation/devicetree/bindings/reserved-memory/intel,wakeup-mailbox.yaml:23:1: [warning] too many blank lines (2 > 1) (empty-lines)

This got triggered by an empty line in an patch already reviewed by the DT
binding maintainers. Previous versions did not trigger this warning since
the check to allow at most 1 empty line is rather recent.

Would it be possible for the review proceed? I am happy to post a new version
fixing this after the rest of the patches have been reviewed.

Thanks and BR,
Ricardo