From: David Daney <[email protected]>
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 <[email protected]>
---
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(+)
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.
--
1.7.11.7
On Thu, Mar 17, 2016 at 1:23 AM, David Daney <[email protected]> wrote:
> From: David Daney <[email protected]>
>
> 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
On Wed, Mar 16, 2016 at 05:23:19PM -0700, David Daney wrote:
> From: David Daney <[email protected]>
>
> 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 <[email protected]>
> ---
> 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.
On Thu, Mar 17, 2016 at 9:09 AM, Mika Westerberg
<[email protected]> wrote:
> On Wed, Mar 16, 2016 at 05:23:19PM -0700, David Daney wrote:
>> From: David Daney <[email protected]>
>>
>> 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 <[email protected]>
>> ---
>> 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.
On 03/17/2016 06:00 AM, Rafael J. Wysocki wrote:
> On Thu, Mar 17, 2016 at 9:09 AM, Mika Westerberg
> <[email protected]> wrote:
>> On Wed, Mar 16, 2016 at 05:23:19PM -0700, David Daney wrote:
>>> From: David Daney <[email protected]>
>>>
>>> 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 <[email protected]>
>>> ---
>>> 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
On Thu, Mar 17, 2016 at 9:21 PM, David Daney <[email protected]> wrote:
> On 03/17/2016 06:00 AM, Rafael J. Wysocki wrote:
>>
>> On Thu, Mar 17, 2016 at 9:09 AM, Mika Westerberg
>> <[email protected]> wrote:
>>>
>>> On Wed, Mar 16, 2016 at 05:23:19PM -0700, David Daney wrote:
>>>>
>>>> From: David Daney <[email protected]>
>>>>
>>>> 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 <[email protected]>
>>>> ---
>>>> 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