All of lore.kernel.org
 help / color / mirror / Atom feed
From: Crt Mori <cmo@melexis.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Peter Rosin <peda@lysator.liu.se>, Peter Rosin <peda@axentia.se>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Peter Korsgaard <peter.korsgaard@barco.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Jonathan Cameron <jic23@kernel.org>,
	Hartmut Knaack <knaack.h@gmx.de>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Peter Meerwald <pmeerw@pmeerw.net>,
	Antti Palosaari <crope@iki.fi>,
	Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
	Frank Rowand <frowand.list@gmail.com>,
	Grant Likely <grant.likely@linaro.org>,
	Adriana Reus <adriana.reus@intel.com>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	Nicholas Mc Guire <hofrat@osadl.org>,
	Olli Salonen <olli.salonen@iki.fi>,
	linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
	linux-media@vger.kernel.org
Subject: Re: [PATCH v2 0/8] i2c mux cleanup and locking update
Date: Wed, 6 Jan 2016 14:23:02 +0100	[thread overview]
Message-ID: <CAKv63uvvdjmQj3J73UJZFLJ=U0c+Z=dmknm3UH=3MvYU0oqNNg@mail.gmail.com> (raw)
In-Reply-To: <20160105184819.GA1743@katana>

Hi Wolfram and Peter,
I will give my opinion about the path chosen although it should be
taken lightly.

I can see that hardware guys missed the software guys again on the
development path, but since this happens more often than not, I would
say it seems OK to have support for this as long as it does not make
more complex (longer) standard i2c transfers. I would support to have
additional mutex before mux as that will make less chance that someone
forgets to lock mutex before mux and proposed solution seems valid.

Regards,
Crt

On 5 January 2016 at 19:48, Wolfram Sang <wsa@the-dreams.de> wrote:
> Peter,
>
>> PS. needs a bunch of testing, I do not have access to all the involved hw
>
> First of all, thanks for diving into this topic and the huge effort you
> apparently have put into it.
>
> It is obviously a quite intrusive series, so it needs careful review.
> TBH, I can't really tell when I have the bandwidth to do that, so I hope
> other people will step up. And yes, it needs serious testing.
>
> To all: Although I appreciate any review support, I'd think the first
> thing to be done should be a very high level review - is this series
> worth the huge update? Is the path chosen proper? Stuff like this. I'd
> appreciate Acks or Revs for that. Stuff like fixing checkpatch warnings
> and other minor stuff should come later.
>
> Thanks,
>
>    Wolfram
>

WARNING: multiple messages have this Message-ID (diff)
From: Crt Mori <cmo-fc6wVz46lShBDgjK7y7TUQ@public.gmane.org>
To: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
Cc: Peter Rosin <peda-SamgB31n2u5IcsJQ0EH25Q@public.gmane.org>,
	Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	Ian Campbell
	<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Peter Korsgaard
	<peter.korsgaard-ob4gmnvZ1/cAvxtiuMwx3w@public.gmane.org>,
	Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>,
	Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Hartmut Knaack <knaack.h-Mmb7MZpHnFY@public.gmane.org>,
	Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>,
	Peter Meerwald <pmeerw-jW+XmwGofnusTnJN9+BGXg@public.gmane.org>,
	Antti Palosaari <crope-X3B1VOXEql0@public.gmane.org>,
	Mauro Carvalho Chehab
	<mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>,
	Frank Rowand
	<frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Grant Likely
	<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Adriana Reus
	<adriana.reus-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Srinivas Pandruvada
	<srinivas.pandruvada-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	Krzysztof Kozlowski
	<k.kozlowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	Hans Verkuil
	<hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>,
	Nicholas Mc Guire
	<hofrat-Q945KHDl0DbYtjvyW6yDsg@public.gmane.org>Olli Salonen <ol>
Subject: Re: [PATCH v2 0/8] i2c mux cleanup and locking update
Date: Wed, 6 Jan 2016 14:23:02 +0100	[thread overview]
Message-ID: <CAKv63uvvdjmQj3J73UJZFLJ=U0c+Z=dmknm3UH=3MvYU0oqNNg@mail.gmail.com> (raw)
In-Reply-To: <20160105184819.GA1743@katana>

Hi Wolfram and Peter,
I will give my opinion about the path chosen although it should be
taken lightly.

I can see that hardware guys missed the software guys again on the
development path, but since this happens more often than not, I would
say it seems OK to have support for this as long as it does not make
more complex (longer) standard i2c transfers. I would support to have
additional mutex before mux as that will make less chance that someone
forgets to lock mutex before mux and proposed solution seems valid.

Regards,
Crt

