[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f801a4cb-3d27-439c-82f2-d5ee5aa0d810@lunn.ch>
Date: Tue, 14 Oct 2025 17:11:22 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Tao Ren <rentao.bupt@...il.com>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Joel Stanley <joel@....id.au>,
Andrew Jeffery <andrew@...econstruct.com.au>,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-aspeed@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
Tao Ren <taoren@...a.com>
Subject: Re: [PATCH v4 11/13] ARM: dts: aspeed: facebook-fuji: Include
facebook-fuji-data64.dts
> > If it is already in mainline, i don't care too much if it is wrong. We
> > don't want to cause regressions.
> >
> > I only object when adding new nodes which are wrong. If we keep adding
> > broken nodes, there is no incentive to fix the broken driver to do the
>
> This wasn't adding an allegedly (sorry, it worked for me) broken node,
> it was removing one that worked for me all along. Obviously I do not know
> if it worked (or if it is even used) on real hardware, but it worked for
> the fuji-bmc qemu emulation.
It probably does work on real hardware, because it is one of those
"two wrongs makes a right" cases. So i see this as a regression. The
node should not be removed. It should hopefully get corrected sometime
in the future when somebody actually fixes the aspeed driver, and
fixes both wrongs.
Andrew
Powered by blists - more mailing lists