linux-kernel - Re: [PATCH v3 2/2] iio: add MCP4728 I2C DAC driver

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: <20230723124101.1af2ae2c@jic23-huawei>
Date:   Sun, 23 Jul 2023 12:41:01 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Andrea Collamati <andrea.collamati@...il.com>
Cc:     Lars-Peter Clausen <lars@...afoo.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>, linux-iio@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] iio: add MCP4728 I2C DAC driver

On Sun, 23 Jul 2023 07:09:11 +0200
Andrea Collamati <andrea.collamati@...il.com> wrote:

> Hi Jonathan,
> 
> On 7/20/23 21:13, Jonathan Cameron wrote:
> >> +static const char *const mcp4728_vref_modes[] = {
> >> +	"vdd_ext",
> >> +	"internal",
> >> +};
> >> +
> >> +static int mcp4728_get_vref_mode(struct iio_dev *indio_dev,
> >> +				 const struct iio_chan_spec *chan)
> >> +{
> >> +	struct mcp4728_data *data = iio_priv(indio_dev);
> >> +
> >> +	return data->channel_data[chan->channel].ref_mode;
> >> +}
> >> +
> >> +static int mcp4728_set_vref_mode(struct iio_dev *indio_dev,
> >> +				 const struct iio_chan_spec *chan,
> >> +				 unsigned int mode)
> >> +{
> >> +	struct mcp4728_data *data = iio_priv(indio_dev);
> >> +	int ret;
> >> +
> >> +	data->channel_data[chan->channel].ref_mode = mode;
> >> +
> >> +	if (mode == MCP4728_VREF_EXTERNAL_VDD &&
> >> +	    data->channel_data[chan->channel].g_mode == MCP4728_GAIN_X2) {
> >> +		dev_warn(&data->client->dev,
> >> +			 "CH%d: Gain x2 not effective when vref is vdd, force to x1",
> >> +			 chan->channel);  
> > Even better if you don't present the option at all and wrap it up in the
> > standard ABI of _scale
> >  
> I think that the solution could be:
> 
> - Removing custom ABI (vref/gain)
> 
> - Initialize them at device tree level using two 4-elements arrays.

If doing with device tree, they should reflect something that is a characteristic
of how the chips is wired up.  So you would need to explain why that is the case here.

However, I'm still not understanding why _SCALE is not appropriate here.  We have
a small set of options with well defined scales.

> 
> - Finally using the same approach of https://github.com/torvalds/linux/blob/c2782531397f5cb19ca3f8f9c17727f1cdf5bee8/drivers/iio/dac/mcp4725.c#L462 where after having  synced current parameters stored in EEPROM they are updated with the ones specified in dts.
> 
From a quick look those are not coming from DTS and are not in the dt-binding for that
device. The parameters only come from legacy platform data (or the wild west of early IIO).

Only the presence of vref and whether to buffer it are in DT binding
https://elixir.bootlin.com/linux/latest/source/drivers/iio/dac/mcp4725.c#L373

We should probably rip the remaining platform data based probe paths out of drivers
sometime soon. No one uses them any more (there are better paths even if people are
using non DT based board files) and they can mislead because the rules weren't
as tight as they are for what goes in a DT binding.

Jonathan


> 
> Best regards
> 
>                        Andrea
> 
>