From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olof Johansson Subject: Re: [PATCH 1/3] arm: spear600: Add missing interrupt-parent of rtc Date: Fri, 12 Jan 2018 13:50:13 -0800 Message-ID: References: <20180112020711.6gp2pnsxxjzelidq@localhost> <20180112032223.GK3626@vireshk-i7> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Rob Herring Cc: Arnd Bergmann , Viresh Kumar , ARM-SoC Maintainers , Linux ARM Mailing List , DTML , gregkh List-Id: devicetree@vger.kernel.org On Fri, Jan 12, 2018 at 12:45 PM, Rob Herring wrote: > On Fri, Jan 12, 2018 at 12:23 PM, Olof Johansson wrote: >> On Fri, Jan 12, 2018 at 12:56 AM, Arnd Bergmann wrote: >>> On Fri, Jan 12, 2018 at 4:23 AM, Olof Johansson wrote: >>>> On Thu, Jan 11, 2018 at 7:22 PM, Viresh Kumar wrote: >>>>> On 11-01-18, 18:07, Olof Johansson wrote: >>>>>> On Thu, Jan 11, 2018 at 11:28:51AM +0530, Viresh Kumar wrote: >>>>>> > The interrupt-parent of rtc was missing, add it. >>>>>> > >>>>>> > Fixes: 8113ba917dfa ("ARM: SPEAr: DT: Update device nodes") >>>>>> > Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org # v3.8+ >>>>>> > Reported-by: Arnd Bergmann >>>>>> > Signed-off-by: Viresh Kumar >>>>>> >>>>>> Applied to next/dt. Is stable really needed on this? It's been broken since >>>>>> pretty much forever, and nobody has complained... :) >>>>> >>>>> Not sure. Just thought it may be useful for someone somewhere :) >>>> >>>> Ok. Left the tags there, but didn't merge into fixes since we're late >>>> in -rc and this didn't seem critical at this time. >>> >>> My plan was to have these in the fixes branch in the hope of making >>> it to a clean build for 4.15 after all, they fix warnings that got introduced >>> by the updated dtc checks in 4.15-rc1. >>> >>> We are getting fairly close, but it seems we still miss a few, so we >>> might as well give up at this point. The remaining fixes should be easy >>> to backport into v4.15.y if we decide to do it, of further back even. >>> For v4.14 and before, the in-kernel copy of dtc won't warn, but mainline >>> dtc will. >>> >>> Greg, let me know your thoughts on this for the upcoming 4.15.y >>> release. We had hundreds of dtc warnings in 4.15-rc1, many of them >>> about important bugs, now we're down to a couple of warnings >>> for platforms we don't care about much, and I expect the last of >>> these fixes to land in 4.16-rc1 or maybe -rc2. Shall we backport >>> them all to get a clean 4.15.y release? >> >> I think it makes more sense to disable the warnings than to backport a >> bunch of warning fixes this late. The code is working, has worked for >> a long time it's just that Rob enabled the warnings by default. We can >> keep them enabled for 4.16. > > In some cases "working" was what's in the DT is unused by the kernel > because the DT is broken. That's why this round was not off by > default. > > It looks to me to be somewhere less than 5 fixes remaining (BTW, why > is there no arm32 allmodconfig build on kernelci.org? That or > allyesconfig are the only ways to build all dtbs). It would also be an > exception to the the stable process because that patch would not be in > Linus' tree. I build them but my script that analyses for warnings only looks for the gcc "warning:" output. Need to do grep -i to catch them. FWIW, logs are here: http://arm-soc.lixom.net/buildlogs/mainline/v4.15-rc7-200-gc92a9a4/buildall.arm.allmodconfig.log.passed >>> Note: there was at least one dtc warning fix that caused a serious >>> regression in code that relied on a device probe to fail because of >>> an invalid node (a fix is still in the works for 4.15), though generally >>> the fixes are really harmless and can only make things better. >> >> Exactly why picking up warning fixes this late is probably not a great idea. > > Applying them now for 4.15 would be late, but tagging them as fixes in > 4.16 would not be late (other than the normal problem that things get > applied to stable before sufficient testing in master). > > > I have more dtc checks in the works (nothing for 4.16 :) ). I'd like > the process to work better. I'm not going to fix all the warnings. I > don't think Arnd should either. Turning them off by default hasn't > worked great either. For some, I'm not sure we can ever get to warning > free, but I'd like new stuff to have warnings enabled and no one > builds with W=1. We could put together tooling to just show new > warnings, but someone has to run it and enforce it. I could stick dtc > updates into linux-next for multiple cycles before sending to Linus. I'll split up and report DT warnings separate from compiler, seems like a reasonable approach. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html