[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210908112703.GC23326@home.paul.comp>
Date: Wed, 8 Sep 2021 14:27:04 +0300
From: Paul Fertser <fercerpav@...il.com>
To: ChiaWei Wang <chiawei_wang@...eedtech.com>
Cc: "robh+dt@...nel.org" <robh+dt@...nel.org>,
"joel@....id.au" <joel@....id.au>,
"andrew@...id.au" <andrew@...id.au>,
"lee.jones@...aro.org" <lee.jones@...aro.org>,
"osk@...gle.com" <osk@...gle.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"openbmc@...ts.ozlabs.org" <openbmc@...ts.ozlabs.org>,
Konstantin Klubnichkin <kitsok@...dex-team.ru>
Subject: Re: VUART compatibility (was: Re: [PATCH v2 0/3] arm: aspeed: Add
UART routing support)
On Wed, Sep 08, 2021 at 01:52:45PM +0300, Paul Fertser wrote:
> In this case do we have some way to make it an obvious error to enable
> both SUART1 and VUART in DTS? If they're conflicting surely there
> should be a way to express that?
I have to add this idea is obviously silly as we have sysfs nodes to
specify both LPC I/O address and interrupt number for VUART and
arbitrary numbers are allowed (so it can conflict with any of the
SUART port) so there should be probably some runtime checking in VUART
driver to prevent that?
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@...il.com
Powered by blists - more mailing lists