Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754171AbbHEUO7 (ORCPT ); Wed, 5 Aug 2015 16:14:59 -0400 Received: from mail-io0-f178.google.com ([209.85.223.178]:34846 "EHLO mail-io0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753293AbbHEUO6 (ORCPT ); Wed, 5 Aug 2015 16:14:58 -0400 Message-ID: <55C26EB9.7010504@gmail.com> Date: Wed, 05 Aug 2015 13:14:49 -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: David Daney , Tomasz Nowicki , "Rafael J. Wysocki" CC: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, Len Brown , Robert Richter , David Daney Subject: Re: [PATCH] acpi, property: Export acpi_dev_prop_read_single call. References: <1438729319-9146-1-git-send-email-ddaney.cavm@gmail.com> <5621301.c1YGTkGNQk@vostro.rjw.lan> <55C212F6.40504@linaro.org> <55C24737.8000309@caviumnetworks.com> In-Reply-To: <55C24737.8000309@caviumnetworks.com> 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: 1867 Lines: 48 On 08/05/2015 10:26 AM, David Daney wrote: > On 08/05/2015 06:43 AM, Tomasz Nowicki wrote: >> On 05.08.2015 15:48, Rafael J. Wysocki wrote: >>> On Tuesday, August 04, 2015 04:01:59 PM David Daney wrote: >>>> From: Tomasz Nowicki >>>> >>>> Fixes the following build error when building drivers as modules: >>>> >>>> ERROR: "acpi_dev_prop_read_single" [drivers/net/phy/mdio-octeon.ko] >>>> undefined! >>>> ERROR: "acpi_dev_prop_read_single" >>>> [drivers/net/ethernet/cavium/thunder/thunder_bgx.ko] undefined! >>> >>> Can you please tell me why the drivers in question use that function >>> directly, although they aren't supposed to? >>> >>> Clearly, their authors had not tried to build them as modules or they >>> would have noticed the problem at the development stage already. >>> >>> What would be wrong with using the generic device properties API >>> instead? >>> >> Yes, you are right. We should use: >> int device_property_read_u64_array(struct device *dev, const char >> *propname, u64 *val, size_t nval); >> > > Thanks all, for the review and suggestions. We we try the suggested > approach and see how it goes... > Actually I don't think device_property_read_u64_array() will work. We are traversing a reference to a different acpi_device via acpi_dev_get_property_reference(), so there is no struct device * available for a call to device_property_read_u64_array(). This looks like a deficiency in the device_property_* framework, so for the time being I guess we will call acpi_dev_get_property(), which is exported, and decode the thing in the driver. David Daney -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/