Re: [net-next: PATCH 00/12] ACPI support for DSA
From: Marcin Wojtas <hidden>
Date: 2022-06-22 15:40:49
Also in:
linux-acpi, lkml
Hi, wt., 21 cze 2022 o 12:46 Marcin Wojtas [off-list ref] napisał(a):
pon., 20 cze 2022 o 20:45 Andrew Lunn [off-list ref] napisał(a):quoted
quoted
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.
Thank you all for vivid discussions. As it may take some time for the MDIOSerialBus _CRS macro review and approval, for now I plan to submit v2 of_ -> fwnode_/device_ migration (patches 1-7,11/12) and skip ACPI-specific additions until it is unblocked by spec extension. Best regards, Marcin