* [PATCH] ACPI / property: Export a couple of symbols.
@ 2016-03-17 0:23 David Daney
2016-03-17 1:25 ` Rafael J. Wysocki
2016-03-17 8:09 ` Mika Westerberg
0 siblings, 2 replies; 6+ messages in thread
From: David Daney @ 2016-03-17 0:23 UTC (permalink / raw)
To: Rafael J. Wysocki, Len Brown, linux-acpi
Cc: linux-kernel, Robert Richter, Tomasz Nowicki, David Daney
From: David Daney <david.daney@cavium.com>
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@cavium.com>
---
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
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH] ACPI / property: Export a couple of symbols.
2016-03-17 0:23 [PATCH] ACPI / property: Export a couple of symbols David Daney
@ 2016-03-17 1:25 ` Rafael J. Wysocki
2016-03-17 8:09 ` Mika Westerberg
1 sibling, 0 replies; 6+ messages in thread
From: Rafael J. Wysocki @ 2016-03-17 1:25 UTC (permalink / raw)
To: David Daney
Cc: Rafael J. Wysocki, Len Brown, ACPI Devel Maling List,
Linux Kernel Mailing List, Robert Richter, Tomasz Nowicki,
David Daney
On Thu, Mar 17, 2016 at 1:23 AM, David Daney <ddaney.cavm@gmail.com> wrote:
> From: David Daney <david.daney@cavium.com>
>
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ACPI / property: Export a couple of symbols.
2016-03-17 0:23 [PATCH] ACPI / property: Export a couple of symbols David Daney
2016-03-17 1:25 ` Rafael J. Wysocki
@ 2016-03-17 8:09 ` Mika Westerberg
2016-03-17 13:00 ` Rafael J. Wysocki
1 sibling, 1 reply; 6+ messages in thread
From: Mika Westerberg @ 2016-03-17 8:09 UTC (permalink / raw)
To: David Daney
Cc: Rafael J. Wysocki, Len Brown, linux-acpi, linux-kernel,
Robert Richter, Tomasz Nowicki, David Daney
On Wed, Mar 16, 2016 at 05:23:19PM -0700, David Daney wrote:
> From: David Daney <david.daney@cavium.com>
>
> 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@cavium.com>
> ---
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ACPI / property: Export a couple of symbols.
2016-03-17 8:09 ` Mika Westerberg
@ 2016-03-17 13:00 ` Rafael J. Wysocki
2016-03-17 20:21 ` David Daney
0 siblings, 1 reply; 6+ messages in thread
From: Rafael J. Wysocki @ 2016-03-17 13:00 UTC (permalink / raw)
To: Mika Westerberg, David Daney
Cc: Rafael J. Wysocki, Len Brown, ACPI Devel Maling List,
Linux Kernel Mailing List, Robert Richter, Tomasz Nowicki,
David Daney
On Thu, Mar 17, 2016 at 9:09 AM, Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
> On Wed, Mar 16, 2016 at 05:23:19PM -0700, David Daney wrote:
>> From: David Daney <david.daney@cavium.com>
>>
>> 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@cavium.com>
>> ---
>> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ACPI / property: Export a couple of symbols.
2016-03-17 13:00 ` Rafael J. Wysocki
@ 2016-03-17 20:21 ` David Daney
2016-03-17 21:50 ` Rafael J. Wysocki
0 siblings, 1 reply; 6+ messages in thread
From: David Daney @ 2016-03-17 20:21 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Mika Westerberg, Rafael J. Wysocki, Len Brown,
ACPI Devel Maling List, Linux Kernel Mailing List, Robert Richter,
Tomasz Nowicki, 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@linux.intel.com> wrote:
>> On Wed, Mar 16, 2016 at 05:23:19PM -0700, David Daney wrote:
>>> From: David Daney <david.daney@cavium.com>
>>>
>>> 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@cavium.com>
>>> ---
>>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] ACPI / property: Export a couple of symbols.
2016-03-17 20:21 ` David Daney
@ 2016-03-17 21:50 ` Rafael J. Wysocki
0 siblings, 0 replies; 6+ messages in thread
From: Rafael J. Wysocki @ 2016-03-17 21:50 UTC (permalink / raw)
To: David Daney
Cc: Rafael J. Wysocki, Mika Westerberg, Rafael J. Wysocki, Len Brown,
ACPI Devel Maling List, Linux Kernel Mailing List, Robert Richter,
Tomasz Nowicki, David Daney
On Thu, Mar 17, 2016 at 9:21 PM, David Daney <ddaney.cavm@gmail.com> 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@linux.intel.com> wrote:
>>>
>>> On Wed, Mar 16, 2016 at 05:23:19PM -0700, David Daney wrote:
>>>>
>>>> From: David Daney <david.daney@cavium.com>
>>>>
>>>> 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@cavium.com>
>>>> ---
>>>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-03-17 21:50 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-17 0:23 [PATCH] ACPI / property: Export a couple of symbols David Daney
2016-03-17 1:25 ` Rafael J. Wysocki
2016-03-17 8:09 ` Mika Westerberg
2016-03-17 13:00 ` Rafael J. Wysocki
2016-03-17 20:21 ` David Daney
2016-03-17 21:50 ` Rafael J. Wysocki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).