linux-next: manual merge of the m68knommu tree with the m68k tree

linux-next: manual merge of the m68knommu tree with the m68k tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the m68knommu tree got a conflict in:

  arch/m68k/Kconfig

between commits:

  34dc63a5fb9b ("m68k: Use the generic dma coherent remap allocator")
  69878ef47562 ("m68k: Implement arch_dma_prep_coherent()")

from the m68k tree and commit:

  bdd15a288492 ("binfmt_flat: replace flat_argvp_envp_on_stack with a Kconfig variable")
  aef0f78e7460 ("binfmt_flat: add a ARCH_HAS_BINFMT_FLAT option")

from the m68knommu tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/m68k/Kconfig
index 00f5c98a5e05,c0c43c624afa..000000000000
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@@ -3,13 -3,12 +3,15 @@@ config M68
  	bool
  	default y
  	select ARCH_32BIT_OFF_T
+ 	select ARCH_HAS_BINFMT_FLAT
 +	select ARCH_HAS_DMA_MMAP_PGPROT if MMU && !COLDFIRE
 +	select ARCH_HAS_DMA_PREP_COHERENT
  	select ARCH_HAS_SYNC_DMA_FOR_DEVICE if HAS_DMA
  	select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
  	select ARCH_NO_COHERENT_DMA_MMAP if !MMU
  	select ARCH_NO_PREEMPT if !COLDFIRE
+ 	select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
 +	select DMA_DIRECT_REMAP if HAS_DMA && MMU && !COLDFIRE
  	select HAVE_IDE
  	select HAVE_AOUT if MMU
  	select HAVE_DEBUG_BUGVERBOSE

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Stephen Rothwell]

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

Hi all,

On Tue, 2 Jul 2019 09:09:12 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the m68knommu tree got a conflict in:
> 
>   arch/m68k/Kconfig
> 
> between commits:
> 
>   34dc63a5fb9b ("m68k: Use the generic dma coherent remap allocator")
>   69878ef47562 ("m68k: Implement arch_dma_prep_coherent()")
> 
> from the m68k tree and commit:
> 
>   bdd15a288492 ("binfmt_flat: replace flat_argvp_envp_on_stack with a Kconfig variable")
>   aef0f78e7460 ("binfmt_flat: add a ARCH_HAS_BINFMT_FLAT option")
> 
> from the m68knommu tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/m68k/Kconfig
> index 00f5c98a5e05,c0c43c624afa..000000000000
> --- a/arch/m68k/Kconfig
> +++ b/arch/m68k/Kconfig
> @@@ -3,13 -3,12 +3,15 @@@ config M68
>   	bool
>   	default y
>   	select ARCH_32BIT_OFF_T
> + 	select ARCH_HAS_BINFMT_FLAT
>  +	select ARCH_HAS_DMA_MMAP_PGPROT if MMU && !COLDFIRE
>  +	select ARCH_HAS_DMA_PREP_COHERENT
>   	select ARCH_HAS_SYNC_DMA_FOR_DEVICE if HAS_DMA
>   	select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
>   	select ARCH_NO_COHERENT_DMA_MMAP if !MMU
>   	select ARCH_NO_PREEMPT if !COLDFIRE
> + 	select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
>  +	select DMA_DIRECT_REMAP if HAS_DMA && MMU && !COLDFIRE
>   	select HAVE_IDE
>   	select HAVE_AOUT if MMU
>   	select HAVE_DEBUG_BUGVERBOSE

I am still getting this conflict (the commit ids may have changed).
Just a reminder in case you think Linus may need to know.

This is now a conflict between the m68knommu tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Greg Ungerer]

Hi Michael,

On 10/5/22 13:37, Michael Schmitz wrote:
> Hi Stephen,
> 
> apologies on my part - I had thought that I had copied in Greg on my patch series. And I evidently missed that his ELF patch would have clashed with mine.

You definitely did, I still have your patches in my inbox too :-)


> Geert and Greg coordinate well as a rule, and both patches had been seen on the linux-m68k mailing list (just too far apart to jog my memory).

Yeah, this was really an accident of timing between Geert applying your series
to his for-next branch, and me applying the regset changes to my for-next
branch.

The two changes are quite distinct, but they overlap in location within
ptrace.c file. The fixup patch is pretty strait forward, and Stephen has that
right.

Regards
Greg



> Won't happen again this decade (I hope).
> 
> Cheers,
> 
>      Michael
> 
> 
> Am 10.05.2022 um 11:44 schrieb Stephen Rothwell:
>> Hi all,
>>
>> Today's linux-next merge of the m68knommu tree got a conflict in:
>>
>>   arch/m68k/kernel/ptrace.c
>>
>> between commit:
>>
>>   c862fe70b023 ("m68k: Wire up syscall_trace_enter/leave for m68k")
>>
>> from the m68k tree and commit:
>>
>>   0d91043d8bdf ("m68knommu: implement minimal regset support")
>>
>> from the m68knommu tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging.  You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
>>

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Michael Schmitz]

Hi Stephen,

apologies on my part - I had thought that I had copied in Greg on my 
patch series. And I evidently missed that his ELF patch would have 
clashed with mine.

Geert and Greg coordinate well as a rule, and both patches had been seen 
on the linux-m68k mailing list (just too far apart to jog my memory).

Won't happen again this decade (I hope).

Cheers,

	Michael


Am 10.05.2022 um 11:44 schrieb Stephen Rothwell:
> Hi all,
>
> Today's linux-next merge of the m68knommu tree got a conflict in:
>
>   arch/m68k/kernel/ptrace.c
>
> between commit:
>
>   c862fe70b023 ("m68k: Wire up syscall_trace_enter/leave for m68k")
>
> from the m68k tree and commit:
>
>   0d91043d8bdf ("m68knommu: implement minimal regset support")
>
> from the m68knommu tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>

