On 28/03/2023 12:45, Julien Panis wrote:
There is no x in compatible. What is (are) the model name(s)?
On 3/28/23 08:51, Krzysztof Kozlowski wrote:
On 27/03/2023 17:40, Julien Panis wrote:OK, I will remove 'X' from model name in v5.
TPS6594 is a Power Management IC which provides regulators and othersLP8764X? Compatible says LP8764.
features like GPIOs, RTC, watchdog, ESMs (Error Signal Monitor), and
PFSM (Pre-configurable Finite State Machine) managing the state of the
device.
TPS6594 is the super-set device while TPS6593 and LP8764X are derivatives.
Signed-off-by: Julien Panis <jpanis@xxxxxxxxxxxx>
---
.../devicetree/bindings/mfd/ti,tps6594.yaml | 231 ++++++++++++++++++
1 file changed, 231 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/ti,tps6594.yaml
diff --git a/Documentation/devicetree/bindings/mfd/ti,tps6594.yaml b/Documentation/devicetree/bindings/mfd/ti,tps6594.yaml
new file mode 100644
index 000000000000..4498e6361b34
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti,tps6594.yaml
@@ -0,0 +1,231 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ti,tps6594.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI TPS6594 Power Management Integrated Circuit
+
+maintainers:
+ - Julien Panis <jpanis@xxxxxxxxxxxx>
+
+description:
+ TPS6594 is a Power Management IC which provides regulators and others
+ features like GPIOs, RTC, watchdog, ESMs (Error Signal Monitor), and
+ PFSM (Pre-configurable Finite State Machine) managing the state of the device.
+ TPS6594 is the super-set device while TPS6593 and LP8764X are derivatives.
+It's confusing. If x was wildcard, didn't you remove part of model name?
+properties:
+ compatible:
+ enum:
+ - ti,lp8764
(...)
+ - ti,tps6593
+ - ti,tps6594
Specific means not loose, not generic, precise with some accurateIt seems that I can't figure out what you and Rob mean by saying that+I doubt that you can have here any RTC and any watchdog (below). This
+ rtc:
+ type: object
+ description: RTC provided by this controller.
+ $ref: /schemas/rtc/rtc.yaml#
should be specific binding instead. Or list of compatibles if you have 3
or more possible bindings.
Additionally, judging by your DTS you do not have any resources in rtc
and watchdog, so these should not be nodes by themself in such case.
"binding must be complete" and that "RTC and watchdog may or may not
need binding changes".
What does "specific binding" mean ?
properties.
Should we add some specific propertyYou know ask me to know what is in your device. I don't know. You should
for RTC/WDG provided by the PMIC ?
know.
Should we write another yaml for bothDepends. Pretty often yes, but think what do you want to put there?
of them ?
Why shouldn't they use the generic rtc/watchdog yaml ?There are no properties in these nodes, so you do not need nodes. Or if
you have properties then you need specific binding, not generic one.
I don'tgit grep $ref | grep rtc.yaml
understand why they would need some "binding changes". Any example
I could refer to ? (I might have not looked at the relevant ones for my case
before sending this v4)
Best regards,
Krzysztof