Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1364033 > unrolled thread
| Started by | Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> |
|---|---|
| First post | 2016-03-24 11:00 +0100 |
| Last post | 2016-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.
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
| From | Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> |
|---|---|
| Date | 2016-03-24 11:00 +0100 |
| Subject | Re: [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]
| From | Peter Rosin <peda@lysator.liu.se> |
|---|---|
| Date | 2016-03-24 12:10 +0100 |
| Subject | Re: [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]
| From | Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> |
|---|---|
| Date | 2016-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]
| From | Peter Rosin <peda@lysator.liu.se> |
|---|---|
| Date | 2016-03-24 20:10 +0100 |
| Subject | Re: [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