DriverDev-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Mark Brown <broonie@kernel.org>
Cc: "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"lars@metafoo.de" <lars@metafoo.de>,
	"Hennerich, Michael" <Michael.Hennerich@analog.com>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"rodrigorsdc@gmail.com" <rodrigorsdc@gmail.com>,
	"kernel-usp@googlegroups.com" <kernel-usp@googlegroups.com>,
	"pmeerw@pmeerw.net" <pmeerw@pmeerw.net>,
	"knaack.h@gmx.de" <knaack.h@gmx.de>,
	"Ardelean, Alexandru" <alexandru.Ardelean@analog.com>,
	"Popa, Stefan Serban" <StefanSerban.Popa@analog.com>,
	Jonathan Cameron <jic23@kernel.org>
Subject: Re: [PATCH v4] dt-bindings: iio: accel: add binding documentation for ADIS16240
Date: Tue, 3 Dec 2019 16:51:54 +0000
Message-ID: <20191203165154.00005793@Huawei.com> (raw)
In-Reply-To: <20191203163850.GN1998@sirena.org.uk>

On Tue, 3 Dec 2019 16:38:50 +0000
Mark Brown <broonie@kernel.org> 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
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

  reply index

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-23  5:19 Rodrigo Carvalho
2019-11-23 11:41 ` Jonathan Cameron
2019-11-25  7:51   ` Ardelean, Alexandru
2019-12-01 11:40     ` Jonathan Cameron
2019-12-03 16:38       ` Mark Brown
2019-12-03 16:51         ` Jonathan Cameron [this message]
2019-12-04  7:18           ` Ardelean, Alexandru
2019-12-04 17:00             ` Mark Brown
2019-12-05  8:19               ` Ardelean, Alexandru
2019-12-04 11:12           ` Mark Brown

Reply instructions:

You may reply publically 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=20191203165154.00005793@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=StefanSerban.Popa@analog.com \
    --cc=alexandru.Ardelean@analog.com \
    --cc=broonie@kernel.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jic23@kernel.org \
    --cc=kernel-usp@googlegroups.com \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    --cc=rodrigorsdc@gmail.com \
    /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

DriverDev-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/driverdev-devel/0 driverdev-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 driverdev-devel driverdev-devel/ https://lore.kernel.org/driverdev-devel \
		driverdev-devel@linuxdriverproject.org devel@driverdev.osuosl.org
	public-inbox-index driverdev-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.linuxdriverproject.driverdev-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git