[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220114231657.AB353C36AE7@smtp.kernel.org>
Date: Fri, 14 Jan 2022 15:16:55 -0800
From: Stephen Boyd <sboyd@...nel.org>
To: Pali Rohár <pali@...nel.org>
Cc: Gregory CLEMENT <gregory.clement@...tlin.com>,
Michael Turquette <mturquette@...libre.com>,
Rob Herring <robh+dt@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andrew Lunn <andrew@...n.ch>,
Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
Vladimir Vid <vladimir.vid@...tura.hr>,
Marek Behún <kabel@...nel.org>,
linux-clk@...r.kernel.org, linux-serial@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH v7 0/6] serial: mvebu-uart: Support for higher baudrates
Quoting Pali Rohár (2022-01-14 15:05:49)
> On Friday 14 January 2022 14:56:58 Stephen Boyd wrote:
> >
> > If we're adding new support why can't we break with backwards
> > compatibility for the binding and do it a different way?
>
> Because DTS are backwards compatible. I was told more times that kernel
> drivers should work correctly with older DTS files. On some boards are
> DTB files provided by bootloader and they do not use in-kernel DTS
> files.
I'm not suggesting to break the kernel driver when used with older DTBs.
New features are fair game to change the compatible string and do
something different. If the user wants the new feature they update their
DTB. We shouldn't be constrained by backwards compatibility here.
Powered by blists - more mailing lists