ASoC: dt-bindings: wm8753: Convert to dtschema
Subsystems (3)
PATCH 1/1 ASoC: dt-bindings: wm8753: Convert to dtschema
Convert the WM8753 audio codec bindings to DT schema.
--- .../devicetree/bindings/sound/wlf,wm8753.yaml | 62 +++++++++++++++++++ .../devicetree/bindings/sound/wm8753.txt | 40 ------------ 2 files changed, 62 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8753.yaml delete mode 100644 Documentation/devicetree/bindings/sound/wm8753.txt
Documentation/devicetree/bindings/sound/wlf,wm8753.yaml new file +62 -0
@@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8753.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: WM8753 audio CODEC + +description: | + Pins on the device (for linking into audio routes): + * LOUT1 + * LOUT2 + * ROUT1 + * ROUT2 + * MONO1 + * MONO2 + * OUT3 + * OUT4 + * LINE1 + * LINE2 + * RXP + * RXN + * ACIN + * ACOP + * MIC1N + * MIC1 + * MIC2N + * MIC2 + * Mic Bias + +maintainers: + - [email protected] + +allOf: + - $ref: dai-common.yaml# + +properties: + compatible: + const: wlf,wm8753 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + codec@1a { + compatible = "wlf,wm8753"; + reg = <0x1a>; + }; + };
Documentation/devicetree/bindings/sound/wm8753.txt deleted +0 -40
@@ -1,40 +0,0 @@ -WM8753 audio CODEC - -This device supports both I2C and SPI (configured with pin strapping -on the board). - -Required properties: - - - compatible : "wlf,wm8753" - - - reg : the I2C address of the device for I2C, the chip select - number for SPI. - -Pins on the device (for linking into audio routes): - - * LOUT1 - * LOUT2 - * ROUT1 - * ROUT2 - * MONO1 - * MONO2 - * OUT3 - * OUT4 - * LINE1 - * LINE2 - * RXP - * RXN - * ACIN - * ACOP - * MIC1N - * MIC1 - * MIC2N - * MIC2 - * Mic Bias - -Example: - -wm8753: codec@1a { - compatible = "wlf,wm8753"; - reg = <0x1a>; -};
Signature · 1 line
2.40.0
Quoted 6 lines · Saalim Quadri
Convert the WM8753 audio codec bindings to DT schema.
Signed-off-by Saalim Quadri <[email protected]>--- .../devicetree/bindings/sound/wlf,wm8753.yaml | 62 +++++++++++++++++++ .../devicetree/bindings/sound/wm8753.txt | 40 ------------
Guys,
You choose unusual bindings to convert to DT schema. It is fine but honestly, less useful, with limited impact. This is an old, 12 year old binding without users. Maybe it would be even removed by now...
I suggest converting ones which have a real impact - have users in DTS. Otherwise you will be putting quite a lot of effort for no real gains... because what is the difference between this binding being TXT and DT schema?
Quoted 4 lines
2 files changed, 62 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8753.yaml delete mode 100644 Documentation/devicetree/bindings/sound/wm8753.txt
Best regards,
Krzysztof
PATCH 1/1 ASoC: dt-bindings: wm8753: Convert to dtschema
Quoted 6 lines
You choose unusual bindings to convert to DT schema. It is fine but honestly, less useful, with limited impact. This is an old, 12 year old binding without users. Maybe it would be even removed by now... I suggest converting ones which have a real impact - have users in DTS. Otherwise you will be putting quite a lot of effort for no real gains... because what is the difference between this binding being TXT and DT schema?
I am converting these bindings as part of my GSoC project where I need to convert as many files as possible during the given tenure, I am slowly trying to read files in other subsystems too and will push patches for other subsystems too. Is it fine?
About the part where you suggested to convert the txt into a single YAML, shall I continue working on them? As I can see Mark merged the previous 2 patches to linux-next
Kind Regards,
Saalim
Quoted 11 lines · Saalim Quadri
Quoted 6 lines
You choose unusual bindings to convert to DT schema. It is fine but honestly, less useful, with limited impact. This is an old, 12 year old binding without users. Maybe it would be even removed by now... I suggest converting ones which have a real impact - have users in DTS. Otherwise you will be putting quite a lot of effort for no real gains... because what is the difference between this binding being TXT and DT schema?
I am converting these bindings as part of my GSoC project where I need to convert as many files as possible during the given tenure, I am slowly trying to read files in other subsystems too and will push patches for other subsystems too. Is it fine?
In general it is fine. I wonder if we can change the goal of GSoC? I am surprised that such goal was chosen in the first place. Converting old, unused bindings to DT schema is okay, but it would be much better to do this for the bindings which are actually used.
Because I still wonder - what is the difference between this binding being TXT and DT schema?
Quoted 2 lines
About the part where you suggested to convert the txt into a single YAML, shall I
The bindings were incomplete, so after adding missing pieces they could stay probably as separate bindings.
Quoted 1 line
continue working on them? As I can see Mark merged the previous 2 patches to linux-next
Best regards,
Krzysztof
Quoted 13 lines · Krzysztof Kozlowski
Quoted 11 lines · Saalim Quadri
Quoted 6 lines
You choose unusual bindings to convert to DT schema. It is fine but honestly, less useful, with limited impact. This is an old, 12 year old binding without users. Maybe it would be even removed by now... I suggest converting ones which have a real impact - have users in DTS. Otherwise you will be putting quite a lot of effort for no real gains... because what is the difference between this binding being TXT and DT schema?
I am converting these bindings as part of my GSoC project where I need to convert as many files as possible during the given tenure, I am slowly trying to read files in other subsystems too and will push patches for other subsystems too. Is it fine?
Quoted 7 lines
In general it is fine. I wonder if we can change the goal of GSoC? I am surprised that such goal was chosen in the first place. Converting old, unused bindings to DT schema is okay, but it would be much better to do this for the bindings which are actually used.
Because I still wonder - what is the difference between this binding being TXT and DT schema?
BTW,
If you want to find used bindings and tasks to do, check Rob's bot output:
https://gitlab.com/robherring/linux-dt/-/jobs/4118960859
https://gitlab.com/robherring/linux-dt/-/jobs/4118960858
I pointed to these jobs two months ago when Daniel was looking for some feedback.
Best regards,
Krzysztof
PATCH 1/1 ASoC: dt-bindings: wm8753: Convert to dtschema
Thank you for that, I will take a look and soon push the patches for bindings that are actually being used.
Kind Regards,
Saalim
Quoted 4 lines · Saalim Quadri
Convert the WM8753 audio codec bindings to DT schema.
Signed-off-by Saalim Quadri <[email protected]>---
Thanks,
Charles
Quoted 4 lines · Saalim Quadri
Convert the WM8753 audio codec bindings to DT schema.
Signed-off-by Saalim Quadri <[email protected]>---
Thanks,
Charles
Mark Brown
maintainerQuoted 3 lines · Saalim Quadri
Convert the WM8753 audio codec bindings to DT schema.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: dt-bindings: wm8753: Convert to dtschema
commit: 59de6c38d713bb16760cc2612a79bc373f79bc6b
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