On Wednesday 23 November 2016 03:35 PM, Sudeep Holla wrote: > > > On 23/11/16 07:49, Sekhar Nori wrote: >> On Tuesday 22 November 2016 09:16 PM, Sudeep Holla wrote: >>> Hi Sekhar, >>> >>> On 22/11/16 15:06, Sekhar Nori wrote: >>>> Hi Sudeep, >>>> >>>> On Tuesday 22 November 2016 04:23 PM, Sudeep Holla wrote: >>>>> >>>>> >>>>> On 22/11/16 10:41, Bartosz Golaszewski wrote: >>>>>> Add a function allowing to retrieve the compatible string of the root >>>>>> node of the device tree. >>>>>> >>>>> >>>>> Rob has queued [1] and it's in -next today. You can reuse that if you >>>>> are planning to target this for v4.11 or just use open coding in your >>>>> driver for v4.10 and target this move for v4.11 to avoid cross tree >>>>> dependencies as I already mentioned in your previous thread. >>>> >>>> I dont have your original patch in my mailbox, but I wonder if >>>> returning a pointer to property string for a node whose reference has >>>> already been released is safe to do? Probably not an issue for the root >>>> node, but still feels counter-intuitive. >>>> >>> >>> I am not sure if I understand the issue here. Are you referring a case >>> where of_root is freed ? >> >> Yes, right, thats what I was hinting at. Since you are giving up the >> reference to the device node before the function returns, the user can >> be left with a dangling reference. >> > > Yes I agree. So, the if(!of_node_get()) is just an expensive NULL pointer check. I think it is better to be explicit about it by not using of_node_get/put() at all. How about: +int of_machine_get_model_name(const char **model) +{ + int error; + + if (!of_root) + return -EINVAL; + + error = of_property_read_string(of_root, "model", model); + if (error) + error = of_property_read_string_index(of_root, "compatible", + 0, model); + return error; +} +EXPORT_SYMBOL(of_machine_get_model_name); I know the patch is already in -next so I guess it depends on how strongly Rob feels about this. Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html