linux-next: manual merge of the m68knommu tree with the m68k tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the m68knommu tree got a conflict in:

  arch/m68k/kernel/ptrace.c

between commit:

  c862fe70b023 ("m68k: Wire up syscall_trace_enter/leave for m68k")

from the m68k tree and commit:

  0d91043d8bdf ("m68knommu: implement minimal regset support")

from the m68knommu tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/m68k/kernel/ptrace.c
index daebccdd2c09,4349b9c4dd68..000000000000
--- a/arch/m68k/kernel/ptrace.c
+++ b/arch/m68k/kernel/ptrace.c
@@@ -284,3 -292,60 +286,59 @@@ asmlinkage void syscall_trace_leave(voi
  	if (test_thread_flag(TIF_SYSCALL_TRACE))
  		ptrace_report_syscall_exit(task_pt_regs(current), 0);
  }
 -#endif /* CONFIG_COLDFIRE */
+ 
+ #if defined(CONFIG_BINFMT_ELF_FDPIC) && defined(CONFIG_ELF_CORE)
+ /*
+  * Currently the only thing that needs to use regsets for m68k is the
+  * coredump support of the elf_fdpic loader. Implement the minimum
+  * definitions required for that.
+  */
+ static int m68k_regset_get(struct task_struct *target,
+ 			   const struct user_regset *regset,
+ 			   struct membuf to)
+ {
+ 	struct pt_regs *ptregs = task_pt_regs(target);
+ 	u32 uregs[ELF_NGREG];
+ 
+ 	ELF_CORE_COPY_REGS(uregs, ptregs);
+ 	return membuf_write(&to, uregs, sizeof(uregs));
+ }
+ 
+ enum m68k_regset {
+ 	REGSET_GPR,
+ #ifdef CONFIG_FPU
+ 	REGSET_FPU,
+ #endif
+ };
+ 
+ static const struct user_regset m68k_user_regsets[] = {
+ 	[REGSET_GPR] = {
+ 		.core_note_type = NT_PRSTATUS,
+ 		.n = ELF_NGREG,
+ 		.size = sizeof(u32),
+ 		.align = sizeof(u16),
+ 		.regset_get = m68k_regset_get,
+ 	},
+ #ifdef CONFIG_FPU
+ 	[REGSET_FPU] = {
+ 		.core_note_type = NT_PRFPREG,
+ 		.n = sizeof(struct user_m68kfp_struct) / sizeof(u32),
+ 		.size = sizeof(u32),
+ 		.align = sizeof(u32),
+ 	}
+ #endif /* CONFIG_FPU */
+ };
+ 
+ static const struct user_regset_view user_m68k_view = {
+ 	.name = "m68k",
+ 	.e_machine = EM_68K,
+ 	.ei_osabi = ELF_OSABI,
+ 	.regsets = m68k_user_regsets,
+ 	.n = ARRAY_SIZE(m68k_user_regsets)
+ };
+ 
+ const struct user_regset_view *task_user_regset_view(struct task_struct *task)
+ {
+ 	return &user_m68k_view;
+ }
+ #endif /* CONFIG_BINFMT_ELF_FDPIC && CONFIG_ELF_CORE */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Stephen Rothwell]

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

Hi all,

On Thu, 10 Sep 2020 09:34:37 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the m68knommu tree got a conflict in:
> 
>   arch/m68k/Kconfig
> 
> between commit:
> 
>   dc072012bc94 ("m68k: Sort selects in main Kconfig")
> 
> from the m68k tree and commit:
> 
>   ef03e4545eac ("m68knommu: switch to using asm-generic/uaccess.h")
> 
> from the m68knommu tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> diff --cc arch/m68k/Kconfig
> index 93bbb74ea876,aefffebc0afa..000000000000
> --- a/arch/m68k/Kconfig
> +++ b/arch/m68k/Kconfig
> @@@ -6,32 -6,33 +6,33 @@@ config M68
>   	select ARCH_HAS_BINFMT_FLAT
>   	select ARCH_HAS_DMA_PREP_COHERENT if HAS_DMA && MMU && !COLDFIRE
>   	select ARCH_HAS_SYNC_DMA_FOR_DEVICE if HAS_DMA
>  +	select ARCH_HAVE_NMI_SAFE_CMPXCHG if RMW_INSNS
>   	select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
>   	select ARCH_NO_PREEMPT if !COLDFIRE
>  +	select ARCH_WANT_IPC_PARSE_VERSION
>   	select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
>   	select DMA_DIRECT_REMAP if HAS_DMA && MMU && !COLDFIRE
>  -	select HAVE_IDE
>  -	select HAVE_AOUT if MMU
>  -	select HAVE_ASM_MODVERSIONS
>  -	select HAVE_DEBUG_BUGVERBOSE
>  -	select GENERIC_IRQ_SHOW
>   	select GENERIC_ATOMIC64
>  -	select NO_DMA if !MMU && !COLDFIRE
>  -	select HAVE_UID16
>  -	select VIRT_TO_BUS
>  -	select ARCH_HAVE_NMI_SAFE_CMPXCHG if RMW_INSNS
>   	select GENERIC_CPU_DEVICES
>   	select GENERIC_IOMAP
>  +	select GENERIC_IRQ_SHOW
>   	select GENERIC_STRNCPY_FROM_USER if MMU
>   	select GENERIC_STRNLEN_USER if MMU
>  -	select UACCESS_MEMCPY if !MMU
>  -	select ARCH_WANT_IPC_PARSE_VERSION
>  +	select HAVE_AOUT if MMU
>  +	select HAVE_ASM_MODVERSIONS
>  +	select HAVE_DEBUG_BUGVERBOSE
>   	select HAVE_FUTEX_CMPXCHG if MMU && FUTEX
>  +	select HAVE_IDE
>   	select HAVE_MOD_ARCH_SPECIFIC
>  +	select HAVE_UID16
>  +	select MMU_GATHER_NO_RANGE if MMU
>   	select MODULES_USE_ELF_REL
>   	select MODULES_USE_ELF_RELA
>  -	select OLD_SIGSUSPEND3
>  +	select NO_DMA if !MMU && !COLDFIRE
>   	select OLD_SIGACTION
>  -	select MMU_GATHER_NO_RANGE if MMU
>  +	select OLD_SIGSUSPEND3
> ++	select UACCESS_MEMCPY if !MMU
>  +	select VIRT_TO_BUS
>   
>   config CPU_BIG_ENDIAN
>   	def_bool y

