[PATCH] staging: tidspbridge: enable watchdog by default

[Greg KH]

On Fri, Feb 10, 2012 at 06:16:19PM +0200, Felipe Contreras wrote:
> On Fri, Feb 10, 2012 at 7:18 AM, Greg KH <gregkh at linuxfoundation.org> wrote:
> > On Thu, Feb 09, 2012 at 04:45:00PM -0800, Ramirez Luna, Omar wrote:
> >> Hi,
> >>
> >> On Thu, Feb 9, 2012 at 3:30 PM, Felipe Contreras
> >> <felipe.contreras at gmail.com> wrote:
> >> >> Again, I'm totally confused as to _WHY_ this needs to be y.  What is
> >> >> causing this oops without it?  If an oops is happening, then shouldn't
> >> >> this be a strict dependancy?  Why allow it to be disabled at all if it
> >> >> can break your box if you don't enable it?
> >> >
> >> > It's not an oops, it's a warning, and again, it depends on the
> >> > firmware being used. We don't have control over that, and we have no
> >> > way to detect if this feature is there. It's up to the user.
> >>
> >> I have been thinking more into it, how about looking for a WDT symbol
> >> inside the baseimage to decide whether to turn ON/OFF WDT3, this would
> >> mean that the code is always compiled in, but the decision to turn it
> >> on/off is made at runtime.
> >
> > I totally don't understand, why not just silence the warning properly
> > then?
> 
> The warning doesn't come from the driver, and AFAIK it's a valid
> warning. Now, I haven't explored the code, so I don't know what's
> going on, I just know Omar said this fixes the warning, and that
> there's no easy way around it.
> 
> > I fail to understand why this warning happens,
> 
> I don't know either, I just know enabling TIDSPBRIDGE_WDT3 fixes it.

Ok, I suggest someone get to the root cause of this before we change
anything, although some better Kconfig text would be nice to have to
document the existing issues.

thanks,

greg k-h