[PATCH 1/2] ASoC: dt-bindings: everest,es8328: Mark ES8388 compatible with ES8328

[PATCH 1/2] ASoC: dt-bindings: everest,es8328: Mark ES8388 compatible with ES8328

[Krzysztof Kozlowski]

Based on Linux driver, the ES8388 looks fully compatible with ES8328.
One upstream DTS (ARM rk3288-rock2-square.dts) already uses ES8328
fallback, so mark the devices as compatible in the binding.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

---

ARM64 Rockchip DTS use only single everest,es8388 compatible, so this
will trigger dtbs_check warnings which I will fix in separate patchset.

No ABI break/impact expected.

Expected dtbs_check warnings:

arm64/boot/dts/rockchip/rk3399-roc-pc-plus.dtb: es8388@11: compatible: 'oneOf' conditional failed, one must be fixed:
  ['everest,es8388'] is too short
  'everest,es8388' is not one of ['everest,es8328']
  from schema $id: http://devicetree.org/schemas/sound/everest,es8328.yaml#
---
 .../devicetree/bindings/sound/everest,es8328.yaml      | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/everest,es8328.yaml b/Documentation/devicetree/bindings/sound/everest,es8328.yaml
index ed18e40dcaac..309c4d01db76 100644
--- a/Documentation/devicetree/bindings/sound/everest,es8328.yaml
+++ b/Documentation/devicetree/bindings/sound/everest,es8328.yaml
@@ -24,9 +24,13 @@ maintainers:
 
 properties:
   compatible:
-    enum:
-      - everest,es8328
-      - everest,es8388
+    oneOf:
+      - enum:
+          - everest,es8328
+      - items:
+          - enum:
+              - everest,es8388
+          - const: everest,es8328
 
   reg:
     maxItems: 1
-- 
2.43.0

[PATCH 2/2] ASoC: dt-bindings: everest,es8328: Require reg property

[Krzysztof Kozlowski]

ES8328 and ES8388 codecs are I2C or SPI devices, thus they are
addressable on their bus and 'reg' property should be always provided.
Requiring 'reg' is pretty close to redundant, because the I2C and SPI
controller/bus bindings require it already, but the convention is to
mention 'reg' also in the device schemas.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
 Documentation/devicetree/bindings/sound/everest,es8328.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/sound/everest,es8328.yaml b/Documentation/devicetree/bindings/sound/everest,es8328.yaml
index 309c4d01db76..ddddd7b143ab 100644
--- a/Documentation/devicetree/bindings/sound/everest,es8328.yaml
+++ b/Documentation/devicetree/bindings/sound/everest,es8328.yaml
@@ -60,6 +60,7 @@ properties:
 
 required:
   - compatible
+  - reg
   - clocks
   - DVDD-supply
   - AVDD-supply
-- 
2.43.0

Re: [PATCH 1/2] ASoC: dt-bindings: everest,es8328: Mark ES8388 compatible with ES8328

[Mark Brown]

On Tue, 04 Mar 2025 11:38:07 +0100, Krzysztof Kozlowski wrote:
> Based on Linux driver, the ES8388 looks fully compatible with ES8328.
> One upstream DTS (ARM rk3288-rock2-square.dts) already uses ES8328
> fallback, so mark the devices as compatible in the binding.
> 
> 

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/2] ASoC: dt-bindings: everest,es8328: Mark ES8388 compatible with ES8328
      commit: 1d251a7adc5b720a71641c758a45b8a119971d80
[2/2] ASoC: dt-bindings: everest,es8328: Require reg property
      commit: 8243a49145e59f19032b86b20d8906f05e31bdcc

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark