[1/2] i2c: mux: demux-pinctrl: use proper parent device for demux adapter

Due to a typo, the wrong parent device was assigned to the newly created
demuxing adapter device. It got connected to the demuxing platform
device but not to the selected parent I2C adapter device. Fix it to get
a proper parent-child relationship of the demuxed busses, needed also for
proper PM.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
 drivers/i2c/muxes/i2c-demux-pinctrl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On 2018-04-30 13:55, Wolfram Sang wrote:
> Due to a typo, the wrong parent device was assigned to the newly created
> demuxing adapter device. It got connected to the demuxing platform
> device but not to the selected parent I2C adapter device. Fix it to get
> a proper parent-child relationship of the demuxed busses, needed also for
> proper PM.
> 

Should this one have a Fixes: tag? Should it go to current or next? Is
a backport to stable good enough?

Cheers,
Peter

> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>  drivers/i2c/muxes/i2c-demux-pinctrl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/muxes/i2c-demux-pinctrl.c b/drivers/i2c/muxes/i2c-demux-pinctrl.c
> index 428de4c97fb2..035032e20327 100644
> --- a/drivers/i2c/muxes/i2c-demux-pinctrl.c
> +++ b/drivers/i2c/muxes/i2c-demux-pinctrl.c
> @@ -106,7 +106,7 @@ static int i2c_demux_activate_master(struct i2c_demux_pinctrl_priv *priv, u32 ne
>  	priv->cur_adap.owner = THIS_MODULE;
>  	priv->cur_adap.algo = &priv->algo;
>  	priv->cur_adap.algo_data = priv;
> -	priv->cur_adap.dev.parent = priv->dev;
> +	priv->cur_adap.dev.parent = &adap->dev;
>  	priv->cur_adap.class = adap->class;
>  	priv->cur_adap.retries = adap->retries;
>  	priv->cur_adap.timeout = adap->timeout;
>

On Sat, May 19, 2018 at 11:40:04PM +0200, Peter Rosin wrote:
> On 2018-04-30 13:55, Wolfram Sang wrote:
> > Due to a typo, the wrong parent device was assigned to the newly created
> > demuxing adapter device. It got connected to the demuxing platform
> > device but not to the selected parent I2C adapter device. Fix it to get
> > a proper parent-child relationship of the demuxed busses, needed also for
> > proper PM.
> > 
> 
> Should this one have a Fixes: tag? Should it go to current or next? Is
> a backport to stable good enough?

A Fixes tag is probably apropriate. I don't think it should go to
stable, though, because it will break a scheme a user might be using.
This can't be avoided for a kernel upgrade here, but IMO we shouldn't
enforce it for a stable update. Especially, given this is not a real
bug, but more something improper. For the same reason, I'd think -next
is good enough.

Thanks, will resend!

   Wolfram

On 2018-05-20 08:45, Wolfram Sang wrote:
> On Sat, May 19, 2018 at 11:40:04PM +0200, Peter Rosin wrote:
>> On 2018-04-30 13:55, Wolfram Sang wrote:
>>> Due to a typo, the wrong parent device was assigned to the newly created
>>> demuxing adapter device. It got connected to the demuxing platform
>>> device but not to the selected parent I2C adapter device. Fix it to get
>>> a proper parent-child relationship of the demuxed busses, needed also for
>>> proper PM.
>>>
>>
>> Should this one have a Fixes: tag? Should it go to current or next? Is
>> a backport to stable good enough?
> 
> A Fixes tag is probably apropriate. I don't think it should go to
> stable, though, because it will break a scheme a user might be using.
> This can't be avoided for a kernel upgrade here, but IMO we shouldn't
> enforce it for a stable update. Especially, given this is not a real
> bug, but more something improper. For the same reason, I'd think -next
> is good enough.
> 
> Thanks, will resend!

Hmm, in that case, I think a Fixes tag is best left out, because I suspect
the net effect is mostly a bunch of mails from the stable trees as the
automatic patch-picker finds this patch. So, I plan to go with this patch.

Ok?

Cheers,
Peter