[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZcJfxRgysxLWAOIH@finisterre.sirena.org.uk>
Date: Tue, 6 Feb 2024 16:35:17 +0000
From: Mark Brown <broonie@...nel.org>
To: Matthias Kaehlcke <mka@...omium.org>
Cc: Javier Carrasco <javier.carrasco@...fvision.net>,
Liam Girdwood <lgirdwood@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-sound@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH v3 6/7] ASoC: dt-bindings: xmos,xvf3500: add XMOS XVF3500
voice processor
On Tue, Feb 06, 2024 at 03:49:35PM +0000, Matthias Kaehlcke wrote:
> Initially the driver targeted a device with a single supply, the name
> 'vdd' was kept generic since it was expected that other devices would be
> supported (except for a couple of minor bits the driver is not device
> specific). Later support for a device with two supplies was added, with
> the generic name 'vdd2' to support other devices with multiple regulators.
It's generally always going to be a problem to add generic names that
don't reflect the actual hardware names, you still end up needing to
define the mapping from the real names to the generic names that have
been define when you end up with the regulators being controllable.
> Using the correct naming would be doable, with the caveat that the old
> naming still needs to be supported for backwards compatibility.
Yes, the existing bindings need to be supported as a legacy/fallback
thing.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists