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
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 th
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
> > > >
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 m
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
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
