[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE-0n518E_Yfy7-Au-pO40SQzZAn6NLr8u1pGyPMWWr0wRgpJA@mail.gmail.com>
Date: Sun, 23 May 2021 23:01:17 -0700
From: Stephen Boyd <swboyd@...omium.org>
To: Saravana Kannan <saravanak@...gle.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
freedreno <freedreno@...ts.freedesktop.org>,
Daniel Vetter <daniel.vetter@...ll.ch>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Rob Clark <robdclark@...il.com>,
Russell King <rmk+kernel@....linux.org.uk>
Subject: Re: [PATCH 3/7] component: Introduce struct aggregate_device
Quoting Saravana Kannan (2021-05-20 13:20:45)
> On Wed, May 19, 2021 at 5:25 PM Stephen Boyd <swboyd@...omium.org> wrote:
> >
> > - master->parent = parent;
> > - master->ops = ops;
> > - master->match = match;
> > + id = ida_alloc(&aggregate_ida, GFP_KERNEL);
> > + if (id < 0) {
> > + kfree(adev);
> > + return id;
> > + }
> > +
> > + adev->id = id;
> > + adev->parent = parent;
> > + adev->dev.parent = parent;
>
> Don't set adev->dev.parent. You are creating a functional 1-1
> dependency where none exists. The real dependencies are the 1-many
> dependencies between the aggregate and the components. Use device
> links to capture that and enforce proper suspend/resume and runtime PM
> ordering.
>
Ah ok. Yeah it seems like that was the thing causing me runtime PM
problems. I've removed the parent patch from this series now and I'll
look at working in the device links now.
Powered by blists - more mailing lists