On Wed, Dec 02, 2015 at 05:09:26PM +0800, Kefeng Wang wrote: > With of_parse_phandle() and acpi_dev_get_reference_device(), we can introduce > a universal helper device_get_reference_node() to read and parse a device > property and return a pointer to the resulting firmware node. What's happening to make this fwnode stuff actually usable? Whenever I've looked at it from the DT perspective, it looks very much like a half-baked train wreck - although the struct device_node contains a fwnode, of_node_init() initialises it partially, and we have a way to convert _from_ a fwnode to a device_node (to_of_node), nothing sets the struct device fwnode pointer. Whenever I've looked at this, it's always led me to the conclusion that the way that fwnode stuff has currently been written, I'm supposed to get the device_node, and then use the embedded fwnode directly, which I'm pretty sure misses the point of fwnode (as it means any driver code making use of this is tied to DT.) This patch seems to confirm my suspicions that it's just wrong - trying to use device_get_reference_node() here will fail in a DT based setup, because (I assume) dev_fwnode(dev) returns dev->fwnode which is NULL there. I don't know, maybe there is an intention that fwnode should not be used for DT? Maybe someone who knows what the intentions are behind this fwnode stuff can enlighten the situation, and maybe sort out this apparent oversight which IMHO should've been spotted in the initial fwnode review? -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- 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
