ACPI / property: Export a couple of symbols.

Commit Message

David Daney March 17, 2016, 12:23 a.m. UTC

From: David Daney <[e-mail]>

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 <[e-mail]>
---
FWIW: We hope to submit soon Cavium Thunder networking patches that
fail under modular builds without these exports.

 drivers/acpi/property.c | 2 ++
 1 file changed, 2 insertions(+)

Comments

Rafael J. Wysocki March 17, 2016, 1:25 a.m. UTC | #1

On Thu, Mar 17, 2016 at 1:23 AM, David Daney <[e-mail]> wrote:
> From: David Daney <[e-mail]>
>
> The acpi_dev_prop_read() and acpi_dev_prop_read_single() can be called
> by drivers.

May I see the driver code that uses them?

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Mika Westerberg March 17, 2016, 8:09 a.m. UTC | #2

On Wed, Mar 16, 2016 at 05:23:19PM -0700, David Daney wrote:
> From: David Daney <[e-mail]>
> 
> 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 <[e-mail]>
> ---
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Rafael J. Wysocki March 17, 2016, 1 p.m. UTC | #3

On Thu, Mar 17, 2016 at 9:09 AM, Mika Westerberg
<[e-mail]> wrote:
> On Wed, Mar 16, 2016 at 05:23:19PM -0700, David Daney wrote:
>> From: David Daney <[e-mail]>
>>
>> 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 <[e-mail]>
>> ---
>> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

David Daney March 17, 2016, 8:21 p.m. UTC | #4

On 03/17/2016 06:00 AM, Rafael J. Wysocki wrote:
> On Thu, Mar 17, 2016 at 9:09 AM, Mika Westerberg
> <[e-mail]> wrote:
>> On Wed, Mar 16, 2016 at 05:23:19PM -0700, David Daney wrote:
>>> From: David Daney <[e-mail]>
>>>
>>> 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 <[e-mail]>
>>> ---
>>> 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 [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Rafael J. Wysocki March 17, 2016, 9:50 p.m. UTC | #5

On Thu, Mar 17, 2016 at 9:21 PM, David Daney <[e-mail]> wrote:
> On 03/17/2016 06:00 AM, Rafael J. Wysocki wrote:
>>
>> On Thu, Mar 17, 2016 at 9:09 AM, Mika Westerberg
>> <[e-mail]> wrote:
>>>
>>> On Wed, Mar 16, 2016 at 05:23:19PM -0700, David Daney wrote:
>>>>
>>>> From: David Daney <[e-mail]>
>>>>
>>>> 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 <[e-mail]>
>>>> ---
>>>> 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 [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index 2aee416..de225dc 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -638,6 +638,7 @@  int acpi_dev_prop_read_single(struct acpi_device *adev, const char *propname,
 {
 	return adev ? acpi_data_prop_read_single(&adev->data, propname, proptype, val) : -EINVAL;
 }
+EXPORT_SYMBOL_GPL(acpi_dev_prop_read_single);
 
 static int acpi_copy_property_array_u8(const union acpi_object *items, u8 *val,
 				       size_t nval)
@@ -772,6 +773,7 @@  int acpi_dev_prop_read(struct acpi_device *adev, const char *propname,
 {
 	return adev ? acpi_data_prop_read(&adev->data, propname, proptype, val, nval) : -EINVAL;
 }
+EXPORT_SYMBOL_GPL(acpi_dev_prop_read);
 
 /**
  * acpi_node_prop_read - retrieve the value of an ACPI property with given name.