[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zg1clCuOwkCNzSgy@smile.fi.intel.com>
Date: Wed, 3 Apr 2024 16:41:40 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Mark Brown <broonie@...nel.org>
Cc: linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
Daniel Mack <daniel@...que.org>,
Haojian Zhuang <haojian.zhuang@...il.com>,
Robert Jarzmik <robert.jarzmik@...e.fr>,
Russell King <linux@...linux.org.uk>, Arnd Bergmann <arnd@...db.de>
Subject: Re: (subset) [PATCH v2 0/9] spi: pxa2xx: Drop linux/spi/pxa2xx_spi.h
On Wed, Apr 03, 2024 at 04:39:13PM +0300, Andy Shevchenko wrote:
> On Wed, Apr 03, 2024 at 02:29:38PM +0100, Mark Brown wrote:
> > On Wed, Apr 03, 2024 at 02:07:29PM +0300, Andy Shevchenko wrote:
> >
> > > Do I need to do anything else to get the rest applied?
> >
> > All the concerns I have with swnodes just being a more complex and less
> > maintainable way of doing things still stand, I'm not clear that this is
> > making anything better.
>
> As I explained before it's not less maintainable than device tree sources.
> The only difference is that we don't have validation tool for in-kernel
> tables. And I don't see why we need that. The data describes the platforms
> and in the very same way may come to the driver from elsewhere.
> How would you validate that? It the same as we trust firmware (boot loader)
> or not. If we don't than how should we do at all?
>
> Can you point out what the exact aspect is most significant from C language
> perspective that we miss after conversion? Type checking? Something else?
Also note, after hiding the data structures from that file we open
the door for the much bigger cleanup, and I have patches already precooked
(need a bit of time to test, though).
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists