On Tuesday, May 13, 2014 8:30 AM, Felipe Balbi wrote: > > On Tue, May 13, 2014 at 11:13:58AM -0400, Alan Stern wrote: > > On Tue, 13 May 2014, Felipe Balbi wrote: > > > > > drivers/reset/core.c does not provide an empty > > > stub for cases when CONFIG_RESET_CONTROLLER isn't > > > enabled, which might break build of the MSM PHY > > > driver if that driver is enabled but > > > CONFIG_RESET_CONTROLLER isn't. > > > > > > We make the driver depend on CONFIG_RESET_CONTROLLER > > > so we can never have such a case > > > > This may be a dumb comment... Would it be better to add the > > appropriate stub routines instead? > > maybe... 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. I admit to being a bit sensitive about this, since I got bit by a situation where the driver relied on the firmware to get the hardware into a proper state. :-) -- Tim -- 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
