On Sun, Apr 13, 2014 at 05:24:01PM -0500, David Fries wrote: > Belisko Marek, > Here is a possible solution, could you give it a try and report back? > > Greg Kroah-Hartman, > Evgeniy asked me to look into this report. I don't have the > reporter's hardware configuration, but I wouldn't think that would be > needed, just some w1 bus master (even W1_MASTER_GPIO might work), then > loading the slave device and manually adding a slave device with that > family id. Even then I didn't reproduce the reported recursive > locking error. I saw unrelated locking reports, but not this one. I > wrote up the included patch, but that undoes the notify changes that > you added earlier in commit 47eba33a0997fc7, and I wanted to ask about > that commit. Specifically these two lines, > > err = device_register(&sl->dev); > ... > + dev_set_uevent_suppress(&sl->dev, false); > + kobject_uevent(&sl->dev.kobj, KOBJ_ADD); > > Wouldn't the default be to not suppress? Nothing in the W1 system > enables suppressing so is that even needed? (I'm fine with saying > it's a good idea). > device_register at some point must call device_add and device_add > calls kobject_uevent(&dev->kobj, KOBJ_ADD); > so doesn't the KOBJ_ADD send the add a second time? As in it > shouldn't be needed? > Can the suppress be called before device_register to avoid the > automatic notify, then after it returns setup the slave device as this > patch does to avoid this problem report, and then call the KOBJ_ADD to > make everything happy?
I really have no idea, if your fix resolves an issue, that's great, I'll be glad to take it. I have no w1 devices to test any of this, and don't even remember writing that kernel patch :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
