On Mon, Apr 20, 2020 at 08:19:10AM +0100, Lee Jones wrote: > On Sat, 18 Apr 2020, Jonathan Cameron wrote: > > > On Sat, 18 Apr 2020 17:01:17 +0200 > > saravanan sekar <sravanhome@xxxxxxxxx> wrote: > > > > > Hi Jonathan, > > > > > > On 18/04/20 4:53 pm, Jonathan Cameron wrote: > > > > On Fri, 17 Apr 2020 10:49:58 +0200 > > > > Saravanan Sekar <sravanhome@xxxxxxxxx> wrote: > > > > > > > >> Add device tree binding information for mp2629 mfd driver. > > > >> > > > >> Signed-off-by: Saravanan Sekar <sravanhome@xxxxxxxxx> > > > >> Reviewed-by: Andy Shevchenko <andy.shevchenko@xxxxxxxxx> > > > >> --- > > > >> .../devicetree/bindings/mfd/mps,mp2629.yaml | 61 +++++++++++++++++++ > > > >> 1 file changed, 61 insertions(+) > > > >> create mode 100644 Documentation/devicetree/bindings/mfd/mps,mp2629.yaml > > > >> > > > >> diff --git a/Documentation/devicetree/bindings/mfd/mps,mp2629.yaml b/Documentation/devicetree/bindings/mfd/mps,mp2629.yaml > > > >> new file mode 100644 > > > >> index 000000000000..b25b29259d67 > > > >> --- /dev/null > > > >> +++ b/Documentation/devicetree/bindings/mfd/mps,mp2629.yaml > > > >> @@ -0,0 +1,61 @@ > > > >> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > > >> +%YAML 1.2 > > > >> +--- > > > >> +$id: http://devicetree.org/schemas/mfd/mps,mp2629.yaml# > > > >> +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > >> + > > > >> +title: MP2629 Battery Charger PMIC from Monolithic Power System. > > > >> + > > > >> +maintainers: > > > >> + - Saravanan Sekar <sravanhome@xxxxxxxxx> > > > >> + > > > >> +description: | > > > >> + MP2629 is a PMIC providing battery charging and power supply for smartphones, > > > >> + wireless camera and portable devices. Chip is controlled over I2C. > > > >> + > > > >> + The battery charge management device handles battery charger controller and > > > >> + ADC IIO device for battery, system voltage > > > >> + > > > >> +properties: > > > >> + compatible: > > > >> + const: mps,mp2629 > > > >> + > > > >> + reg: > > > >> + maxItems: 1 > > > >> + > > > >> + interrupts: > > > >> + maxItems: 1 > > > >> + > > > >> + interrupt-controller: true > > > >> + > > > >> + "#interrupt-cells": > > > >> + const: 2 > > > >> + description: > > > >> + The first cell is the IRQ number, the second cell is the trigger type. > > > >> + > > > >> +required: > > > >> + - compatible > > > >> + - reg > > > >> + - interrupts > > > >> + - interrupt-controller > > > >> + - "#interrupt-cells" > > > >> + > > > >> +examples: > > > >> + - | > > > >> + #include <dt-bindings/interrupt-controller/irq.h> > > > >> + #include <dt-bindings/input/linux-event-codes.h> > > > >> + i2c@7e205000 { > > > > I thought the general trend for i2c devices was to leave the i2c > > > > part 'vague'. > > > > > > > > i2c { > > > > #address-cells = <1>; > > > > #size-cells = <0>; > > > > > > > > pmic@4b.. etc > > > I agree with you and initial patch was as like above, but Lee was > > > somehow unhappy and not satisfied with Jonathan is correct. > > > > > > my explanations. Please find more info on v4. > > > > Ah. Curious. Oh well - over to Rob for a definitive answer! > > I haven't seen this spoken about before. The comments were based > solely on my own views of, the example should provide a solid, valid, > potentially working block for people to use as a reference. I agree that the part matching this schema should be. The rest is just boilerplate. > Would an I2C node missing an address be a valid DTS/DTSI entry? i2c-gpio? Rob
