lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 11 Oct 2022 11:12:45 +0800 From: "Soha Jin" <soha@...u.info> To: "'Andrew Lunn'" <andrew@...n.ch> Cc: "'Giuseppe Cavallaro'" <peppe.cavallaro@...com>, "'Alexandre Torgue'" <alexandre.torgue@...s.st.com>, "'Jose Abreu'" <joabreu@...opsys.com>, "'David S. Miller'" <davem@...emloft.net>, "'Eric Dumazet'" <edumazet@...gle.com>, "'Jakub Kicinski'" <kuba@...nel.org>, "'Paolo Abeni'" <pabeni@...hat.com>, "'Yangyu Chen'" <cyy@...self.name>, <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org> Subject: RE: [PATCH 1/3] net: stmmac: use fwnode instead of of to configure driver Hi Andrew, > From: Andrew Lunn <andrew@...n.ch> > Sent: Tuesday, October 11, 2022 4:38 AM > > None of these are documented as being valid in ACPI. Do you need to ensure > they only come from DT, or you document them for ACPI, and get the ACPI > maintainers to ACK that they are O.K. There is _DSD object in ACPI which is used to define Device Specific Data, and provide additional properties and information to the driver. With specific UUID listed in _DSD, a package can be used like Device Tree (a string key associated with a value), and this is also the object fwnode_property_* will parse with. I have tested some of properties with a device describing stmmac device in ACPI, and it works. These properties should be the configuration to the driver, and is not related to the way configuring it. Moreover, these are described in _DSD and not a part of ACPI standard, there seems no need to ask ACPI maintainers. Also, as described in Documentation/firmware-guide/acpi/enumeration.rst, there is a Device Tree Namespace Link HID (PRP0001) in kernel. PRP0001 can be used to describe a Device Tree in ACPI's _DSD object, and it just put DT properties in a _DSD package with the specific UUID I said above. But to utilize this feature, the driver seems need to use fwnode APIs. > Backward compatibility only applies to DT. Anybody using ACPI should not > expect any backwards compatibility, they should be documented mandatory > properties right from the beginning. Just do not want to mix the use of OF and fwnode APIs, I simply changed all OF property APIs with fwnode APIs. If you really think the backward compatibility should not exist in ACPI, I will change these compatible codes back to OF APIs. Regards, Soha
Powered by blists - more mailing lists