[PATCH/RFC 0/1] soc: renesas: Add DT fixup code for backwards compatibility

[Geert Uytterhoeven <geert+renesas@glider.be>]

	Hi all,

When moving functionality from C code to DT, we're regularly faced with
stable DT issues: old DTBs should keep on working. This requires keeping
workaround code in the kernel.

An alternative solution to having workaround C code, would be to
dynamically modify the DT, to add missing device nodes and phandle links.
This has several advantages:
  - All workarounds are kept together,
  - Workarounds can be enabled/disabled using a single Kconfig option,
  - Individual driver code is not polluted by workaround code.

Examples of missing support in DT are:
  - A device node for the R-Car RST (Reset Controller), which a.o.
    provides access to the Mode Pins (currently handled using an
    hardcoded address in platform/driver code), cfr. the series
    "[PATCH/RFC v3 00/22] soc: renesas: Add R-Car RST driver for
    obtaining mode pin state" I've just sent
    (http://www.spinics.net/lists/linux-renesas-soc/msg04289.html),
  - A device node for the R-Car SYSC (System Controller), to link CPUs
    to their respective power domains (On R-Car Gen2 CPUs can be
    auto-detected, as there's a register indicating which CPU cores are
    present),
  - Add a device node for the R-Car Gen2 APMU (Advanced Power
    Management Unit), for modern CPU bringup using "enable-method".
    Note that the method from this RFC doesn't work for
    "enable-method", as that is parsed in arm_dt_init_cpu_maps(),
    immediately after unflatten_device_tree(), long before initcalls
    run.

However, there are other possible uses:
  - Workarounds for hardware bugs: early engineering samples of an SoC
    may have non-functional devices. This would allow to describe the
    latest (functional) hardware in the .dtsi, knowing that the fixup
    code will disable non-functional devices when running on an early
    engineering sample, based on reading the PRR (Product Revision
    Register).
  - Handle other differences between SoC versions, e.g. change
    compatible values for an early engineering sample that needs special
    handling, or limit the features of a device.
  - Add SoC-specific compatible values to all device nodes (e.g. add
    "renesas,r8a7795-wdt" to a node already having
    "renesas,rcar-gen3-wdt" when running on r8a7795). This would make
    it easier to share .dtsi files within the same SoC family, without
    relying on e.g. C preprocessor tricks.

This proof-of-concept implements this for the missing R-Car RST (Reset
Controller) node. This poc is not suitable for all of the above, as some
DT structures (e.g. the CPU's "enable-method) are parsed long before
early_initcall(), and would need a different workaround.

What do you think?
Should this be handled at another level? E.g. operate on the FDT?

Thanks!

Geert Uytterhoeven (1):
  soc: renesas: Add DT fixup code for missing r8a7791 RST

 drivers/soc/renesas/Makefile           |   4 +
 drivers/soc/renesas/renesas-dt-fixup.c | 159 +++++++++++++++++++++++++++++++++
 2 files changed, 163 insertions(+)
 create mode 100644 drivers/soc/renesas/renesas-dt-fixup.c

-- 
1.9.1

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds