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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 11 Oct 2022 11:12:45 +0800
From:   "Soha Jin" <>
To:     "'Andrew Lunn'" <>
Cc:     "'Giuseppe Cavallaro'" <>,
        "'Alexandre Torgue'" <>,
        "'Jose Abreu'" <>,
        "'David S. Miller'" <>,
        "'Eric Dumazet'" <>,
        "'Jakub Kicinski'" <>,
        "'Paolo Abeni'" <>,
        "'Yangyu Chen'" <>, <>,
Subject: RE: [PATCH 1/3] net: stmmac: use fwnode instead of of to configure driver

Hi Andrew,

> From: Andrew Lunn <>
> 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.


Powered by blists - more mailing lists