linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: "Ardelean, Alexandru" <alexandru.Ardelean@analog.com>,
	David Jander <david@protonic.nl>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>
Subject: Re: [PATCH v1] Input: ads7846: do not overwrite spi->mode flags set by spi framework
Date: Mon, 26 Oct 2020 20:53:09 -0700	[thread overview]
Message-ID: <20201027035309.GI444962@dtor-ws> (raw)
In-Reply-To: <20201022065402.x7hlp2zncmnjyum7@pengutronix.de>

On Thu, Oct 22, 2020 at 08:54:02AM +0200, Oleksij Rempel wrote:
> On Wed, Oct 21, 2020 at 11:27:57AM -0700, Dmitry Torokhov wrote:
> > On Wed, Oct 21, 2020 at 12:56:14PM +0200, Oleksij Rempel wrote:
> > > 
> > > As you can see, I would need to configure my dts with spi-cs-high flag,
> > > even if the hardware is actually ACTIVE_LOW. If I will go this way, I
> > > would risk a regression as soon as this issue is fixed.
> > > 
> > > Since the spi framework is already parsing devicetree and set all needed
> > > flags, I assume it is wrong to blindly drop all this flags in the
> > > driver.
> > 
> > Yes, but I wonder if the devices can only work in mode 0 we should be
> > doing:
> > 
> > 	spi->mode &= ~SPI_MODE_MASK; // to be defined as 0x03 in spi.h
> > 	spi->mode |= SPI_MODE_0;
> > 
> > as we can't simply "or" mode value as is
> 
> Why not? This values are taken from device tree. If some developer
> decided to add them, then driver should take it over. Even if this
> values will break the functionality.
> 
> Other properties of this driver will break the functionality too of this
> driver too, so why should we silently filter only set of this bits?

What I was trying to say is that if driver wants to set mode to
particular value it should not "or" the value, as it will not reset the
relevant bits. I.e. if there some undesirable data in spi->mode mode
bits it will not get set properly by essentially doing "spi->mode |= 0".
That is why I said the driver needs to clear mode bits and set them to
the desired mode.

Thanks.

-- 
Dmitry

  reply	other threads:[~2020-10-27  3:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-21  9:04 [PATCH v1] Input: ads7846: do not overwrite spi->mode flags set by spi framework Oleksij Rempel
2020-10-21  9:29 ` Ardelean, Alexandru
2020-10-21 10:56   ` Oleksij Rempel
2020-10-21 18:27     ` Dmitry Torokhov
2020-10-22  6:54       ` Oleksij Rempel
2020-10-27  3:53         ` Dmitry Torokhov [this message]
2020-10-27  8:07           ` Oleksij Rempel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201027035309.GI444962@dtor-ws \
    --to=dmitry.torokhov@gmail.com \
    --cc=alexandru.Ardelean@analog.com \
    --cc=david@protonic.nl \
    --cc=kernel@pengutronix.de \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).