On Thu, Feb 10, 2022 at 05:54:23PM +0000, Jonathan Cameron wrote: > On Mon, 7 Feb 2022 09:34:08 +0530 > Jagath Jog J <jagathjog1996@xxxxxxxxx> wrote: > > > The DS3502 is a 7-bit, nonvolatile digital potentiometer featuring > > an output voltage range of up to 15.5V. > > DS3502 support is implemented into existing ds1803 driver > > > > Datasheet: https://datasheets.maximintegrated.com/en/ds/DS3502.pdf > > > > Signed-off-by: Jagath Jog J <jagathjog1996@xxxxxxxxx> > Hi Jagath, > > Comments inline. Looks pretty clean in the end so this is definitely > the better option than introducing another driver. > > Thanks, > > Jonathan > > > --- > > drivers/iio/potentiometer/Kconfig | 4 +- > > drivers/iio/potentiometer/ds1803.c | 150 +++++++++++++++++++++++------ > > 2 files changed, 120 insertions(+), 34 deletions(-) > > > > diff --git a/drivers/iio/potentiometer/Kconfig b/drivers/iio/potentiometer/Kconfig > > index 832df8da2bc6..1741af33672c 100644 > > --- a/drivers/iio/potentiometer/Kconfig > > +++ b/drivers/iio/potentiometer/Kconfig > > @@ -27,10 +27,10 @@ config AD5272 > > module will be called ad5272. > > > > config DS1803 > > - tristate "Maxim Integrated DS1803 Digital Potentiometer driver" > > + tristate "Maxim Integrated DS1803 and similar Digital Potentiometer driver" > > depends on I2C > > help > > - Say yes here to build support for the Maxim Integrated DS1803 > > + Say yes here to build support for the Maxim Integrated DS1803 and DS3502 > > digital potentiometer chip. > > > > To compile this driver as a module, choose M here: the > > diff --git a/drivers/iio/potentiometer/ds1803.c b/drivers/iio/potentiometer/ds1803.c > > index 20b45407eaac..5e403e3400f7 100644 > > --- a/drivers/iio/potentiometer/ds1803.c > > +++ b/drivers/iio/potentiometer/ds1803.c > > @@ -1,12 +1,15 @@ > > // SPDX-License-Identifier: GPL-2.0-only > > /* > > - * Maxim Integrated DS1803 digital potentiometer driver > > + * Maxim Integrated DS1803 and DS3502 digital potentiometer driver > > I'd stick to and similar wording here. We want to be able > to grep the part number and hit the Kconfig + drivers, but > once is enough for either. "and similar" avoids more churn > than necessary when adding additional parts. In v1 will add "and similar" instead of adding new part. > > > > * Copyright (c) 2016 Slawomir Stepien > > + * Copyright (c) 2022 Jagath Jog J > > * > > * Datasheet: https://datasheets.maximintegrated.com/en/ds/DS1803.pdf > > + * Datasheet: https://datasheets.maximintegrated.com/en/ds/DS3502.pdf > > * > > * DEVID #Wipers #Positions Resistor Opts (kOhm) i2c address > > * ds1803 2 256 10, 50, 100 0101xxx > > + * DS3502 1 128 10 01010xx > > Stick to lowercase for consistency. > Also use tabs for spacing for consistency with existing table entry. will fix this in v1 > > > */ > > > > #include <linux/err.h> > > @@ -16,47 +19,88 @@ > > #include <linux/module.h> > > #include <linux/mod_devicetable.h> > > > > -#define DS1803_MAX_POS 255 > > -#define DS1803_WRITE(chan) (0xa8 | ((chan) + 1)) > > +#define DS1803_WIPER_0 (0xA9) > > Single constants don't need or benefit from being surrounding in > brackets like this. will fix this in v1 > > > +#define DS1803_WIPER_1 (0xAA) > > +#define DS3502_WR_IVR (0x00) > > +#define DS3502_CR (0x02) > > +#define DS3502_MODE0 (0x00) > > +#define DS3502_MODE1 (0x80) > > > > enum ds1803_type { > > DS1803_010, > > DS1803_050, > > DS1803_100, > > + DS3502, > > }; > > > > struct ds1803_cfg { > > + int wipers; > > + int avail[3]; > > int kohms; > > }; > > > > static const struct ds1803_cfg ds1803_cfg[] = { > > - [DS1803_010] = { .kohms = 10, }, > > - [DS1803_050] = { .kohms = 50, }, > > - [DS1803_100] = { .kohms = 100, }, > > + [DS1803_010] = { .wipers = 2, .avail = { 0, 1, 255 }, .kohms = 10, }, > > + [DS1803_050] = { .wipers = 2, .avail = { 0, 1, 255 }, .kohms = 50, }, > > + [DS1803_100] = { .wipers = 2, .avail = { 0, 1, 255 }, .kohms = 100, }, > > + [DS3502] = { .wipers = 1, .avail = { 0, 1, 127 }, .kohms = 10, }, > > +}; > > + > > +struct maxim_potentiometer { > > + const struct iio_chan_spec *channels; > > + u8 num_channels; > > }; > > > > struct ds1803_data { > > struct i2c_client *client; > > + enum ds1803_type chip_type; > > Move this into the ds1803_cfg. > > > const struct ds1803_cfg *cfg; > > + const struct maxim_potentiometer *chip; > > Everything in here should go in ds1803_cfg as well. Will add members of maxim_potentiometer in ds1803_cfg structure in v1 > > > }; > > > > -#define DS1803_CHANNEL(ch) { \ > > - .type = IIO_RESISTANCE, \ > > - .indexed = 1, \ > > - .output = 1, \ > > - .channel = (ch), \ > > - .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \ > > - .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \ > > +#define DS1803_CHANNEL(ch, addr) { \ > > + .type = IIO_RESISTANCE, \ > > + .indexed = 1, \ > > + .output = 1, \ > > + .channel = (ch), \ > > + .address = (addr), \ > > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \ > > + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \ > > + .info_mask_shared_by_type_available = BIT(IIO_CHAN_INFO_RAW), \ > > Adding available is new functionality for the old part. > Good to have but ideally would be in a separate patch (probably before > the main one) I will first add available functionality for old part and send the patch. > > > } > > > > static const struct iio_chan_spec ds1803_channels[] = { > > - DS1803_CHANNEL(0), > > - DS1803_CHANNEL(1), > > + DS1803_CHANNEL(0, DS1803_WIPER_0), > > + DS1803_CHANNEL(1, DS1803_WIPER_1), > > +}; > > + > > +static const struct iio_chan_spec ds3502_channels[] = { > > + { > > + .type = IIO_RESISTANCE, > > + .indexed = 1, > > + .output = 1, > > + .channel = 0, > > + .address = (DS3502_WR_IVR), > > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_ENABLE), > > + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), > > + .info_mask_shared_by_type_available = BIT(IIO_CHAN_INFO_RAW), > > + }, > > +}; > > + > > +static const struct maxim_potentiometer maxim_potentiometer_chips[] = { > > + [DS1803_100] = { > > + .channels = ds1803_channels, > > Very deep indenting. Stick to > This level and reduce the indent of the closing bracket by one > tab. Will avoid deep indenting. > > I would add this information to the existing ds1803_cfg structure. > you will have to duplicate a elements, but you will save on the > complexity of having two chip type related structures. > You will have to reorder the code to make that work cleanly. I will try to add this information into ds1803_cfg structure in v1. > > > + .num_channels = ARRAY_SIZE(ds1803_channels), > > + }, > > + [DS3502] = { > > + .channels = ds3502_channels, > > + .num_channels = ARRAY_SIZE(ds3502_channels), > > + }, > > }; > > > > static int ds1803_read_raw(struct iio_dev *indio_dev, > > - struct iio_chan_spec const *chan, > > - int *val, int *val2, long mask) > > + struct iio_chan_spec const *chan, > > + int *val, int *val2, long mask) > If there are valid white space tidy ups, please do them in > a separate patch as they just distract form the important stuff > ehre. Will send the checkpatch fixes separately. > > > { > > struct ds1803_data *data = iio_priv(indio_dev); > > int pot = chan->channel; > > @@ -65,17 +109,28 @@ static int ds1803_read_raw(struct iio_dev *indio_dev, > > > > switch (mask) { > > case IIO_CHAN_INFO_RAW: > > - ret = i2c_master_recv(data->client, result, > > - indio_dev->num_channels); > > + switch (data->chip_type) { > > + case DS1803_010: > > + case DS1803_050: > > + case DS1803_100: > > + ret = i2c_master_recv(data->client, result, > > + indio_dev->num_channels); > Whilst it doesn't cause problems, as a general rule, you shouldn't use > the output of a function if it has returned an error code. You should > do the > if (ret < 0) > return ret; > which seems have have gotten lost below. > > + *val = result[pot]; > > return IIO_VAL_INT; here Will fix this in v1. > > > + break; > > + case DS3502: > > + ret = i2c_smbus_read_byte_data(data->client, chan->address); > > Preference for 80 char max lines when there is no strong reason to go over. Here > wrapping after client, will not hurt readability significantly. > > > + *val = ret; > > + break; > > return here. Will fix this in v1. > > > + default: > > + return -EINVAL; > > + } > > + > > if (ret < 0) > > return ret; > > - > > - *val = result[pot]; > > return IIO_VAL_INT; > > - > > case IIO_CHAN_INFO_SCALE: > > *val = 1000 * data->cfg->kohms; > > - *val2 = DS1803_MAX_POS; > > + *val2 = data->cfg->avail[2]; > > Probably worth a comment on why [2] is the right option here. Will add comment in v1 > > > return IIO_VAL_FRACTIONAL; > > } > > > > @@ -83,38 +138,64 @@ static int ds1803_read_raw(struct iio_dev *indio_dev, > > } > > > > static int ds1803_write_raw(struct iio_dev *indio_dev, > > - struct iio_chan_spec const *chan, > > - int val, int val2, long mask) > > + struct iio_chan_spec const *chan, > > + int val, int val2, long mask) > > Check for white space only changes like this before sending patches. > They are easy to accidentally introduce but should not be in a patch > doing significant changes like this one. Will send the checkpatch fixes separately first. > > > { > > struct ds1803_data *data = iio_priv(indio_dev); > > - int pot = chan->channel; > > + int max_pos = data->cfg->avail[2]; > > + u8 addr = chan->address; > > > > if (val2 != 0) > > return -EINVAL; > > > > switch (mask) { > > case IIO_CHAN_INFO_RAW: > > - if (val > DS1803_MAX_POS || val < 0) > > + if (val > max_pos || val < 0) > > as max_pos is just used here I would not bother with the local > variable. > > > + return -EINVAL; > > + break; > > + case IIO_CHAN_INFO_ENABLE: > > This doesn't seem to map to enable as it is about whether the > value is written to the initial value register or not. > We may need to invent some new sysfs attributes to cover that > though I'd be a bit surprised if we have no precedence in other > DACs. Sure I will not use enable in next v1. Will wait for mode functionality in new part as it required new sysfs attribute > > > > + if (val == 1) > > + val = DS3502_MODE1; > > + else if (val != DS3502_MODE0) > > return -EINVAL; > > + addr = DS3502_CR; > > In cases like this it's better to assign addr in both > case statements as one is no more of a 'default' than the > other choice. Will use addr in both case statements in v1. > > > break; > > default: > > return -EINVAL; > > } > > > > - return i2c_smbus_write_byte_data(data->client, DS1803_WRITE(pot), val); > > + return i2c_smbus_write_byte_data(data->client, addr, val); > > > +} > > + > > +static int ds1803_read_avail(struct iio_dev *indio_dev, struct iio_chan_spec const *chan, > > + const int **vals, int *type, int *length, long mask) > > +{ > > As mentioned above. This is great, but not strictly about support for > the new part, so it should be a different patch. Will add available functionality for old part and send the patch > > > + struct ds1803_data *data = iio_priv(indio_dev); > > + > > + switch (mask) { > > + case IIO_CHAN_INFO_RAW: > > + *vals = data->cfg->avail; > > + *length = ARRAY_SIZE(data->cfg->avail); > > + *type = IIO_VAL_INT; > > + return IIO_AVAIL_RANGE; > > + } > > + return -EINVAL; > > } > > > > static const struct iio_info ds1803_info = { > > .read_raw = ds1803_read_raw, > > + .read_avail = ds1803_read_avail, > > .write_raw = ds1803_write_raw, > > }; > > > > static int ds1803_probe(struct i2c_client *client, > > - const struct i2c_device_id *id) > > + const struct i2c_device_id *id) > > Another white space change. Fixing up the alignment is a good thing > to do but needs to be in a separate patch. Will send the checkpatch fixes separately. > > > { > > struct device *dev = &client->dev; > > struct ds1803_data *data; > > struct iio_dev *indio_dev; > > + enum ds1803_type chip_type = (id->driver_data <= DS1803_100 ? DS1803_100 : DS3502); > > Why this dance? You have all the models covered by a switch statement anyway. Will fix this in v1 as there will no need to maintain two chip type related structures > > > + const struct maxim_potentiometer *chip = &maxim_potentiometer_chips[chip_type]; > > > > indio_dev = devm_iio_device_alloc(dev, sizeof(*data)); > > if (!indio_dev) > > @@ -125,10 +206,12 @@ static int ds1803_probe(struct i2c_client *client, > > data = iio_priv(indio_dev); > > data->client = client; > > data->cfg = &ds1803_cfg[id->driver_data]; > > Unrelated to this patch, but note that for DT based bindings this relies > on the part after the comma precisely matching the entry in the > i2c_device_id table which is rather fragile. At somepoint we should tidy > this up to first check if there is a firmware provided entry with data > and only if there is not fall back to using id->driver_data if available. > It never is on ACPI platforms for starters. Since firmware provided entry with data is available in this driver I will try to use device_get_match_data to retrive chip specific data. > > > + data->chip = chip; > > Not used anywhere that I can see. Will fix this in v1 > > > + data->chip_type = chip_type; > > > > indio_dev->info = &ds1803_info; > > - indio_dev->channels = ds1803_channels; > > - indio_dev->num_channels = ARRAY_SIZE(ds1803_channels); > > + indio_dev->channels = chip->channels; > > + indio_dev->num_channels = chip->num_channels; > > indio_dev->name = client->name; > > > > return devm_iio_device_register(dev, indio_dev); > > @@ -138,6 +221,7 @@ static const struct of_device_id ds1803_dt_ids[] = { > > { .compatible = "maxim,ds1803-010", .data = &ds1803_cfg[DS1803_010] }, > > { .compatible = "maxim,ds1803-050", .data = &ds1803_cfg[DS1803_050] }, > > { .compatible = "maxim,ds1803-100", .data = &ds1803_cfg[DS1803_100] }, > > + { .compatible = "maxim,ds3502", .data = &ds1803_cfg[DS3502] }, > > {} > > }; > > MODULE_DEVICE_TABLE(of, ds1803_dt_ids); > > @@ -146,6 +230,7 @@ static const struct i2c_device_id ds1803_id[] = { > > { "ds1803-010", DS1803_010 }, > > { "ds1803-050", DS1803_050 }, > > { "ds1803-100", DS1803_100 }, > > + { "ds3502", DS3502 }, > > {} > > }; > > MODULE_DEVICE_TABLE(i2c, ds1803_id); > > @@ -162,5 +247,6 @@ static struct i2c_driver ds1803_driver = { > > module_i2c_driver(ds1803_driver); > > > > MODULE_AUTHOR("Slawomir Stepien <sst@xxxxxxxxx>"); > > -MODULE_DESCRIPTION("DS1803 digital potentiometer"); > > +MODULE_AUTHOR("Jagath Jog J <jagathjog1996@xxxxxxxxx>"); > > +MODULE_DESCRIPTION("DS1803 and DS3502 digital potentiometer"); > > I would use and similar here, or just don't bother changing the > description. It's common for these to not cover all the devices > supported. Will fix this in v1. > > > MODULE_LICENSE("GPL v2"); > Thanks for feedback, First will send checkpatch fixes and new available feature in separate patch for old part then I will try to add new part in v1. Regards, Jagath
