From: Marc Zyngier <maz@kernel.org>
To: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Rob Herring <robh+dt@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>, Nishanth Menon <nm@ti.com>,
Tero Kristo <t-kristo@ti.com>,
Santosh Shilimkar <ssantosh@kernel.org>,
Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>,
Sekhar Nori <nsekhar@ti.com>,
Grygorii Strashko <grygorii.strashko@ti.com>,
Peter Ujfalusi <peter.ujfalusi@ti.com>,
Device Tree Mailing List <devicetree@vger.kernel.org>,
Suman Anna <s-anna@ti.com>
Subject: Re: [PATCH v3 6/9] irqchip/ti-sci-intr: Add support for INTR being a parent to INTR
Date: Sat, 25 Jul 2020 15:42:44 +0100 [thread overview]
Message-ID: <71b33062f87f66e8c865b9e80b36585c@kernel.org> (raw)
In-Reply-To: <e19a84ff-d990-d87a-1df0-fd5b10654e3a@ti.com>
On 2020-07-25 15:37, Lokesh Vutla wrote:
> On 25/07/20 7:36 pm, Marc Zyngier wrote:
>> On Fri, 24 Jul 2020 15:18:34 +0100,
>> Lokesh Vutla <lokeshvutla@ti.com> wrote:
>>>
>>> Driver assumes that Interrupt parent to Interrupt router is always
>>> GIC.
>>> This is not true always and an Interrupt Router can be a parent to
>>> Interrupt Router. Update the driver to detect the parent and request
>>> the
>>> parent irqs accordingly.
>>>
>>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>>> ---
>>> drivers/irqchip/irq-ti-sci-intr.c | 150
>>> ++++++++++++++++++------------
>>> 1 file changed, 91 insertions(+), 59 deletions(-)
>>>
>>> diff --git a/drivers/irqchip/irq-ti-sci-intr.c
>>> b/drivers/irqchip/irq-ti-sci-intr.c
>>> index 59d51a20bbd8..0b73816e77fc 100644
>>> --- a/drivers/irqchip/irq-ti-sci-intr.c
>>> +++ b/drivers/irqchip/irq-ti-sci-intr.c
[...]
>>> - ret = of_property_read_u32(dev_of_node(dev), "ti,sci-dst-id",
>>> - &intr->dst_id);
>>> + ret = of_property_read_u32(dev_of_node(dev), "ti,sci-dev-id",
>>> + &pdev->id);
>>
>> This feels very dodgy. You are hijacking a random field in the
>> platform device data structure, which shouldn't be any of your
>
> pdev->id is pretty much unused field today. I was kind of hoping that
> in future
> it can be utilized to populated field with TISCI device IDs in some
> generic
> manner. So thought of using it now.
It isn't unused. DT doesn't make active use of it for now, not that's
not
something you can rely on.
>> business. What was wrong with having a separate field for something
>> that is obviously platform specific?
>
> No reason. I could just add a new filed in the intr structure.
Please do.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2020-07-25 14:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-24 14:18 [PATCH v3 0/9] irqchip: ti, sci-intr/inta: Update the dt bindings to accept different interrupt parents Lokesh Vutla
2020-07-24 14:18 ` [PATCH v3 1/9] firmware: ti_sci: Drop the device id to resource type translation Lokesh Vutla
2020-07-24 14:18 ` [PATCH v3 2/9] firmware: ti_sci: Drop unused structure ti_sci_rm_type_map Lokesh Vutla
2020-07-24 14:18 ` [PATCH v3 3/9] firmware: ti_sci: Add support for getting resource with subtype Lokesh Vutla
2020-07-24 14:18 ` [PATCH v3 4/9] dt-bindings: irqchip: ti,sci-intr: Update bindings to drop the usage of gic as parent Lokesh Vutla
2020-07-24 14:18 ` [PATCH v3 5/9] dt-bindings: irqchip: Convert ti,sci-intr bindings to yaml Lokesh Vutla
2020-07-24 14:18 ` [PATCH v3 6/9] irqchip/ti-sci-intr: Add support for INTR being a parent to INTR Lokesh Vutla
2020-07-25 14:06 ` Marc Zyngier
2020-07-25 14:37 ` Lokesh Vutla
2020-07-25 14:42 ` Marc Zyngier [this message]
2020-07-24 14:18 ` [PATCH v3 7/9] dt-bindings: irqchip: ti,sci-inta: Update docs to support different parent Lokesh Vutla
2020-07-24 14:18 ` [PATCH v3 8/9] dt-bindings: irqchip: Convert ti,sci-inta bindings to yaml Lokesh Vutla
2020-07-24 14:18 ` [PATCH v3 9/9] irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC Lokesh Vutla
2020-07-25 14:10 ` Marc Zyngier
2020-07-25 14:12 ` [PATCH v3 0/9] irqchip: ti, sci-intr/inta: Update the dt bindings to accept different interrupt parents Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=71b33062f87f66e8c865b9e80b36585c@kernel.org \
--to=maz@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=grygorii.strashko@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=lokeshvutla@ti.com \
--cc=nm@ti.com \
--cc=nsekhar@ti.com \
--cc=peter.ujfalusi@ti.com \
--cc=robh+dt@kernel.org \
--cc=s-anna@ti.com \
--cc=ssantosh@kernel.org \
--cc=t-kristo@ti.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).