On Fri, 10 Feb 2012 18:05:59 +0200 Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > On Fri, Feb 10, 2012 at 5:35 PM, Justin P. Mattock > <justinmattock@xxxxxxxxx> wrote: > > On Thu, 9 Feb 2012 21:18:49 -0800 > > Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> 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? > >> > >> I fail to understand why this warning happens, why it depends on the > >> firmware, and why you can't detect it at runtime to not do it. And how > >> it all ties into a kconfig option... > >> > >> confused, > >> > >> greg k-h > > > > so there are _two_ issues that need to be fixed here: > > > > 1) the warning fix. > > > > 2) the whole default y thing that Mr. Torvalds is talking about. > > (the first fix(in my mind)would need to go first before anything else) > > > > Now reading through, greg had mentioned something about dependency, so if this is just dependency then add the proper > > Kconfig option, but if this is more than just a _dependency_ then somebody(who knows this code)is going to > > have to supply the proper fix for the warning(my C skills only take me so far!) > > > > below is my go at sending a _dependency_ fix for this, but could be totally wrong.. > > > > From 5c7ad6c00d051d5444474007cdbecdf14bf3d0cb Mon Sep 17 00:00:00 2001 > > From: "Justin P. Mattock" <justinmattock@xxxxxxxxx> > > Date: Fri, 10 Feb 2012 07:19:45 -0800 > > Subject: [PATCH] Add dependency TIDSBRIDGE_WDT3 to TIDSBRIDGE. > > > > This would add the missing _dependency_ to tidsbridge to prevent a warning from happening. > > > > Note: my Kconfig skills are not the greatest so the below may or may not work. > > I can't test this because I dont have the hardware. > > Your patch *always* turns on TIDSPBRIDGE_WDT3, which is not what we > want. Depending on the firmware, some people might want it off. > > Basically, right now on the typical firmware, people have to either > manually turn TIDSPBRIDGE_WDT3 on, or they will see the warning. > > Cheers. > > -- > Felipe Contreras ahh!! I see.. then maybe it needs be something like what omar had suggested, or maybe even some dmi_system_id(but the kernel has to many of those). -- Justin P. Mattock <justinmattock@xxxxxxxxx> _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
