Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935747AbcCQUWD (ORCPT ); Thu, 17 Mar 2016 16:22:03 -0400 Received: from mail-pf0-f173.google.com ([209.85.192.173]:35464 "EHLO mail-pf0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932595AbcCQUV6 (ORCPT ); Thu, 17 Mar 2016 16:21:58 -0400 Message-ID: <56EB11E2.6050608@gmail.com> Date: Thu, 17 Mar 2016 13:21:54 -0700 From: David Daney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 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 Subject: Re: [PATCH] ACPI / property: Export a couple of symbols. References: <1458174199-23615-1-git-send-email-ddaney.cavm@gmail.com> <20160317080926.GO1793@lahna.fi.intel.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1569 Lines: 43 On 03/17/2016 06:00 AM, Rafael J. Wysocki wrote: > On Thu, Mar 17, 2016 at 9:09 AM, Mika Westerberg > wrote: >> On Wed, Mar 16, 2016 at 05:23:19PM -0700, David Daney wrote: >>> From: David Daney >>> >>> 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 >>> --- >>> 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