linux-kernel - Re: [PATCH V4 3/5] iio: adc: Add support for PMIC7 ADC

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]

Date:   Wed, 13 May 2020 12:48:07 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Jishnu Prakash <jprakash@...eaurora.org>
Cc:     agross@...nel.org, Bjorn Andersson <bjorn.andersson@...aro.org>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Amit Kucheria <amit.kucheria@...durent.com>,
        smohanad@...eaurora.org, kgunda@...eaurora.org,
        aghayal@...eaurora.org, Jonathan Cameron <jic23@...nel.org>,
        Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        linux-arm-msm@...r.kernel.org,
        linux-iio <linux-iio@...r.kernel.org>,
        linux-arm-msm-owner@...r.kernel.org
Subject: Re: [PATCH V4 3/5] iio: adc: Add support for PMIC7 ADC

On Wed, May 13, 2020 at 12:23 PM Jishnu Prakash <jprakash@...eaurora.org> wrote:
>
> The ADC architecture on PMIC7 is changed as compared to PMIC5. The
> major change from PMIC5 is that all SW communication to ADC goes through
> PMK8350, which communicates with other PMICs through PBS when the ADC
> on PMK8350 works in master mode. The SID register is used to identify the
> PMICs with which the PBS needs to communicate. Add support for the same.

> +#define ADC7_CONV_TIMEOUT                      msecs_to_jiffies(10)

...

> +       ret = adc5_read(adc, ADC5_USR_DIG_PARAM, buf, sizeof(buf));
> +       if (ret < 0)

Is ' < 0' part necessary?
Ditto for same cases in other places in the code.

> +               return ret;

...

> +       switch (mask) {
> +       case IIO_CHAN_INFO_PROCESSED:
> +               ret = adc7_do_conversion(adc, prop, chan,
> +                                       &adc_code_volt, &adc_code_cur);
> +               if (ret)
> +                       return ret;
> +
> +               ret = qcom_adc5_hw_scale(prop->scale_fn_type,
> +                       &adc5_prescale_ratios[prop->prescale],
> +                       adc->data,
> +                       adc_code_volt, val);
> +
> +               if (ret)
> +                       return ret;
> +
> +               return IIO_VAL_INT;
> +       default:
> +               return -EINVAL;
> +       }

> +
> +       return 0;

Dead code?

...

> +static int qcom_vadc7_scale_hw_calib_die_temp(
> +                               const struct vadc_prescale_ratio *prescale,
> +                               const struct adc5_data *data,
> +                               u16 adc_code, int *result_mdec)
> +{
> +
> +       int voltage, vtemp0, temp, i = ARRAY_SIZE(adcmap7_die_temp) - 1;

How assignment to i is useful?

> +       voltage = qcom_vadc_scale_code_voltage_factor(adc_code,
> +                               prescale, data, 1);
> +
> +       if (adcmap7_die_temp[0].x > voltage) {
> +               *result_mdec = DIE_TEMP_ADC7_SCALE_1;
> +               return 0;

> +       } else if (adcmap7_die_temp[i].x <= voltage) {

Redundant 'else'.

> +               *result_mdec = DIE_TEMP_ADC7_MAX;
> +               return 0;
> +       }
> +
> +       for (i = 0; i < ARRAY_SIZE(adcmap7_die_temp); i++)
> +               if (adcmap7_die_temp[i].x > voltage)
> +                       break;
> +
> +       vtemp0 = adcmap7_die_temp[i - 1].x;
> +       voltage = voltage - vtemp0;
> +       temp = div64_s64(voltage * DIE_TEMP_ADC7_SCALE_FACTOR,
> +               adcmap7_die_temp[i - 1].y);
> +       temp += DIE_TEMP_ADC7_SCALE_1 + (DIE_TEMP_ADC7_SCALE_2 * (i - 1));
> +       *result_mdec = temp;
> +
> +       return 0;
> +}

...

> +#define RATIO_MAX_ADC7         0x4000

Hmm... Why the last is in hex? Is it related to amount of bits in the
hardware? Then probably better to use BIT().

-- 
With Best Regards,
Andy Shevchenko