[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181021150857.4f9c2244@archlinux>
Date: Sun, 21 Oct 2018 15:08:57 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Song Qiang <songqiang1304521@...il.com>
Cc: Himanshu Jha <himanshujha199640@...il.com>, knaack.h@....de,
lars@...afoo.de, pmeerw@...erw.net, robh+dt@...nel.org,
mark.rutland@....com, preid@...ctromag.com.au,
linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 3/3] iio: magnetometer: Add driver support for PNI
RM3100
On Wed, 17 Oct 2018 16:00:02 +0800
Song Qiang <songqiang1304521@...il.com> wrote:
> On 2018/10/12 下午8:53, Himanshu Jha wrote:
> > Hi Qiang,
> >
> > On Fri, Oct 12, 2018 at 04:36:01PM +0800, Song Qiang wrote:
> >>
> >> On 2018年10月12日 15:35, Song Qiang wrote:
> >>> PNI RM3100 is a high resolution, large signal immunity magnetometer,
> >>> composed of 3 single sensors and a processing chip with a MagI2C
> >>> interface.
> >>>
> >> ...
> >>> +static irqreturn_t rm3100_trigger_handler(int irq, void *p)
> >>> +{
> >>> + struct iio_poll_func *pf = p;
> >>> + struct iio_dev *indio_dev = pf->indio_dev;
> >>> + unsigned long scan_mask = *indio_dev->active_scan_mask;
> >>> + unsigned int mask_len = indio_dev->masklength;
> >>> + struct rm3100_data *data = iio_priv(indio_dev);
> >>> + struct regmap *regmap = data->regmap;
> >>> + int ret, i, bit;
> >>> +
> >>> + mutex_lock(&data->lock);
> >>> + switch (scan_mask) {
> >>> + case BIT(0) | BIT(1) | BIT(2):
> >>> + ret = regmap_bulk_read(regmap, RM3100_REG_MX2, data->buffer, 9);
> >>> + mutex_unlock(&data->lock);
> >>> + if (ret < 0)
> >>> + goto done;
> >>> + break;
> >>> + case BIT(0) | BIT(1):
> >>> + ret = regmap_bulk_read(regmap, RM3100_REG_MX2, data->buffer, 6);
> >>> + mutex_unlock(&data->lock);
> >>> + if (ret < 0)
> >>> + goto done;
> >>> + break;
> >>> + case BIT(1) | BIT(2):
> >>> + ret = regmap_bulk_read(regmap, RM3100_REG_MY2, data->buffer, 6);
> >>> + mutex_unlock(&data->lock);
> >>> + if (ret < 0)
> >>> + goto done;
> >>> + break;
> >> Hi Jonathan,
> >>
> >> I just noticed that these three breaks are not proper aligned.
> > Please send the new version of a patch as a *new* thread and don't
> > use `--in-reply-to` flag(if you're using) to chain into older versions
> > as whole thread of older discussion comes up and is often not required.
> >
> > The changelog gives enough info of what's new in the revised series.
> >
> >
> Hi Himanshu,
>
>
> Thanks for your advise.
>
> I did it because the following instruction tells me to, and I think it's
> also a very quick way of gathering
>
> all scattered messages. Both ways have their own advantages and
> disadvantages I think. :)
>
> <https://kernelnewbies.org/PatchPhilosophy> Section "Updating and
> resending patches".
That's a curious bit of advice. There are certainly a lot of maintainers
who would not want that. It never works with anything beyond trivial
and short patches (we have had patches going to v13 + and hundreds of
emails) - no email client handles that depth and complexity in
a coherent fashion. Replying to previous versions is one of those things
that makes sense until you hit the 'unusual cases' ;)
Oh well. I should probably propose a change to that Doc, but it make
take some time for me to get around to it.
Thanks,
Jonathan
>
>
> yours,
>
> Song Qiang
>
Powered by blists - more mailing lists