Thread (84 messages) 84 messages, 9 authors, 2022-06-25

Re: [net-next: PATCH 00/12] ACPI support for DSA

From: Marcin Wojtas <hidden>
Date: 2022-06-21 10:47:14
Also in: linux-acpi, lkml

pon., 20 cze 2022 o 20:45 Andrew Lunn [off-list ref] napisał(a):
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.

Best regards,
Marcin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help