Re: [PATCH v2] dt-bindings: interrupt-controller: loongson,liointc: Fix warnings about liointc-2.0

From: Binbin Zhou
Date: Mon Oct 30 2023 - 05:57:40 EST


On Sun, Oct 29, 2023 at 1:42 PM Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxx> wrote:
>
> On 26/10/2023 09:19, Huacai Chen wrote:
> > Hi, Krzysztof
> >
> > On Wed, Oct 25, 2023 at 3:16 PM Krzysztof Kozlowski
> > <krzysztof.kozlowski@xxxxxxxxxx> wrote:
> >>
> >> On 25/10/2023 03:56, Huacai Chen wrote:
> >>> Hi, Krzysztof,
> >>>
> >>> On Fri, Oct 20, 2023 at 8:18 PM Marc Zyngier <maz@xxxxxxxxxx> wrote:
> >>>>
> >>>> On Fri, 20 Oct 2023 10:51:35 +0100,
> >>>> Binbin Zhou <zhoubb.aaron@xxxxxxxxx> wrote:
> >>>>>
> >>>>> Hi Krzysztof & Marc:
> >>>>>
> >>>>> Sorry for the interruption.
> >>>>> As said before, we tried to use the 'interrupt-map attribute' in our
> >>>>> Loongson liointc dts(i), but there are some unfriendly points.
> >>>>> Do you have any other different suggestions?
> >>>>
> >>>> I don't have any suggestion, but if you are still thinking of adding
> >>>> some extra crap to the of_irq_imap_abusers[] array, the answer is a
> >>>> firm 'NO'.
> >>> Excuse me, but as described before, 'interrupt-map' cannot be used for
> >>> liointc unless adding it to of_irq_imap_abusers[], can we still use
> >>> 'parent_int_map' in this case? Or just change it to 'parent-int-map'
> >>> to satisfy the naming style?
> >>
> >> Why do you respond to me? You received firm 'NO' about
> >> of_irq_imap_abusers, so how adhering to naming style or violating naming
> >> style has anything to do with it?
> > I'm sorry but of_irq_imap_abusers is to make 'interrupt-map' to work,
> > without of_irq_imap_abusers we can only use the existing
> > 'parent_int_map'. We need your response because we want to know
> > whether you can accept the existing method since the other approach
> > has received 'NO'. And, changing 'parent_int_map' to 'parent-int-map'
> > can be a little better, at least it satisfies the naming style.
>
> Indeed, interrupt-map might not fit here. I don't know whether your
> custom property - purely for runtime performance purpose - will be
> accepted. Initial description of this field suggested that it is OS
> policy, not hardware choice. But sure, propose something with
> justification, so we can review it. The proposal must not break ABI, so
> you must support both parent_int_map and parent-int-map (or whatever we
> call it) properties. The first we will probably deprecate.
>
Hi Krzysztof:

Thanks a lot for your reply and suggestion!
I'll try to split the change points into separate patches in the next
version, it might be better understood.

Thanks.
Binbin

> The way this property was sneaked into kernel bypassing review is still
> disappointing.
>
> Best regards,
> Krzysztof
>