Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1364033 > unrolled thread

Re: [PATCH v2 1/8] i2c-mux: add common core data for every mux instance

Started byVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
First post2016-03-24 11:00 +0100
Last post2016-03-24 20:10 +0100
Articles 4 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH v2 1/8] i2c-mux: add common core data for every mux  instance Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> - 2016-03-24 11:00 +0100
    Re: [PATCH v2 1/8] i2c-mux: add common core data for every mux instance Peter Rosin <peda@lysator.liu.se> - 2016-03-24 12:10 +0100
      Re: [PATCH v2 1/8] i2c-mux: add common core data for every mux  instance Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> - 2016-03-24 15:30 +0100
        Re: [PATCH v2 1/8] i2c-mux: add common core data for every mux instance Peter Rosin <peda@lysator.liu.se> - 2016-03-24 20:10 +0100

#1364033 — Re: [PATCH v2 1/8] i2c-mux: add common core data for every mux instance

FromVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Date2016-03-24 11:00 +0100
SubjectRe: [PATCH v2 1/8] i2c-mux: add common core data for every mux instance
Message-ID<rgadz-EQ-1@gated-at.bofh.it>
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 :)

[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?

>  	of_node_put(parent_np);
> -	if (!arb->parent) {
> +	if (!muxc->parent) {
>  		dev_err(dev, "Cannot find parent bus\n");
>  		return -EPROBE_DEFER;
>  	}
>  
>  	/* Actually add the mux adapter */
> -	arb->child = i2c_add_mux_adapter(arb->parent, dev, arb, 0, 0, 0,
> +	arb->child = i2c_add_mux_adapter(muxc, dev, arb, 0, 0, 0,
>  					 i2c_arbitrator_select,
>  					 i2c_arbitrator_deselect);
>  	if (!arb->child) {
>  		dev_err(dev, "Failed to add adapter\n");
>  		ret = -ENODEV;
> -		i2c_put_adapter(arb->parent);
> +		i2c_put_adapter(muxc->parent);
>  	}
>  
>  	return ret;

--
With best wishes,
Vladimir

[toc] | [next] | [standalone]


#1364084 — Re: [PATCH v2 1/8] i2c-mux: add common core data for every mux instance

FromPeter Rosin <peda@lysator.liu.se>
Date2016-03-24 12:10 +0100
SubjectRe: [PATCH v2 1/8] i2c-mux: add common core data for every mux instance
Message-ID<rgbjl-1Fk-41@gated-at.bofh.it>
In reply to#1364033
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?

Cheers,
Peter

[toc] | [prev] | [next] | [standalone]


#1364196

FromVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Date2016-03-24 15:30 +0100
Message-ID<rgeqT-3Ql-29@gated-at.bofh.it>
In reply to#1364084
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

[toc] | [prev] | [next] | [standalone]


#1364405 — Re: [PATCH v2 1/8] i2c-mux: add common core data for every mux instance

FromPeter Rosin <peda@lysator.liu.se>
Date2016-03-24 20:10 +0100
SubjectRe: [PATCH v2 1/8] i2c-mux: add common core data for every mux instance
Message-ID<rgiNR-7cM-27@gated-at.bofh.it>
In reply to#1364196
Hi Vladimir,

On 2016-03-24 15:24, Vladimir Zapolskiy wrote:
> On 24.03.2016 13:05, Peter Rosin wrote:
>> On 2016-03-24 10:50, Vladimir Zapolskiy wrote:
>>> On 05.01.2016 17:57, Peter Rosin wrote:
>>>> @@ -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.

Oh , v3 is old news, v4 was sent out some weeks ago, and there is a v5
on a github branch. This bad rebase was fixed in v4.

> 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.

Please put that on hold until I have rebased ontop of v4.6-rc1 and
changed a couple of other things. I'd hate for you to waste your
time on outdated patches.

Cheers,
Peter

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web