From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BC198C4361B for ; Fri, 11 Dec 2020 22:59:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5973A20DD4 for ; Fri, 11 Dec 2020 22:59:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405836AbgLKWIU (ORCPT ); Fri, 11 Dec 2020 17:08:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58856 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405443AbgLKWIF (ORCPT ); Fri, 11 Dec 2020 17:08:05 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1662EC0613D6; Fri, 11 Dec 2020 14:07:25 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1607724443; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uE5KR5qlfz+ztx9s8pbRCB1Be+kxvrwztlDzBEoJCeU=; b=upIVkJhj5g1RmAalIreFExmj0QWc7xxC7dfgYyTKQ7/s1CPaLrvswCn2cis9a5ELIHv+rz IPyhjuoIqfAMI+60hoe1U1U27IhweRJLvNYpN7cTAqQ0o0KlM2VdD+/ibGw4UCrbJtLWLY inuTJUAvrZhdYHuTfLNeogwgdoyl5SGN/dy3kNNRxVqcfza2kw+U/H2LlJBjtaANpZFTIZ ptr78MOU90DKS42tb76OuG8X418bmY7SaqmPbyqibyrcTnWO7/ljKjMmuQI0HfaTAZd7Ho gSP1o6so90u917yflugfQ7VOzMuRufMAcgTvFJSwBRyBFBjjIC3oXcfJ628ySQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1607724443; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uE5KR5qlfz+ztx9s8pbRCB1Be+kxvrwztlDzBEoJCeU=; b=6l4EGHeIGgEoz1BM8xIprj71LYQ/8TNyn+KsbwNoVJfPjiraGOnwYmma/niMdHbbcB5BbA SooB9xEZT4EUdpBw== To: Andy Shevchenko Cc: LKML , Peter Zijlstra , Marc Zyngier , "James E.J. Bottomley" , Helge Deller , afzal mohammed , linux-parisc@vger.kernel.org, Russell King , linux-arm Mailing List , Mark Rutland , Catalin Marinas , Will Deacon , Christian Borntraeger , Heiko Carstens , linux-s390@vger.kernel.org, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Daniel Vetter , Pankaj Bharadiya , Chris Wilson , Wambui Karuga , intel-gfx , dri-devel , Tvrtko Ursulin , Linus Walleij , "open list\:GPIO SUBSYSTEM" , Lee Jones , Jon Mason , Dave Jiang , Allen Hubbe , linux-ntb@googlegroups.com, Lorenzo Pieralisi , Rob Herring , Bjorn Helgaas , Michal Simek , linux-pci , Karthikeyan Mitran , Hou Zhiqiang , Tariq Toukan , "David S. Miller" , Jakub Kicinski , netdev , "open list\:HFI1 DRIVER" , Saeed Mahameed , Leon Romanovsky , Boris Ostrovsky , Juergen Gross , Stefano Stabellini , xen-devel@lists.xenproject.org Subject: Re: [patch 03/30] genirq: Move irq_set_lockdep_class() to core In-Reply-To: <87h7osgifc.fsf@nanos.tec.linutronix.de> References: <20201210192536.118432146@linutronix.de> <20201210194042.860029489@linutronix.de> <87h7osgifc.fsf@nanos.tec.linutronix.de> Date: Fri, 11 Dec 2020 23:07:22 +0100 Message-ID: <87360cgfol.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Fri, Dec 11 2020 at 22:08, Thomas Gleixner wrote: > On Fri, Dec 11 2020 at 19:53, Andy Shevchenko wrote: > >> On Thu, Dec 10, 2020 at 10:14 PM Thomas Gleixner wrote: >>> >>> irq_set_lockdep_class() is used from modules and requires irq_to_desc() to >>> be exported. Move it into the core code which lifts another requirement for >>> the export. >> >> ... >> >>> + if (IS_ENABLED(CONFIG_LOCKDEP)) >>> + __irq_set_lockdep_class(irq, lock_class, request_class); > > You are right. Let me fix that. No. I have to correct myself. You're wrong. The inline is evaluated in the compilation units which include that header and because the function declaration is unconditional it is happy. Now the optimizer stage makes the whole thing a NOOP if CONFIG_LOCKDEP=n and thereby drops the reference to the function which makes it not required for linking. So in the file where the function is implemented: #ifdef CONFIG_LOCKDEP void __irq_set_lockdep_class(....) { } #endif The whole block is either discarded because CONFIG_LOCKDEP is not defined or compile if it is defined which makes it available for the linker. And in the latter case the optimizer keeps the call in the inline (it optimizes the condition away because it's always true). So in both cases the compiler and the linker are happy and everything works as expected. It would fail if the header file had the following: #ifdef CONFIG_LOCKDEP void __irq_set_lockdep_class(....); #endif Because then it would complain about the missing function prototype when it evaluates the inline. Thanks, tglx From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from galois.linutronix.de (Galois.linutronix.de. [2a0a:51c0:0:12e:550::1]) by gmr-mx.google.com with ESMTPS id v7si569363edj.5.2020.12.11.14.07.24 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Dec 2020 14:07:24 -0800 (PST) From: Thomas Gleixner Subject: Re: [patch 03/30] genirq: Move irq_set_lockdep_class() to core In-Reply-To: <87h7osgifc.fsf@nanos.tec.linutronix.de> References: <20201210192536.118432146@linutronix.de> <20201210194042.860029489@linutronix.de> <87h7osgifc.fsf@nanos.tec.linutronix.de> Date: Fri, 11 Dec 2020 23:07:22 +0100 Message-ID: <87360cgfol.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain To: Andy Shevchenko Cc: LKML , Peter Zijlstra , Marc Zyngier , "James E.J. Bottomley" , Helge Deller , afzal mohammed , linux-parisc@vger.kernel.org, Russell King , linux-arm Mailing List , Mark Rutland , Catalin Marinas , Will Deacon , Christian Borntraeger , Heiko Carstens , linux-s390@vger.kernel.org, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Daniel Vetter , Pankaj Bharadiya , Chris Wilson , Wambui Karuga , intel-gfx , dri-devel , Tvrtko Ursulin , Linus Walleij , "open list:GPIO SUBSYSTEM" , Lee Jones , Jon Mason , Dave Jiang , Allen Hubbe , linux-ntb@googlegroups.com, Lorenzo Pieralisi , Rob Herring , Bjorn Helgaas , Michal Simek , linux-pci , Karthikeyan Mitran , Hou Zhiqiang , Tariq Toukan , "David S. Miller" , Jakub Kicinski , netdev , "open list:HFI1 DRIVER" , Saeed Mahameed , Leon Romanovsky , Boris Ostrovsky , Juergen Gross , Stefano Stabellini , xen-devel@lists.xenproject.org List-ID: On Fri, Dec 11 2020 at 22:08, Thomas Gleixner wrote: > On Fri, Dec 11 2020 at 19:53, Andy Shevchenko wrote: > >> On Thu, Dec 10, 2020 at 10:14 PM Thomas Gleixner wrote: >>> >>> irq_set_lockdep_class() is used from modules and requires irq_to_desc() to >>> be exported. Move it into the core code which lifts another requirement for >>> the export. >> >> ... >> >>> + if (IS_ENABLED(CONFIG_LOCKDEP)) >>> + __irq_set_lockdep_class(irq, lock_class, request_class); > > You are right. Let me fix that. No. I have to correct myself. You're wrong. The inline is evaluated in the compilation units which include that header and because the function declaration is unconditional it is happy. Now the optimizer stage makes the whole thing a NOOP if CONFIG_LOCKDEP=n and thereby drops the reference to the function which makes it not required for linking. So in the file where the function is implemented: #ifdef CONFIG_LOCKDEP void __irq_set_lockdep_class(....) { } #endif The whole block is either discarded because CONFIG_LOCKDEP is not defined or compile if it is defined which makes it available for the linker. And in the latter case the optimizer keeps the call in the inline (it optimizes the condition away because it's always true). So in both cases the compiler and the linker are happy and everything works as expected. It would fail if the header file had the following: #ifdef CONFIG_LOCKDEP void __irq_set_lockdep_class(....); #endif Because then it would complain about the missing function prototype when it evaluates the inline. Thanks, tglx From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DCA69C4361B for ; Mon, 14 Dec 2020 08:18:50 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 947C6207A6 for ; Mon, 14 Dec 2020 08:18:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 947C6207A6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3ADFA6E087; Mon, 14 Dec 2020 08:18:45 +0000 (UTC) Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by gabe.freedesktop.org (Postfix) with ESMTPS id 165F56ECDB; Fri, 11 Dec 2020 22:07:25 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1607724443; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uE5KR5qlfz+ztx9s8pbRCB1Be+kxvrwztlDzBEoJCeU=; b=upIVkJhj5g1RmAalIreFExmj0QWc7xxC7dfgYyTKQ7/s1CPaLrvswCn2cis9a5ELIHv+rz IPyhjuoIqfAMI+60hoe1U1U27IhweRJLvNYpN7cTAqQ0o0KlM2VdD+/ibGw4UCrbJtLWLY inuTJUAvrZhdYHuTfLNeogwgdoyl5SGN/dy3kNNRxVqcfza2kw+U/H2LlJBjtaANpZFTIZ ptr78MOU90DKS42tb76OuG8X418bmY7SaqmPbyqibyrcTnWO7/ljKjMmuQI0HfaTAZd7Ho gSP1o6so90u917yflugfQ7VOzMuRufMAcgTvFJSwBRyBFBjjIC3oXcfJ628ySQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1607724443; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uE5KR5qlfz+ztx9s8pbRCB1Be+kxvrwztlDzBEoJCeU=; b=6l4EGHeIGgEoz1BM8xIprj71LYQ/8TNyn+KsbwNoVJfPjiraGOnwYmma/niMdHbbcB5BbA SooB9xEZT4EUdpBw== To: Andy Shevchenko Subject: Re: [patch 03/30] genirq: Move irq_set_lockdep_class() to core In-Reply-To: <87h7osgifc.fsf@nanos.tec.linutronix.de> References: <20201210192536.118432146@linutronix.de> <20201210194042.860029489@linutronix.de> <87h7osgifc.fsf@nanos.tec.linutronix.de> Date: Fri, 11 Dec 2020 23:07:22 +0100 Message-ID: <87360cgfol.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 14 Dec 2020 08:17:41 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Karthikeyan Mitran , Peter Zijlstra , Catalin Marinas , dri-devel , Chris Wilson , "James E.J. Bottomley" , Saeed Mahameed , netdev , Will Deacon , Michal Simek , linux-s390@vger.kernel.org, afzal mohammed , Lorenzo Pieralisi , Dave Jiang , xen-devel@lists.xenproject.org, Leon Romanovsky , "open list:HFI1 DRIVER" , Marc Zyngier , Helge Deller , Russell King , Christian Borntraeger , linux-pci , Jakub Kicinski , Heiko Carstens , Wambui Karuga , Allen Hubbe , Juergen Gross , David Airlie , "open list:GPIO SUBSYSTEM" , Stefano Stabellini , Rodrigo Vivi , Bjorn Helgaas , Lee Jones , linux-arm Mailing List , Boris Ostrovsky , Tvrtko Ursulin , linux-parisc@vger.kernel.org, Pankaj Bharadiya , Hou Zhiqiang , LKML , Tariq Toukan , Jon Mason , linux-ntb@googlegroups.com, intel-gfx , "David S. Miller" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Dec 11 2020 at 22:08, Thomas Gleixner wrote: > On Fri, Dec 11 2020 at 19:53, Andy Shevchenko wrote: > >> On Thu, Dec 10, 2020 at 10:14 PM Thomas Gleixner wrote: >>> >>> irq_set_lockdep_class() is used from modules and requires irq_to_desc() to >>> be exported. Move it into the core code which lifts another requirement for >>> the export. >> >> ... >> >>> + if (IS_ENABLED(CONFIG_LOCKDEP)) >>> + __irq_set_lockdep_class(irq, lock_class, request_class); > > You are right. Let me fix that. No. I have to correct myself. You're wrong. The inline is evaluated in the compilation units which include that header and because the function declaration is unconditional it is happy. Now the optimizer stage makes the whole thing a NOOP if CONFIG_LOCKDEP=n and thereby drops the reference to the function which makes it not required for linking. So in the file where the function is implemented: #ifdef CONFIG_LOCKDEP void __irq_set_lockdep_class(....) { } #endif The whole block is either discarded because CONFIG_LOCKDEP is not defined or compile if it is defined which makes it available for the linker. And in the latter case the optimizer keeps the call in the inline (it optimizes the condition away because it's always true). So in both cases the compiler and the linker are happy and everything works as expected. It would fail if the header file had the following: #ifdef CONFIG_LOCKDEP void __irq_set_lockdep_class(....); #endif Because then it would complain about the missing function prototype when it evaluates the inline. Thanks, tglx _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37946C433FE for ; Fri, 11 Dec 2020 22:07:27 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D0FF623D50 for ; Fri, 11 Dec 2020 22:07:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D0FF623D50 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5E02D6ECDC; Fri, 11 Dec 2020 22:07:26 +0000 (UTC) Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by gabe.freedesktop.org (Postfix) with ESMTPS id 165F56ECDB; Fri, 11 Dec 2020 22:07:25 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1607724443; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uE5KR5qlfz+ztx9s8pbRCB1Be+kxvrwztlDzBEoJCeU=; b=upIVkJhj5g1RmAalIreFExmj0QWc7xxC7dfgYyTKQ7/s1CPaLrvswCn2cis9a5ELIHv+rz IPyhjuoIqfAMI+60hoe1U1U27IhweRJLvNYpN7cTAqQ0o0KlM2VdD+/ibGw4UCrbJtLWLY inuTJUAvrZhdYHuTfLNeogwgdoyl5SGN/dy3kNNRxVqcfza2kw+U/H2LlJBjtaANpZFTIZ ptr78MOU90DKS42tb76OuG8X418bmY7SaqmPbyqibyrcTnWO7/ljKjMmuQI0HfaTAZd7Ho gSP1o6so90u917yflugfQ7VOzMuRufMAcgTvFJSwBRyBFBjjIC3oXcfJ628ySQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1607724443; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uE5KR5qlfz+ztx9s8pbRCB1Be+kxvrwztlDzBEoJCeU=; b=6l4EGHeIGgEoz1BM8xIprj71LYQ/8TNyn+KsbwNoVJfPjiraGOnwYmma/niMdHbbcB5BbA SooB9xEZT4EUdpBw== To: Andy Shevchenko In-Reply-To: <87h7osgifc.fsf@nanos.tec.linutronix.de> References: <20201210192536.118432146@linutronix.de> <20201210194042.860029489@linutronix.de> <87h7osgifc.fsf@nanos.tec.linutronix.de> Date: Fri, 11 Dec 2020 23:07:22 +0100 Message-ID: <87360cgfol.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Subject: Re: [Intel-gfx] [patch 03/30] genirq: Move irq_set_lockdep_class() to core X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Karthikeyan Mitran , Peter Zijlstra , Catalin Marinas , Linus Walleij , dri-devel , Chris Wilson , "James E.J. Bottomley" , Saeed Mahameed , netdev , Will Deacon , Michal Simek , linux-s390@vger.kernel.org, afzal mohammed , Lorenzo Pieralisi , Dave Jiang , xen-devel@lists.xenproject.org, Leon Romanovsky , "open list:HFI1 DRIVER" , Marc Zyngier , Helge Deller , Russell King , Christian Borntraeger , linux-pci , Jakub Kicinski , Heiko Carstens , Wambui Karuga , Allen Hubbe , Juergen Gross , Rob Herring , David Airlie , "open list:GPIO SUBSYSTEM" , Stefano Stabellini , Bjorn Helgaas , Lee Jones , linux-arm Mailing List , Boris Ostrovsky , linux-parisc@vger.kernel.org, Hou Zhiqiang , LKML , Tariq Toukan , Jon Mason , linux-ntb@googlegroups.com, intel-gfx , "David S. Miller" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Fri, Dec 11 2020 at 22:08, Thomas Gleixner wrote: > On Fri, Dec 11 2020 at 19:53, Andy Shevchenko wrote: > >> On Thu, Dec 10, 2020 at 10:14 PM Thomas Gleixner wrote: >>> >>> irq_set_lockdep_class() is used from modules and requires irq_to_desc() to >>> be exported. Move it into the core code which lifts another requirement for >>> the export. >> >> ... >> >>> + if (IS_ENABLED(CONFIG_LOCKDEP)) >>> + __irq_set_lockdep_class(irq, lock_class, request_class); > > You are right. Let me fix that. No. I have to correct myself. You're wrong. The inline is evaluated in the compilation units which include that header and because the function declaration is unconditional it is happy. Now the optimizer stage makes the whole thing a NOOP if CONFIG_LOCKDEP=n and thereby drops the reference to the function which makes it not required for linking. So in the file where the function is implemented: #ifdef CONFIG_LOCKDEP void __irq_set_lockdep_class(....) { } #endif The whole block is either discarded because CONFIG_LOCKDEP is not defined or compile if it is defined which makes it available for the linker. And in the latter case the optimizer keeps the call in the inline (it optimizes the condition away because it's always true). So in both cases the compiler and the linker are happy and everything works as expected. It would fail if the header file had the following: #ifdef CONFIG_LOCKDEP void __irq_set_lockdep_class(....); #endif Because then it would complain about the missing function prototype when it evaluates the inline. Thanks, tglx _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx