Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751301AbdCSIcA (ORCPT ); Sun, 19 Mar 2017 04:32:00 -0400 Received: from smtprelay0014.hostedemail.com ([216.40.44.14]:45135 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751251AbdCSIb5 (ORCPT ); Sun, 19 Mar 2017 04:31:57 -0400 X-Session-Marker: 6A6F6540706572636865732E636F6D X-Spam-Summary: 10,1,0,,d41d8cd98f00b204,joe@perches.com,:::::::,RULES_HIT:41:152:334:355:368:369:379:541:599:967:969:973:988:989:1260:1277:1311:1313:1314:1345:1359:1373:1437:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1777:1792:2111:2393:2525:2565:2682:2685:2691:2859:2895:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3622:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4321:4361:4425:5007:6119:7653:7903:8784:9025:10007:10400:10450:10455:10848:11026:11232:11658:11783:11914:12043:12295:12296:12438:12555:12663:12740:12895:13095:13894:14181:14659:14664:14721:19904:19999:21063:21080:21324:21433:21451:30006:30012:30041:30054:30070:30089:30091,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:1:0,LFtime:2,LUA_SUMMARY:none X-HE-Tag: bells77_26ad494051233 X-Filterd-Recvd-Size: 3015 Message-ID: <1489912261.13953.22.camel@perches.com> Subject: Re: checkpatch: Question regarding asmlinkage and storage class From: Joe Perches To: Paul Menzel , Andy Whitcroft Cc: linux-kernel@vger.kernel.org, coreboot@coreboot.org Date: Sun, 19 Mar 2017 01:31:01 -0700 In-Reply-To: <1489839338.9183.68.camel@users.sourceforge.net> References: <1489839338.9183.68.camel@users.sourceforge.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.3-0ubuntu0.1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2134 Lines: 69 On Sat, 2017-03-18 at 13:15 +0100, Paul Menzel wrote: > Dear checkpatch developers, > > > The coreboot project started using checkpatch.pl, and now some effort > is going into fixing issues pointed out by `checkpatch.pl`. > > The file `src/arch/x86/acpi_s3.c` in coreboot contains the code below. > > ``` >    205 void (*acpi_do_wakeup)(uintptr_t vector, u32 backup_source, u32 backup_target, >    206 u32 backup_size) asmlinkage = (void *)WAKEUP_BASE; > ``` > > The warning is > > > WARNING: storage class should be at the beginning of the declaration > > which raised the question below [2]. > > > And I am waiting for someone to answer why checkpatch.pl claims > > asmlinkage as a storage-class in the first place. [] > In coreboot the macro is defined similarly to Linux. > > ``` > #define asmlinkage __attribute__((regparm(0))) > #define alwaysinline inline __attribute__((always_inline)) > ``` Are they similar? $ git grep -i "define.*ASMLINKAGE\b" include include/linux/linkage.h:#define CPP_ASMLINKAGE extern "C" include/linux/linkage.h:#define CPP_ASMLINKAGE include/linux/linkage.h:#define asmlinkage CPP_ASMLINKAGE I believe asmlinkage is defined just to avoid possible asm/c++ symbol decorations. > In Linux, commit 9c0ca6f9 (update checkpatch.pl to version 0.10) seems > to have introduced the check. The commit message contains “asmlinkage > is also a storage type”. > > Furthermore, `checkpatch.pl` doesn’t seem to warn about the code below. > > ``` > void __attribute__((weak)) mainboard_suspend_resume(void) > ``` > > This raises the question below. > > > It appears coreboot proper mostly followed this placement for > > function attributes before. It would be nice if we were consistent, > > specially if checkpatch starts to complaint about these. > > Is there another reason, besides not having that implemented? > > I am looking forward to your answers. > > > Kind regards, > > Paul > > > [1] https://review.coreboot.org/#/c/18865/1/src/arch/x86/acpi_s3.c@205 > [2] https://review.coreboot.org/18865/ > [3] https://review.coreboot.org/#/c/18865/1/src/arch/x86/acpi_s3.c@244