On 03/17/2016 06:00 AM, Rafael J. Wysocki wrote:
On Thu, Mar 17, 2016 at 9:09 AM, Mika Westerberg
<mika.westerberg@xxxxxxxxxxxxxxx> wrote:
On Wed, Mar 16, 2016 at 05:23:19PM -0700, David Daney wrote:
From: David Daney <david.daney@xxxxxxxxxx>
The acpi_dev_prop_read() and acpi_dev_prop_read_single() can be called
by drivers. Add EXPORT_SYMBOL_GPL to them to allow use by modular
drivers. This makes them consistent with acpi_dev_get_property() and
acpi_node_get_property_reference() which are already exported.
Signed-off-by: David Daney <david.daney@xxxxxxxxxx>
---
FWIW: We hope to submit soon Cavium Thunder networking patches that
fail under modular builds without these exports.
You should not be using these functions directly in drivers.
That's exactly my point.
OK, for the sake of argument I will concede that my particular use of
acpi_dev_prop_read_single() is incorrect.
Let me ask you this:
What is the point of the code in drivers/acpi/property.c?
acpi_dev_prop_read() and acpi_dev_prop_read_single() are not used
anywhere that I can see in the kernel, would you accept a patch to
remove them?
But from a philosophical point of view, what is the underlying problem
of having drivers extract property information from the ACPI tables
corresponding to the devices they control.
Specifically, I am trying to understand how to port drivers that
currently successfully use OF device tree so that they are usable in
systems with ACPI based firmware.
Thanks in advance,
David Daney
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
