Hello Tom,
Am 21.04.2016 um 15:53 schrieb Tom Rini:
On Thu, Apr 21, 2016 at 03:50:28PM +0200, Marek Vasut wrote:
On 04/21/2016 03:35 PM, Simon Glass wrote:
Hi,
On 21 April 2016 at 07:25, Marek Vasut <[email protected]> wrote:
On 04/21/2016 03:17 PM, Heiko Schocher wrote:
Hello Marek,
Am 21.04.2016 um 14:51 schrieb Marek Vasut:
On 04/21/2016 02:48 PM, Heiko Schocher wrote:
suppress a lot of
"reg or ranges property, but no unit name" warnings,
through the dtc compiler flag "-Wno-unit_address_vs_reg".
If all DTS are fixed, we can remove this flag again.
Signed-off-by: Heiko Schocher <[email protected]>
---
There is also a solution to suppress warnings from
the dtc compiler by the "-q" flag, but that would
suppress all warnings. Not realy what I want.
Yep
With this patch and patch:
http://patchwork.ozlabs.org/patch/609150/
travis build passes, see:
https://travis-ci.org/hsdenx/u-boot/builds/124723016
arch/arc/dts/Makefile | 2 ++
arch/arm/dts/Makefile | 3 ++-
arch/microblaze/dts/Makefile | 2 ++
arch/mips/dts/Makefile | 3 ++-
arch/nios2/dts/Makefile | 2 ++
arch/powerpc/dts/Makefile | 2 ++
arch/sandbox/dts/Makefile | 2 ++
arch/x86/dts/Makefile | 2 ++
8 files changed, 16 insertions(+), 2 deletions(-)
Isn't there some common place in scripts/ or so where we can disable
this warning using an one-liner ?
I don;t know ... but I prefer to disable this per arch .. so we can
enable the check back if one arch is fixed ...
In my opinion, we should stick to the same behavior Linux does.
Ccing a few more people.
Wouldn't it be better to fix the problems?
My impression was that these warnings are just the result of
over-eagerness of DTC, that's why Linux prints them only if you
increase the W= (warning) verbosity. I might be wrong tho.
They are minor problems. For the vast majority of the dts files we
have, the fixes will come in via re-syncs with the kernel and in at
least some cases it's not just a simple regex but also "oh, lets give
things better names". With respect to dts files that we really do own
(ie x86) yes, we should fix them.
So, this patch from me could be still an option?
http://patchwork.ozlabs.org/patch/610866/
(at least for the sandbox fixes?)
(I have a v2 where I worked in the comments from Bin ...)
bye,
Heiko
--
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
