On Fri, 8 Mar 2019 at 14:17, Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> wrote: > > On Fri, Mar 08, 2019 at 02:07:51PM +0100, Ulf Hansson wrote: > > On Fri, 8 Mar 2019 at 12:49, Lorenzo Pieralisi > > <lorenzo.pieralisi@xxxxxxx> wrote: > > > > > > On Fri, Mar 08, 2019 at 11:36:49AM +0100, Ulf Hansson wrote: > > > > > > [...] > > > > > > > Instead, my suggestion is according to what I propose in patch 4 and > > > > $subject patch, which means minor adjustments to be able to pass the > > > > struct cpuidle_driver * to the init functions. This, I need it for > > > > next steps, but already at this point it improves things as it avoids > > > > some of the OF parsing, and that's good, isn't it? > > > > > > I will take the patches Mark ACKed and send them for v5.2 as > > > early as it gets in v5.1-rc* cycle. > > > > Actually, may I suggest we funnel these through Rafael's tree, unless > > you are expecting other PSCI changes for v.5.2, which could cause > > conflicts? > > > > The reason is, other PM core changes, to genpd for example, needs to > > go via Rafael's tree. Those would then potentially block us for > > applying any other changes to your tree (arm-soc?) for PSCI (as there > > is dependency) until v5.3. > > > > How about if you provides your explicit acks for those PSCI changes > > your are happy with, then Rafael can pick them? > > It is fine we can do that, I would have not sent the patches Mark > has ACKed to arm-soc till -{rc2/rc3} anyway. Great! May I suggest you just reply to the cover-letter and provide the acks to the relevant patches, then I can then collect the received acks tags and re-post them to Rafael once rc1 is out. Kind regards Uffe > > Thanks, > Lorenzo > > > > For this one maybe you can post the changes on top and see what's > > > the best way forward ? > > > > > > I agree that duplicating idle state parsing code across back-ends > > > is silly - we just want to keep PSCI and kernel data structure > > > decoupled. > > > > Right. Let's continue this discussion later on and move forward here. > > Make sense. > > > > > > > > Post the code on top and we will find a way forward, OK ? > > > > Sure, let me do that. > > > > Thanks and kind regards > > Uffe