| 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
| ||
|
Message-ID: <66d670d6-0374-88ae-c4c1-efd60b54bbd2@gmail.com>
Date: Sat, 7 Aug 2021 23:04:18 +0530
From: Mugilraj Dhavachelvan <dmugil2000@...il.com>
To: Lars-Peter Clausen <lars@...afoo.de>, Dragos.Bogdan@...log.com,
Darius.Berghe@...log.com, Rob Herring <robh+dt@...nel.org>,
Jonathan Cameron <jic23@...nel.org>,
Michael Hennerich <Michael.Hennerich@...log.com>,
Guenter Roeck <linux@...ck-us.net>,
Chris Packham <chris.packham@...iedtelesis.co.nz>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Krzysztof Kozlowski <krzk@...nel.org>,
Alexandru Ardelean <alexandru.ardelean@...log.com>,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-iio@...r.kernel.org
Subject: Re: [PATCH 2/2] iio: potentiometer: Add driver support for AD5110
Sorry some formatting issues happened in my previous mail.
On 07/08/21 10:56 pm, Mugilraj Dhavachelvan wrote:
>
>
> On 07/08/21 5:41 pm, Lars-Peter Clausen wrote:
>> On 8/7/21 7:08 AM, Mugilraj Dhavachelvan wrote:
>>> The AD5110/AD5112/AD5114 provide a nonvolatile solution
>>> for 128-/64-/32-position adjustment applications, offering
>>> guaranteed low resistor tolerance errors of ±8% and up to
>>> ±6 mA current density.
>>>
>>> Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/AD5110_5112_5114.pdf
>>> Signed-off-by: Mugilraj Dhavachelvan <dmugil2000@...il.com>
>>
>> Thanks for the patch. This looks really good>
>>
>>> [...]
>>>
>>> +static int ad5110_write(struct ad5110_data *data, u8 cmd, u8 val)
>>> +{
>>> + int ret;
>>> +
>>> + mutex_lock(&data->lock);
>>> + data->buf[0] = cmd;
>>> + data->buf[1] = val;
>>> +
>>> + ret = i2c_master_send_dmasafe(data->client, data->buf, sizeof(data->buf));
>>> + mutex_unlock(&data->lock);
>>
>> This returns the number of bytes written, which can be less then the number of bytes requested if there was an error. This should check if the right amount of bytes was written and return -EIO otherwise. Same for the other places that read/write from I2C.
>
> Fixed in v2.
>>
>>> +
>>> + return ret < 0 ? ret : 0;
>>> +}
>>> +
>>> +static int ad5110_resistor_tol(struct ad5110_data *data, u8 cmd, int val)
>>> +{
>>> + int ret;
>>> +
>>> + ret = ad5110_read(data, cmd, &val);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + data->tol = FIELD_GET(GENMASK(6, 3), val);
>>> + data->tol = ((val & GENMASK(2, 0)) * 1000 / 8) + data->tol * 1000;
>>> + data->tol = data->cfg->kohms * data->tol / 100;
>>
>> This is not wrong, but it can be implemented a bit simpler. The tolerance is encoded as a fixed point number, you don't have to treat them as two independent fields, but can treat it as one fixed point number.
>>
>> data->tol = data->cfg->kohms * (val & GENMASK(6, 0)) * 1000 / 100 / 8;
>>
> Great, Fixed in v2.
>>
>>> + if (!(val & BIT(7)))
>>> + data->tol *= -1;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static ssize_t ad5110_eeprom_read(struct device *dev,
>>> + struct device_attribute *attr,
>>> + char *buf)
>>> +{
>>> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>>> + struct ad5110_data *data = iio_priv(indio_dev);
>>> + int val = AD5110_WIPER_POS;
>>> + int ret;
>>> +
>>> + ret = ad5110_read(data, AD5110_EEPROM_RD, &val);
>>> + if (ret)
>>> + return ret;
>> Maybe apply shift to get consistent behavior with `raw`.
> Fixed in v2.
>>> +
>>> + return iio_format_value(buf, IIO_VAL_INT, 1, &val);
>>> +}
>>> +
>>> +static ssize_t ad5110_eeprom_write(struct device *dev,
>>> + struct device_attribute *attr,
>>> + const char *buf, size_t len)
>>> +{
>>> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>>> + struct ad5110_data *data = iio_priv(indio_dev);
>>> + int ret;
>>> +
>>> + ret = ad5110_write(data, AD5110_EEPROM_WR, 0);
>>> + if (ret) {
>>> + dev_err(&data->client->dev, "RDAC to EEPROM write failed\n");
>>> + return ret;
>>> + }
>>> + msleep(20);
>>> +
>>> + return len;
>>> +}
>>> +
>>> +static IIO_DEVICE_ATTR(wiper_pos_eeprom, 0644,
>>> + ad5110_eeprom_read,
>>> + ad5110_eeprom_write, 0);
>> This is new custom ABI and needs to be documented
> I'm not aware of this, fixed in v2.
>>> +static int ad5110_write_raw(struct iio_dev *indio_dev,
>>> + struct iio_chan_spec const *chan,
>>> + int val, int val2, long mask)
>>> +{
>>> + struct ad5110_data *data = iio_priv(indio_dev);
>>> + int ret;
>>> +
>>> + switch (mask) {
>>> + case IIO_CHAN_INFO_RAW:
>>> + if (val >= data->cfg->max_pos || val < 0)
>> val == data->cfg->max_pos is a valid setting. Writing max_pos puts it in top-scale mode which gives maximum resistance.
> Fixed in v2.
>>> + return -EINVAL;
>>> +
>>> + return ad5110_write(data, AD5110_RDAC_WR, val << data->cfg->shift);
>>> + case IIO_CHAN_INFO_ENABLE:
>>> + if (val < 0 || val > 1)
>>> + return -EINVAL;
>>> + if (data->enable == val)
>>> + return 0;
>>> + ret = ad5110_write(data, AD5110_SHUTDOWN, val);
>> Doesn't val have to be inverted to get the right behavior
> I just replicated the datasheet operation.
> You mean,
> 1 - shutdown off
> 0 - shutdown on
> If yes, then the user won't get confused with the datasheet and the behavior of the driver?
> Or Is it work like this? But yeah even I like this change it's more convenient.
>>> + if (ret)
>>> + return ret;
>>> + data->enable = val;
>>> + return 0;
>>> + default:
>>> + return -EINVAL;
>>> + }
>>> +}
>> [...]
> Thanks for feedback!!
>
Powered by blists - more mailing lists