On Tue, Jun 21, 2022 at 02:46:05PM +0300, Andy Shevchenko wrote:
> On Tue, Jun 21, 2022 at 01:24:51PM +0200, Andrew Lunn wrote:
> > On Tue, Jun 21, 2022 at 02:15:41PM +0300, Andy Shevchenko wrote:
> > > On Tue, Jun 21, 2022 at 10:45:56AM +0100, Sudeep Holla wrote:
>
> ...
>
> > > I dunno we have a such, but the closest I may imagine is MIPI standardization,
> > > that we have at least for cameras and sound.
> > >
> > > I would suggest to go and work with MIPI for network / DSA / etc area, so
> > > everybody else will be aware of the standard.
> >
> > It is the same argument as for DT. Other OSes and bootloaders seem to
> > manage digging around in Linux for DT binding documentation. I don't
> > see why bootloaders and other OSes can not also dig around in Linux
> > for ACPI binding documentations.
> >
> > Ideally, somebody will submit all this for acceptance into ACPI, but
> > into somebody does, i suspect it will just remain a defacto standard
> > in Linux.
>
> The "bindings" are orthogonal to ACPI specification. It's a vendor / OS / ...
> specific from ACPI p.o.v. It has an UUID field and each UUID may or may not
> be a part of any standard.
We want to avoid snowflakes, each driver doing its own thing,
different to every other driver. So we push as much as possible into
the core, meaning the driver have no choice. So i expect the MDIO part
to look the same for every MDIO bus in Linux using ACPI. I expect the
PHY part to look the same, for every PHY using ACPI in Linux, the DSA
part to look the same, for every DSA switch using linux, because all
the ACPI is in the core of each of these subsystems. The driver only
gets to implement its own properties for anything which is not in one
of these cores.
So you say these bindings are vendor/OS specific, which is great. We
are defining how Linux does this. We are fully open, any other OS or
bootloader can copy it, but it also suggests we don't need to care
about other OSes and bootloaders? That actually seems opposite to DT,
were we do try to share it, and avoid being vendor or OS specific!
Andrew
