Re: [PATCH] ACPI / property: Export a couple of symbols.

[David Daney]

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