This is now a conflict between the m68knommu tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the m68knommu tree with the m68k tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the m68knommu tree got a conflict in:

  arch/m68k/Kconfig

between commit:

  dc072012bc94 ("m68k: Sort selects in main Kconfig")

from the m68k tree and commit:

  ef03e4545eac ("m68knommu: switch to using asm-generic/uaccess.h")

from the m68knommu tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/m68k/Kconfig
index 93bbb74ea876,aefffebc0afa..000000000000
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@@ -6,32 -6,33 +6,33 @@@ config M68
  	select ARCH_HAS_BINFMT_FLAT
  	select ARCH_HAS_DMA_PREP_COHERENT if HAS_DMA && MMU && !COLDFIRE
  	select ARCH_HAS_SYNC_DMA_FOR_DEVICE if HAS_DMA
 +	select ARCH_HAVE_NMI_SAFE_CMPXCHG if RMW_INSNS
  	select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
  	select ARCH_NO_PREEMPT if !COLDFIRE
 +	select ARCH_WANT_IPC_PARSE_VERSION
  	select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
  	select DMA_DIRECT_REMAP if HAS_DMA && MMU && !COLDFIRE
 -	select HAVE_IDE
 -	select HAVE_AOUT if MMU
 -	select HAVE_ASM_MODVERSIONS
 -	select HAVE_DEBUG_BUGVERBOSE
 -	select GENERIC_IRQ_SHOW
  	select GENERIC_ATOMIC64
 -	select NO_DMA if !MMU && !COLDFIRE
 -	select HAVE_UID16
 -	select VIRT_TO_BUS
 -	select ARCH_HAVE_NMI_SAFE_CMPXCHG if RMW_INSNS
  	select GENERIC_CPU_DEVICES
  	select GENERIC_IOMAP
 +	select GENERIC_IRQ_SHOW
  	select GENERIC_STRNCPY_FROM_USER if MMU
  	select GENERIC_STRNLEN_USER if MMU
 -	select UACCESS_MEMCPY if !MMU
 -	select ARCH_WANT_IPC_PARSE_VERSION
 +	select HAVE_AOUT if MMU
 +	select HAVE_ASM_MODVERSIONS
 +	select HAVE_DEBUG_BUGVERBOSE
  	select HAVE_FUTEX_CMPXCHG if MMU && FUTEX
 +	select HAVE_IDE
  	select HAVE_MOD_ARCH_SPECIFIC
 +	select HAVE_UID16
 +	select MMU_GATHER_NO_RANGE if MMU
  	select MODULES_USE_ELF_REL
  	select MODULES_USE_ELF_RELA
 -	select OLD_SIGSUSPEND3
 +	select NO_DMA if !MMU && !COLDFIRE
  	select OLD_SIGACTION
 -	select MMU_GATHER_NO_RANGE if MMU
 +	select OLD_SIGSUSPEND3
++	select UACCESS_MEMCPY if !MMU
 +	select VIRT_TO_BUS
  
  config CPU_BIG_ENDIAN
  	def_bool y

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Greg Ungerer]

Hi Stephen,

