[PATCH v6 2/2] ARM hibernation / suspend-to-disk

[Lorenzo Pieralisi]

On Tue, Mar 04, 2014 at 09:55:31AM +0000, Sebastian Capella wrote:
> Quoting Sebastian Capella (2014-02-28 15:38:54)
> > Quoting Lorenzo Pieralisi (2014-02-28 14:49:33)
> > > On Fri, Feb 28, 2014 at 08:15:57PM +0000, Sebastian Capella wrote:
> > > > > 
> > > > > This does not guarantee your stack is 8-byte aligned, that's not AAPCS
> > > > > compliant and might buy you trouble.
> > > > > 
> > > > > Either you align the stack or you align the pointer you are passing.
> > > > > 
> > > > > Please have a look at kernel/process.c
> > > > 
> > > > I've added this for now, do you see any issues?
> > > > 
> > > > -static u8 resume_stack[PAGE_SIZE/2] __nosavedata;
> > > > +static u64 resume_stack[PAGE_SIZE/2/sizeof(u64)] __nosavedata;
> > > > -               resume_stack + sizeof(resume_stack));
> > > > +               resume_stack + ARRAY_SIZE(resume_stack));
> > > 
> > > I do not see why the stack depends on the PAGE_SIZE. I would be surprised
> > > if you need more than a few bytes (given that soft_restart switches stack
> > > again...), go through it with a debugger, it is easy to check the stack
> > > usage and allow for some extra buffer (but half a page is not needed).
> > 
> > I assuming this is becase the no-save region is one page anyway (we skip
> > restoring the no-save region physical page).  So maybe 1/2 is a way to
> > leave some room for whatever else may need to be here, but in any case
> > the 4k is used for nosave.  I think you're right that it can be much less.
> 
> Hi Lorenzo,
> 
> Are you ok with this just being half a page?  Or do you want me to try
> to reduce the stack size?  I am at Connect without my debugger, so in
> that case it would have to wait until next week.

I am ok, either you leave that as it is (that multiple division looks
horrible but it is just nitpicking on my side) or define it as an u8 array,
stick __attribute__((aligned(8)) to the definition (and explain why) and be
done with it.

You can add my:

Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>