On Thu, Mar 17, 2016 at 9:21 PM, David Daney <ddaney.cavm@xxxxxxxxx> wrote: > 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? It is used by the code in drivers/base/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? Yes, I would. They are leftovers. > 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. The code in drivers/base/property.c is for that in theory. If it doesn't work for you, please let me know what the problem is. Thanks, Rafael -- 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
