From: James Hogan <jhogan@kernel.org>
To: Rob Herring <robh+dt@kernel.org>
Cc: "Alexandre Belloni" <alexandre.belloni@bootlin.com>,
"Ralf Baechle" <ralf@linux-mips.org>,
"Allan Nielsen" <Allan.Nielsen@microsemi.com>,
Linux-MIPS <linux-mips@linux-mips.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
devicetree@vger.kernel.org,
"Álvaro Fernández Rojas" <noltari@gmail.com>,
"Kevin Cernekee" <cernekee@gmail.com>,
"Florian Fainelli" <f.fainelli@gmail.com>
Subject: MIPS DT W=1 warnings (was Re: [PATCH v5 2/5] MIPS: mscc: add ocelot dtsi)
Date: Wed, 7 Mar 2018 21:49:26 +0000 [thread overview]
Message-ID: <20180307214925.GU4197@saruman> (raw)
In-Reply-To: <CAL_JsqKzEUO1DiaVtw8vBtiO9Xw7_5EprrC8z3C9JA6bFq1KmQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2280 bytes --]
Hi Rob,
On Wed, Mar 07, 2018 at 10:08:28AM -0600, Rob Herring wrote:
> Please compile with W=1 and fix any issues like this one which is a
> unit-address without a reg property. Drop the unit-address.
I was just giving the BMIPS W=1 DT warnings a look, and a few look
spurious. I'd value your opinion on their legitimacy (its hard to care
about W=1 if spurious or seemingly pedantic warnings are going to be
common). e.g.
1)
arch/mips/boot/dts/brcm/bcm9ejtagprb.dtb: Warning (unit_address_vs_reg): Node /ubus/syscon-reboot@10000068 has a unit name, but no reg property
due to:
periph_cntl: syscon@fff8c000 {
compatible = "syscon";
reg = <0xfff8c000 0xc>;
native-endian;
};
reboot: syscon-reboot@fff8c008 {
compatible = "syscon-reboot";
regmap = <&periph_cntl>;
offset = <0x8>;
mask = <0x1>;
};
That doesn't seem to take regmap into account. Would you strictly drop
the unit-address in this case, or is there a way the DT compiler can be
fixed (i presume offset and mask are binding specific, so the best it
could do is probably to allow the unit-address due to the regmap without
checking the actual address)?
2)
arch/mips/boot/dts/brcm/bcm9ejtagprb.dtb: Warning (simple_bus_reg): Node /ubus/syscon-reboot@10000068 missing or empty reg/ranges property
Same code as above. Should syscon-reboot be outside of the simple-bus
that both nodes are in, or is it fine there? There's a similar warning
from a DTS which has a syscon property instead of regmap.
3)
arch/mips/boot/dts/brcm/bcm97425svmb.dtb: Warning (simple_bus_reg): Node /rdb@10000000/spi@41c000 simple-bus unit address format error, expected "419920"
qspi: spi@41c000 {
#address-cells = <0x1>;
#size-cells = <0x0>;
compatible = "brcm,spi-bcm-qspi",
"brcm,spi-brcmstb-qspi";
clocks = <&upg_clk>;
reg = <0x419920 0x4 0x41c200 0x188 0x41c000 0x50>;
reg-names = "cs_reg", "hif_mspi", "bspi";
...
Well 41c000 is one of the reg entries, just not the first. I presume
bspi is the "main" one, perhaps that should come first since we have
reg-names, but even that could potentially confuse driver code if it
didn't find reg resources by name (in this case it does appear to, so
perhaps that would fine)?
Thanks
James
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-03-07 21:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-06 12:16 [PATCH v5 0/5] MIPS: add support for Microsemi MIPS SoCs Alexandre Belloni
2018-03-06 12:16 ` [PATCH v5 1/5] dt-bindings: mips: Add bindings for Microsemi SoCs Alexandre Belloni
2018-03-06 12:16 ` [PATCH v5 2/5] MIPS: mscc: add ocelot dtsi Alexandre Belloni
2018-03-07 15:17 ` James Hogan
2018-03-07 15:27 ` Alexandre Belloni
2018-03-07 15:56 ` James Hogan
2018-03-07 16:04 ` Alexandre Belloni
2018-03-07 16:08 ` Rob Herring
2018-03-07 21:49 ` James Hogan [this message]
2018-03-06 12:16 ` [PATCH v5 3/5] MIPS: mscc: add ocelot PCB123 device tree Alexandre Belloni
2018-03-06 12:16 ` [PATCH v5 4/5] MIPS: generic: Add support for Microsemi Ocelot Alexandre Belloni
2018-03-07 15:47 ` James Hogan
2018-03-06 12:16 ` [PATCH v5 5/5] MAINTAINERS: Add entry for Microsemi MIPS SoCs Alexandre Belloni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180307214925.GU4197@saruman \
--to=jhogan@kernel.org \
--cc=Allan.Nielsen@microsemi.com \
--cc=alexandre.belloni@bootlin.com \
--cc=cernekee@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=noltari@gmail.com \
--cc=ralf@linux-mips.org \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.