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. Best regards, Marcin
