| 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
| ||
|
Date: Tue, 24 Mar 2020 18:33:31 +0200
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>,
Stephen Boyd <sboyd@...eaurora.org>,
Jonathan Cameron <Jonathan.Cameron@...wei.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>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
linux-arm-msm@...r.kernel.org,
linux-iio <linux-iio@...r.kernel.org>,
linux-arm-msm-owner@...r.kernel.org
Subject: Re: [PATCH 3/3] iio: adc: Add support for PMIC7 ADC
On Tue, Mar 24, 2020 at 5:46 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.
>
> In addition, add definitions for ADC channels and virtual channel
> definitions per PMIC, to be used by ADC clients for PMIC7.
...
> +#define ADC_CHANNEL_OFFSET 0x8
> +#define ADC_CHANNEL_MASK 0xff
GENMASK()
...
> +#define ADC_APP_SID 0x40
> +#define ADC_APP_SID_MASK 0xf
GENMASK()
> +#define ADC7_CONV_TIMEOUT msecs_to_jiffies(10)
Useless.
...
> + buf[1] &= (u8) ~ADC5_USR_FAST_AVG_CTL_SAMPLES_MASK;
Use '0xFF ^ _MASK' instead of casting.
...
> + buf[3] &= (u8) ~ADC5_USR_HW_SETTLE_DELAY_MASK;
Ditto.
...
> + ret = adc5_write(adc, ADC5_USR_CONV_REQ, &conv_req, 1);
> +
> + return ret;
return adc5_write(...);
...
> + pr_err("ADC configure failed with %d\n", ret);
Use dev_*() instead everywhere.
...
> + /* No support for polling mode at present*/
> + wait_for_completion_timeout(&adc->complete,
> + ADC7_CONV_TIMEOUT);
One line. The limit is 80 and it can be bend in some cases a little bit.
...
> + v_channel = ((adc->chan_props[i].sid << ADC_CHANNEL_OFFSET) |
> + adc->chan_props[i].channel);
Too many parentheses.
...
> + sid = (chan >> ADC_CHANNEL_OFFSET);
> + chan = (chan & ADC_CHANNEL_MASK);
Ditto.
...
> + (adc->is_pmic7))
Ditto.
...
> + if (of_device_is_compatible(node, "qcom,spmi-adc7")) {
> + indio_dev->info = &adc7_info;
> + adc->is_pmic7 = true;
> + } else {
> + indio_dev->info = &adc5_info;
> + }
Hmm... I would rather put this as driver_data in ID structure(s).
...
> +static int adc5_exit(struct platform_device *pdev)
> +{
> + struct adc5_chip *adc = platform_get_drvdata(pdev);
> +
> + mutex_destroy(&adc->lock);
Are you sure you will have no race conditions? Does this driver use IRQs?
> + return 0;
> +}
...
> + s64 resistance = 0;
= adc_code // or sign extended variant if needed.
> + /* (ADC code * R_PULLUP (100Kohm)) / (full_scale_code - ADC code)*/
> + resistance = (s64) adc_code * R_PU_100K;
> + resistance = div64_s64(resistance, (RATIO_MAX_ADC7 - adc_code));
resistance *= R_PU_100K;
resistance = div64_s64(resistance, RATIO_MAX_ADC7 - adc_code);
...
> + int voltage, vtemp0, temp, i = 0;
> + while (i < ARRAY_SIZE(adcmap7_die_temp)) {
> + if (adcmap7_die_temp[i].x > voltage)
> + break;
> + i++;
> + }
for loop (one line less, more explicit initial value assignment)?
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists