Message ID | 20230315114806.3819515-3-cristian.ciocaltea@collabora.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp2280085wrd; Wed, 15 Mar 2023 04:51:08 -0700 (PDT) X-Google-Smtp-Source: AK7set/HYgp+90zWzYCK8I5XFGpzXGp+WVZk17TcWK2+BuzBltV5o13l5M93hkyUqTcCbL0BQo+C X-Received: by 2002:a17:90b:4a48:b0:23e:2b3c:d4a7 with SMTP id lb8-20020a17090b4a4800b0023e2b3cd4a7mr2086625pjb.35.1678881068478; Wed, 15 Mar 2023 04:51:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1678881068; cv=none; d=google.com; s=arc-20160816; b=f9QCB89wMsaruRHav+EtB6diriyiGpu2EvQ87VnkR8xAopmGAOqA94OfzIzeAwb/GK QiimugaaeOEdcCobtSQ7g6axQsj5HqdlAdzoxtMHAsBFM7V/n+Z9qC8q845e/Mu6fLdR X7QJMFa8tDoZ0ZNd9YnC9ALNaAndBDzEZaKvla30qdYaMsaGcy4rHQ06tSIVcP4Bkgya Wea9cm9ficng8V3ShzoZ3lmmjXlt1rYtkCf4WTyUgcOJT5za2T2MMUDjnF9FIJudWXmK /E2M+vvRBBxgibfDBbR5piJ9Ps+9anj7KG5C8XO3n4xuSqmWLcrc9vLoEVv5jg1qf/4k vkYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=1QmDIc3RNkWnKufEycK3co8No0MjXufOd8NXdSv/2QA=; b=jerrSEfbIE2tBw8pZZJ3xQBHVzPZq3+0U79u0onppqrpyeVbDE5JFOR84MLFAp6CVT rnEY0hYkA143OKhXo0dwxqfDX3yqbsAJ0xmugqhzeIxuPv6JaiSHxzpXWK9s9Hkl1lDU fv4mbjOr1ByQelEI+D8xzh9vOB1t4krtVZvMi1DOFp24v9LWJ21LhaKJM2LJgGaDCUwM /y1KVryv+K0oS5uRhGHIANuNWcPC0bnEdH4YPBIqTs7U4COTj4wGFjcgnKFDrsAS5UAu C/8H5xe8Tegyd7wvjQLBMOHvEm+zk/9s9U+8Gn9YKqU/cvoxS1/c95tTlXj1um+5Jp3O vL8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=X58SfGRM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y7-20020a63e247000000b005077dda0491si4787288pgj.523.2023.03.15.04.50.56; Wed, 15 Mar 2023 04:51:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=X58SfGRM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231652AbjCOLs2 (ORCPT <rfc822;ruipengqi7@gmail.com> + 99 others); Wed, 15 Mar 2023 07:48:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54280 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231600AbjCOLsV (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 15 Mar 2023 07:48:21 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D77DC55505; Wed, 15 Mar 2023 04:48:19 -0700 (PDT) Received: from localhost (unknown [188.24.156.231]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: cristicc) by madras.collabora.co.uk (Postfix) with ESMTPSA id 57B026603058; Wed, 15 Mar 2023 11:48:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1678880898; bh=C+CkBCBIxEIFOAjzgyNm1268qn0Q1m0JZg82+SgLbSc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=X58SfGRMKG9NMnROtcQIsHKPqTiN3hEwxxvjMK1CBZAuNkvJZzsUYX46U7ZK9w6S6 dF4cWgtlSfBpB8jUa/4djaWG13TVCtFcT45OS/83t3Yw6fakhmegMNTgKGABCsilX/ wHS2lvwEUTbpSNOotY3XW9z1pVo7f5vlTrQWiLpSupOFiyAOoNrA8OYMPLMmr5TPyN JcBcMmqRoAFaPZMBUMUwP7t2IyoYiSr8EtaBYoSFn2xK3I5BULLPfOYbfOu6Wk2QXq wcRNhblusYn5BaeQW5QYIAVEuJsdJVOaqvBKDSUpfN1l8nBSghvjXURdUp51ZFH4+v PCS7fq1RtkfSA== From: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> To: Sudeep Holla <sudeep.holla@arm.com>, Cristian Marussi <cristian.marussi@arm.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>, Nicolas Frattaroli <frattaroli.nicolas@gmail.com>, Heiko Stuebner <heiko@sntech.de>, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Daniel Drake <drake@endlessm.com>, Katsuhiro Suzuki <katsuhiro@katsuster.net> Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, alsa-devel@alsa-project.org, linux-rockchip@lists.infradead.org, linux-riscv@lists.infradead.org, kernel@collabora.com Subject: [PATCH 02/11] dt-bindings: serial: snps-dw-apb-uart: Relax dma-names order constraint Date: Wed, 15 Mar 2023 13:47:57 +0200 Message-Id: <20230315114806.3819515-3-cristian.ciocaltea@collabora.com> X-Mailer: git-send-email 2.39.1 In-Reply-To: <20230315114806.3819515-1-cristian.ciocaltea@collabora.com> References: <20230315114806.3819515-1-cristian.ciocaltea@collabora.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760434395149395834?= X-GMAIL-MSGID: =?utf-8?q?1760434395149395834?= |
Series |
Enable I2S support for RK3588/RK3588S SoCs
|
|
Commit Message
Cristian Ciocaltea
March 15, 2023, 11:47 a.m. UTC
Commit 370f696e4474 ("dt-bindings: serial: snps-dw-apb-uart: add dma &
dma-names properties") documented dma-names property to handle Allwiner
D1 dtbs_check warnings, but relies on a strict rx->tx ordering, which is
the reverse of what a different board expects:
rk3326-odroid-go2.dtb: serial@ff030000: dma-names:0: 'rx' was expected
A quick and incomplete check shows the inconsistency is present in many
other DT files:
$ git grep -A10 snps,dw-apb-uart | grep dma-names | sort -u
arch/arm64/boot/dts/rockchip/px30.dtsi- dma-names = "tx", "rx";
arch/arm64/boot/dts/rockchip/rk3328.dtsi- dma-names = "tx", "rx";
arch/arm64/boot/dts/rockchip/rk3588s.dtsi- dma-names = "tx", "rx";
arch/arm/boot/dts/rk3066a.dtsi- dma-names = "tx", "rx";
arch/arm/boot/dts/rk3128.dtsi- dma-names = "tx", "rx";
arch/arm/boot/dts/rk3288.dtsi- dma-names = "tx", "rx";
arch/arm/boot/dts/rv1126.dtsi- dma-names = "tx", "rx";
arch/arm/boot/dts/socfpga.dtsi- dma-names = "tx", "rx";
arch/arm/boot/dts/sun6i-a31.dtsi- dma-names = "rx", "tx";
arch/arm/boot/dts/sun8i-a23-a33.dtsi- dma-names = "rx", "tx";
arch/arm/boot/dts/sun8i-v3s.dtsi- dma-names = "rx", "tx";
arch/arm/boot/dts/sunxi-h3-h5.dtsi- dma-names = "rx", "tx";
arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi- dma-names = "rx", "tx";
Do not enforce the order of the dma-names items.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
.../devicetree/bindings/serial/snps-dw-apb-uart.yaml | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
Comments
On 15/03/2023 12:47, Cristian Ciocaltea wrote: > Commit 370f696e4474 ("dt-bindings: serial: snps-dw-apb-uart: add dma & > dma-names properties") documented dma-names property to handle Allwiner > D1 dtbs_check warnings, but relies on a strict rx->tx ordering, which is > the reverse of what a different board expects: > > rk3326-odroid-go2.dtb: serial@ff030000: dma-names:0: 'rx' was expected > > A quick and incomplete check shows the inconsistency is present in many > other DT files: Why not fixing the DTS? The properties should have fixed order. Best regards, Krzysztof
On 3/17/23 10:31, Krzysztof Kozlowski wrote: > On 15/03/2023 12:47, Cristian Ciocaltea wrote: >> Commit 370f696e4474 ("dt-bindings: serial: snps-dw-apb-uart: add dma & >> dma-names properties") documented dma-names property to handle Allwiner >> D1 dtbs_check warnings, but relies on a strict rx->tx ordering, which is >> the reverse of what a different board expects: >> >> rk3326-odroid-go2.dtb: serial@ff030000: dma-names:0: 'rx' was expected >> >> A quick and incomplete check shows the inconsistency is present in many >> other DT files: > > Why not fixing the DTS? The properties should have fixed order. I was initially concerned about the risk of a potential ABI breakage, but I think that's not really a problem since dma-names is not directly accessed in the driver and DT Kernel API doesn't rely on a particular order. If there are no objections, I would switch the order in the binding to tx->rx, since that's what most of the DTS use, and fix the remaining ones. > Best regards, > Krzysztof Thanks, Cristian
On 17/03/2023 11:21, Cristian Ciocaltea wrote: > On 3/17/23 10:31, Krzysztof Kozlowski wrote: >> On 15/03/2023 12:47, Cristian Ciocaltea wrote: >>> Commit 370f696e4474 ("dt-bindings: serial: snps-dw-apb-uart: add dma & >>> dma-names properties") documented dma-names property to handle Allwiner >>> D1 dtbs_check warnings, but relies on a strict rx->tx ordering, which is >>> the reverse of what a different board expects: >>> >>> rk3326-odroid-go2.dtb: serial@ff030000: dma-names:0: 'rx' was expected >>> >>> A quick and incomplete check shows the inconsistency is present in many >>> other DT files: >> >> Why not fixing the DTS? The properties should have fixed order. > > I was initially concerned about the risk of a potential ABI breakage, > but I think that's not really a problem since dma-names is not directly > accessed in the driver and DT Kernel API doesn't rely on a particular order. > > If there are no objections, I would switch the order in the binding to > tx->rx, since that's what most of the DTS use, and fix the remaining ones. Since we added the order recently, I rather assume it is the correct or preferred one. Best regards, Krzysztof
On Fri, Mar 17, 2023 at 04:54:47PM +0100, Krzysztof Kozlowski wrote: > On 17/03/2023 11:21, Cristian Ciocaltea wrote: > > On 3/17/23 10:31, Krzysztof Kozlowski wrote: > >> On 15/03/2023 12:47, Cristian Ciocaltea wrote: > >>> Commit 370f696e4474 ("dt-bindings: serial: snps-dw-apb-uart: add dma & > >>> dma-names properties") documented dma-names property to handle Allwiner > >>> D1 dtbs_check warnings, but relies on a strict rx->tx ordering, which is > >>> the reverse of what a different board expects: > >>> > >>> rk3326-odroid-go2.dtb: serial@ff030000: dma-names:0: 'rx' was expected > >>> > >>> A quick and incomplete check shows the inconsistency is present in many > >>> other DT files: > >> > >> Why not fixing the DTS? The properties should have fixed order. > > > > I was initially concerned about the risk of a potential ABI breakage, > > but I think that's not really a problem since dma-names is not directly > > accessed in the driver and DT Kernel API doesn't rely on a particular order. > > > > If there are no objections, I would switch the order in the binding to > > tx->rx, since that's what most of the DTS use, and fix the remaining ones. > > Since we added the order recently, I rather assume it is the correct or > preferred one. IIRC I checked around the other serial bindings & there was not a consistent order that all serial bindings used, so I picked the order that was used across the various allwinner boards that do use dma-names. Before changing dts files, it's probably a good idea to make sure that the dma-names are not used somewhere outside of Linux. Cheers, Conor.
On 3/17/23 18:26, Conor Dooley wrote: > On Fri, Mar 17, 2023 at 04:54:47PM +0100, Krzysztof Kozlowski wrote: >> On 17/03/2023 11:21, Cristian Ciocaltea wrote: >>> On 3/17/23 10:31, Krzysztof Kozlowski wrote: >>>> On 15/03/2023 12:47, Cristian Ciocaltea wrote: >>>>> Commit 370f696e4474 ("dt-bindings: serial: snps-dw-apb-uart: add dma & >>>>> dma-names properties") documented dma-names property to handle Allwiner >>>>> D1 dtbs_check warnings, but relies on a strict rx->tx ordering, which is >>>>> the reverse of what a different board expects: >>>>> >>>>> rk3326-odroid-go2.dtb: serial@ff030000: dma-names:0: 'rx' was expected >>>>> >>>>> A quick and incomplete check shows the inconsistency is present in many >>>>> other DT files: >>>> >>>> Why not fixing the DTS? The properties should have fixed order. >>> >>> I was initially concerned about the risk of a potential ABI breakage, >>> but I think that's not really a problem since dma-names is not directly >>> accessed in the driver and DT Kernel API doesn't rely on a particular order. >>> >>> If there are no objections, I would switch the order in the binding to >>> tx->rx, since that's what most of the DTS use, and fix the remaining ones. >> >> Since we added the order recently, I rather assume it is the correct or >> preferred one. > > IIRC I checked around the other serial bindings & there was not a > consistent order that all serial bindings used, so I picked the order that > was used across the various allwinner boards that do use dma-names. Thanks for clarifying this, Conor! Would it be fine to switch to tx->rx order as it requires less changes to fix the inconsistencies? > Before changing dts files, it's probably a good idea to make sure that > the dma-names are not used somewhere outside of Linux. Right, that means we cannot exclude the ABI breakage concern. Not sure how easy would be to actually verify this. Hence I wonder if there is really no chance to allow the flexible order in the binding.. > Cheers, > Conor
On Fri, Mar 17, 2023 at 12:21:41PM +0200, Cristian Ciocaltea via Alsa-devel wrote: > Date: Fri, 17 Mar 2023 12:21:41 +0200 > From: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> > To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Sudeep Holla > <sudeep.holla@arm.com>, Cristian Marussi <cristian.marussi@arm.com>, Rob > Herring <robh+dt@kernel.org>, Krzysztof Kozlowski > <krzysztof.kozlowski+dt@linaro.org>, Greg Kroah-Hartman > <gregkh@linuxfoundation.org>, Liam Girdwood <lgirdwood@gmail.com>, Mark > Brown <broonie@kernel.org>, Nicolas Frattaroli > <frattaroli.nicolas@gmail.com>, Heiko Stuebner <heiko@sntech.de>, Jaroslav > Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>, Paul Walmsley > <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou > <aou@eecs.berkeley.edu>, Daniel Drake <drake@endlessm.com>, Katsuhiro > Suzuki <katsuhiro@katsuster.net> > CC: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, > linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, > alsa-devel@alsa-project.org, linux-rockchip@lists.infradead.org, > linux-riscv@lists.infradead.org, kernel@collabora.com > Subject: Re: [PATCH 02/11] dt-bindings: serial: snps-dw-apb-uart: Relax > dma-names order constraint > Message-ID: <8ae57fe3-56aa-7e50-3eaa-a12a40657baf@collabora.com> > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 > Thunderbird/102.7.2 There is something strange going on with your mails as there are 2 copies in the archives with the 2nd one getting the header twice. It's coming from the alsa-devel list. > > On 3/17/23 10:31, Krzysztof Kozlowski wrote: > > On 15/03/2023 12:47, Cristian Ciocaltea wrote: > > > Commit 370f696e4474 ("dt-bindings: serial: snps-dw-apb-uart: add dma & > > > dma-names properties") documented dma-names property to handle Allwiner > > > D1 dtbs_check warnings, but relies on a strict rx->tx ordering, which is > > > the reverse of what a different board expects: > > > > > > rk3326-odroid-go2.dtb: serial@ff030000: dma-names:0: 'rx' was expected > > > > > > A quick and incomplete check shows the inconsistency is present in many > > > other DT files: > > > > Why not fixing the DTS? The properties should have fixed order. > > I was initially concerned about the risk of a potential ABI breakage, but I > think that's not really a problem since dma-names is not directly accessed > in the driver and DT Kernel API doesn't rely on a particular order. > > If there are no objections, I would switch the order in the binding to > tx->rx, since that's what most of the DTS use, and fix the remaining ones. > > > Best regards, > > Krzysztof > > Thanks, > Cristian
On Fri, Mar 17, 2023 at 07:43:53PM +0200, Cristian Ciocaltea wrote: > On 3/17/23 18:26, Conor Dooley wrote: > > On Fri, Mar 17, 2023 at 04:54:47PM +0100, Krzysztof Kozlowski wrote: > > > On 17/03/2023 11:21, Cristian Ciocaltea wrote: > > > > On 3/17/23 10:31, Krzysztof Kozlowski wrote: > > > > > On 15/03/2023 12:47, Cristian Ciocaltea wrote: > > > > > > Commit 370f696e4474 ("dt-bindings: serial: snps-dw-apb-uart: add dma & > > > > > > dma-names properties") documented dma-names property to handle Allwiner > > > > > > D1 dtbs_check warnings, but relies on a strict rx->tx ordering, which is > > > > > > the reverse of what a different board expects: > > > > > > > > > > > > rk3326-odroid-go2.dtb: serial@ff030000: dma-names:0: 'rx' was expected > > > > > > > > > > > > A quick and incomplete check shows the inconsistency is present in many > > > > > > other DT files: > > > > > > > > > > Why not fixing the DTS? The properties should have fixed order. > > > > > > > > I was initially concerned about the risk of a potential ABI breakage, > > > > but I think that's not really a problem since dma-names is not directly > > > > accessed in the driver and DT Kernel API doesn't rely on a particular order. > > > > > > > > If there are no objections, I would switch the order in the binding to > > > > tx->rx, since that's what most of the DTS use, and fix the remaining ones. > > > > > > Since we added the order recently, I rather assume it is the correct or > > > preferred one. > > > > IIRC I checked around the other serial bindings & there was not a > > consistent order that all serial bindings used, so I picked the order that > > was used across the various allwinner boards that do use dma-names. > > Thanks for clarifying this, Conor! Would it be fine to switch to tx->rx > order as it requires less changes to fix the inconsistencies? > > > Before changing dts files, it's probably a good idea to make sure that > > the dma-names are not used somewhere outside of Linux. > > Right, that means we cannot exclude the ABI breakage concern. Not sure how > easy would be to actually verify this. Hence I wonder if there is really no > chance to allow the flexible order in the binding.. If it changes and someone complains, then yes we'll allow flexible order. Rob
On Mon, Mar 20, 2023 at 10:58:12AM -0500, Rob Herring wrote: > On Fri, Mar 17, 2023 at 12:21:41PM +0200, Cristian Ciocaltea via Alsa-devel wrote: > > dma-names order constraint > > Message-ID: <8ae57fe3-56aa-7e50-3eaa-a12a40657baf@collabora.com> > > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 > > Thunderbird/102.7.2 > There is something strange going on with your mails as there are 2 > copies in the archives with the 2nd one getting the header twice. It's > coming from the alsa-devel list. This is probably caused by alsa-devel, it'll be mailman rewriting bits of the message. There's stuff coming up with other people's mails too.
On 3/20/23 18:01, Rob Herring wrote: > On Fri, Mar 17, 2023 at 07:43:53PM +0200, Cristian Ciocaltea wrote: >> On 3/17/23 18:26, Conor Dooley wrote: >>> On Fri, Mar 17, 2023 at 04:54:47PM +0100, Krzysztof Kozlowski wrote: >>>> On 17/03/2023 11:21, Cristian Ciocaltea wrote: >>>>> On 3/17/23 10:31, Krzysztof Kozlowski wrote: >>>>>> On 15/03/2023 12:47, Cristian Ciocaltea wrote: >>>>>>> Commit 370f696e4474 ("dt-bindings: serial: snps-dw-apb-uart: add dma & >>>>>>> dma-names properties") documented dma-names property to handle Allwiner >>>>>>> D1 dtbs_check warnings, but relies on a strict rx->tx ordering, which is >>>>>>> the reverse of what a different board expects: >>>>>>> >>>>>>> rk3326-odroid-go2.dtb: serial@ff030000: dma-names:0: 'rx' was expected >>>>>>> >>>>>>> A quick and incomplete check shows the inconsistency is present in many >>>>>>> other DT files: >>>>>> >>>>>> Why not fixing the DTS? The properties should have fixed order. >>>>> >>>>> I was initially concerned about the risk of a potential ABI breakage, >>>>> but I think that's not really a problem since dma-names is not directly >>>>> accessed in the driver and DT Kernel API doesn't rely on a particular order. >>>>> >>>>> If there are no objections, I would switch the order in the binding to >>>>> tx->rx, since that's what most of the DTS use, and fix the remaining ones. >>>> >>>> Since we added the order recently, I rather assume it is the correct or >>>> preferred one. >>> >>> IIRC I checked around the other serial bindings & there was not a >>> consistent order that all serial bindings used, so I picked the order that >>> was used across the various allwinner boards that do use dma-names. >> >> Thanks for clarifying this, Conor! Would it be fine to switch to tx->rx >> order as it requires less changes to fix the inconsistencies? >> >>> Before changing dts files, it's probably a good idea to make sure that >>> the dma-names are not used somewhere outside of Linux. >> >> Right, that means we cannot exclude the ABI breakage concern. Not sure how >> easy would be to actually verify this. Hence I wonder if there is really no >> chance to allow the flexible order in the binding.. > > If it changes and someone complains, then yes we'll allow flexible > order. I looked a bit further and it seems the allwiner boards are not really affected as all of them are using the same DMA channel for both rx and tx. So we should be fine by switching to tx->rx order. $ git grep -A10 snps,dw-apb-uart | grep 'sun.*dmas' | sort -u arch/arm/boot/dts/sun6i-a31.dtsi- dmas = <&dma 10>, <&dma 10>; arch/arm/boot/dts/sun6i-a31.dtsi- dmas = <&dma 22>, <&dma 22>; arch/arm/boot/dts/sun6i-a31.dtsi- dmas = <&dma 6>, <&dma 6>; arch/arm/boot/dts/sun6i-a31.dtsi- dmas = <&dma 7>, <&dma 7>; arch/arm/boot/dts/sun6i-a31.dtsi- dmas = <&dma 8>, <&dma 8>; arch/arm/boot/dts/sun6i-a31.dtsi- dmas = <&dma 9>, <&dma 9>; arch/arm/boot/dts/sun8i-a23-a33.dtsi- dmas = <&dma 10>, <&dma 10>; arch/arm/boot/dts/sun8i-a23-a33.dtsi- dmas = <&dma 6>, <&dma 6>; arch/arm/boot/dts/sun8i-a23-a33.dtsi- dmas = <&dma 7>, <&dma 7>; arch/arm/boot/dts/sun8i-a23-a33.dtsi- dmas = <&dma 8>, <&dma 8>; arch/arm/boot/dts/sun8i-a23-a33.dtsi- dmas = <&dma 9>, <&dma 9>; arch/arm/boot/dts/sun8i-v3s.dtsi- dmas = <&dma 6>, <&dma 6>; arch/arm/boot/dts/sun8i-v3s.dtsi- dmas = <&dma 7>, <&dma 7>; arch/arm/boot/dts/sun8i-v3s.dtsi- dmas = <&dma 8>, <&dma 8>; arch/arm/boot/dts/sunxi-h3-h5.dtsi- dmas = <&dma 6>, <&dma 6>; arch/arm/boot/dts/sunxi-h3-h5.dtsi- dmas = <&dma 7>, <&dma 7>; arch/arm/boot/dts/sunxi-h3-h5.dtsi- dmas = <&dma 8>, <&dma 8>; arch/arm/boot/dts/sunxi-h3-h5.dtsi- dmas = <&dma 9>, <&dma 9>; arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi- dmas = <&dma 14>, <&dma 14>; arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi- dmas = <&dma 15>, <&dma 15>; arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi- dmas = <&dma 16>, <&dma 16>; arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi- dmas = <&dma 17>, <&dma 17>; arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi- dmas = <&dma 18>, <&dma 18>; arch/riscv/boot/dts/allwinner/sunxi-d1s-t113.dtsi- dmas = <&dma 19>, <&dma 19>; Thanks, Cristian
diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml index 2becdfab4f15..d374844a61a5 100644 --- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml +++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml @@ -71,9 +71,13 @@ properties: minItems: 2 dma-names: - items: - - const: rx - - const: tx + oneOf: + - items: + - const: tx + - const: rx + - items: + - const: rx + - const: tx snps,uart-16550-compatible: description: reflects the value of UART_16550_COMPATIBLE configuration