linux-kernel - Re: [PATCH v9 2/2] iio: adc: ad4130: add AD4130 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] [day] [month] [year] [list]
Message-ID: <20221020180743.00000416@huawei.com>
Date:   Thu, 20 Oct 2022 18:07:43 +0100
From:   Jonathan Cameron <Jonathan.Cameron@...wei.com>
To:     Cosmin Tanislav <demonsingur@...il.com>
CC:     Jonathan Cameron <jic23@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        <linux-iio@...r.kernel.org>, <linux-gpio@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
        Cosmin Tanislav <cosmin.tanislav@...log.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>
Subject: Re: [PATCH v9 2/2] iio: adc: ad4130: add AD4130 driver

On Mon, 17 Oct 2022 10:08:10 +0300
Cosmin Tanislav <demonsingur@...il.com> wrote:

> On 10/9/22 20:31, Jonathan Cameron wrote:
> > On Thu,  6 Oct 2022 17:07:37 +0300
> > Cosmin Tanislav <demonsingur@...il.com> wrote:
> >   
> >> AD4130-8 is an ultra-low power, high precision, measurement solution for
> >> low bandwidth battery operated applications.
> >>
> >> The fully integrated AFE (Analog Front-End) includes a multiplexer for up
> >> to 16 single-ended or 8 differential inputs, PGA (Programmable Gain
> >> Amplifier), 24-bit Sigma-Delta ADC, on-chip reference and oscillator,
> >> selectable filter options, smart sequencer, sensor biasing and excitation
> >> options, diagnostics, and a FIFO buffer.
> >>
> >> Signed-off-by: Cosmin Tanislav <cosmin.tanislav@...log.com>
> >> Reviewed-by: Andy Shevchenko <andy.shevchenko@...il.com>  
> > Hi Cosmin,
> > 
> > I've cropped down (mostly) to the clock changes.
> > A few minor things in there + this looks like it would suffer from the issue
> > with IIO_CONST_ATTR() not being handled correctly for buffer attributes.
> > 
> > Jonathan
> > 
> > 
> >   
> >> +static IIO_CONST_ATTR(hwfifo_watermark_min, "1");
> >> +static IIO_CONST_ATTR(hwfifo_watermark_max, __stringify(AD4130_FIFO_SIZE));  
> > 
> > These look like they'd suffer from same problem
> > https://lore.kernel.org/all/cover.1664782676.git.mazziesaccount@gmail.com/
> > tackles.  Short term fix is don't use IIO_CONST_ATTR for buffer attributes.
> >   
> 
> Right, this only works downstream.
> 
> Should I switch to IIO_STATIC_CONST_DEVICE_ATTR?

Depends a bit on timing. For now I'd just put a hand coded equivalent here similar
to the patches I've queue in fixes-togreg.  Then we can roll this over
to IIO_STATIC_CONST_DEVICE_ATTR once that code lands.

