linux-next: manual merge of the arm-mpidr tree with the arm tree

linux-next: manual merge of the arm-mpidr tree with the arm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2161 bytes --]

Hi Lorenzo,

Today's linux-next merge of the arm-mpidr tree got a conflict in
arch/arm/kernel/suspend.c between commit aa1aadc3305c ("ARM: suspend: fix
CPU suspend code for !CONFIG_MMU configurations") from the arm tree and
commit 3fed6a1e3bf0 ("ARM: kernel: implement stack pointer save array
through MPIDR hashing") from the arm-mpidr tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

P.S. that arm tree commit above has no Signed-off-by from its
committer :-(
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/arm/kernel/suspend.c
index 38a5067,17d02f6..0000000
--- a/arch/arm/kernel/suspend.c
+++ b/arch/arm/kernel/suspend.c
@@@ -82,3 -49,48 +85,20 @@@ void __cpu_suspend_save(u32 *ptr, u32 p
  	outer_clean_range(virt_to_phys(save_ptr),
  			  virt_to_phys(save_ptr) + sizeof(*save_ptr));
  }
+ 
 -/*
 - * Hide the first two arguments to __cpu_suspend - these are an implementation
 - * detail which platform code shouldn't have to know about.
 - */
 -int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
 -{
 -	struct mm_struct *mm = current->active_mm;
 -	int ret;
 -
 -	if (!idmap_pgd)
 -		return -EINVAL;
 -
 -	/*
 -	 * Provide a temporary page table with an identity mapping for
 -	 * the MMU-enable code, required for resuming.  On successful
 -	 * resume (indicated by a zero return code), we need to switch
 -	 * back to the correct page tables.
 -	 */
 -	ret = __cpu_suspend(arg, fn);
 -	if (ret == 0) {
 -		cpu_switch_mm(mm->pgd, mm);
 -		local_flush_bp_all();
 -		local_flush_tlb_all();
 -	}
 -
 -	return ret;
 -}
 -
+ extern struct sleep_save_sp sleep_save_sp;
+ 
+ static int cpu_suspend_alloc_sp(void)
+ {
+ 	void *ctx_ptr;
+ 	/* ctx_ptr is an array of physical addresses */
+ 	ctx_ptr = kcalloc(mpidr_hash_size(), sizeof(u32), GFP_KERNEL);
+ 
+ 	if (WARN_ON(!ctx_ptr))
+ 		return -ENOMEM;
+ 	sleep_save_sp.save_ptr_stash = ctx_ptr;
+ 	sleep_save_sp.save_ptr_stash_phys = virt_to_phys(ctx_ptr);
+ 	sync_cache_w(&sleep_save_sp);
+ 	return 0;
+ }
+ early_initcall(cpu_suspend_alloc_sp);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the arm-mpidr tree with the arm tree

[Russell King]

On Wed, Jun 19, 2013 at 10:44:09AM +1000, Stephen Rothwell wrote:
> Hi Lorenzo,
> 
> Today's linux-next merge of the arm-mpidr tree got a conflict in
> arch/arm/kernel/suspend.c between commit aa1aadc3305c ("ARM: suspend: fix
> CPU suspend code for !CONFIG_MMU configurations") from the arm tree and
> commit 3fed6a1e3bf0 ("ARM: kernel: implement stack pointer save array
> through MPIDR hashing") from the arm-mpidr tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 
> P.S. that arm tree commit above has no Signed-off-by from its
> committer :-(

Oh bloody hell.  Now what do I do about that.  The branch is a declared
stable branch, and the commit came in from someone elses tree.  So it's
immutable...

Is there any script around which checks that kind of stuff?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: linux-next: manual merge of the arm-mpidr tree with the arm tree

[Jonathan Austin]

On 19/06/13 09:26, Russell King wrote:
> On Wed, Jun 19, 2013 at 10:44:09AM +1000, Stephen Rothwell wrote:
>> Hi Lorenzo,
>>
>> Today's linux-next merge of the arm-mpidr tree got a conflict in
>> arch/arm/kernel/suspend.c between commit aa1aadc3305c ("ARM: suspend: fix
>> CPU suspend code for !CONFIG_MMU configurations") from the arm tree and
>> commit 3fed6a1e3bf0 ("ARM: kernel: implement stack pointer save array
>> through MPIDR hashing") from the arm-mpidr tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
>>
>> P.S. that arm tree commit above has no Signed-off-by from its
>> committer :-(
>
> Oh bloody hell.  Now what do I do about that.  The branch is a declared
> stable branch, and the commit came in from someone elses tree.  So it's
> immutable...
>

Sorry guys, this was my first pull request and I didn't realise that,
though Will was the author, I needed to sign off on the patch too as *I*
had become the committer (I thought that Russell would become the
committer as this was going 'via' him, as it does when it goes through
Russell's patch system).

Apologies. I'll make sure this doesn't happen again...

Jonny




-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

Re: linux-next: manual merge of the arm-mpidr tree with the arm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

Hi Lorenzo,

On Wed, 26 Jun 2013 09:57:20 +0100 Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>
> No, arm-mpidr can be dropped from -next now that those patches, as you
> correctly mentioned, are queued through the arm tree.

Thanks, done.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the arm-mpidr tree with the arm tree

[Lorenzo Pieralisi]

Hi Stephen,

On Wed, Jun 26, 2013 at 02:04:11AM +0100, Stephen Rothwell wrote:
> Hi Lorenzo,
> 
> Today's linux-next merge of the arm-mpidr tree got a conflict in
> arch/arm/kernel/suspend.c between commit 7604537bbb57 ("ARM: kernel:
> implement stack pointer save array through MPIDR hashing") from the arm
> tree and commit 3fed6a1e3bf0 ("ARM: kernel: implement stack pointer save
> array through MPIDR hashing") from the arm-mpidr tree.
> 
> The former is just a rebase of the latter, so I used it.  It then turns
> out that the arm-mpidr contains nothing that is not already included in
> the arm tree, so is it needed any more i.e. is there further work coming?

No, arm-mpidr can be dropped from -next now that those patches, as you
correctly mentioned, are queued through the arm tree.

Thank you very much indeed,
Lorenzo

Re: linux-next: manual merge of the arm-mpidr tree with the arm tree

[Russell King]

On Wed, Jun 26, 2013 at 11:04:11AM +1000, Stephen Rothwell wrote:
> Hi Lorenzo,
> 
> Today's linux-next merge of the arm-mpidr tree got a conflict in
> arch/arm/kernel/suspend.c between commit 7604537bbb57 ("ARM: kernel:
> implement stack pointer save array through MPIDR hashing") from the arm
> tree and commit 3fed6a1e3bf0 ("ARM: kernel: implement stack pointer save
> array through MPIDR hashing") from the arm-mpidr tree.
> 
> The former is just a rebase of the latter, so I used it.  It then turns
> out that the arm-mpidr contains nothing that is not already included in
> the arm tree, so is it needed any more i.e. is there further work coming?

The reason for this is that the changes were submitted to me as patches
as two of the changes are for -rc, the other one is a development change,
but in Lorenzo's git tree, they're all part of a single branch, and so
can't be separately pushed upstream.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

linux-next: manual merge of the arm-mpidr tree with the arm tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

Hi Lorenzo,

Today's linux-next merge of the arm-mpidr tree got a conflict in
arch/arm/kernel/suspend.c between commit 7604537bbb57 ("ARM: kernel:
implement stack pointer save array through MPIDR hashing") from the arm
tree and commit 3fed6a1e3bf0 ("ARM: kernel: implement stack pointer save
array through MPIDR hashing") from the arm-mpidr tree.

The former is just a rebase of the latter, so I used it.  It then turns
out that the arm-mpidr contains nothing that is not already included in
the arm tree, so is it needed any more i.e. is there further work coming?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]