Received-SPF: pass (google.com: domain of linux-kernel+bounces-129863-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Wed, 3 Apr 2024 16:41:40 +0300
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Daniel Mack <daniel@zonque.org>,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	Robert Jarzmik <robert.jarzmik@free.fr>,
	Russell King <linux@armlinux.org.uk>, Arnd Bergmann <arnd@arndb.de>
Subject: Re: (subset) [PATCH v2 0/9] spi: pxa2xx: Drop linux/spi/pxa2xx_spi.h
Message-ID: <Zg1clCuOwkCNzSgy@smile.fi.intel.com>
References: <20240327193138.2385910-1-andriy.shevchenko@linux.intel.com>
 <171167575036.187521.17547262230962160149.b4-ty@kernel.org>
 <Zg04cWhT_Dl6AUik@smile.fi.intel.com>
 <b7ac20d0-ca45-4e65-92ff-ddf84da6645a@sirena.org.uk>
 <Zg1cAHEkhIf2vpwJ@smile.fi.intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Zg1cAHEkhIf2vpwJ@smile.fi.intel.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

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