On Fri, Sep 21, 2018 at 7:48 AM Alexander Duyck <[email protected]> wrote: [..] > > I was thinking everywhere we set dev->parent before registering, also > > set the node... > > That will not work unless we move the call to device_initialize to > somewhere before you are setting the node. That is why I was thinking it > might work to put the node assignment in nd_device_register itself since > it looks like the regions don't call __nd_device_register directly. > > I guess we could get rid of nd_device_register if we wanted to go that > route. > > >> If you wanted what I could do is pull the set_dev_node call from > >> nvdimm_bus_uevent and place it in nd_device_register. That should stick > >> as the node doesn't get overwritten by the parent if it is set after > >> device_initialize. If I did that along with the parent bit I was already > >> doing then all that would be left to do in is just use the dev_to_node > >> call on the device itself. > > > > ...but this is even better. > > > > I'm not sure it adds that much. Basically My thought was we just need to > make sure to set the device node after the call to device_initialize but > before the call to device_add. This just seems like a bunch more work > spread the device_initialize calls all over and introduce possible > regressions.
Yeah, device_initialize() clobbering the numa_node makes it awkward. Lets go with what you have presently and fix up the comment to say why region devices are special. _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
