Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220221162652.103834-1-clement.leger@bootlin.com>
 <YhQHqDJvahgriDZK@lunn.ch> <CAHp75VeHiTo6B=Ppz9Yc6OiC7nb5DViDt_bGifj6Jr=g89zf8Q@mail.gmail.com>
 <YhSlX01mEpFiRZQR@lunn.ch>
In-Reply-To: <YhSlX01mEpFiRZQR@lunn.ch>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Tue, 22 Feb 2022 10:20:23 +0100
Message-ID: <CAHp75VcrhRaCMq8fwFtf9NPGQTedszwDHmqsibfB-uBxkaBb2A@mail.gmail.com>
Subject: Re: [RFC 00/10] add support for fwnode in i2c mux system and sfp
To:     Andrew Lunn <andrew@lunn.ch>
Cc:     =?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= <clement.leger@bootlin.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Daniel Scally <djrscally@gmail.com>,
        Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        Sakari Ailus <sakari.ailus@linux.intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J . Wysocki" <rafael@kernel.org>,
        Wolfram Sang <wsa@kernel.org>, Peter Rosin <peda@axentia.se>,
        Russell King <linux@armlinux.org.uk>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        "David S . Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
        linux-i2c <linux-i2c@vger.kernel.org>,
        netdev <netdev@vger.kernel.org>,
        Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Feb 22, 2022 at 9:57 AM Andrew Lunn <andrew@lunn.ch> 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