pon., 20 cze 2022 o 20:45 Andrew Lunn <andrew@xxxxxxx> napisał(a):
>
> > You beat me up to this. I also was about to mention that the problem with such
> > conversions (like this series does) is not in the code. It's simplest part. The
> > problem is bindings and how you get them to be a standard (at least de facto).
>
> De facto is easy. Get it merged. After that, i will simply refuse
> anything else, the same way i and other Maintainers would refuse a
> different DT binding.
>
> If the ACPI committee approve and publish a binding, we will naturally
> accept that as well. So in the end we might have two bindings. But so
> far in this whole ACPI for networking story, i've not heard anybody
> say they are going to submit anything for standardisation. So this
> might be a mute point.
>
I understand your concern and of course it's better to be on a safe
side from the beginning. Based on the hitherto discussion under this
patchset, I would split the question about standardization to 2
orthogonal topics:
1. Relation to the bus and enumeration:
* As pointed out in another patch some switches can be attached to
SPI or I2C. In such a case this is simple - SPISerialBus /
I2CSerialBus structures
in _CRS are included in the ACPI Spec. They allow to comprise more
bus specific
information and the code in acpi/scan.c marks those child devices
as to be enumerated
by parent bus.
* MDIO bus doesn't have its own _CRS macro in the Spec, on the other
hand the _ADR
seems to be the only object required for proper operation - this
was my base for
proposed solution in patch 06/12.
2. The device description (unrelated to which bus it is attached)
* In Linux and other OS's there is a great amount of devices
conforming the guidelines
and using only the standard device identification/configuration
objects as per [1].
* Above do not contain custom items and entire information can be obtained by
existing, generic ACPI accessors - those devices (e.g. NICs,
SD/MMC controllers and
many others) are not explicitly mentioned in official standards.
* The question, also related to this DSA case - is the ACPI device()
hierarchical
structure of this kind a subject for standardization for including
in official ACPI specification?
* In case not, where to document it? Is Linux' Documentation enough?
I agree that in the moment of merge it becomes de facto standard ABI and
it's worth to sort it out.
Rafael, Len, any other ACPI expert - I would appreciate your inputs
and clarification
of the above. Your recommendation would be extremely helpful.
Best regards,
Marcin
