On Tue, Feb 22, 2022 at 9:57 AM Andrew Lunn <andrew@xxxxxxx> wrote: > > > > In the DT world, we avoid snow flakes. Once you define a binding, it > > > is expected every following board will use it. So what i believe you > > > are doing here is defining how i2c muxes are described in APCI. > > > > Linux kernel has already established description of I2C muxes in ACPI: > > https://www.kernel.org/doc/html/latest/firmware-guide/acpi/i2c-muxes.html > > > > I'm not sure we want another one. > > Agreed. This implementation needs to make use of that. Thanks for > pointing it out. I don't know the ACPI world, are there any other > overlaps with existing ACPI bindings? Besides ACPI specification, which defines _CRS resources, such as I2C, SPI, GPIO, and other peripheral connections, in the Linux kernel we have already established these [1]. I hope it's all here, since in the past not everything got documented and there were some documentation patches in time. On top of that there are some Microsoft documents on enumeration that Linux follows, such as USB embedded devices [2]. There is also a PCI FW specification that defines how PCI bus devices, bridges, etc have to be represented in ACPI, including additional tables, such as MCFG. [1]: https://www.kernel.org/doc/html/latest/firmware-guide/acpi/enumeration.html [2]: https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/other-acpi-namespace-objects#acpi-namespace-hierarchy-and-_adr-for-embedded-usb-devices -- With Best Regards, Andy Shevchenko
