Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <1660225318-4063-1-git-send-email-u0084500@gmail.com>
 <1660225318-4063-2-git-send-email-u0084500@gmail.com> <3cae9d60-4012-1dfd-abd9-4d0b9379e6bb@linaro.org>
 <CADiBU3_depGDZtiyizU3MB939A3oH1uTWzTMyruUy0z=u6BZkQ@mail.gmail.com>
 <40261b95-637a-1304-2e06-8c8ff7fc377b@linaro.org> <CADiBU38+9sR1r20=YWt-9s2+u7maHH+1VudCnV1-0+F4jYKdQQ@mail.gmail.com>
 <CADiBU3_Jt6n6tm=oVvjk5vsoEAneH7t-37S6skepA6v6bVVYUw@mail.gmail.com> <f2a664be-71e9-7a26-2f0c-5f654d9cb3cb@linaro.org>
In-Reply-To: <f2a664be-71e9-7a26-2f0c-5f654d9cb3cb@linaro.org>
From:   ChiYuan Huang <u0084500@gmail.com>
Date:   Sat, 13 Aug 2022 22:52:29 +0800
Message-ID: <CADiBU3-bKGhW2Yy13svNUykqW+WN3VS6LftWMU0rMeCc+fMySg@mail.gmail.com>
Subject: Re: [PATCH 1/2] dt-bindings: power: supply: Add Richtek RT9471
 battery charger
To:     Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc:     Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Sebastian Reichel <sre@kernel.org>,
        =?UTF-8?B?5ri45a2Q6aao?= <alina_yu@richtek.com>,
        cy_huang <cy_huang@richtek.com>, alinayu829@gmail.com,
        Linux PM <linux-pm@vger.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>, lkml <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> =E6=96=BC 2022=E5=B9=
=B48=E6=9C=8813=E6=97=A5 =E9=80=B1=E5=85=AD =E5=87=8C=E6=99=A82:53=E5=AF=AB=
=E9=81=93=EF=BC=9A
>
> On 12/08/2022 19:05, ChiYuan Huang wrote:
> >> It's the same usage like as TI charger.
> >>>>
> >>>> For charger driver, does it mean legacy IRQ handler is more preferre=
d?
> >>>
> >>> Who is the consumer of these interrupts? Can you show the DTS with th=
e
> >>> interrupt consumer?
> >>>
> > Sorry, I forget to reply this question.
> > Some battery driver may need to know the 'full', 'recharge' , 'ieoc' st=
atus.
> > The usage will  be like as below
> >
> > battery {
> >   interrupts-extended =3D <&rt9471_chg 2 0>, <&rt9471_chg 3 0>, &(rt947=
1_chg 5 0>;
> >   interrupt-names =3D "chg-done", "chg-recharge", "chg-ieoc";
> > };
> >
> > Some gauge HW needs this information to enhance the battery capacity ac=
curacy.
>
> Other supply stack pieces do it via supplies (supplied to/from in
> include/linux/power_supply.h) and reporting power_supply_changed().
>
> With such explanation, your device is an interrupt source, but it is not
> an interrupt controller. If your device is interrupt controller, it
> means someone routes the interrupt line to your device. Physical line.
>
Yap, sure. And so on, just use the SW power supply chain to do this
kind of event notification.
To remove it, it doesn't affect the internal interrupt request inside
the driver.
Just cannot be used for the outer driver to request the events directly.

If so, I think 'interrupt-controller' and even '#interrupt-cells' need
to be removed.
OK?
> Best regards,
> Krzysztof