On 4/10/24 13:03, Conor Dooley wrote:
On Wed, Apr 10, 2024 at 10:57:08AM +0300, Matti Vaittinen wrote:
On 4/4/24 22:54, Andreas Kemnade wrote:
As this chip was seen in several devices in the wild, add it.
Signed-off-by: Andreas Kemnade <andreas@xxxxxxxxxxxx>
Suggested-by: Matti Vaittinen <mazziesaccount@xxxxxxxxx>
---
.../devicetree/bindings/mfd/rohm,bd71828-pmic.yaml | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
index 0b62f854bf6b..07f99738fcf6 100644
--- a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
@@ -17,7 +17,12 @@ description: |
properties:
compatible:
- const: rohm,bd71828
+ oneOf:
+ - const: rohm,bd71828
+
+ - items:
+ - const: rohm,bd71879
+ - const: rohm,bd71828
reg:
description:
Am I correct, this reads as:
Either
compatible = rohm,bd71828
or
compatible = rohm,bd71879, rohm,bd71828
but not compatible = rohm,bd71879?
Correct.
Thanks Conor!
I guess that if we later find out that there is a 'gizmo' in BD71828
which is not present on BD71879 - and if we write driver supporting
this, then we need to have handling for both the BD71879 and BD71828 in
this driver to ensure the fall-back wont happen. It's a bit ugly as I
think the fall-back compatible should be used only in case where the
"fall-back" HW can be guaranteed to have exactly same, or a subset of,
features of the "full board".
Well, I've been told these are similar by HW colleagues. I have my
doubts if 'similar' really is '_similar_', or if it's 'similar, except
of course...' - but let's trust the HW guys on this. We have the above
mentioned workaround if we should not have trusted...
Acked-By: Matti Vaittinen <mazziesaccount@xxxxxxxxx>
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
