linux-kernel - Re: [tip:irq/core 12/13] drivers/irqchip/irq-vic.c:295:2: error: implicit declaration of function 'set_handle_irq'; did you mean 'vic_handle

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: <mhng-b8f6e13a-d514-4af3-936e-22dd9ab9a546@palmer-si-x1c4>
Date:   Tue, 27 Mar 2018 09:18:47 -0700 (PDT)
From:   Palmer Dabbelt <palmer@...ive.com>
To:     tglx@...utronix.de
CC:     Arnd Bergmann <arnd@...db.de>, fengguang.wu@...el.com,
        kbuild-all@...org, linux-kernel@...r.kernel.org, tipbuild@...or.com
Subject:     Re: [tip:irq/core 12/13] drivers/irqchip/irq-vic.c:295:2: error: implicit declaration of function 'set_handle_irq'; did you mean 'vic_handle_irq'?

On Tue, 27 Mar 2018 08:38:29 PDT (-0700), tglx@...utronix.de wrote:
> On Tue, 27 Mar 2018, Palmer Dabbelt wrote:
>> On Mon, 26 Mar 2018 22:27:36 PDT (-0700), tglx@...utronix.de wrote:
>> >
>> > The commits in tip right now are:
>> >
>> >   cc6c98485f8e ("RISC-V: Move to the new GENERIC_IRQ_MULTI_HANDLER handler")
>> >   caacdbf4aa56 ("genirq: Add CONFIG_GENERIC_IRQ_MULTI_HANDLER")
>> >
>> > I surely can revert them, but I don't see how they would break arm or
>> > anything else.
>>
>> If GENERIC_IRQ_MULTI_HANDLER is set via randconfig then set_handle_irq() is
>> pulled in from the generic code, which conflicts with the definitions in arm,
>> arm64, and openrisc.  The RISC-V commit depends on the genirq one.
>
> Two ways to fix that:
>
>  - Rename set_handle_irq() in tip:irq/core and then convert the rest of the
>    tree over. A few more files touched, but nothing harmful
>
>  - Make GENERIC_IRQ_MULTI_HANDLER depend on !IRQ_MULTI_HANDLER. That should
>    cure it as well

I have a patch set that does the second one, but it's done in a manner that 
assumes the partial patch set got merged.  Let me just send it out...