On 09/07, Rajendra Nayak wrote: > > > >Yeah this might happen though because we've assigned the of_node > >pointer to the tsens device before we register it on the platform > >bus. The other way to pass that data down from gcc to tsens would > >be to not have an of_node assigned to the tsens device, and check > >for that case in the tsens driver. If there isn't an of_node, > >then we look at the parent device's of_node to figure out which > >gcc it is (if this even matters) and parse DT properties. > > Parsing DT properties from parent (in the tsens driver) is fine, but > the nvmem apis still expect an of_node for the tsens device and hence > fail. So pass the parent device to the nvmem APIs? Or adjust the nvmem APIs to look for a parent of_node if there isn't an of_node for the device being passed? Or make the nvmem APIs work without using DT, and copy over the nvmem information from the gcc node to the virtual tsens child device? > > Associating the of_node of the parent to the tsens device while being > probed ends up with the same issues of gcc ending up probing the device > and failing because tsens defers probe a couple times before a > successful probe. Yeah sounds like we shouldn't do it that way. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
