linux-kernel - Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAEnQRZCzkq5wFsS7Ydby+bsFJTbGVq=AX9TLkkhfMKOG8gAZHA@mail.gmail.com>
Date:	Wed, 10 Feb 2016 14:56:05 +0200
From:	Daniel Baluta <daniel.baluta@...el.com>
To:	Sricharan <sricharan@...eaurora.org>
Cc:	Michael Welling <mwelling@...e.org>,
	Wolfram Sang <wsa@...-dreams.de>,
	Daniel Baluta <daniel.baluta@...el.com>,
	Jonathan Cameron <jic23@...nel.org>,
	Hartmut Knaack <knaack.h@....de>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Peter Meerwald-Stadler <pmeerw@...erw.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
	Lucas De Marchi <lucas.demarchi@...el.com>,
	Andy Gross <agross@...eaurora.org>,
	Pramod Gurav <pramod.gurav@...rtplayin.com>,
	Bjorn Andersson <bjorn.andersson@...ymobile.com>,
	Guenter Roeck <linux@...ck-us.net>, eibach@...ys.de,
	linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support

<snap headers>

>> > > > > > >> +static int ads1015_read_raw(struct iio_dev *indio_dev,
>> > > > > > >> +                         struct iio_chan_spec const *chan,
>> > > > > > >> +int
>> > *val,
>> > > > > > >> +                         int *val2, long mask) {
>> > > > > > >> +     int ret, idx;
>> > > > > > >> +     struct ads1015_data *data = iio_priv(indio_dev);
>> > > > > > >> +
>> > > > > > >> +     mutex_lock(&data->lock);
>> > > > > > >> +     switch (mask) {
>> > > > > > >> +     case IIO_CHAN_INFO_RAW:
>> > > > > > >> +             if (iio_buffer_enabled(indio_dev)) {
>> > > > > > >> +                     ret = -EBUSY;
>> > > > > > >> +                     break;
>> > > > > > >> +             }
>> > > > > > >> +
>> > > > > > >> +             ret = ads1015_set_power_state(data, true);
>> > > > > > >> +             if (ret < 0)
>> > > > > > >> +                     break;
>> > > > > > >
>> > > > > > > Just tested the driver on a Dragonboard 410C with a robotics
>> > > > > > > mezzanine that I designed.
>> > > > > > >
>> > > > > > > The above ads1015_set_power_state(data, true) is always
>> > > > > > > returning
>> > -
>> > > EINVAL.
>> > > > > > >
>> > > > > > > Any ideas why that would be happening?
>> > > > > > > I think it may be the return from pm_runtime_get_sync?
>> > > > > >
>> > > > > > Can you confirm that pm_runtime_get_sync fails? Using some
>> printk?
>> > > > > >
>> > > > > > Also adding printks in suspend/resume function would be helpful.
>> > > > > > Do you have CONFIG_PM enabled?
>> > > > > >
>> > > > >
>> > > > > Indeed it is the pm_runtime_get_sync that fails with a -EINVAL.
>> > > > >
>> > > > > > >
>> > > > > > > When I comment out the break the readings come back but are
>> > > > > > > not
>> > > updated continually.
>> > > > > > > If I read in_voltage0-voltage1_raw then in_voltage0_raw the
>> > > > > > > value
>> > is
>> > > updated.
>> > > > > >
>> > > > > > I guess this is normal if set_power_state fails.
>> > > > >
>> > > > > The hwmod driver works fine BTW.
>> > > > >
>> > > > > My guess is there is an issue with the qup i2c driver seeing as
>> > > > > it has worked on other system without issue.
>> > > > >
>> > > > > CC'd some the latest developer on the qup i2c driver.
>> > > > >
>> > > > > I2C guys have any ideas on this?
>> > > > >
>> > > >
>> > > > Adding some more people who recently worked on this. Might be nice
>> > > > to know which kernel version you are using.
>> > > >
>> >  Which i2c bus is this connected to ? I can give a try with 410c to
>> > see why pm_runtime_get_sync from qup  fails.
>>
>> It is on the lowspeed header. Here is my devicetree entry:
>>
>>                  i2c@...6000 {
>>                  /* On Low speed expansion */
>>                          label = "LS-I2C0";
>>                          status = "okay";
>>
>>                          pca: pca@40 {
>>                                  compatible = "nxp,pca9685-pwm";
>>                                  #pwm-cells = <2>;
>>                                  reg = <0x40>;
>>                          };
>>
>>                          adc: adc@48 {
>>                                  compatible = "ti,ads1015";
>>                                  reg = <0x48>;
>>                          };
>>                  };
>
> Whats the sequence in which the failure happens ?
>
> I tested on DB410c by adding the DT entry that you mentioned above on
> 4.5-rc2 and rc3.
> I see that the i2c transfers call from pca9685  during  pca9685_pwm_probe
> did
> go through and no failure from pm_runtime_get_sync

Hi Sricharan,

Are you looking at pca9685_pwm_probe in drivers/pwm/pwm-pca9685.c right?

I'm asking this because this driver doesn't seem to support runtime
pm and there is no check for regmap_write/regmap_write return
code in the probe function.


Daniel.