iicmux: do not walk a bogus OFW node on systems described by ACPI

[yarshure_gmail.com]

Summary

iicmux_attach_children() reads the mux's OFW node and walks its children to
find the downstream buses. On a system with no device tree ofw_bus_get_node()
answers -1, and the walk then ran over that as if it were a node. Take the
generic path -- one iicbus child per channel the chip supports -- whenever
there is no node, and set childnodes[] to -1 explicitly there so that the
per-child ofw_bus_get_node() accessor answers "no node" rather than 0, which
is a valid phandle.

An arm64 GENERIC kernel carries both FDT and ACPI support and may be booted
either way, so this is not reachable only on ACPI-only platforms.

Test Plan

arm64 GENERIC, and a variant with iicmux/pca954x as modules.

On a SolidRun CEX7 (NXP LX2160A) booted through UEFI/ACPI -- no device tree,
the PCA9547 described in ACPI -- the mux now brings up its downstream buses:

iicbus0 <Philips I2C bus (ACPI-hinted)>
  pca954x0 <PCA9547 I2C Mux> ... handle=\_SB_.I2C0.MUX0
    iicbus1 ... iicbus8 <Philips I2C bus>

and "i2c -f /dev/iicN -s" reaches the devices on each channel. Before, the
OFW walk ran over the -1 that ofw_bus_get_node() answers for a device with no
node.

No behaviour change where a node exists: the device-tree walk is taken first
and unchanged, and childnodes[] is only written in the generic path.

[adrian]

@mmel and @wulf hey, this stack looks .. interesting to go and dig into as part of some other upcoming work. Would you mind taking a quick look at it and see what you think?
Thanks!

[mmel]

This is pure hack, imho. The ACPI mux, buses and their devices must be enumerated in exactly the same way as in the FDT case.