Re: [PATCH] staging: iio: cdc: ad7746: Remove unnecessary assignment in ad7746_probe()
On Tue, 18 May 2021 13:16:26 +0300 Dan Carpenter wrote: > On Tue, May 18, 2021 at 05:56:47PM +0800, Tang Bin wrote: > > In the function ad7746_probe(), the initialized value of 'ret' is unused, > > because it will be assigned by the function i2c_smbus_write_byte_data(), > > thus remove it. > > > > Signed-off-by: Tang Bin > > Thanks! > > Reviewed-by: Dan Carpenter > > regards, > dan carpenter > As this doesn't (I think) overlap with Lucas' series I've applied this one to the togreg branch of iio.git and pushed it out as testing for the autobuilders to see if we missed anything. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: cdc: ad7746: Fix unnecessary check andassignment in ad7746_probe()
On Tue, 18 May 2021 17:27:07 +0800 tangbin wrote: > Hi Dan： > > On 2021/5/18 15:52, Dan Carpenter wrote: > > On Mon, May 17, 2021 at 11:00:06PM +0800, Tang Bin wrote: > >> @@ -730,11 +730,7 @@ static int ad7746_probe(struct i2c_client *client, > >>if (ret < 0) > >>return ret; > >> > >> - ret = devm_iio_device_register(indio_dev->dev.parent, indio_dev); > >> - if (ret) > >> - return ret; > >> - > >> - return 0; > >> + return devm_iio_device_register(indio_dev->dev.parent, indio_dev); > >> } > > This sort of thing is done deliberately as a style choice... I probably > > wouldn't have written it that way myself, but there really isn't a > > downside to leaving it as-is. > > > > The unused "int ret = 0;" just introduces a static checker warning about > > unused assignments and disables the static checker warning for > > uninitialized variables so we want to remove that. > > > Got it, I will send this patch for you. I fall a bit different on this and would consider the above a cleanup though one I'd prefer to get with more significant stuff rather than on it's own. However, there is already a patch in revision that includes the same change from Lucas Stankus. > > Thanks > > Tang Bin > > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 78/79] media: hantro: use pm_runtime_resume_and_get()
On Wed, 28 Apr 2021 16:52:39 +0200
Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
> usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
>
> While there's nothing wrong with the current usage on this driver,
> as we're getting rid of the pm_runtime_get_sync() call all over
> the media subsystem, let's remove the last occurrence on this
> driver.
Not sure there is nothing wrong in here before your patch...
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/staging/media/hantro/hantro_drv.c | 23 ---
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/media/hantro/hantro_drv.c
> b/drivers/staging/media/hantro/hantro_drv.c
> index 595e82a82728..25fa36e7e773 100644
> --- a/drivers/staging/media/hantro/hantro_drv.c
> +++ b/drivers/staging/media/hantro/hantro_drv.c
> @@ -56,14 +56,12 @@ dma_addr_t hantro_get_ref(struct hantro_ctx *ctx, u64 ts)
> return hantro_get_dec_buf_addr(ctx, buf);
> }
>
> -static void hantro_job_finish(struct hantro_dev *vpu,
> - struct hantro_ctx *ctx,
> - enum vb2_buffer_state result)
> +static void hantro_job_finish_no_pm(struct hantro_dev *vpu,
> + struct hantro_ctx *ctx,
> + enum vb2_buffer_state result)
> {
> struct vb2_v4l2_buffer *src, *dst;
>
> - pm_runtime_mark_last_busy(vpu->dev);
> - pm_runtime_put_autosuspend(vpu->dev);
> clk_bulk_disable(vpu->variant->num_clocks, vpu->clocks);
>
> src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> @@ -81,6 +79,16 @@ static void hantro_job_finish(struct hantro_dev *vpu,
>result);
> }
>
> +static void hantro_job_finish(struct hantro_dev *vpu,
> + struct hantro_ctx *ctx,
> + enum vb2_buffer_state result)
> +{
> + pm_runtime_mark_last_busy(vpu->dev);
> + pm_runtime_put_autosuspend(vpu->dev);
> +
> + hantro_job_finish_no_pm(vpu, ctx, result);
> +}
> +
> void hantro_irq_done(struct hantro_dev *vpu,
>enum vb2_buffer_state result)
> {
> @@ -155,7 +163,8 @@ static void device_run(void *priv)
> ret = clk_bulk_enable(ctx->dev->variant->num_clocks, ctx->dev->clocks);
> if (ret)
> goto err_cancel_job;
Before your patch, if this error condition happened, we'd call runtime_put
before the related runtime_get... You fixed that, but the patch description
doesn't call it out.
> - ret = pm_runtime_get_sync(ctx->dev->dev);
> +
> + ret = pm_runtime_resume_and_get(ctx->dev->dev);
> if (ret < 0)
> goto err_cancel_job;
>
> @@ -165,7 +174,7 @@ static void device_run(void *priv)
> return;
>
> err_cancel_job:
> - hantro_job_finish(ctx->dev, ctx, VB2_BUF_STATE_ERROR);
> + hantro_job_finish_no_pm(ctx->dev, ctx, VB2_BUF_STATE_ERROR);
> }
>
> static struct v4l2_m2m_ops vpu_m2m_ops = {
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 26/79] staging: media: tegra-video: use pm_runtime_resume_and_get()
On Wed, 28 Apr 2021 16:51:47 +0200
Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
> usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
>
> Use the new API, in order to cleanup the error check logic.
>
> Signed-off-by: Mauro Carvalho Chehab
NOP patch so
Reviewed-by: Jonathan Cameron
> ---
> drivers/staging/media/tegra-video/csi.c | 3 +--
> drivers/staging/media/tegra-video/vi.c | 3 +--
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/media/tegra-video/csi.c
> b/drivers/staging/media/tegra-video/csi.c
> index 033a6935c26d..e938bf4c48b6 100644
> --- a/drivers/staging/media/tegra-video/csi.c
> +++ b/drivers/staging/media/tegra-video/csi.c
> @@ -298,10 +298,9 @@ static int tegra_csi_enable_stream(struct v4l2_subdev
> *subdev)
> struct tegra_csi *csi = csi_chan->csi;
> int ret, err;
>
> - ret = pm_runtime_get_sync(csi->dev);
> + ret = pm_runtime_resume_and_get(csi->dev);
> if (ret < 0) {
> dev_err(csi->dev, "failed to get runtime PM: %d\n", ret);
> - pm_runtime_put_noidle(csi->dev);
> return ret;
> }
>
> diff --git a/drivers/staging/media/tegra-video/vi.c
> b/drivers/staging/media/tegra-video/vi.c
> index 7a09061cda57..1298740a9c6c 100644
> --- a/drivers/staging/media/tegra-video/vi.c
> +++ b/drivers/staging/media/tegra-video/vi.c
> @@ -297,10 +297,9 @@ static int tegra_channel_start_streaming(struct
> vb2_queue *vq, u32 count)
> struct tegra_vi_channel *chan = vb2_get_drv_priv(vq);
> int ret;
>
> - ret = pm_runtime_get_sync(chan->vi->dev);
> + ret = pm_runtime_resume_and_get(chan->vi->dev);
> if (ret < 0) {
> dev_err(chan->vi->dev, "failed to get runtime PM: %d\n", ret);
> - pm_runtime_put_noidle(chan->vi->dev);
> return ret;
> }
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 25/79] staging: media: tegra-vde: use pm_runtime_resume_and_get()
On Fri, 30 Apr 2021 18:08:36 +0100
Jonathan Cameron wrote:
> On Wed, 28 Apr 2021 16:51:46 +0200
> Mauro Carvalho Chehab wrote:
>
> > Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal
> > with usage counter")
> > added pm_runtime_resume_and_get() in order to automatically handle
> > dev->power.usage_count decrement on errors.
> >
> > Use the new API, in order to cleanup the error check logic.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> LGTM
>
> Reviewed-by: Jonathan Cameron
drop that. I missed the misc unwind thing caught in the other review.
Too many patches without a break :(
>
> > ---
> > drivers/staging/media/tegra-vde/vde.c | 19 ---
> > 1 file changed, 16 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/staging/media/tegra-vde/vde.c
> > b/drivers/staging/media/tegra-vde/vde.c
> > index 28845b5bafaf..1cdacb3f781c 100644
> > --- a/drivers/staging/media/tegra-vde/vde.c
> > +++ b/drivers/staging/media/tegra-vde/vde.c
> > @@ -775,9 +775,9 @@ static int tegra_vde_ioctl_decode_h264(struct tegra_vde
> > *vde,
> > if (ret)
> > goto release_dpb_frames;
> >
> > - ret = pm_runtime_get_sync(dev);
> > + ret = pm_runtime_resume_and_get(dev);
> > if (ret < 0)
> > - goto put_runtime_pm;
> > + goto unlock;
> >
> > /*
> > * We rely on the VDE registers reset value, otherwise VDE
> > @@ -843,6 +843,8 @@ static int tegra_vde_ioctl_decode_h264(struct tegra_vde
> > *vde,
> > put_runtime_pm:
> > pm_runtime_mark_last_busy(dev);
> > pm_runtime_put_autosuspend(dev);
> > +
> > +unlock:
> > mutex_unlock(>lock);
> >
> > release_dpb_frames:
> > @@ -1069,11 +1071,17 @@ static int tegra_vde_probe(struct platform_device
> > *pdev)
> > * power-cycle it in order to put hardware into a predictable lower
> > * power state.
> > */
> > - pm_runtime_get_sync(dev);
> > + if (pm_runtime_resume_and_get(dev) < 0)
> > + goto err_pm_runtime;
> > +
> > pm_runtime_put(dev);
> >
> > return 0;
> >
> > +err_pm_runtime:
> > + pm_runtime_dont_use_autosuspend(dev);
> > + pm_runtime_disable(dev);
> > +
> > err_deinit_iommu:
> > tegra_vde_iommu_deinit(vde);
> >
> > @@ -1089,7 +1097,12 @@ static int tegra_vde_remove(struct platform_device
> > *pdev)
> > struct tegra_vde *vde = platform_get_drvdata(pdev);
> > struct device *dev = >dev;
> >
> > + /*
> > +* As it increments RPM usage_count even on errors, we don't need to
> > +* check the returned code here.
> > +*/
> > pm_runtime_get_sync(dev);
> > +
> > pm_runtime_dont_use_autosuspend(dev);
> > pm_runtime_disable(dev);
> >
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 25/79] staging: media: tegra-vde: use pm_runtime_resume_and_get()
On Wed, 28 Apr 2021 16:51:46 +0200
Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
> usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
>
> Use the new API, in order to cleanup the error check logic.
>
> Signed-off-by: Mauro Carvalho Chehab
LGTM
Reviewed-by: Jonathan Cameron
> ---
> drivers/staging/media/tegra-vde/vde.c | 19 ---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/media/tegra-vde/vde.c
> b/drivers/staging/media/tegra-vde/vde.c
> index 28845b5bafaf..1cdacb3f781c 100644
> --- a/drivers/staging/media/tegra-vde/vde.c
> +++ b/drivers/staging/media/tegra-vde/vde.c
> @@ -775,9 +775,9 @@ static int tegra_vde_ioctl_decode_h264(struct tegra_vde
> *vde,
> if (ret)
> goto release_dpb_frames;
>
> - ret = pm_runtime_get_sync(dev);
> + ret = pm_runtime_resume_and_get(dev);
> if (ret < 0)
> - goto put_runtime_pm;
> + goto unlock;
>
> /*
>* We rely on the VDE registers reset value, otherwise VDE
> @@ -843,6 +843,8 @@ static int tegra_vde_ioctl_decode_h264(struct tegra_vde
> *vde,
> put_runtime_pm:
> pm_runtime_mark_last_busy(dev);
> pm_runtime_put_autosuspend(dev);
> +
> +unlock:
> mutex_unlock(>lock);
>
> release_dpb_frames:
> @@ -1069,11 +1071,17 @@ static int tegra_vde_probe(struct platform_device
> *pdev)
>* power-cycle it in order to put hardware into a predictable lower
>* power state.
>*/
> - pm_runtime_get_sync(dev);
> + if (pm_runtime_resume_and_get(dev) < 0)
> + goto err_pm_runtime;
> +
> pm_runtime_put(dev);
>
> return 0;
>
> +err_pm_runtime:
> + pm_runtime_dont_use_autosuspend(dev);
> + pm_runtime_disable(dev);
> +
> err_deinit_iommu:
> tegra_vde_iommu_deinit(vde);
>
> @@ -1089,7 +1097,12 @@ static int tegra_vde_remove(struct platform_device
> *pdev)
> struct tegra_vde *vde = platform_get_drvdata(pdev);
> struct device *dev = >dev;
>
> + /*
> + * As it increments RPM usage_count even on errors, we don't need to
> + * check the returned code here.
> + */
> pm_runtime_get_sync(dev);
> +
> pm_runtime_dont_use_autosuspend(dev);
> pm_runtime_disable(dev);
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 21/79] staging: media: atomisp: use pm_runtime_resume_and_get()
On Wed, 28 Apr 2021 16:51:42 +0200
Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
> usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
>
> Use the new API, in order to cleanup the error check logic.
I'd mention that the origin error handling order was wrong and you've
also fixed that by moving hm_pool_unregister() later.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/staging/media/atomisp/pci/atomisp_fops.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/media/atomisp/pci/atomisp_fops.c
> b/drivers/staging/media/atomisp/pci/atomisp_fops.c
> index f1e6b2597853..26d05474a035 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp_fops.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp_fops.c
> @@ -837,7 +837,7 @@ static int atomisp_open(struct file *file)
> }
>
> /* runtime power management, turn on ISP */
> - ret = pm_runtime_get_sync(vdev->v4l2_dev->dev);
> + ret = pm_runtime_resume_and_get(vdev->v4l2_dev->dev);
> if (ret < 0) {
> dev_err(isp->dev, "Failed to power on device\n");
> goto error;
> @@ -881,9 +881,9 @@ static int atomisp_open(struct file *file)
>
> css_error:
> atomisp_css_uninit(isp);
> -error:
> - hmm_pool_unregister(HMM_POOL_TYPE_DYNAMIC);
> pm_runtime_put(vdev->v4l2_dev->dev);
> +error:
> + hmm_pool_unregister(HMM_POOL_TYPE_DYNAMIC);
> rt_mutex_unlock(>mutex);
> return ret;
> }
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 24/79] staging: media: cedrus_video: use pm_runtime_resume_and_get()
On Wed, 28 Apr 2021 16:51:45 +0200
Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
> usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
>
> Use the new API, in order to cleanup the error check logic.
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Jonathan Cameron
> ---
> drivers/staging/media/sunxi/cedrus/cedrus_video.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> index b62eb8e84057..9ddd789d0b1f 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> @@ -490,11 +490,9 @@ static int cedrus_start_streaming(struct vb2_queue *vq,
> unsigned int count)
> }
>
> if (V4L2_TYPE_IS_OUTPUT(vq->type)) {
> - ret = pm_runtime_get_sync(dev->dev);
> - if (ret < 0) {
> - pm_runtime_put_noidle(dev->dev);
> + ret = pm_runtime_resume_and_get(dev->dev);
> + if (ret < 0)
> goto err_cleanup;
> - }
>
> if (dev->dec_ops[ctx->current_codec]->start) {
> ret = dev->dec_ops[ctx->current_codec]->start(ctx);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 23/79] staging: media: ipu3: use pm_runtime_resume_and_get()
On Wed, 28 Apr 2021 16:51:44 +0200
Mauro Carvalho Chehab wrote:
> Commit dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with
> usage counter")
> added pm_runtime_resume_and_get() in order to automatically handle
> dev->power.usage_count decrement on errors.
>
> Use the new API, in order to cleanup the error check logic.
>
> Signed-off-by: Mauro Carvalho Chehab
Could add that pm_runtime_put() should have been pm_runtime_put_noidle()
inorder to not potentially result in a call to runtime suspend when
we never resumed in the first place.
Otherwise reasonable cleanup.
Reviewed-by: Jonathan Cameron
> ---
> drivers/staging/media/ipu3/ipu3.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/ipu3/ipu3.c
> b/drivers/staging/media/ipu3/ipu3.c
> index ee1bba6bdcac..8e1e9e46e604 100644
> --- a/drivers/staging/media/ipu3/ipu3.c
> +++ b/drivers/staging/media/ipu3/ipu3.c
> @@ -392,10 +392,9 @@ int imgu_s_stream(struct imgu_device *imgu, int enable)
> }
>
> /* Set Power */
> - r = pm_runtime_get_sync(dev);
> + r = pm_runtime_resume_and_get(dev);
> if (r < 0) {
> dev_err(dev, "failed to set imgu power\n");
> - pm_runtime_put(dev);
> return r;
> }
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: ad9832: kernel-doc fixes
On Mon, 15 Mar 2021 19:07:11 +0530 Mugilraj Dhavachelvan wrote: > Fixes a W=1 warning. > -Added ``:`` to lock parameter in 'ad9832_state' description. > -It's a reference comment so removed /** > > Signed-off-by: Mugilraj Dhavachelvan Great. Thanks for tidying this up. Applied to the togreg branch of iio.git and pushed out for testing to let the autobuilders poke at it. thanks Jonathan > --- > drivers/staging/iio/frequency/ad9832.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/iio/frequency/ad9832.c > b/drivers/staging/iio/frequency/ad9832.c > index 74308a2e72db..e31ebba47a3c 100644 > --- a/drivers/staging/iio/frequency/ad9832.c > +++ b/drivers/staging/iio/frequency/ad9832.c > @@ -86,7 +86,7 @@ > * @freq_msg:tuning word spi message > * @phase_xfer: tuning word spi transfer > * @phase_msg: tuning word spi message > - * @lock protect sensor state > + * @lock:protect sensor state > * @data:spi transmit buffer > * @phase_data: tuning word spi transmit buffer > * @freq_data: tuning word spi transmit buffer > @@ -248,7 +248,7 @@ static ssize_t ad9832_write(struct device *dev, struct > device_attribute *attr, > return ret ? ret : len; > } > > -/** > +/* > * see dds.h for further information > */ > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: ad9834: convert to device-managed functions in probe
On Wed, 10 Mar 2021 11:51:31 +0200
Alexandru Ardelean wrote:
> This change converts the driver to use device-managed functions in the
> probe function. For the clock and regulator disable, some
> devm_add_action_or_reset() calls are required, and then
> devm_iio_device_register() function can be used register the IIO device.
>
> The final aim here would be for IIO to export only the device-managed
> functions of it's API. That's a long way to go and this a small step in
> that direction.
>
> Signed-off-by: Alexandru Ardelean
I tweaked this a little to drop st->reg as it's no longer used.
Applied to the togreg branch of iio.git and pushed out as testing for
allow the autobuilders to poke randomly at it.
Thanks,
Jonathan
> ---
> drivers/staging/iio/frequency/ad9834.c | 64 +-
> 1 file changed, 31 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/staging/iio/frequency/ad9834.c
> b/drivers/staging/iio/frequency/ad9834.c
> index 262c3590e64e..b063cfd0e0e1 100644
> --- a/drivers/staging/iio/frequency/ad9834.c
> +++ b/drivers/staging/iio/frequency/ad9834.c
> @@ -390,6 +390,20 @@ static const struct iio_info ad9833_info = {
> .attrs = _attribute_group,
> };
>
> +static void ad9834_disable_reg(void *data)
> +{
> + struct regulator *reg = data;
> +
> + regulator_disable(reg);
> +}
> +
> +static void ad9834_disable_clk(void *data)
> +{
> + struct clk *clk = data;
> +
> + clk_disable_unprepare(clk);
> +}
> +
> static int ad9834_probe(struct spi_device *spi)
> {
> struct ad9834_state *st;
> @@ -407,26 +421,33 @@ static int ad9834_probe(struct spi_device *spi)
> return ret;
> }
>
> + ret = devm_add_action_or_reset(>dev, ad9834_disable_reg, reg);
> + if (ret)
> + return ret;
> +
> indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
> if (!indio_dev) {
> ret = -ENOMEM;
> - goto error_disable_reg;
> + return ret;
> }
> - spi_set_drvdata(spi, indio_dev);
> st = iio_priv(indio_dev);
> mutex_init(>lock);
> st->mclk = devm_clk_get(>dev, NULL);
> if (IS_ERR(st->mclk)) {
> ret = PTR_ERR(st->mclk);
> - goto error_disable_reg;
> + return ret;
> }
>
> ret = clk_prepare_enable(st->mclk);
> if (ret) {
> dev_err(>dev, "Failed to enable master clock\n");
> - goto error_disable_reg;
> + return ret;
> }
>
> + ret = devm_add_action_or_reset(>dev, ad9834_disable_clk, st->mclk);
> + if (ret)
> + return ret;
> +
> st->spi = spi;
> st->devid = spi_get_device_id(spi)->driver_data;
> st->reg = reg;
> @@ -470,48 +491,26 @@ static int ad9834_probe(struct spi_device *spi)
> ret = spi_sync(st->spi, >msg);
> if (ret) {
> dev_err(>dev, "device init failed\n");
> - goto error_clock_unprepare;
> + return ret;
> }
>
> ret = ad9834_write_frequency(st, AD9834_REG_FREQ0, 100);
> if (ret)
> - goto error_clock_unprepare;
> + return ret;
>
> ret = ad9834_write_frequency(st, AD9834_REG_FREQ1, 500);
> if (ret)
> - goto error_clock_unprepare;
> + return ret;
>
> ret = ad9834_write_phase(st, AD9834_REG_PHASE0, 512);
> if (ret)
> - goto error_clock_unprepare;
> + return ret;
>
> ret = ad9834_write_phase(st, AD9834_REG_PHASE1, 1024);
> if (ret)
> - goto error_clock_unprepare;
> -
> - ret = iio_device_register(indio_dev);
> - if (ret)
> - goto error_clock_unprepare;
> -
> - return 0;
> -error_clock_unprepare:
> - clk_disable_unprepare(st->mclk);
> -error_disable_reg:
> - regulator_disable(reg);
> -
> - return ret;
> -}
> -
> -static int ad9834_remove(struct spi_device *spi)
> -{
> - struct iio_dev *indio_dev = spi_get_drvdata(spi);
> - struct ad9834_state *st = iio_priv(indio_dev);
> -
> - iio_device_unregister(indio_dev);
> - clk_disable_unprepare(st->mclk);
> - regulator_disable(st->reg);
> + return ret;
>
> - return 0;
> + return devm_iio_device_register(>dev, indio_dev);
> }
>
> static const struct spi_device_id ad9834_id[] = {
> @@ -539,7 +538,6 @@ static struct spi_driver ad9834_driver = {
> .of_match_table = ad9834_of_match
> },
> .probe = ad9834_probe,
> - .remove = ad9834_remove,
> .id_table = ad9834_id,
> };
> module_spi_driver(ad9834_driver);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [GIT PULL] Staging/IIO driver fixes for 5.11-rc5
On Mon, 25 Jan 2021 15:08:17 +0100 Greg KH wrote: > On Sun, Jan 24, 2021 at 11:31:59AM -0800, Linus Torvalds wrote: > > On Sun, Jan 24, 2021 at 4:58 AM Greg KH wrote: > > > > > > > > David Lechner (1): > > > counter:ti-eqep: remove floor > > > > I'm not sure why that ti-eqep counter driver seems to be in your > > "iio/staging" pile rather than "char/misc", but whatever.. > > Jonathan said why that was needed, I think it was due to fixes in the > counter core code, but he can verify this better than I can... Hi Linus / Greg, Bit of history involved here... The counter drivers started out as just another sensor type under IIO, but ended up pushing the boundaries of the ABI a lot - ultimately making it clear that they really didn't fit in IIO. William came up with a better abstraction / framework that became drivers/counter/, but currently the patch flow for drivers/counter/ is sufficiently low that I handle their patches along side IIO rather than via a separate tree. There is also a cross dependency because of legacy IIO ABI though we are aiming to drop that either this cycle or next. Hope that clears it up. If either of you would prefer it a different way in future let me know. This particular fix was local to the driver - it was pretending it supported something that hardware couldn't actually do. Thanks, Jonathan > > thanks, > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 10/10] iio: adis: Drop non Managed device functions
On Tue, 15 Sep 2020 10:20:20 +
"Sa, Nuno" wrote:
> > -Original Message-
> > From: Jonathan Cameron
> > Sent: Tuesday, September 15, 2020 12:10 PM
> > To: Sa, Nuno
> > Cc: linux-...@vger.kernel.org; de...@driverdev.osuosl.org; Lars-Peter
> > Clausen ; Hennerich, Michael
> > ; Jonathan Cameron ;
> > Hartmut Knaack ; Peter Meerwald-Stadler
> > ; Bogdan, Dragos ;
> > Greg Kroah-Hartman ; Ardelean, Alexandru
> >
> > Subject: Re: [PATCH 10/10] iio: adis: Drop non Managed device functions
> >
> > [External]
> >
> > On Tue, 15 Sep 2020 11:33:45 +0200
> > Nuno Sá wrote:
> >
> > > Drop `adis_setup_buffer_and_trigger()`. All users were updated to use
> > > the devm version of this function. This avoids having almost the same
> > > code repeated.
> > >
> > > Signed-off-by: Nuno Sá
> >
> > Good to see this cleanup, as long as we tidy up the few issues in the
> > earlier patches.
> >
> > Note I think I only commented on first instance of each thing to fix.
> > Please carry them through all the patches.
> >
> > Thanks,
> >
> > Jonathan
>
> So, I did thought about further cleaning the probe functions in order to get
> rid of the remove function but it felt like a different series to me.
> Anyways, since
> it's fine with you to include those changes here I will send a v2.
Understood. Could have been separate, but it feels like trying to use devm
throughout is a good enough theme per patch to combine them. This is
particularly
true as you'd need to do 3 series if you wanted to separate this out without the
ordering issues.
1) Devm stuff before this particular function in probe.
2) This series
3) Devm stuff after the particular function in probe.
Definitely easier to do in one go and still easily reviewed individual patches!
Jonathan
>
> - Nuno Sá
>
> > > ---
> > > drivers/iio/imu/adis_buffer.c | 64 +++---
> > > drivers/iio/imu/adis_trigger.c | 60 ---
> > > include/linux/iio/imu/adis.h | 27 --
> > > 3 files changed, 4 insertions(+), 147 deletions(-)
> > >
> > > diff --git a/drivers/iio/imu/adis_buffer.c b/drivers/iio/imu/adis_buffer.c
> > > index 5b4225ee09b9..df6144285470 100644
> > > --- a/drivers/iio/imu/adis_buffer.c
> > > +++ b/drivers/iio/imu/adis_buffer.c
> > > @@ -169,48 +169,6 @@ static void adis_buffer_cleanup(void *arg)
> > > kfree(adis->xfer);
> > > }
> > >
> > > -/**
> > > - * adis_setup_buffer_and_trigger() - Sets up buffer and trigger for the
> > adis device
> > > - * @adis: The adis device.
> > > - * @indio_dev: The IIO device.
> > > - * @trigger_handler: Optional trigger handler, may be NULL.
> > > - *
> > > - * Returns 0 on success, a negative error code otherwise.
> > > - *
> > > - * This function sets up the buffer and trigger for a adis devices. If
> > > - * 'trigger_handler' is NULL the default trigger handler will be used.
> > > The
> > > - * default trigger handler will simply read the registers assigned to the
> > > - * currently active channels.
> > > - *
> > > - * adis_cleanup_buffer_and_trigger() should be called to free the
> > resources
> > > - * allocated by this function.
> > > - */
> > > -int adis_setup_buffer_and_trigger(struct adis *adis, struct iio_dev
> > *indio_dev,
> > > - irqreturn_t (*trigger_handler)(int, void *))
> > > -{
> > > - int ret;
> > > -
> > > - if (!trigger_handler)
> > > - trigger_handler = adis_trigger_handler;
> > > -
> > > - ret = iio_triggered_buffer_setup(indio_dev,
> > _pollfunc_store_time,
> > > - trigger_handler, NULL);
> > > - if (ret)
> > > - return ret;
> > > -
> > > - if (adis->spi->irq) {
> > > - ret = adis_probe_trigger(adis, indio_dev);
> > > - if (ret)
> > > - goto error_buffer_cleanup;
> > > - }
> > > - return 0;
> > > -
> > > -error_buffer_cleanup:
> > > - iio_triggered_buffer_cleanup(indio_dev);
> > > - return ret;
> > > -}
> > > -EXPORT_SYMBOL_GPL(adis_setup_buffer_and_trigger);
> > > -
> > > /**
> > > * devm_adis_setup_buffer_and_trigger() - Sets up buffer and trigger for
> > > * the managed adis de
Re: [PATCH 10/10] iio: adis: Drop non Managed device functions
On Tue, 15 Sep 2020 11:33:45 +0200
Nuno Sá wrote:
> Drop `adis_setup_buffer_and_trigger()`. All users were updated to use
> the devm version of this function. This avoids having almost the same
> code repeated.
>
> Signed-off-by: Nuno Sá
Good to see this cleanup, as long as we tidy up the few issues in the
earlier patches.
Note I think I only commented on first instance of each thing to fix.
Please carry them through all the patches.
Thanks,
Jonathan
> ---
> drivers/iio/imu/adis_buffer.c | 64 +++---
> drivers/iio/imu/adis_trigger.c | 60 ---
> include/linux/iio/imu/adis.h | 27 --
> 3 files changed, 4 insertions(+), 147 deletions(-)
>
> diff --git a/drivers/iio/imu/adis_buffer.c b/drivers/iio/imu/adis_buffer.c
> index 5b4225ee09b9..df6144285470 100644
> --- a/drivers/iio/imu/adis_buffer.c
> +++ b/drivers/iio/imu/adis_buffer.c
> @@ -169,48 +169,6 @@ static void adis_buffer_cleanup(void *arg)
> kfree(adis->xfer);
> }
>
> -/**
> - * adis_setup_buffer_and_trigger() - Sets up buffer and trigger for the adis
> device
> - * @adis: The adis device.
> - * @indio_dev: The IIO device.
> - * @trigger_handler: Optional trigger handler, may be NULL.
> - *
> - * Returns 0 on success, a negative error code otherwise.
> - *
> - * This function sets up the buffer and trigger for a adis devices. If
> - * 'trigger_handler' is NULL the default trigger handler will be used. The
> - * default trigger handler will simply read the registers assigned to the
> - * currently active channels.
> - *
> - * adis_cleanup_buffer_and_trigger() should be called to free the resources
> - * allocated by this function.
> - */
> -int adis_setup_buffer_and_trigger(struct adis *adis, struct iio_dev
> *indio_dev,
> - irqreturn_t (*trigger_handler)(int, void *))
> -{
> - int ret;
> -
> - if (!trigger_handler)
> - trigger_handler = adis_trigger_handler;
> -
> - ret = iio_triggered_buffer_setup(indio_dev, _pollfunc_store_time,
> - trigger_handler, NULL);
> - if (ret)
> - return ret;
> -
> - if (adis->spi->irq) {
> - ret = adis_probe_trigger(adis, indio_dev);
> - if (ret)
> - goto error_buffer_cleanup;
> - }
> - return 0;
> -
> -error_buffer_cleanup:
> - iio_triggered_buffer_cleanup(indio_dev);
> - return ret;
> -}
> -EXPORT_SYMBOL_GPL(adis_setup_buffer_and_trigger);
> -
> /**
> * devm_adis_setup_buffer_and_trigger() - Sets up buffer and trigger for
> * the managed adis device
> @@ -220,7 +178,10 @@ EXPORT_SYMBOL_GPL(adis_setup_buffer_and_trigger);
> *
> * Returns 0 on success, a negative error code otherwise.
> *
> - * This function perfoms exactly the same as adis_setup_buffer_and_trigger()
> + * This function sets up the buffer and trigger for a adis devices. If
> + * 'trigger_handler' is NULL the default trigger handler will be used. The
> + * default trigger handler will simply read the registers assigned to the
> + * currently active channels.
> */
> int
> devm_adis_setup_buffer_and_trigger(struct adis *adis, struct iio_dev
> *indio_dev,
> @@ -248,20 +209,3 @@ devm_adis_setup_buffer_and_trigger(struct adis *adis,
> struct iio_dev *indio_dev,
> }
> EXPORT_SYMBOL_GPL(devm_adis_setup_buffer_and_trigger);
>
> -/**
> - * adis_cleanup_buffer_and_trigger() - Free buffer and trigger resources
> - * @adis: The adis device.
> - * @indio_dev: The IIO device.
> - *
> - * Frees resources allocated by adis_setup_buffer_and_trigger()
> - */
> -void adis_cleanup_buffer_and_trigger(struct adis *adis,
> - struct iio_dev *indio_dev)
> -{
> - if (adis->spi->irq)
> - adis_remove_trigger(adis);
> - kfree(adis->buffer);
> - kfree(adis->xfer);
> - iio_triggered_buffer_cleanup(indio_dev);
> -}
> -EXPORT_SYMBOL_GPL(adis_cleanup_buffer_and_trigger);
> diff --git a/drivers/iio/imu/adis_trigger.c b/drivers/iio/imu/adis_trigger.c
> index 8afe71947c00..64e0ba51cb18 100644
> --- a/drivers/iio/imu/adis_trigger.c
> +++ b/drivers/iio/imu/adis_trigger.c
> @@ -55,53 +55,6 @@ static int adis_validate_irq_flag(struct adis *adis)
>
> return 0;
> }
> -/**
> - * adis_probe_trigger() - Sets up trigger for a adis device
> - * @adis: The adis device
> - * @indio_dev: The IIO device
> - *
> - * Returns 0 on success or a negative error code
> - *
> - * adis_remove_trigger() should be used to free the trigger.
> - */
> -int adis_probe_trigger(struct adis *adis, struct iio_dev *indio_dev)
> -{
> - int ret;
> -
> - adis->trig = iio_trigger_alloc("%s-dev%d", indio_dev->name,
> - indio_dev->id);
> - if (adis->trig == NULL)
> - return -ENOMEM;
> -
> - adis_trigger_setup(adis);
> -
> - ret = adis_validate_irq_flag(adis);
> - if (ret)
> - return ret;
> -
> - ret = request_irq(adis->spi->irq,
> -
Re: [PATCH 07/10] iio: adis16480: Use Managed device functions
On Tue, 15 Sep 2020 11:33:42 +0200 Nuno Sá wrote: > Use the adis managed device functions to setup the buffer and the trigger. > The ultimate goal will be to completely drop the non devm version from > the lib. > > Signed-off-by: Nuno Sá > --- > drivers/iio/imu/adis16480.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/iio/imu/adis16480.c b/drivers/iio/imu/adis16480.c > index 1eb4f98076f1..b6a129a70d4b 100644 > --- a/drivers/iio/imu/adis16480.c > +++ b/drivers/iio/imu/adis16480.c > @@ -1264,20 +1264,18 @@ static int adis16480_probe(struct spi_device *spi) > st->clk_freq = st->chip_info->int_clk; > } > > - ret = adis_setup_buffer_and_trigger(>adis, indio_dev, NULL); > + ret = devm_adis_setup_buffer_and_trigger(>adis, indio_dev, NULL); > if (ret) > goto error_clk_disable_unprepare; > > ret = iio_device_register(indio_dev); > if (ret) > - goto error_cleanup_buffer; > + goto error_clk_disable_unprepare; > > adis16480_debugfs_init(indio_dev); > > return 0; > > -error_cleanup_buffer: > - adis_cleanup_buffer_and_trigger(>adis, indio_dev); > error_clk_disable_unprepare: > clk_disable_unprepare(st->ext_clk); > error_stop_device: > @@ -1293,7 +1291,6 @@ static int adis16480_remove(struct spi_device *spi) > iio_device_unregister(indio_dev); > adis16480_stop_device(indio_dev); > > - adis_cleanup_buffer_and_trigger(>adis, indio_dev); This change the remove order so that it will not be a reverse of the order seen in probe. Perhaps you can solve that by using devm_add_action_or_reset() calls to handle the few other remaining things in remove? Thanks, Jonathan > clk_disable_unprepare(st->ext_clk); > > return 0; ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 03/10] iio: adis16136: Use Managed device functions
On Tue, 15 Sep 2020 11:33:38 +0200
Nuno Sá wrote:
> Use the adis managed device functions to setup the buffer and the trigger.
> The ultimate goal will be to completely drop the non devm version from
> the lib.
>
> Signed-off-by: Nuno Sá
> ---
> drivers/iio/gyro/adis16136.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iio/gyro/adis16136.c b/drivers/iio/gyro/adis16136.c
> index d8a96f6bbae2..a4b060d9d23f 100644
> --- a/drivers/iio/gyro/adis16136.c
> +++ b/drivers/iio/gyro/adis16136.c
> @@ -552,13 +552,13 @@ static int adis16136_probe(struct spi_device *spi)
> if (ret)
> return ret;
>
> - ret = adis_setup_buffer_and_trigger(>adis, indio_dev, NULL);
> + ret = devm_adis_setup_buffer_and_trigger(>adis, indio_dev,
> NULL);
> if (ret)
> return ret;
>
> ret = adis16136_initial_setup(indio_dev);
> if (ret)
> - goto error_cleanup_buffer;
> + return ret;
>
> ret = iio_device_register(indio_dev);
> if (ret)
> @@ -570,21 +570,16 @@ static int adis16136_probe(struct spi_device *spi)
>
> error_stop_device:
> adis16136_stop_device(indio_dev);
> -error_cleanup_buffer:
> - adis_cleanup_buffer_and_trigger(>adis, indio_dev);
> return ret;
> }
>
> static int adis16136_remove(struct spi_device *spi)
> {
> struct iio_dev *indio_dev = spi_get_drvdata(spi);
> - struct adis16136 *adis16136 = iio_priv(indio_dev);
>
> iio_device_unregister(indio_dev);
> adis16136_stop_device(indio_dev);
As adis16136_stop_device() is always run in remove, I'd suggest using
devm_add_action_or_reset at appropriate place in probe to use
the automated unrolling for that as well, letting you get rid of this
remove function.
>
> - adis_cleanup_buffer_and_trigger(>adis, indio_dev);
> -
> return 0;
> }
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 01/10] iio: adis16201: Use Managed device functions
On Tue, 15 Sep 2020 11:33:36 +0200
Nuno Sá wrote:
> Use the adis managed device functions to setup the buffer and the trigger.
> The ultimate goal will be to completely drop the non devm version from
> the lib.
>
> Signed-off-by: Nuno Sá
> ---
> drivers/iio/accel/adis16201.c | 16 +++-
> 1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/iio/accel/adis16201.c b/drivers/iio/accel/adis16201.c
> index 59a24c355a1a..a375ec25448a 100644
> --- a/drivers/iio/accel/adis16201.c
> +++ b/drivers/iio/accel/adis16201.c
> @@ -281,32 +281,22 @@ static int adis16201_probe(struct spi_device *spi)
> if (ret)
> return ret;
>
> - ret = adis_setup_buffer_and_trigger(st, indio_dev, NULL);
> + ret = devm_adis_setup_buffer_and_trigger(st, indio_dev, NULL);
> if (ret)
> return ret;
>
> ret = adis_initial_startup(st);
> if (ret)
> - goto error_cleanup_buffer_trigger;
> -
> - ret = iio_device_register(indio_dev);
> - if (ret < 0)
> - goto error_cleanup_buffer_trigger;
> -
> - return 0;
> + return ret;
>
> -error_cleanup_buffer_trigger:
> - adis_cleanup_buffer_and_trigger(st, indio_dev);
> - return ret;
> + return iio_device_register(indio_dev);
> }
>
> static int adis16201_remove(struct spi_device *spi)
> {
> struct iio_dev *indio_dev = spi_get_drvdata(spi);
> - struct adis *st = iio_priv(indio_dev);
>
> iio_device_unregister(indio_dev);
If all you have left in remove is a call to iio_device_unregister()
why not just use devm_iio_device_register in probe and drop the
remove function entirely?
> - adis_cleanup_buffer_and_trigger(st, indio_dev);
>
> return 0;
> }
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -v2] Staging: iio: Fixed a punctuation and a spelling mistake.
On Wed, 29 Jul 2020 13:38:28 +0300 Andy Shevchenko wrote: > On Wed, Jul 29, 2020 at 11:12 AM Ankit Baluni > wrote: > > > > Added a missing comma and changed 'it it useful' to 'it is useful'. > > Reviewed-by: Andy Shevchenko Gah. I had kind of forgotten these docs existed and they have rotted pretty badly from a quick glance. Sometime soon I'll take a look and see if there is anything worth moving over to the main docs. In meantime, nothing wrong with cleaning them up a little as you Ankit has done here. Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to ignore them. Thanks, Jonathan > > > Signed-off-by: Ankit Baluni > > --- > > Changes in -v2: > > -Remove space before ':' in subject line. > > > > drivers/staging/iio/Documentation/overview.txt | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/staging/iio/Documentation/overview.txt > > b/drivers/staging/iio/Documentation/overview.txt > > index ebdc64f451d7..00409d5dab4e 100644 > > --- a/drivers/staging/iio/Documentation/overview.txt > > +++ b/drivers/staging/iio/Documentation/overview.txt > > @@ -9,7 +9,7 @@ The aim is to fill the gap between the somewhat similar > > hwmon and > > input subsystems. Hwmon is very much directed at low sample rate > > sensors used in applications such as fan speed control and temperature > > measurement. Input is, as its name suggests focused on input > > -devices. In some cases there is considerable overlap between these and > > +devices. In some cases, there is considerable overlap between these and > > IIO. > > > > A typical device falling into this category would be connected via SPI > > @@ -38,7 +38,7 @@ series and Analog Devices ADXL345 accelerometers. Each > > buffer supports > > polling to establish when data is available. > > > > * Trigger and software buffer support. In many data analysis > > -applications it it useful to be able to capture data based on some > > +applications it is useful to be able to capture data based on some > > external signal (trigger). These triggers might be a data ready > > signal, a gpio line connected to some external system or an on > > processor periodic interrupt. A single trigger may initialize data > > -- > > 2.25.1 > > > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/5] iio: core: pass parent device as parameter during allocation
On Fri, 22 May 2020 11:56:40 +0300
Andy Shevchenko wrote:
> On Fri, May 22, 2020 at 11:36 AM Alexandru Ardelean
> wrote:
> >
> > The change passes the parent device to the iio_device_alloc() call. This
> > also updates the devm_iio_device_alloc() call to consider the device object
> > as the parent device by default.
> >
> > Having it passed like this, should ensure that any IIO device object
> > already has a device object as parent, allowing for neater control, like
> > passing the 'indio_dev' object for other stuff [like buffers/triggers/etc],
> > and potentially creating iiom_xxx(indio_dev) functions.
> >
> > With this patch, only the 'drivers/platform/x86/toshiba_acpi.c' needs an
> > update to pass the parent object as a parameter.
>
> Acked-by: Andy Shevchenko
Whole series looks good to me. I dare say a few drivers will cross with
this but I'll keep my eyes open and it's not too much a a problem if
we have a few cases left to clean up later.
Nice work. I'll let this sit for a weekish though as it obviously touches
a lot of drivers so people 'might' want to comment.
Thanks,
Jonathan
>
> >
> > In the next patch all devm_iio_device_alloc() calls will be handled.
> >
> > Signed-off-by: Alexandru Ardelean
> > ---
> > drivers/iio/dummy/iio_simple_dummy.c | 14 --
> > drivers/iio/industrialio-core.c | 11 ++-
> > drivers/platform/x86/toshiba_acpi.c | 3 +--
> > drivers/staging/iio/Documentation/device.txt | 4 +---
> > include/linux/iio/iio.h | 4 ++--
> > 5 files changed, 18 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/iio/dummy/iio_simple_dummy.c
> > b/drivers/iio/dummy/iio_simple_dummy.c
> > index 6cb02299a215..b35ae7c039f7 100644
> > --- a/drivers/iio/dummy/iio_simple_dummy.c
> > +++ b/drivers/iio/dummy/iio_simple_dummy.c
> > @@ -566,6 +566,13 @@ static struct iio_sw_device *iio_dummy_probe(const
> > char *name)
> > struct iio_dev *indio_dev;
> > struct iio_dummy_state *st;
> > struct iio_sw_device *swd;
> > + struct device *parent = NULL;
> > +
> > + /*
> > +* With hardware: Set the parent device.
> > +* parent = >dev;
> > +* parent = >dev;
> > +*/
> >
> > swd = kzalloc(sizeof(*swd), GFP_KERNEL);
> > if (!swd) {
> > @@ -580,7 +587,7 @@ static struct iio_sw_device *iio_dummy_probe(const char
> > *name)
> > * It also has a region (accessed by iio_priv()
> > * for chip specific state information.
> > */
> > - indio_dev = iio_device_alloc(sizeof(*st));
> > + indio_dev = iio_device_alloc(parent, sizeof(*st));
> > if (!indio_dev) {
> > ret = -ENOMEM;
> > goto error_ret;
> > @@ -590,11 +597,6 @@ static struct iio_sw_device *iio_dummy_probe(const
> > char *name)
> > mutex_init(>lock);
> >
> > iio_dummy_init_device(indio_dev);
> > - /*
> > -* With hardware: Set the parent device.
> > -* indio_dev->dev.parent = >dev;
> > -* indio_dev->dev.parent = >dev;
> > -*/
> >
> > /*
> > * Make the iio_dev struct available to remove function.
> > diff --git a/drivers/iio/industrialio-core.c
> > b/drivers/iio/industrialio-core.c
> > index 1527f01a44f1..75661661aaba 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -1493,7 +1493,7 @@ struct device_type iio_device_type = {
> > * iio_device_alloc() - allocate an iio_dev from a driver
> > * @sizeof_priv: Space to allocate for private structure.
> > **/
> > -struct iio_dev *iio_device_alloc(int sizeof_priv)
> > +struct iio_dev *iio_device_alloc(struct device *parent, int sizeof_priv)
> > {
> > struct iio_dev *dev;
> > size_t alloc_size;
> > @@ -1510,6 +1510,7 @@ struct iio_dev *iio_device_alloc(int sizeof_priv)
> > if (!dev)
> > return NULL;
> >
> > + dev->dev.parent = parent;
> > dev->dev.groups = dev->groups;
> > dev->dev.type = _device_type;
> > dev->dev.bus = _bus_type;
> > @@ -1551,7 +1552,7 @@ static void devm_iio_device_release(struct device
> > *dev, void *res)
> >
> > /**
> > * devm_iio_device_alloc - Resource-managed iio_device_alloc()
> > - * @dev: Device to allocate iio_dev for
> > + * @parent:Device to allocate iio_dev for, and parent for this
> > IIO device
> > * @sizeof_priv: Space to allocate for private structure.
> > *
> > * Managed iio_device_alloc. iio_dev allocated with this function is
> > @@ -1560,7 +1561,7 @@ static void devm_iio_device_release(struct device
> > *dev, void *res)
> > * RETURNS:
> > * Pointer to allocated iio_dev on success, NULL on failure.
> > */
> > -struct iio_dev *devm_iio_device_alloc(struct device *dev, int sizeof_priv)
> > +struct iio_dev *devm_iio_device_alloc(struct device *parent, int
> > sizeof_priv)
> > {
>
Re: [PATCH] staging: iio: ad5933: rework probe to use devm_ function variants
On Fri, 8 May 2020 13:57:46 +0100 Mark Brown wrote: > On Fri, May 08, 2020 at 01:43:07PM +0100, Jonathan Cameron wrote: > > Dan Carpenter wrote: > > > > It feels like we should just make a devm_ version of regulator_enable(). > > > Or potentially this is more complicated than it seems, but in that case > > > probably adding devm_add_action_or_reset() is more complicated than it > > > seems as well. > > > It has been a while since that was last proposed. At the time the > > counter argument was that you should almost always be doing some form > > of PM and hence the regulator shouldn't have the same lifetime as the > > driver. Reality is that a lot of simple drivers either don't do > > PM or have elected to not turn the regulator off so as to retain state > > etc. > > Same issue as before - I fear it's far too error prone in conjunction > with runtime PM, and if the driver really is just doing an enable and > disable at probe and remove then that seems fairly trivial anyway. I > am constantly finding abuses of things like regulator_get_optional() > (which we do actually need) in drivers and it's not like I can review > all the users, I don't have much confidence in this stuff especially > when practically speaking few regulators ever change state at runtime so > issues don't manifest so often. > Fair enough. We'll carry on doing it with devm_add_action_or_reset which forces us to take a close look at why we always want the lifetime to match that of the device. Note the key thing here is we don't have a remove in these drivers. Everything is managed. Mixing and matching between managed and unmanaged causes more subtle race conditions... Jonathan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: ad5933: rework probe to use devm_ function variants
On Thu, 7 May 2020 12:50:16 +0300
Dan Carpenter wrote:
> On Sat, May 02, 2020 at 07:25:42PM +0100, Jonathan Cameron wrote:
> > On Tue, 28 Apr 2020 12:31:28 +0300
> > Alexandru Ardelean wrote:
> > > +static void ad5933_cleanup(void *data)
> > > +{
> > > + struct ad5933_state *st = data;
> > > +
> > > + clk_disable_unprepare(st->mclk);
> > > + regulator_disable(st->reg);
> >
> > Please do two separate callbacks so that these can be handled
> > in the correct places. I.e. you do something then immediately
> > register the handler to undo it.
> >
> > Currently you can end up disabling a clock you haven't enabled
> > (which I am fairly sure will give you an error message).
>
> Yeah. It does.
>
> It feels like we should just make a devm_ version of regulator_enable().
> Or potentially this is more complicated than it seems, but in that case
> probably adding devm_add_action_or_reset() is more complicated than it
> seems as well.
>
> regards,
> dan carpenter
It has been a while since that was last proposed. At the time the
counter argument was that you should almost always be doing some form
of PM and hence the regulator shouldn't have the same lifetime as the
driver. Reality is that a lot of simple drivers either don't do
PM or have elected to not turn the regulator off so as to retain state
etc.
Mark what do you think?
Jonathan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: ad2s1210: Fix SPI reading
On Wed, 29 Apr 2020 10:21:29 +0300
Alexandru Ardelean wrote:
> From: Dragos Bogdan
>
> If the serial interface is used, the 8-bit address should be latched using
> the rising edge of the WR/FSYNC signal.
>
> This basically means that a CS change is required between the first byte
> sent, and the second one.
> This change splits the single-transfer transfer of 2 bytes into 2 transfers
> with a single byte, and CS change in-between.
>
> Signed-off-by: Dragos Bogdan
> Signed-off-by: Alexandru Ardelean
Fixes tag would have been nice. I've had a go by picking a patch where I
refactored this code, but I think the issue probably predates that one.
Its in 2011 so I doubt anyone will try going past that with backports ;)
Applied to the fixes-togreg branch of iio.git and marked for stable.
I'm guessing this means you have hardware and hope to get this one out
of staging shortly? *crosses fingers* :)
Jonathan
> ---
> drivers/staging/iio/resolver/ad2s1210.c | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/iio/resolver/ad2s1210.c
> b/drivers/staging/iio/resolver/ad2s1210.c
> index 4b25a3a314ed..ed404355ea4c 100644
> --- a/drivers/staging/iio/resolver/ad2s1210.c
> +++ b/drivers/staging/iio/resolver/ad2s1210.c
> @@ -130,17 +130,24 @@ static int ad2s1210_config_write(struct ad2s1210_state
> *st, u8 data)
> static int ad2s1210_config_read(struct ad2s1210_state *st,
> unsigned char address)
> {
> - struct spi_transfer xfer = {
> - .len = 2,
> - .rx_buf = st->rx,
> - .tx_buf = st->tx,
> + struct spi_transfer xfers[] = {
> + {
> + .len = 1,
> + .rx_buf = >rx[0],
> + .tx_buf = >tx[0],
> + .cs_change = 1,
> + }, {
> + .len = 1,
> + .rx_buf = >rx[1],
> + .tx_buf = >tx[1],
> + },
> };
> int ret = 0;
>
> ad2s1210_set_mode(MOD_CONFIG, st);
> st->tx[0] = address | AD2S1210_MSB_IS_HIGH;
> st->tx[1] = AD2S1210_REG_FAULT;
> - ret = spi_sync_transfer(st->sdev, , 1);
> + ret = spi_sync_transfer(st->sdev, xfers, 2);
> if (ret < 0)
> return ret;
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: ad5933: rework probe to use devm_ function variants
On Tue, 28 Apr 2020 12:31:28 +0300
Alexandru Ardelean wrote:
> This change cleans up the driver's probe function to use only devm_
> function variants. This also gets rid of the remove function and moves the
> clock & regulator de-initializations to the 'ad5933_cleanup()' callback.
>
> Signed-off-by: Alexandru Ardelean
Basic rule of thumb. Whatever you register with devm_add_action_or_reset
should only cleanup one one thing done in the probe path.
There is almost always a race if you do more than one bit of cleanup
per such callback + it's harder to review as it fails the 'obviously correct
test'.
Jonathan
> ---
> .../staging/iio/impedance-analyzer/ad5933.c | 59 ---
> 1 file changed, 23 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c
> b/drivers/staging/iio/impedance-analyzer/ad5933.c
> index af0bcf95ee8a..06a6dcd7883b 100644
> --- a/drivers/staging/iio/impedance-analyzer/ad5933.c
> +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
> @@ -602,11 +602,12 @@ static const struct iio_buffer_setup_ops
> ad5933_ring_setup_ops = {
> .postdisable = ad5933_ring_postdisable,
> };
>
> -static int ad5933_register_ring_funcs_and_init(struct iio_dev *indio_dev)
> +static int ad5933_register_ring_funcs_and_init(struct device *dev,
> +struct iio_dev *indio_dev)
> {
> struct iio_buffer *buffer;
>
> - buffer = iio_kfifo_allocate();
> + buffer = devm_iio_kfifo_allocate(dev);
> if (!buffer)
> return -ENOMEM;
>
> @@ -676,6 +677,14 @@ static void ad5933_work(struct work_struct *work)
> }
> }
>
> +static void ad5933_cleanup(void *data)
> +{
> + struct ad5933_state *st = data;
> +
> + clk_disable_unprepare(st->mclk);
> + regulator_disable(st->reg);
Please do two separate callbacks so that these can be handled
in the correct places. I.e. you do something then immediately
register the handler to undo it.
Currently you can end up disabling a clock you haven't enabled
(which I am fairly sure will give you an error message).
> +}
> +
> static int ad5933_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> @@ -703,23 +712,28 @@ static int ad5933_probe(struct i2c_client *client,
> dev_err(>dev, "Failed to enable specified VDD
> supply\n");
> return ret;
> }
> +
> + ret = devm_add_action_or_reset(>dev, ad5933_cleanup, st);
> + if (ret)
> + return ret;
> +
> ret = regulator_get_voltage(st->reg);
>
> if (ret < 0)
> - goto error_disable_reg;
> + return ret;
>
> st->vref_mv = ret / 1000;
>
> st->mclk = devm_clk_get(>dev, "mclk");
> if (IS_ERR(st->mclk) && PTR_ERR(st->mclk) != -ENOENT) {
> ret = PTR_ERR(st->mclk);
> - goto error_disable_reg;
> + return ret;
> }
>
> if (!IS_ERR(st->mclk)) {
> ret = clk_prepare_enable(st->mclk);
> if (ret < 0)
> - goto error_disable_reg;
> + return ret;
> ext_clk_hz = clk_get_rate(st->mclk);
> }
>
> @@ -742,41 +756,15 @@ static int ad5933_probe(struct i2c_client *client,
> indio_dev->channels = ad5933_channels;
> indio_dev->num_channels = ARRAY_SIZE(ad5933_channels);
>
> - ret = ad5933_register_ring_funcs_and_init(indio_dev);
> + ret = ad5933_register_ring_funcs_and_init(>dev, indio_dev);
> if (ret)
> - goto error_disable_mclk;
> + return ret;
>
> ret = ad5933_setup(st);
> if (ret)
> - goto error_unreg_ring;
> -
> - ret = iio_device_register(indio_dev);
> - if (ret)
> - goto error_unreg_ring;
> -
> - return 0;
> -
> -error_unreg_ring:
> - iio_kfifo_free(indio_dev->buffer);
> -error_disable_mclk:
> - clk_disable_unprepare(st->mclk);
> -error_disable_reg:
> - regulator_disable(st->reg);
> -
> - return ret;
> -}
> -
> -static int ad5933_remove(struct i2c_client *client)
> -{
> - struct iio_dev *indio_dev = i2c_get_clientdata(client);
> - struct ad5933_state *st = iio_priv(indio_dev);
> -
> - iio_device_unregister(indio_dev);
> - iio_kfifo_free(indio_dev->buffer);
> - regulator_disable(st->reg);
> - clk_disable_unprepare(st->mclk);
> + return ret;
>
> - return 0;
> + return devm_iio_device_register(>dev, indio_dev);
> }
>
> static const struct i2c_device_id ad5933_id[] = {
> @@ -801,7 +789,6 @@ static struct i2c_driver ad5933_driver = {
> .of_match_table = ad5933_of_match,
> },
> .probe = ad5933_probe,
> - .remove = ad5933_remove,
> .id_table = ad5933_id,
> };
> module_i2c_driver(ad5933_driver);
___
devel mailing list
de...@linuxdriverproject.org
Re: [PATCH 1/3] iio: kfifo: add iio_device_attach_kfifo_buffer() helper
On Mon, 6 Apr 2020 08:12:42 + "Ardelean, Alexandru" wrote: > On Sun, 2020-04-05 at 11:46 +0100, Jonathan Cameron wrote: > > [External] > > > > On Wed, 1 Apr 2020 15:59:34 +0300 > > Alexandru Ardelean wrote: > > > > > This change adds the iio_device_attach_kfifo_buffer() helper/short-hand, > > > which groups the simple routine of allocating a kfifo buffers via > > > devm_iio_kfifo_allocate() and calling iio_device_attach_buffer(). > > > > > > The mode_flags parameter is required. The setup_ops parameter is optional. > > > > > > This function will be a bit more useful when needing to define multiple > > > buffers per IIO device. > > > > > > One requirement [that is more a recommendation] for this helper, is to > > > call > > > it after 'indio_dev' has been populated. > > > > > > Also, one consequence related to using this helper is that the resource > > > management of the buffer will be tied to 'indio_dev->dev'. Previously it > > > was open-coded, and each driver does it slightly differently. Most of them > > > tied it to the parent device, some of them to 'indio_dev->dev'. > > > This shouldn't be a problem, and may be a good idea when adding more > > > buffers per-device. > > > > I'm glad you highlighted this subtlety. I'm not sure it's safe in all cases > > because the result is that the managed cleanup for this will occur once we > > get to the cleanup for devm_iio_device_alloc and we release the > > indio_dev->dev > > > > That would put it 'after' any other devm calls that are still hung off the > > parent > > device. > > > > Now the question is whether that ever causes us problems... See next patch. > > It potentially does. I think we need to provide the dev separately even > > if it feels a bit silly to do so. Scope management is complex so I don't > > really want to force people to mix and match between different devices > > and so get it wrong by accident. > > > > The other issue is that it's not readily apparent from the naming that > > this function is registering stuff that is cleaned up automatically or > > that it even allocates anything that might need that.. > > > > devm_iio_device_attach_new_kfifo_buffer maybe? > > > > I'm sort of wondering if we should do what dma did and have > > > > iiom_device_attach_new_kfifo_buffer to indicate it's managed in the > > scope of the iio device? > > > > What do people think? > > > > However, see patch 2 before commenting. Reality is I'm not sure forcing > > managed calls to hang off iio_dev->dev is a good idea (at this stage given > > where we are). > > What I am really after with this patch is to hide away these: > iio_kfifo_free(indio_dev->buffer); > iio_buffer_set_attrs(indio_dev->buffer, _fifo_attributes); > i.e. not have 'indio_dev->buffer' open-coded in drivers, and hide it in IIO > core > somewhere. > Some ideas can go in parallel [like this one] to add support for multiple > buffers. > > So, I will think of a better [less sloppy] V2 for this. > > One intermediate alternative is to do 'iio_device_kfifo_free(indio_dev)', but > I'll still try to think of a better devm_ approach. > devm_iio_device_attach_new_kfifo_buffer() sounds a bit long but may work. > iiom_device_attach_new_kfifo_buffer() can also work. > > What if we just default attaching to the parent device? That would work and be consistent with the vast majority of current cases. > > Would it work to also attach the parent device in devm_iio_device_alloc() by > default? That would need a thorough audit to check nothing crazy is done by a driver with an odd structure. Such a driver would (I think) be buggy though as the child lifetime should be dependent on the parent and not some other device. > Or change 'iio_device_alloc()' to take a parent device as argument? I think there are only a couple of users, so that would work. > Which for devm_iio_device_alloc(dev,...) would implicitly mean that 'dev' is > 'parent'? I think that's a fair assumption (though needs a sanity check) > > These are just some thoughts. > > > > > > Thanks > > > > Jonathan > > > > > > > Signed-off-by: Alexandru Ardelean > > > --- > > > drivers/iio/buffer/kfifo_buf.c | 37 ++ > > > include/linux/iio/kfifo_buf.h | 4 > > > 2 files changed, 41 insertions(+) > > > > > > diff --git a/drivers/iio/buf
Re: [PATCH 3/3] staging: iio: ad5933: use iio_device_attach_kfifo_buffer() helper
On Wed, 1 Apr 2020 15:59:36 +0300
Alexandru Ardelean wrote:
> This driver calls iio_kfifo_allocate() vs devm_iio_kfifo_allocate(). But
> the conversion is still simpler here, and cleans-up/reduces some error
> paths.
>
> Signed-off-by: Alexandru Ardelean
This mixes devm managed stuff an unmanaged. Hence it fails the 'obviously
correct'
test. If you wanted to do this you'd first need to sort out the unmanaged
bits to be automatically unwound (regulators and clocks). Or potentially reorder
the driver so those happen after this allocation is done.
Thanks,
Jonathan
> ---
> .../staging/iio/impedance-analyzer/ad5933.c | 28 ---
> 1 file changed, 5 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c
> b/drivers/staging/iio/impedance-analyzer/ad5933.c
> index af0bcf95ee8a..7bde93c6dd74 100644
> --- a/drivers/staging/iio/impedance-analyzer/ad5933.c
> +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
> @@ -602,22 +602,6 @@ static const struct iio_buffer_setup_ops
> ad5933_ring_setup_ops = {
> .postdisable = ad5933_ring_postdisable,
> };
>
> -static int ad5933_register_ring_funcs_and_init(struct iio_dev *indio_dev)
> -{
> - struct iio_buffer *buffer;
> -
> - buffer = iio_kfifo_allocate();
> - if (!buffer)
> - return -ENOMEM;
> -
> - iio_device_attach_buffer(indio_dev, buffer);
> -
> - /* Ring buffer functions - here trigger setup related */
> - indio_dev->setup_ops = _ring_setup_ops;
> -
> - return 0;
> -}
> -
> static void ad5933_work(struct work_struct *work)
> {
> struct ad5933_state *st = container_of(work,
> @@ -738,26 +722,25 @@ static int ad5933_probe(struct i2c_client *client,
> indio_dev->dev.parent = >dev;
> indio_dev->info = _info;
> indio_dev->name = id->name;
> - indio_dev->modes = (INDIO_BUFFER_SOFTWARE | INDIO_DIRECT_MODE);
> + indio_dev->modes = INDIO_DIRECT_MODE;
> indio_dev->channels = ad5933_channels;
> indio_dev->num_channels = ARRAY_SIZE(ad5933_channels);
>
> - ret = ad5933_register_ring_funcs_and_init(indio_dev);
> + ret = iio_device_attach_kfifo_buffer(indio_dev, INDIO_BUFFER_SOFTWARE,
> + _ring_setup_ops);
> if (ret)
> goto error_disable_mclk;
>
> ret = ad5933_setup(st);
> if (ret)
> - goto error_unreg_ring;
> + goto error_disable_mclk;
>
> ret = iio_device_register(indio_dev);
> if (ret)
> - goto error_unreg_ring;
> + goto error_disable_mclk;
>
> return 0;
>
> -error_unreg_ring:
> - iio_kfifo_free(indio_dev->buffer);
> error_disable_mclk:
> clk_disable_unprepare(st->mclk);
> error_disable_reg:
> @@ -772,7 +755,6 @@ static int ad5933_remove(struct i2c_client *client)
> struct ad5933_state *st = iio_priv(indio_dev);
>
> iio_device_unregister(indio_dev);
> - iio_kfifo_free(indio_dev->buffer);
> regulator_disable(st->reg);
> clk_disable_unprepare(st->mclk);
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] iio: kfifo: add iio_device_attach_kfifo_buffer() helper
On Wed, 1 Apr 2020 15:59:34 +0300
Alexandru Ardelean wrote:
> This change adds the iio_device_attach_kfifo_buffer() helper/short-hand,
> which groups the simple routine of allocating a kfifo buffers via
> devm_iio_kfifo_allocate() and calling iio_device_attach_buffer().
>
> The mode_flags parameter is required. The setup_ops parameter is optional.
>
> This function will be a bit more useful when needing to define multiple
> buffers per IIO device.
>
> One requirement [that is more a recommendation] for this helper, is to call
> it after 'indio_dev' has been populated.
>
> Also, one consequence related to using this helper is that the resource
> management of the buffer will be tied to 'indio_dev->dev'. Previously it
> was open-coded, and each driver does it slightly differently. Most of them
> tied it to the parent device, some of them to 'indio_dev->dev'.
> This shouldn't be a problem, and may be a good idea when adding more
> buffers per-device.
I'm glad you highlighted this subtlety. I'm not sure it's safe in all cases
because the result is that the managed cleanup for this will occur once we
get to the cleanup for devm_iio_device_alloc and we release the indio_dev->dev
That would put it 'after' any other devm calls that are still hung off the
parent
device.
Now the question is whether that ever causes us problems... See next patch.
It potentially does. I think we need to provide the dev separately even
if it feels a bit silly to do so. Scope management is complex so I don't
really want to force people to mix and match between different devices
and so get it wrong by accident.
The other issue is that it's not readily apparent from the naming that
this function is registering stuff that is cleaned up automatically or
that it even allocates anything that might need that..
devm_iio_device_attach_new_kfifo_buffer maybe?
I'm sort of wondering if we should do what dma did and have
iiom_device_attach_new_kfifo_buffer to indicate it's managed in the
scope of the iio device?
What do people think?
However, see patch 2 before commenting. Reality is I'm not sure forcing
managed calls to hang off iio_dev->dev is a good idea (at this stage given
where we are).
Thanks
Jonathan
>
> Signed-off-by: Alexandru Ardelean
> ---
> drivers/iio/buffer/kfifo_buf.c | 37 ++
> include/linux/iio/kfifo_buf.h | 4
> 2 files changed, 41 insertions(+)
>
> diff --git a/drivers/iio/buffer/kfifo_buf.c b/drivers/iio/buffer/kfifo_buf.c
> index 3150f8ab984b..05b7c5fc6f1d 100644
> --- a/drivers/iio/buffer/kfifo_buf.c
> +++ b/drivers/iio/buffer/kfifo_buf.c
> @@ -228,4 +228,41 @@ void devm_iio_kfifo_free(struct device *dev, struct
> iio_buffer *r)
> }
> EXPORT_SYMBOL(devm_iio_kfifo_free);
>
> +/**
> + * iio_device_attach_kfifo_buffer - Allocate a kfifo buffer & attach it to
> an IIO device
> + * @indio_dev: The device the buffer should be attached to
> + * @mode_flags: The mode flags for this buffer (INDIO_BUFFER_SOFTWARE and/or
> + * INDIO_BUFFER_TRIGGERED).
> + * @setup_ops: The setup_ops required to configure the HW part of the buffer
> (optional)
> + *
> + * This function allocates a kfifo buffer via devm_iio_kfifo_allocate() and
> + * attaches it to the IIO device via iio_device_attach_buffer().
> + * This is meant to be a bit of a short-hand/helper function as many driver
> + * seem to do this.
> + */
> +int iio_device_attach_kfifo_buffer(struct iio_dev *indio_dev,
> +int mode_flags,
> +const struct iio_buffer_setup_ops *setup_ops)
> +{
> + struct iio_buffer *buffer;
> +
> + if (mode_flags)
> + mode_flags &= kfifo_access_funcs.modes;
> +
> + if (!mode_flags)
> + return -EINVAL;
> +
> + buffer = devm_iio_kfifo_allocate(_dev->dev);
> + if (!buffer)
> + return -ENOMEM;
> +
> + iio_device_attach_buffer(indio_dev, buffer);
> +
> + indio_dev->modes |= mode_flags;
> + indio_dev->setup_ops = setup_ops;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(iio_device_attach_kfifo_buffer);
> +
> MODULE_LICENSE("GPL");
> diff --git a/include/linux/iio/kfifo_buf.h b/include/linux/iio/kfifo_buf.h
> index 764659e01b68..2363a931be14 100644
> --- a/include/linux/iio/kfifo_buf.h
> +++ b/include/linux/iio/kfifo_buf.h
> @@ -11,4 +11,8 @@ void iio_kfifo_free(struct iio_buffer *r);
> struct iio_buffer *devm_iio_kfifo_allocate(struct device *dev);
> void devm_iio_kfifo_free(struct device *dev, struct iio_buffer *r);
>
> +int iio_device_attach_kfifo_buffer(struct iio_dev *indio_dev,
> +int mode_flags,
> +const struct iio_buffer_setup_ops
> *setup_ops);
> +
> #endif
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/3] iio: make use of iio_device_attach_kfifo_buffer() where straightforward
On Wed, 1 Apr 2020 15:59:35 +0300
Alexandru Ardelean wrote:
> All drivers that already call devm_iio_kfifo_allocate() &
> iio_device_attach_buffer() are simple to convert to
> iio_device_attach_kfifo_buffer() in a single go/patch/.
>
> This change does that.
>
> For drivers max30100 & max30102 this helper is called after indio_dev has
> been populated. This doesn't make any difference [at this point in time].
>
> Signed-off-by: Alexandru Ardelean
Comments inline refer back to the question of whether this results in
any order changes that might matter. Unfortunately it does. I think
we need to allow the new function to take the struct device *
that the driver author wants it to us and to have the naming make it
clear it's a managed function.
The alternative is to go tidy up the allocations so all of the managed
calls scopes are correct. I.e. any that are associated with the iio_dev
(or iio_priv obviously) use the indio_dev->dev including irq requests
etc. That might be a good exercise to do but it's not a small one
and the benefits aren't obvious. We'd move from a simple linear unwind
to a nested one.
devm_iio_device_alloc
devm_iio_*_alloc
devm_request_threaded_irq etc
devm_kzalloc
devm_iio_device_register
devm_iio_device_alloc
devm_iio*alloc
devm_request_threaded_irq
devm_kzalloc
devm_iio_device_register
So the release of the parent in the second cause the unwind of the
device setup in devm_iio_device_alloc and take out all of the items below.
If we'd structure this right in the first place the second option might be
more elegant but we didn't so retrofitting it now will be messy.
Jonathan
> ---
> drivers/iio/accel/sca3000.c| 18 ++
> drivers/iio/accel/ssp_accel_sensor.c | 13 -
> drivers/iio/adc/ina2xx-adc.c | 13 +
> drivers/iio/gyro/ssp_gyro_sensor.c | 13 -
> drivers/iio/health/max30100.c | 15 ++-
> drivers/iio/health/max30102.c | 15 ++-
> drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c | 17 +++--
> drivers/iio/light/acpi-als.c | 11 +--
> drivers/iio/light/apds9960.c | 15 ++-
> 9 files changed, 45 insertions(+), 85 deletions(-)
>
> diff --git a/drivers/iio/accel/sca3000.c b/drivers/iio/accel/sca3000.c
> index 66d768d971e1..a0db76082ba6 100644
> --- a/drivers/iio/accel/sca3000.c
> +++ b/drivers/iio/accel/sca3000.c
> @@ -1272,20 +1272,6 @@ static int sca3000_write_event_config(struct iio_dev
> *indio_dev,
> return ret;
> }
>
> -static int sca3000_configure_ring(struct iio_dev *indio_dev)
> -{
> - struct iio_buffer *buffer;
> -
> - buffer = devm_iio_kfifo_allocate(_dev->dev);
> - if (!buffer)
> - return -ENOMEM;
> -
> - iio_device_attach_buffer(indio_dev, buffer);
> - indio_dev->modes |= INDIO_BUFFER_SOFTWARE;
> -
> - return 0;
> -}
> -
> static inline
> int __sca3000_hw_ring_state_set(struct iio_dev *indio_dev, bool state)
> {
> @@ -1480,7 +1466,8 @@ static int sca3000_probe(struct spi_device *spi)
> }
> indio_dev->modes = INDIO_DIRECT_MODE;
>
> - ret = sca3000_configure_ring(indio_dev);
> + ret = iio_device_attach_kfifo_buffer(indio_dev, INDIO_BUFFER_SOFTWARE,
> + _ring_setup_ops);
This one is fine (for a moment I thought we had a bug in the current code)
as this call is the next thing that needs unwinding after the
devm_iio_device_alloc
anyway. It would however have been more consistent if original code had
used the parent dev.
> if (ret)
> return ret;
>
> @@ -1494,7 +1481,6 @@ static int sca3000_probe(struct spi_device *spi)
> if (ret)
> return ret;
> }
> - indio_dev->setup_ops = _ring_setup_ops;
> ret = sca3000_clean_setup(st);
> if (ret)
> goto error_free_irq;
> diff --git a/drivers/iio/accel/ssp_accel_sensor.c
> b/drivers/iio/accel/ssp_accel_sensor.c
> index c32647abce20..1d9971db949d 100644
> --- a/drivers/iio/accel/ssp_accel_sensor.c
> +++ b/drivers/iio/accel/ssp_accel_sensor.c
> @@ -96,7 +96,6 @@ static int ssp_accel_probe(struct platform_device *pdev)
> int ret;
> struct iio_dev *indio_dev;
> struct ssp_sensor_data *spd;
> - struct iio_buffer *buffer;
>
> indio_dev = devm_iio_device_alloc(>dev, sizeof(*spd));
> if (!indio_dev)
> @@ -111,18 +110,14 @@ static int ssp_accel_probe(struct platform_device *pdev)
> indio_dev->dev.parent = >dev;
> indio_dev->dev.of_node = pdev->dev.of_node;
> indio_dev->info = _accel_iio_info;
> - indio_dev->modes = INDIO_BUFFER_SOFTWARE;
> indio_dev->channels = ssp_acc_channels;
> indio_dev->num_channels = ARRAY_SIZE(ssp_acc_channels);
> indio_dev->available_scan_masks = ssp_accel_scan_mask;
>
>
Re: [PATCH v3] staging: iio: update TODO
On Sat, 29 Feb 2020 19:35:45 +0530 Rohit Sarkar wrote: > Since there are no uses of the old GPIO API, remove the item from > the TODO. > > Changelog > v3: Remove new items added. > v2: Add work item mentioned by Alexandru in > https://marc.info/?l=linux-iio=158261515624212=2 Change log belongs below the --- as we don't want this info in the git history. I've tidied up and applied to the togreg branch of iio.git (pushed out as testing for the autobuilders to play with it). Thanks, Jonathan > > Signed-off-by: Rohit Sarkar > --- > drivers/staging/iio/TODO | 8 +--- > 1 file changed, 1 insertion(+), 7 deletions(-) > > diff --git a/drivers/staging/iio/TODO b/drivers/staging/iio/TODO > index 1b8ebf2c1b69..4d469016a13a 100644 > --- a/drivers/staging/iio/TODO > +++ b/drivers/staging/iio/TODO > @@ -1,10 +1,4 @@ > -2018-04-15 > - > -All affected drivers: > -Convert all uses of the old GPIO API from to the > -GPIO descriptor API in and look up GPIO > -lines from device tree, ACPI or board files, board files should > -use . > +2020-02-25 > > > ADI Drivers: ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/4] iio: imu: adis: Refactor adis_initial_startup
On Thu, 6 Feb 2020 10:19:09 + "Sa, Nuno" wrote: > On Thu, 2020-02-06 at 09:45 +0000, Jonathan Cameron wrote: > > On Wed, 5 Feb 2020 16:44:13 + > > "Sa, Nuno" wrote: > > > > > On Wed, 2020-02-05 at 14:59 +, Jonathan Cameron wrote: > > > > On Wed, 5 Feb 2020 12:25:40 + > > > > "Sa, Nuno" wrote: > > > > > > > > > On Mon, 2020-02-03 at 12:03 +, Jonathan Cameron wrote: > > > > > > On Mon, 3 Feb 2020 10:31:30 +0100 > > > > > > Nuno Sá wrote: > > > > > > > > > > > > > Hi Jonathan, > > > > > > > > > > > > > > > > > > > > > On Sat, 2020-02-01 at 17:08 +, Jonathan Cameron > > > > > > > wrote: > > > > > > > > On Mon, 20 Jan 2020 16:20:49 +0200 > > > > > > > > Alexandru Ardelean wrote: > > > > > > > > > > > > > > > > > From: Nuno Sá > > > > > > > > > > > > > > > > > > All the ADIS devices perform, at the beginning, a self > > > > > > > > > test > > > > > > > > > to > > > > > > > > > make > > > > > > > > > sure > > > > > > > > > the device is in a sane state. Furthermore, some > > > > > > > > > drivers > > > > > > > > > also > > > > > > > > > do a > > > > > > > > > call > > > > > > > > > to `adis_reset()` before the test which is also a good > > > > > > > > > practice. > > > > > > > > > This > > > > > > > > > patch unifies all those operation so that, there's no > > > > > > > > > need > > > > > > > > > for > > > > > > > > > code > > > > > > > > > duplication. Furthermore, the rst pin is also checked > > > > > > > > > to > > > > > > > > > make > > > > > > > > > sure > > > > > > > > > the > > > > > > > > > device is not in HW reset. On top of this, some drivers > > > > > > > > > also > > > > > > > > > read > > > > > > > > > the > > > > > > > > > device product id and compare it with the device being > > > > > > > > > probed > > > > > > > > > to > > > > > > > > > make > > > > > > > > > sure the correct device is being handled. This can also > > > > > > > > > be > > > > > > > > > passed > > > > > > > > > to the > > > > > > > > > library by introducing a variable holding the PROD_ID > > > > > > > > > register > > > > > > > > > of > > > > > > > > > the > > > > > > > > > device. > > > > > > > > > > > > > > > > > > Signed-off-by: Nuno Sá > > > > > > > > > Signed-off-by: Alexandru Ardelean < > > > > > > > > > alexandru.ardel...@analog.com> > > > > > > > > > --- > > > > > > > > > drivers/iio/imu/Kconfig | 1 + > > > > > > > > > drivers/iio/imu/adis.c | 63 > > > > > > > > > ++ > > > > > > > > > > > > > > > > > > -- > > > > > > > > > include/linux/iio/imu/adis.h | 15 - > > > > > > > > > 3 files changed, 61 insertions(+), 18 deletions(-) > > > > > > > > > > > > > > > > > > diff --git a/drivers/iio/imu/Kconfig > > > > > > > > > b/drivers/iio/imu/Kconfig > > > > > > > > > index 60bb1029e759..63036cf473c7 100644 > > > > > > > > > --- a/drivers/iio/imu/Kconfig > > > > > > > > > +++ b/drivers/iio/imu/Kconfig > > > > > > > > > @@ -85,6 +85,7 @@ endmenu > >
Re: [PATCH 2/4] iio: imu: adis: Refactor adis_initial_startup
On Wed, 5 Feb 2020 16:44:13 + "Sa, Nuno" wrote: > On Wed, 2020-02-05 at 14:59 +0000, Jonathan Cameron wrote: > > On Wed, 5 Feb 2020 12:25:40 + > > "Sa, Nuno" wrote: > > > > > On Mon, 2020-02-03 at 12:03 +, Jonathan Cameron wrote: > > > > On Mon, 3 Feb 2020 10:31:30 +0100 > > > > Nuno Sá wrote: > > > > > > > > > Hi Jonathan, > > > > > > > > > > > > > > > On Sat, 2020-02-01 at 17:08 +, Jonathan Cameron wrote: > > > > > > On Mon, 20 Jan 2020 16:20:49 +0200 > > > > > > Alexandru Ardelean wrote: > > > > > > > > > > > > > From: Nuno Sá > > > > > > > > > > > > > > All the ADIS devices perform, at the beginning, a self test > > > > > > > to > > > > > > > make > > > > > > > sure > > > > > > > the device is in a sane state. Furthermore, some drivers > > > > > > > also > > > > > > > do a > > > > > > > call > > > > > > > to `adis_reset()` before the test which is also a good > > > > > > > practice. > > > > > > > This > > > > > > > patch unifies all those operation so that, there's no need > > > > > > > for > > > > > > > code > > > > > > > duplication. Furthermore, the rst pin is also checked to > > > > > > > make > > > > > > > sure > > > > > > > the > > > > > > > device is not in HW reset. On top of this, some drivers > > > > > > > also > > > > > > > read > > > > > > > the > > > > > > > device product id and compare it with the device being > > > > > > > probed > > > > > > > to > > > > > > > make > > > > > > > sure the correct device is being handled. This can also be > > > > > > > passed > > > > > > > to the > > > > > > > library by introducing a variable holding the PROD_ID > > > > > > > register > > > > > > > of > > > > > > > the > > > > > > > device. > > > > > > > > > > > > > > Signed-off-by: Nuno Sá > > > > > > > Signed-off-by: Alexandru Ardelean < > > > > > > > alexandru.ardel...@analog.com> > > > > > > > --- > > > > > > > drivers/iio/imu/Kconfig | 1 + > > > > > > > drivers/iio/imu/adis.c | 63 > > > > > > > ++ > > > > > > > > > > > > > > -- > > > > > > > include/linux/iio/imu/adis.h | 15 - > > > > > > > 3 files changed, 61 insertions(+), 18 deletions(-) > > > > > > > > > > > > > > diff --git a/drivers/iio/imu/Kconfig > > > > > > > b/drivers/iio/imu/Kconfig > > > > > > > index 60bb1029e759..63036cf473c7 100644 > > > > > > > --- a/drivers/iio/imu/Kconfig > > > > > > > +++ b/drivers/iio/imu/Kconfig > > > > > > > @@ -85,6 +85,7 @@ endmenu > > > > > > > > > > > > > > config IIO_ADIS_LIB > > > > > > > tristate > > > > > > > + depends on GPIOLIB > > > > > > > help > > > > > > > A set of IO helper functions for the Analog Devices > > > > > > > ADIS* > > > > > > > device family. > > > > > > > > > > > > > > diff --git a/drivers/iio/imu/adis.c > > > > > > > b/drivers/iio/imu/adis.c > > > > > > > index d02b1911b0f2..1eca5271380e 100644 > > > > > > > --- a/drivers/iio/imu/adis.c > > > > > > > +++ b/drivers/iio/imu/adis.c > > > > > > > @@ -7,6 +7,7 @@ > > > > > > > */ > > > > > > > > > > > > > > #include > > > > > > > +#include > > > > > > > #include > > > > > > > #include > > > > > > >
Re: [PATCH 2/4] iio: imu: adis: Refactor adis_initial_startup
On Wed, 5 Feb 2020 12:25:40 + "Sa, Nuno" wrote: > On Mon, 2020-02-03 at 12:03 +0000, Jonathan Cameron wrote: > > > > On Mon, 3 Feb 2020 10:31:30 +0100 > > Nuno Sá wrote: > > > > > Hi Jonathan, > > > > > > > > > On Sat, 2020-02-01 at 17:08 +, Jonathan Cameron wrote: > > > > On Mon, 20 Jan 2020 16:20:49 +0200 > > > > Alexandru Ardelean wrote: > > > > > > > > > From: Nuno Sá > > > > > > > > > > All the ADIS devices perform, at the beginning, a self test to > > > > > make > > > > > sure > > > > > the device is in a sane state. Furthermore, some drivers also > > > > > do a > > > > > call > > > > > to `adis_reset()` before the test which is also a good > > > > > practice. > > > > > This > > > > > patch unifies all those operation so that, there's no need for > > > > > code > > > > > duplication. Furthermore, the rst pin is also checked to make > > > > > sure > > > > > the > > > > > device is not in HW reset. On top of this, some drivers also > > > > > read > > > > > the > > > > > device product id and compare it with the device being probed > > > > > to > > > > > make > > > > > sure the correct device is being handled. This can also be > > > > > passed > > > > > to the > > > > > library by introducing a variable holding the PROD_ID register > > > > > of > > > > > the > > > > > device. > > > > > > > > > > Signed-off-by: Nuno Sá > > > > > Signed-off-by: Alexandru Ardelean < > > > > > alexandru.ardel...@analog.com> > > > > > --- > > > > > drivers/iio/imu/Kconfig | 1 + > > > > > drivers/iio/imu/adis.c | 63 ++ > > > > > > > > > > -- > > > > > include/linux/iio/imu/adis.h | 15 - > > > > > 3 files changed, 61 insertions(+), 18 deletions(-) > > > > > > > > > > diff --git a/drivers/iio/imu/Kconfig b/drivers/iio/imu/Kconfig > > > > > index 60bb1029e759..63036cf473c7 100644 > > > > > --- a/drivers/iio/imu/Kconfig > > > > > +++ b/drivers/iio/imu/Kconfig > > > > > @@ -85,6 +85,7 @@ endmenu > > > > > > > > > > config IIO_ADIS_LIB > > > > > tristate > > > > > + depends on GPIOLIB > > > > > help > > > > > A set of IO helper functions for the Analog Devices > > > > > ADIS* > > > > > device family. > > > > > > > > > > diff --git a/drivers/iio/imu/adis.c b/drivers/iio/imu/adis.c > > > > > index d02b1911b0f2..1eca5271380e 100644 > > > > > --- a/drivers/iio/imu/adis.c > > > > > +++ b/drivers/iio/imu/adis.c > > > > > @@ -7,6 +7,7 @@ > > > > > */ > > > > > > > > > > #include > > > > > +#include > > > > > #include > > > > > #include > > > > > #include > > > > > @@ -365,36 +366,64 @@ static int adis_self_test(struct adis > > > > > *adis) > > > > > } > > > > > > > > > > /** > > > > > - * adis_inital_startup() - Performs device self-test > > > > > + * __adis_initial_startup() - Device initial setup > > > > > * @adis: The adis device > > > > > * > > > > > + * This functions makes sure the device is not in reset, via > > > > > rst > > > > > pin. > > > > > + * Furthermore it performs a SW reset (only in the case we are > > > > > not > > > > > coming from > > > > > + * reset already) and a self test. It also compares the > > > > > product id > > > > > with the > > > > > + * device id if the prod_id_reg variable is set. > > > > > + * > > > > > * Returns 0 if the device is operational, a negative error > > > > > code > > > > > otherwise. > > > > > * > > > > > * This function should be called early on in the device > > > &
Re: [PATCH 2/4] iio: imu: adis: Refactor adis_initial_startup
On Mon, 3 Feb 2020 10:31:30 +0100
Nuno Sá wrote:
> Hi Jonathan,
>
>
> On Sat, 2020-02-01 at 17:08 +0000, Jonathan Cameron wrote:
> > On Mon, 20 Jan 2020 16:20:49 +0200
> > Alexandru Ardelean wrote:
> >
> > > From: Nuno Sá
> > >
> > > All the ADIS devices perform, at the beginning, a self test to make
> > > sure
> > > the device is in a sane state. Furthermore, some drivers also do a
> > > call
> > > to `adis_reset()` before the test which is also a good practice.
> > > This
> > > patch unifies all those operation so that, there's no need for code
> > > duplication. Furthermore, the rst pin is also checked to make sure
> > > the
> > > device is not in HW reset. On top of this, some drivers also read
> > > the
> > > device product id and compare it with the device being probed to
> > > make
> > > sure the correct device is being handled. This can also be passed
> > > to the
> > > library by introducing a variable holding the PROD_ID register of
> > > the
> > > device.
> > >
> > > Signed-off-by: Nuno Sá
> > > Signed-off-by: Alexandru Ardelean
> > > ---
> > > drivers/iio/imu/Kconfig | 1 +
> > > drivers/iio/imu/adis.c | 63 ++
> > > --
> > > include/linux/iio/imu/adis.h | 15 -
> > > 3 files changed, 61 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/iio/imu/Kconfig b/drivers/iio/imu/Kconfig
> > > index 60bb1029e759..63036cf473c7 100644
> > > --- a/drivers/iio/imu/Kconfig
> > > +++ b/drivers/iio/imu/Kconfig
> > > @@ -85,6 +85,7 @@ endmenu
> > >
> > > config IIO_ADIS_LIB
> > > tristate
> > > + depends on GPIOLIB
> > > help
> > > A set of IO helper functions for the Analog Devices ADIS*
> > > device family.
> > >
> > > diff --git a/drivers/iio/imu/adis.c b/drivers/iio/imu/adis.c
> > > index d02b1911b0f2..1eca5271380e 100644
> > > --- a/drivers/iio/imu/adis.c
> > > +++ b/drivers/iio/imu/adis.c
> > > @@ -7,6 +7,7 @@
> > > */
> > >
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -365,36 +366,64 @@ static int adis_self_test(struct adis *adis)
> > > }
> > >
> > > /**
> > > - * adis_inital_startup() - Performs device self-test
> > > + * __adis_initial_startup() - Device initial setup
> > > * @adis: The adis device
> > > *
> > > + * This functions makes sure the device is not in reset, via rst
> > > pin.
> > > + * Furthermore it performs a SW reset (only in the case we are not
> > > coming from
> > > + * reset already) and a self test. It also compares the product id
> > > with the
> > > + * device id if the prod_id_reg variable is set.
> > > + *
> > > * Returns 0 if the device is operational, a negative error code
> > > otherwise.
> > > *
> > > * This function should be called early on in the device
> > > initialization sequence
> > > * to ensure that the device is in a sane and known state and that
> > > it is usable.
> > > */
> > > -int adis_initial_startup(struct adis *adis)
> > > +int __adis_initial_startup(struct adis *adis)
> > > {
> > > int ret;
> > > -
> > > - mutex_lock(>state_lock);
> > > + struct gpio_desc *gpio;
> > > + const struct adis_timeout *timeouts = adis->data->timeouts;
> > > + const char *iio_name = spi_get_device_id(adis->spi)->name;
> > > + u16 prod_id, dev_id;
> > > +
> > > + /* check if the device has rst pin low */
> > > + gpio = devm_gpiod_get_optional(>spi->dev, "reset",
> > > GPIOD_ASIS);
> > > + if (IS_ERR(gpio)) {
> > > + return PTR_ERR(gpio);
> >
> > Given you are returning here, no need for else to follow
> >
> > if (gpio...
> >
>
> Definitely...
>
> > > + } else if (gpio && gpiod_get_value_cansleep(gpio)) {
> > > + /* bring device out of reset */
> > > + gpiod_set_value_cansleep(gpio, 0);
> >
> > Hmm. So is a software reset the best option if we have a hardware
> > reset
> > line but it's not currently in the reset mode?
> >
>
> Hmm, that's a fair question. No
Re: [PATCH 2/4] iio: imu: adis: Refactor adis_initial_startup
On Mon, 20 Jan 2020 16:20:49 +0200
Alexandru Ardelean wrote:
> From: Nuno Sá
>
> All the ADIS devices perform, at the beginning, a self test to make sure
> the device is in a sane state. Furthermore, some drivers also do a call
> to `adis_reset()` before the test which is also a good practice. This
> patch unifies all those operation so that, there's no need for code
> duplication. Furthermore, the rst pin is also checked to make sure the
> device is not in HW reset. On top of this, some drivers also read the
> device product id and compare it with the device being probed to make
> sure the correct device is being handled. This can also be passed to the
> library by introducing a variable holding the PROD_ID register of the
> device.
>
> Signed-off-by: Nuno Sá
> Signed-off-by: Alexandru Ardelean
> ---
> drivers/iio/imu/Kconfig | 1 +
> drivers/iio/imu/adis.c | 63 ++--
> include/linux/iio/imu/adis.h | 15 -
> 3 files changed, 61 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/iio/imu/Kconfig b/drivers/iio/imu/Kconfig
> index 60bb1029e759..63036cf473c7 100644
> --- a/drivers/iio/imu/Kconfig
> +++ b/drivers/iio/imu/Kconfig
> @@ -85,6 +85,7 @@ endmenu
>
> config IIO_ADIS_LIB
> tristate
> + depends on GPIOLIB
> help
> A set of IO helper functions for the Analog Devices ADIS* device
> family.
>
> diff --git a/drivers/iio/imu/adis.c b/drivers/iio/imu/adis.c
> index d02b1911b0f2..1eca5271380e 100644
> --- a/drivers/iio/imu/adis.c
> +++ b/drivers/iio/imu/adis.c
> @@ -7,6 +7,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -365,36 +366,64 @@ static int adis_self_test(struct adis *adis)
> }
>
> /**
> - * adis_inital_startup() - Performs device self-test
> + * __adis_initial_startup() - Device initial setup
> * @adis: The adis device
> *
> + * This functions makes sure the device is not in reset, via rst pin.
> + * Furthermore it performs a SW reset (only in the case we are not coming
> from
> + * reset already) and a self test. It also compares the product id with the
> + * device id if the prod_id_reg variable is set.
> + *
> * Returns 0 if the device is operational, a negative error code otherwise.
> *
> * This function should be called early on in the device initialization
> sequence
> * to ensure that the device is in a sane and known state and that it is
> usable.
> */
> -int adis_initial_startup(struct adis *adis)
> +int __adis_initial_startup(struct adis *adis)
> {
> int ret;
> -
> - mutex_lock(>state_lock);
> + struct gpio_desc *gpio;
> + const struct adis_timeout *timeouts = adis->data->timeouts;
> + const char *iio_name = spi_get_device_id(adis->spi)->name;
> + u16 prod_id, dev_id;
> +
> + /* check if the device has rst pin low */
> + gpio = devm_gpiod_get_optional(>spi->dev, "reset", GPIOD_ASIS);
> + if (IS_ERR(gpio)) {
> + return PTR_ERR(gpio);
Given you are returning here, no need for else to follow
if (gpio...
> + } else if (gpio && gpiod_get_value_cansleep(gpio)) {
> + /* bring device out of reset */
> + gpiod_set_value_cansleep(gpio, 0);
Hmm. So is a software reset the best option if we have a hardware reset
line but it's not currently in the reset mode?
> + msleep(timeouts->reset_ms);
> + } else {
> + ret = __adis_reset(adis);
> + if (ret)
> + return ret;
> + }
>
> ret = adis_self_test(adis);
> - if (ret) {
> - dev_err(>spi->dev, "Self-test failed, trying reset.\n");
> - __adis_reset(adis);
> - ret = adis_self_test(adis);
> - if (ret) {
> - dev_err(>spi->dev, "Second self-test failed,
> giving up.\n");
> - goto out_unlock;
> - }
> - }
> + if (ret)
> + return ret;
>
> -out_unlock:
> - mutex_unlock(>state_lock);
> - return ret;
> + if (!adis->data->prod_id_reg)
> + return 0;
> +
> + ret = adis_read_reg_16(adis, adis->data->prod_id_reg, _id);
> + if (ret)
> + return ret;
> +
> + ret = sscanf(iio_name, "adis%hu\n", _id);
Hmm. I have a general dislike of pulling part name strings apart to get
IDs. It tends to break when someone comes along and adds a part with new
branding. Perhaps just put it in the relevant device part specific structures
directly?
> + if (ret != 1)
> + return -EINVAL;
> +
> + if (prod_id != dev_id)
> + dev_warn(>spi->dev,
> + "Device ID(%u) and product ID(%u) do not match.",
> + dev_id, prod_id);
> +
> + return 0;
> }
> -EXPORT_SYMBOL_GPL(adis_initial_startup);
> +EXPORT_SYMBOL_GPL(__adis_initial_startup);
>
> /**
> * adis_single_conversion() - Performs a single sample conversion
> diff --git
Re: [PATCH v6 2/2] dt-bindings: iio: accel: add binding documentation for ADIS16240
On Fri, 13 Dec 2019 13:10:36 -0600 Rob Herring wrote: > On Sat, 7 Dec 2019 01:53:39 -0300, Rodrigo Carvalho wrote: > > This patch add device tree binding documentation for ADIS16240. > > > > Signed-off-by: Rodrigo Carvalho > > --- > > V6: > > - Update SPDX license identifier > > > > .../bindings/iio/accel/adi,adis16240.yaml | 49 +++ > > 1 file changed, 49 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml > > > > Please add Acked-by/Reviewed-by tags when posting new versions. However, > there's no need to repost patches *only* to add the tags. The upstream > maintainer will do that for acks received on the version they apply. > > If a tag was not added on purpose, please state why and what changed. Applied to the togreg branch of iio.git, picking up Rob's tag from v5. Pushed out as testing for the autobuilders to poke at it. Thanks, Jonathan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 2/2] dt-bindings: iio: accel: add binding documentation for ADIS16240
On Thu, 5 Dec 2019 09:21:29 -0600
Rob Herring wrote:
> On Sat, Nov 23, 2019 at 08:35:10PM -0300, Rodrigo Carvalho wrote:
> > This patch add device tree binding documentation for ADIS16240.
> >
> > Signed-off-by: Rodrigo Ribeiro Carvalho
>
> checkpatch.pl complains about a mismatch between the author and S-o-b.
The open question on patch 1 is resolved, so respin with the points Rob pointed
out her resolved and I'll pick up v6.
Thanks,
Jonathan
>
> > ---
> > V5:
> > - None
> >
> > .../bindings/iio/accel/adi,adis16240.yaml | 49 +++
> > 1 file changed, 49 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> > b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> > new file mode 100644
> > index ..8e902f7c49e6
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> > @@ -0,0 +1,49 @@
> > +# SPDX-License-Identifier: GPL-2.0
>
> Dual license new bindings please: (GPL-2.0-only OR BSD-2-Clause)
>
> With that,
>
> Reviewed-by: Rob Herring
>
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iio/accel/adi,adis16240.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: ADIS16240 Programmable Impact Sensor and Recorder driver
> > +
> > +maintainers:
> > + - Alexandru Ardelean
> > +
> > +description: |
> > + ADIS16240 Programmable Impact Sensor and Recorder driver that supports
> > + SPI interface.
> > +https://www.analog.com/en/products/adis16240.html
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - adi,adis16240
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + interrupts:
> > +maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +spi0 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +/* Example for a SPI device node */
> > +accelerometer@0 {
> > +compatible = "adi,adis16240";
> > +reg = <0>;
> > +spi-max-frequency = <250>;
> > +interrupt-parent = <>;
> > +interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> > +};
> > +};
> > --
> > 2.24.0
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] dt-bindings: iio: accel: add binding documentation for ADIS16240
On Tue, 3 Dec 2019 16:38:50 + Mark Brown wrote: > On Sun, Dec 01, 2019 at 11:40:32AM +0000, Jonathan Cameron wrote: > > > +CC Mark as we probably need a more general view point on > > the question of whether SPI mode should be enforced by binding > > or in the driver. > > Not sure I see the question here, I think I was missing a bit of > the conversation? It's perfectly fine for a driver to specify a > mode, if the hardware always uses some unusual mode then there's > no sense in forcing every single DT to set the same mode. On the > other hand if there's some configuration for the driver that was > handling some board specific configuration that there's already > some generic SPI support for setting then it seems odd to have a > custom driver specific configuration mechanism. > If the driver picks a mode because that's what it says on the datasheet it prevents odd board configurations from working. The question becomes whether it makes sense in general to assume those odd board conditions don't exist until we actually have one, or to assume that they might and push the burden on to all DT files. Traditionally in IIO at least we've mostly taken the view the DT should be right and complete and had bindings state what normal parameters must be for it to work (assuming no inverters etc) If we encode it in the driver, and we later meet such a board we end up with a custom dance to query the DT parameters again and only override if present. We can't rely on the core SPI handling because I don't think there is any means of specifying a default. We can adopt the view that in general these weird boards with inverters are weird and just handle them when they occur. Sounds like that is your preference, at least for new parts. For old ones we have no idea if there are boards out there using them with inverters so easiest is probably to just carry on putting them in the DT bindings. Jonathan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 1/2] staging: iio: accel: adis16240: enforce SPI mode on probe function
On Mon, 25 Nov 2019 07:55:39 +
"Ardelean, Alexandru" wrote:
> On Sat, 2019-11-23 at 20:35 -0300, Rodrigo Carvalho wrote:
> > [External]
> >
> > According to the datasheet, this driver supports only SPI mode 3,
> > so we should enforce it and call spi_setup() on probe function.
> >
> > Signed-off-by: Rodrigo Ribeiro Carvalho
> > ---
> > V5:
> > - Add this patch to the patchset
> >
> > drivers/staging/iio/accel/adis16240.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/staging/iio/accel/adis16240.c
> > b/drivers/staging/iio/accel/adis16240.c
> > index 82099db4bf0c..77b6b81767b9 100644
> > --- a/drivers/staging/iio/accel/adis16240.c
> > +++ b/drivers/staging/iio/accel/adis16240.c
> > @@ -400,6 +400,13 @@ static int adis16240_probe(struct spi_device *spi)
> > indio_dev->num_channels = ARRAY_SIZE(adis16240_channels);
> > indio_dev->modes = INDIO_DIRECT_MODE;
> >
> > + spi->mode = SPI_MODE_3;
>
> A generic question from me here, since I am not sure.
>
> Would this limit the configurations of this chip on the board?
> In case there is some level-inverter [for various weird reasons] on the
> board, this may not work, because the SPI controller would need CPOL to be
> 0.
>
> Not sure if this question is valid, or whether we need to care about such
> configurations.
It's a good question as this sort of trick is used sometimes. Let's see
what responses we get to the other branch of this thread before moving forwards
with this.
Jonathan
>
> Thanks
> Alex
>
> > + ret = spi_setup(spi);
> > + if (ret) {
> > + dev_err(>dev, "spi_setup failed!\n");
> > + return ret;
> > + }
> > +
> > ret = adis_init(st, indio_dev, spi, _data);
> > if (ret)
> > return ret;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] dt-bindings: iio: accel: add binding documentation for ADIS16240
+CC Mark as we probably need a more general view point on
the question of whether SPI mode should be enforced by binding
or in the driver.
On Mon, 25 Nov 2019 07:51:30 +
"Ardelean, Alexandru" wrote:
> On Sat, 2019-11-23 at 11:41 +0000, Jonathan Cameron wrote:
> > On Sat, 23 Nov 2019 02:19:27 -0300
> > Rodrigo Carvalho wrote:
> >
> > > This patch add device tree binding documentation for ADIS16240.
> > >
> > > Signed-off-by: Rodrigo Ribeiro Carvalho
>
> My bad for the late timing on this.
> I'm slightly more fresh on Mondays.
> But I will get overloaded with work in a few hours, so I may not have time
> ot respond.
>
> > No problem with this patch, but I definitely want to see an accompanying
> > one enforcing the SPI mode in the driver.
> >
>
> So, then the binding should probably also define spi-cpol & spi-cpha
> as mandatory.
> Maybe, the driver would do a check and print a warning.
>
> I'm noticing that this device uses SPI mode 3, but this DT binding defaults
> to SPI mode 0
>
> > Right now the driver doesn't set it and so I'm fairly sure not putting
> > it in the binding will leave you with a non working device.
> >
> > The right option if only one option is supported is for the driver
> > to call spi_setup with the relevant options.
> >
>
> What if the board uses some level inverters [because of some weird reason]
> and that messes up with the SPI mode?
> It's not common, but it is possible.
I have wondered the same and have a few boards that do this sort of thing.
My personal feeling is that such level convertors should have explicit
representation rather than being hidden in changes to
the devicetree. Perhaps via a single input single output mux that
would wrap up the actions of any inverters in the path.
As you say, the alternative is to just leave it to the devicetree bindings.
Jonathan
>
> > Thanks,
> >
> > Jonathan
> >
> > > ---
> > > V4:
> > >- Remove spi-cpha and spi-cpol in binding example, since this driver
> > > supports only one timing mode.
> > > .../bindings/iio/accel/adi,adis16240.yaml | 49 +++
> > > 1 file changed, 49 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> > > b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> > > new file mode 100644
> > > index ..8e902f7c49e6
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> > > @@ -0,0 +1,49 @@
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/iio/accel/adi,adis16240.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: ADIS16240 Programmable Impact Sensor and Recorder driver
> > > +
> > > +maintainers:
> > > + - Alexandru Ardelean
> > > +
> > > +description: |
> > > + ADIS16240 Programmable Impact Sensor and Recorder driver that
> > > supports
> > > + SPI interface.
> > > +https://www.analog.com/en/products/adis16240.html
> > > +
> > > +properties:
> > > + compatible:
> > > +enum:
> > > + - adi,adis16240
> > > +
> > > + reg:
> > > +maxItems: 1
> > > +
> > > + interrupts:
> > > +maxItems: 1
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - interrupts
> > > +
> > > +examples:
> > > + - |
> > > +#include
> > > +#include
> > > +spi0 {
> > > +#address-cells = <1>;
> > > +#size-cells = <0>;
> > > +
> > > +/* Example for a SPI device node */
> > > +accelerometer@0 {
> > > +compatible = "adi,adis16240";
> > > +reg = <0>;
> > > +spi-max-frequency = <250>;
> > > +interrupt-parent = <>;
> > > +interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> > > +};
> > > +};
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/4] iio: adc: Add support for AD7091R5 ADC
On Mon, 25 Nov 2019 11:26:27 +
"Ardelean, Alexandru" wrote:
> On Tue, 2019-10-29 at 18:29 +0200, Beniamin Bia wrote:
> > [External]
> >
> > From: Paul Cercueil
> >
> > AD7091 is 4-Channel, I2C, Ultra Low Power,12-Bit ADC.
> >
> > Datasheet:
> > Link:
> > https://www.analog.com/media/en/technical-documentation/data-sheets/ad7091r-5.pdf
> >
> > Signed-off-by: Paul Cercueil
> > Co-developed-by: Beniamin Bia
> > Signed-off-by: Beniamin Bia
> > ---
> > Changes in v2:
> > -blank lines removed
> > -prefix added to macros
> > -comments rework
> > -error checking syntax changed
> > -iio mutex replaced by a mutex
> > -device remove function was removed and later replaced by devm_add_action
> > -regmap include removed from header
> >
> > drivers/iio/adc/Kconfig| 7 +
> > drivers/iio/adc/Makefile | 1 +
> > drivers/iio/adc/ad7091r-base.c | 264 +
> > drivers/iio/adc/ad7091r-base.h | 25
> > drivers/iio/adc/ad7091r5.c | 102 +
> > 5 files changed, 399 insertions(+)
> > create mode 100644 drivers/iio/adc/ad7091r-base.c
> > create mode 100644 drivers/iio/adc/ad7091r-base.h
> > create mode 100644 drivers/iio/adc/ad7091r5.c
> >
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 7e3286265a38..80b1b9551749 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -22,6 +22,13 @@ config AD7124
> > To compile this driver as a module, choose M here: the module
> > will be
> > called ad7124.
> >
> > +config AD7091R5
> > + tristate "Analog Devices AD7091R5 ADC Driver"
> > + depends on I2C
> > + select REGMAP_I2C
> > + help
> > + Say yes here to build support for Analog Devices AD7091R-5 ADC.
> > +
>
> Sorry for the lateness here.
> Is it too late to mention to put this before the AD7124 driver?
> Same question for Makefile.
Good spot, but at this stage please send a follow up patch
tidying the ordering up.
Thanks,
Jonathan
>
> This is to keep things alphabetically sorted.
>
> Thanks
> Alex
>
> > config AD7266
> > tristate "Analog Devices AD7265/AD7266 ADC driver"
> > depends on SPI_MASTER
> > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> > index ef9cc485fb67..55e44735aaac 100644
> > --- a/drivers/iio/adc/Makefile
> > +++ b/drivers/iio/adc/Makefile
> > @@ -6,6 +6,7 @@
> > # When adding new entries keep the list in alphabetical order
> > obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o
> > obj-$(CONFIG_AD7124) += ad7124.o
> > +obj-$(CONFIG_AD7091R5) += ad7091r5.o ad7091r-base.o
> > obj-$(CONFIG_AD7266) += ad7266.o
> > obj-$(CONFIG_AD7291) += ad7291.o
> > obj-$(CONFIG_AD7298) += ad7298.o
> > diff --git a/drivers/iio/adc/ad7091r-base.c b/drivers/iio/adc/ad7091r-
> > base.c
> > new file mode 100644
> > index ..c2500f614d54
> > --- /dev/null
> > +++ b/drivers/iio/adc/ad7091r-base.c
> > @@ -0,0 +1,264 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * AD7091RX Analog to Digital converter driver
> > + *
> > + * Copyright 2014-2019 Analog Devices Inc.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "ad7091r-base.h"
> > +
> > +#define AD7091R_REG_RESULT 0
> > +#define AD7091R_REG_CHANNEL 1
> > +#define AD7091R_REG_CONF2
> > +#define AD7091R_REG_ALERT 3
> > +#define AD7091R_REG_CH_LOW_LIMIT(ch) ((ch) * 3 + 4)
> > +#define AD7091R_REG_CH_HIGH_LIMIT(ch) ((ch) * 3 + 5)
> > +#define AD7091R_REG_CH_HYSTERESIS(ch) ((ch) * 3 + 6)
> > +
> > +/* AD7091R_REG_RESULT */
> > +#define AD7091R_REG_RESULT_CH_ID(x)(((x) >> 13) & 0x3)
> > +#define AD7091R_REG_RESULT_CONV_RESULT(x) ((x) & 0xfff)
> > +
> > +/* AD7091R_REG_CONF */
> > +#define AD7091R_REG_CONF_AUTO BIT(8)
> > +#define AD7091R_REG_CONF_CMDBIT(10)
> > +
> > +#define AD7091R_REG_CONF_MODE_MASK \
> > + (AD7091R_REG_CONF_AUTO | AD7091R_REG_CONF_CMD)
> > +
> > +enum ad7091r_mode {
> > + AD7091R_MODE_SAMPLE,
> > + AD7091R_MODE_COMMAND,
> > + AD7091R_MODE_AUTOCYCLE,
> > +};
> > +
> > +struct ad7091r_state {
> > + struct device *dev;
> > + struct regmap *map;
> > + const struct ad7091r_chip_info *chip_info;
> > + enum ad7091r_mode mode;
> > + struct mutex lock;
> > +};
> > +
> > +static int ad7091r_set_mode(struct ad7091r_state *st, enum ad7091r_mode
> > mode)
> > +{
> > + int ret;
> > +
> > + switch (mode) {
> > + case AD7091R_MODE_SAMPLE:
> > + ret = regmap_update_bits(st->map, AD7091R_REG_CONF,
> > +AD7091R_REG_CONF_MODE_MASK, 0);
> > + break;
> > + case AD7091R_MODE_COMMAND:
> > + ret = regmap_update_bits(st->map, AD7091R_REG_CONF,
> > +AD7091R_REG_CONF_MODE_MASK,
> > +AD7091R_REG_CONF_CMD);
> > + break;
> > + case AD7091R_MODE_AUTOCYCLE:
> > + ret = regmap_update_bits(st->map,
Re: [PATCH v4] dt-bindings: iio: accel: add binding documentation for ADIS16240
On Sat, 23 Nov 2019 02:19:27 -0300
Rodrigo Carvalho wrote:
> This patch add device tree binding documentation for ADIS16240.
>
> Signed-off-by: Rodrigo Ribeiro Carvalho
No problem with this patch, but I definitely want to see an accompanying
one enforcing the SPI mode in the driver.
Right now the driver doesn't set it and so I'm fairly sure not putting
it in the binding will leave you with a non working device.
The right option if only one option is supported is for the driver
to call spi_setup with the relevant options.
Thanks,
Jonathan
> ---
> V4:
>- Remove spi-cpha and spi-cpol in binding example, since this driver
> supports only one timing mode.
> .../bindings/iio/accel/adi,adis16240.yaml | 49 +++
> 1 file changed, 49 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> new file mode 100644
> index ..8e902f7c49e6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> @@ -0,0 +1,49 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/accel/adi,adis16240.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ADIS16240 Programmable Impact Sensor and Recorder driver
> +
> +maintainers:
> + - Alexandru Ardelean
> +
> +description: |
> + ADIS16240 Programmable Impact Sensor and Recorder driver that supports
> + SPI interface.
> +https://www.analog.com/en/products/adis16240.html
> +
> +properties:
> + compatible:
> +enum:
> + - adi,adis16240
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +examples:
> + - |
> +#include
> +#include
> +spi0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +/* Example for a SPI device node */
> +accelerometer@0 {
> +compatible = "adi,adis16240";
> +reg = <0>;
> +spi-max-frequency = <250>;
> +interrupt-parent = <>;
> +interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +};
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 1/4] iio: adc: Add support for AD7091R5 ADC
On Fri, 15 Nov 2019 15:57:20 +0200
Beniamin Bia wrote:
> From: Paul Cercueil
>
> AD7091R5 is 4-Channel, I2C, Ultra Low Power,12-Bit ADC.
>
> This driver will also support AD7091R2/4/8 in the future.
>
> Datasheet:
> Link:
> https://www.analog.com/media/en/technical-documentation/data-sheets/ad7091r-5.pdf
>
> Signed-off-by: Paul Cercueil
> Co-developed-by: Beniamin Bia
> Signed-off-by: Beniamin Bia
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
> ---
> Changes in v5:
> -nothing changed
>
> drivers/iio/adc/Kconfig| 7 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/ad7091r-base.c | 260 +
> drivers/iio/adc/ad7091r-base.h | 25
> drivers/iio/adc/ad7091r5.c | 108 ++
> 5 files changed, 401 insertions(+)
> create mode 100644 drivers/iio/adc/ad7091r-base.c
> create mode 100644 drivers/iio/adc/ad7091r-base.h
> create mode 100644 drivers/iio/adc/ad7091r5.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 7e3286265a38..80b1b9551749 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -22,6 +22,13 @@ config AD7124
> To compile this driver as a module, choose M here: the module will be
> called ad7124.
>
> +config AD7091R5
> + tristate "Analog Devices AD7091R5 ADC Driver"
> + depends on I2C
> + select REGMAP_I2C
> + help
> + Say yes here to build support for Analog Devices AD7091R-5 ADC.
> +
> config AD7266
> tristate "Analog Devices AD7265/AD7266 ADC driver"
> depends on SPI_MASTER
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index ef9cc485fb67..55e44735aaac 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -6,6 +6,7 @@
> # When adding new entries keep the list in alphabetical order
> obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o
> obj-$(CONFIG_AD7124) += ad7124.o
> +obj-$(CONFIG_AD7091R5) += ad7091r5.o ad7091r-base.o
> obj-$(CONFIG_AD7266) += ad7266.o
> obj-$(CONFIG_AD7291) += ad7291.o
> obj-$(CONFIG_AD7298) += ad7298.o
> diff --git a/drivers/iio/adc/ad7091r-base.c b/drivers/iio/adc/ad7091r-base.c
> new file mode 100644
> index ..854de7c654c2
> --- /dev/null
> +++ b/drivers/iio/adc/ad7091r-base.c
> @@ -0,0 +1,260 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * AD7091RX Analog to Digital converter driver
> + *
> + * Copyright 2014-2019 Analog Devices Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "ad7091r-base.h"
> +
> +#define AD7091R_REG_RESULT 0
> +#define AD7091R_REG_CHANNEL 1
> +#define AD7091R_REG_CONF2
> +#define AD7091R_REG_ALERT 3
> +#define AD7091R_REG_CH_LOW_LIMIT(ch) ((ch) * 3 + 4)
> +#define AD7091R_REG_CH_HIGH_LIMIT(ch) ((ch) * 3 + 5)
> +#define AD7091R_REG_CH_HYSTERESIS(ch) ((ch) * 3 + 6)
> +
> +/* AD7091R_REG_RESULT */
> +#define AD7091R_REG_RESULT_CH_ID(x) (((x) >> 13) & 0x3)
> +#define AD7091R_REG_RESULT_CONV_RESULT(x) ((x) & 0xfff)
> +
> +/* AD7091R_REG_CONF */
> +#define AD7091R_REG_CONF_AUTO BIT(8)
> +#define AD7091R_REG_CONF_CMDBIT(10)
> +
> +#define AD7091R_REG_CONF_MODE_MASK \
> + (AD7091R_REG_CONF_AUTO | AD7091R_REG_CONF_CMD)
> +
> +enum ad7091r_mode {
> + AD7091R_MODE_SAMPLE,
> + AD7091R_MODE_COMMAND,
> + AD7091R_MODE_AUTOCYCLE,
> +};
> +
> +struct ad7091r_state {
> + struct device *dev;
> + struct regmap *map;
> + const struct ad7091r_chip_info *chip_info;
> + enum ad7091r_mode mode;
> + struct mutex lock; /*lock to prevent concurent reads */
> +};
> +
> +static int ad7091r_set_mode(struct ad7091r_state *st, enum ad7091r_mode mode)
> +{
> + int ret, conf;
> +
> + switch (mode) {
> + case AD7091R_MODE_SAMPLE:
> + conf = 0;
> + break;
> + case AD7091R_MODE_COMMAND:
> + conf = AD7091R_REG_CONF_CMD;
> + break;
> + case AD7091R_MODE_AUTOCYCLE:
> + conf = AD7091R_REG_CONF_AUTO;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + ret = regmap_update_bits(st->map, AD7091R_REG_CONF,
> + AD7091R_REG_CONF_MODE_MASK, conf);
> + if (ret)
> + return ret;
> +
> + st->mode = mode;
> +
> + return 0;
> +}
> +
> +static int ad7091r_set_channel(struct ad7091r_state *st, unsigned int
> channel)
> +{
> + unsigned int dummy;
> + int ret;
> +
> + /* AD7091R_REG_CHANNEL specified which channels to be converted */
> + ret = regmap_write(st->map, AD7091R_REG_CHANNEL,
> + BIT(channel) | (BIT(channel) << 8));
> + if (ret)
> + return ret;
> +
> + /*
> + * There is a latency of one conversion before the channel conversion
> + * sequence is updated
> + */
> + return regmap_read(st->map, AD7091R_REG_RESULT, );
Re: [PATCH v5 2/4] iio: adc: ad7091r5: Add scale and external VREF support
On Fri, 15 Nov 2019 15:57:21 +0200
Beniamin Bia wrote:
> From: Paul Cercueil
>
> The scale can now be obtained with the "in_voltage_scale" file.
> By default, the scale returned corresponds to the internal VREF of 2.5V.
>
> It is possible to use an external VREF (through the REFIN/REFOUT pin of
> the chip), by passing a regulator to the driver. The scale will then be
> calculated according to the voltage reported by the regulator.
>
> Signed-off-by: Paul Cercueil
> Co-developed-by: Beniamin Bia
> Signed-off-by: Beniamin Bia
Doesn't build. However I've fixed it up and applied
to the togreg branch of iio.git pushed out as testing so the
build bots can run more tests.
Please check the result.
Jonathan
> ---
> Changes in v5:
> -check if error is -eprobe instead of eprobe
> -one bracket aligned
>
> drivers/iio/adc/ad7091r-base.c | 38 ++
> drivers/iio/adc/ad7091r-base.h | 1 +
> drivers/iio/adc/ad7091r5.c | 5 +
> 3 files changed, 44 insertions(+)
>
> diff --git a/drivers/iio/adc/ad7091r-base.c b/drivers/iio/adc/ad7091r-base.c
> index 854de7c654c2..58fcf1ff8c76 100644
> --- a/drivers/iio/adc/ad7091r-base.c
> +++ b/drivers/iio/adc/ad7091r-base.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
>
> #include "ad7091r-base.h"
>
> @@ -42,6 +43,7 @@ enum ad7091r_mode {
> struct ad7091r_state {
> struct device *dev;
> struct regmap *map;
> + struct regulator *vref;
> const struct ad7091r_chip_info *chip_info;
> enum ad7091r_mode mode;
> struct mutex lock; /*lock to prevent concurent reads */
> @@ -141,6 +143,21 @@ static int ad7091r_read_raw(struct iio_dev *iio_dev,
> ret = IIO_VAL_INT;
> break;
>
> + case IIO_CHAN_INFO_SCALE:
> + if (st->vref) {
> + ret = regulator_get_voltage(st->vref);
> + if (ret < 0)
> + goto unlock;
> +
> + *val = ret / 1000;
> + } else {
> + *val = st->chip_info->vref_mV;
> + }
> +
> + *val2 = chan->scan_type.realbits;
> + ret = IIO_VAL_FRACTIONAL_LOG2;
> + break;
> +
> default:
> ret = -EINVAL;
> break;
> @@ -183,6 +200,13 @@ static irqreturn_t ad7091r_event_handler(int irq, void
> *private)
> return IRQ_HANDLED;
> }
>
> +static void ad7091r_remove(void *data)
> +{
> + struct ad7091r_state *st = data;
> +
> + regulator_disable(st->vref);
> +}
> +
> int ad7091r_probe(struct device *dev, const char *name,
> const struct ad7091r_chip_info *chip_info,
> struct regmap *map, int irq)
> @@ -216,6 +240,20 @@ int ad7091r_probe(struct device *dev, const char *name,
> return ret;
> }
>
> + st->vref = devm_regulator_get_optional(dev, "vref");
> + if (IS_ERR(st->vref)) {
> + if (PTR_ERR(st->reg) == -EPROBE_DEFER)
I'm going to optimistically hope this was a last minute edit and
you have tested this driver thoroughly.
st->vref?
> + return -EPROBE_DEFER;
> + st->vref = NULL;
> + } else {
> + ret = regulator_enable(st->vref);
> + if (ret)
> + return ret;
> + ret = devm_add_action_or_reset(dev, ad7091r_remove, st);
> + if (ret)
> + return ret;
> + }
> +
> /* Use command mode by default to convert only desired channels*/
> ret = ad7091r_set_mode(st, AD7091R_MODE_COMMAND);
> if (ret)
> diff --git a/drivers/iio/adc/ad7091r-base.h b/drivers/iio/adc/ad7091r-base.h
> index b0b4fe01a681..509748aef9b1 100644
> --- a/drivers/iio/adc/ad7091r-base.h
> +++ b/drivers/iio/adc/ad7091r-base.h
> @@ -14,6 +14,7 @@ struct ad7091r_state;
> struct ad7091r_chip_info {
> unsigned int num_channels;
> const struct iio_chan_spec *channels;
> + unsigned int vref_mV;
> };
>
> extern const struct regmap_config ad7091r_regmap_config;
> diff --git a/drivers/iio/adc/ad7091r5.c b/drivers/iio/adc/ad7091r5.c
> index 30ff0108a6ed..9665679c3ea6 100644
> --- a/drivers/iio/adc/ad7091r5.c
> +++ b/drivers/iio/adc/ad7091r5.c
> @@ -35,10 +35,13 @@ static const struct iio_event_spec ad7091r5_events[] = {
> #define AD7091R_CHANNEL(idx, bits, ev, num_ev) { \
> .type = IIO_VOLTAGE, \
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> .indexed = 1, \
> .channel = idx, \
> .event_spec = ev, \
> .num_event_specs = num_ev, \
> + .scan_type.storagebits = 16, \
> + .scan_type.realbits = bits, \
> }
> static const struct iio_chan_spec ad7091r5_channels_irq[] = {
> AD7091R_CHANNEL(0, 12, ad7091r5_events, ARRAY_SIZE(ad7091r5_events)),
> @@ -57,11 +60,13 @@ static const struct iio_chan_spec
> ad7091r5_channels_noirq[] = {
>
Re: [PATCH v5 4/4] MAINTAINERS: add entry for AD7091R5 driver
On Fri, 15 Nov 2019 15:57:23 +0200 Beniamin Bia wrote: > Add Beniamin Bia as a maintainer for AD7091R5 ADC. > > Signed-off-by: Beniamin Bia Applied, Thanks, Jonathan > --- > Changes in v5: > -nothing changed > > MAINTAINERS | 8 > 1 file changed, 8 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 2e01d0f0b0e5..7f1e4b88688f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -893,6 +893,14 @@ S: Supported > F: drivers/iio/dac/ad5758.c > F: Documentation/devicetree/bindings/iio/dac/ad5758.txt > > +ANALOG DEVICES INC AD7091R5 DRIVER > +M: Beniamin Bia > +L: linux-...@vger.kernel.org > +W: http://ez.analog.com/community/linux-device-drivers > +S: Supported > +F: drivers/iio/adc/ad7091r5.c > +F: Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml > + > ANALOG DEVICES INC AD7124 DRIVER > M: Stefan Popa > L: linux-...@vger.kernel.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 3/4] dt-binding: iio: Add documentation for AD7091R5
On Fri, 15 Nov 2019 15:57:22 +0200
Beniamin Bia wrote:
> Documentation for AD7091R5 ADC was added.
>
> Signed-off-by: Beniamin Bia
> Reviewed-by: Rob Herring
Applied.
Thanks,
Jonathan
> ---
> Changes in v5:
> -nothing changed
>
> .../bindings/iio/adc/adi,ad7091r5.yaml| 54 +++
> 1 file changed, 54 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml
> b/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml
> new file mode 100644
> index ..31ffa275f5fa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/adc/adi,ad7091r5.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices AD7091R5 4-Channel 12-Bit ADC
> +
> +maintainers:
> + - Beniamin Bia
> +
> +description: |
> + Analog Devices AD7091R5 4-Channel 12-Bit ADC
> +
> https://www.analog.com/media/en/technical-documentation/data-sheets/ad7091r-5.pdf
> +
> +properties:
> + compatible:
> +enum:
> + - adi,ad7091r5
> +
> + reg:
> +maxItems: 1
> +
> + vref-supply:
> +description:
> + Phandle to the vref power supply
> +
> + interrupts:
> +maxItems: 1
> +
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +adc@2f {
> +compatible = "adi,ad7091r5";
> +reg = <0x2f>;
> +
> +interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> +interrupt-parent = <>;
> +};
> +};
> +...
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] iio: Add ADM1177 Hot Swap Controller and Digital Power Monitor driver
On Tue, 12 Nov 2019 17:35:50 +0200
Beniamin Bia wrote:
> From: Michael Hennerich
>
> ADM1177 is a Hot Swap Controller and Digital Power Monitor with
> Soft Start Pin.
>
> Datasheet:
> Link:
> https://www.analog.com/media/en/technical-documentation/data-sheets/ADM1177.pdf
>
> Signed-off-by: Michael Hennerich
> Co-developed-by: Beniamin Bia
> Signed-off-by: Beniamin Bia
Hi Beniamin,
A couple immediate thoughts.
1. That cc list has some rather non obvious people on it. Unless something
fairly surprising is going on, probably better to cut it back a bit.
2. Why IIO? Not entirely obvious to me. From first glance this is definitely
doing hardware monitoring. If there is a reason there should be a clear
statement here on why.
+CC Guenter and Jean as hwmon maintainers.
Whilst I'm here, a very quick review below.
> ---
> drivers/iio/adc/Kconfig | 12 ++
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/adm1177.c | 257 ++
> 3 files changed, 270 insertions(+)
> create mode 100644 drivers/iio/adc/adm1177.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 9554890a3200..4db8c6dcb595 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -228,6 +228,18 @@ config ASPEED_ADC
> To compile this driver as a module, choose M here: the module will be
> called aspeed_adc.
>
> +config ADM1177
> + tristate "Analog Devices ADM1177 Digital Power Monitor driver"
> + depends on I2C
> + help
> + Say yes here to build support for Analog Devices:
> + ADM1177 Hot Swap Controller and Digital Power Monitor
> + with Soft Start Pin. Provides direct access
> + via sysfs.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called adm1177.
> +
> config AT91_ADC
> tristate "Atmel AT91 ADC"
> depends on ARCH_AT91
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 5ecc481c2967..7899d6a158f3 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_AD7887) += ad7887.o
> obj-$(CONFIG_AD7949) += ad7949.o
> obj-$(CONFIG_AD799X) += ad799x.o
> obj-$(CONFIG_ASPEED_ADC) += aspeed_adc.o
> +obj-$(CONFIG_ADM1177) += adm1177.o
> obj-$(CONFIG_AT91_ADC) += at91_adc.o
> obj-$(CONFIG_AT91_SAMA5D2_ADC) += at91-sama5d2_adc.o
> obj-$(CONFIG_AXP20X_ADC) += axp20x_adc.o
> diff --git a/drivers/iio/adc/adm1177.c b/drivers/iio/adc/adm1177.c
> new file mode 100644
> index ..daec34566a65
> --- /dev/null
> +++ b/drivers/iio/adc/adm1177.c
> @@ -0,0 +1,257 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * ADM1177 Hot Swap Controller and Digital Power Monitor with Soft Start Pin
> + *
> + * Copyright 2015-2019 Analog Devices Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +/* Command Byte Operations */
> +#define ADM1177_CMD_V_CONT BIT(0)
> +#define ADM1177_CMD_V_ONCE BIT(1)
> +#define ADM1177_CMD_I_CONT BIT(2)
> +#define ADM1177_CMD_I_ONCE BIT(3)
> +#define ADM1177_CMD_VRANGE BIT(4)
> +#define ADM1177_CMD_STATUS_RDBIT(6)
> +
> +/* Extended Register */
> +#define ADM1177_REG_ALERT_EN 1
> +#define ADM1177_REG_ALERT_TH 2
> +#define ADM1177_REG_CONTROL 3
> +
> +/* ADM1177_REG_ALERT_EN */
> +#define ADM1177_EN_ADC_OC1 BIT(0)
> +#define ADM1177_EN_ADC_OC4 BIT(1)
> +#define ADM1177_EN_HS_ALERT BIT(2)
> +#define ADM1177_EN_OFF_ALERT BIT(3)
> +#define ADM1177_CLEARBIT(4)
> +
> +/* ADM1177_REG_CONTROL */
> +#define ADM1177_SWOFFBIT(0)
> +
> +#define ADM1177_BITS 12
> +
> +/**
> + * struct adm1177_state - driver instance specific data
> + * @client pointer to i2c client
> + * @reg regulator info for the the power supply of the
> device
> + * @command internal control register
> + * @r_sense_uohm current sense resistor value
> + * @alert_threshold_ua current limit for shutdown
> + * @vrange_high internal voltage divider
> + */
> +struct adm1177_state {
> + struct i2c_client *client;
> + struct regulator*reg;
> + u8 command;
> + u32 r_sense_uohm;
> + u32 alert_threshold_ua;
> + boolvrange_high;
> +};
> +
> +static int adm1177_read(struct adm1177_state *st, u8 num, u8 *data)
> +{
> + struct i2c_client *client = st->client;
> + int ret = 0;
> +
> + ret = i2c_master_recv(client, data, num);
> + if (ret < 0) {
> + dev_err(>dev, "I2C read error\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int adm1177_write_cmd(struct adm1177_state *st, u8 cmd)
> +{
> + st->command = cmd;
> + return i2c_smbus_write_byte(st->client, cmd);
>
Re: [PATCH v3 2/4] iio: adc: ad7091r5: Add scale and external VREF support
On Thu, 7 Nov 2019 17:07:57 +0200
Beniamin Bia wrote:
> From: Paul Cercueil
>
> The scale can now be obtained with the "in_voltage_scale" file.
> By default, the scale returned corresponds to the internal VREF of 2.5V.
>
> It is possible to use an external VREF (through the REFIN/REFOUT pin of
> the chip), by passing a regulator to the driver. The scale will then be
> calculated according to the voltage reported by the regulator.
>
> Signed-off-by: Paul Cercueil
> Co-developed-by: Beniamin Bia
> Signed-off-by: Beniamin Bia
A suggestion inline for how to simplify the code a little by only
registering the regulator disable if we actually have a regulator.
Thanks,
Jonathan
> ---
> Changes in v3:
> -type cast from void* in remove function removed
> -error checking for devm_add_action_or_reset
>
> drivers/iio/adc/ad7091r-base.c | 41 ++
> drivers/iio/adc/ad7091r-base.h | 1 +
> drivers/iio/adc/ad7091r5.c | 5 +
> 3 files changed, 47 insertions(+)
>
> diff --git a/drivers/iio/adc/ad7091r-base.c b/drivers/iio/adc/ad7091r-base.c
> index 2ebc40dfd927..abb0d9c2ea9c 100644
> --- a/drivers/iio/adc/ad7091r-base.c
> +++ b/drivers/iio/adc/ad7091r-base.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
>
> #include "ad7091r-base.h"
>
> @@ -42,6 +43,7 @@ enum ad7091r_mode {
> struct ad7091r_state {
> struct device *dev;
> struct regmap *map;
> + struct regulator *reg;
> const struct ad7091r_chip_info *chip_info;
> enum ad7091r_mode mode;
> struct mutex lock;
> @@ -142,6 +144,21 @@ static int ad7091r_read_raw(struct iio_dev *iio_dev,
> ret = IIO_VAL_INT;
> break;
>
> + case IIO_CHAN_INFO_SCALE:
> + if (st->reg) {
> + ret = regulator_get_voltage(st->reg);
> + if (ret < 0)
> + goto unlock;
> +
> + *val = ret / 1000;
> + } else {
> + *val = st->chip_info->vref_mV;
> + }
> +
> + *val2 = chan->scan_type.realbits;
> + ret = IIO_VAL_FRACTIONAL_LOG2;
> + break;
> +
> default:
> ret = -EINVAL;
> break;
> @@ -184,6 +201,14 @@ static irqreturn_t ad7091r_event_handler(int irq, void
> *private)
> return IRQ_HANDLED;
> }
>
> +static void ad7091r_remove(void *data)
> +{
> + struct ad7091r_state *st = data;
> +
> + if (st->reg)
> + regulator_disable(st->reg);
> +}
> +
> int ad7091r_probe(struct device *dev, const char *name,
> const struct ad7091r_chip_info *chip_info,
> struct regmap *map, int irq)
> @@ -217,6 +242,22 @@ int ad7091r_probe(struct device *dev, const char *name,
> return ret;
> }
>
> + st->reg = devm_regulator_get_optional(dev, "vref");
> + if (IS_ERR(st->reg)) {
> + if (PTR_ERR(st->reg) == EPROBE_DEFER)
> + return -EPROBE_DEFER;
> +
> + st->reg = NULL;
> + } else {
> + ret = regulator_enable(st->reg);
> + if (ret)
> + return ret;
> + }
> +
> + ret = devm_add_action_or_reset(dev, ad7091r_remove, st);
> + if (ret)
> + return ret;
> +
This is more complex than it needs to be...
st->reg = devm_regulator_get_optional(dev, "vref");
if (IS_ERR(st->reg)) {
if (PTR_ERR(st->reg) == EPROBE_DEFER)
return -EPROBE_DEFER;
st->reg = NULL;
} else {
ret = regulator_enable(st->reg);
if (ret)
return ret;
ret = devm_add_action_or_reset(dec, ad7091r_dis_reg, st);
if (ret)
return ret;
}
with
static void ad7091r_dis_reg(void *data)
{
struct ad7091r_state *st = data;
regulator_disable(st->reg);
}
That way the disable is only registered if we actually have a reg
and hence we don't need to check if we do.
Also, give it a more specific name than reg. Chances are someone
will add the main power supply control sometime in the future.
> /* Use command mode by default to convert only desired channels*/
> ret = ad7091r_set_mode(st, AD7091R_MODE_COMMAND);
> if (ret)
> diff --git a/drivers/iio/adc/ad7091r-base.h b/drivers/iio/adc/ad7091r-base.h
> index 5f1147735953..76b76968d071 100644
> --- a/drivers/iio/adc/ad7091r-base.h
> +++ b/drivers/iio/adc/ad7091r-base.h
> @@ -14,6 +14,7 @@ struct ad7091r_state;
> struct ad7091r_chip_info {
> unsigned int num_channels;
> const struct iio_chan_spec *channels;
> + unsigned int vref_mV;
> };
>
> extern const struct regmap_config ad7091r_regmap_config;
> diff --git a/drivers/iio/adc/ad7091r5.c b/drivers/iio/adc/ad7091r5.c
> index f7b3326032e8..73d18ddfd2c9 100644
> ---
Re: [PATCH v3 1/4] iio: adc: Add support for AD7091R5 ADC
On Thu, 7 Nov 2019 17:07:56 +0200
Beniamin Bia wrote:
> From: Paul Cercueil
>
> AD7091 is 4-Channel, I2C, Ultra Low Power,12-Bit ADC.
>
I'd like to see a bit of info here about what other ad7091r parts exist
to explain the current split in files.
> Datasheet:
> Link:
> https://www.analog.com/media/en/technical-documentation/data-sheets/ad7091r-5.pdf
>
> Signed-off-by: Paul Cercueil
> Co-developed-by: Beniamin Bia
> Signed-off-by: Beniamin Bia
Was a close run thing, but there are just enough minor things between my
review here and Dan's that I think we need a v4 rather than me just cleaning
them up whilst applying.
Thanks,
Jonathan
> ---
> Changes in v3:
> -parameters for functions calls were aligned
> -iio_device_register replaced by devm_iio_device_register
> -duplication of regmap_update_bits calls removed in set_mode
>
> drivers/iio/adc/Kconfig| 7 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/ad7091r-base.c | 261 +
> drivers/iio/adc/ad7091r-base.h | 25
> drivers/iio/adc/ad7091r5.c | 102 +
> 5 files changed, 396 insertions(+)
> create mode 100644 drivers/iio/adc/ad7091r-base.c
> create mode 100644 drivers/iio/adc/ad7091r-base.h
> create mode 100644 drivers/iio/adc/ad7091r5.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 7e3286265a38..80b1b9551749 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -22,6 +22,13 @@ config AD7124
> To compile this driver as a module, choose M here: the module will be
> called ad7124.
>
> +config AD7091R5
> + tristate "Analog Devices AD7091R5 ADC Driver"
> + depends on I2C
> + select REGMAP_I2C
> + help
> + Say yes here to build support for Analog Devices AD7091R-5 ADC.
> +
> config AD7266
> tristate "Analog Devices AD7265/AD7266 ADC driver"
> depends on SPI_MASTER
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index ef9cc485fb67..55e44735aaac 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -6,6 +6,7 @@
> # When adding new entries keep the list in alphabetical order
> obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o
> obj-$(CONFIG_AD7124) += ad7124.o
> +obj-$(CONFIG_AD7091R5) += ad7091r5.o ad7091r-base.o
> obj-$(CONFIG_AD7266) += ad7266.o
> obj-$(CONFIG_AD7291) += ad7291.o
> obj-$(CONFIG_AD7298) += ad7298.o
> diff --git a/drivers/iio/adc/ad7091r-base.c b/drivers/iio/adc/ad7091r-base.c
> new file mode 100644
> index ..2ebc40dfd927
> --- /dev/null
> +++ b/drivers/iio/adc/ad7091r-base.c
> @@ -0,0 +1,261 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * AD7091RX Analog to Digital converter driver
> + *
> + * Copyright 2014-2019 Analog Devices Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "ad7091r-base.h"
> +
> +#define AD7091R_REG_RESULT 0
> +#define AD7091R_REG_CHANNEL 1
> +#define AD7091R_REG_CONF2
> +#define AD7091R_REG_ALERT 3
> +#define AD7091R_REG_CH_LOW_LIMIT(ch) ((ch) * 3 + 4)
> +#define AD7091R_REG_CH_HIGH_LIMIT(ch) ((ch) * 3 + 5)
> +#define AD7091R_REG_CH_HYSTERESIS(ch) ((ch) * 3 + 6)
> +
> +/* AD7091R_REG_RESULT */
> +#define AD7091R_REG_RESULT_CH_ID(x) (((x) >> 13) & 0x3)
> +#define AD7091R_REG_RESULT_CONV_RESULT(x) ((x) & 0xfff)
> +
> +/* AD7091R_REG_CONF */
> +#define AD7091R_REG_CONF_AUTO BIT(8)
> +#define AD7091R_REG_CONF_CMDBIT(10)
> +
> +#define AD7091R_REG_CONF_MODE_MASK \
> + (AD7091R_REG_CONF_AUTO | AD7091R_REG_CONF_CMD)
> +
> +enum ad7091r_mode {
> + AD7091R_MODE_SAMPLE,
> + AD7091R_MODE_COMMAND,
> + AD7091R_MODE_AUTOCYCLE,
> +};
> +
> +struct ad7091r_state {
> + struct device *dev;
> + struct regmap *map;
> + const struct ad7091r_chip_info *chip_info;
> + enum ad7091r_mode mode;
> + struct mutex lock;
Locks should always have documentation so we know exactly what their
scope is.
> +};
> +
> +static int ad7091r_set_mode(struct ad7091r_state *st, enum ad7091r_mode mode)
> +{
> + int ret, conf;
> +
> + switch (mode) {
> + case AD7091R_MODE_SAMPLE:
> + conf = 0;
> + break;
> + case AD7091R_MODE_COMMAND:
> + conf = AD7091R_REG_CONF_CMD;
> + break;
> + case AD7091R_MODE_AUTOCYCLE:
> + conf = AD7091R_REG_CONF_AUTO;
> + break;
> + default:
> + ret = -EINVAL;
> + break;
> + }
> +
> + ret = regmap_update_bits(st->map, AD7091R_REG_CONF,
> + AD7091R_REG_CONF_MODE_MASK, conf);
> + if (ret)
> + return ret;
> +
> + st->mode = mode;
> +
> + return ret;
> +}
> +
> +static int ad7091r_set_channel(struct ad7091r_state *st, unsigned int
> channel)
> +{
> + unsigned int foo;
> + int ret;
> +
> + /* AD7091R_REG_CHANNEL specified which channels to be converted */
> + ret =
Re: [PATCH] staging: iio: adc: ad7280: Add spaces around math operator
On Sat, 9 Nov 2019 16:17:28 +0100 Pedro Ortega wrote: > Add spaces around the minus math operator to increase readability. > > Signed-off-by: Pedro Ortega Hi Pedro, Afraid not. Look at what that macro is actually doing. That's not a maths operator at all. I'm fairly sure we had a plan to actually hide these examples away as we get a few people suggesting this 'fix' ever year. Not sure what happened to them though, I'll have to check back. Sorry about this, but it is a good lesson in making sure you check that the suggestion from checkpatch is actually correct. It's a pattern matcher, it can't always know enough to be able to tell what is going on. Thanks, Jonathan > --- > drivers/staging/iio/adc/ad7280a.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/iio/adc/ad7280a.c > b/drivers/staging/iio/adc/ad7280a.c > index 19a5f244dcae..34ca0d09db85 100644 > --- a/drivers/staging/iio/adc/ad7280a.c > +++ b/drivers/staging/iio/adc/ad7280a.c > @@ -825,14 +825,14 @@ static irqreturn_t ad7280_event_handler(int irq, void > *private) > } > > static IIO_DEVICE_ATTR_NAMED(in_thresh_low_value, > - in_voltage-voltage_thresh_low_value, > + in_voltage - voltage_thresh_low_value, >0644, >ad7280_read_channel_config, >ad7280_write_channel_config, >AD7280A_CELL_UNDERVOLTAGE); > > static IIO_DEVICE_ATTR_NAMED(in_thresh_high_value, > - in_voltage-voltage_thresh_high_value, > + in_voltage - voltage_thresh_high_value, >0644, >ad7280_read_channel_config, >ad7280_write_channel_config, > -- > 2.17.1 > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] dt-bindings: iio: accel: add binding documentation for ADIS16240
On Tue, 5 Nov 2019 14:19:32 -0600
Rob Herring wrote:
> On Thu, Oct 31, 2019 at 09:03:01PM -0300, Rodrigo Carvalho wrote:
> > This patch add device tree binding documentation for ADIS16240.
> >
> > Signed-off-by: Rodrigo Ribeiro Carvalho
> > ---
> > V3:
> >- Remove spi-cpol and spi-cpha field. They don't seem necessary
>
> Not necessary to document or use? The latter requires the former.
>
> If your device only supports one timing mode, then you don't need them
> because it should be implied and the driver can just tell the SPI
> subsystem what mode it requires. If the device can support multiple
> timing modes, then you should document that you are using the
> properties.
The diagram in the datasheet is less than clear and the driver doesn't
currently enforce anything.
Looks like clock is high when in active and fall so CPOL, as per
SPI docs though this might not matter...
Sampling on rising edge (that's the bit that is unclear) so CPHA,
but the timing is such that you can probably get away with not
setting that.
As Rob said, makes sense for driver to enforce the documented correct
mode and not have anything in the binding. We should probably audit
all drivers for this at somepoint and drop the binding requirements
for ones that have only one supported mode.
Jonathan
>
> > .../bindings/iio/accel/adi,adis16240.yaml | 51 +++
> > 1 file changed, 51 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> > b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> > new file mode 100644
> > index ..9a4cd12c4818
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
> > @@ -0,0 +1,51 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iio/accel/adi,adis16240.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: ADIS16240 Programmable Impact Sensor and Recorder driver
> > +
> > +maintainers:
> > + - Alexandru Ardelean
> > +
> > +description: |
> > + ADIS16240 Programmable Impact Sensor and Recorder driver that supports
> > + SPI interface.
> > +https://www.analog.com/en/products/adis16240.html
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - adi,adis16240
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + interrupts:
> > +maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +spi0 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +/* Example for a SPI device node */
> > +accelerometer@0 {
> > +compatible = "adi,adis16240";
> > +reg = <0>;
> > +spi-max-frequency = <250>;
> > +spi-cpol;
> > +spi-cpha;
> > +interrupt-parent = <>;
> > +interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> > +};
> > +};
> > --
> > 2.23.0
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/4] iio: adc: ad7091r5: Add scale and external VREF support
On Mon, 21 Oct 2019 20:06:06 +0300
Beniamin Bia wrote:
> From: Paul Cercueil
>
> The scale can now be obtained with the "in_voltage_scale" file.
> By default, the scale returned corresponds to the internal VREF of 2.5V.
>
> It is possible to use an external VREF (through the REFIN/REFOUT pin of
> the chip), by passing a regulator to the driver. The scale will then be
> calculated according to the voltage reported by the regulator.
>
> Signed-off-by: Paul Cercueil
> Co-developed-by: Beniamin Bia
> Signed-off-by: Beniamin Bia
My only comment on this one is that you could use devm_add_action_or_reset
to deal with the regulator clean up.
> ---
> drivers/iio/adc/ad7091r-base.c | 42 +-
> drivers/iio/adc/ad7091r-base.h | 1 +
> drivers/iio/adc/ad7091r5.c | 5
> 3 files changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/adc/ad7091r-base.c b/drivers/iio/adc/ad7091r-base.c
> index 140413329754..d416f0912531 100644
> --- a/drivers/iio/adc/ad7091r-base.c
> +++ b/drivers/iio/adc/ad7091r-base.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> #define AD7091R_REG_RESULT 0
> #define AD7091R_REG_CHANNEL 1
> @@ -42,6 +43,7 @@ enum ad7091r_mode {
> struct ad7091r_state {
> struct device *dev;
> struct regmap *map;
> + struct regulator *reg;
> const struct ad7091r_chip_info *chip_info;
> enum ad7091r_mode mode;
> };
> @@ -139,6 +141,21 @@ static int ad7091r_read_raw(struct iio_dev *iio_dev,
> ret = IIO_VAL_INT;
> break;
>
> + case IIO_CHAN_INFO_SCALE:
> + if (st->reg) {
> + ret = regulator_get_voltage(st->reg);
> + if (ret < 0)
> + goto unlock;
> +
> + *val = ret / 1000;
> + } else {
> + *val = st->chip_info->vref_mV;
> + }
> +
> + *val2 = chan->scan_type.realbits;
> + ret = IIO_VAL_FRACTIONAL_LOG2;
> + break;
> +
> default:
> ret = -EINVAL;
> break;
> @@ -215,6 +232,18 @@ int ad7091r_probe(struct device *dev, const char *name,
> return ret;
> }
>
> + st->reg = devm_regulator_get_optional(dev, "vref");
> + if (IS_ERR(st->reg)) {
> + if (PTR_ERR(st->reg) == EPROBE_DEFER)
> + return -EPROBE_DEFER;
> +
> + st->reg = NULL;
> + } else {
> + ret = regulator_enable(st->reg);
> + if (ret)
> + return ret;
I would use devm_add_action_or_reset with appropriate wrapper
around disabling the regulator. That will get rid of the
need to manually deal with errors or remove path.
> + }
> +
> /* Use command mode by default */
> ret = ad7091r_set_mode(st, AD7091R_MODE_COMMAND);
> if (ret < 0)
> @@ -222,18 +251,29 @@ int ad7091r_probe(struct device *dev, const char *name,
>
> ret = iio_device_register(iio_dev);
> if (ret)
> - return ret;
> + goto err_disable_reg;
>
> dev_dbg(dev, "Probed\n");
> return 0;
> +
> +err_disable_reg:
> + if (st->reg)
> + regulator_disable(st->reg);
> +
> + return ret;
> }
> EXPORT_SYMBOL_GPL(ad7091r_probe);
>
> int ad7091r_remove(struct device *dev)
> {
> struct iio_dev *iio_dev = dev_get_drvdata(dev);
> + struct ad7091r_state *st = iio_priv(iio_dev);
>
> iio_device_unregister(iio_dev);
> +
> + if (st->reg)
> + regulator_disable(st->reg);
> +
> return 0;
> }
> EXPORT_SYMBOL_GPL(ad7091r_remove);
> diff --git a/drivers/iio/adc/ad7091r-base.h b/drivers/iio/adc/ad7091r-base.h
> index 7a29f86ea82b..cec4fb75fecc 100644
> --- a/drivers/iio/adc/ad7091r-base.h
> +++ b/drivers/iio/adc/ad7091r-base.h
> @@ -18,6 +18,7 @@ struct ad7091r_state;
> struct ad7091r_chip_info {
> unsigned int num_channels;
> const struct iio_chan_spec *channels;
> + unsigned int vref_mV;
> };
>
> extern const struct regmap_config ad7091r_regmap_config;
> diff --git a/drivers/iio/adc/ad7091r5.c b/drivers/iio/adc/ad7091r5.c
> index 1ba838c58c31..65bcd8bb692a 100644
> --- a/drivers/iio/adc/ad7091r5.c
> +++ b/drivers/iio/adc/ad7091r5.c
> @@ -35,10 +35,13 @@ static const struct iio_event_spec ad7091r5_events[] = {
> #define AD7091R_CHANNEL(idx, bits, ev, num_ev) { \
> .type = IIO_VOLTAGE, \
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> .indexed = 1, \
> .channel = idx, \
> .event_spec = ev, \
> .num_event_specs = num_ev, \
> + .scan_type.storagebits = 16, \
> + .scan_type.realbits = bits, \
> }
> static const struct iio_chan_spec ad7091r5_channels_irq[] = {
> AD7091R_CHANNEL(0, 12, ad7091r5_events, ARRAY_SIZE(ad7091r5_events)),
> @@ -58,11 +61,13 @@ static const struct
Re: [PATCH 1/4] iio: adc: Add support for AD7091R5 ADC
On Mon, 21 Oct 2019 20:06:05 +0300
Beniamin Bia wrote:
> From: Paul Cercueil
>
> AD7091 is 4-Channel, I2C, Ultra Low Power,12-Bit ADC.
>
> Datasheet:
> Link:
> https://www.analog.com/media/en/technical-documentation/data-sheets/ad7091r-5.pdf
>
> Signed-off-by: Paul Cercueil
> Co-developed-by: Beniamin Bia
> Signed-off-by: Beniamin Bia
Hi. I'm going to guess this one is a case of upstreaming a driver
that's been in the Analog tree for quite a while. Great if so, but
it has a few rough corners.
See inline,
Thanks,
Jonathan
> ---
> drivers/iio/adc/Kconfig| 7 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/ad7091r-base.c | 273 +
> drivers/iio/adc/ad7091r-base.h | 30
> drivers/iio/adc/ad7091r5.c | 108 +
> 5 files changed, 419 insertions(+)
> create mode 100644 drivers/iio/adc/ad7091r-base.c
> create mode 100644 drivers/iio/adc/ad7091r-base.h
> create mode 100644 drivers/iio/adc/ad7091r5.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 7e3286265a38..80b1b9551749 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -22,6 +22,13 @@ config AD7124
> To compile this driver as a module, choose M here: the module will be
> called ad7124.
>
> +config AD7091R5
> + tristate "Analog Devices AD7091R5 ADC Driver"
> + depends on I2C
> + select REGMAP_I2C
> + help
> + Say yes here to build support for Analog Devices AD7091R-5 ADC.
> +
> config AD7266
> tristate "Analog Devices AD7265/AD7266 ADC driver"
> depends on SPI_MASTER
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index ef9cc485fb67..55e44735aaac 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -6,6 +6,7 @@
> # When adding new entries keep the list in alphabetical order
> obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o
> obj-$(CONFIG_AD7124) += ad7124.o
> +obj-$(CONFIG_AD7091R5) += ad7091r5.o ad7091r-base.o
> obj-$(CONFIG_AD7266) += ad7266.o
> obj-$(CONFIG_AD7291) += ad7291.o
> obj-$(CONFIG_AD7298) += ad7298.o
> diff --git a/drivers/iio/adc/ad7091r-base.c b/drivers/iio/adc/ad7091r-base.c
> new file mode 100644
> index ..140413329754
> --- /dev/null
> +++ b/drivers/iio/adc/ad7091r-base.c
> @@ -0,0 +1,273 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * AD7091RX Analog to Digital converter driver
> + *
> + * Copyright 2014 Analog Devices Inc.
> + *
This blank line doesn't add anything.
> + */
> +
> +#include "ad7091r-base.h"
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define AD7091R_REG_RESULT 0
> +#define AD7091R_REG_CHANNEL 1
> +#define AD7091R_REG_CONF2
> +#define AD7091R_REG_ALERT 3
> +#define AD7091R_REG_CH_LOW_LIMIT(ch) ((ch) * 3 + 4)
> +#define AD7091R_REG_CH_HIGH_LIMIT(ch) ((ch) * 3 + 5)
> +#define AD7091R_REG_CH_HYSTERESIS(ch) ((ch) * 3 + 6)
> +
> +/* AD7091R_REG_RESULT */
> +#define REG_RESULT_CH_ID(x) (((x) >> 13) & 0x3)
Prefix these as well.
> +#define REG_RESULT_CONV_RESULT(x) ((x) & 0xfff)
> +
> +/* AD7091R_REG_CONF */
> +#define REG_CONF_AUTO BIT(8)
> +#define REG_CONF_CMDBIT(10)
> +
> +#define REG_CONF_MODE_MASK (REG_CONF_AUTO | REG_CONF_CMD)
> +
> +enum ad7091r_mode {
> + AD7091R_MODE_SAMPLE,
> + AD7091R_MODE_COMMAND,
> + AD7091R_MODE_AUTOCYCLE,
> +};
> +
> +struct ad7091r_state {
> + struct device *dev;
> + struct regmap *map;
> + const struct ad7091r_chip_info *chip_info;
> + enum ad7091r_mode mode;
> +};
> +
> +static int ad7091r_set_mode(struct ad7091r_state *st, enum ad7091r_mode mode)
> +{
> + int ret;
> +
> + switch (mode) {
> + case AD7091R_MODE_SAMPLE:
> + ret = regmap_update_bits(st->map, AD7091R_REG_CONF,
> + REG_CONF_MODE_MASK, 0);
> + break;
> + case AD7091R_MODE_COMMAND:
> + ret = regmap_update_bits(st->map, AD7091R_REG_CONF,
> + REG_CONF_MODE_MASK, REG_CONF_CMD);
> + break;
> + case AD7091R_MODE_AUTOCYCLE:
> + ret = regmap_update_bits(st->map, AD7091R_REG_CONF,
> + REG_CONF_MODE_MASK, REG_CONF_AUTO);
> + break;
> + default:
> + ret = -EINVAL;
> + break;
> + }
> +
> + if (!ret)
> + st->mode = mode;
I always prefer the error path out of line. Slightly longer but more
consistent with earlier cases.
if (ret)
return ret;
st->mode = mode;
return 0;
> + return ret;
> +}
> +
> +static int ad7091r_set_channel(struct ad7091r_state *st, unsigned int
> channel)
> +{
> + unsigned int foo;
> + int ret;
> +
> + /* AD7091R_REG_CHANNEL is a 8-bit register */
I'm not sure what the comment is telling us...
> + ret = regmap_write(st->map, AD7091R_REG_CHANNEL,
> + BIT(channel) |
Re: [PATCH] staging: iio: ad9834: add a check for devm_clk_get
On Thu, 17 Oct 2019 12:56:33 +
"Ardelean, Alexandru" wrote:
> On Wed, 2019-10-16 at 22:25 +0800, Chuhong Yuan wrote:
> > ad9834_probe misses a check for devm_clk_get and may cause problems.
> > Add a check like what ad9832 does to fix it.
> >
>
> This could also use a Fixes tag, but not a big deal.
>
> Reviewed-by: Alexandru Ardelean
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
As a general point though, the fact that a devm error handler
actually has things to do suggests this code doesn't pass
the obviously correct test.
Nothing to do with this patch mind you!
Jonathan
>
> > Signed-off-by: Chuhong Yuan
> > ---
> > drivers/staging/iio/frequency/ad9834.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/staging/iio/frequency/ad9834.c
> > b/drivers/staging/iio/frequency/ad9834.c
> > index 038d6732c3fd..23026978a5a5 100644
> > --- a/drivers/staging/iio/frequency/ad9834.c
> > +++ b/drivers/staging/iio/frequency/ad9834.c
> > @@ -417,6 +417,10 @@ static int ad9834_probe(struct spi_device *spi)
> > st = iio_priv(indio_dev);
> > mutex_init(>lock);
> > st->mclk = devm_clk_get(>dev, NULL);
> > + if (IS_ERR(st->mclk)) {
> > + ret = PTR_ERR(st->mclk);
> > + goto error_disable_reg;
> > + }
> >
> > ret = clk_prepare_enable(st->mclk);
> > if (ret) {
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: ADIS16240: Remove unused include
On Sat, 14 Sep 2019 02:06:27 +0530 Rohit Sarkar wrote: > Bcc: > Subject: [PATCH] staging: iio: adis16240: remove unused include > Reply-To: Something odd happened here with patch formatting. I fixed it up and applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with it. Thanks, Jonathan > > '#include' isn't being used anywhere. Remove it. > > Signed-off-by: Rohit Sarkar > --- > drivers/staging/iio/accel/adis16240.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/staging/iio/accel/adis16240.c > b/drivers/staging/iio/accel/adis16240.c > index 82099db4bf0c..a480409090c0 100644 > --- a/drivers/staging/iio/accel/adis16240.c > +++ b/drivers/staging/iio/accel/adis16240.c > @@ -7,7 +7,6 @@ > > #include > #include > -#include > #include > #include > #include ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [kbuild-all] [staging:staging-testing 314/401] drivers/iio/common/hid-sensors/hid-sensor-attributes.c:312: undefined reference to `__udivdi3'
On Fri, 6 Sep 2019 16:58:52 +0800 "Chen, Rong A" wrote: > On 9/5/2019 5:08 PM, Jonathan Cameron wrote: > > On Wed, 4 Sep 2019 15:37:11 +0300 > > Andy Shevchenko wrote: > > > >> On Wed, Sep 04, 2019 at 11:33:50AM +0800, kbuild test robot wrote: > >>> tree: > >>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/staging.git > >>> staging-testing > >>> head: 74eb9c06b1d722468db397595ac6834b9e4ac235 > >>> commit: 473d12f7638c93acbd9296a8cd455b203d5eb528 [314/401] iio: > >>> hid-sensor-attributes: Convert to use int_pow() > >>> config: i386-randconfig-e004-201935 (attached as .config) > >>> compiler: gcc-7 (Debian 7.4.0-11) 7.4.0 > >>> reproduce: > >>> git checkout 473d12f7638c93acbd9296a8cd455b203d5eb528 > >>> # save the attached .config to linux build tree > >>> make ARCH=i386 > >>> > >>> If you fix the issue, kindly add following tag > >>> Reported-by: kbuild test robot > >>> > >>> All errors (new ones prefixed by >>): > >> So, as far as I understood it wasn't compiled on 32-bit before, so, it's > >> not a > >> new error and thus would (has to?) be fixed separately. > > I'm not convinced. My assumption is this is triggered because the local > > pow_10 > > function was returning int whereas generic int_pow is returning an int64. > > Whilst I would imagine it is fairly easy to fix, I'll not have a chance to > > do > > so until the weekend. Perhaps we should just revert this patch and revisit > > in the next cycle? > > > > 0-day people, any idea why the iio.git/testing branch isn't getting built > > any > > more? I got lazy and started relying on your infrastructure and not > > bothering > > with 32 bit local builds. Somewhere along the way you stopped building it > > and I'm afraid I didn't really notice. > > > > Thanks for you all your hard work on 0day btw as it used to catch a lot > > of stuff my local few builds didn't! > > > > Jonathan > > Hi Jonathan, > > Sorry for the inconvenience, we updated the git url to > https://kernel.googlesource.com/pub/scm/linux/kernel/git/jic23/iio.git > recently, > but it seems the branches are not updated, so we switch to use > https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git now. Thanks. I wonder why some trees don't seem to be getting updated in that google mirror. Anyone know who manages that as a bit silly having mirrors that are years out of date. Anyone know who manages those mirrors? I've poked the send feedback form but who knows if it'll filter through to the right person. Anyhow, thanks Rong Chen. Looking forwards to continuing to be lazy and rely on your excellent service! Jonathan > > Best Regards, > Rong Chen > > > > > > > > > >>> ld: drivers/iio/common/hid-sensors/hid-sensor-attributes.o: in > >>> function `adjust_exponent_nano': > >>>>> drivers/iio/common/hid-sensors/hid-sensor-attributes.c:312: undefined > >>>>> reference to `__udivdi3' > >>>>> ld: drivers/iio/common/hid-sensors/hid-sensor-attributes.c:314: > >>>>> undefined reference to `__umoddi3' > >>>>> ld: drivers/iio/common/hid-sensors/hid-sensor-attributes.c:324: > >>>>> undefined reference to `__udivdi3' > >>> ld: drivers/iio/common/hid-sensors/hid-sensor-attributes.c:325: > >>> undefined reference to `__umoddi3' > >> > > > > ___ > > kbuild-all mailing list > > kbuild-...@lists.01.org > > https://lists.01.org/mailman/listinfo/kbuild-all > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [staging:staging-testing 314/401] drivers/iio/common/hid-sensors/hid-sensor-attributes.c:312: undefined reference to `__udivdi3'
On Wed, 4 Sep 2019 15:37:11 +0300 Andy Shevchenko wrote: > On Wed, Sep 04, 2019 at 11:33:50AM +0800, kbuild test robot wrote: > > tree: > > https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/staging.git > > staging-testing > > head: 74eb9c06b1d722468db397595ac6834b9e4ac235 > > commit: 473d12f7638c93acbd9296a8cd455b203d5eb528 [314/401] iio: > > hid-sensor-attributes: Convert to use int_pow() > > config: i386-randconfig-e004-201935 (attached as .config) > > compiler: gcc-7 (Debian 7.4.0-11) 7.4.0 > > reproduce: > > git checkout 473d12f7638c93acbd9296a8cd455b203d5eb528 > > # save the attached .config to linux build tree > > make ARCH=i386 > > > > If you fix the issue, kindly add following tag > > Reported-by: kbuild test robot > > > > All errors (new ones prefixed by >>): > > So, as far as I understood it wasn't compiled on 32-bit before, so, it's not a > new error and thus would (has to?) be fixed separately. I'm not convinced. My assumption is this is triggered because the local pow_10 function was returning int whereas generic int_pow is returning an int64. Whilst I would imagine it is fairly easy to fix, I'll not have a chance to do so until the weekend. Perhaps we should just revert this patch and revisit in the next cycle? 0-day people, any idea why the iio.git/testing branch isn't getting built any more? I got lazy and started relying on your infrastructure and not bothering with 32 bit local builds. Somewhere along the way you stopped building it and I'm afraid I didn't really notice. Thanks for you all your hard work on 0day btw as it used to catch a lot of stuff my local few builds didn't! Jonathan > > >ld: drivers/iio/common/hid-sensors/hid-sensor-attributes.o: in function > > `adjust_exponent_nano': > > >> drivers/iio/common/hid-sensors/hid-sensor-attributes.c:312: undefined > > >> reference to `__udivdi3' > > >> ld: drivers/iio/common/hid-sensors/hid-sensor-attributes.c:314: > > >> undefined reference to `__umoddi3' > > >> ld: drivers/iio/common/hid-sensors/hid-sensor-attributes.c:324: > > >> undefined reference to `__udivdi3' > >ld: drivers/iio/common/hid-sensors/hid-sensor-attributes.c:325: > > undefined reference to `__umoddi3' > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 4/4] dt-bindings: iio: adc: Add AD7606B ADC documentation
On Wed, 21 Aug 2019 17:16:56 +0300 Beniamin Bia wrote: > Documentation for AD7606B Analog to Digital Converter and software > mode was added. > > Signed-off-by: Beniamin Bia Tweaked as per Peter's comment and added Rob's Reviewed-by from v2 Seems everyone decided to review this one just as you were posting the new version ;) Jonathan > --- > Changes in v3: > -nothing changed > > Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml > b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml > index 509dbe9c84d2..2afe31747a70 100644 > --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml > +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml > @@ -13,6 +13,7 @@ maintainers: > description: | >Analog Devices AD7606 Simultaneous Sampling ADC > > https://www.analog.com/media/en/technical-documentation/data-sheets/ad7606_7606-6_7606-4.pdf > + > https://www.analog.com/media/en/technical-documentation/data-sheets/AD7606B.pdf > > https://www.analog.com/media/en/technical-documentation/data-sheets/AD7616.pdf > > properties: > @@ -22,6 +23,7 @@ properties: >- adi,ad7606-8 >- adi,ad7606-6 >- adi,ad7606-4 > + - adi,ad7606b >- adi,ad7616 > >reg: > @@ -87,7 +89,7 @@ properties: > >adi,sw-mode: > description: > - Software mode of operation, so far available only for ad7616. > + Software mode of operation, so far available only for ad7616 and > ad7606B. >It is enabled when all three oversampling mode pins are connected to >high level. The device is configured by the corresponding registers. > If the >adi,oversampling-ratio-gpios property is defined, then the driver will > set the ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 3/4] dt-bindings: iio: adc: Migrate AD7606 documentation to yaml
On Wed, 21 Aug 2019 17:16:55 +0300
Beniamin Bia wrote:
> The documentation for ad7606 was migrated to yaml.
>
> Signed-off-by: Beniamin Bia
make dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
3 things needed fixing beyond the tweak Rob mentioned (also done).
2 missing headers + one required property isn't present in the example.
I'll be grumpy next time... Particularly as the warnings don't exactly
point clearly to what is wrong for missing headers.
Applied with those changes to the togreg branch of iio.git and pushed out
as testing.
Thanks,
Jonathan
> ---
> Changes in v3:
> -nothing changed
>
> .../bindings/iio/adc/adi,ad7606.txt | 66 -
> .../bindings/iio/adc/adi,ad7606.yaml | 134 ++
> MAINTAINERS | 2 +-
> 3 files changed, 135 insertions(+), 67 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt
> create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt
> b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt
> deleted file mode 100644
> index d8652460198e..
> --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt
> +++ /dev/null
> @@ -1,66 +0,0 @@
> -Analog Devices AD7606 Simultaneous Sampling ADC
> -
> -Required properties for the AD7606:
> -
> -- compatible: Must be one of
> - * "adi,ad7605-4"
> - * "adi,ad7606-8"
> - * "adi,ad7606-6"
> - * "adi,ad7606-4"
> - * "adi,ad7616"
> -- reg: SPI chip select number for the device
> -- spi-max-frequency: Max SPI frequency to use
> - see: Documentation/devicetree/bindings/spi/spi-bus.txt
> -- spi-cpha: See Documentation/devicetree/bindings/spi/spi-bus.txt
> -- avcc-supply: phandle to the Avcc power supply
> -- interrupts: IRQ line for the ADC
> - see:
> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> -- adi,conversion-start-gpios: must be the device tree identifier of the
> CONVST pin.
> - This logic input is used to initiate conversions on the analog
> - input channels. As the line is active high, it should be
> marked
> - GPIO_ACTIVE_HIGH.
> -
> -Optional properties:
> -
> -- reset-gpios: must be the device tree identifier of the RESET pin. If
> specified,
> -it will be asserted during driver probe. As the line is active
> high,
> -it should be marked GPIO_ACTIVE_HIGH.
> -- standby-gpios: must be the device tree identifier of the STBY pin. This
> pin is used
> - to place the AD7606 into one of two power-down modes, Standby
> mode or
> - Shutdown mode. As the line is active low, it should be marked
> - GPIO_ACTIVE_LOW.
> -- adi,first-data-gpios: must be the device tree identifier of the FRSTDATA
> pin.
> - The FRSTDATA output indicates when the first channel, V1, is
> - being read back on either the parallel, byte or serial
> interface.
> - As the line is active high, it should be marked
> GPIO_ACTIVE_HIGH.
> -- adi,range-gpios: must be the device tree identifier of the RANGE pin. The
> polarity on
> - this pin determines the input range of the analog input channels.
> If
> - this pin is tied to a logic high, the analog input range is ±10V
> for
> - all channels. If this pin is tied to a logic low, the analog
> input range
> - is ±5V for all channels. As the line is active high, it should be
> marked
> - GPIO_ACTIVE_HIGH.
> -- adi,oversampling-ratio-gpios: must be the device tree identifier of the
> over-sampling
> - mode pins. As the line is active high, it
> should be marked
> - GPIO_ACTIVE_HIGH.
> -
> -Example:
> -
> - adc@0 {
> - compatible = "adi,ad7606-8";
> - reg = <0>;
> - spi-max-frequency = <100>;
> - spi-cpol;
> -
> - avcc-supply = <_vref>;
> -
> - interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> - interrupt-parent = <>;
> -
> - adi,conversion-start-gpios = < 17 GPIO_ACTIVE_HIGH>;
> - reset-gpios = < 27 GPIO_ACTIVE_HIGH>;
> - adi,first-data-gpios = < 22 GPIO_ACTIVE_HIGH>;
> - adi,oversampling-ratio-gpios = < 18 GPIO_ACTIVE_HIGH
> - 23 GPIO_ACTIVE_HIGH
> - 26 GPIO_ACTIVE_HIGH>;
> - standby-gpios = < 24 GPIO_ACTIVE_LOW>;
> - };
> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
> b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
> new file mode 100644
> index ..509dbe9c84d2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml
>
Re: [PATCH v3 2/4] MAINTAINERS: Add Beniamin Bia for AD7606 driver
On Wed, 21 Aug 2019 17:16:54 +0300 Beniamin Bia wrote: > Add Beniamin Bia as maintainer for AD7606 driver. > > Signed-off-by: Beniamin Bia Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to probably ignore it. Thanks, Jonathan > --- > Changes in v3: > -nothing changed > > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ad498428b38c..052d7a8591fb 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -895,6 +895,7 @@ F: > Documentation/devicetree/bindings/iio/adc/adi,ad7124.txt > > ANALOG DEVICES INC AD7606 DRIVER > M: Stefan Popa > +M: Beniamin Bia > L: linux-...@vger.kernel.org > W: http://ez.analog.com/community/linux-device-drivers > S: Supported ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/4] iio: adc: ad7606: Add support for AD7606B ADC
On Wed, 21 Aug 2019 17:16:53 +0300
Beniamin Bia wrote:
> From: Stefan Popa
>
> The AD7606B is a 16-bit ADC that supports simultaneous sampling of 8
> channels. It is pin compatible to AD7606, but adds extra modes by
> writing to the register map.
>
> The AD7606B can be configured to work in software mode by setting all
> oversampling pins to high. This mode is selected by default.
> The oversampling ratio is configured from the OS_MODE register (address
> 0x08) with the addition of OS=128 and OS=256 that were not available in
> hardware mode.
>
> The device is configured to output data on a single spi channel, but this
> configuration must be done right after restart. That is why the delay was
> removed for devices which doesn't require it.
>
> Moreover, in software mode, the range gpio has no longer its function.
> Instead, the scale can be configured individually for each channel from
> the RANGE_CH registers (address 0x03 to 0x06). Besides the already
> supported ±10 V and ±5 V ranges, software mode can also accommodate the
> ±2.5 V range.
>
> Signed-off-by: Stefan Popa
> Co-developed-by: Beniamin Bia
> Signed-off-by: Beniamin Bia
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
> ---
> Changes in v3:
> -comments reworked
> -isWriteOp renamed to is_write_op
>
> drivers/iio/adc/ad7606.c | 13 -
> drivers/iio/adc/ad7606.h | 4 ++
> drivers/iio/adc/ad7606_spi.c | 109 ++-
> 3 files changed, 123 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c
> index ed2d08437e5d..f5ba94c03a8d 100644
> --- a/drivers/iio/adc/ad7606.c
> +++ b/drivers/iio/adc/ad7606.c
> @@ -410,12 +410,19 @@ static const struct ad7606_chip_info
> ad7606_chip_info_tbl[] = {
> .oversampling_avail = ad7606_oversampling_avail,
> .oversampling_num = ARRAY_SIZE(ad7606_oversampling_avail),
> },
> + [ID_AD7606B] = {
> + .channels = ad7606_channels,
> + .num_channels = 9,
> + .oversampling_avail = ad7606_oversampling_avail,
> + .oversampling_num = ARRAY_SIZE(ad7606_oversampling_avail),
> + },
> [ID_AD7616] = {
> .channels = ad7616_channels,
> .num_channels = 17,
> .oversampling_avail = ad7616_oversampling_avail,
> .oversampling_num = ARRAY_SIZE(ad7616_oversampling_avail),
> .os_req_reset = true,
> + .init_delay_ms = 15,
> },
> };
>
> @@ -631,8 +638,10 @@ int ad7606_probe(struct device *dev, int irq, void
> __iomem *base_address,
> dev_warn(st->dev, "failed to RESET: no RESET GPIO specified\n");
>
> /* AD7616 requires al least 15ms to reconfigure after a reset */
> - if (msleep_interruptible(15))
> - return -ERESTARTSYS;
> + if (st->chip_info->init_delay_ms) {
> + if (msleep_interruptible(st->chip_info->init_delay_ms))
> + return -ERESTARTSYS;
> + }
>
> st->write_scale = ad7606_write_scale_hw;
> st->write_os = ad7606_write_os_hw;
> diff --git a/drivers/iio/adc/ad7606.h b/drivers/iio/adc/ad7606.h
> index eeaaa8b905db..9350ef1f63b5 100644
> --- a/drivers/iio/adc/ad7606.h
> +++ b/drivers/iio/adc/ad7606.h
> @@ -46,6 +46,8 @@
> * oversampling ratios.
> * @oversampling_num number of elements stored in oversampling_avail array
> * @os_req_reset some devices require a reset to update oversampling
> + * @init_delay_msrequired delay in miliseconds for initialization
> + * after a restart
> */
> struct ad7606_chip_info {
> const struct iio_chan_spec *channels;
> @@ -53,6 +55,7 @@ struct ad7606_chip_info {
> const unsigned int *oversampling_avail;
> unsigned intoversampling_num;
> boolos_req_reset;
> + unsigned long init_delay_ms;
> };
>
> /**
> @@ -155,6 +158,7 @@ enum ad7606_supported_device_ids {
> ID_AD7606_8,
> ID_AD7606_6,
> ID_AD7606_4,
> + ID_AD7606B,
> ID_AD7616,
> };
>
> diff --git a/drivers/iio/adc/ad7606_spi.c b/drivers/iio/adc/ad7606_spi.c
> index 98ed52b74507..29945ad07dca 100644
> --- a/drivers/iio/adc/ad7606_spi.c
> +++ b/drivers/iio/adc/ad7606_spi.c
> @@ -28,9 +28,23 @@
> * an offset of 2 for register address.
> */
> #define AD7616_RANGE_CH_ADDR(ch) ((ch) >> 2)
> -/* The range of the channel is stored on 2 bits*/
> +/* The range of the channel is stored in 2 bits */
> #define AD7616_RANGE_CH_MSK(ch) (0b11 << (((ch) & 0b11) * 2))
> #define AD7616_RANGE_CH_MODE(ch, mode) ((mode) << ch) & 0b11)) *
> 2))
> +
> +#define AD7606_CONFIGURATION_REGISTER0x02
> +#define AD7606_SINGLE_DOUT 0x00
> +
> +/*
> + * Range for AD7606B channels are stored in
Re: [PATCH v2] staging: iio: accel: adis16240: Improve readability on write_raw function
On Wed, 14 Aug 2019 06:56:18 +
"Ardelean, Alexandru" wrote:
> On Tue, 2019-08-13 at 16:31 -0300, Rodrigo Ribeiro wrote:
> > [External]
> >
> > Replace shift and minus operation by GENMASK macro and remove the local
> > variables used to store intermediate data.
> >
>
> Reviewed-by: Alexandru Ardelean
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
>
> > Signed-off-by: Rodrigo Ribeiro Carvalho
> > ---
> > v2:
> >- Leave switch statement instead of replace by if statement
> > drivers/staging/iio/accel/adis16240.c | 5 +
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/staging/iio/accel/adis16240.c
> > b/drivers/staging/iio/accel/adis16240.c
> > index 62f4b3b1b457..82099db4bf0c 100644
> > --- a/drivers/staging/iio/accel/adis16240.c
> > +++ b/drivers/staging/iio/accel/adis16240.c
> > @@ -309,15 +309,12 @@ static int adis16240_write_raw(struct iio_dev
> > *indio_dev,
> >long mask)
> > {
> > struct adis *st = iio_priv(indio_dev);
> > - int bits = 10;
> > - s16 val16;
> > u8 addr;
> >
> > switch (mask) {
> > case IIO_CHAN_INFO_CALIBBIAS:
> > - val16 = val & ((1 << bits) - 1);
> > addr = adis16240_addresses[chan->scan_index][0];
> > - return adis_write_reg_16(st, addr, val16);
> > + return adis_write_reg_16(st, addr, val & GENMASK(9, 0));
> > }
> > return -EINVAL;
> > }
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: accel: adis16240: Improve readability on write_raw function
On Sun, 11 Aug 2019 13:47:04 -0300
Rodrigo Ribeiro wrote:
> Em dom, 11 de ago de 2019 às 05:43, Jonathan Cameron
> escreveu:
> >
> > On Sat, 10 Aug 2019 12:00:58 -0300
> > Rodrigo wrote:
> >
> > > From: Rodrigo Carvalho
> > >
> > > Improve readability by using GENMASK macro, changing switch statement
> > > by if statement and removing unnecessary local variables.
> >
>
> Hi Jonathan. Thanks for reviewing!
>
> > From your description it sounds like multiple changes in one patch.
> > Always preferable to have one type of change in a patch and more
> > small patches.
> >
> > Based on comments below, I would leave the switch statement alone,
> > but put in your GENMASK change as that one is good and gets
> > rid of the odd local variable 'bits' as well :)
> >
> > Thanks,
> >
> > Jonathan
> >
> >
> > >
> > > Signed-off-by: Rodrigo Ribeiro Carvalho
> > > ---
> > > drivers/staging/iio/accel/adis16240.c | 16 +++-
> > > 1 file changed, 7 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/staging/iio/accel/adis16240.c
> > > b/drivers/staging/iio/accel/adis16240.c
> > > index 62f4b3b1b457..68f165501389 100644
> > > --- a/drivers/staging/iio/accel/adis16240.c
> > > +++ b/drivers/staging/iio/accel/adis16240.c
> > > @@ -309,17 +309,15 @@ static int adis16240_write_raw(struct iio_dev
> > > *indio_dev,
> > > long mask)
> > > {
> > > struct adis *st = iio_priv(indio_dev);
> > > - int bits = 10;
> > > - s16 val16;
> > > + int m;
> > > u8 addr;
> > >
> > > - switch (mask) {
> > > - case IIO_CHAN_INFO_CALIBBIAS:
> > > - val16 = val & ((1 << bits) - 1);
> > > - addr = adis16240_addresses[chan->scan_index][0];
> > > - return adis_write_reg_16(st, addr, val16);
> > > - }
> > > - return -EINVAL;
> > > + if (mask != IIO_CHAN_INFO_CALIBBIAS)
> > > + return -EINVAL;
> >
> > Hmm. We generally encourage the use of switch statements in these
> > cases because they reduce churn as new features are added.
> >
> > In this particular case, we don't have any control of sampling frequency
> > in the driver, but the hardware appears to support it (table 23 on the
> > datasheet).
>
> On drivers of same kind out of staging (adis16209 and adis16201), sampling
> frequency writing are not implemented, even though datasheets suggest a
> register
> writing for this. I can try to implement if it is a good one.
I would be a bit nervous about doing so if you don't have
hardware, and we can't find anyone who is setup to test the device.
Obviously if you can get it tested one way or the other, it would be good
to add support.
Thanks,
J
>
> > > +
> > > + m = GENMASK(9, 0);
> > > + addr = adis16240_addresses[chan->scan_index][0];
> > > + return adis_write_reg_16(st, addr, val & m);
> > Why the local variable m? Can we not just do
> >
> > return adis_write_reg_16(st, addr, val & GENMASK(9, 0));
> >
> > If anything I think that is a little more readable than your
> > version. There is a reasonable argument for just having
> > addr inline as well.
> >
> > return adis_write_reg_16(st,
> > adis16240_addresses[chan->scan_index][0],
> > val & GENMASK(9, 0));
> >
> > However, given I'm suggesting you leave it as a switch statement, it
> > will be too long with addr inline.
> >
> > > }
> > >
> > > static const struct iio_chan_spec adis16240_channels[] = {
> >
>
> Regards,
> Rodrigo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: accel: adis16240: Improve readability on write_raw function
On Sat, 10 Aug 2019 12:00:58 -0300
Rodrigo wrote:
> From: Rodrigo Carvalho
>
> Improve readability by using GENMASK macro, changing switch statement
> by if statement and removing unnecessary local variables.
>From your description it sounds like multiple changes in one patch.
Always preferable to have one type of change in a patch and more
small patches.
Based on comments below, I would leave the switch statement alone,
but put in your GENMASK change as that one is good and gets
rid of the odd local variable 'bits' as well :)
Thanks,
Jonathan
>
> Signed-off-by: Rodrigo Ribeiro Carvalho
> ---
> drivers/staging/iio/accel/adis16240.c | 16 +++-
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/staging/iio/accel/adis16240.c
> b/drivers/staging/iio/accel/adis16240.c
> index 62f4b3b1b457..68f165501389 100644
> --- a/drivers/staging/iio/accel/adis16240.c
> +++ b/drivers/staging/iio/accel/adis16240.c
> @@ -309,17 +309,15 @@ static int adis16240_write_raw(struct iio_dev
> *indio_dev,
> long mask)
> {
> struct adis *st = iio_priv(indio_dev);
> - int bits = 10;
> - s16 val16;
> + int m;
> u8 addr;
>
> - switch (mask) {
> - case IIO_CHAN_INFO_CALIBBIAS:
> - val16 = val & ((1 << bits) - 1);
> - addr = adis16240_addresses[chan->scan_index][0];
> - return adis_write_reg_16(st, addr, val16);
> - }
> - return -EINVAL;
> + if (mask != IIO_CHAN_INFO_CALIBBIAS)
> + return -EINVAL;
Hmm. We generally encourage the use of switch statements in these
cases because they reduce churn as new features are added.
In this particular case, we don't have any control of sampling frequency
in the driver, but the hardware appears to support it (table 23 on the
datasheet).
> +
> + m = GENMASK(9, 0);
> + addr = adis16240_addresses[chan->scan_index][0];
> + return adis_write_reg_16(st, addr, val & m);
Why the local variable m? Can we not just do
return adis_write_reg_16(st, addr, val & GENMASK(9, 0));
If anything I think that is a little more readable than your
version. There is a reasonable argument for just having
addr inline as well.
return adis_write_reg_16(st,
adis16240_addresses[chan->scan_index][0],
val & GENMASK(9, 0));
However, given I'm suggesting you leave it as a switch statement, it
will be too long with addr inline.
> }
>
> static const struct iio_chan_spec adis16240_channels[] = {
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/4] iio: adc: ad7606: Add support for AD7606B ADC
On Fri, 2 Aug 2019 13:03:01 +0300
Beniamin Bia wrote:
> From: Stefan Popa
>
> The AD7606B is a 16-bit ADC that supports simultaneous sampling of 8
> channels. It is pin compatible to AD7606, but adds extra modes by
> writing to the register map.
>
> The AD7606B can be configured to work in software mode by setting all
> oversampling pins to high. This mode is selected by default.
> The oversampling ratio is configured from the OS_MODE register (address
> 0x08) with the addition of OS=128 and OS=256 that were not available in
> hardware mode.
>
> The device is configured to output data on a single spi channel, but this
> configuration must be done right after restart. That is why the delay was
> removed for devices which doesn't require it.
>
> Moreover, in software mode, the range gpio has no longer its function.
> Instead, the scale can be configured individually for each channel from
> the RANGE_CH registers (address 0x03 to 0x06). Besides the already
> supported ±10 V and ±5 V ranges, software mode can also accommodate the
> ±2.5 V range.
>
> Signed-off-by: Stefan Popa
> Co-developed-by: Beniamin Bia
> Signed-off-by: Beniamin Bia
This looks fine to me. I'll pick it up (if no other comments)
when you've tidied up the issues Rob raises for the DT bindings.
Thanks,
Jonathan
> ---
> drivers/iio/adc/ad7606.c | 13 -
> drivers/iio/adc/ad7606.h | 4 ++
> drivers/iio/adc/ad7606_spi.c | 107 +++
> 3 files changed, 122 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c
> index ed2d08437e5d..f5ba94c03a8d 100644
> --- a/drivers/iio/adc/ad7606.c
> +++ b/drivers/iio/adc/ad7606.c
> @@ -410,12 +410,19 @@ static const struct ad7606_chip_info
> ad7606_chip_info_tbl[] = {
> .oversampling_avail = ad7606_oversampling_avail,
> .oversampling_num = ARRAY_SIZE(ad7606_oversampling_avail),
> },
> + [ID_AD7606B] = {
> + .channels = ad7606_channels,
> + .num_channels = 9,
> + .oversampling_avail = ad7606_oversampling_avail,
> + .oversampling_num = ARRAY_SIZE(ad7606_oversampling_avail),
> + },
> [ID_AD7616] = {
> .channels = ad7616_channels,
> .num_channels = 17,
> .oversampling_avail = ad7616_oversampling_avail,
> .oversampling_num = ARRAY_SIZE(ad7616_oversampling_avail),
> .os_req_reset = true,
> + .init_delay_ms = 15,
> },
> };
>
> @@ -631,8 +638,10 @@ int ad7606_probe(struct device *dev, int irq, void
> __iomem *base_address,
> dev_warn(st->dev, "failed to RESET: no RESET GPIO specified\n");
>
> /* AD7616 requires al least 15ms to reconfigure after a reset */
> - if (msleep_interruptible(15))
> - return -ERESTARTSYS;
> + if (st->chip_info->init_delay_ms) {
> + if (msleep_interruptible(st->chip_info->init_delay_ms))
> + return -ERESTARTSYS;
> + }
>
> st->write_scale = ad7606_write_scale_hw;
> st->write_os = ad7606_write_os_hw;
> diff --git a/drivers/iio/adc/ad7606.h b/drivers/iio/adc/ad7606.h
> index eeaaa8b905db..9350ef1f63b5 100644
> --- a/drivers/iio/adc/ad7606.h
> +++ b/drivers/iio/adc/ad7606.h
> @@ -46,6 +46,8 @@
> * oversampling ratios.
> * @oversampling_num number of elements stored in oversampling_avail array
> * @os_req_reset some devices require a reset to update oversampling
> + * @init_delay_msrequired delay in miliseconds for initialization
> + * after a restart
> */
> struct ad7606_chip_info {
> const struct iio_chan_spec *channels;
> @@ -53,6 +55,7 @@ struct ad7606_chip_info {
> const unsigned int *oversampling_avail;
> unsigned intoversampling_num;
> boolos_req_reset;
> + unsigned long init_delay_ms;
> };
>
> /**
> @@ -155,6 +158,7 @@ enum ad7606_supported_device_ids {
> ID_AD7606_8,
> ID_AD7606_6,
> ID_AD7606_4,
> + ID_AD7606B,
> ID_AD7616,
> };
>
> diff --git a/drivers/iio/adc/ad7606_spi.c b/drivers/iio/adc/ad7606_spi.c
> index 98ed52b74507..070ee7e31e2c 100644
> --- a/drivers/iio/adc/ad7606_spi.c
> +++ b/drivers/iio/adc/ad7606_spi.c
> @@ -31,6 +31,20 @@
> /* The range of the channel is stored on 2 bits*/
> #define AD7616_RANGE_CH_MSK(ch) (0b11 << (((ch) & 0b11) * 2))
> #define AD7616_RANGE_CH_MODE(ch, mode) ((mode) << ch) & 0b11)) *
> 2))
> +
> +#define AD7606_CONFIGURATION_REGISTER0x02
> +#define AD7606_SINGLE_DOUT 0x0
> +
> +/*
> + * Range for AD7606B channels are stored in registers starting with address
> 0x3.
> + * Each register stores range for 2 channels(4 bits per channel).
> + */
> +#define AD7606_RANGE_CH_MSK(ch) (GENMASK(3, 0) << (4 * ((ch) &
> 0x1)))
>
Re: [PATCH] staging: iio: ad2s1210: Use device-managed API
On Fri, 26 Jul 2019 12:36:08 +
"Ardelean, Alexandru" wrote:
> On Fri, 2019-07-26 at 19:07 +0800, Chuhong Yuan wrote:
> > [External]
> >
> > Use device-managed API to simplify the code.
> > The remove function is redundant now and can
> > be deleted.
>
> Reviewed-by: Alexandru Ardelean
The end of this probe function is rather odd and probably needs sorting
out as I imagine that needs to happen before the device is exposed to
userspace.
Nothing to do with this patch though which is great.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
>
> >
> > Signed-off-by: Chuhong Yuan
> > ---
> > drivers/staging/iio/resolver/ad2s1210.c | 12 +---
> > 1 file changed, 1 insertion(+), 11 deletions(-)
> >
> > diff --git a/drivers/staging/iio/resolver/ad2s1210.c
> > b/drivers/staging/iio/resolver/ad2s1210.c
> > index 0c1bd108c386..4b25a3a314ed 100644
> > --- a/drivers/staging/iio/resolver/ad2s1210.c
> > +++ b/drivers/staging/iio/resolver/ad2s1210.c
> > @@ -671,7 +671,7 @@ static int ad2s1210_probe(struct spi_device *spi)
> > indio_dev->num_channels = ARRAY_SIZE(ad2s1210_channels);
> > indio_dev->name = spi_get_device_id(spi)->name;
> >
> > - ret = iio_device_register(indio_dev);
> > + ret = devm_iio_device_register(>dev, indio_dev);
> > if (ret)
> > return ret;
> >
> > @@ -683,15 +683,6 @@ static int ad2s1210_probe(struct spi_device *spi)
> > return 0;
> > }
> >
> > -static int ad2s1210_remove(struct spi_device *spi)
> > -{
> > - struct iio_dev *indio_dev = spi_get_drvdata(spi);
> > -
> > - iio_device_unregister(indio_dev);
> > -
> > - return 0;
> > -}
> > -
> > static const struct of_device_id ad2s1210_of_match[] = {
> > { .compatible = "adi,ad2s1210", },
> > { }
> > @@ -710,7 +701,6 @@ static struct spi_driver ad2s1210_driver = {
> > .of_match_table = of_match_ptr(ad2s1210_of_match),
> > },
> > .probe = ad2s1210_probe,
> > - .remove = ad2s1210_remove,
> > .id_table = ad2s1210_id,
> > };
> > module_spi_driver(ad2s1210_driver);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging:iio:adc:ad7280a: add of_match_table entry
On Fri, 26 Jul 2019 14:59:16 -0300
Matheus Tavares Bernardino wrote:
> On Fri, Jul 26, 2019 at 2:30 AM Ardelean, Alexandru
> wrote:
> >
> > On Fri, 2019-07-26 at 01:38 +0530, Kartik Kulkarni wrote:
> > > Add the of_device_id struct and the respective
> > > of_match_device entry to complete device tree support.
> > >
> >
> > This would be a [V2] I suppose.
> >
> > This change also does the rename of the driver name in a single go.
> > Since it's a trivial change, it's fine from my side.
>
> I think there was a small confusion when we sent the patches. Sorry
> for that. Originally, Kartik made the rename in its own patch. Would
> it be better if we resend the two patches separately?
I would prefer that. They are two separate changes, and the driver
name one may be a little unexpected so let's make sure it's obvious.
There is also the question on whether we should tidy up all the
prefixing to make it clear that this is an ad7280a throughout.
Perhaps that's too painful though and we should leave it like this
for now.
Thanks,
Jonathan
>
> Thanks,
> Matheus
>
> > Reviewed-by: Alexandru Ardelean
> >
> >
> > > Signed-off-by: Kartik Kulkarni
> > > Reviewed-by: Matheus Tavares
> > > ---
> > > drivers/staging/iio/adc/ad7280a.c | 9 -
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/staging/iio/adc/ad7280a.c
> > > b/drivers/staging/iio/adc/ad7280a.c
> > > index 19a5f244dcae..ded0ba093a28 100644
> > > --- a/drivers/staging/iio/adc/ad7280a.c
> > > +++ b/drivers/staging/iio/adc/ad7280a.c
> > > @@ -1027,9 +1027,16 @@ static const struct spi_device_id ad7280_id[] = {
> > > };
> > > MODULE_DEVICE_TABLE(spi, ad7280_id);
> > >
> > > +static const struct of_device_id ad7280_of_match[] = {
> > > + { .compatible = "adi,ad7280a", },
> > > + { }
> > > +};
> > > +MODULE_DEVICE_TABLE(of, ad7280_of_match);
> > > +
> > > static struct spi_driver ad7280_driver = {
> > > .driver = {
> > > - .name = "ad7280",
> > > + .name = "ad7280a",
> > > + .of_match_table = ad7280_of_match,
> > > },
> > > .probe = ad7280_probe,
> > > .id_table = ad7280_id,
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Kernel USP" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to kernel-usp+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/kernel-usp/0e273486f1c4fb6249896225837cdf2da0fd2415.camel%40analog.com.
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: iio: ad7192: create of_device_id array
On Fri, 28 Jun 2019 16:49:22 -0300
Bárbara Fernandes wrote:
> Create list of compatible device ids to be matched with those stated in
> the device tree.
>
> Signed-off-by: Bárbara Fernandes
> Signed-off-by: Wilson Sales
> Co-developed by: Wilson Sales
> ---
Patch is fine and applied to the togreg branch of iio.git.
Only thing to note is that reviewers and maintainers often have
poor memories (or are jet lagged which is my excuse today!)
so it helps to put a change log here under the ---
Thanks,
Jonathan
> drivers/staging/iio/adc/ad7192.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/staging/iio/adc/ad7192.c
> b/drivers/staging/iio/adc/ad7192.c
> index 3d74da9d37e7..70118db98d94 100644
> --- a/drivers/staging/iio/adc/ad7192.c
> +++ b/drivers/staging/iio/adc/ad7192.c
> @@ -810,11 +810,23 @@ static const struct spi_device_id ad7192_id[] = {
> {"ad7195", ID_AD7195},
> {}
> };
> +
> MODULE_DEVICE_TABLE(spi, ad7192_id);
>
> +static const struct of_device_id ad7192_of_match[] = {
> + { .compatible = "adi,ad7190" },
> + { .compatible = "adi,ad7192" },
> + { .compatible = "adi,ad7193" },
> + { .compatible = "adi,ad7195" },
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(of, ad7192_of_match);
> +
> static struct spi_driver ad7192_driver = {
> .driver = {
> .name = "ad7192",
> + .of_match_table = ad7192_of_match,
> },
> .probe = ad7192_probe,
> .remove = ad7192_remove,
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: ad7150: use ternary operating to ensure 0/1 value
On Mon, 17 Jun 2019 11:40:34 +0300 Dan Carpenter wrote: > On Sun, Jun 16, 2019 at 11:15:16AM +0100, Jonathan Cameron wrote: > > On Fri, 14 Jun 2019 13:50:59 -0300 > > Melissa Wen wrote: > > > > > Remove idiom and use ternary operator for consistently trigger 0/1 value > > > on variable declaration. > > > > > > Signed-off-by: Melissa Wen > > Hi Melissa, > > > > In general I would consider this unnecessary churn as, whilst > > it's no longer a favoured idiom, it is extremely common in the > > kernel. > > It's still my favourite... Why wouldn't people like it? It feels like > last week I just saw someone send a bunch of: > > - foo = (bar == baz) ? 1 : 0; > + foo = (bar == baz); > > patches and I thought it was an improvement at the time... That one is nice enough, it's the !! that Linus came out fairly strongly against though not sure I can find the particular email. That one is a fairly kernel specific idiom that I'll be honest I've rarely seen elsewhere ;) I remember wincing at the thread on this as it was an idiom I personally rather liked. In cases where it doesn't matter because foo doesn't need to 1 or 0 then what you have is nice and clean. I can't say it's one I care that much about, but I am happy if code that happens to be under cleanup anyway has this little bit made the 'preferred style'. There is something to said for consistency. Jonathan > > regards, > dan carpenter > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 3/4] iio: adc: ad7606: Add support for software mode for ad7616
On Sat, 8 Jun 2019 12:30:39 +0100
Jonathan Cameron wrote:
> On Mon, 27 May 2019 15:56:49 +0300
> Beniamin Bia wrote:
>
> > Support for ad7616 running in software was added. In order
> > to activate the software mode, HW_RNGSEL pins must be pulled low.
> > Oversampling and input ranges are now configured in corresponding
> > registers. Ad7616 has multiple scale options when it is configured
> > in software mode.
> > Also, in order to support multiple devices in software mode, the spi
> > the calculation of registers address must be generic. Because
> > the length of address and bit which specifies the read/write operation is
> > different for every device, calculation of address was made generic.
> >
> > Signed-off-by: Beniamin Bia
> Applied to the togreg branch of iio.git and pushed out as testing
> to see if the autobuilders can find anything we have missed.
>
Oops. Missed that this makes the core driver dependant on spi support.
Two ways of fixing it. Either make it dependant and fuse the lot
or use some calls into the ad7606_spi file with suitable dummy
versions in the header.
I've dropped this and patch 4 for now until we have this sorted.
Another win for 0-day!
Thanks,
Jonathan
> Thanks,
>
> Jonathan
>
> > ---
> > Changes in v2:
> > -squashed with the patch which introduces the reg access function.
> > -some casting warnings were fixed.
> >
> > drivers/iio/adc/ad7606.c | 171 +--
> > drivers/iio/adc/ad7606.h | 4 +
> > 2 files changed, 167 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c
> > index aba0fd123a51..8e09ad4bb72e 100644
> > --- a/drivers/iio/adc/ad7606.c
> > +++ b/drivers/iio/adc/ad7606.c
> > @@ -25,8 +25,24 @@
> > #include
> > #include
> >
> > +#include
> > +
> > #include "ad7606.h"
> >
> > +#define AD7606_RANGE_CH_ADDR(ch) (0x03 + ((ch) >> 1))
> > +#define AD7606_OS_MODE 0x08
> > +
> > +#define AD7616_CONFIGURATION_REGISTER 0x02
> > +#define AD7616_OS_MASK GENMASK(4, 2)
> > +#define AD7616_BURST_MODE BIT(6)
> > +#define AD7616_SEQEN_MODE BIT(5)
> > +#define AD7616_RANGE_CH_ADDR_OFF 0x04
> > +#define AD7616_RANGE_CH_ADDR(ch) ch) & 0x1) << 1) + ((ch) >> 3))
> > +#define AD7616_RANGE_CH_MSK(ch)(GENMASK(1, 0) << ((ch) & 0x6))
> > +#define AD7616_RANGE_CH_MODE(ch, mode) ((mode) << (ch & GENMASK(2, 1)))
> > +
> > +static int ad7616_sw_mode_config(struct iio_dev *indio_dev);
> > +
> > /*
> > * Scales are computed as 5000/32768 and 1/32768 respectively,
> > * so that when applied to the raw values they provide mV values
> > @@ -35,6 +51,11 @@ static const unsigned int ad7606_scale_avail[2] = {
> > 152588, 305176
> > };
> >
> > +
> > +static const unsigned int ad7616_sw_scale_avail[3] = {
> > + 76293, 152588, 305176
> > +};
> > +
> > static const unsigned int ad7606_oversampling_avail[7] = {
> > 1, 2, 4, 8, 16, 32, 64,
> > };
> > @@ -43,6 +64,11 @@ static const unsigned int ad7616_oversampling_avail[8] =
> > {
> > 1, 2, 4, 8, 16, 32, 64, 128,
> > };
> >
> > +static u16 ad7616_spi_rd_wr_cmd(int addr, char isWriteOp)
> > +{
> > + return ((addr & 0x7F) << 1) | ((isWriteOp & 0x1) << 7);
> > +}
> > +
> > static int ad7606_reset(struct ad7606_state *st)
> > {
> > if (st->gpio_reset) {
> > @@ -55,6 +81,59 @@ static int ad7606_reset(struct ad7606_state *st)
> > return -ENODEV;
> > }
> >
> > +static int ad7606_spi_reg_read(struct ad7606_state *st, unsigned int addr)
> > +{
> > + struct spi_device *spi = to_spi_device(st->dev);
> > + struct spi_transfer t[] = {
> > + {
> > + .tx_buf = >d16[0],
> > + .len = 2,
> > + .cs_change = 0,
> > + }, {
> > + .rx_buf = >d16[1],
> > + .len = 2,
> > + },
> > + };
> > + int ret;
> > +
> > + st->d16[0] = cpu_to_be16(st->chip_info->spi_rd_wr_cmd(addr, 0) << 8);
> > +
> > + ret = spi_sync_transfer(spi, t, ARRAY_SIZE(t));
> > + if (ret < 0)
> > + return ret;
> > +
> > + return be16_to_cpu(st->d16[1]);
> > +}
> > +
> > +static in
Re: [PATCH] Staging: iio: adt7316: use correct headers for gpio
On Mon, 17 Jun 2019 13:09:20 +0200
Arnd Bergmann wrote:
> When building without CONFIG_GPIOLIB, we get a compile-time failure:
>
> drivers/staging/iio/addac/adt7316.c:947:3: error: implicit declaration of
> function 'gpiod_set_value' [-Werror,-Wimplicit-function-declaration]
> gpiod_set_value(chip->ldac_pin, 0);
> ^
> drivers/staging/iio/addac/adt7316.c:947:3: note: did you mean
> 'gpio_set_value'?
> include/linux/gpio.h:169:20: note: 'gpio_set_value' declared here
> static inline void gpio_set_value(unsigned gpio, int value)
>^
> drivers/staging/iio/addac/adt7316.c:947:3: error: this function declaration
> is not a prototype [-Werror,-Wstrict-prototypes]
> gpiod_set_value(chip->ldac_pin, 0);
> ^
> drivers/staging/iio/addac/adt7316.c:1805:13: error: implicit declaration of
> function 'irqd_get_trigger_type' [-Werror,-Wimplicit-function-declaration]
> irq_type = irqd_get_trigger_type(irq_get_irq_data(chip->bus.irq));
>
> Include the correct headers that contain the declarations for these
> functions.
>
> Fixes: c63460c4298f ("Staging: iio: adt7316: Use device tree data to set
> ldac_pin")
> Signed-off-by: Arnd Bergmann
Sorry, this is me being exceedingly slow on getting the fix upstream.
I've just sent a pull request for the fix I've had queued up for a few weeks.
Jonathan
> ---
> drivers/staging/iio/addac/adt7316.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/iio/addac/adt7316.c
> b/drivers/staging/iio/addac/adt7316.c
> index 37ce563cb0e1..9cb3d0e42c38 100644
> --- a/drivers/staging/iio/addac/adt7316.c
> +++ b/drivers/staging/iio/addac/adt7316.c
> @@ -6,7 +6,8 @@
> */
>
> #include
> -#include
> +#include
> +#include
> #include
> #include
> #include
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] dt-bindings: iio: adc: add adi,ad7780.yaml binding
On Fri, 14 Jun 2019 13:43:02 -0600 Rob Herring wrote: > On Fri, 24 May 2019 22:26:30 -0300, Renato Lui Geh wrote: > > This patch adds a YAML binding for the Analog Devices AD7780/1 and > > AD7170/1 analog-to-digital converters. > > > > Signed-off-by: Renato Lui Geh > > --- > > Changes in v2: > > - vref-supply to avdd-supply > > - remove avdd-supply from required list > > - include adc block in an spi block > > > > .../bindings/iio/adc/adi,ad7780.txt | 48 -- > > .../bindings/iio/adc/adi,ad7780.yaml | 87 +++ > > 2 files changed, 87 insertions(+), 48 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt > > create mode 100644 > > Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml > > > > Reviewed-by: Rob Herring Thanks. As I'd not yet pushed out as togreg (rather than testing) I've rebased to add your RB. Thanks, Jonathan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: adt7316: Add missing include files
On Fri, 14 Jun 2019 23:28:46 +0800
YueHaibing wrote:
> Fix build error:
>
> drivers/staging/iio/addac/adt7316.c: In function adt7316_store_update_DAC:
> drivers/staging/iio/addac/adt7316.c:949:3: error: implicit declaration of
> function gpiod_set_value; did you mean gpio_set_value?
> [-Werror=implicit-function-declaration]
>gpiod_set_value(chip->ldac_pin, 0);
>
> drivers/staging/iio/addac/adt7316.c: In function adt7316_setup_irq:
> drivers/staging/iio/addac/adt7316.c:1807:13: error: implicit declaration of
> function irqd_get_trigger_type; did you mean devm_iio_trigger_free?
> [-Werror=implicit-function-declaration]
> irq_type = irqd_get_trigger_type(irq_get_irq_data(chip->bus.irq));
>
> Reported-by: Hulk Robot
> Fixes: 7f6b6d553df7 ("Staging: iio: adt7316: Add all irq related code in
> adt7316_irq_setup()")
> Fixes: c63460c4298f ("Staging: iio: adt7316: Use device tree data to set
> ldac_pin")
> Signed-off-by: YueHaibing
Hi yuehaibing,
You were second to send a fix for this. I've had it in my
fixes branch since last week, but not done a pull request quite yet.
I'll probably send it out later today.
https://patchwork.kernel.org/patch/10978301/
Thanks,
Jonathan
> ---
> drivers/staging/iio/addac/adt7316.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/staging/iio/addac/adt7316.c
> b/drivers/staging/iio/addac/adt7316.c
> index 37ce563..9d3d159 100644
> --- a/drivers/staging/iio/addac/adt7316.c
> +++ b/drivers/staging/iio/addac/adt7316.c
> @@ -16,6 +16,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
> #include
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/3] staging: iio: ad7150: simplify i2c SMBus return treatment
On Fri, 14 Jun 2019 13:32:54 -0300 Melissa Wen wrote: > Since i2c_smbus_write_byte_data returns no-positive value, this commit > making the treatment of its return value less verbose. > > Signed-off-by: Melissa Wen Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with it. Thanks, Jonathan > --- > drivers/staging/iio/cdc/ad7150.c | 9 ++--- > 1 file changed, 2 insertions(+), 7 deletions(-) > > diff --git a/drivers/staging/iio/cdc/ad7150.c > b/drivers/staging/iio/cdc/ad7150.c > index 091aa33589d7..7d56f10a19ed 100644 > --- a/drivers/staging/iio/cdc/ad7150.c > +++ b/drivers/staging/iio/cdc/ad7150.c > @@ -202,16 +202,11 @@ static int ad7150_write_event_params(struct iio_dev > *indio_dev, > ret = i2c_smbus_write_byte_data(chip->client, > ad7150_addresses[chan][4], > sens); > - if (ret < 0) > + if (ret) > return ret; > - > - ret = i2c_smbus_write_byte_data(chip->client, > + return i2c_smbus_write_byte_data(chip->client, > ad7150_addresses[chan][5], > timeout); > - if (ret < 0) > - return ret; > - > - return 0; > } > > static int ad7150_write_event_config(struct iio_dev *indio_dev, ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 3/3] staging: iio: ad7150: clean up of comments
On Fri, 14 Jun 2019 13:33:19 -0300
Melissa Wen wrote:
> General cleaning of comments to remove useless information or improve
> description.
>
> Signed-off-by: Melissa Wen
Applied,
Thanks,
Jonathan
> ---
> drivers/staging/iio/cdc/ad7150.c | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/staging/iio/cdc/ad7150.c
> b/drivers/staging/iio/cdc/ad7150.c
> index 7d56f10a19ed..51d6b52bce8b 100644
> --- a/drivers/staging/iio/cdc/ad7150.c
> +++ b/drivers/staging/iio/cdc/ad7150.c
> @@ -163,7 +163,8 @@ static int ad7150_read_event_config(struct iio_dev
> *indio_dev,
> return -EINVAL;
> }
>
> -/* lock should be held */
> +/* state_lock should be held to ensure consistent state*/
> +
> static int ad7150_write_event_params(struct iio_dev *indio_dev,
>unsigned int chan,
>enum iio_event_type type,
> @@ -479,10 +480,6 @@ static const struct iio_chan_spec ad7150_channels[] = {
> AD7150_CAPACITANCE_CHAN(1)
> };
>
> -/*
> - * threshold events
> - */
> -
> static irqreturn_t ad7150_event_handler(int irq, void *private)
> {
> struct iio_dev *indio_dev = private;
> @@ -571,10 +568,6 @@ static const struct iio_info ad7150_info = {
> .write_event_value = _write_event_value,
> };
>
> -/*
> - * device probe and remove
> - */
> -
> static int ad7150_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/3] staging: iio: ad7150: use FIELD_GET and GENMASK
On Fri, 14 Jun 2019 13:32:21 -0300
Melissa Wen wrote:
> Use the bitfield macro FIELD_GET, and GENMASK to do the shift and mask in
> one go. This makes the code more readable than explicit masking followed
> by a shift.
>
> Signed-off-by: Melissa Wen
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to paly with it.
Thanks,
Jonathan
> ---
> drivers/staging/iio/cdc/ad7150.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/iio/cdc/ad7150.c
> b/drivers/staging/iio/cdc/ad7150.c
> index 8234da4b8c65..091aa33589d7 100644
> --- a/drivers/staging/iio/cdc/ad7150.c
> +++ b/drivers/staging/iio/cdc/ad7150.c
> @@ -5,6 +5,7 @@
> * Copyright 2010-2011 Analog Devices Inc.
> */
>
> +#include
> #include
> #include
> #include
> @@ -45,6 +46,9 @@
> #define AD7150_SN0 22
> #define AD7150_ID 23
>
> +/* AD7150 masks */
> +#define AD7150_THRESHTYPE_MSKGENMASK(6, 5)
> +
> /**
> * struct ad7150_chip_info - instance specific chip data
> * @client: i2c client for this device
> @@ -137,7 +141,7 @@ static int ad7150_read_event_config(struct iio_dev
> *indio_dev,
> if (ret < 0)
> return ret;
>
> - threshtype = (ret >> 5) & 0x03;
> + threshtype = FIELD_GET(AD7150_THRESHTYPE_MSK, ret);
> adaptive = !!(ret & 0x80);
>
> switch (type) {
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: ad7150: use ternary operating to ensure 0/1 value
On Fri, 14 Jun 2019 13:50:59 -0300
Melissa Wen wrote:
> Remove idiom and use ternary operator for consistently trigger 0/1 value
> on variable declaration.
>
> Signed-off-by: Melissa Wen
Hi Melissa,
In general I would consider this unnecessary churn as, whilst
it's no longer a favoured idiom, it is extremely common in the
kernel. However, as this is a staging cleanup, fair enough to
make it as 'nice as possible'!
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/staging/iio/cdc/ad7150.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/iio/cdc/ad7150.c
> b/drivers/staging/iio/cdc/ad7150.c
> index 8234da4b8c65..25598bf124fb 100644
> --- a/drivers/staging/iio/cdc/ad7150.c
> +++ b/drivers/staging/iio/cdc/ad7150.c
> @@ -350,8 +350,8 @@ static ssize_t ad7150_show_timeout(struct device *dev,
>
> /* use the event code for consistency reasons */
> int chan = IIO_EVENT_CODE_EXTRACT_CHAN(this_attr->address);
> - int rising = !!(IIO_EVENT_CODE_EXTRACT_DIR(this_attr->address)
> - == IIO_EV_DIR_RISING);
> + int rising = (IIO_EVENT_CODE_EXTRACT_DIR(this_attr->address)
> + == IIO_EV_DIR_RISING) ? 1 : 0;
>
> switch (IIO_EVENT_CODE_EXTRACT_TYPE(this_attr->address)) {
> case IIO_EV_TYPE_MAG_ADAPTIVE:
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: iio: adt7316: Fix build errors when GPIOLIB is not set
On Wed, 5 Jun 2019 20:24:09 -0700 Randy Dunlap wrote: > On 6/5/19 7:05 PM, Fabio Estevam wrote: > > On x86_64 when GPIOLIB is not set the following build errors > > are seen: > > > > drivers/staging/iio/addac/adt7316.c:947:3: error: implicit declaration of > > function 'gpiod_set_value' [-Werror=implicit-function-declaration] > > drivers/staging/iio/addac/adt7316.c:1805:2: error: implicit declaration of > > function 'irqd_get_trigger_type' [-Werror=implicit-function-declaration] > > > > These functions are provided by the > > and headers, so include them to fix these > > build errors. > > > > While at it, remove as this driver is a GPIO > > consumer and not a GPIO driver. > > > > Reported-by: Randy Dunlap > > Signed-off-by: Fabio Estevam > > Acked-by: Randy Dunlap # build-tested Applied to the fixes-togreg branch of iio.git. thanks, Jonathan > > Thanks. > > > --- > > Changes since v1: > > - Remove - Phil > > > > drivers/staging/iio/addac/adt7316.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/staging/iio/addac/adt7316.c > > b/drivers/staging/iio/addac/adt7316.c > > index 37ce563cb0e1..9cb3d0e42c38 100644 > > --- a/drivers/staging/iio/addac/adt7316.c > > +++ b/drivers/staging/iio/addac/adt7316.c > > @@ -6,7 +6,8 @@ > > */ > > > > #include > > -#include > > +#include > > +#include > > #include > > #include > > #include > > > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 4/4] iio: adc: ad7606: Add debug mode for ad7616
On Mon, 27 May 2019 15:56:50 +0300
Beniamin Bia wrote:
> Support for register access was added for spi devices.
>
> Signed-off-by: Beniamin Bia
> Acked-by: Jonathan Cameron
Applied.
Thanks,
Jonathan
> ---
> Changes in v2:
> -nothing changed
>
> drivers/iio/adc/ad7606.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c
> index 8e09ad4bb72e..0eccfc873802 100644
> --- a/drivers/iio/adc/ad7606.c
> +++ b/drivers/iio/adc/ad7606.c
> @@ -134,6 +134,30 @@ static int ad7606_spi_write_mask(struct ad7606_state *st,
> return ad7606_spi_reg_write(st, addr, readval);
> }
>
> +static int ad7606_reg_access(struct iio_dev *indio_dev,
> + unsigned int reg,
> + unsigned int writeval,
> + unsigned int *readval)
> +{
> + struct ad7606_state *st = iio_priv(indio_dev);
> + int ret;
> +
> + mutex_lock(>lock);
> + if (readval) {
> + ret = ad7606_spi_reg_read(st, reg);
> + if (ret < 0)
> + goto err_unlock;
> + *readval = ret;
> + ret = 0;
> + } else {
> + ret = ad7606_spi_reg_write(st, reg, writeval);
> + }
> +err_unlock:
> + mutex_unlock(>lock);
> +
> + return ret;
> +}
> +
> static int ad7606_read_samples(struct ad7606_state *st)
> {
> unsigned int num = st->chip_info->num_channels;
> @@ -645,6 +669,7 @@ static const struct iio_info ad7606_info_no_os_or_range =
> {
> static const struct iio_info ad7606_info_os_and_range = {
> .read_raw = _read_raw,
> .write_raw = _write_raw,
> + .debugfs_reg_access = _reg_access,
> .attrs = _attribute_group_os_and_range,
> .validate_trigger = _validate_trigger,
> };
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 3/4] iio: adc: ad7606: Add support for software mode for ad7616
On Mon, 27 May 2019 15:56:49 +0300
Beniamin Bia wrote:
> Support for ad7616 running in software was added. In order
> to activate the software mode, HW_RNGSEL pins must be pulled low.
> Oversampling and input ranges are now configured in corresponding
> registers. Ad7616 has multiple scale options when it is configured
> in software mode.
> Also, in order to support multiple devices in software mode, the spi
> the calculation of registers address must be generic. Because
> the length of address and bit which specifies the read/write operation is
> different for every device, calculation of address was made generic.
>
> Signed-off-by: Beniamin Bia
Applied to the togreg branch of iio.git and pushed out as testing
to see if the autobuilders can find anything we have missed.
Thanks,
Jonathan
> ---
> Changes in v2:
> -squashed with the patch which introduces the reg access function.
> -some casting warnings were fixed.
>
> drivers/iio/adc/ad7606.c | 171 +--
> drivers/iio/adc/ad7606.h | 4 +
> 2 files changed, 167 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c
> index aba0fd123a51..8e09ad4bb72e 100644
> --- a/drivers/iio/adc/ad7606.c
> +++ b/drivers/iio/adc/ad7606.c
> @@ -25,8 +25,24 @@
> #include
> #include
>
> +#include
> +
> #include "ad7606.h"
>
> +#define AD7606_RANGE_CH_ADDR(ch) (0x03 + ((ch) >> 1))
> +#define AD7606_OS_MODE 0x08
> +
> +#define AD7616_CONFIGURATION_REGISTER0x02
> +#define AD7616_OS_MASK GENMASK(4, 2)
> +#define AD7616_BURST_MODEBIT(6)
> +#define AD7616_SEQEN_MODEBIT(5)
> +#define AD7616_RANGE_CH_ADDR_OFF 0x04
> +#define AD7616_RANGE_CH_ADDR(ch) ch) & 0x1) << 1) + ((ch) >> 3))
> +#define AD7616_RANGE_CH_MSK(ch) (GENMASK(1, 0) << ((ch) & 0x6))
> +#define AD7616_RANGE_CH_MODE(ch, mode) ((mode) << (ch & GENMASK(2, 1)))
> +
> +static int ad7616_sw_mode_config(struct iio_dev *indio_dev);
> +
> /*
> * Scales are computed as 5000/32768 and 1/32768 respectively,
> * so that when applied to the raw values they provide mV values
> @@ -35,6 +51,11 @@ static const unsigned int ad7606_scale_avail[2] = {
> 152588, 305176
> };
>
> +
> +static const unsigned int ad7616_sw_scale_avail[3] = {
> + 76293, 152588, 305176
> +};
> +
> static const unsigned int ad7606_oversampling_avail[7] = {
> 1, 2, 4, 8, 16, 32, 64,
> };
> @@ -43,6 +64,11 @@ static const unsigned int ad7616_oversampling_avail[8] = {
> 1, 2, 4, 8, 16, 32, 64, 128,
> };
>
> +static u16 ad7616_spi_rd_wr_cmd(int addr, char isWriteOp)
> +{
> + return ((addr & 0x7F) << 1) | ((isWriteOp & 0x1) << 7);
> +}
> +
> static int ad7606_reset(struct ad7606_state *st)
> {
> if (st->gpio_reset) {
> @@ -55,6 +81,59 @@ static int ad7606_reset(struct ad7606_state *st)
> return -ENODEV;
> }
>
> +static int ad7606_spi_reg_read(struct ad7606_state *st, unsigned int addr)
> +{
> + struct spi_device *spi = to_spi_device(st->dev);
> + struct spi_transfer t[] = {
> + {
> + .tx_buf = >d16[0],
> + .len = 2,
> + .cs_change = 0,
> + }, {
> + .rx_buf = >d16[1],
> + .len = 2,
> + },
> + };
> + int ret;
> +
> + st->d16[0] = cpu_to_be16(st->chip_info->spi_rd_wr_cmd(addr, 0) << 8);
> +
> + ret = spi_sync_transfer(spi, t, ARRAY_SIZE(t));
> + if (ret < 0)
> + return ret;
> +
> + return be16_to_cpu(st->d16[1]);
> +}
> +
> +static int ad7606_spi_reg_write(struct ad7606_state *st,
> + unsigned int addr,
> + unsigned int val)
> +{
> + struct spi_device *spi = to_spi_device(st->dev);
> +
> + st->d16[0] = cpu_to_be16((st->chip_info->spi_rd_wr_cmd(addr, 1) << 8) |
> + (val & 0x1FF));
> +
> + return spi_write(spi, >d16[0], sizeof(st->d16[0]));
> +}
> +
> +static int ad7606_spi_write_mask(struct ad7606_state *st,
> + unsigned int addr,
> + unsigned long mask,
> + unsigned int val)
> +{
> + int readval;
> +
> + readval = ad7606_spi_reg_read(st, addr);
> + if (readval < 0)
> + return readval;
> +
> + readval &= ~mask;
> + readval |= val;
> +
> + return ad7606_spi_reg_write(st, addr, readval);
> +}
> +
> static int ad7606_read_samples(struct ad7606_state *st)
> {
> unsigned int num = st->chip_info->num_channels;
> @@ -222,6 +301,26 @@ static int ad7606_write_os_hw(struct iio_dev *indio_dev,
> int val)
> return 0;
> }
>
> +static int ad7616_write_scale_sw(struct iio_dev *indio_dev, int ch, int val)
> +{
> + struct ad7606_state *st = iio_priv(indio_dev);
> + unsigned int ch_addr, mode;
> +
> +
Re: [PATCH v2 2/4] iio: adc: ad7606: Add software configuration
On Mon, 27 May 2019 15:56:48 +0300
Beniamin Bia wrote:
> Because this driver will support multiple configurations for software,
> the software configuration was made generic.
>
> Signed-off-by: Beniamin Bia
> Acked-by: Jonathan Cameron
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to poke at it.
Thanks,
Jonathan
> ---
> Changes in v2:
> -nothing changed
>
> drivers/iio/adc/ad7606.c | 40 +---
> drivers/iio/adc/ad7606.h | 2 ++
> 2 files changed, 39 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c
> index c66ff22f32d2..aba0fd123a51 100644
> --- a/drivers/iio/adc/ad7606.c
> +++ b/drivers/iio/adc/ad7606.c
> @@ -140,7 +140,7 @@ static int ad7606_read_raw(struct iio_dev *indio_dev,
> int *val2,
> long m)
> {
> - int ret;
> + int ret, ch = 0;
> struct ad7606_state *st = iio_priv(indio_dev);
>
> switch (m) {
> @@ -157,8 +157,10 @@ static int ad7606_read_raw(struct iio_dev *indio_dev,
> *val = (short)ret;
> return IIO_VAL_INT;
> case IIO_CHAN_INFO_SCALE:
> + if (st->sw_mode_en)
> + ch = chan->address;
> *val = 0;
> - *val2 = st->scale_avail[st->range[0]];
> + *val2 = st->scale_avail[st->range[ch]];
> return IIO_VAL_INT_PLUS_MICRO;
> case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
> *val = st->oversampling;
> @@ -233,7 +235,9 @@ static int ad7606_write_raw(struct iio_dev *indio_dev,
> case IIO_CHAN_INFO_SCALE:
> mutex_lock(>lock);
> i = find_closest(val2, st->scale_avail, st->num_scales);
> - ret = st->write_scale(indio_dev, chan->address, i);
> + if (st->sw_mode_en)
> + ch = chan->address;
> + ret = st->write_scale(indio_dev, ch, i);
> if (ret < 0) {
> mutex_unlock(>lock);
> return ret;
> @@ -616,6 +620,36 @@ int ad7606_probe(struct device *dev, int irq, void
> __iomem *base_address,
> st->write_scale = ad7606_write_scale_hw;
> st->write_os = ad7606_write_os_hw;
>
> + if (st->chip_info->sw_mode_config)
> + st->sw_mode_en = device_property_present(st->dev,
> + "adi,sw-mode");
> +
> + if (st->sw_mode_en) {
> + /* After reset, in software mode, ±10 V is set by default */
> + memset32(st->range, 2, ARRAY_SIZE(st->range));
> + indio_dev->info = _info_os_and_range;
> +
> + /*
> + * In software mode, the range gpio has no longer its function.
> + * Instead, the scale can be configured individually for each
> + * channel from the range registers.
> + */
> + if (st->chip_info->write_scale_sw)
> + st->write_scale = st->chip_info->write_scale_sw;
> +
> + /*
> + * In software mode, the oversampling is no longer configured
> + * with GPIO pins. Instead, the oversampling can be configured
> + * in configuratiion register.
> + */
> + if (st->chip_info->write_os_sw)
> + st->write_os = st->chip_info->write_os_sw;
> +
> + ret = st->chip_info->sw_mode_config(indio_dev);
> + if (ret < 0)
> + return ret;
> + }
> +
> st->trig = devm_iio_trigger_alloc(dev, "%s-dev%d",
> indio_dev->name, indio_dev->id);
> if (!st->trig)
> diff --git a/drivers/iio/adc/ad7606.h b/drivers/iio/adc/ad7606.h
> index 143c30163df9..d8a509c2c428 100644
> --- a/drivers/iio/adc/ad7606.h
> +++ b/drivers/iio/adc/ad7606.h
> @@ -43,6 +43,7 @@ struct ad7606_chip_info {
> * @rangevoltage range selection, selects which scale to apply
> * @oversampling oversampling selection
> * @base_address address from where to read data in parallel operation
> + * @sw_mode_en software mode enabled
> * @scale_avail pointer to the array which stores the available
> scales
> * @num_scales number of elements stored in the scale_avail
> array
> * @oversampling_avail pointer to the array which stores the available
> @@ -71,6 +72,7 @@ struct ad7606_state {
> unsign
Re: [PATCH v2 1/4] iio: adc: ad7606: Move oversampling and scale options to chip info
On Mon, 27 May 2019 15:56:47 +0300
Beniamin Bia wrote:
> The device dependent options which are going to be different for devices
> which will be supported in the future by this driver,
> were moved in chip info for a more generic driver. This patch allows
> supporting more devices by the driver. Also, it is an intermediate
> step of adding support for ad7616 in software mode.
>
> Signed-off-by: Beniamin Bia
> Acked-by: Jonathan Cameron
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
> ---
> Changes in v2:
> -nothing changed
>
> drivers/iio/adc/ad7606.c | 61 +---
> drivers/iio/adc/ad7606.h | 15 +-
> 2 files changed, 58 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c
> index 24c70c3cefb4..c66ff22f32d2 100644
> --- a/drivers/iio/adc/ad7606.c
> +++ b/drivers/iio/adc/ad7606.c
> @@ -158,7 +158,7 @@ static int ad7606_read_raw(struct iio_dev *indio_dev,
> return IIO_VAL_INT;
> case IIO_CHAN_INFO_SCALE:
> *val = 0;
> - *val2 = st->scale_avail[st->range];
> + *val2 = st->scale_avail[st->range[0]];
> return IIO_VAL_INT_PLUS_MICRO;
> case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
> *val = st->oversampling;
> @@ -194,6 +194,32 @@ static ssize_t in_voltage_scale_available_show(struct
> device *dev,
>
> static IIO_DEVICE_ATTR_RO(in_voltage_scale_available, 0);
>
> +static int ad7606_write_scale_hw(struct iio_dev *indio_dev, int ch, int val)
> +{
> + struct ad7606_state *st = iio_priv(indio_dev);
> +
> + gpiod_set_value(st->gpio_range, val);
> +
> + return 0;
> +}
> +
> +static int ad7606_write_os_hw(struct iio_dev *indio_dev, int val)
> +{
> + struct ad7606_state *st = iio_priv(indio_dev);
> + DECLARE_BITMAP(values, 3);
> +
> + values[0] = val;
> +
> + gpiod_set_array_value(ARRAY_SIZE(values), st->gpio_os->desc,
> + st->gpio_os->info, values);
> +
> + /* AD7616 requires a reset to update value */
> + if (st->chip_info->os_req_reset)
> + ad7606_reset(st);
> +
> + return 0;
> +}
> +
> static int ad7606_write_raw(struct iio_dev *indio_dev,
> struct iio_chan_spec const *chan,
> int val,
> @@ -201,15 +227,18 @@ static int ad7606_write_raw(struct iio_dev *indio_dev,
> long mask)
> {
> struct ad7606_state *st = iio_priv(indio_dev);
> - DECLARE_BITMAP(values, 3);
> - int i;
> + int i, ret, ch = 0;
>
> switch (mask) {
> case IIO_CHAN_INFO_SCALE:
> mutex_lock(>lock);
> i = find_closest(val2, st->scale_avail, st->num_scales);
> - gpiod_set_value(st->gpio_range, i);
> - st->range = i;
> + ret = st->write_scale(indio_dev, chan->address, i);
> + if (ret < 0) {
> + mutex_unlock(>lock);
> + return ret;
> + }
> + st->range[ch] = i;
> mutex_unlock(>lock);
>
> return 0;
> @@ -218,17 +247,12 @@ static int ad7606_write_raw(struct iio_dev *indio_dev,
> return -EINVAL;
> i = find_closest(val, st->oversampling_avail,
>st->num_os_ratios);
> -
> - values[0] = i;
> -
> mutex_lock(>lock);
> - gpiod_set_array_value(ARRAY_SIZE(values), st->gpio_os->desc,
> - st->gpio_os->info, values);
> -
> - /* AD7616 requires a reset to update value */
> - if (st->chip_info->os_req_reset)
> - ad7606_reset(st);
> -
> + ret = st->write_os(indio_dev, i);
> + if (ret < 0) {
> + mutex_unlock(>lock);
> + return ret;
> + }
> st->oversampling = st->oversampling_avail[i];
> mutex_unlock(>lock);
>
> @@ -536,7 +560,7 @@ int ad7606_probe(struct device *dev, int irq, void
> __iomem *base_address,
> st->bops = bops;
> st->base_address = base_address;
> /* tied to logic low, analog input range is +/- 5V */
> - st->range = 0;
> + st->range[0] = 0;
> st->oversampling = 1;
> st->scale_avail = ad7606_scale_avail;
> st->num_scales = ARRAY_SIZE(a
Re: [PATCH v2 2/2] MAINTAINERS: add entry for ad7780 adc driver
On Fri, 24 May 2019 22:26:55 -0300 Renato Lui Geh wrote: > This patch adds a MAINTAINERS entry for the AD7780 ADC driver. > > Signed-off-by: Renato Lui Geh Applied to the togreg branch of iio.git and pushed out as testing to be completely ignored by the autobuilders. Thanks, Jonathan > --- > MAINTAINERS | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 54c8e14fae98..d12685c5b09a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -880,6 +880,15 @@ S: Supported > F: drivers/iio/adc/ad7768-1.c > F: Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.txt > > +ANALOG DEVICES INC AD7780 DRIVER > +M: Michael Hennerich > +M: Renato Lui Geh > +L: linux-...@vger.kernel.org > +W: http://ez.analog.com/community/linux-device-drivers > +S: Supported > +F: drivers/iio/adc/ad7780.c > +F: Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml > + > ANALOG DEVICES INC AD9389B DRIVER > M: Hans Verkuil > L: linux-me...@vger.kernel.org ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] dt-bindings: iio: adc: add adi,ad7780.yaml binding
On Thu, 6 Jun 2019 16:52:14 +0100 Jonathan Cameron wrote: > On Thu, 6 Jun 2019 11:13:52 + > "Ardelean, Alexandru" wrote: > > > On Wed, 2019-06-05 at 17:35 -0300, Renato Lui Geh wrote: > > > [External] > > > > > > > > > On 05/26, Jonathan Cameron wrote: > > > > On Fri, 24 May 2019 22:26:30 -0300 > > > > Renato Lui Geh wrote: > > > > > > > > > This patch adds a YAML binding for the Analog Devices AD7780/1 and > > > > > AD7170/1 analog-to-digital converters. > > > > > > > > > > Signed-off-by: Renato Lui Geh > > > > Looks good to me, but I'm still finding my feet with these so will > > > > leave it for a few days for others to have time to comment. > > > > > > > > Michael, looking for a quick reply from you to say if you are happy > > > > being explicitly listed as maintainer for this one, or if you'd > > > > rather land it on someone else. Same applies for patch 2. > > > > > > > > Renato, if I seem to have forgotten this in a week or so, feel > > > > free to give me a poke. I've been known to loose patches entirely! > > > > > > Hi Jonathan, > > > > > > Just here to give you a poke. :) > > > > > > By the way, in these cases, which would be easier for you? To send you > > > an email like I'm doing right now on last week's thread; or to resend > > > the entire patch(set)? > > > > > > > I think in this case, maybe let's wait a bit longer. > > Jonathan has not been active recently. > > > > I think a [RESEND] would be a good idea when he gets back/active and misses > > your patchset. > > > Sorry, was away last weekend and haven't caught up since. > > I should be fine to pick this up this weekend. > > A ping like this is fine rather than a resend. I've applied this the togreg branch of iio.git and pushed out as testing. Note I'm not planning a pull request for a week or so, so welcome any additional comments anyone has when they are able to make them. Thanks, Jonathan > > Thanks, > > Jonathan > > > Thanks > > Alex > > > > > Thanks, > > > Renato > > > > Thanks, > > > > > > > > Jonathan > > > > > --- > > > > > Changes in v2: > > > > > - vref-supply to avdd-supply > > > > > - remove avdd-supply from required list > > > > > - include adc block in an spi block > > > > > > > > > > .../bindings/iio/adc/adi,ad7780.txt | 48 -- > > > > > .../bindings/iio/adc/adi,ad7780.yaml | 87 > > > > > +++ > > > > > 2 files changed, 87 insertions(+), 48 deletions(-) > > > > > delete mode 100644 > > > > > Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt > > > > > create mode 100644 > > > > > Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt > > > > > b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt > > > > > deleted file mode 100644 > > > > > index 440e52555349.. > > > > > --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt > > > > > +++ /dev/null > > > > > @@ -1,48 +0,0 @@ > > > > > -* Analog Devices AD7170/AD7171/AD7780/AD7781 > > > > > - > > > > > -Data sheets: > > > > > - > > > > > -- AD7170: > > > > > -* > > > > > https://www.analog.com/media/en/technical-documentation/data-sheets/AD7170.pdf > > > > > -- AD7171: > > > > > -* > > > > > https://www.analog.com/media/en/technical-documentation/data-sheets/AD7171.pdf > > > > > -- AD7780: > > > > > -* > > > > > https://www.analog.com/media/en/technical-documentation/data-sheets/ad7780.pdf > > > > > -- AD7781: > > > > > -* > > > > > https://www.analog.com/media/en/technical-documentation/data-sheets/AD7781.pdf > > > > > - > > > > > -Required properties: > > > > > - > > > > > -- compatible: should be one of > > > > > -* "adi,ad7170" > > > > > -* "
Re: [PATCH v2 1/2] dt-bindings: iio: adc: add adi,ad7780.yaml binding
On Thu, 6 Jun 2019 11:13:52 + "Ardelean, Alexandru" wrote: > On Wed, 2019-06-05 at 17:35 -0300, Renato Lui Geh wrote: > > [External] > > > > > > On 05/26, Jonathan Cameron wrote: > > > On Fri, 24 May 2019 22:26:30 -0300 > > > Renato Lui Geh wrote: > > > > > > > This patch adds a YAML binding for the Analog Devices AD7780/1 and > > > > AD7170/1 analog-to-digital converters. > > > > > > > > Signed-off-by: Renato Lui Geh > > > Looks good to me, but I'm still finding my feet with these so will > > > leave it for a few days for others to have time to comment. > > > > > > Michael, looking for a quick reply from you to say if you are happy > > > being explicitly listed as maintainer for this one, or if you'd > > > rather land it on someone else. Same applies for patch 2. > > > > > > Renato, if I seem to have forgotten this in a week or so, feel > > > free to give me a poke. I've been known to loose patches entirely! > > > > Hi Jonathan, > > > > Just here to give you a poke. :) > > > > By the way, in these cases, which would be easier for you? To send you > > an email like I'm doing right now on last week's thread; or to resend > > the entire patch(set)? > > > > I think in this case, maybe let's wait a bit longer. > Jonathan has not been active recently. > > I think a [RESEND] would be a good idea when he gets back/active and misses > your patchset. > Sorry, was away last weekend and haven't caught up since. I should be fine to pick this up this weekend. A ping like this is fine rather than a resend. Thanks, Jonathan > Thanks > Alex > > > Thanks, > > Renato > > > Thanks, > > > > > > Jonathan > > > > --- > > > > Changes in v2: > > > > - vref-supply to avdd-supply > > > > - remove avdd-supply from required list > > > > - include adc block in an spi block > > > > > > > > .../bindings/iio/adc/adi,ad7780.txt | 48 -- > > > > .../bindings/iio/adc/adi,ad7780.yaml | 87 +++ > > > > 2 files changed, 87 insertions(+), 48 deletions(-) > > > > delete mode 100644 > > > > Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt > > > > create mode 100644 > > > > Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt > > > > b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt > > > > deleted file mode 100644 > > > > index 440e52555349.. > > > > --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt > > > > +++ /dev/null > > > > @@ -1,48 +0,0 @@ > > > > -* Analog Devices AD7170/AD7171/AD7780/AD7781 > > > > - > > > > -Data sheets: > > > > - > > > > -- AD7170: > > > > -* > > > > https://www.analog.com/media/en/technical-documentation/data-sheets/AD7170.pdf > > > > -- AD7171: > > > > -* > > > > https://www.analog.com/media/en/technical-documentation/data-sheets/AD7171.pdf > > > > -- AD7780: > > > > -* > > > > https://www.analog.com/media/en/technical-documentation/data-sheets/ad7780.pdf > > > > -- AD7781: > > > > -* > > > > https://www.analog.com/media/en/technical-documentation/data-sheets/AD7781.pdf > > > > - > > > > -Required properties: > > > > - > > > > -- compatible: should be one of > > > > -* "adi,ad7170" > > > > -* "adi,ad7171" > > > > -* "adi,ad7780" > > > > -* "adi,ad7781" > > > > -- reg: spi chip select number for the device > > > > -- vref-supply: the regulator supply for the ADC reference voltage > > > > - > > > > -Optional properties: > > > > - > > > > -- powerdown-gpios: must be the device tree identifier of the PDRST > > > > pin. If > > > > -specified, it will be asserted during driver probe. As > > > > the > > > > -line is active high, it should be marked > > > > GPIO_ACTIVE_HIGH. > > > > -- adi,gain-gpios: must be the device tree identifier of the GAIN > > > > pin. Only for > > > > -
Re: [PATCH] dt-bindings: iio: adc: add adi,ad7780.yaml binding
On Fri, 24 May 2019 21:28:02 -0300 Renato Lui Geh wrote: > Hi Jonathan, Alex, > > Thanks for the review. Some comments inline. > > Thanks, > Renato > > On 05/20, Ardelean, Alexandru wrote: > >On Sun, 2019-05-19 at 12:32 +0100, Jonathan Cameron wrote: > >> [External] > >> > >> > >> On Sat, 18 May 2019 19:41:12 -0300 > >> Renato Lui Geh wrote: > >> > >> > This patch adds a YAML binding for the Analog Devices AD7780/1 and > >> > AD7170/1 analog-to-digital converters. > >> > > >> > Signed-off-by: Renato Lui Geh > >> > >> One comment inline. I'll also be needing an ack from Analog on this, > >> preferably Michael's. > >> > >> Thanks, > >> > >> Jonathan > >> > --- > >> > .../bindings/iio/adc/adi,ad7780.txt | 48 --- > >> > .../bindings/iio/adc/adi,ad7780.yaml | 85 +++ > > > >You should also update the MAINTAINERS file. > >Maybe in a following patch. > >It looks like there is not entry in there, so maybe you need to add a new > >one. > > > >Something like: > > > > > >ANALOG DEVICES INC AD7780 DRIVER > >M: Michael Hennerich > >M: Renato Lui Geh > >L: linux-...@vger.kernel.org > >W: http://ez.analog.com/community/linux-device-drivers > >S: Supported > >F: drivers/iio/adc/ad7780.c > >F: Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml > > > >This should be after this block > >ANALOG DEVICES INC AD7768-1 DRIVER > > > >Note that I added you as a co-maintainer. > >If you want, you do not need to add that line. > > > >> > 2 files changed, 85 insertions(+), 48 deletions(-) > >> > delete mode 100644 > >> > Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt > >> > create mode 100644 > >> > Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml > >> > > >> > diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt > >> > b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt > >> > deleted file mode 100644 > >> > index 440e52555349.. > >> > --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt > >> > +++ /dev/null > >> > @@ -1,48 +0,0 @@ > >> > -* Analog Devices AD7170/AD7171/AD7780/AD7781 > >> > - > >> > -Data sheets: > >> > - > >> > -- AD7170: > >> > - * > >> > https://www.analog.com/media/en/technical-documentation/data-sheets/AD7170.pdf > >> > -- AD7171: > >> > - * > >> > https://www.analog.com/media/en/technical-documentation/data-sheets/AD7171.pdf > >> > -- AD7780: > >> > - * > >> > https://www.analog.com/media/en/technical-documentation/data-sheets/ad7780.pdf > >> > -- AD7781: > >> > - * > >> > https://www.analog.com/media/en/technical-documentation/data-sheets/AD7781.pdf > >> > - > >> > -Required properties: > >> > - > >> > -- compatible: should be one of > >> > - * "adi,ad7170" > >> > - * "adi,ad7171" > >> > - * "adi,ad7780" > >> > - * "adi,ad7781" > >> > -- reg: spi chip select number for the device > >> > -- vref-supply: the regulator supply for the ADC reference voltage > >> > - > >> > -Optional properties: > >> > - > >> > -- powerdown-gpios: must be the device tree identifier of the PDRST > >> > pin. If > >> > - specified, it will be asserted during driver probe. > >> > As the > >> > - line is active high, it should be marked > >> > GPIO_ACTIVE_HIGH. > >> > -- adi,gain-gpios: must be the device tree identifier of the GAIN > >> > pin. Only for > >> > - the ad778x chips. If specified, it will be asserted > >> > during > >> > - driver probe. As the line is active low, it should be > >> > marked > >> > - GPIO_ACTIVE_LOW. > >> > -- adi,filter-gpios: must be the device tree identifier of the FILTER > >> > pin. Only > >> > - for the ad778x chips. If specified, it will be > >> > asserted > >> > -
Re: [PATCH v2 1/2] dt-bindings: iio: adc: add adi,ad7780.yaml binding
On Fri, 24 May 2019 22:26:30 -0300
Renato Lui Geh wrote:
> This patch adds a YAML binding for the Analog Devices AD7780/1 and
> AD7170/1 analog-to-digital converters.
>
> Signed-off-by: Renato Lui Geh
Looks good to me, but I'm still finding my feet with these so will
leave it for a few days for others to have time to comment.
Michael, looking for a quick reply from you to say if you are happy
being explicitly listed as maintainer for this one, or if you'd
rather land it on someone else. Same applies for patch 2.
Renato, if I seem to have forgotten this in a week or so, feel
free to give me a poke. I've been known to loose patches entirely!
Thanks,
Jonathan
> ---
> Changes in v2:
> - vref-supply to avdd-supply
> - remove avdd-supply from required list
> - include adc block in an spi block
>
> .../bindings/iio/adc/adi,ad7780.txt | 48 --
> .../bindings/iio/adc/adi,ad7780.yaml | 87 +++
> 2 files changed, 87 insertions(+), 48 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt
> create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt
> b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt
> deleted file mode 100644
> index 440e52555349..
> --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt
> +++ /dev/null
> @@ -1,48 +0,0 @@
> -* Analog Devices AD7170/AD7171/AD7780/AD7781
> -
> -Data sheets:
> -
> -- AD7170:
> - *
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD7170.pdf
> -- AD7171:
> - *
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD7171.pdf
> -- AD7780:
> - *
> https://www.analog.com/media/en/technical-documentation/data-sheets/ad7780.pdf
> -- AD7781:
> - *
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD7781.pdf
> -
> -Required properties:
> -
> -- compatible: should be one of
> - * "adi,ad7170"
> - * "adi,ad7171"
> - * "adi,ad7780"
> - * "adi,ad7781"
> -- reg: spi chip select number for the device
> -- vref-supply: the regulator supply for the ADC reference voltage
> -
> -Optional properties:
> -
> -- powerdown-gpios: must be the device tree identifier of the PDRST pin. If
> - specified, it will be asserted during driver probe. As the
> - line is active high, it should be marked GPIO_ACTIVE_HIGH.
> -- adi,gain-gpios: must be the device tree identifier of the GAIN pin. Only
> for
> - the ad778x chips. If specified, it will be asserted during
> - driver probe. As the line is active low, it should be marked
> - GPIO_ACTIVE_LOW.
> -- adi,filter-gpios: must be the device tree identifier of the FILTER pin.
> Only
> - for the ad778x chips. If specified, it will be asserted
> - during driver probe. As the line is active low, it should be
> - marked GPIO_ACTIVE_LOW.
> -
> -Example:
> -
> -adc@0 {
> - compatible = "adi,ad7780";
> - reg = <0>;
> - vref-supply = <_supply>
> -
> - powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
> - adi,gain-gpios = < 5 GPIO_ACTIVE_LOW>;
> - adi,filter-gpios = < 15 GPIO_ACTIVE_LOW>;
> -};
> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
> b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
> new file mode 100644
> index ..d1109416963c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
> @@ -0,0 +1,87 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/adc/adi,ad7780.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices AD7170/AD7171/AD7780/AD7781 analog to digital
> converters
> +
> +maintainers:
> + - Michael Hennerich
> +
> +description: |
> + The ad7780 is a sigma-delta analog to digital converter. This driver
> provides
> + reading voltage values and status bits from both the ad778x and ad717x
> series.
> + Its interface also allows writing on the FILTER and GAIN GPIO pins on the
> + ad778x.
> +
> + Specifications on the converters can be found at:
> +AD7170:
> +
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD7170.pdf
> +AD7171:
> +
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD7171.pdf
> +AD7780:
> +
> https://www.analog.com/media/en/technical-documentation/data-sheets/ad7780.pdf
> +AD7781:
> +
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD7781.pdf
> +
> +properties:
> + compatible:
> +enum:
> + - adi,ad7170
> + - adi,ad7171
> + - adi,ad7780
> + - adi,ad7781
> +
> + reg:
> +maxItems: 1
> +
> + avdd-supply:
> +description:
> + The regulator supply for the ADC
Re: [PATCH] staging: iio: adis16240: add of_match_table entry
On Fri, 24 May 2019 13:54:49 +
"Ardelean, Alexandru" wrote:
> On Fri, 2019-05-24 at 10:50 -0300, Marcelo Schmitt wrote:
> > [External]
> >
> >
> > Hi Alexandru,
> >
> > On 05/24, Alexandru Ardelean wrote:
> > > On Fri, May 24, 2019 at 6:30 AM Rodrigo Ribeiro
> > > wrote:
> > > >
> > > > This patch adds of_match_table entry in device driver in order to
> > > > enable spi fallback probing.
> > > >
> > > > Signed-off-by: Rodrigo Ribeiro
> > > > Reviewed-by: Marcelo Schmitt
> > > > ---
> > > > drivers/staging/iio/accel/adis16240.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/staging/iio/accel/adis16240.c
> > > > b/drivers/staging/iio/accel/adis16240.c
> > > > index 8c6d23604eca..b80c8529784b 100644
> > > > --- a/drivers/staging/iio/accel/adis16240.c
> > > > +++ b/drivers/staging/iio/accel/adis16240.c
> > > > @@ -444,6 +444,7 @@ MODULE_DEVICE_TABLE(of, adis16240_of_match);
> > > > static struct spi_driver adis16240_driver = {
> > > > .driver = {
> > > > .name = "adis16240",
> > > > + .of_match_table = adis16240_of_match,
> > >
> > > This patch is missing the actual table.
> >
> > Struct with compatible devices table was included separately in a
> > previous patch at commit d9e533b6c0a26c7ef8116b7f3477c164c07bb6fb.
> > Yeah, I also thought it was missing the match table the first time I was
> > this patch. It's really confusing when we have two patches, one
> > depending on another, that are not part of the same patch set. We're
> > trying to avoid things like this the most but that slipped out from our
> > internal review. We're sorry about that.
>
> No worries.
>
> It happens to me too.
>
> Thanks
> Alex
Oops. I should have caught that one in review as well.
Oh well, these things happen.
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it. I rebased the tree to pick up on
all the other stuff in staging/staging-next after the mere window.
Thanks,
Jonathan
>
> >
> > >
> > > > },
> > > > .probe = adis16240_probe,
> > > > .remove = adis16240_remove,
> > > > --
> > > > 2.20.1
> > > >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] dt-bindings: iio: adc: add adi,ad7780.yaml binding
On Sat, 18 May 2019 19:41:12 -0300
Renato Lui Geh wrote:
> This patch adds a YAML binding for the Analog Devices AD7780/1 and
> AD7170/1 analog-to-digital converters.
>
> Signed-off-by: Renato Lui Geh
One comment inline. I'll also be needing an ack from Analog on this,
preferably Michael's.
Thanks,
Jonathan
> ---
> .../bindings/iio/adc/adi,ad7780.txt | 48 ---
> .../bindings/iio/adc/adi,ad7780.yaml | 85 +++
> 2 files changed, 85 insertions(+), 48 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt
> create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt
> b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt
> deleted file mode 100644
> index 440e52555349..
> --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.txt
> +++ /dev/null
> @@ -1,48 +0,0 @@
> -* Analog Devices AD7170/AD7171/AD7780/AD7781
> -
> -Data sheets:
> -
> -- AD7170:
> - *
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD7170.pdf
> -- AD7171:
> - *
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD7171.pdf
> -- AD7780:
> - *
> https://www.analog.com/media/en/technical-documentation/data-sheets/ad7780.pdf
> -- AD7781:
> - *
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD7781.pdf
> -
> -Required properties:
> -
> -- compatible: should be one of
> - * "adi,ad7170"
> - * "adi,ad7171"
> - * "adi,ad7780"
> - * "adi,ad7781"
> -- reg: spi chip select number for the device
> -- vref-supply: the regulator supply for the ADC reference voltage
> -
> -Optional properties:
> -
> -- powerdown-gpios: must be the device tree identifier of the PDRST pin. If
> - specified, it will be asserted during driver probe. As the
> - line is active high, it should be marked GPIO_ACTIVE_HIGH.
> -- adi,gain-gpios: must be the device tree identifier of the GAIN pin. Only
> for
> - the ad778x chips. If specified, it will be asserted during
> - driver probe. As the line is active low, it should be marked
> - GPIO_ACTIVE_LOW.
> -- adi,filter-gpios: must be the device tree identifier of the FILTER pin.
> Only
> - for the ad778x chips. If specified, it will be asserted
> - during driver probe. As the line is active low, it should be
> - marked GPIO_ACTIVE_LOW.
> -
> -Example:
> -
> -adc@0 {
> - compatible = "adi,ad7780";
> - reg = <0>;
> - vref-supply = <_supply>
> -
> - powerdown-gpios = < 12 GPIO_ACTIVE_HIGH>;
> - adi,gain-gpios = < 5 GPIO_ACTIVE_LOW>;
> - adi,filter-gpios = < 15 GPIO_ACTIVE_LOW>;
> -};
> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
> b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
> new file mode 100644
> index ..931bc4f8ec04
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
> @@ -0,0 +1,85 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/adc/adi,ad7780.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices AD7170/AD7171/AD7780/AD7781 analog to digital
> converters
> +
> +maintainers:
> + - Michael Hennerich
> +
> +description: |
> + The ad7780 is a sigma-delta analog to digital converter. This driver
> provides
> + reading voltage values and status bits from both the ad778x and ad717x
> series.
> + Its interface also allows writing on the FILTER and GAIN GPIO pins on the
> + ad778x.
> +
> + Specifications on the converters can be found at:
> +AD7170:
> +
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD7170.pdf
> +AD7171:
> +
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD7171.pdf
> +AD7780:
> +
> https://www.analog.com/media/en/technical-documentation/data-sheets/ad7780.pdf
> +AD7781:
> +
> https://www.analog.com/media/en/technical-documentation/data-sheets/AD7781.pdf
> +
> +properties:
> + compatible:
> +enum:
> + - adi,ad7170
> + - adi,ad7171
> + - adi,ad7780
> + - adi,ad7781
> +
> + reg:
> +description:
> + Chip select number for the device
> +maxItems: 1
> +
> + vref-supply:
> +description:
> + The regulator supply for the ADC reference voltage
> +maxItems: 1
> +
> + powerdown-gpios:
> +description:
> + Must be the device tree identifier of the PDRST pin. If
> + specified, it will be asserted during driver probe. As the
> + line is active high, it should be marked GPIO_ACTIVE_HIGH.
> +maxItems: 1
> +
> + adi,gain-gpios:
> +description:
> + Must be the device tree identifier of the GAIN pin. Only for
> + the
Re: [PATCH] staging: iio: ad9832: Add device tree support
On Sat, 18 May 2019 17:48:25 -0300
João Seckler wrote:
> Add a of_device_id struct variable and subsequent call to
> MODULE_DEVICE_TABLE macro to support device tree.
>
> Signed-off-by: João Seckler
> Signed-off-by: Anderson Reis
> Co-developed-by: Anderson Reis
> Signed-off-by: Andre Tadeu de Carvalho
> Co-developed-by: Andre Tadeu de Carvalho
Hi All,
Missing the setting of the relevant entry in the spi_driver structure.
Otherwise looks fine,
Thanks,
Jonathan
> ---
> drivers/staging/iio/frequency/ad9832.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/staging/iio/frequency/ad9832.c
> b/drivers/staging/iio/frequency/ad9832.c
> index 74308a2e72db..51e97c74c6b2 100644
> --- a/drivers/staging/iio/frequency/ad9832.c
> +++ b/drivers/staging/iio/frequency/ad9832.c
> @@ -451,6 +451,13 @@ static int ad9832_remove(struct spi_device *spi)
> return 0;
> }
>
> +static const struct of_device_id ad9832_of_match[] = {
> + { .compatible = "adi,ad9832", },
> + { .compatible = "adi,ad9835", },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, ad9832_of_match);
> +
> static const struct spi_device_id ad9832_id[] = {
> {"ad9832", 0},
> {"ad9835", 0},
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: iio: ad2s1210: Add devicetree yaml doc
On Sat, 18 May 2019 19:15:58 -0300
Tallys Martins wrote:
> The driver currently has no devicetree documentation. This commit adds a
> devicetree folder and documentation for it. Documentation must be moved
> as well when the driver gets out of staging.
>
> Signed-off-by: Tallys Martins
> Signed-off-by: Souza Guilherme
> Co-developed-by: Souza Guilherme
Hi,
There is no need for a direct relationship between a binding and a driver
at all. As such, we normally don't take binding documents in staging.
Just put it directly in it's final destination. The driver can catch
up with it later!
I'm still not that comfortable with yaml (haven't gotten around
to doing any conversions myself yet) so I'll be looking for additional
review on these from others.
A few comments inline.
> ---
> .../Documentation/devicetree/ad2s1210.yaml| 41 +++
> 1 file changed, 41 insertions(+)
> create mode 100644 drivers/staging/iio/Documentation/devicetree/ad2s1210.yaml
>
> diff --git a/drivers/staging/iio/Documentation/devicetree/ad2s1210.yaml
> b/drivers/staging/iio/Documentation/devicetree/ad2s1210.yaml
> new file mode 100644
> index ..733aa07b4626
> --- /dev/null
> +++ b/drivers/staging/iio/Documentation/devicetree/ad2s1210.yaml
> @@ -0,0 +1,41 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/iio/ad2s1210.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: |
> + Analog Devices Inc. AD2S1210 10-Bit to 16-Bit R/D Converters
> +
> +maintainers:
> + - Graff Yang
I would check that one with the Analog devices team.
> +
> +description: |
> + Analog Devices AD2S1210 Resolver to Digital SPI driver
> +
> + https://www.analog.com/en/products/ad2s1210.html
> +
> +properties:
> + compatible:
> +enum:
> + - adi,ad2s1210
> +
> + reg:
> +maxItems: 1
> +
> + clock-frequency:
> +minimum: 2000
> +maximum: 2
> +default: 8192
This doesn't look like a modern clock binding.
If we are going to end up changing this, then we should probably delay
having a binding doc until after that change is made.
We often only do binding docs for drivers in staging just before moving
them out so as to avoid this sort of issue.
> +
> +required:
> + - compatible
> + - reg
> +
> +examples:
> + - |
> + resolver@0 {
> +compatible = "adi,ad2s1210";
> +reg = <0>;
An example is probably more useful if it includes all the optional properties
as well.
> + };
> +...
Thanks,
Jonathan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: iio: ad2s1210: Destroy mutex at remove
On Sat, 18 May 2019 19:15:57 -0300
Tallys Martins wrote:
> Ensure the mutex will be destroyed on drive removal.
> Also adds mutex comment description.
>
> Signed-off-by: Tallys Martins
> Signed-off-by: Souza Guilherme
> Co-developed-by: Souza Guilherme
Hi.
This particular 'issue' is never a simple one.
The destroy_mutex call is intended for lock debugging only,
which is why there is devm_init_mutex or similar to allow for
automatic unwinding.
It simple cleanup paths like this, it provides very little value
and leads to a more complex unwind.
It is for this reason that the vast majority of drivers simply
don't bother.
Hence, unless there is a good reason I'm missing I won't be
introducing more of them.
Thanks,
Jonathan
> ---
> drivers/staging/iio/resolver/ad2s1210.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/iio/resolver/ad2s1210.c
> b/drivers/staging/iio/resolver/ad2s1210.c
> index b6be0bc202f5..b91cf57c5e57 100644
> --- a/drivers/staging/iio/resolver/ad2s1210.c
> +++ b/drivers/staging/iio/resolver/ad2s1210.c
> @@ -86,7 +86,7 @@ static const struct ad2s1210_gpio gpios[] = {
> static const unsigned int ad2s1210_resolution_value[] = { 10, 12, 14, 16 };
>
> struct ad2s1210_state {
> - struct mutex lock;
> + struct mutex lock; /* lock to protect the state on r/w operations */
> struct spi_device *sdev;
> struct gpio_desc *gpios[5];
> unsigned int fclkin;
> @@ -689,8 +689,10 @@ static int ad2s1210_probe(struct spi_device *spi)
> static int ad2s1210_remove(struct spi_device *spi)
> {
> struct iio_dev *indio_dev = spi_get_drvdata(spi);
> + struct ad2s1210_state *ad2s1210_ad = iio_priv(indio_dev);
>
> iio_device_unregister(indio_dev);
> + mutex_destroy(_ad->lock);
>
> return 0;
> }
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: ad7746: add device tree support
On Sun, 19 May 2019 12:02:50 +0100
Jonathan Cameron wrote:
> On Sat, 18 May 2019 19:27:33 -0300
> João Seckler wrote:
>
> > Add a of_device_id struct variable and subsequent call to
> > MODULE_DEVICE_TABLE macro to support device tree.
> >
> > Signed-off-by: João Seckler
> > Signed-off-by: Lucas Oshiro
> > Co-developed-by: Lucas Oshiro
> Applied to the togreg branch of iio.git and pushed out as testing
> for the autobuilders to play with it.
>
> For a future improvement, try to explain the 'why' rather than
> 'what' of a patch in the description. This particular change
> is so common I don't mind that much, but it is a good habit to
> get into!
Ah, you do say to support device tree at the end, but more
detail on that would have been good!
Thanks,
J
>
> Thanks,
>
> Jonathan
> > ---
> > drivers/staging/iio/cdc/ad7746.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/staging/iio/cdc/ad7746.c
> > b/drivers/staging/iio/cdc/ad7746.c
> > index 47610d863908..21527d84f940 100644
> > --- a/drivers/staging/iio/cdc/ad7746.c
> > +++ b/drivers/staging/iio/cdc/ad7746.c
> > @@ -748,9 +748,19 @@ static const struct i2c_device_id ad7746_id[] = {
> >
> > MODULE_DEVICE_TABLE(i2c, ad7746_id);
> >
> > +static const struct of_device_id ad7746_of_match[] = {
> > + { .compatible = "adi,ad7745" },
> > + { .compatible = "adi,ad7746" },
> > + { .compatible = "adi,ad7747" },
> > + { },
> > +};
> > +
> > +MODULE_DEVICE_TABLE(of, ad7746_of_match);
> > +
> > static struct i2c_driver ad7746_driver = {
> > .driver = {
> > .name = KBUILD_MODNAME,
> > + .of_match_table = ad7746_of_match,
> > },
> > .probe = ad7746_probe,
> > .id_table = ad7746_id,
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: ad7746: add device tree support
On Sat, 18 May 2019 19:27:33 -0300
João Seckler wrote:
> Add a of_device_id struct variable and subsequent call to
> MODULE_DEVICE_TABLE macro to support device tree.
>
> Signed-off-by: João Seckler
> Signed-off-by: Lucas Oshiro
> Co-developed-by: Lucas Oshiro
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
For a future improvement, try to explain the 'why' rather than
'what' of a patch in the description. This particular change
is so common I don't mind that much, but it is a good habit to
get into!
Thanks,
Jonathan
> ---
> drivers/staging/iio/cdc/ad7746.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/staging/iio/cdc/ad7746.c
> b/drivers/staging/iio/cdc/ad7746.c
> index 47610d863908..21527d84f940 100644
> --- a/drivers/staging/iio/cdc/ad7746.c
> +++ b/drivers/staging/iio/cdc/ad7746.c
> @@ -748,9 +748,19 @@ static const struct i2c_device_id ad7746_id[] = {
>
> MODULE_DEVICE_TABLE(i2c, ad7746_id);
>
> +static const struct of_device_id ad7746_of_match[] = {
> + { .compatible = "adi,ad7745" },
> + { .compatible = "adi,ad7746" },
> + { .compatible = "adi,ad7747" },
> + { },
> +};
> +
> +MODULE_DEVICE_TABLE(of, ad7746_of_match);
> +
> static struct i2c_driver ad7746_driver = {
> .driver = {
> .name = KBUILD_MODNAME,
> + .of_match_table = ad7746_of_match,
> },
> .probe = ad7746_probe,
> .id_table = ad7746_id,
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: iio: adis16240: add device to module device table
On Sat, 18 May 2019 18:44:34 -0300
Lucas Oshiro wrote:
> Add a of_device_id struct and MODULE_DEVICE_TABLE call, in order to add
> device-tree support for this driver.
>
> Signed-off-by: Lucas Oshiro
> Signed-off-by: Rodrigo Ribeiro
> Co-developed-by: Rodrigo Ribeiro
Hi Lucas, Rodrigo,
The description isn't 100% accurate but it's close enough.
Ever since devicetree was introduced, there has been a fallback mode for
i2c and spi devices in which, in the absence of either a devicetree match table
or an ACPI one, an attempt is made to match against the older i2c_device_id
table entries.
So it'll 'work' for devicetree bindings without this patch, but by a less
controlled route and one that doesn't allow for the possibility of
multiple manufacturers using the same part number.
Hence these are good changes to make. Simplifying the description to enabling
devicetree probing is fine though.
Under drivers/spi.c, devices probed via a device tree binding use:
of_register_spi_device (applied to all children of an spi bus, so the slave
devices). This calls of_modalias_node which performs a copy of the
compatible without the manufacturer ID into the modalias field.
Later, spi_match_device is called, which first attempts
of_driver_match_device which I think does the precise match.
If that fails, it tries ACPI, and failing that it falls back to matching
the modalias against the id_table entries. Thus it can still
work without these entries but they do make it simpler and more consistent.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/staging/iio/accel/adis16240.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/staging/iio/accel/adis16240.c
> b/drivers/staging/iio/accel/adis16240.c
> index b80e0d248b0f..8c6d23604eca 100644
> --- a/drivers/staging/iio/accel/adis16240.c
> +++ b/drivers/staging/iio/accel/adis16240.c
> @@ -435,6 +435,12 @@ static int adis16240_remove(struct spi_device *spi)
> return 0;
> }
>
> +static const struct of_device_id adis16240_of_match[] = {
> + { .compatible = "adi,adis16240" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, adis16240_of_match);
> +
> static struct spi_driver adis16240_driver = {
> .driver = {
> .name = "adis16240",
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH] staging: iio: ad7192: create of_device_id array
On Sat, 18 May 2019 19:44:35 -0300
Bárbara Fernandes wrote:
> Create list of compatible device ids to be matched with those stated in
> the device tree.
>
> Signed-off-by: Bárbara Fernandes
> Signed-off-by: Wilson Sales
> Co-developed by: Wilson Sales
Hi Bárbara, Wilson,
One minor issue inline about code ordering.
Actual content is fine.
Thanks,
Jonathan
> ---
> drivers/staging/iio/adc/ad7192.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/staging/iio/adc/ad7192.c
> b/drivers/staging/iio/adc/ad7192.c
> index 3d74da9d37e7..cc886f944dbf 100644
> --- a/drivers/staging/iio/adc/ad7192.c
> +++ b/drivers/staging/iio/adc/ad7192.c
> @@ -810,11 +810,23 @@ static const struct spi_device_id ad7192_id[] = {
> {"ad7195", ID_AD7195},
> {}
> };
> +
> +static const struct of_device_id ad7192_of_spi_match[] = {
> + { .compatible = "adi,ad7190" },
> + { .compatible = "adi,ad7192" },
> + { .compatible = "adi,ad7193" },
> + { .compatible = "adi,ad7195" },
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(of, ad7192_of_spi_match);
> +
Please keep the declaration of the table alongside the relevant
MODULE_DEVICE_TABLE.
In short, better to have your additions after this next line.
> MODULE_DEVICE_TABLE(spi, ad7192_id);
>
> static struct spi_driver ad7192_driver = {
> .driver = {
> .name = "ad7192",
> + .of_match_table = ad7192_of_spi_match,
> },
> .probe = ad7192_probe,
> .remove = ad7192_remove,
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH] staging: iio: adt7316: create of_device_id array
On Sat, 18 May 2019 19:43:33 -0300
Bárbara Fernandes wrote:
> Create structure of type of_device_id in order to register all devices
> the driver is able to manage.
>
> Signed-off-by: Bárbara Fernandes
> Signed-off-by: Wilson Sales
> Co-developed-by: Wilson Sales
Looks good to me.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/staging/iio/addac/adt7316-spi.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/staging/iio/addac/adt7316-spi.c
> b/drivers/staging/iio/addac/adt7316-spi.c
> index 8294b9c1e3c2..9968775f1d23 100644
> --- a/drivers/staging/iio/addac/adt7316-spi.c
> +++ b/drivers/staging/iio/addac/adt7316-spi.c
> @@ -127,9 +127,22 @@ static const struct spi_device_id adt7316_spi_id[] = {
>
> MODULE_DEVICE_TABLE(spi, adt7316_spi_id);
>
> +static const struct of_device_id adt7316_of_spi_match[] = {
> + { .compatible = "adi,adt7316" },
> + { .compatible = "adi,adt7317" },
> + { .compatible = "adi,adt7318" },
> + { .compatible = "adi,adt7516" },
> + { .compatible = "adi,adt7517" },
> + { .compatible = "adi,adt7519" },
> + { }
> +};
> +
> +MODULE_DEVICE_TABLE(of, adt7316_of_spi_match);
> +
> static struct spi_driver adt7316_driver = {
> .driver = {
> .name = "adt7316",
> + .of_match_table = adt7316_of_spi_match,
> .pm = ADT7316_PM_OPS,
> },
> .probe = adt7316_spi_probe,
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: adis16203: Add of_device_id table
On Sat, 18 May 2019 19:42:13 -0300
Thiago Estrela wrote:
> Accomplish device tree compatibility to driver ADIS16203
> by adding of_device_id table and making a subsequent call to
> MODULE_DEVICE_TABLE.
>
> Signed-off-by: Thiago Estrela
> Signed-off-by: Tiago Napoli
> Co-developed-by: Tiago Napoli
> Signed-off-by: Pedro Sousa
> Co-developed-by: Pedro Sousa
> Reviewed-by: Matheus Tavares
> Reviewed-by: Marcelo Schmitt
Another nice patch. Certainly seems like the dev day was
successful and welcome to so many new people.
Applied to the togreg branch of iio.git and pushed out as
testing for the autobuilders to see if we missed anything.
Thanks,
Jonathan
> ---
> drivers/staging/iio/accel/adis16203.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/staging/iio/accel/adis16203.c
> b/drivers/staging/iio/accel/adis16203.c
> index 70381756a64a..a5d974ac2e3b 100644
> --- a/drivers/staging/iio/accel/adis16203.c
> +++ b/drivers/staging/iio/accel/adis16203.c
> @@ -311,9 +311,17 @@ static int adis16203_remove(struct spi_device *spi)
> return 0;
> }
>
> +static const struct of_device_id adis16203_of_match[] = {
> + { .compatible = "adi,adis16203" },
> + { },
> +};
> +
> +MODULE_DEVICE_TABLE(of, adis16203_of_match);
> +
> static struct spi_driver adis16203_driver = {
> .driver = {
> .name = "adis16203",
> + .of_match_table = adis16203_of_match,
> },
> .probe = adis16203_probe,
> .remove = adis16203_remove,
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: iio: ad9834: add of_device_id table
On Sat, 18 May 2019 19:47:20 -0300
João Victor Marques de Oliveira wrote:
> Add a of_device_id struct array of_match_table variable and subsequent
> call to MODULE_DEVICE_TABLE macro to device tree support.
>
> Co-developed-by: Thiago L. A. Miller
> Signed-off-by: Thiago L. A. Miller
> Co-developed-by: Osvaldo M. Yasuda
> Signed-off-by: Osvaldo M. Yasuda
> Signed-off-by: João Victor Marques de Oliveira
Nice patch.
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.
Thanks,
j
> ---
> drivers/staging/iio/frequency/ad9834.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/staging/iio/frequency/ad9834.c
> b/drivers/staging/iio/frequency/ad9834.c
> index 6de3cd7363d7..038d6732c3fd 100644
> --- a/drivers/staging/iio/frequency/ad9834.c
> +++ b/drivers/staging/iio/frequency/ad9834.c
> @@ -521,9 +521,20 @@ static const struct spi_device_id ad9834_id[] = {
> };
> MODULE_DEVICE_TABLE(spi, ad9834_id);
>
> +static const struct of_device_id ad9834_of_match[] = {
> + {.compatible = "adi,ad9833"},
> + {.compatible = "adi,ad9834"},
> + {.compatible = "adi,ad9837"},
> + {.compatible = "adi,ad9838"},
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(of, ad9834_of_match);
> +
> static struct spi_driver ad9834_driver = {
> .driver = {
> .name = "ad9834",
> + .of_match_table = ad9834_of_match
> },
> .probe = ad9834_probe,
> .remove = ad9834_remove,
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging:iio:ad7150: fix threshold mode config bit
On Sat, 18 May 2019 22:04:56 -0300
Melissa Wen wrote:
> According to the AD7150 configuration register description, bit 7 assumes
> value 1 when the threshold mode is fixed and 0 when it is adaptive,
> however, the operation that identifies this mode was considering the
> opposite values.
>
> This patch renames the boolean variable to describe it correctly and
> properly replaces it in the places where it is used.
>
> Fixes: 531efd6aa0991 ("staging:iio:adc:ad7150: chan_spec conv + i2c_smbus
> commands + drop unused poweroff timeout control.")
> Signed-off-by: Melissa Wen
Looks good to me. Applied to the fixes-togreg branch of iio.git pushed out as
as testing-fixes for the autobuilders to see if they can find anything
we have missed.
Thanks,
Jonathan
> ---
> drivers/staging/iio/cdc/ad7150.c | 19 +++
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/iio/cdc/ad7150.c
> b/drivers/staging/iio/cdc/ad7150.c
> index dd7fcab8e19e..e075244c602b 100644
> --- a/drivers/staging/iio/cdc/ad7150.c
> +++ b/drivers/staging/iio/cdc/ad7150.c
> @@ -5,6 +5,7 @@
> * Copyright 2010-2011 Analog Devices Inc.
> */
>
> +#include
> #include
> #include
> #include
> @@ -130,7 +131,7 @@ static int ad7150_read_event_config(struct iio_dev
> *indio_dev,
> {
> int ret;
> u8 threshtype;
> - bool adaptive;
> + bool thrfixed;
> struct ad7150_chip_info *chip = iio_priv(indio_dev);
>
> ret = i2c_smbus_read_byte_data(chip->client, AD7150_CFG);
> @@ -138,21 +139,23 @@ static int ad7150_read_event_config(struct iio_dev
> *indio_dev,
> return ret;
>
> threshtype = (ret >> 5) & 0x03;
> - adaptive = !!(ret & 0x80);
> +
> + /*check if threshold mode is fixed or adaptive*/
> + thrfixed = FIELD_GET(AD7150_CFG_FIX, ret);
>
> switch (type) {
> case IIO_EV_TYPE_MAG_ADAPTIVE:
> if (dir == IIO_EV_DIR_RISING)
> - return adaptive && (threshtype == 0x1);
> - return adaptive && (threshtype == 0x0);
> + return !thrfixed && (threshtype == 0x1);
> + return !thrfixed && (threshtype == 0x0);
> case IIO_EV_TYPE_THRESH_ADAPTIVE:
> if (dir == IIO_EV_DIR_RISING)
> - return adaptive && (threshtype == 0x3);
> - return adaptive && (threshtype == 0x2);
> + return !thrfixed && (threshtype == 0x3);
> + return !thrfixed && (threshtype == 0x2);
> case IIO_EV_TYPE_THRESH:
> if (dir == IIO_EV_DIR_RISING)
> - return !adaptive && (threshtype == 0x1);
> - return !adaptive && (threshtype == 0x0);
> + return thrfixed && (threshtype == 0x1);
> + return thrfixed && (threshtype == 0x0);
> default:
> break;
> }
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: iio: cdc: ad7150: create macro for capacitance channels
On Sat, 18 May 2019 19:41:36 -0300
Bárbara Fernandes wrote:
> Create macro for capacitance channels in order to remove the repeated
> code and improve its readability.
>
> Signed-off-by: Bárbara Fernandes
> Signed-off-by: Wilson Sales
> Co-developed-by: Wilson Sales
Not a totally clear cut case given there are only two instances, but
I think, on balance that it is an improvement.
As this isn't really connected to patch 1 in the series (or the fix
going via the other tree) I'll apply this one now. Please only
send a new version of patch 1.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders (0-day etc) to see if they can find anything
we have missed.
Some time after those test results have come in, I'll push the tree
out as togreg, and in a few weeks send a pull request to Greg to
hopefully have it pulled into his tree which is part of Linux next
and from which he will then send a pull request to Linus in the
next merge window.
Thanks,
Jonathan
> ---
> drivers/staging/iio/cdc/ad7150.c | 29 -
> 1 file changed, 12 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/staging/iio/cdc/ad7150.c
> b/drivers/staging/iio/cdc/ad7150.c
> index 072094227e1b..d8c43cabce25 100644
> --- a/drivers/staging/iio/cdc/ad7150.c
> +++ b/drivers/staging/iio/cdc/ad7150.c
> @@ -468,24 +468,19 @@ static const struct iio_event_spec ad7150_events[] = {
> },
> };
>
> +#define AD7150_CAPACITANCE_CHAN(_chan) { \
> + .type = IIO_CAPACITANCE,\
> + .indexed = 1, \
> + .channel = _chan, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
> + BIT(IIO_CHAN_INFO_AVERAGE_RAW), \
> + .event_spec = ad7150_events,\
> + .num_event_specs = ARRAY_SIZE(ad7150_events), \
> + }
> +
> static const struct iio_chan_spec ad7150_channels[] = {
> - {
> - .type = IIO_CAPACITANCE,
> - .indexed = 1,
> - .channel = 0,
> - .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> - BIT(IIO_CHAN_INFO_AVERAGE_RAW),
> - .event_spec = ad7150_events,
> - .num_event_specs = ARRAY_SIZE(ad7150_events),
> - }, {
> - .type = IIO_CAPACITANCE,
> - .indexed = 1,
> - .channel = 1,
> - .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> - BIT(IIO_CHAN_INFO_AVERAGE_RAW),
> - .event_spec = ad7150_events,
> - .num_event_specs = ARRAY_SIZE(ad7150_events),
> - },
> + AD7150_CAPACITANCE_CHAN(0),
> + AD7150_CAPACITANCE_CHAN(1)
> };
>
> /*
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: iio: cdc: ad7150: create of_device_id array
On Sat, 18 May 2019 19:41:35 -0300
Bárbara Fernandes wrote:
> Create structure of type of_device_id in order to register all devices
> the driver is able to manage.
>
> Signed-off-by: Bárbara Fernandes
> Signed-off-by: Melissa Wen
> Co-developed-by: Melissa Wen
> Signed-off-by: Wilson Sales
> Co-developed-by: Wilson Sales
Hi,
One really minor point inline, otherwise looks good to me.
Thanks,
Jonathan
> ---
> drivers/staging/iio/cdc/ad7150.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/staging/iio/cdc/ad7150.c
> b/drivers/staging/iio/cdc/ad7150.c
> index 4b1c90e1b0ea..072094227e1b 100644
> --- a/drivers/staging/iio/cdc/ad7150.c
> +++ b/drivers/staging/iio/cdc/ad7150.c
> @@ -655,11 +655,21 @@ static const struct i2c_device_id ad7150_id[] = {
> {}
> };
>
> +static const struct of_device_id ad7150_of_i2c_match[] = {
> + { .compatible = "adi,ad7150" },
> + { .compatible = "adi,ad7151" },
> + { .compatible = "adi,ad7156" },
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(of, ad7150_of_i2c_match);
> +
I would suggest keeping the below MODULE_DEVICE_TABLE
entry next to the definition of ad7150_id rather than putting
this new block in between them.
In short, just move your additions below the next line.
Thanks,
Jonathan
> MODULE_DEVICE_TABLE(i2c, ad7150_id);
>
> static struct i2c_driver ad7150_driver = {
> .driver = {
> .name = "ad7150",
> + .of_match_table = ad7150_of_i2c_match
> },
> .probe = ad7150_probe,
> .id_table = ad7150_id,
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
