Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753224AbdG1XsF (ORCPT ); Fri, 28 Jul 2017 19:48:05 -0400 Received: from mga14.intel.com ([192.55.52.115]:23762 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752987AbdG1XsD (ORCPT ); Fri, 28 Jul 2017 19:48:03 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,428,1496127600"; d="scan'208";a="1156656050" From: "Mani, Rajmohan" To: Andy Shevchenko CC: Lee Jones , "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+zW969r8dYKJc4YQAgACTgJCAB0orAIAAFhaAgAFvEwCAACJ9AIAB8XnAgAEfi4CAAH2wsA== Date: Fri, 28 Jul 2017 23:48:00 +0000 Message-ID: <6F87890CF0F5204F892DEA1EF0D77A59725DFDAC@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> <6F87890CF0F5204F892DEA1EF0D77A59725DF8D6@FMSMSX114.amr.corp.intel.com> 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.107] 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 v6SNmB1S017910 Content-Length: 2338 Lines: 66 Hi Andy, > Subject: Re: [PATCH v4 1/3] mfd: Add new mfd device TPS68470 > > On Fri, Jul 28, 2017 at 3:30 AM, Mani, Rajmohan > wrote: > >> 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. > > It prooves exactly the Lee's point. > > So, perhaps the best approach is to move to if (ret) return ret; > > ...if it will be a problem in the future, fix it accordingly. > Ack. We have spent enough time on this already.