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.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 E2E2EC4361B for ; Mon, 14 Dec 2020 15:31:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AA93E22B2C for ; Mon, 14 Dec 2020 15:31:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2438698AbgLNPa7 (ORCPT ); Mon, 14 Dec 2020 10:30:59 -0500 Received: from mga12.intel.com ([192.55.52.136]:59116 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726321AbgLNPak (ORCPT ); Mon, 14 Dec 2020 10:30:40 -0500 IronPort-SDR: 78DfHj6F2AkDum15ulwjEvESvPK9IgExTqfE0KMsltc2bxCf8uAPzyJ46pQemAGaYXvKoz/+yT sZdmYuv8fsuw== X-IronPort-AV: E=McAfee;i="6000,8403,9834"; a="153956437" X-IronPort-AV: E=Sophos;i="5.78,420,1599548400"; d="scan'208";a="153956437" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Dec 2020 07:28:55 -0800 IronPort-SDR: OPwsMQMavvnOkLnZ56LPyn7D6nn+yVWXLjMMuRKhic8gvmnwEXWCNPBGokfcYN/1iDaM2LVPLt 9bOuV6UByL8g== X-IronPort-AV: E=Sophos;i="5.78,420,1599548400"; d="scan'208";a="487149117" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Dec 2020 07:28:53 -0800 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1kopnP-00EIcQ-3k; Mon, 14 Dec 2020 17:29:55 +0200 Date: Mon, 14 Dec 2020 17:29:55 +0200 From: Andy Shevchenko To: Sakari Ailus Cc: kernel test robot , kbuild-all@lists.01.org, clang-built-linux@googlegroups.com, linux-kernel@vger.kernel.org, Mauro Carvalho Chehab , linux-media@vger.kernel.org Subject: Re: drivers/media/pci/intel/ipu3/ipu3-cio2.c:163:56: warning: implicit conversion from 'unsigned long' to 'u16' (aka 'unsigned short') changes value from 131072 to 0 Message-ID: <20201214152955.GH4077@smile.fi.intel.com> References: <202011211600.bZyprrVg-lkp@intel.com> <20201123104018.GX4077@smile.fi.intel.com> <20201211165614.GC26370@paasikivi.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201211165614.GC26370@paasikivi.fi.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 11, 2020 at 06:56:14PM +0200, Sakari Ailus wrote: > On Mon, Nov 23, 2020 at 12:40:18PM +0200, Andy Shevchenko wrote: > > On Sat, Nov 21, 2020 at 04:23:05PM +0800, kernel test robot wrote: ... > > > All warnings (new ones prefixed by >>): > > > > > > >> drivers/media/pci/intel/ipu3/ipu3-cio2.c:163:56: warning: implicit conversion from 'unsigned long' to 'u16' (aka 'unsigned short') changes value from 131072 to 0 [-Wconstant-conversion] > > > entry[1].second_entry.num_of_pages = CIO2_LOP_ENTRIES * CIO2_MAX_LOPS; > > > ~ ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~ > > > 1 warning generated. > > > > Okay, now we have an interesting case. The IP is quite unlikely be used on > > ARM64, but my patches made the clear picture about use of PAGE_SIZE here. > > > > So, I see at least the following options to mitigate the above, i.e.: > > 1/ reduce driver scope to X86 > > 2/ fix the variables to be wider type to be able to hold PAGE_SIZE > 4k > > 3/ switch to custom PAGE_SIZE / _SHIFT / _MASK and accompanying macros > > > > And I still consider 3/ is silly move because as we see the driver was > > never assumed to work with big page sizes (besides unsigned short type > > here, PAGE_SHIFT and PAGE_MASK in the original code was as is and on ARM64 > > they compiled to 0 values w/o warnings, effectively make the driver > > improperly functioning anyway). > > Apologies for the late answer. > > I think I'd favour the first option. It's not really useful to be able to > compile this elsewhere; as such the driver doesn't do anything special that > would make it prone to breakage through changes elsewhere. > > Would you like to send a patch? :-) Done. -- With Best Regards, Andy Shevchenko