[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191013210455.GA16344@jack.zhora.eu>
Date: Mon, 14 Oct 2019 00:04:55 +0300
From: Andi Shyti <andi@...zian.org>
To: Stephan Gerhold <stephan@...hold.net>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Andi Shyti <andi@...zian.org>,
Simon Shields <simon@...eageos.org>,
linux-input@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] Input: mms114 - add support for mms345l
Hi Stephan,
> > > There was a related patch [2] that removes I2C_M_NOSTART for all models,
> > > but it seems abandoned and I do not have any other model for testing.
> > > Therefore, this patch implements the least instrusive solution
> > > and only removes I2C_M_NOSTART for MMS345L.
> >
> > Hmm, at this point I am inclined to pick up Andi's patch since it seems
> > to work for you and him and it looks like Android drivers are not using
> > I2C_M_NOSTART. I wonder if this was some quirk/big on the platform where
> > it was originally developed.
> >
> > Any objections?
>
> I cannot really speak for any of the other models, but no objections for
> removing I2C_M_NOSTART from my side. I'm actually rather confused by it
> since it is used on the first partial message.
>
> The documentation [1] says:
> If you set the I2C_M_NOSTART variable for the first partial message,
> we do not generate Addr, but we do generate the startbit S.
> ** This will probably confuse all other clients on your bus,
> so don't try this. **
>
> Yet, someone felt like trying this here. ;)
still it should be specified in the i2c protocol of the device,
if it's not, then most probably it's not needed, I guess.
Andi
Powered by blists - more mailing lists