Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp423328ybt; Wed, 1 Jul 2020 01:38:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwr7YiXLhBd0OlPeza9A4jusgrzI3bCQfIFZ+2qLvZ8kqUPudIV/mqYl9PxnO7K3S+tHtZ1 X-Received: by 2002:a17:906:6d15:: with SMTP id m21mr21234732ejr.209.1593592727171; Wed, 01 Jul 2020 01:38:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593592727; cv=none; d=google.com; s=arc-20160816; b=Dek5MW8+G0N+ckUkApxr5qGq/HG6pBiFByIshLies4rDcCxj+1oJgOfzsWoFyer1Pk rYZkM9N8jpFlqU8jEAmT+aLIca1UlawHYLHg3BaFa8TJzr6HStjMg6SCIMTGg07mNAlE VJ7aQqGcGWCMSbdIHZZ3SGn1JvbeyvFCHQt5Ejxs8bL25jleSL1ktRZgkw672y7dnsNW iiWXsp5FZ4bydkK7Ci3JhpuBDvQTrJlt8vywu3P3tnCYChzLNerqAFaIxD9pgNH+t/A2 Z5hjohifXQ75qjRxNtQgtwpQBmg+eYmYIxLfkZYYhDPpW/AWySyGtSSrDBCpgtWcNwx5 +oiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=2Ls7lqAbPqUjSKa1+m5x5NSOYqrObQYiqQnpjjhFHgo=; b=CQw+w0GPyE5KGfuyXhEvL4FCbNabAMcRexSugpME1MsLR0kbayhUAm6tVBrYH3aEFu ElhNUadgdXJxoVrlPv9+QdWxHxj5KyqZ7bBof1CY40jNMoYFHbOqQY9QsosFCcm24fTj u2qlBBrpiEWuwld9at0Dg6SRQt1GkVtu6MXTjzyAm6RWyomiytmZoIvWBfRqNK+TamTf G7Zcdz1E8/hn8sJUVueiBhrFkbgVsc64PLC5N5RZ0feqqZjSBQuWuRAaTfNkn94Y8jL/ q+3Bhsr1nC5DuGtTwnKD9K/EdV2BkhKhKlTqKkcVK4huUlN0hG2iF+93UFIT0lMlWHsQ cNgw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a2si3811331edb.243.2020.07.01.01.38.24; Wed, 01 Jul 2020 01:38:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728794AbgGAIiT convert rfc822-to-8bit (ORCPT + 99 others); Wed, 1 Jul 2020 04:38:19 -0400 Received: from mout.kundenserver.de ([217.72.192.75]:36497 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728713AbgGAIiS (ORCPT ); Wed, 1 Jul 2020 04:38:18 -0400 Received: from mail-lf1-f43.google.com ([209.85.167.43]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.145]) with ESMTPSA (Nemesis) id 1N6LIF-1ikk2T2fE1-016k59; Wed, 01 Jul 2020 10:38:16 +0200 Received: by mail-lf1-f43.google.com with SMTP id u25so13124276lfm.1; Wed, 01 Jul 2020 01:38:16 -0700 (PDT) X-Gm-Message-State: AOAM533xy/B54DPq4ztENfNDLBCfLWy5i3zXjLonPGW7MiEEQDXr5sle iBdBAJ1mIhFsdXAuXBYS16mfpCFS2+54Wg8GfrA= X-Received: by 2002:a19:4a94:: with SMTP id x142mr14757261lfa.207.1593592696066; Wed, 01 Jul 2020 01:38:16 -0700 (PDT) MIME-Version: 1.0 References: <1593410042-10598-1-git-send-email-Anson.Huang@nxp.com> <1593410042-10598-3-git-send-email-Anson.Huang@nxp.com> In-Reply-To: From: Arnd Bergmann Date: Wed, 1 Jul 2020 10:37:59 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V3 02/10] init.h: Fix the __setup_param() macro for module build To: Anson Huang Cc: Russell King - ARM Linux , Shawn Guo , Sascha Hauer , Sascha Hauer , Fabio Estevam , Michael Turquette , Stephen Boyd , "oleksandr.suvorov@toradex.com" , Stefan Agner , Peng Fan , Abel Vesa , Aisheng Dong , Andy Duan , Daniel Baluta , YueHaibing , Stephen Rothwell , Al Viro , Linux ARM , "linux-kernel@vger.kernel.org" , linux-clk , dl-linux-imx Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Provags-ID: V03:K1:41ecaovUe9VVqxw3GNZSmlJioDVuUFbZuYiPPXm3pJZCduxti+E 2PapA+8sEsI26KAMnuMGCKD9nf43PRyPyLopR37GIVMFoNTCWHSLxyvbGV6fTyEkEN+dn83 RQ+2vHKfVVUeOBx2Um5qcWKExQLtf+0GwODE8C+w7ttybwrAGZvW8oJOoeCOCirvNA8gMfu 9ZCvYFU8dqHbAPJUHhOpA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:6QPKR3G4LQs=:UYD4p1YQ5DuPba1zFbRJ1t UxU5xk9KDrRr2CEed5E1K6JULqSQ0kn/DlosJBniA/W7t1xJ17eEI3x0Zu1Gan8ozjaKew3mp BgLTenvZZnbszZqWayE4lJBuPaYhLMa0yZgbmP+fa9ZhNOQmEiWVW2t47+Rq8HYvgkCTOcs5q 1ZApXvPNUSJdABHzCagD5aR+auzEGOB3wuDyH7ZEJ+8BFbs4kvbLlESj1uVsaGmYAsfgapFGb /P5wDT9dV4NXqkoWr8TSzUNThdTfO95NPBQ1jiMN2pgeKYybkkelGswucr2YVvm3YxJP9vy8H B7UoV4RUdad8Fl1PMXbxzjbg/aqnA23PYL9fp165PITtRk41VjP7MajHMemiEGUD3M1eEk4yN iq+6QylcHOoZSs8T0SWcaxrTN1sUY4wmCeBc5V+QFVDKdNVzMrtzoQ3Z5NfkpaT9a0bzUWsqx mQ/bAWKVrwGk608CcraGBzPx12tx3BPf2ySG54WH3kqGX2o2ZUzwFv7g+1S5nM7F057yRHvvb h5YtpNgpGC+0639q+lrGkj9GnTJuXTDm+nRJhVElJ3EFlrdH5Av0mfPZRxrnDaR4bUDRbK9S0 fv6kc5f+oPZyTlAsZtm4tOylzWQVYkDhG7DmCVggPk+4j/YW6G5xfrqBB37Xp4aE/RNq0j4Lq a9YHFBrBdWV4r0DpBQ979xJ/n+cqmG2F3G66kIiJTSIF0eI9Y5uqRejtcVLsHHwFJMYJDif67 8NNwRhU5Er98IhCS4R7kj3zbBhrQCXPpyZ2ZWksA2XuC1nLosmKA+sYPHB+Fc/DLmlAwDDMZ+ yt+xsa3+Ku/OfZxnSB9BXcjmb6UOTL7+XUJX0N18/iIeqPBYjc= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 1, 2020 at 7:14 AM Anson Huang wrote: > > Subject: Re: [PATCH V3 02/10] init.h: Fix the __setup_param() macro for module build > > On Mon, Jun 29, 2020 at 1:40 PM Anson Huang > > wrote: > > > It makes sense to drop the __setup() and __serup_param() in the #else > > > block, just use one definition for all cases, if no one objects, I will remove > > them in next patch series. > > > > Ok, sounds good. Note that there may be users of the plain __setup() that just > > get turned into nops right now. Usually those are already enclosed in "#ifndef > > MODULE", but if they are not, then removing the definition would cause a > > build error. > > > > Have a look if you can find such instances, and either change the patch to add > > the missing "#ifndef MODULE" checks, or just drop the __setup_param() and > > leave the __setup() if it gets too complicated. > > Looks like the __setup_param() defined in "#ifndef MODULE" can NOT be used for > MODULE build at all, so sharing same implementation is NOT available, so if it is NOT > that critical, I plan to keep the #else block in this patch, let me know if you have further > concern or any other suggestion, below is the build error reported for module build using > __setup_param() implementation for built in. I don't understand what your plan is here. Do you mean you will leave that part of the clk driver as built-in? > In file included from ./arch/arm64/include/asm/alternative.h:12, > from ./arch/arm64/include/asm/lse.h:15, > from ./arch/arm64/include/asm/cmpxchg.h:14, > from ./arch/arm64/include/asm/atomic.h:16, > from ./include/linux/atomic.h:7, > from ./include/asm-generic/bitops/atomic.h:5, > from ./arch/arm64/include/asm/bitops.h:26, > from ./include/linux/bitops.h:29, > from ./include/linux/kernel.h:12, > from ./include/linux/clk.h:13, > from drivers/clk/imx/clk.c:2: > ./include/linux/init.h:177:16: error: variable ‘__setup_imx_keep_uart_earlycon’ has initializer but incomplete type > 177 | static struct obs_kernel_param __setup_##unique_id \ > | ^~~~~~~~~~~~~~~~ > drivers/clk/imx/clk.c:157:1: note: in expansion of macro ‘__setup_param’ > 157 | __setup_param("earlycon", imx_keep_uart_earlycon, > | ^~~~~~~~~~~~~ > ./include/linux/init.h:180:7: warning: excess elements in struct initializer > 180 | = { __setup_str_##unique_id, fn, early } > | ^~~~~~~~~~~~ > drivers/clk/imx/clk.c:157:1: note: in expansion of macro ‘__setup_param’ > 157 | __setup_param("earlycon", imx_keep_uart_earlycon, > | ^~~~~~~~~~~~~ > ./include/linux/init.h:180:7: note: (near initialization for ‘__setup_imx_keep_uart_earlycon’) This error just means you can't have a __setup_param() call in a loadable module, which we already knew. If you need to do something with the clocks early on, that has to be in built-in code and cannot be in a module. If you don't need that code, then you should just remove it from both the modular version and the built-in version. What is the purpose of that __setup_param() argument parsing in the clock driver? Arnd