On 5 January 2016 at 19:48, Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org> wrote:
> Peter,
>
>> PS. needs a bunch of testing, I do not have access to all the involved hw
>
> First of all, thanks for diving into this topic and the huge effort you
> apparently have put into it.
>
> It is obviously a quite intrusive series, so it needs careful review.
> TBH, I can't really tell when I have the bandwidth to do that, so I hope
> other people will step up. And yes, it needs serious testing.
>
> To all: Although I appreciate any review support, I'd think the first
> thing to be done should be a very high level review - is this series
> worth the huge update? Is the path chosen proper? Stuff like this. I'd
> appreciate Acks or Revs for that. Stuff like fixing checkpatch warnings
> and other minor stuff should come later.
>
> Thanks,
>
>    Wolfram
>

  parent reply	other threads:[~2016-01-06 13:23 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-05 15:57 [PATCH v2 0/8] i2c mux cleanup and locking update Peter Rosin
2016-01-05 15:57 ` Peter Rosin
2016-01-05 15:57 ` [PATCH v2 1/8] i2c-mux: add common core data for every mux instance Peter Rosin
2016-01-05 15:57   ` Peter Rosin
2016-01-05 16:42   ` Guenter Roeck
2016-01-05 16:42     ` Guenter Roeck
2016-01-05 18:55     ` Peter Rosin
2016-01-05 18:55       ` Peter Rosin
2016-03-24  9:50   ` Vladimir Zapolskiy
2016-03-24  9:50     ` Vladimir Zapolskiy
2016-03-24 11:05     ` Peter Rosin
2016-03-24 11:05       ` Peter Rosin
2016-03-24 14:24       ` Vladimir Zapolskiy
2016-03-24 14:24         ` Vladimir Zapolskiy
2016-03-24 18:59         ` Peter Rosin
2016-03-24 18:59           ` Peter Rosin
2016-04-11 20:59           ` Wolfram Sang
2016-04-11 20:59             ` Wolfram Sang
2016-01-05 15:57 ` [PATCH v2 2/8] i2c-mux: move select and deselect ops to i2c_mux_core Peter Rosin
2016-01-05 15:57   ` Peter Rosin
2016-01-05 15:57 ` [PATCH v2 3/8] i2c-mux: move the slave side adapter management " Peter Rosin
2016-01-05 15:57   ` Peter Rosin
2016-01-05 16:49   ` kbuild test robot
2016-01-05 16:49     ` kbuild test robot
2016-01-05 19:16     ` Peter Rosin
2016-01-05 19:16       ` Peter Rosin
2016-01-05 22:17   ` Peter Rosin
2016-01-05 22:17     ` Peter Rosin
2016-01-05 15:57 ` [PATCH v2 4/8] i2c-mux: remove the mux dev pointer from the mux per channel data Peter Rosin
2016-01-05 15:57   ` Peter Rosin
2016-01-05 15:57 ` [PATCH v2 5/8] i2c-mux: pinctrl: get rid of the driver private struct device pointer Peter Rosin
2016-01-05 15:57   ` Peter Rosin
2016-01-05 15:57 ` [PATCH v2 6/8] i2c: allow adapter drivers to override the adapter locking Peter Rosin
2016-01-05 15:57   ` Peter Rosin
2016-01-05 15:57 ` [PATCH v2 7/8] i2c: muxes always lock the parent adapter Peter Rosin
2016-01-05 15:57   ` Peter Rosin
2016-01-05 15:57 ` [PATCH v2 8/8] i2c-mux: relax locking of the top i2c adapter during i2c controlled muxing Peter Rosin
2016-01-05 15:57   ` Peter Rosin
2016-01-06 14:49   ` Rob Herring
2016-01-06 14:49     ` Rob Herring
2016-01-07  8:21     ` Peter Rosin
2016-01-07  8:21       ` Peter Rosin
2016-01-05 18:48 ` [PATCH v2 0/8] i2c mux cleanup and locking update Wolfram Sang
2016-01-05 18:48   ` Wolfram Sang
2016-01-05 19:01   ` Peter Rosin
2016-01-05 19:01     ` Peter Rosin
2016-01-06 13:23   ` Crt Mori [this message]
2016-01-06 13:23     ` Crt Mori
2016-01-06 17:17 ` Antti Palosaari
2016-01-06 17:17   ` Antti Palosaari
2016-01-07  8:14   ` Peter Rosin
2016-01-07  8:14     ` 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='CAKv63uvvdjmQj3J73UJZFLJ=U0c+Z=dmknm3UH=3MvYU0oqNNg@mail.gmail.com' \
    --to=cmo@melexis.com \
    --cc=adriana.reus@intel.com \
    --cc=crope@iki.fi \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=galak@codeaurora.org \
    --cc=grant.likely@linaro.org \
    --cc=hans.verkuil@cisco.com \
    --cc=hofrat@osadl.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jic23@kernel.org \
    --cc=k.kozlowski@samsung.com \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mark.rutland@arm.com \
    --cc=mchehab@osg.samsung.com \
    --cc=olli.salonen@iki.fi \
    --cc=pawel.moll@arm.com \
    --cc=peda@axentia.se \
    --cc=peda@lysator.liu.se \
    --cc=peter.korsgaard@barco.com \
    --cc=pmeerw@pmeerw.net \
    --cc=robh+dt@kernel.org \
    --cc=srinivas.pandruvada@linux.intel.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.