From: Masahiro Yamada <yamada.masahiro@socionext.com>
To: David Daney <ddaney@caviumnetworks.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Walleij <linus.walleij@linaro.org>,
linux-gpio@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
Jassi Brar <jaswinder.singh@linaro.org>,
devicetree@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>,
Masami Hiramatsu <mhiramat@kernel.org>,
David Daney <david.daney@cavium.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 1/6] irqdomain: rename variables in irq_domain_{push,pop}_irq()
Date: Sat, 9 Sep 2017 00:05:49 +0900 [thread overview]
Message-ID: <CAK7LNARboWo4-zkioMAxtpM84f9avtL8Z4z_s0cU5UHXkGotPg@mail.gmail.com> (raw)
In-Reply-To: <c9fd0412-6dce-95e9-4ca3-d4d61f9feeca@caviumnetworks.com>
Hi Marc, David,
2017-09-08 2:45 GMT+09:00 David Daney <ddaney@caviumnetworks.com>:
> On 09/07/2017 05:47 AM, Marc Zyngier wrote:
>>
>> On 07/09/17 12:41, Masahiro Yamada wrote:
>>>
>>> The meaning of "root" in irq_domain_{push,pop} is opposite to the
>>> documentation. Documentation/IRQ-domain.txt depicts the hierarchy
>>> IRQ domain as follows:
>>>
>>> CPU Vector irq_domain (root irq_domain to manage CPU vectors)
>>> ^
>>> |
>>> Interrupt Remapping irq_domain (manage irq_remapping entries)
>>> ^
>>> |
>>> IOAPIC irq_domain (manage IOAPIC delivery entries/pins)
>>>
>>> From above, the inner-most domain (nearest to the CPU) is "root".
>>>
>>> The document also says, "When building irq_domain hierarchy, the
>>> irq_domain near to the device is child and the irq_domain near to
>>> CPU is parent." This is how irq_data->parent_data works. In
>>> contrast, these function use a variable "child_irq_data" for that.
>>
>> The exact opposite argument could be used for the data structure. The
>> irq_desc is the root of the list ordered with parent_data.
>>
>> Yes, this is confusing, but because we're using the same English words
>> to describe two different things, we're bound to make one thing more
>> difficult. I'm unconvinced that this change helps anything (it certainly
>> confuses me more than anything else).
>>
>
> There may be room for improvement here.
>
> Here is my recollection of how I choose the names:
>
> "root" is the thing embedded in the struct irq_desc, if you think about a
> typical linked list structure like this, we can refer to the starting point
> as the "root". Sometimes it might be referred to as the "head" of the list,
> but usually not the "tail"
>
> "child" was used to indicate the thing we get to by traversing the link in
> the list. The fact that ->parent is the name of the next pointer and that
> it points to something called "child" is confusing here.
> So what do I think should be done? This:
>
> Either
> A) s/child_irq_data/parent_irq_data/g As this patch does, but leave the
> root_irq_data name unchanged.
Sounds better than the current situation.
> B) Change the name of the ->parent in struct irq_data to ->next
This is a bad idea.
irq_data->parent_data corresponds to irq_domain->parent.
We should not lose consistency/symmetry.
irq_domain->parent originates in the "parent" argument
passed to irq_domain_create_hierarchy().
If we change this, it will introduce horrible confusion.
As the document says, when we talk about the hierarchy,
"the irq_domain near to the device is
child and the irq_domain near to CPU is parent"
This is the original concept, and should not be changed.
We can excuse that all the variables in these two helpers
were named from the point of linked-list view,
not talking about the hierarchy.
However, what I thought more confusing was the comment block.
/**
* irq_domain_push_irq() - Push a domain in to the top of a hierarchy.
This comment is talking about the "hierarchy" at first glance.
So, what is my mind is the picture in Documentation/IRQ-domain.txt
But, from the term "top", this is talking about the linked list here too.
The linked list is just implementation detail...
> But that is just my $0.02
>
> I fear we risk a Bike Shedding type of discussion here.
--
Best Regards
Masahiro Yamada
next prev parent reply other threads:[~2017-09-08 15:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-07 11:41 [PATCH v4 0/6] irqdomain, gpio: expand irq_domain_push_irq() for DT use and use it for GPIO Masahiro Yamada
2017-09-07 11:41 ` [PATCH v4 1/6] irqdomain: rename variables in irq_domain_{push,pop}_irq() Masahiro Yamada
2017-09-07 12:47 ` Marc Zyngier
2017-09-07 17:45 ` David Daney
2017-09-08 15:05 ` Masahiro Yamada [this message]
[not found] ` <1504784522-26841-1-git-send-email-yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
2017-09-07 11:41 ` [PATCH v4 2/6] irqdomain: clear trigger type in irq_domain_push_irq() Masahiro Yamada
2017-09-07 12:25 ` Marc Zyngier
[not found] ` <a3e38f20-007b-1065-7999-95e2264f2155-5wv7dgnIgG8@public.gmane.org>
2017-09-08 15:09 ` Masahiro Yamada
2017-09-07 11:42 ` [PATCH v4 4/6] irqdomain: set irq domain flags before the irq domain becomes visible Masahiro Yamada
2017-09-07 11:41 ` [PATCH v4 3/6] irqdomain: move IRQ_DOMAIN_NAME_ALLOCATED define to the original position Masahiro Yamada
2017-09-07 12:04 ` Marc Zyngier
2017-09-08 15:10 ` Masahiro Yamada
2017-09-07 11:42 ` [PATCH v4 5/6] irqdomain: add IRQ_DOMAIN_FLAG_NO_CREATE flag Masahiro Yamada
2017-09-07 11:42 ` [PATCH v4 6/6] gpio: uniphier: add UniPhier GPIO controller driver Masahiro Yamada
[not found] ` <1504784522-26841-7-git-send-email-yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
2017-09-07 19:41 ` Rob Herring
[not found] ` <CAL_Jsq+Da1=myQGEpA_0f+dEU0Rk6RB3BJHVCzq0M0MyJ3UDoQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-09-08 15:14 ` Masahiro Yamada
2017-09-11 20:15 ` Rob Herring
2017-09-10 12:13 ` kbuild test robot
2017-09-12 14:03 ` Linus Walleij
2017-09-12 15:44 ` David Daney
[not found] ` <7e46f2a3-114f-0c34-d3c5-49e6422b9200-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
2017-09-13 8:31 ` Masahiro Yamada
2017-09-07 12:39 ` [PATCH v4 0/6] irqdomain, gpio: expand irq_domain_push_irq() for DT use and use it for GPIO Marc Zyngier
2017-09-08 15:06 ` Masahiro Yamada
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=CAK7LNARboWo4-zkioMAxtpM84f9avtL8Z4z_s0cU5UHXkGotPg@mail.gmail.com \
--to=yamada.masahiro@socionext.com \
--cc=david.daney@cavium.com \
--cc=ddaney@caviumnetworks.com \
--cc=devicetree@vger.kernel.org \
--cc=jason@lakedaemon.net \
--cc=jaswinder.singh@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mhiramat@kernel.org \
--cc=robh+dt@kernel.org \
--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).