From: Kuldeep Singh <singh.kuldeep87k@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Viresh Kumar <vireshk@kernel.org>,
Shiraz Hashim <shiraz.linux.kernel@gmail.com>,
SoC Team <soc@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
DTML <devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] ARM: dts: spear13xx: Update SPI dma properties
Date: Sat, 26 Mar 2022 00:56:37 +0530 [thread overview]
Message-ID: <20220325192637.GA15904@9a2d8922b8f1> (raw)
In-Reply-To: <20220325173826.GA70042@9a2d8922b8f1>
On Fri, Mar 25, 2022 at 11:08:26PM +0530, Kuldeep Singh wrote:
> On Fri, Mar 25, 2022 at 10:11:41AM +0100, Arnd Bergmann wrote:
> > On Fri, Mar 25, 2022 at 2:58 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > > On 24-03-22, 11:55, Kuldeep Singh wrote:
> > > > Fixed order of values is important in case of properties like
> > > > compatibles etc. In case of dma-names, yes order shouldn't matter here.
> > > >
> > > > This patch is more of appeasing dtbs_check warning rather than fixing
> > > > something.
> > >
> > > Exactly my point. We have seen similar type of issues with other tools, like
> > > coccinelle, earlier and such patches were rejected as the kernel was just fine
> > > and tooling needs to be fixed.
> > >
> > > > It's safe to go with this patch.
> > > > I am not sure if there's a provision to exclude dma-names from fix
> > > > ordering checks. Rob can help here in providing better insights.
> >
> > I think it's a question of the scale of the warnings: my understanding is that
> > there are only a handful of dts files that trigger the warning at all, and it
> > would be rather hard to change the tooling around this. Since the proposed
> > dts change is clearly harmless, I don't mind applying it.
> >
> > Kuldeep, you have probably looked at all dts files in the kernel, can you
> > say how many of them are affected by the dma property reordering?
>
> I have checked spi-pl022.yaml as of now and this was the only one which
> was affected with dma ordering.
>
> For all dts files, I can definitely give a try and will come up with
> some numbers. Please note, there are still bindings left to be converted
> to yaml format, so won't be able to catch those cases.
I checked and found below dts with dma-names warnings[1].
spear1340, spear1310, spear13xx, fsl-ls1043a, fsl-ls1046a
Yes Arnd, you were right. Very few dts are affected by dma ordering
right now. There might be cases where nodes don't define generic names
and thus not running required checks, still I assume the numbers will be
very less. So, probably we can go ahead with the change.
- Kuldeep
[1]
root@9a2d8922b8f1:~/linux/torvalds# grep "'rx' was expected" output.txt
arch/arm/boot/dts/spear1340-evb.dt.yaml: spi@e0100000: dma-names:0: 'rx' was expected
arch/arm/boot/dts/spear1310-evb.dt.yaml: spi@e0100000: dma-names:0: 'rx' was expected
arch/arm/boot/dts/spear1340-evb.dt.yaml: serial@b4100000: dma-names:0: 'rx' was expected
root@9a2d8922b8f1:~/linux/torvalds# grep "'rx' was expected" arm64_all
arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dt.yaml: i2c@2180000: dma-names:0: 'rx' was expected
arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dt.yaml: i2c@2180000: dma-names:0: 'rx' was expected
arch/arm64/boot/dts/freescale/fsl-ls1046a-frwy.dt.yaml: i2c@2180000: dma-names:0: 'rx' was expected
arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dt.yaml: i2c@2180000: dma-names:0: 'rx' was expected
arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dt.yaml: i2c@2180000: dma-names:0: 'rx' was expected
prev parent reply other threads:[~2022-03-25 19:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-23 17:59 [PATCH v2] ARM: dts: spear13xx: Update SPI dma properties Kuldeep Singh
2022-03-24 2:39 ` Viresh Kumar
2022-03-24 6:25 ` Kuldeep Singh
2022-03-25 1:58 ` Viresh Kumar
2022-03-25 9:11 ` Arnd Bergmann
2022-03-25 9:13 ` Viresh Kumar
2022-03-25 17:38 ` Kuldeep Singh
2022-03-25 19:26 ` Kuldeep Singh [this message]
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=20220325192637.GA15904@9a2d8922b8f1 \
--to=singh.kuldeep87k@gmail.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=shiraz.linux.kernel@gmail.com \
--cc=soc@kernel.org \
--cc=viresh.kumar@linaro.org \
--cc=vireshk@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).