From: Peter Rosin <peda@axentia.se>
To: Jonathan Cameron <jic23@kernel.org>, linux-kernel@vger.kernel.org
Cc: Wolfram Sang <wsa@the-dreams.de>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Hartmut Knaack <knaack.h@gmx.de>,
Lars-Peter Clausen <lars@metafoo.de>,
Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
Jonathan Corbet <corbet@lwn.net>,
Andrew Morton <akpm@linux-foundation.org>,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-iio@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v8 12/12] mux: support simplified bindings for single-user gpio mux
Date: Mon, 23 Jan 2017 11:24:18 +0100 [thread overview]
Message-ID: <d32f335f-56f2-38c1-e4d9-4629926dbe21@axentia.se> (raw)
In-Reply-To: <33b29f7e-3e48-b85d-ccf9-93b1d67ac634@kernel.org>
On 2017-01-22 14:30, Jonathan Cameron wrote:
> On 18/01/17 15:57, Peter Rosin wrote:
>> Allow bindings for a GPIO controlled mux to be specified in the
>> mux consumer node.
>>
>> Signed-off-by: Peter Rosin <peda@axentia.se>
> Code is good as far as I am concerned. Only question is whether this
Hmmm, now that I think some more about it, the code supporting the
simplified binding (patch 12/12) is a bit fishy in one respect.
A driver that calls mux_control_get and gets a mux_control that happens
to be backed by an implicit mux chip (i.e. using the simplified binding)
will not be able to reverse the resource allocation with less than a
complete destruction of itself. Now, this is likely not a problem in
most cases, but I bet it will creep up at the most inopportune time. And
your remark that I'm the one that has to maintain this makes me dislike
this concept...
I.e. mux_control_put *should* reverse mux_control_get, but this simply
does not happen for the implicit mux chips, as implicit mux chips are
not put away until the owning device is put away.
Every time I have tried to come up with a way to implement the simplified
bindings I seem to hit one of these subtleties.
> is worth the hassle given the normal bindings don't give that high
> a burden in complexity!
I am missing an ack from Rob though.
> I don't really care either way:)
But Rob seems to care, this series just has to find a way to get out of
his too-much-churn-will-look-at-it-later list. I sadly don't know how to
pull that trick...
Cheers,
peda
next prev parent reply other threads:[~2017-01-23 10:24 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-18 15:57 [PATCH v8 00/12] mux controller abstraction and iio/i2c muxes Peter Rosin
2017-01-18 15:57 ` [PATCH v8 01/12] devres: trivial whitespace fix Peter Rosin
2017-01-18 15:57 ` [PATCH v8 02/12] dt-bindings: document devicetree bindings for mux-controllers and mux-gpio Peter Rosin
2017-01-27 17:49 ` Rob Herring
2017-01-27 18:57 ` Peter Rosin
2017-01-18 15:57 ` [PATCH v8 03/12] mux: minimal mux subsystem and gpio-based mux controller Peter Rosin
2017-01-18 15:57 ` [PATCH v8 04/12] iio: inkern: api for manipulating ext_info of iio channels Peter Rosin
2017-01-18 15:57 ` [PATCH v8 05/12] dt-bindings: iio: io-channel-mux: document io-channel-mux bindings Peter Rosin
2017-01-27 19:12 ` Rob Herring
2017-01-18 15:57 ` [PATCH v8 06/12] iio: multiplexer: new iio category and iio-mux driver Peter Rosin
2017-01-18 15:57 ` [PATCH v8 07/12] dt-bindings: i2c: i2c-mux-simple: document i2c-mux-simple bindings Peter Rosin
2017-01-27 19:39 ` Rob Herring
2017-01-28 22:42 ` Peter Rosin
2017-01-30 17:20 ` Rob Herring
2017-01-31 7:36 ` Peter Rosin
2017-02-02 16:08 ` Rob Herring
2017-02-03 8:25 ` Peter Rosin
2017-02-06 21:22 ` Rob Herring
2017-01-18 15:57 ` [PATCH v8 08/12] i2c: i2c-mux-simple: new driver Peter Rosin
2017-01-18 15:57 ` [PATCH v8 09/12] dt-bindings: mux-adg792a: document devicetree bindings for ADG792A/G mux Peter Rosin
2017-01-27 19:50 ` Rob Herring
2017-01-27 22:09 ` Peter Rosin
2017-01-28 10:34 ` Peter Meerwald-Stadler
2017-01-28 11:40 ` Jonathan Cameron
2017-01-18 15:57 ` [PATCH v8 10/12] mux: adg792a: add mux controller driver for ADG792A/G Peter Rosin
2017-01-18 15:57 ` [PATCH v8 11/12] dt-bindings: simplified bindings for single-user gpio mux Peter Rosin
2017-01-18 15:57 ` [PATCH v8 12/12] mux: support " Peter Rosin
2017-01-22 13:30 ` Jonathan Cameron
2017-01-23 10:24 ` Peter Rosin [this message]
2017-01-27 15:52 ` Rob Herring
2017-01-30 8:02 ` Peter Rosin
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=d32f335f-56f2-38c1-e4d9-4629926dbe21@axentia.se \
--to=peda@axentia.se \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-doc@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pmeerw@pmeerw.net \
--cc=robh+dt@kernel.org \
--cc=wsa@the-dreams.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).