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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D01FC25B4E for ; Tue, 24 Jan 2023 13:02:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233728AbjAXNCu (ORCPT ); Tue, 24 Jan 2023 08:02:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38526 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233660AbjAXNCs (ORCPT ); Tue, 24 Jan 2023 08:02:48 -0500 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 12A2E7DAE for ; Tue, 24 Jan 2023 05:02:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1674565367; x=1706101367; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=A/uTpm/OkUDfvq247JLo9eTUq9QvMLpXKnQ6arYeX4U=; b=kaYMbikGfD+h+j4T1jFciFq1e9dUvXol53n9piDDLrMiA3faSISbCtj9 F7Gd85gT3/euSeS67dvIKDfUNsAjSwFMHrkVIr/GuGi2yLGB42rjIM3Sh 621lj/U+SkMZCuo3l9tzTnQgEiTSlpKtXCW6+UOrtTl6A8ipjTkL1pKvy 8Yxy7xUwZ39IuBSPH6/TtDW1p6OebhXtxt1rDdqk3lhe9ypwVU+54JIE+ jG156gjXsBNdACBOTZ/U7NGtyQCbYUg0FR5B8dRikwfyEngH57qgmfeYS Fg4fz3V/GJxC5pFSuesYe0QYPtdhDDgds3VfB9fyE+xauhb0V9iV1z4lV w==; X-IronPort-AV: E=McAfee;i="6500,9779,10599"; a="412519539" X-IronPort-AV: E=Sophos;i="5.97,242,1669104000"; d="scan'208";a="412519539" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jan 2023 05:02:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10599"; a="655414151" X-IronPort-AV: E=Sophos;i="5.97,242,1669104000"; d="scan'208";a="655414151" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga007.jf.intel.com with ESMTP; 24 Jan 2023 05:02:43 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1pKIwj-00ELgp-2j; Tue, 24 Jan 2023 15:02:41 +0200 Date: Tue, 24 Jan 2023 15:02:41 +0200 From: Andy Shevchenko To: Jarkko Nikula Cc: Shyam Sundar S K , Mika Westerberg , Jan Dabros , linux-i2c@vger.kernel.org Subject: Re: [PATCH v1] i2c: designware: Change from u32 to unsigned int for regmap_read() calls Message-ID: References: <20230124114732.1387997-1-Shyam-sundar.S-k@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-i2c@vger.kernel.org On Tue, Jan 24, 2023 at 02:54:52PM +0200, Jarkko Nikula wrote: > On 1/24/23 13:47, Shyam Sundar S K wrote: > > regmap_read() API signature expects the caller to send "unsigned int" > > type to return back the read value, but there are some occurrences of 'u32' > > across i2c-designware-* files. > > > > Change them to match the regmap_read() signature. ... > Hmm.. I'm not sure about these. We know registers are 32-bit and change to > unsigned int is a step being more ambiguous. I'm wearing my old embedded > developer hat who likes to see explicit types when dealing with HW. > > Andy: what was your rationale to propose changing u32 to unsigned int in > another i2c-designware patch? Has gcc started complaining if regmap_read() > is used with u32 type? To be the same type as regmap API is expecting. What you are talking about makes sense for the direct IO accessor calls. Actually something like this had to be done when driver was converted to regmap APIs. Here we might have 16-bit registers, they are fine when variable is u32, but goes over boundaries if we declare it as u16. So unsigned int makes more sense to me. OTOH I agree that this change is subjective since there is no functional or other changes as long as we have unsigned int == u32. So, up to you, guys. But I'm fine with the change. -- With Best Regards, Andy Shevchenko