On Tue, May 13, 2014 at 05:49:06PM +0200, Bird, Tim wrote: > 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. heh, stubs are only stubs... they're there so the driver can still build otherwise every module's dependency list would be gigantic. IOW, stubs are only for randconfig's sake. -- balbi
Attachment:
signature.asc
Description: Digital signature
