From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0EAB213AFA for ; Mon, 18 Sep 2023 08:23:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695025421; x=1726561421; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=LSr4AFp7VQS9eCOKjiyauP1ikNwrfoAhtarijUPvqlU=; b=f6pp+4bcvAfJjx6M2YyK4sUZJuxJ2xThxeuc2rLa6KQykV5JL/fRw7da V6Acmg6LWdddp6npJe4pyurnNMUYbcRNt6o9vBD3hAuGc80i5bnpof/vz Y4xfv/RdNqF1W0XBp4RJ4+W/qSvS3eiKcaR3LoSjC6Ty8Q1PgSv0tNmSq 8r3fYC+SCiBj2jhAeYQidwRuE0Img5dLY3YXea3pPQpWx38jhK7ksWBQb 5URqcIV5L2vo+npiXLn3wTPrEBNsQOvFCfs8DYymhK+5pARN6nMTdiT4z JkeA/tcixxBcFV/ysu+9Phknjo8B0EhTjoxAQoXb02JWkvV/fRyLT/Yta g==; X-IronPort-AV: E=McAfee;i="6600,9927,10836"; a="382341052" X-IronPort-AV: E=Sophos;i="6.02,156,1688454000"; d="scan'208";a="382341052" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Sep 2023 01:23:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10836"; a="860971603" X-IronPort-AV: E=Sophos;i="6.02,156,1688454000"; d="scan'208";a="860971603" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga002.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Sep 2023 01:23:38 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.97-RC0) (envelope-from ) id 1qi9Xb-0000000GMuR-2iAg; Mon, 18 Sep 2023 11:23:35 +0300 Date: Mon, 18 Sep 2023 11:23:35 +0300 From: Andy Shevchenko To: Huacai Chen , Guo Ren Cc: loongarch@lists.linux.dev, linux-kernel@vger.kernel.org, WANG Xuerui Subject: Re: [PATCH v1 1/2] LoongArch: Add missing headers Message-ID: References: <20230914103445.511285-1-andriy.shevchenko@linux.intel.com> Precedence: bulk X-Mailing-List: loongarch@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo On Mon, Sep 18, 2023 at 04:05:50PM +0800, Huacai Chen wrote: > On Mon, Sep 18, 2023 at 2:49 PM Andy Shevchenko > wrote: > > On Sat, Sep 16, 2023 at 08:05:52PM +0800, Huacai Chen wrote: > > > On Sat, Sep 16, 2023 at 6:27 PM Andy Shevchenko > > > wrote: > > > > On Fri, Sep 15, 2023 at 08:36:24AM +0800, Huacai Chen wrote: > > > > > On Fri, Sep 15, 2023 at 2:53 AM Andy Shevchenko > > > > > wrote: > > > > > > On Thu, Sep 14, 2023 at 11:25:22PM +0800, Huacai Chen wrote: > > > > > > > > > > > Thank you for your patch, can this patch solve the problem below? > > > > > > > https://lore.kernel.org/oe-kbuild-all/202309072237.9zxMv4MZ-lkp@intel.com/T/#u > > > > > > > > > > > > Nope, this just adds missing includes. > > > > > > No functional change, so warnings will still be there. > > > > > But I think a patch should solve a problem. > > > > > > > > No, that problem is static analyser concern, not the compiler nor linker. > > > > > > > > > If we don't get a build > > > > > error or warning without this patch, does that mean the 'missing' > > > > > headers are actually included indirectly? > > > > > > > > I might be missing something, but I do not see any build error in the above message. > > > Hmm, then I think I will take the second patch only. > > > > Thanks, but can you shed a light why? > > > > The rule of thumb is to include the headers we are direct users of, we have not > > to imply any other inclusions done by others, unless it's kinda same family of > > headers (like types.h always includes compiler_types.h). Since in your case > > the const.h is included the other two are missing and it's even worse, as I > > understand you rely on the specific headers to be included _before_ using this > > one in the users. > I agree with you more or less, but I doubt there is another rule: no > break, no fix. Please see: > > https://lore.kernel.org/loongarch/20221024070105.306280-1-chenhuacai@loongson.cn/T/#t > > Obviously static_key is used in page-flags.h and it really causes > build errors once before, but at last I removed the inclusion of > static_key.h to get that series merged. This is strange requirement to be honest. Doing like this is to move your responsibility and understanding of the code to be a burden of the person who volunteers cleaning up the header mess we have in the Linux kernel source tree. Since I'm the one who tries to fix some mess (in particular kernel.h), I am pretty much know what I am talking about from the experience. Cc'ing Guo. Guo, can you shed a light on the rationale of your comment in the above mentioned thread? -- With Best Regards, Andy Shevchenko