On 5/7/15 7:51 AM, Mark Brown wrote:
On Thu, May 07, 2015 at 05:34:27AM +0000, Bard Liao wrote:
We should really be using device_property_() instead of of_property_() APIs since we will have to support both DT and ACPI properties.
Unfortunately, I can't find a way to test it.
Why can't you test it - weren't you testing your original version of the code?
You can test it on an platform using device tree, the device_property_ code will fetch the same information as before. If you want to test on an ACPI platform, I can help with some examples (off-list) showing how to override the DSDT table and to add those properties in an ASL device entry. You may not be able to test all the configurations but at least you can add basic checks that show the data is passed from ACPI to your driver. I used all this stuff for a proof of concept on AsusT100 where the audio routing in the machine driver is passed from ACPI.
Is that ok we just replace all of_property_ with device_property_? Also, is there any corresponding API for of_get_named_gpio? Or we can replace it with device_property_read_u32? I tried the change above, and it can build. However I don't know if it can work.
You shouldn't be using of_get_named_gpio() for DT stuff either, use gpiod_get() which follows the usual pattern of taking a string which is used to do the lookup with whatever firmware is in use.
But to Bard's credit the use of_get_named_gpio() is pretty common - i see 18 occurrences in soc/codecs alone, others will have the same problem... we talked internally (RafaelW, Darren Hart, LiamG and me) about reaching out to gpio and audio maintainers and aligning some sort of coordinated change to the gpiod framework w/ guidance to developers, did that thread start?