Please post complete ast2700 SCU binding - what children do you have? If
none of ones mentioned in the binding apply, then why the binding
mentions them? why do you allow p2a if 2700 does not have it? And
smp-ram?

Yes, on reflection the approach taken so far is not particularly helpful,
as the binding has been extended incrementally without clearly defining
which SCU capabilities should appear in devicetree.

And if 2700 has silicon-id, interrupt controller, pinctrl etc, then why
none of them were present in the example you added?

You're right that the earlier example was incomplete. The example was
added while extending the binding for pinctrl support, and it did not
reflect the full set of SCU capabilities.

But more importantly, none of this was actually built tested/checked
against DTS thus I cannot accept it. We are back to basics... post your
COMPLETE DTS somewhere and provide link to it.

The AST2700 devicetree integrating the patches on the upstream lists is available here:

https://github.com/billy-tsai/linux/blob/integration/ast2700/arch/arm64/boot/dts/aspeed/aspeed-g7-common.dtsi

This isn't yet the complete description of the hardware you asked for,
that's something we need to better develop. To address that, I think we
can break the full set of SCU0 capabilities down into the following
groups:

Providers:
- SCU interrupt controller (0x1c0-0x1c8)
- Host 0 interrupt controller (0x1d0-0x1d8)
- Host 1 interrupt controller (0x1e0-0x1e8)
- Resets (0x200-0x240, 0xf00-0xff8)
- Clocks (0x240-0x2f0, 0x300-0x3b0)
- Pinctrl (0x400-0x718)
- SW scratch registers (0x7b0-0x800)
  - `reg` describes the scratch register region that might be useful
  elsewhere?
    
Consumers:
- SSP control (0x120-0x160)
  - Reserved memory regions to map into SSP address space

- TSP control (0x160-0x1c0)
  - Reserved memory regions to map into TSP address space

- SCU interrupt controller (0x1c0-0x1c8)
- Host 0 interrupt controller (0x1d0-0x1d8)
- Host 1 interrupt controller (0x1e0-0x1e8)
- PCI control (0x900-0xb00)
  - Interrupt for VGA scratch register changes
    
Neither consumer or producer:
- Silicon revision ID (0x000-0x004)
- Hardware strapping (0x010-0x030)
- OTP strapping (0x030-0x038)
- System Reset Event Log (0x050-0x080)
- GPIO debug probe (0x0a0-0x0a8)
- Debug UART control (0x0a8-0x0b0)
- Misc reset / PCIe (0x0c0-0x0c4)
- SoC debug control (0x0c8-0x0cc)
- Free running counter (0x0e0-0x0e8)
- PSP control (0x100-0x120)
- PERST# interrupt log (0x1d8-0x1dc)
- RCRST# interrupt log (0x1e8-0x1ec)
- SMP scratch registers (0x780-0x7b0)
- EFUSE (0x800-0x870)
- PMU (0x880-0x8c0)
- Write control (0xb00-0xf00)

The SCU0 node itself already acts as the provider for clocks and resets,
and the existing binding defines child nodes for the interrupt
controllers and pinctrl.

The software-defined scratch registers are also exposed through the SCU
register space, but it is likely sufficient for consumers to reference
the SCU syscon node directly rather than introducing a separate child
node.

What remains unclear is how best to model the secondary and tertiary
service processor control blocks (SSP/TSP) and the PCI control region.
The SSP and TSP controls consume reserved memory regions used to
configure the processors' address spaces, while the PCI control region
contains the VGA scratch registers used to communicate host display
ownership.

The p2a and smp-ram features are supported on earlier generations
but are not present on AST2700, and should be disabled in the binding
for the AST2700 as you suggested.

In the next revision, I plan to restrict these nodes for AST2700
using schema conditionals so that they are no longer allowed when the
compatible is "aspeed,ast2700-scu0" or "aspeed,ast2700-scu1".

    allOf:
      - if:
        properties:
            compatible:
            contains:
                enum:
                - aspeed,ast2700-scu0
                - aspeed,ast2700-scu1
        then:
        patternProperties:
            '^p2a-control@[0-9a-f]+$': false
            '^smp-memram@[0-9a-f]+$': false

Thanks
Billy Tsai