> 
> >   
> >> +static IIO_DEVICE_ATTR_RO(hwfifo_watermark, 0);
> >> +static IIO_DEVICE_ATTR_RO(hwfifo_enabled, 0);
> >> +
> >> +static const struct attribute *ad4130_fifo_attributes[] = {
> >> +	&iio_const_attr_hwfifo_watermark_min.dev_attr.attr,
> >> +	&iio_const_attr_hwfifo_watermark_max.dev_attr.attr,
> >> +	&iio_dev_attr_hwfifo_watermark.dev_attr.attr,
> >> +	&iio_dev_attr_hwfifo_enabled.dev_attr.attr,
> >> +	NULL
> >> +};  
> > 
> >   
> >> +static void ad4130_clk_disable_unprepare(void *clk)
> >> +{
> >> +	clk_disable_unprepare(clk);
> >> +}
> >> +
> >> +static int ad4130_set_mclk_sel(struct ad4130_state *st,
> >> +			       enum ad4130_mclk_sel mclk_sel)
> >> +{
> >> +	return regmap_update_bits(st->regmap, AD4130_ADC_CONTROL_REG,
> >> +				 AD4130_ADC_CONTROL_MCLK_SEL_MASK,
> >> +				 FIELD_PREP(AD4130_ADC_CONTROL_MCLK_SEL_MASK,
> >> +					    mclk_sel));
> >> +}
> >> +
> >> +static unsigned long ad4130_int_clk_recalc_rate(struct clk_hw *hw,
> >> +						unsigned long parent_rate)
> >> +{
> >> +	return AD4130_MCLK_FREQ_76_8KHZ;
> >> +}
> >> +
> >> +static int ad4130_int_clk_is_enabled(struct clk_hw *hw)
> >> +{
> >> +	struct ad4130_state *st = container_of(hw, struct ad4130_state, int_clk_hw);
> >> +
> >> +	return st->mclk_sel == AD4130_MCLK_76_8KHZ_OUT;
> >> +}
> >> +
> >> +static int ad4130_int_clk_prepare(struct clk_hw *hw)
> >> +{
> >> +	struct ad4130_state *st = container_of(hw, struct ad4130_state, int_clk_hw);
> >> +	int ret;
> >> +
> >> +	ret = ad4130_set_mclk_sel(st, AD4130_MCLK_76_8KHZ_OUT);
> >> +	if (ret)
> >> +		return ret;
> >> +
> >> +	st->mclk_sel = AD4130_MCLK_76_8KHZ_OUT;
> >> +
> >> +	return 0;
> >> +}
> >> +
> >> +static void ad4130_int_clk_unprepare(struct clk_hw *hw)
> >> +{
> >> +	struct ad4130_state *st = container_of(hw, struct ad4130_state, int_clk_hw);
> >> +	int ret;
> >> +
> >> +	ret = ad4130_set_mclk_sel(st, AD4130_MCLK_76_8KHZ);
> >> +	if (ret)
> >> +		return;
> >> +
> >> +	st->mclk_sel = AD4130_MCLK_76_8KHZ;
> >> +}
> >> +
> >> +static const struct clk_ops ad4130_int_clk_ops = {
> >> +	.recalc_rate = ad4130_int_clk_recalc_rate,
> >> +	.is_enabled = ad4130_int_clk_is_enabled,
> >> +	.prepare = ad4130_int_clk_prepare,
> >> +	.unprepare = ad4130_int_clk_unprepare,
> >> +};
> >> +
> >> +static int ad4130_setup_int_clk(struct ad4130_state *st)
> >> +{
> >> +	struct device *dev = &st->spi->dev;
> >> +	struct device_node *of_node = dev->of_node;  
> > 
> > Hmm. There goes our careful use of generic firmware properties.
> > I guess there still isn't much we can do about that for clks
> > so at least it's contained to this one function.
> > 
> > Also is this code safe to of_node == NULL?
> >   
> 
> No, I guess it is not. I'll fix it.
> Should I just
> if (!of_node) return 0;
> ?

Good question.  I guess we are fine just not having the output clock
on ACPI platforms.  Maybe this is worth a dev_info message
to say we are carrying on without them?

> 
> >> +	struct clk_init_data init;
> >> +	const char *clk_name;
> >> +	struct clk *clk;
> >> +
> >> +	if (st->int_pin_sel == AD4130_INT_PIN_CLK ||
> >> +	    st->mclk_sel != AD4130_MCLK_76_8KHZ)
> >> +		return 0;
> >> +
> >> +	clk_name = of_node->name;
> >> +	of_property_read_string(of_node, "clock-output-names", &clk_name);  
> > 
> > Probably want to check success of that read before using it.
> > I'd also expect that these to be optional + doesn't he dt binding need
> > updating to add this stuff?
> >   
> 
> It does need updating, sorry.
> of_node->name is the default clk_name, if clock-output-names is present
> then the of_property_read_string() result will be used instead. If not,
> there's no trouble, and we don't care about the return value since we
> have the default clk_name assigned just above.
> I can also switch to device_property_read_string() here to minimize the
> damage from using OF.

Sounds good to me.

Jonathan

> 
> >   
> >> +
> >> +	init.name = clk_name;
> >> +	init.ops = &ad4130_int_clk_ops;
> >> +
> >> +	st->int_clk_hw.init = &init;
> >> +	clk = devm_clk_register(dev, &st->int_clk_hw);
> >> +	if (IS_ERR(clk))
> >> +		return PTR_ERR(clk);
> >> +
> >> +	return of_clk_add_provider(of_node, of_clk_src_simple_get, clk);
> >> +}
> >> +