Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Dmitry Rokosov <DDRokosov@sberdevices.ru>
To:     Andy Shevchenko <andy.shevchenko@gmail.com>
CC:     Jonathan Cameron <jic23@kernel.org>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>,
        "stano.jakubek@gmail.com" <stano.jakubek@gmail.com>,
        "shawnguo@kernel.org" <shawnguo@kernel.org>,
        "lars@metafoo.de" <lars@metafoo.de>,
        "stephan@gerhold.net" <stephan@gerhold.net>,
        "linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        kernel <kernel@sberdevices.ru>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 2/3] iio: add MEMSensing MSA311 3-axis accelerometer
 driver
Thread-Topic: [PATCH v4 2/3] iio: add MEMSensing MSA311 3-axis accelerometer
 driver
Thread-Index: AQHYpzqIoQnaRj7vNkq2cXUUGjAB/62dQgeAgAAYQICABG4VgIAEYneAgAADdACAAAhqgA==
Date:   Tue, 9 Aug 2022 10:35:19 +0000
Message-ID: <20220809103519.437rcude7fstxyy4@CAB-WSD-L081021.sigma.sbrf.ru>
References: <20220803131132.19630-1-ddrokosov@sberdevices.ru>
 <20220803131132.19630-3-ddrokosov@sberdevices.ru>
 <CAHp75VcVuC6yVoB1kycCOfqMa=JfCtbe3WYSK5qndtYcJy3vpg@mail.gmail.com>
 <20220803191621.tzrmndkygfe7nlpx@CAB-WSD-L081021.sigma.sbrf.ru>
 <20220806155523.37c3e587@jic23-huawei>
 <20220809095251.vpp6arac3pkntdlo@CAB-WSD-L081021.sigma.sbrf.ru>
 <CAHp75Vc9LGX-=Y2smOrKuAgSRrhA0AgGuBE-0=_-q78FpSB6ag@mail.gmail.com>
In-Reply-To: <CAHp75Vc9LGX-=Y2smOrKuAgSRrhA0AgGuBE-0=_-q78FpSB6ag@mail.gmail.com>
Accept-Language: ru-RU, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4A44EE2DD7C669428F74395D26CCE4BE@sberdevices.ru>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: bulk

On Tue, Aug 09, 2022 at 12:05:12PM +0200, Andy Shevchenko wrote:
> > > > > > +       indio_dev->modes =3D 0; /* setup buffered mode later */
> > > > >
> > > > > Why explicit assignment to 0? Doesn't kzalloc() do it for you?
> > > >
> > > > kzalloc() will do it for me, of course. Previously, I initialized m=
odes to
> > > > INDIO_DIRECT_MODE to just provide default value for that. Jonathan
> > > > suggested to replace it with 0.
> > >
> > > I did?  I wonder what I was smoking that day.
> > > Should be set to INDIO_DIRECT_MODE as you had it previously.
> > >
> > > (From what I recall it will work either way but we have in the past h=
ad
> > > core code that checked this and may do again in the future so drivers=
 should
> > > still be setting it to specify they provide sysfs interfaces to direc=
tly read
> > > the channels).
> >
> > Jonathan, really sorry I referred to you. I'm confused. This comment wa=
s
> > from Andy in the v3 discussion:
> >
> > https://lore.kernel.org/linux-iio/CAHp75Vc0+ckNnm2tzLMPrjeFRjwoj3zy0C4k=
oNShFRG3kP8b6w@mail.gmail.com/
>=20
> Indeed. I was confused by the comment. My understanding at that time
> was that the triggered mode is inevitable and hence assigning to
> something which _will_ be reassigned later makes a little sense. So,
> does it mean that triggered mode is optional and might not be set? In
> such a case the comment is misleading.

Actually, this comment was introduced in the early MSA311 driver
versions, when I have made buffer setup only if HW irq is enabled. In
the newest versions buffer is setup unconditionally, because buffer mode
can be used based on hrtimer software trigger.

Jonathan, why we shouldn't delete INDIO_DIRECT_MODE initialization if
after couple of lines we always setup buffer mode?

--=20
Thank you,
Dmitry=