| Message ID | a062d9ed0d3365b578156a780202fa533e725374.1515650104.git.viresh.kumar@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Jan 10, 2018 at 11:58 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > The interrupt-parent of rtc was missing, add it. > > Fixes: 8113ba917dfa ("ARM: SPEAr: DT: Update device nodes") > Cc: stable@vger.kernel.org # v3.8+ > Reported-by: Arnd Bergmann <arnd@arndb.de> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > --- > arch/arm/boot/dts/spear600.dtsi | 1 + > 1 file changed, 1 insertion(+) For all three patches: Reviewed-by: Rob Herring <robh@kernel.org>
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@vger.kernel.org # v3.8+ > Reported-by: Arnd Bergmann <arnd@arndb.de> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Applied to next/dt. Is stable really needed on this? It's been broken since pretty much forever, and nobody has complained... :) -Olof
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@vger.kernel.org # v3.8+ > > Reported-by: Arnd Bergmann <arnd@arndb.de> > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > 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 :)
On Thu, Jan 11, 2018 at 7:22 PM, Viresh Kumar <viresh.kumar@linaro.org> 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@vger.kernel.org # v3.8+ >> > Reported-by: Arnd Bergmann <arnd@arndb.de> >> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> >> >> 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. -Olof
On Fri, Jan 12, 2018 at 4:23 AM, Olof Johansson <olof@lixom.net> wrote: > On Thu, Jan 11, 2018 at 7:22 PM, Viresh Kumar <viresh.kumar@linaro.org> 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@vger.kernel.org # v3.8+ >>> > Reported-by: Arnd Bergmann <arnd@arndb.de> >>> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> >>> >>> 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? 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. Arnd
On Fri, Jan 12, 2018 at 12:56 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Fri, Jan 12, 2018 at 4:23 AM, Olof Johansson <olof@lixom.net> wrote: >> On Thu, Jan 11, 2018 at 7:22 PM, Viresh Kumar <viresh.kumar@linaro.org> 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@vger.kernel.org # v3.8+ >>>> > Reported-by: Arnd Bergmann <arnd@arndb.de> >>>> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> >>>> >>>> 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. Rob? > 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. -Olof
On Fri, Jan 12, 2018 at 12:23 PM, Olof Johansson <olof@lixom.net> wrote: > On Fri, Jan 12, 2018 at 12:56 AM, Arnd Bergmann <arnd@arndb.de> wrote: >> On Fri, Jan 12, 2018 at 4:23 AM, Olof Johansson <olof@lixom.net> wrote: >>> On Thu, Jan 11, 2018 at 7:22 PM, Viresh Kumar <viresh.kumar@linaro.org> 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@vger.kernel.org # v3.8+ >>>>> > Reported-by: Arnd Bergmann <arnd@arndb.de> >>>>> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> >>>>> >>>>> 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. >> 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. Rob
On Fri, Jan 12, 2018 at 12:45 PM, Rob Herring <robh+dt@kernel.org> wrote: > On Fri, Jan 12, 2018 at 12:23 PM, Olof Johansson <olof@lixom.net> wrote: >> On Fri, Jan 12, 2018 at 12:56 AM, Arnd Bergmann <arnd@arndb.de> wrote: >>> On Fri, Jan 12, 2018 at 4:23 AM, Olof Johansson <olof@lixom.net> wrote: >>>> On Thu, Jan 11, 2018 at 7:22 PM, Viresh Kumar <viresh.kumar@linaro.org> 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@vger.kernel.org # v3.8+ >>>>>> > Reported-by: Arnd Bergmann <arnd@arndb.de> >>>>>> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> >>>>>> >>>>>> 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
On Fri, Jan 12, 2018 at 10:50 PM, Olof Johansson <olof@lixom.net> wrote: > On Fri, Jan 12, 2018 at 12:45 PM, Rob Herring <robh+dt@kernel.org> wrote: >> On Fri, Jan 12, 2018 at 12:23 PM, Olof Johansson <olof@lixom.net> wrote: >> 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. Maybe also report any other output from the build process as another category. When things build fine, we should see no output at all. Arnd
On Fri, Jan 12, 2018 at 1:53 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Fri, Jan 12, 2018 at 10:50 PM, Olof Johansson <olof@lixom.net> wrote: >> On Fri, Jan 12, 2018 at 12:45 PM, Rob Herring <robh+dt@kernel.org> wrote: >>> On Fri, Jan 12, 2018 at 12:23 PM, Olof Johansson <olof@lixom.net> wrote: >>> 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. > > Maybe also report any other output from the build process as another > category. When things build fine, we should see no output at all. Yep, true. Right now there's mostly DTC warnings and missing MODULE_LICENSE(). -Olof
On Fri, Jan 12, 2018 at 10:57 PM, Olof Johansson <olof@lixom.net> wrote: > On Fri, Jan 12, 2018 at 1:53 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> On Fri, Jan 12, 2018 at 10:50 PM, Olof Johansson <olof@lixom.net> wrote: >>> On Fri, Jan 12, 2018 at 12:45 PM, Rob Herring <robh+dt@kernel.org> wrote: >>>> On Fri, Jan 12, 2018 at 12:23 PM, Olof Johansson <olof@lixom.net> wrote: >>>> 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. >> >> Maybe also report any other output from the build process as another >> category. When things build fine, we should see no output at all. > > Yep, true. > > Right now there's mostly DTC warnings and missing MODULE_LICENSE(). I've sent patches for all the remaining MODULE_LICENSE warnings earlier this week, and we should now have patches for almost all the dtc warnings in flight. This is what I still see on my randconfig builder with linux-next + arm-soc/for-next + patches I sent: arch/arm/boot/dts/spear1310-evb.dtb: Warning (gpios_property): Missing property '#gpio-cells' in node /interrupt-controller@ec801000 or bad phandle (referred from /ahb/apb/spi@e0100000:cs-gpios[6]) arch/arm/boot/dts/spear1310-evb.dtb: Warning (gpios_property): Property 'cs-gpios', cell 6 is not a phandle reference in /ahb/apb/spi@e0100000 arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): Missing property '#dma-cells' in node /interrupt-controller@ec801000 or bad phandle (referred from /ahb/apb/serial@b4100000:dmas[4]) arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): Property 'dmas', cell 4 is not a phandle reference in /ahb/apb/serial@b4100000 arch/arm/boot/dts/spear600-evb.dtb: Warning (interrupts_property): Missing interrupt-parent for /ahb/apb/rtc@fc900000 arch/arm/boot/dts/ste-nomadik-nhk15.dtb: Warning (interrupts_property): Missing interrupt-parent for /amba/clcd@10120000 arch/arm/boot/dts/ste-nomadik-s8815.dtb: Warning (interrupts_property): Missing interrupt-parent for /amba/clcd@10120000 Not sure why the spear warnings are still there, maybe Viresh missed those or you missed one of his patches? I hope Linus Walleij can find out what the right interrupt-parent should be on the nomadik machine, that is otherwise the last remaining warning. Apparently the clcd driver doesn't actually need its interrupt, so we could decide to just comment out that line if we don't know which controller it's connected to. Arnd
On Fri, Jan 12, 2018 at 3:07 AM, Olof Johansson <olof@lixom.net> 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@vger.kernel.org # v3.8+ >> Reported-by: Arnd Bergmann <arnd@arndb.de> >> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > Applied to next/dt. Is stable really needed on this? It's been broken since > pretty much forever, and nobody has complained... :) The SPEAr architecture is widely used (in modified variants) by a large industrial automation company, 20+ years of support cycle. However I think they have a forked both kernel and hardware, so they will not notice any time soon, and when they eventually upgrade they can simply pick the latest I guess. Yours, Linus Walleij
On Fri, Jan 12, 2018 at 11:05 PM, Arnd Bergmann <arnd@arndb.de> wrote: > arch/arm/boot/dts/ste-nomadik-nhk15.dtb: Warning > (interrupts_property): Missing interrupt-parent for > /amba/clcd@10120000 > arch/arm/boot/dts/ste-nomadik-s8815.dtb: Warning > (interrupts_property): Missing interrupt-parent for > /amba/clcd@10120000 (...) > I hope Linus Walleij can find out what the right interrupt-parent > should be on the > nomadik machine, that is otherwise the last remaining warning. OK I will look into it. > Apparently the > clcd driver doesn't actually need its interrupt, so we could decide to > just comment > out that line if we don't know which controller it's connected to. I am migrating it to the new DRM driver which uses the IRQ to sync screen output to avoid tearing so it would be unfortunate. I will look into it. Yours, Linus Walleij
Hi, On 14/01/2018 at 12:17:23 +0100, Linus Walleij wrote: > On Fri, Jan 12, 2018 at 3:07 AM, Olof Johansson <olof@lixom.net> 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@vger.kernel.org # v3.8+ > >> Reported-by: Arnd Bergmann <arnd@arndb.de> > >> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > > > > Applied to next/dt. Is stable really needed on this? It's been broken since > > pretty much forever, and nobody has complained... :) > > The SPEAr architecture is widely used (in modified variants) by > a large industrial automation company, 20+ years of support cycle. > > However I think they have a forked both kernel and hardware, so they > will not notice any time soon, and when they eventually upgrade they > can simply pick the latest I guess. > We have a customer using mainline v4.14 on their Spear600 based products. I guess the reason why nobody complained is simply because nobody is using the SoC RTC ;)
On 12-01-18, 23:05, Arnd Bergmann wrote: > I've sent patches for all the remaining MODULE_LICENSE warnings earlier > this week, and we should now have patches for almost all the dtc > warnings in flight. This is what I still see on my randconfig builder > with linux-next + arm-soc/for-next + patches I sent: > > arch/arm/boot/dts/spear1310-evb.dtb: Warning (gpios_property): > Missing property '#gpio-cells' in node /interrupt-controller@ec801000 > or bad phandle (referred from /ahb/apb/spi@e0100000:cs-gpios[6]) > arch/arm/boot/dts/spear1310-evb.dtb: Warning (gpios_property): > Property 'cs-gpios', cell 6 is not a phandle reference in > /ahb/apb/spi@e0100000 > arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): > Missing property '#dma-cells' in node /interrupt-controller@ec801000 > or bad phandle (referred from /ahb/apb/serial@b4100000:dmas[4]) > arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): > Property 'dmas', cell 4 is not a phandle reference in > /ahb/apb/serial@b4100000 > arch/arm/boot/dts/spear600-evb.dtb: Warning > (interrupts_property): Missing interrupt-parent for > /ahb/apb/rtc@fc900000 These are all the warnings we got earlier. So none of my patches are in the branch you tested I believe. Can you do a `git log` and see if they are present ?
On Mon, Jan 15, 2018 at 5:22 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > On 12-01-18, 23:05, Arnd Bergmann wrote: >> I've sent patches for all the remaining MODULE_LICENSE warnings earlier >> this week, and we should now have patches for almost all the dtc >> warnings in flight. This is what I still see on my randconfig builder >> with linux-next + arm-soc/for-next + patches I sent: >> >> arch/arm/boot/dts/spear1310-evb.dtb: Warning (gpios_property): >> Missing property '#gpio-cells' in node /interrupt-controller@ec801000 >> or bad phandle (referred from /ahb/apb/spi@e0100000:cs-gpios[6]) >> arch/arm/boot/dts/spear1310-evb.dtb: Warning (gpios_property): >> Property 'cs-gpios', cell 6 is not a phandle reference in >> /ahb/apb/spi@e0100000 >> arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): >> Missing property '#dma-cells' in node /interrupt-controller@ec801000 >> or bad phandle (referred from /ahb/apb/serial@b4100000:dmas[4]) >> arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): >> Property 'dmas', cell 4 is not a phandle reference in >> /ahb/apb/serial@b4100000 >> arch/arm/boot/dts/spear600-evb.dtb: Warning >> (interrupts_property): Missing interrupt-parent for >> /ahb/apb/rtc@fc900000 > > These are all the warnings we got earlier. So none of my patches are in the > branch you tested I believe. Can you do a `git log` and see if they are present > ? I checked again on today's linux-next and all your patches are there, and the warning is gone. Whatever caused the warnings to still appear seems to be gone now. Sorry for the confusion. Arnd
On Sun, Jan 14, 2018 at 12:20 PM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Fri, Jan 12, 2018 at 11:05 PM, Arnd Bergmann <arnd@arndb.de> wrote: > >> arch/arm/boot/dts/ste-nomadik-nhk15.dtb: Warning >> (interrupts_property): Missing interrupt-parent for >> /amba/clcd@10120000 >> arch/arm/boot/dts/ste-nomadik-s8815.dtb: Warning >> (interrupts_property): Missing interrupt-parent for >> /amba/clcd@10120000 > (...) >> I hope Linus Walleij can find out what the right interrupt-parent >> should be on the >> nomadik machine, that is otherwise the last remaining warning. > > OK I will look into it. I took another look myself now since this was the last remaining dtc warning in linux-next. The answer was easy enough to find in the git history for the board files: all the on-chip devices are connected to the same VIC instance. I'll send the patch. Arnd
diff --git a/arch/arm/boot/dts/spear600.dtsi b/arch/arm/boot/dts/spear600.dtsi index 6b32d20acc9f..00166eb9be86 100644 --- a/arch/arm/boot/dts/spear600.dtsi +++ b/arch/arm/boot/dts/spear600.dtsi @@ -194,6 +194,7 @@ rtc: rtc@fc900000 { compatible = "st,spear600-rtc"; reg = <0xfc900000 0x1000>; + interrupt-parent = <&vic0>; interrupts = <10>; status = "disabled"; };
The interrupt-parent of rtc was missing, add it. Fixes: 8113ba917dfa ("ARM: SPEAr: DT: Update device nodes") Cc: stable@vger.kernel.org # v3.8+ Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> --- arch/arm/boot/dts/spear600.dtsi | 1 + 1 file changed, 1 insertion(+)