On Tue, 2014-05-13 at 12:07 -0400, Alan Stern wrote: > On Tue, 13 May 2014, Bird, Tim wrote: > > > I don't think so. I haven't tested, but I believe the driver now relies > > on operational (not stub) resets. I think this comment is a bit off. > > I think it would be better to just say that the driver now depends on the > > reset sub-system, and thus needs the config dependency. > > > > Maybe there's a case where the driver works fine even without > > the resets, but if so it's not obvious to me. > > > > Out of curiosity - is this something that many sub-systems do: > > provide stubs for compilation, and support operating with or without > > real functionality. This seems kind of odd. > > Some subsystems do it when the functionality they provide is optional. > Runtime PM is a good example. If I could add. clk and regulator frameworks also provide stub API's, why reset framework should be different? Probably none of the drivers, which use clk or regulator, did not have dependency to these frameworks. I am pretty sure that these drivers will not work properly without proper back end implementation. Regards, Ivan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
