[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9df5e85b-79e6-b796-e5ce-bc47d2cbed67@cogentembedded.com>
Date: Thu, 30 Dec 2021 13:53:30 +0300
From: Nikita Yushchenko <nikita.yoush@...entembedded.com>
To: Marc Zyngier <maz@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Magnus Damm <magnus.damm@...il.com>,
linux-renesas-soc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH/RFC] drivers/irqchip: add irq-inverter
>>>>> The right way to do it is to use the existing API by exposing the
>>>>> inverter (there are existing examples in the tree, using the
>>>>> hierarchical model)...
>>>
>>> A much simpler version can be written in a few minutes, see below...
>>
>> Can something like that be used if the parent domain is not
>> hierarchical (i.e. does not provide alloc(), but provides map()
>> instead)?
>
> No. This definitely relies on the parent being hierarchical, as that's
> exactly what it was designed for the first place.
Is supporting hierarchical API now mandatory for kernel irqchips?
If yes, then perhaps you can at least document it somewhere?
E.g. declare irq_domain.map() as deprecated?
If no, then I'd like to discuss a solution for irq_inverter that can work for non-hierarchical case.
Nikita
Powered by blists - more mailing lists