Re: [PATCH v4 1/4] mfd: wm831x: Support software nodes for DCDC regulators

[Charles Keepax]

On Thu, Nov 05, 2026 at 06:24:48PM +0100, Arnd Bergmann wrote:
> On Thu, Nov 5, 2026, at 18:12, Dmitry Torokhov wrote:
> > On Thu, Nov 05, 2026 at 02:43:17PM +0100, Arnd Bergmann wrote:
> >> 
> >> As far as I understand the situation, wm831x was used on the
> >> reference board (Samsung smdk6410, removed in 2019) in addition
> >> to crag6410 but never anywhere else upstream. The question
> >> then is whether we'll ever see a DT conversion of crag6410.
> >> This would require finding someone willing to actually do
> >> the work, and coming up with a way to handle the autodetection
> >> in mach-crag6410-module.c so the correct spi/i2c codec
> >> child devices are probed.
> >
> > So I guess the question then: do we need to keep this board at all? Or
> > it is time for it to go the way of the dodo? And then we could drop some
> > more drivers as well.
> >
> > My goal for the series was to move along legacy gpio API conversions, as
> > well as move away from the GPIO lookup tables (ideally I want them gone
> > now that we have software nodes supporting describing GPIOs).
> 
> Mark Brown is using the board for testing eight Cirrus/Wolfson
> audio codecs:
> 
>  - arizona and wm8994 have actual users with DT, but this is
>    the board he has for testing with platform_data

Yeah both of these series of parts sold into a lot of systems.

>  - wm0010, wm1250-ev1, wm5100, wm8996 and wm9081 have no other
>    upstream users besides this board and no DT support, so arguably
>    these are probably obsolete and could also be removed.

Personally, I am not super fussed about testing for any of these
parts most of them didn't sell loads and they are quite old.

> I assume Charles can comment on how important the testing still
> is for the codec above, or if there is other hardware that could
> be used for testing the arizona and wm8994 drivers in case the
> other ones are in fact as obsolete as they appear.

Without wanting to put words into Mark's mouth (please do shout
at me if I am off course here), I assume his use of Cragganmore
is less about testing specific parts and more about it being a
very flexible complex audio system with good debug, allowing
testing parts of the core frameworks that would be hard to hit
with off the shelf hardware.

Thanks,
Charles