On Tue, Jun 21, 2022 at 06:00:42PM +0200, Rafael J. Wysocki wrote: > On Tue, Jun 21, 2022 at 5:37 PM Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > > > On Tue, Jun 21, 2022 at 05:23:30PM +0200, Rafael J. Wysocki wrote: > > > On Tue, Jun 21, 2022 at 3:28 PM Sudeep Holla <sudeep.holla@xxxxxxx> wrote: > > > > > > > > On Tue, Jun 21, 2022 at 01:24:51PM +0200, Andrew Lunn wrote: > > > > > On Tue, Jun 21, 2022 at 02:15:41PM +0300, Andy Shevchenko wrote: > > > > > > On Tue, Jun 21, 2022 at 10:45:56AM +0100, Sudeep Holla wrote: > > > > > > > On Mon, Jun 20, 2022 at 05:02:22PM +0200, Marcin Wojtas wrote: > > > > > > > > Describe the Distributed Switch Architecture (DSA) - compliant > > > > > > > > MDIO devices. In ACPI world they are represented as children > > > > > > > > of the MDIO busses, which are responsible for their enumeration > > > > > > > > based on the standard _ADR fields and description in _DSD objects > > > > > > > > under device properties UUID [1]. > > > > > > > > > > > > > > > > [1] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf > > > > > > > > > > > > > Why is this document part of Linux code base ? > > > > > > > > > > > > It's fine, but your are right with your latter questions. > > > > > > > > > > > > > How will the other OSes be aware of this ? > > > > > > > > > > > > Should be a standard somewhere. > > > > > > > > > > > > > I assume there was some repository to maintain such DSDs so that it > > > > > > > is accessible for other OSes. I am not agreeing or disagreeing on the > > > > > > > change itself, but I am concerned about this present in the kernel > > > > > > > code. > > > > > > > > > > > > I dunno we have a such, but the closest I may imagine is MIPI standardization, > > > > > > that we have at least for cameras and sound. > > > > > > > > > > > > I would suggest to go and work with MIPI for network / DSA / etc area, so > > > > > > everybody else will be aware of the standard. > > > > > > > > > > It is the same argument as for DT. Other OSes and bootloaders seem to > > > > > manage digging around in Linux for DT binding documentation. I don't > > > > > see why bootloaders and other OSes can not also dig around in Linux > > > > > for ACPI binding documentations. > > > > > > > > > > > > > Theoretically you are right. But in DT case majority of non-standard(by > > > > standard I am referring to the one's in Open Firmware specification) are > > > > in the kernel. But that is not true for ACPI. And that is the reason for > > > > objecting it. One of the main other OS using ACPI may not look here for > > > > any ACPI bindings(we may not care, but still OS neutral place is better > > > > for this). > > > > > > > > > Ideally, somebody will submit all this for acceptance into ACPI, but > > > > > into somebody does, i suspect it will just remain a defacto standard > > > > > in Linux. > > > > > > > > > > > > > DSD is not integral part of ACPI spec, so the process is never clear. > > > > However there is this project[1], IIUC it is just guidance and doesn't > > > > include any bindings IIUC. But we need something similar here for better > > > > visibility and to remain OS agnostic. Even with DT, there is a strong > > > > desire to separate it out, but it has grown so much that it is getting > > > > harder to do that with every release. I was just trying to avoid getting > > > > into that situation. > > > > > > > > [1] https://github.com/UEFI/DSD-Guide > > > > > > Here's my personal take on this. > > > > > > This patch series essentially makes the kernel recognize a few generic > > > (that is, not tied on any specific device ID) device properties > > > supplied by the firmware via _DSD. They are generic, because there is > > > some library code in the kernel that can consume them and that library > > > code is used in multiple places (and it is better to supply data from > > > the firmware directly to it). > > > > > > If we all agree that it is a good idea for the kernel to allow these > > > properties to be supplied via _DSD this way, there is no reason to > > > avoid admitting that fact in the kernel documentation. > > > > > > IMV, there's nothing wrong with stating officially that these > > > properties are recognized by the kernel and what they are used for and > > > it has no bearing on whether or not they are also used by someone > > > else. > > > > Good point. I was also suggested to make properties have prefix "linux-" > > similar to "uefi-" in the set of DSD properties list @[1]. In that case > > it makes more sense to maintain in the kernel. If they add "uefi-" prefix, > > I was also told that it can be hosted @[1] as specific in section 3.1.4 @[2] > > Well, the point here is to use the same property names on both the DT > and ACPI ends IIUC and there's certain value in doing that. > > The library in question already uses these names with DT and there is > no real need to change that. > Make sense and I agree. > Of course, if the platform firmware supplies these properties in a way > described in the document in question, it will be a provision > specifically for Linux and nothing else (unless that hypothetical > other thing decides to follow Linux in this respect, that is). As > long as that is clear, I don't see why it would be better to introduce > different property names just for _DSD. > Understood and very valid point. > > I just sent an update to Documentation with the link to[1]. > > Thanks! > > > I can also > > update the same to mention about the process as described in section 3.1.4 > > if that helps and we are happy to follow that in the kernel. > > > > [1] https://github.com/UEFI/DSD-Guide > > [2] https://github.com/UEFI/DSD-Guide/blob/main/src/dsd-guide.adoc#314-adding-uefi-device-properties > > IMV it would be useful to add that information, but IMO the process is > mostly relevant for new use cases, when someone wants to introduce an > entirely new property that is not yet covered by the DT bindings. > > In the cases when the existing DT properties are the closest thing to > a standard way of supplying the OS with the information in question it > is most appealing to use the property names that are in use already. Agreed, I wasn't aware that the properties discussed in $subject are already DT properties. I agree on the point that we don't want to have a different one(with prefix) if the DT properties are already supported. -- Regards, Sudeep