On 14/11/11 10:03, Stephen Rothwell wrote:
> Today's linux-next merge of the m68knommu tree got a conflict in
> arch/m68k/Kconfig.debug between commit 049755db2c3f ("m68k/mvme16x: Add
> support for EARLY_PRINTK") from the m68k tree and commit d0106cf0aa29
> ("m68k: support configure time command line for MMU m68k") from the
> m68knommu tree.
>
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.

Thanks for the heads up. Geert's irq changes have been pushed in now,
so I will rebase my patches and fix up the few bits of breakage you
have seen.

Thanks
Greg


-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com

linux-next: manual merge of the m68knommu tree with the m68k tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the m68knommu tree got a conflict in
arch/m68k/Kconfig.debug between commit 049755db2c3f ("m68k/mvme16x: Add
support for EARLY_PRINTK") from the m68k tree and commit d0106cf0aa29
("m68k: support configure time command line for MMU m68k") from the
m68knommu tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/m68k/Kconfig.debug
index a0c8863,af4fd5f..0000000
--- a/arch/m68k/Kconfig.debug
+++ b/arch/m68k/Kconfig.debug
@@@ -2,17 -2,14 +2,25 @@@ menu "Kernel hacking
  
  source "lib/Kconfig.debug"
  
 +config EARLY_PRINTK
 +	bool "Early printk" if EMBEDDED
 +	depends on MVME16x || MAC
 +	default y
 +	help
 +          Write kernel log output directly to a serial port.
 +
 +          This is useful for kernel debugging when your machine crashes very
 +          early before the console code is initialized.
 +          You should normally say N here, unless you want to debug such a crash.
 +
+ config BOOTPARAM
+ 	bool 'Compiled-in Kernel Boot Parameter'
+ 
+ config BOOTPARAM_STRING
+ 	string 'Kernel Boot Parameter'
+ 	default 'console=ttyS0,19200'
+ 	depends on BOOTPARAM
+ 
  if !MMU
  
  config FULLDEBUG

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

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Geert Uytterhoeven]

Hi Greg,

On Wed, Nov 9, 2011 at 08:37, Greg Ungerer <gerg@snapgear.com> wrote:
> On 11/09/2011 05:13 PM, Geert Uytterhoeven wrote:
>> On Wed, Nov 9, 2011 at 08:08, Greg Ungerer<gerg@snapgear.com>  wrote:
>>>
>>> On 11/09/2011 10:15 AM, Stephen Rothwell wrote:
>>>>
>>>> Today's linux-next merge of the m68knommu tree got a conflict in
>>>> arch/m68k/Kconfig between commit d890d7399525 ("m68k/irq: Remove
>>>> obsolete
>>>> m68k irq framework") from the m68k tree and commit 4e8a9e70dfe8 ("m68k:
>>>> selection of GENERIC_ATOMIC64 is not MMU specific") from the m68knommu
>>>> tree.
>>>>
>>>> Just context changes. áI fixed it up (see below) and can carry the fix
>>>> as
>>>> necessary.
>>>
>>> Thanks. Both this and the previous m68k merge conflict patch look good.
>>>
>>> Geert: would you prefer I hold off on these 2 patches until after
>>> you merge your IRQ changes?
>>
>> I'll ask Linus to pull them today or tomorrow. After that (and he has
>> pulled), you can
>> rebase your tree. Is that OK for you?
>
> Yep, that is good. I wasn't sure if you where looking to push them
> in rc1 or in the next merge window.

rc2. I didn't want to rebase them to a random point between 3.1 and rc1.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Greg Ungerer]

Hi Geert,

On 11/09/2011 05:13 PM, Geert Uytterhoeven wrote:
> Hi Greg,
>
> On Wed, Nov 9, 2011 at 08:08, Greg Ungerer<gerg@snapgear.com>  wrote:
>> On 11/09/2011 10:15 AM, Stephen Rothwell wrote:
>>> Today's linux-next merge of the m68knommu tree got a conflict in
>>> arch/m68k/Kconfig between commit d890d7399525 ("m68k/irq: Remove obsolete
>>> m68k irq framework") from the m68k tree and commit 4e8a9e70dfe8 ("m68k:
>>> selection of GENERIC_ATOMIC64 is not MMU specific") from the m68knommu
>>> tree.
>>>
>>> Just context changes. áI fixed it up (see below) and can carry the fix as
>>> necessary.
>>
>> Thanks. Both this and the previous m68k merge conflict patch look good.
>>
>> Geert: would you prefer I hold off on these 2 patches until after
>> you merge your IRQ changes?
>
> I'll ask Linus to pull them today or tomorrow. After that (and he has
> pulled), you can
> rebase your tree. Is that OK for you?

Yep, that is good. I wasn't sure if you where looking to push them
in rc1 or in the next merge window.

Thanks
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close,                            FAX:         +61 7 3891 3630
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Geert Uytterhoeven]

Hi Greg,

On Wed, Nov 9, 2011 at 08:08, Greg Ungerer <gerg@snapgear.com> wrote:
> On 11/09/2011 10:15 AM, Stephen Rothwell wrote:
>> Today's linux-next merge of the m68knommu tree got a conflict in
>> arch/m68k/Kconfig between commit d890d7399525 ("m68k/irq: Remove obsolete
>> m68k irq framework") from the m68k tree and commit 4e8a9e70dfe8 ("m68k:
>> selection of GENERIC_ATOMIC64 is not MMU specific") from the m68knommu
>> tree.
>>
>> Just context changes.  I fixed it up (see below) and can carry the fix as
>> necessary.
>
> Thanks. Both this and the previous m68k merge conflict patch look good.
>
> Geert: would you prefer I hold off on these 2 patches until after
> you merge your IRQ changes?

I'll ask Linus to pull them today or tomorrow. After that (and he has
pulled), you can
rebase your tree. Is that OK for you?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Greg Ungerer]

Hi Stephen,

