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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 17 Mar 2016 22:50:08 +0100
From:	"Rafael J. Wysocki" <rafael@...nel.org>
To:	David Daney <ddaney.cavm@...il.com>
Cc:	"Rafael J. Wysocki" <rafael@...nel.org>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <lenb@...nel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Robert Richter <rrichter@...ium.com>,
	Tomasz Nowicki <tn@...ihalf.com>,
	David Daney <david.daney@...ium.com>
Subject: Re: [PATCH] ACPI / property: Export a couple of symbols.

On Thu, Mar 17, 2016 at 9:21 PM, David Daney <ddaney.cavm@...il.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@...ux.intel.com> wrote:
>>>
>>> On Wed, Mar 16, 2016 at 05:23:19PM -0700, David Daney wrote:
>>>>
>>>> From: David Daney <david.daney@...ium.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@...ium.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