Hello, Ben. On Tue, Mar 18, 2014 at 11:22:26AM +1100, Benjamin Herrenschmidt wrote: > On Mon, 2014-03-17 at 18:21 -0400, Tejun Heo wrote: > > So, looked at the failed code. The only necessary change seems to be > > calling device_remove_file_self() in dump_ack_store() and then doing > > kobject_put() directly afterwards, which would have been completely > > fine as a merge fix patch. > > Ok. Since there's no merge error, I'll have to tell Linus explicitly to > apply it during the merge. I've never done that before but I suppose > it's doable. Yeah, that should be fine. For the next tree, including the fix patch in a temp branch and pulling that into your for-next branch should work fine. > Sorry I don't understand. Reverting the removal until after -rc1 (or > later in the merge window) is the easiest path from my perspective and > ensure no bisection breakage but whatever Linus prefers works here. Merge fix doesn't cause any bisection issue either (because it *is* a merge problem after all). It could be just my personal preference but I'd handle this one as merge fix. If we rever the removal of the interface, we'll probably need to mark it deprecated too as people tend to fork off their devel branches before or at rc1. > I don't think it's a drastic action or anything like that. It can > trivially be re-applied once the merge window has settled. But I'm happy > to also just send Linus a "apply this as a merge fixup" patch if he's > happy with the method (as I said, I've never done that before on > something that doesn't have an actual merge conflict to begin with) Sure, either should work. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
