Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1359484 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [PATCH] ACPI / property: Export a couple of symbols. David Daney <ddaney.cavm@gmail.com> - 2016-03-17 01:30 +0100
    Re: [PATCH] ACPI / property: Export a couple of symbols. "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-17 02:30 +0100
    Re: [PATCH] ACPI / property: Export a couple of symbols. Mika Westerberg <mika.westerberg@linux.intel.com> - 2016-03-17 09:10 +0100
      Re: [PATCH] ACPI / property: Export a couple of symbols. "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-17 14:10 +0100
        Re: [PATCH] ACPI / property: Export a couple of symbols. David Daney <ddaney.cavm@gmail.com> - 2016-03-17 21:30 +0100
          Re: [PATCH] ACPI / property: Export a couple of symbols. "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-17 23:00 +0100

#1359484 — [PATCH] ACPI / property: Export a couple of symbols.

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

[toc] | [next] | [standalone]

#1359510

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

[toc] | [prev] | [next] | [standalone]

#1359617

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.

[toc] | [prev] | [next] | [standalone]

#1359832

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.

[toc] | [prev] | [next] | [standalone]

#1360169

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

[toc] | [prev] | [next] | [standalone]

#1360217

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web