Message ID | 1438729319-9146-1-git-send-email-ddaney.cavm@gmail.com |
---|---|
State | New |
Headers | show |
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@linaro.org> >> >> 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); Regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c index 7836e2e..237e3c5 100644 --- a/drivers/acpi/property.c +++ b/drivers/acpi/property.c @@ -432,6 +432,7 @@ int acpi_dev_prop_read_single(struct acpi_device *adev, const char *propname, } return ret; } +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)