linux-kernel - RE: [PATCH v4 1/3] mfd: Add new mfd device TPS68470

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6F87890CF0F5204F892DEA1EF0D77A59725DFDAC@FMSMSX114.amr.corp.intel.com>
Date:   Fri, 28 Jul 2017 23:48:00 +0000
From:   "Mani, Rajmohan" <rajmohan.mani@...el.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
CC:     Lee Jones <lee.jones@...aro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Alexandre Courbot <gnurou@...il.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>,
        "sakari.ailus@...ux.intel.com" <sakari.ailus@...ux.intel.com>
Subject: RE: [PATCH v4 1/3] mfd: Add new mfd device TPS68470

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
> <rajmohan.mani@...el.com> wrote:
> >> On Wed, Jul 26, 2017 at 11:23 AM, Lee Jones <lee.jones@...aro.org>
> wrote:
> >> > On Tue, 25 Jul 2017, Andy Shevchenko wrote:
> >> >> On Tue, Jul 25, 2017 at 12:10 PM, Lee Jones <lee.jones@...aro.org>
> 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.