On Mon, Oct 19, 2020 at 9:53 AM Evan Green <evgreen@xxxxxxxxxxxx> wrote: > > On Sun, Oct 18, 2020 at 11:58 AM Andy Shevchenko > <andy.shevchenko@xxxxxxxxx> wrote: > > > > On Sat, Oct 17, 2020 at 8:30 AM Evan Green <evgreen@xxxxxxxxxxxx> wrote: > > > > > > Enable i2c-mux-gpio devices to be defined via ACPI. The idle-state > > > property translates directly to a fwnode_property_*() call. The child > > > reg property translates naturally into _ADR in ACPI. > > > > > > The i2c-parent binding is a relic from the days when the bindings > > > dictated that all direct children of an I2C controller had to be I2C > > > devices. These days that's no longer required. The i2c-mux can sit as a > > > direct child of its parent controller, which is where it makes the most > > > sense from a hardware description perspective. For the ACPI > > > implementation we'll assume that's always how the i2c-mux-gpio is > > > instantiated. > > > > Can you tell me if the following is relevant to what you are looking for? > > https://elixir.bootlin.com/linux/latest/source/drivers/i2c/i2c-mux.c#L393 > > I don't think so, but let me know if I'm reading between the lines incorrectly. > > The code you pointed to links the newly-minted fake i2c controller > back together with its ACPI node. This is important, since I think > that's how child I2C devices underneath the fake busses get populated > in ACPI land. But the paragraph above is discussing how to identify > the parent adapter (ie the real hardware) for an i2c-mux-gpio device. > > In DT-land, the i2c-mux-gpio floats at the top of the tree directly > under /, and then uses a phandle to point to where transactions should > be forwarded. I'm told the reason for this is historical limitations > with the DT bindings. Rather than trying to translate the phandle over > 1:1 into ACPI-land, I'm asserting that the mux device should live > underneath the adapter it wants to forward traffic to. Andy or Peter, Any other thoughts on this series? -Evan
