On Wednesday, August 05, 2015 04:17:21 PM David Daney wrote: > On 08/05/2015 04:23 PM, Rafael J. Wysocki wrote: > > On Wednesday, August 05, 2015 01:14:49 PM David Daney wrote: > >> 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 <tomasz.nowicki@xxxxxxxxxx> > >>>>>> > >>>>>> 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(), > > > > Why? > > Network device has a "phy-handle" (traversed with > acpi_dev_get_property_reference()), and we want to get some properties > of that phy. > > I could turn the question around to you: Why export > acpi_dev_get_property_reference()? If there is a reason to export that, > then you should let people use the result. The GPIO core uses it and you *can* use the result (please see my other message). I wonder how does the ACPI table in question look like. Do you have an acpidump output from that system by any chance? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
