[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <163415390922.936959.12352892206436080955@swboyd.mtv.corp.google.com>
Date: Wed, 13 Oct 2021 12:38:29 -0700
From: Stephen Boyd <sboyd@...nel.org>
To: Fenglin Wu <quic_fenglinw@...cinc.com>,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: collinsd@...eaurora.org, subbaram@...eaurora.org
Subject: Re: [RESEND PATCH v1 8/9] spmi: pmic-arb: make interrupt support optional
Quoting Fenglin Wu (2021-10-13 01:36:54)
>
> On 10/13/2021 1:41 AM, Stephen Boyd wrote:
> > Quoting Fenglin Wu (2021-09-16 23:33:03)
> >> From: David Collins <collinsd@...eaurora.org>
> >>
> >> Make the support of PMIC peripheral interrupts optional for
> >> spmi-pmic-arb devices. This is useful in situations where
> >> SPMI address mapping is required without the need for IRQ
> >> support.
> >>
> >> Signed-off-by: David Collins <collinsd@...eaurora.org>
> >> Signed-off-by: Fenglin Wu <quic_fenglinw@...cinc.com>
> >> ---
> >> drivers/spmi/spmi-pmic-arb.c | 45 +++++++++++++++++++++++++++-----------------
> > Is there a binding update? Can the binding be converted to YAML as well?
> This change doesn't add/update any dtsi properties but just checking if an
> existing property is present to decide if IRQ support is required, so no
> binding change is needed.
The property is now optional in the binding. Please update the binding.
> >
> >> 1 file changed, 28 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/drivers/spmi/spmi-pmic-arb.c b/drivers/spmi/spmi-pmic-arb.c
> >> index 988204c..55fa981 100644
> >> --- a/drivers/spmi/spmi-pmic-arb.c
> >> +++ b/drivers/spmi/spmi-pmic-arb.c
> >> @@ -1280,10 +1280,12 @@ static int spmi_pmic_arb_probe(struct platform_device *pdev)
> >> goto err_put_ctrl;
> >> }
> >>
> >> - pmic_arb->irq = platform_get_irq_byname(pdev, "periph_irq");
> >> - if (pmic_arb->irq < 0) {
> >> - err = pmic_arb->irq;
> >> - goto err_put_ctrl;
> >> + if (of_find_property(pdev->dev.of_node, "interrupt-names", NULL)) {
> > I don't think we should be keying off of interrupt-names. Instead we
> > should be checking for something else. Maybe interrupt-controller
> > property?
> Sure, I can update it to check the presence of "interrupt-controller"
> property.
Ok.
Powered by blists - more mailing lists