On Wed, Jun 22, 2022 at 5:44 PM Marcin Wojtas <mw@xxxxxxxxxxxx> wrote: > > Hi, > > wt., 21 cze 2022 o 12:46 Marcin Wojtas <mw@xxxxxxxxxxxx> napisał(a): > > > > 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. > > > > 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. Sounds good to me (as from fwnode perspective). -- With Best Regards, Andy Shevchenko
