> Would it make sense to merge patches 2, 4, 5 and 6 into a single one? > They all deal with the same thing (ie. they bring back ->bind callback) > and it seems to me like all those changes belong in a single patch as > otherwise they produce some intermediate states, which don't have clean > purpose.
- 2 introduces bind in struct usb_composite_driver. No gadget sets this, only composite does. - 4 adds only _ref so we don't have section missmatch warnings in between. - 5 moves the argument from usb_composite_probe() into struct usb_composite_driver. - 6 moves the argument from usb_gadget_probe_driver() into struct usb_gadget_driver. Each patch changes one logical part and should not break build / functionality during bisect. > For instance this patch fiddles with composite_bind_probe() so that it > allows both the bind argument and driver->bind callback, but than patch > 5 fiddles with this even more removing bind argument. I agree that 2 + 5 do the same thing as 6 but in a different struct. However if you look at changes 2 and 5 than you see that they are bigger than in 6. I would like to keep 4, 5, 6 seperated as they do different things. I could merge 2 and 5 if you really think it makes reading patch easier. > Others may disagree, but I feel that those changes would be simpler to > understand if put as a single patch. Also, even though I wrote three > paragraphs on that issue, I don't have strong feelings, and: > > Acked-by: Michal Nazarewicz <min...@mina86.com> Okay, thanks. So I keep things as they are :) Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
