(subset) [PATCH v2 0/9] spi: pxa2xx: Drop linux/spi/pxa2xx_spi.h

[Mark Brown]

On Wed, Apr 03, 2024 at 04:41:40PM +0300, Andy Shevchenko wrote:
> 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:

> > > 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?

I don't think we should do this at all, all I see from these changes is
effort in reviewing them - as far as I can tell they are a solution in
search of a problem.  DT has some support for validation of the
formatting of the data supplied by the board and offers the potential
for distributing the board description separately to the kernel.

> > Can you point out what the exact aspect is most significant from C language
> > perspective that we miss after conversion? Type checking? Something else?

You're changing the code from supplying data from the board description
via a simple C structure where the compiler offers at least some
validation and where we can just supply directly usable values to an
abstract data structure that's still encoded in C but has less
validation and requires a bunch of code to parse at runtime.  Platform
data is unsurprisingly a good solution to the problem of supplying
platform data.

> 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).

Perhaps those will motivate a change, as things stand I've not seen what
you're proposing to do here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20240403/7566f35f/attachment.sig>