All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
To: Peter Rosin <peda@lysator.liu.se>
Cc: Wolfram Sang <wsa@the-dreams.de>, 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 1/8] i2c-mux: add common core data for every mux instance
Date: Thu, 24 Mar 2016 16:24:31 +0200	[thread overview]
Message-ID: <56F3F89F.8000805@mentor.com> (raw)
In-Reply-To: <56F3CA0E.60906@lysator.liu.se>

Hi Peter,

On 24.03.2016 13:05, Peter Rosin wrote:
> Hi Vladimir,
> 
> On 2016-03-24 10:50, Vladimir Zapolskiy wrote:
>> Hi Peter,
>>
>> On 05.01.2016 17:57, Peter Rosin wrote:
>>> From: Peter Rosin <peda@axentia.se>
>>>
>>> The initial core mux structure starts off small with only the parent
>>> adapter pointer, which all muxes have, and a priv pointer for mux
>>> driver private data.
>>>
>>> Add i2c_mux_alloc function to unify the creation of a mux.
>>>
>>> Where appropriate, pass around the mux core structure instead of the
>>> parent adapter or the driver private data.
>>>
>>> Remove the parent adapter pointer from the driver private data for all
>>> mux drivers.
>>>
>>> Signed-off-by: Peter Rosin <peda@axentia.se>
>>
>> is it still under review? If yes, please find one question from me below :)
> 
> Yes, the series is still under review/testing, with an update planned in a
> week or so.
> 
>> [snip]
>>
>>> @@ -196,21 +195,21 @@ static int i2c_arbitrator_probe(struct platform_device *pdev)
>>>  		dev_err(dev, "Cannot parse i2c-parent\n");
>>>  		return -EINVAL;
>>>  	}
>>> -	arb->parent = of_get_i2c_adapter_by_node(parent_np);
>>> +	muxc->parent = of_find_i2c_adapter_by_node(parent_np);
>>
>> why do you prefer here to use "unlocked" version of API?
>>
>> Foe example would it be safe/possible to unload an I2C bus device driver
>> module or unbind I2C device itself in runtime?
> 
> I think you ask why I change from of_get_i2c_... to of_find_i2c_..., and that
> change was not intentional. It was the result of a bad merge during an early
> rebase.
> 
> Does that cover it?
> 

Yep, thank you for clarification, please account this in v3.

I'll try to find some time to review the whole changeset carefully,
in fact I briefly reviewed it two months ago, but I didn't find
anything obviously wrong that time.

--
With best wishes,
Vladimir

WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Zapolskiy <vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
To: Peter Rosin <peda-SamgB31n2u5IcsJQ0EH25Q@public.gmane.org>
Cc: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@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
	<oll>
Subject: Re: [PATCH v2 1/8] i2c-mux: add common core data for every mux instance
Date: Thu, 24 Mar 2016 16:24:31 +0200	[thread overview]
Message-ID: <56F3F89F.8000805@mentor.com> (raw)
In-Reply-To: <56F3CA0E.60906-SamgB31n2u5IcsJQ0EH25Q@public.gmane.org>

Hi Peter,

On 24.03.2016 13:05, Peter Rosin wrote:
> Hi Vladimir,
> 
> On 2016-03-24 10:50, Vladimir Zapolskiy wrote:
>> Hi Peter,
>>
>> On 05.01.2016 17:57, Peter Rosin wrote:
>>> From: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
>>>
>>> The initial core mux structure starts off small with only the parent
>>> adapter pointer, which all muxes have, and a priv pointer for mux
>>> driver private data.
>>>
>>> Add i2c_mux_alloc function to unify the creation of a mux.
>>>
>>> Where appropriate, pass around the mux core structure instead of the
>>> parent adapter or the driver private data.
>>>
>>> Remove the parent adapter pointer from the driver private data for all
>>> mux drivers.
>>>
>>> Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
>>
>> is it still under review? If yes, please find one question from me below :)
> 
> Yes, the series is still under review/testing, with an update planned in a
> week or so.
> 
>> [snip]
>>
>>> @@ -196,21 +195,21 @@ static int i2c_arbitrator_probe(struct platform_device *pdev)
>>>  		dev_err(dev, "Cannot parse i2c-parent\n");
>>>  		return -EINVAL;
>>>  	}
>>> -	arb->parent = of_get_i2c_adapter_by_node(parent_np);
>>> +	muxc->parent = of_find_i2c_adapter_by_node(parent_np);
>>
>> why do you prefer here to use "unlocked" version of API?
>>
>> Foe example would it be safe/possible to unload an I2C bus device driver
>> module or unbind I2C device itself in runtime?
> 
> I think you ask why I change from of_get_i2c_... to of_find_i2c_..., and that
> change was not intentional. It was the result of a bad merge during an early
> rebase.
> 
> Does that cover it?
> 

Yep, thank you for clarification, please account this in v3.

I'll try to find some time to review the whole changeset carefully,
in fact I briefly reviewed it two months ago, but I didn't find
anything obviously wrong that time.

--
With best wishes,
Vladimir

  reply	other threads:[~2016-03-24 14:25 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 [this message]
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
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=56F3F89F.8000805@mentor.com \
    --to=vladimir_zapolskiy@mentor.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.