linux-kernel - Re: [PATCH] irq-dw-apb-ictl: convert to platform device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACRpkdZy0mG-2U_DV=d=xL67jSuYZL4k+_5p0sUpXJ2GV6a8Yg@mail.gmail.com>
Date:	Mon, 9 Mar 2015 17:03:26 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Vineet Gupta <Vineet.Gupta1@...opsys.com>
Cc:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	Jisheng Zhang <jszhang@...vell.com>,
	Alexey Brodkin <Alexey.Brodkin@...opsys.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jason Cooper <jason@...edaemon.net>,
	Alexandre Courbot <gnurou@...il.com>,
	Jamie Iles <jamie@...ieiles.com>
Subject: Re: [PATCH] irq-dw-apb-ictl: convert to platform device

On Wed, Mar 4, 2015 at 11:46 AM, Vineet Gupta
<Vineet.Gupta1@...opsys.com> wrote:
> On Wednesday 04 March 2015 02:30 PM, Sebastian Hesselbarth wrote:
>> On 04.03.2015 04:11, Jisheng Zhang wrote:
>>> On Tue, 3 Mar 2015 06:56:59 -0800
>>> Alexey Brodkin <Alexey.Brodkin@...opsys.com> wrote:
>>>> This allows utilization of probe deferral if master interrupt controller
>>>> was not yet probed.
>>>>
>>>> In my case there's an DW APB GPIO configured as interrupt controller
>>>> which is a master for DW APB INTC.
>>>>
>>>> Interrupt controller sub-node of DW APB GPIO gets parsed only on DW APB
>>>> GPIO real probe - before that slave interrupt controllers cannot resolve
>>>> its master connection which lead to failures on probes of devices that
>>>> use DW APB INTC as its interrupt controller.
>> Alexey,
>>
>> thanks for the input, but the point is not to break existing users which
>> your patch clearly does.
>>
>> Just to get this straight for me, you are using DW_APB_INTC as a _slave_
>> interrupt controller of DW_APB_GPIO _master_ interrupt controller? Is
>> this a fictional setup to test your IP or is it a real world example?
>>
>> IMHO, if the setup is real, i.e. an APB_INTC hooked up to a GPIO
>> upstream-wise, you should think of a new driver for an externally
>> connected but APB bus accessible (???) interrupt controller. If it
>> is rather some extension of the GPIO controller you should amend
>> dw_apb_gpio.c instead.
>>
>> Sorry, but I cannot really wrap my head around that specific setup...
>>
>> Sebastian
>
> Hi Sebastian,
>
> I think Alexey is away for rest of the week so let me fill in some of the details.
> The setup is indeed real and part of ARC SDP (Software Development Platform) and
> these patches are precursor to getting that merged upstream.
>
> SDP has a split main board / cpu card design, where both cards have an intc of own
> to mux the irqs from respective levels. MB has a DW APB intc which sends a single
> uplink to DW GPIO intc on cpu card, which in turn hooks up to ARC core. In the
> final design, the board guys decided that this GPIO intc will act as a pass thru
> for the downstream IRQ, but we still need to clear the interrupt on it etc - hence
> it needs to properly show up in the cascaded intc hierarchy.

We have hierarchical IRQ domains in the Linux kernel since a while
back and I think that is what you want here.

I am looking at some way to have any GPIOLIB_IRQCHIP turn up
as a proper hierarchical irqchip but that means getting at the domain
from an IRQ number, not just knowing it from context so have not
gotten around to fixing this yet...

We have several cascaded irqchip drivers doing this already however,
look in drivers/irqchip/irq-vic.c function vic_init_cascaded() for example.
A cascaded GPIO-based irqchip is no different for what I can tell.
Just call irq_set_chained_handler() and be happy.

Well there is also irq_set_parent(), which the gpiolib irqchip calls
and which is helpful for the situation where the irq needs to be
resent (see kernel/irq/resend.c).

I set this also for the cascaded irqs on GPIOLIB_IRQCHIP but
don't know for sure if it's needed.

By the way please if you have time convert the DWAPB driver
to GPIOLIB_IRQCHIP so we can solve problems like this in the
GPIO core and need not deal with it in a myriad of drivers...

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/