On 11/09/2011 10:15 AM, Stephen Rothwell wrote:
> Today's linux-next merge of the m68knommu tree got a conflict in
> arch/m68k/Kconfig between commit d890d7399525 ("m68k/irq: Remove obsolete
> m68k irq framework") from the m68k tree and commit 4e8a9e70dfe8 ("m68k:
> selection of GENERIC_ATOMIC64 is not MMU specific") from the m68knommu
> tree.
>
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.

Thanks. Both this and the previous m68k merge conflict patch look good.

Geert: would you prefer I hold off on these 2 patches until after
you merge your IRQ changes?

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close,                            FAX:         +61 7 3891 3630
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com

linux-next: manual merge of the m68knommu tree with the m68k tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the m68knommu tree got a conflict in
arch/m68k/Kconfig between commit d890d7399525 ("m68k/irq: Remove obsolete
m68k irq framework") from the m68k tree and commit 4e8a9e70dfe8 ("m68k:
selection of GENERIC_ATOMIC64 is not MMU specific") from the m68knommu
tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/m68k/Kconfig
index 361d540,26ed01b..0000000
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@@ -3,9 -3,8 +3,8 @@@ config M68
  	default y
  	select HAVE_IDE
  	select HAVE_AOUT if MMU
- 	select GENERIC_ATOMIC64 if MMU
 -	select HAVE_GENERIC_HARDIRQS if !MMU
 -	select GENERIC_IRQ_SHOW if !MMU
 +	select HAVE_GENERIC_HARDIRQS
 +	select GENERIC_IRQ_SHOW
  	select ARCH_HAVE_NMI_SAFE_CMPXCHG if RMW_INSNS
  
  config RWSEM_GENERIC_SPINLOCK

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

linux-next: manual merge of the m68knommu tree with the m68k tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the m68knommu tree got a conflict in
arch/m68k/kernel/Makefile between commits 4936f63cb790 ("m68k/irq: Add
genirq support") and d890d7399525 ("m68k/irq: Remove obsolete m68k irq
framework") from the m68k tree and commit 7bf6f100a307 ("m68k: merge the
init_task code for mmu and non-mmu targets") from the m68knommu tree.

I fixed it up (see below) and can carry the fixes as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/m68k/kernel/Makefile
index c569619,01ae30e..0000000
--- a/arch/m68k/kernel/Makefile
+++ b/arch/m68k/kernel/Makefile
@@@ -6,15 -6,16 +6,11 @@@ extra-$(CONFIG_MMU)	:= head.
  extra-$(CONFIG_SUN3)	:= sun3-head.o
  extra-y			+= vmlinux.lds
  
- obj-y	:= entry.o irq.o m68k_ksyms.o module.o process.o ptrace.o setup.o \
- 	   signal.o sys_m68k.o syscalltable.o time.o traps.o
 -obj-y	:= entry.o init_task.o m68k_ksyms.o module.o process.o ptrace.o
++obj-y	:= entry.o irq.o init_task.o m68k_ksyms.o module.o process.o ptrace.o
+ obj-y	+= setup.o signal.o sys_m68k.o syscalltable.o time.o traps.o
  
 -obj-$(CONFIG_MMU)	+= ints.o devres.o vectors.o
 -devres-$(CONFIG_MMU)	= ../../../kernel/irq/devres.o
 +obj-$(CONFIG_MMU)	+= ints.o vectors.o
  
  ifndef CONFIG_MMU_SUN3
  obj-y			+= dma.o
  endif
--ifndef CONFIG_MMU
- obj-y			+= init_task.o
- endif
- 
 -obj-y			+= irq.o
 -endif
 -

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

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Greg Ungerer]

On 22/06/11 18:29, Geert Uytterhoeven wrote:
> Hi Greg, Stephen,
>
> On Wed, Jun 22, 2011 at 08:34, Greg Ungerer<gerg@snapgear.com>  wrote:
>> On 22/06/11 11:12, Stephen Rothwell wrote:
>>> Today's linux-next merge of the m68knommu tree got a conflict in
>>> arch/m68k/include/asm/bitops_mm.h between commit 17c74432b88e
>>> ("m68k/bitops: Make bitmap data pointer of atomic ops volatile") from the
>>> m68k tree and commit 2cb0d89e66b1 ("m68k: merge mmu and non-mmu
>>> bitops.h") from the m68knommu tree.
>>>
>>> The latter effectively deletes in the file and in doing the merge,
>>> removes the funtions that were modified by the former commit. áSo I just
>>> removed the file.
>>
>> That would be right. The changes that Geert's patch makes are in
>> my merge patch.
>
> Sorry, I forgot that Greg was merging them, which also fixes the issue we
> had on m68k.
>
> [mental note to self: check for merge conflicts with m68knommu before updating
>   for-next]
>
>> Geert: do you want me to hold of on merging the bitops.h files?
>
> No, it looks fine to me. Feel free to add my Acked-by.

Thanks Geert. Will do.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Geert Uytterhoeven]

Hi Greg, Stephen,

On Wed, Jun 22, 2011 at 08:34, Greg Ungerer <gerg@snapgear.com> wrote:
> On 22/06/11 11:12, Stephen Rothwell wrote:
>> Today's linux-next merge of the m68knommu tree got a conflict in
>> arch/m68k/include/asm/bitops_mm.h between commit 17c74432b88e
>> ("m68k/bitops: Make bitmap data pointer of atomic ops volatile") from the
>> m68k tree and commit 2cb0d89e66b1 ("m68k: merge mmu and non-mmu
>> bitops.h") from the m68knommu tree.
>>
>> The latter effectively deletes in the file and in doing the merge,
>> removes the funtions that were modified by the former commit.  So I just
>> removed the file.
>
> That would be right. The changes that Geert's patch makes are in
> my merge patch.

Sorry, I forgot that Greg was merging them, which also fixes the issue we
had on m68k.

[mental note to self: check for merge conflicts with m68knommu before updating
 for-next]

> Geert: do you want me to hold of on merging the bitops.h files?

No, it looks fine to me. Feel free to add my Acked-by.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Greg Ungerer]

Hi Stephen,

On 22/06/11 11:12, Stephen Rothwell wrote:
> Today's linux-next merge of the m68knommu tree got a conflict in
> arch/m68k/include/asm/bitops_mm.h between commit 17c74432b88e
> ("m68k/bitops: Make bitmap data pointer of atomic ops volatile") from the
> m68k tree and commit 2cb0d89e66b1 ("m68k: merge mmu and non-mmu
> bitops.h") from the m68knommu tree.
>
> The latter effectively deletes in the file and in doing the merge,
> removes the funtions that were modified by the former commit.  So I just
> removed the file.

That would be right. The changes that Geert's patch makes are in
my merge patch.

Geert: do you want me to hold of on merging the bitops.h files?

Regards
Greg


-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com

linux-next: manual merge of the m68knommu tree with the m68k tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the m68knommu tree got a conflict in
arch/m68k/include/asm/bitops_mm.h between commit 17c74432b88e
("m68k/bitops: Make bitmap data pointer of atomic ops volatile") from the
m68k tree and commit 2cb0d89e66b1 ("m68k: merge mmu and non-mmu
bitops.h") from the m68knommu tree.

The latter effectively deletes in the file and in doing the merge,
removes the funtions that were modified by the former commit.  So I just
removed the file.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Geert Uytterhoeven]

On Tue, Sep 14, 2010 at 03:21, Greg Ungerer <gerg@snapgear.com> wrote:
> Stephen Rothwell wrote:
>>
>> Today's linux-next merge of the m68knommu tree got a conflict in
>> arch/m68k/sun3/sun3ints.c between commit
>> 72fe185cd9acbfc6e8a7afa884ae1152be706e52 ("m68k/m68knommu: Remove dead
>> SMP config option") from the m68k tree and commit
>> 5313b581e4efc214c6132d32f580db6668e5c5a8 ("arch/m68k{,nommu}: Removing
>> dead SMP config option") from the m68knommu tree.
>>
>> These appear to be the same patch with some formatting differences.  I
>> used the version from the m68k tree.
>
> Looks like Geert added the same patch to the m68k git tree.
> I'll drop it from the m68knommu git tree.

Sorry, I should have checked explicitly which patches were already in
the m68knommu git tree.
I did leave out one patch I knew (from email) Greg was going to take.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Greg Ungerer]

Hi Stephen,

Stephen Rothwell wrote:
> Today's linux-next merge of the m68knommu tree got a conflict in
> arch/m68k/sun3/sun3ints.c between commit
> 72fe185cd9acbfc6e8a7afa884ae1152be706e52 ("m68k/m68knommu: Remove dead
> SMP config option") from the m68k tree and commit
> 5313b581e4efc214c6132d32f580db6668e5c5a8 ("arch/m68k{,nommu}: Removing
> dead SMP config option") from the m68knommu tree.
> 
> These appear to be the same patch with some formatting differences.  I
> used the version from the m68k tree.

Looks like Geert added the same patch to the m68k git tree.
I'll drop it from the m68knommu git tree.

Thanks
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com

linux-next: manual merge of the m68knommu tree with the m68k tree

[Stephen Rothwell]

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

Hi Greg,

Today's linux-next merge of the m68knommu tree got a conflict in
arch/m68k/sun3/sun3ints.c between commit
72fe185cd9acbfc6e8a7afa884ae1152be706e52 ("m68k/m68knommu: Remove dead
SMP config option") from the m68k tree and commit
5313b581e4efc214c6132d32f580db6668e5c5a8 ("arch/m68k{,nommu}: Removing
dead SMP config option") from the m68knommu tree.

These appear to be the same patch with some formatting differences.  I
used the version from the m68k tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Geert Uytterhoeven]

On Fri, Nov 27, 2009 at 12:23, Greg Ungerer <gerg@snapgear.com> wrote:
> On 11/27/2009 06:43 PM, Geert Uytterhoeven wrote:
>> On Fri, Nov 27, 2009 at 05:43, Greg Ungerer<gerg@snapgear.com>  wrote:
>>> Geert Uytterhoeven wrote:
>>>> On Thu, Nov 26, 2009 at 01:58, Stephen Rothwell<sfr@canb.auug.org.au>
>>>> wrote:
>>>>>
>>>>> Today's linux-next merge of the m68knommu tree got a conflict in
>>>>> arch/m68k/include/asm/ptrace.h between commit
>>>>> 63c361b65f6540043c4baabf1a044a45c7465858 ("m68k: use generic code for
>>>>> ptrace requests") from the m68k tree and commit
>>>>> 03a03164e8084b810e9f92906a51232d63bac72c ("m68knommu: define
>>>>> arch_has_single_step() and friends") from the m68knommu tree.
>>>>>
>>>>> These mostly add the same stuff but not quite :-(
>>>>
>>>> Ah sorry, my bad. I'm not yet used to the uClinux guys touching "my"
>>>> includes ;-)
>>>> So we need better coordination between us.
>>>>
>>>> IIRC, Greg's changes were inspired by Andreas' patch.
>>>
>>> Yes, largely they are.
>>>
>>>
>>>>> I have done a fixup (see below) and can carry it as necessary.  Please
>>>>> check the result.
>>>>
>>>> At first sight, it looks OK. Thanks for fixing it up!
>>>
>>> Yep, looks ok from what I can see.
>>>
>>> Geert, how do you want to handle for the real linus merge?
>>> Do you want me to drop the changes to ptrace.h from that patch?
>>
>> I can apply your patch (modified to apply on top of Andreas') to the
>> m68k for-linus branch.
>> Does that sound OK for you?
>
> Yep, thats fine by me.

Done.

I also added the #ifdef CONFIG_MMU to Andreas' commit, so it will stay
bisectable on m68knommu.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Greg Ungerer]

Hi Geert,

On 11/27/2009 06:43 PM, Geert Uytterhoeven wrote:
> On Fri, Nov 27, 2009 at 05:43, Greg Ungerer<gerg@snapgear.com>  wrote:
>> Geert Uytterhoeven wrote:
>>>
>>> On Thu, Nov 26, 2009 at 01:58, Stephen Rothwell<sfr@canb.auug.org.au>
>>> wrote:
>>>>
>>>> Today's linux-next merge of the m68knommu tree got a conflict in
>>>> arch/m68k/include/asm/ptrace.h between commit
>>>> 63c361b65f6540043c4baabf1a044a45c7465858 ("m68k: use generic code for
>>>> ptrace requests") from the m68k tree and commit
>>>> 03a03164e8084b810e9f92906a51232d63bac72c ("m68knommu: define
>>>> arch_has_single_step() and friends") from the m68knommu tree.
>>>>
>>>> These mostly add the same stuff but not quite :-(
>>>
>>> Ah sorry, my bad. I'm not yet used to the uClinux guys touching "my"
>>> includes ;-)
>>> So we need better coordination between us.
>>>
>>> IIRC, Greg's changes were inspired by Andreas' patch.
>>
>> Yes, largely they are.
>>
>>
>>>> I have done a fixup (see below) and can carry it as necessary.  Please
>>>> check the result.
>>>
>>> At first sight, it looks OK. Thanks for fixing it up!
>>
>> Yep, looks ok from what I can see.
>>
>> Geert, how do you want to handle for the real linus merge?
>> Do you want me to drop the changes to ptrace.h from that patch?
>
> I can apply your patch (modified to apply on top of Andreas') to the
> m68k for-linus branch.
> Does that sound OK for you?

Yep, thats fine by me.

Regards
Greg



>>>> --
>>>> Cheers,
>>>> Stephen Rothwell                    sfr@canb.auug.org.au
>>>>
>>>> diff --cc arch/m68k/include/asm/ptrace.h
>>>> index eef9309,beb2091..0000000
>>>> --- a/arch/m68k/include/asm/ptrace.h
>>>> +++ b/arch/m68k/include/asm/ptrace.h
>>>> @@@ -86,14 -84,15 +86,18 @@@ struct switch_stack
>>>>   extern void show_regs(struct pt_regs *);
>>>>
>>>>   /*
>>>>   - * These are defined as per linux/ptrace.h.
>>>>   + * These are defined as per linux/ptrace.h, which see.
>>>>   */
>>>> + struct task_struct;
>>>> +
>>>>   -#ifndef CONFIG_MMU
>>>>   -#define       arch_has_single_step()  (1)
>>>>   +#define arch_has_single_step()        (1)
>>>>   extern void user_enable_single_step(struct task_struct *);
>>>>   extern void user_disable_single_step(struct task_struct *);
>>>>   +
>>>> ++#ifdef CONFIG_MMU
>>>>   +#define arch_has_block_step() (1)
>>>>   +extern void user_enable_block_step(struct task_struct *);
>>>> + #endif
>>>>
>>>>   #endif /* __KERNEL__ */
>>>>   #endif /* __ASSEMBLY__ */
>
> Gr{oetje,eeting}s,
>
> 						Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> 							    -- Linus Torvalds
>

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close,                            FAX:         +61 7 3891 3630
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Geert Uytterhoeven]

On Fri, Nov 27, 2009 at 05:43, Greg Ungerer <gerg@snapgear.com> wrote:
> Geert Uytterhoeven wrote:
>>
>> On Thu, Nov 26, 2009 at 01:58, Stephen Rothwell <sfr@canb.auug.org.au>
>> wrote:
>>>
>>> Today's linux-next merge of the m68knommu tree got a conflict in
>>> arch/m68k/include/asm/ptrace.h between commit
>>> 63c361b65f6540043c4baabf1a044a45c7465858 ("m68k: use generic code for
>>> ptrace requests") from the m68k tree and commit
>>> 03a03164e8084b810e9f92906a51232d63bac72c ("m68knommu: define
>>> arch_has_single_step() and friends") from the m68knommu tree.
>>>
>>> These mostly add the same stuff but not quite :-(
>>
>> Ah sorry, my bad. I'm not yet used to the uClinux guys touching "my"
>> includes ;-)
>> So we need better coordination between us.
>>
>> IIRC, Greg's changes were inspired by Andreas' patch.
>
> Yes, largely they are.
>
>
>>> I have done a fixup (see below) and can carry it as necessary.  Please
>>> check the result.
>>
>> At first sight, it looks OK. Thanks for fixing it up!
>
> Yep, looks ok from what I can see.
>
> Geert, how do you want to handle for the real linus merge?
> Do you want me to drop the changes to ptrace.h from that patch?

I can apply your patch (modified to apply on top of Andreas') to the
m68k for-linus branch.
Does that sound OK for you?

>>> --
>>> Cheers,
>>> Stephen Rothwell                    sfr@canb.auug.org.au
>>>
>>> diff --cc arch/m68k/include/asm/ptrace.h
>>> index eef9309,beb2091..0000000
>>> --- a/arch/m68k/include/asm/ptrace.h
>>> +++ b/arch/m68k/include/asm/ptrace.h
>>> @@@ -86,14 -84,15 +86,18 @@@ struct switch_stack
>>>  extern void show_regs(struct pt_regs *);
>>>
>>>  /*
>>>  - * These are defined as per linux/ptrace.h.
>>>  + * These are defined as per linux/ptrace.h, which see.
>>>  */
>>> + struct task_struct;
>>> +
>>>  -#ifndef CONFIG_MMU
>>>  -#define       arch_has_single_step()  (1)
>>>  +#define arch_has_single_step()        (1)
>>>  extern void user_enable_single_step(struct task_struct *);
>>>  extern void user_disable_single_step(struct task_struct *);
>>>  +
>>> ++#ifdef CONFIG_MMU
>>>  +#define arch_has_block_step() (1)
>>>  +extern void user_enable_block_step(struct task_struct *);
>>> + #endif
>>>
>>>  #endif /* __KERNEL__ */
>>>  #endif /* __ASSEMBLY__ */

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Greg Ungerer]

Hi Stephen, Geert,

Geert Uytterhoeven wrote:
> On Thu, Nov 26, 2009 at 01:58, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Today's linux-next merge of the m68knommu tree got a conflict in
>> arch/m68k/include/asm/ptrace.h between commit
>> 63c361b65f6540043c4baabf1a044a45c7465858 ("m68k: use generic code for
>> ptrace requests") from the m68k tree and commit
>> 03a03164e8084b810e9f92906a51232d63bac72c ("m68knommu: define
>> arch_has_single_step() and friends") from the m68knommu tree.
>>
>> These mostly add the same stuff but not quite :-(
> 
> Ah sorry, my bad. I'm not yet used to the uClinux guys touching "my"
> includes ;-)
> So we need better coordination between us.
> 
> IIRC, Greg's changes were inspired by Andreas' patch.

Yes, largely they are.


>> I have done a fixup (see below) and can carry it as necessary.  Please
>> check the result.
> 
> At first sight, it looks OK. Thanks for fixing it up!

Yep, looks ok from what I can see.

Geert, how do you want to handle for the real linus merge?
Do you want me to drop the changes to ptrace.h from that patch?

Regards
Greg



>> --
>> Cheers,
>> Stephen Rothwell                    sfr@canb.auug.org.au
>>
>> diff --cc arch/m68k/include/asm/ptrace.h
>> index eef9309,beb2091..0000000
>> --- a/arch/m68k/include/asm/ptrace.h
>> +++ b/arch/m68k/include/asm/ptrace.h
>> @@@ -86,14 -84,15 +86,18 @@@ struct switch_stack
>>  extern void show_regs(struct pt_regs *);
>>
>>  /*
>>  - * These are defined as per linux/ptrace.h.
>>  + * These are defined as per linux/ptrace.h, which see.
>>   */
>> + struct task_struct;
>> +
>>  -#ifndef CONFIG_MMU
>>  -#define       arch_has_single_step()  (1)
>>  +#define arch_has_single_step()        (1)
>>  extern void user_enable_single_step(struct task_struct *);
>>  extern void user_disable_single_step(struct task_struct *);
>>  +
>> ++#ifdef CONFIG_MMU
>>  +#define arch_has_block_step() (1)
>>  +extern void user_enable_block_step(struct task_struct *);
>> + #endif
>>
>>  #endif /* __KERNEL__ */
>>  #endif /* __ASSEMBLY__ */
> 
> Gr{oetje,eeting}s,
> 
> 						Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> 							    -- Linus Torvalds
> 


-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com

Re: linux-next: manual merge of the m68knommu tree with the m68k tree

[Geert Uytterhoeven]

On Thu, Nov 26, 2009 at 01:58, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Today's linux-next merge of the m68knommu tree got a conflict in
> arch/m68k/include/asm/ptrace.h between commit
> 63c361b65f6540043c4baabf1a044a45c7465858 ("m68k: use generic code for
> ptrace requests") from the m68k tree and commit
> 03a03164e8084b810e9f92906a51232d63bac72c ("m68knommu: define
> arch_has_single_step() and friends") from the m68knommu tree.
>
> These mostly add the same stuff but not quite :-(

Ah sorry, my bad. I'm not yet used to the uClinux guys touching "my"
includes ;-)
So we need better coordination between us.

IIRC, Greg's changes were inspired by Andreas' patch.

> I have done a fixup (see below) and can carry it as necessary.  Please
> check the result.

At first sight, it looks OK. Thanks for fixing it up!

> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
>
> diff --cc arch/m68k/include/asm/ptrace.h
> index eef9309,beb2091..0000000
> --- a/arch/m68k/include/asm/ptrace.h
> +++ b/arch/m68k/include/asm/ptrace.h
> @@@ -86,14 -84,15 +86,18 @@@ struct switch_stack
>  extern void show_regs(struct pt_regs *);
>
>  /*
>  - * These are defined as per linux/ptrace.h.
>  + * These are defined as per linux/ptrace.h, which see.
>   */
> + struct task_struct;
> +
>  -#ifndef CONFIG_MMU
>  -#define       arch_has_single_step()  (1)
>  +#define arch_has_single_step()        (1)
>  extern void user_enable_single_step(struct task_struct *);
>  extern void user_disable_single_step(struct task_struct *);
>  +
> ++#ifdef CONFIG_MMU
>  +#define arch_has_block_step() (1)
>  +extern void user_enable_block_step(struct task_struct *);
> + #endif
>
>  #endif /* __KERNEL__ */
>  #endif /* __ASSEMBLY__ */

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

linux-next: manual merge of the m68knommu tree with the m68k tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the m68knommu tree got a conflict in
arch/m68k/include/asm/ptrace.h between commit
63c361b65f6540043c4baabf1a044a45c7465858 ("m68k: use generic code for
ptrace requests") from the m68k tree and commit
03a03164e8084b810e9f92906a51232d63bac72c ("m68knommu: define
arch_has_single_step() and friends") from the m68knommu tree.

These mostly add the same stuff but not quite :-(

I have done a fixup (see below) and can carry it as necessary.  Please
check the result.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/m68k/include/asm/ptrace.h
index eef9309,beb2091..0000000
--- a/arch/m68k/include/asm/ptrace.h
+++ b/arch/m68k/include/asm/ptrace.h
@@@ -86,14 -84,15 +86,18 @@@ struct switch_stack 
  extern void show_regs(struct pt_regs *);
  
  /*
 - * These are defined as per linux/ptrace.h.
 + * These are defined as per linux/ptrace.h, which see.
   */
+ struct task_struct;
+ 
 -#ifndef CONFIG_MMU
 -#define	arch_has_single_step()	(1)
 +#define arch_has_single_step()	(1)
  extern void user_enable_single_step(struct task_struct *);
  extern void user_disable_single_step(struct task_struct *);
 +
++#ifdef CONFIG_MMU
 +#define arch_has_block_step()	(1)
 +extern void user_enable_block_step(struct task_struct *);
+ #endif
  
  #endif /* __KERNEL__ */
  #endif /* __ASSEMBLY__ */