All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ionut Nicu <ioan.nicu.ext-OYasijW0DpE@public.gmane.org>
To: Alexander Sverdlin <alexander.sverdlin-OYasijW0DpE@public.gmane.org>
Cc: Peter Korsgaard
	<peter.korsgaard-ob4gmnvZ1/cAvxtiuMwx3w@public.gmane.org>,
	Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 2/2] i2c-mux-gpio: eliminate i2c channel order assumptions
Date: Fri, 11 Oct 2013 10:46:00 +0200	[thread overview]
Message-ID: <5257BAC8.7060505@nsn.com> (raw)
In-Reply-To: <525682B5.20102-OYasijW0DpE@public.gmane.org>

Hi,

On 10.10.2013 12:34, Alexander Sverdlin wrote:
> Hi!
> 
> On 10/10/2013 10:39 AM, Ionut Nicu wrote:
>> The i2c-mux driver uses the chan_id parameter provided
>> in i2c_add_mux_adapter as a parameter to the select
>> and deselect callbacks while the i2c-mux-gpio driver
>> uses the chan_id as an index in the mux->data.values
>> array.
>>
>> A simple example of where this doesn't work is when we
>> have a device tree like this:
>>
>> i2cmux {
>> 	i2c@1 {
>> 		reg = <1>;
>> 		...
>> 	};
>>
>> 	i2c@0 {
>> 		reg = <0>;
>> 		...
>> 	};
>> };
>>
>> The mux->data.values array will be { 1, 0 }, but when
>> the i2-mux driver will try to select channel 0, the
>> i2c-mux-gpio driver will actually use values[0], hence 1
>> as the gpio selection value.
> 
> The patch itself is correct, but the description is not precise,
> I suppose... i2c-mux-gpio is consistent inside itself, it will
> receive for every child adapter the value it has configured.
> The problem happens inside i2c-mux.c, i2c_add_mux_adapter():
> 
>                	for_each_child_of_node(mux_dev->of_node, child) {
>                        	ret = of_property_read_u32(child, "reg", &reg);
>                        	if (ret)
>                                	continue;
>                        	if (chan_id == reg) {
>                                	priv->adap.dev.of_node = child;
> 
> Which means, i2c-mux-gpio MUST pass reg, not its logical index inside
> array. Otherwise node will not be correctly assigned and i2c-mux will
> have problems selecting right adapter for the multiplexed devices.
> 
>> Signed-off-by: Ionut Nicu <ioan.nicu.ext-OYasijW0DpE@public.gmane.org>
> 
> So, for the code itself
> 
> Acked-by: Alexander Sverdlin <alexander.sverdlin-OYasijW0DpE@public.gmane.org>
> 

You are right, the patch description is not so good. I will try to change
it so it's clearer for everyone what I'm trying to fix here and after that
I will re-submit the series.

>> ---
>>  drivers/i2c/muxes/i2c-mux-gpio.c |    4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/i2c/muxes/i2c-mux-gpio.c b/drivers/i2c/muxes/i2c-mux-gpio.c
>> index b5f17ef..3505d0e 100644
>> --- a/drivers/i2c/muxes/i2c-mux-gpio.c
>> +++ b/drivers/i2c/muxes/i2c-mux-gpio.c
>> @@ -43,7 +43,7 @@ static int i2c_mux_gpio_select(struct i2c_adapter *adap, void *data, u32 chan)
>>  {
>>  	struct gpiomux *mux = data;
>>  
>> -	i2c_mux_gpio_set(mux, mux->data.values[chan]);
>> +	i2c_mux_gpio_set(mux, chan);
>>  
>>  	return 0;
>>  }
>> @@ -233,7 +233,7 @@ static int i2c_mux_gpio_probe(struct platform_device *pdev)
>>  		unsigned int class = mux->data.classes ? mux->data.classes[i] : 0;
>>  
>>  		mux->adap[i] = i2c_add_mux_adapter(parent, &pdev->dev, mux, nr,
>> -						   i, class,
>> +						   mux->data.values[i], class,
>>  						   i2c_mux_gpio_select, deselect);
>>  		if (!mux->adap[i]) {
>>  			ret = -ENODEV;
>>
> 

WARNING: multiple messages have this Message-ID (diff)
From: Ionut Nicu <ioan.nicu.ext@nsn.com>
To: Alexander Sverdlin <alexander.sverdlin@nsn.com>
Cc: Peter Korsgaard <peter.korsgaard@barco.com>,
	Wolfram Sang <wsa@the-dreams.de>,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] i2c-mux-gpio: eliminate i2c channel order assumptions
Date: Fri, 11 Oct 2013 10:46:00 +0200	[thread overview]
Message-ID: <5257BAC8.7060505@nsn.com> (raw)
In-Reply-To: <525682B5.20102@nsn.com>

Hi,

On 10.10.2013 12:34, Alexander Sverdlin wrote:
> Hi!
> 
> On 10/10/2013 10:39 AM, Ionut Nicu wrote:
>> The i2c-mux driver uses the chan_id parameter provided
>> in i2c_add_mux_adapter as a parameter to the select
>> and deselect callbacks while the i2c-mux-gpio driver
>> uses the chan_id as an index in the mux->data.values
>> array.
>>
>> A simple example of where this doesn't work is when we
>> have a device tree like this:
>>
>> i2cmux {
>> 	i2c@1 {
>> 		reg = <1>;
>> 		...
>> 	};
>>
>> 	i2c@0 {
>> 		reg = <0>;
>> 		...
>> 	};
>> };
>>
>> The mux->data.values array will be { 1, 0 }, but when
>> the i2-mux driver will try to select channel 0, the
>> i2c-mux-gpio driver will actually use values[0], hence 1
>> as the gpio selection value.
> 
> The patch itself is correct, but the description is not precise,
> I suppose... i2c-mux-gpio is consistent inside itself, it will
> receive for every child adapter the value it has configured.
> The problem happens inside i2c-mux.c, i2c_add_mux_adapter():
> 
>                	for_each_child_of_node(mux_dev->of_node, child) {
>                        	ret = of_property_read_u32(child, "reg", &reg);
>                        	if (ret)
>                                	continue;
>                        	if (chan_id == reg) {
>                                	priv->adap.dev.of_node = child;
> 
> Which means, i2c-mux-gpio MUST pass reg, not its logical index inside
> array. Otherwise node will not be correctly assigned and i2c-mux will
> have problems selecting right adapter for the multiplexed devices.
> 
>> Signed-off-by: Ionut Nicu <ioan.nicu.ext@nsn.com>
> 
> So, for the code itself
> 
> Acked-by: Alexander Sverdlin <alexander.sverdlin@nsn.com>
> 

You are right, the patch description is not so good. I will try to change
it so it's clearer for everyone what I'm trying to fix here and after that
I will re-submit the series.

>> ---
>>  drivers/i2c/muxes/i2c-mux-gpio.c |    4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/i2c/muxes/i2c-mux-gpio.c b/drivers/i2c/muxes/i2c-mux-gpio.c
>> index b5f17ef..3505d0e 100644
>> --- a/drivers/i2c/muxes/i2c-mux-gpio.c
>> +++ b/drivers/i2c/muxes/i2c-mux-gpio.c
>> @@ -43,7 +43,7 @@ static int i2c_mux_gpio_select(struct i2c_adapter *adap, void *data, u32 chan)
>>  {
>>  	struct gpiomux *mux = data;
>>  
>> -	i2c_mux_gpio_set(mux, mux->data.values[chan]);
>> +	i2c_mux_gpio_set(mux, chan);
>>  
>>  	return 0;
>>  }
>> @@ -233,7 +233,7 @@ static int i2c_mux_gpio_probe(struct platform_device *pdev)
>>  		unsigned int class = mux->data.classes ? mux->data.classes[i] : 0;
>>  
>>  		mux->adap[i] = i2c_add_mux_adapter(parent, &pdev->dev, mux, nr,
>> -						   i, class,
>> +						   mux->data.values[i], class,
>>  						   i2c_mux_gpio_select, deselect);
>>  		if (!mux->adap[i]) {
>>  			ret = -ENODEV;
>>
> 


  parent reply	other threads:[~2013-10-11  8:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-10  8:39 [PATCH 2/2] i2c-mux-gpio: eliminate i2c channel order assumptions Ionut Nicu
     [not found] ` <525667CA.3030504-OYasijW0DpE@public.gmane.org>
2013-10-10 10:34   ` Alexander Sverdlin
2013-10-10 10:34     ` Alexander Sverdlin
     [not found]     ` <525682B5.20102-OYasijW0DpE@public.gmane.org>
2013-10-11  8:46       ` Ionut Nicu [this message]
2013-10-11  8:46         ` Ionut Nicu

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=5257BAC8.7060505@nsn.com \
    --to=ioan.nicu.ext-oyasijw0dpe@public.gmane.org \
    --cc=alexander.sverdlin-OYasijW0DpE@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=peter.korsgaard-ob4gmnvZ1/cAvxtiuMwx3w@public.gmane.org \
    --cc=wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org \
    /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.