acpi_iicbus, pca954x: map ACPI namespace scopes onto i2c mux channels

[yarshure_gmail.com]

Summary

acpi_iicbus(4) decides which ACPI devices belong to it by comparing the
ResourceSource of their I2cSerialBus resource against the handle of the
controller its bus hangs off. That holds for a controller driving a single
bus: the bus is not a namespace object of its own, and everything on it is
described in the controller's scope.

It does not hold for an i2c mux. One device fans out into several buses, and
firmware describes each downstream channel as its own namespace node, with
whatever sits on that channel in that channel's scope. The comparison can
therefore never match, and nothing firmware placed on a channel is
enumerated. On a SolidRun CEX7 (NXP LX2160A) that is the board's fan
controller and temperature sensor: both are described in ACPI and both end up
as unattached devices hanging off acpi0.

Give iicbus(4) the notion of a bus that stands for a namespace scope of its
own. pca954x(4) records the node firmware described each channel with,
keyed by _ADR, and answers ACPI_IVAR_HANDLE for the matching child bus --
the same shape as the FDT side, where iicmux(4) keeps childnodes[] and the
parent answers ofw_bus_get_node() per child. acpi_iicbus(4) then prefers the
bus's own handle and falls back to the controller's.

Answering with a NULL handle is not the same as declining: it says the
channel is ours and firmware did not describe it, so that channel gets a
plain iicbus(4) rather than an ACPI-aware one.

Depends on D60063

Test Plan

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

On a SolidRun CEX7 (NXP LX2160A) under UEFI/ACPI the firmware describes a fan
controller on mux channel 1 and a thermal sensor on channel 3, each in its
channel's own scope. Before, no bus claimed those scopes and both ended up
as unattached devices on acpi0:

iicbus1 ... iicbus8 <Philips I2C bus>
unknown _HID=PRP0001 _UID=0 ... handle=\_SB_.I2C0.MUX0.CH01.FAN1
unknown _HID=PRP0001 _UID=1 ... handle=\_SB_.I2C0.MUX0.CH03.THE1

After, the two channels firmware described are ACPI-aware buses and the
devices sit on them, while the six it did not describe stay plain:

iicbus2 <Philips I2C bus (ACPI-hinted)>
  unknown ... at addr=0x30 handle=\_SB_.I2C0.MUX0.CH01.FAN1
iicbus4 <Philips I2C bus (ACPI-hinted)>
  unknown ... at addr=0x94 handle=\_SB_.I2C0.MUX0.CH03.THE1
iicbus1, 3, 5..8 <Philips I2C bus>