Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751766AbdG1Aam (ORCPT ); Thu, 27 Jul 2017 20:30:42 -0400 Received: from mga05.intel.com ([192.55.52.43]:54653 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751750AbdG1Aak (ORCPT ); Thu, 27 Jul 2017 20:30:40 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,422,1496127600"; d="scan'208";a="132894500" From: "Mani, Rajmohan" To: Andy Shevchenko , Lee Jones CC: "linux-kernel@vger.kernel.org" , "linux-gpio@vger.kernel.org" , "linux-acpi@vger.kernel.org" , Linus Walleij , Alexandre Courbot , "Rafael J. Wysocki" , Len Brown , "sakari.ailus@linux.intel.com" Subject: RE: [PATCH v4 1/3] mfd: Add new mfd device TPS68470 Thread-Topic: [PATCH v4 1/3] mfd: Add new mfd device TPS68470 Thread-Index: AQHTAOa9zEd+focor0e+zW969r8dYKJc4YQAgACTgJCAB0orAIAAFhaAgAFvEwCAACJ9AIAB8XnA Date: Fri, 28 Jul 2017 00:30:39 +0000 Message-ID: <6F87890CF0F5204F892DEA1EF0D77A59725DF8D6@FMSMSX114.amr.corp.intel.com> References: <1500506426-3047-1-git-send-email-rajmohan.mani@intel.com> <1500506426-3047-2-git-send-email-rajmohan.mani@intel.com> <20170720090300.ayx5pz5l4yntefpt@dell> <6F87890CF0F5204F892DEA1EF0D77A59725DD60A@FMSMSX114.amr.corp.intel.com> <20170725091012.3hpxihekht2j35xb@dell> <20170726082304.7j4lbvsuyyu7owqy@dell> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.1.200.108] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v6S0UlcK027219 Content-Length: 2247 Lines: 59 Hi Lee, Andy, > Subject: Re: [PATCH v4 1/3] mfd: Add new mfd device TPS68470 > > On Wed, Jul 26, 2017 at 11:23 AM, Lee Jones wrote: > > On Tue, 25 Jul 2017, Andy Shevchenko wrote: > >> On Tue, Jul 25, 2017 at 12:10 PM, Lee Jones wrote: > > >> I briefly checked few ->read() and ->write() implementations and > >> didn't find any evidence of positive numbers that can be returned. > >> Documentation (kernel doc) doesn't shed a light on that. So, to me it > >> sounds unspecified. > >> > >> So, for now (until documentation will be fixed) I would rely on if > >> (ret < 0) > > > > It's not unspecified. The regmap methods call into regcache_write(), > > where the kerneldoc is clear. > Since, we are interested in the regmap for the I2C bus here, I looked into the implementation of __devm_regmap_init() __regmap_init() regcache_init() for I2C bus. At the end of __devm_regmap_init() call from devm_regmap_init_i2c() inside tps68470_probe(), I see that both cache_bypass and defer_caching flags of i2c regmap struct are set. So, it looks regcache_write/read calls do not come into play here. So, regmap_write() _regmap_write() map->reg_write (drivers/base/regmap/regmap.c:1665) translates to regmap_i2c_write(drivers/base/regmap/regmap-i2c.c:128) These checks in regmap_i2c_write() ensure all return values from i2c_master_send() other than the requested number of bytes to write, are converted into negative values. if (ret == count) return 0; else if (ret < 0) return ret; else return -EIO; Similar argument goes for regmap_read() as well. With that, for regmap over I2C bus, it sounds like 'if (ret < 0)' looks to be a better choice. Please see if I missed anything here. > drivers/base/regmap/regcache.c:266 > > " * Return a negative value on failure, 0 on success." > > I can hardly find this any cleaner than "unspecified". > > > Perhaps we can also change the regmap kerneldoc headers too to match, > > which might lessen the disparity. > > I'm not familiar with the guts of regmap API, so, I would stick with if (ret < 0) > for now until documentation specifies positive return values. > Ack