Re: [PATCH 2/2] gpiolib: Defer gpio device setup until after gpiolib initialization

On 01/04/16 10:53, Guenter Roeck wrote: > On Fri, Apr 01, 2016 at 10:29:11AM +1000, Greg Ungerer wrote: >> Hi Guenter, >> >> On 01/04/16 01:11, Guenter Roeck wrote: >>> Since commit ff2b13592299 ("gpio: make the gpiochip a real device"), >>

Re: [PATCH 2/2] gpiolib: Defer gpio device setup until after gpiolib initialization

On 01/04/16 10:53, Guenter Roeck wrote: > On Fri, Apr 01, 2016 at 10:29:11AM +1000, Greg Ungerer wrote: >> Hi Guenter, >> >> On 01/04/16 01:11, Guenter Roeck wrote: >>> Since commit ff2b13592299 ("gpio: make the gpiochip a real device"), >>

Re: [PATCH 2/2] gpiolib: Defer gpio device setup until after gpiolib initialization

ed yet. Defer creating gpio devices until after gpiolib has > been initialized to fix the problem. > > Cc: Greg Ungerer <g...@uclinux.org> > Cc: Alexandre Courbot <gnu...@gmail.com> > Fixes: ff2b13592299 ("gpio: make the gpiochip a real device") > Signed-

Re: [PATCH 2/2] gpiolib: Defer gpio device setup until after gpiolib initialization

ed yet. Defer creating gpio devices until after gpiolib has > been initialized to fix the problem. > > Cc: Greg Ungerer > Cc: Alexandre Courbot > Fixes: ff2b13592299 ("gpio: make the gpiochip a real device") > Signed-off-by: Guenter Roeck Thanks for putting these pa

Re: [PATCH] gpio: add a userspace chardev ABI for GPIOs

Hi Alexandre, On 31/03/16 15:59, Alexandre Courbot wrote: > On Wed, Mar 30, 2016 at 10:49 AM, Greg Ungerer <g...@uclinux.org> wrote: >> Hi Linus, >> >> Commit 3c702e99 ("gpio: add a userspace chardev ABI for GPIOs") >> breaks booting on all my m68k/

Re: [PATCH] gpio: add a userspace chardev ABI for GPIOs

Hi Alexandre, On 31/03/16 15:59, Alexandre Courbot wrote: > On Wed, Mar 30, 2016 at 10:49 AM, Greg Ungerer wrote: >> Hi Linus, >> >> Commit 3c702e99 ("gpio: add a userspace chardev ABI for GPIOs") >> breaks booting on all my m68k/ColdFire platforms (with MMU

[git pull] m68knommu/coldfire fixes for 4.6

:17 +1000) Greg Ungerer (2): m68knommu: fix FEC platform device registration when driver is modular m68knommu: remove obsolete 68360 support arch/m68k/68360/Makefile | 12 - arch/m68k/68360/commproc.c

[git pull] m68knommu/coldfire fixes for 4.6

:17 +1000) Greg Ungerer (2): m68knommu: fix FEC platform device registration when driver is modular m68knommu: remove obsolete 68360 support arch/m68k/68360/Makefile | 12 - arch/m68k/68360/commproc.c

Re: [PATCH] ARM: ks8695: fix __initdata annotation

/mach-ks8695/board-og.c:83:31: error: '__section__' attribute only > applies to functions and global variables > > This moves the attribute to the correct place. > > Signed-off-by: Arnd Bergmann Acked-by: Greg Ungerer Regards Greg > --- > arch/arm/mach-ks8695/board-og

Re: [PATCH] ARM: ks8695: fix __initdata annotation

/mach-ks8695/board-og.c:83:31: error: '__section__' attribute only > applies to functions and global variables > > This moves the attribute to the correct place. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> Acked-by: Greg Ungerer <g...@uclinux.org> Regards Greg

Re: [PATCH] m68k: Wire up copy_file_range

On 23/01/16 20:05, Geert Uytterhoeven wrote: Signed-off-by: Geert Uytterhoeven Acked-by: Greg Ungerer --- arch/m68k/include/asm/unistd.h | 2 +- arch/m68k/include/uapi/asm/unistd.h | 1 + arch/m68k/kernel/syscalltable.S | 1 + 3 files changed, 3 insertions(+), 1 deletion

Re: [PATCH] m68k: Wire up copy_file_range

On 23/01/16 20:05, Geert Uytterhoeven wrote: Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> Acked-by: Greg Ungerer <g...@uclinux.org> --- arch/m68k/include/asm/unistd.h | 2 +- arch/m68k/include/uapi/asm/unistd.h | 1 + arch/m68k/kernel/syscalltable.S | 1

Re: [PATCH] serial: Remove 68328 driver

On 04/01/16 20:30, One Thousand Gnomes wrote: On Mon, 4 Jan 2016 15:03:50 +1000 Greg Ungerer wrote: If 68328serial.c is removed is there any point keeping the architecture support for 68328 platforms? The 68328serial.c provides pretty much the only type of console that can be used

Re: [PATCH] serial: Remove 68328 driver

On 04/01/16 20:30, One Thousand Gnomes wrote: On Mon, 4 Jan 2016 15:03:50 +1000 Greg Ungerer <gregunge...@westnet.com.au> wrote: If 68328serial.c is removed is there any point keeping the architecture support for 68328 platforms? The 68328serial.c provides pretty much the only type of c

Re: [PATCH] serial: Remove 68328 driver

ight (C) 1998 Kenneth Albanowski >> - * Copyright (C) 1998, 1999 D. Jeff Dionne >> - * Copyright (C) 1999 Vladimir Gurevich >> - * Copyright (C) 2002-2003 David McCullough >> - * Copyright (C) 2002 Greg Ungerer >> - * >> - *

Re: [PATCH] serial: Remove 68328 driver

>> - * >> - * Copyright (C) 1995 David S. Miller<da...@caip.rutgers.edu> >> - * Copyright (C) 1998 Kenneth Albanowski <kja...@kjahds.com> >> - * Copyright (C) 1998, 1999 D. Jeff Dionne <j...@uclinux.org> >> - * Copyright (C) 199

Re: [PATCH] clk: let clk_disable() return immediately if clk is NULL or error

to all callees. Signed-off-by: Masahiro Yamada I have no problems with the m68k/coldfire change: Acked-by: Greg Ungerer Regards Greg --- arch/arm/mach-ep93xx/clock.c | 2 +- arch/arm/mach-lpc32xx/clock.c| 3 +++ arch/arm/mach-mmp/clock.c| 3 +++ arch/arm/mach-sa1100

Re: [PATCH] clk: let clk_disable() return immediately if clk is NULL or error

to all callees. Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com> I have no problems with the m68k/coldfire change: Acked-by: Greg Ungerer <g...@uclinux.org> Regards Greg --- arch/arm/mach-ep93xx/clock.c | 2 +- arch/arm/mach-lpc32xx/clock.c| 3 +++ arch/

Re: [PATCH] include: asm-generic: page.h: Remove useless get_user_page and free_user_page

with each other, neither are used in real world (can not be found by grep command in source code root directory), so remove them. Signed-off-by: Chen Gang Compile and run tested on m68k (MMU and noMMU) targets. No problems found. So for those parts: Acked-by: Greg Ungerer Regards Greg

Re: [PATCH] include: asm-generic: page.h: Remove useless get_user_page and free_user_page

So for those parts: Acked-by: Greg Ungerer <g...@uclinux.org> Regards Greg --- arch/arc/include/asm/page.h | 3 --- arch/arm/include/asm/page-nommu.h | 3 --- arch/frv/include/asm/page.h | 3 --- arch/m68k/include/asm/page_mm.h | 3 --- arch/m68k/include/asm/page_no.

Re: [PATCH] m68k: Wire up mlock2

Hi Geert, On 15/11/15 21:09, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven I see no problems. Acked-by: Greg Ungerer Regards Greg > This depends on series "[PATCH 0/4] m68k/mm: Add missing initialization of > max_pfn and {min,max}_low_pfn" to work. >

Re: [PATCH 0/4] m68k/mm: Add missing initialization of max_pfn and {min,max}_low_pfn

block > devices. An uninitialized (zero) value means all RAM is suitable for > DMA. All looks good to me. Tested-by acks set separately. But otherwise Acked-by: Greg Ungerer Regards Greg > Absence of initialization of min_low_pfn and max_low_pfn is more subtle. > (are there an

Re: [PATCH 2/4] m68k/mm: m54xx - Add missing initialization of max_pfn

> --- > Compile-tested only. Tested and seems to work fine on MMU ColdFire (I didn't check the actual entries for accuracy - but /proc/kpageflags and /proc/kpagecount look to be reporting correctly now). Tested-by: Greg Ungerer Regards Greg






> --- > arc

Re: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn

Hi Geert, On 15/11/15 21:04, Geert Uytterhoeven wrote: > If max_pfn is not initialized, the block layer may use wrong DMA masks. > > Replace open-coded shifts by PFN_DOWN() while we're at it. > > Signed-off-by: Geert Uytterhoeven Tested and working fine on m68knommu. So:

Re: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn

Hi Geert, On 16/11/15 23:05, Geert Uytterhoeven wrote: > On Mon, Nov 16, 2015 at 1:18 PM, Greg Ungerer wrote: >>> --- a/arch/m68k/kernel/setup_no.c >>> +++ b/arch/m68k/kernel/setup_no.c >>> @@ -238,11 +238,14 @@ void __init setup_arch(char **cmdline_p) >

Re: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn

Hi Geert, On 15/11/15 21:04, Geert Uytterhoeven wrote: If max_pfn is not initialized, the block layer may use wrong DMA masks. Replace open-coded shifts by PFN_DOWN() while we're at it. Signed-off-by: Geert Uytterhoeven --- Compile-tested only. --- arch/m68k/kernel/setup_no.c | 9 ++---

Re: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn

Hi Geert, On 15/11/15 21:04, Geert Uytterhoeven wrote: If max_pfn is not initialized, the block layer may use wrong DMA masks. Replace open-coded shifts by PFN_DOWN() while we're at it. Signed-off-by: Geert Uytterhoeven --- Compile-tested only. ---

Re: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn

fine on m68knommu. So: Tested-By: Greg Ungerer <g...@uclinux.org> If you respin this patch for any reason I wouldn't object to removing the "/* 0 on coldfire */" comment... Regards Greg > --- > Compile-tested only. > --- > arch/m68k/kernel/setup_no.c | 9 ++--

Re: [PATCH 4/4] m68knommu: Add missing initialization of max_pfn and {min,max}_low_pfn

Hi Geert, On 16/11/15 23:05, Geert Uytterhoeven wrote: > On Mon, Nov 16, 2015 at 1:18 PM, Greg Ungerer <g...@uclinux.org> wrote: >>> --- a/arch/m68k/kernel/setup_no.c >>> +++ b/arch/m68k/kernel/setup_no.c >>> @@ -238,11 +238,14 @@ void __init setup_arch(char

Re: [PATCH 2/4] m68k/mm: m54xx - Add missing initialization of max_pfn

en <ge...@linux-m68k.org> > --- > Compile-tested only. Tested and seems to work fine on MMU ColdFire (I didn't check the actual entries for accuracy - but /proc/kpageflags and /proc/kpagecount look to be reporting correctly now). Tested-by: Greg Ungerer <g

Re: [PATCH] m68k: Wire up mlock2

Hi Geert, On 15/11/15 21:09, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> I see no problems. Acked-by: Greg Ungerer <g...@uclinux.org> Regards Greg > This depends on series "[PATCH 0/4] m68k/mm: Add missing initialization of

Re: [PATCH 0/4] m68k/mm: Add missing initialization of max_pfn and {min,max}_low_pfn

block > devices. An uninitialized (zero) value means all RAM is suitable for > DMA. All looks good to me. Tested-by acks set separately. But otherwise Acked-by: Greg Ungerer <g...@uclinux.org> Regards Greg > Absence of initialization of min_low_pfn and max_low_pfn is more subtle.

[git pull] m68knommu/coldfire fixes for 4.4

Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only a single patch, fixes brk area setup problem in nommu environments. Regards Greg The following changes since commit 32b88194f71d6ae7768a29f87fbba454728273ee: Linux 4.3-rc7 (2015-10-25 10:39:47 +0900) are

[git pull] m68knommu/coldfire fixes for 4.4

Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only a single patch, fixes brk area setup problem in nommu environments. Regards Greg The following changes since commit 32b88194f71d6ae7768a29f87fbba454728273ee: Linux 4.3-rc7 (2015-10-25 10:39:47 +0900) are

Re: [PATCH v2] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries

Hi Rich, On 14/10/15 01:49, Rich Felker wrote: > On Tue, Oct 13, 2015 at 10:55:45PM +1000, Greg Ungerer wrote: >> Hi Rich, >> >> On 09/10/15 02:38, Rich Felker wrote: >>> From: Rich Felker >>> >>> The ELF binary loader in binfmt_elf.c requires an

Re: [PATCH v2] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries

Hi Rich, On 14/10/15 01:49, Rich Felker wrote: > On Tue, Oct 13, 2015 at 10:55:45PM +1000, Greg Ungerer wrote: >> Hi Rich, >> >> On 09/10/15 02:38, Rich Felker wrote: >>> From: Rich Felker <dal...@libc.org> >>> >>> The ELF binary loader in

Re: [PATCH v2] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries

virtual address is not possible on NOMMU. Signed-off-by: Rich Felker I have no problem with this, so from me: Acked-by: Greg Ungerer --- This patch was developed and tested on J2 (SH2-compatible) but should be usable immediately on all archs where binfmt_elf_fdpic is available. Moreover

Re: [PATCH v2] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries

since loading at a fixed virtual address is not possible on NOMMU. Signed-off-by: Rich Felker <dal...@libc.org> I have no problem with this, so from me: Acked-by: Greg Ungerer <g...@uclinux.org> --- This patch was developed and tested on J2 (SH2-compatible) but should be usable immedi

Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU

Hi Rich, On 15/09/15 01:17, Rich Felker wrote: > On Mon, Sep 14, 2015 at 10:13:03PM +1000, Greg Ungerer wrote: >> On 26/08/15 11:26, Greg Ungerer wrote: >>> On 21/08/15 05:11, Rich Felker wrote: >>>> From: Rich Felker >>>> >>>> On NOMMU ar

Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU

Hi Rich, On 26/08/15 11:26, Greg Ungerer wrote: On 21/08/15 05:11, Rich Felker wrote: From: Rich Felker On NOMMU archs, the FDPIC ELF loader sets up the usable brk range to overlap with all but the last PAGE_SIZE bytes of the stack. This leads to catastrophic memory reuse/corruption if brk

Re: [PATCH v2 3/4] m68k: Wire up direct ipc calls

Hi Geert, On 14/09/15 18:56, Geert Uytterhoeven wrote: Signed-off-by: Geert Uytterhoeven Both new patches look fine to me, Acked-by: Greg Ungerer Regards Greg --- v2: - New. --- arch/m68k/include/asm/unistd.h | 2 +- arch/m68k/include/uapi/asm/unistd.h | 11

Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU

Hi Rich, On 26/08/15 11:26, Greg Ungerer wrote: On 21/08/15 05:11, Rich Felker wrote: From: Rich Felker <dal...@libc.org> On NOMMU archs, the FDPIC ELF loader sets up the usable brk range to overlap with all but the last PAGE_SIZE bytes of the stack. This leads to catastrophic memory

Re: [PATCH v2 3/4] m68k: Wire up direct ipc calls

Hi Geert, On 14/09/15 18:56, Geert Uytterhoeven wrote: Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> Both new patches look fine to me, Acked-by: Greg Ungerer <g...@uclinux.org> Regards Greg --- v2: - New. --- arch/m68k/include/asm/unistd.h | 2 +- arch/

Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU

Hi Rich, On 15/09/15 01:17, Rich Felker wrote: > On Mon, Sep 14, 2015 at 10:13:03PM +1000, Greg Ungerer wrote: >> On 26/08/15 11:26, Greg Ungerer wrote: >>> On 21/08/15 05:11, Rich Felker wrote: >>>> From: Rich Felker <dal...@libc.org> >>>> &

Re: [PATCH 1/2] [RFC] m68k: Wire up direct socket calls

Hi Geert, On 06/09/15 20:06, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven Both of these syscall patches look good to me: Acked-by: Greg Ungerer Regards Greg > --- > arch/m68k/include/asm/unistd.h | 2 +- > arch/m68k/include/uapi/asm/u

[git pull] m68knommu/coldfire fixes for 4.3

Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only a couple of patches this time. One migrating the clock driver code to the new set-state interface. The other cleaning up to use the PFN_DOWN macro. Regards Greg The following changes since commit

[git pull] m68knommu/coldfire fixes for 4.3

Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only a couple of patches this time. One migrating the clock driver code to the new set-state interface. The other cleaning up to use the PFN_DOWN macro. Regards Greg The following changes since commit

Re: [PATCH 1/2] [RFC] m68k: Wire up direct socket calls

Hi Geert, On 06/09/15 20:06, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> Both of these syscall patches look good to me: Acked-by: Greg Ungerer <g...@uclinux.org> Regards Greg > --- > arch/m68k/include/asm/unistd.h | 2 +-

Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU

tting > the brk area to zero size to disable its use. > > Signed-off-by: Rich Felker It would make sense to run this by David Howells , I think he wrote this code (added to CC list). I have no problem with it, so: Acked-by: Greg Ungerer > --- > > There is no reason for the

Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU

the brk area to zero size to disable its use. Signed-off-by: Rich Felker dal...@libc.org It would make sense to run this by David Howells dhowe...@redhat.com, I think he wrote this code (added to CC list). I have no problem with it, so: Acked-by: Greg Ungerer g...@uclinux.org

Re: [PATCH v2] m68k/coldfire: use PFN_DOWN macro

Hi Alexander, On 12/08/15 17:14, Alexander Kuleshov wrote: > Replace ((x) >> PAGE_SHIFT) with the predefined PFN_DOWN macro. > > Signed-off-by: Alexander Kuleshov This one looks good. Applied to m68knommu git tree (for-next branch). Thanks Greg > --- > arch/m68k/coldfire/m54xx.c | 9

Re: [PATCH v2] m68k/coldfire: use PFN_DOWN macro

Hi Alexander, On 12/08/15 17:14, Alexander Kuleshov wrote: Replace ((x) PAGE_SHIFT) with the predefined PFN_DOWN macro. Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com This one looks good. Applied to m68knommu git tree (for-next branch). Thanks Greg ---

[git pull] m68knommu/coldfire fixes for 4.2-rc3

to 67592f699cb309559575b89d727d510ea076521c: m68k: enable PCI support for m5475evb defconfig (2015-07-13 09:34:40 +1000) Greg Ungerer (12): m68knommu: force setting of CONFIG_CLOCK_FREQ for ColdFire m68knommu: improve the clock configuration defaults

Re: [PATCH 08/23] m68k/coldfire/pit: Migrate to new 'set-state' interface

: ONESHOT_STOPPED. We weren't doing anything in ->set_mode(RESUME) and so tick_resume() isn't implemented. Cc: Greg Ungerer Applied and tested ok (against 4.2-rc2). Acked-by: Greg Ungerer Cc: Geert Uytterhoeven Cc: linux-m...@lists.linux-m68k.org Signed-off-by: Viresh Kumar --- arch/m68k/coldf

Re: [PATCH 08/23] m68k/coldfire/pit: Migrate to new 'set-state' interface

: ONESHOT_STOPPED. We weren't doing anything in -set_mode(RESUME) and so tick_resume() isn't implemented. Cc: Greg Ungerer g...@uclinux.org Applied and tested ok (against 4.2-rc2). Acked-by: Greg Ungerer g...@uclinux.org Cc: Geert Uytterhoeven ge...@linux-m68k.org Cc: linux-m...@lists.linux-m68k.org

[git pull] m68knommu/coldfire fixes for 4.2-rc3

to 67592f699cb309559575b89d727d510ea076521c: m68k: enable PCI support for m5475evb defconfig (2015-07-13 09:34:40 +1000) Greg Ungerer (12): m68knommu: force setting of CONFIG_CLOCK_FREQ for ColdFire m68knommu: improve the clock configuration defaults

[git pull] m68knommu arch fixes for 4.2

entry (2015-06-19 17:22:17 +1000) Greg Ungerer (1): m68k: improve m68knommu MAINTAINERS entry Joe Perches (1): m68k: Use vsprintf %pM extension MAINTAINERS| 6 +- arch/m68k/68000/m68EZ328.c | 3

[git pull] m68knommu arch fixes for 4.2

entry (2015-06-19 17:22:17 +1000) Greg Ungerer (1): m68k: improve m68knommu MAINTAINERS entry Joe Perches (1): m68k: Use vsprintf %pM extension MAINTAINERS| 6 +- arch/m68k/68000/m68EZ328.c | 3

Re: [PATCH] m68k: improve m68knommu MAINTAINERS entry

Hi Geert, On 19/06/15 16:58, Geert Uytterhoeven wrote: > Hi Greg, > > On Fri, Jun 19, 2015 at 3:13 AM, wrote: >> From: Greg Ungerer >> >> Improve the information in the m68knommu maintainers entry. This >> should aid in making it clearer what parts of the m68

Re: [PATCH] m68k: improve m68knommu MAINTAINERS entry

Hi Geert, On 19/06/15 16:58, Geert Uytterhoeven wrote: Hi Greg, On Fri, Jun 19, 2015 at 3:13 AM, g...@uclinux.org wrote: From: Greg Ungerer g...@uclinux.org Improve the information in the m68knommu maintainers entry. This should aid in making it clearer what parts of the m68k

Re: [uClinux-dev] m68k compile issue with 4.0.5

Hi Waldemar, On 17/06/15 15:42, Waldemar Brodkorb wrote: Hi Greg, Greg Ungerer wrote, I don't have any compile (or runtime) problems with m5208evb_defconfig on linux-4.0.5 either. That is close to what most people use with qemu. What .config are you using? Are you sure the defconfig creates

Re: [uClinux-dev] m68k compile issue with 4.0.5

Hi Waldemar, On 17/06/15 15:42, Waldemar Brodkorb wrote: Hi Greg, Greg Ungerer wrote, I don't have any compile (or runtime) problems with m5208evb_defconfig on linux-4.0.5 either. That is close to what most people use with qemu. What .config are you using? Are you sure the defconfig creates

Re: [uClinux-dev] m68k compile issue with 4.0.5

Hi Waldemar, On 17/06/15 15:42, Waldemar Brodkorb wrote: > Hi Greg, > Greg Ungerer wrote, >> >> I don't have any compile (or runtime) problems with m5208evb_defconfig >> on linux-4.0.5 either. That is close to what most people use with qemu. >> What .config ar

Re: [uClinux-dev] m68k compile issue with 4.0.5

Hi Waldemar, On 17/06/15 15:42, Waldemar Brodkorb wrote: Hi Greg, Greg Ungerer wrote, I don't have any compile (or runtime) problems with m5208evb_defconfig on linux-4.0.5 either. That is close to what most people use with qemu. What .config are you using? Are you sure the defconfig

Re: [PATCH] m68k: Use vsprintf %pM extension

Hi Joe, On 15/06/15 12:01, Joe Perches wrote: > Format mac addresses with the normal kernel extension. > > Signed-off-by: Joe Perches Thanks. I have pushed this into the m68knommu git tree (for-next branch) on kernel.org. Regards Greg > --- > arch/m68k/68000/m68EZ328.c | 3 +-- >

Re: [uClinux-dev] m68k compile issue with 4.0.5

Hi Waldemar, On 16/06/15 16:24, Geert Uytterhoeven wrote: > Hi Waldemar, > > On Mon, Jun 15, 2015 at 10:23 PM, Waldemar Brodkorb wrote: >> I am trying to build a M68K (Coldfire no-MMU) kernel for Qemu-system-m68k. >> >> With 4.0.4 everything is fine. With 4.0.5 I get following compile >> error:

Re: [uClinux-dev] m68k compile issue with 4.0.5

Hi Waldemar, On 16/06/15 16:24, Geert Uytterhoeven wrote: Hi Waldemar, On Mon, Jun 15, 2015 at 10:23 PM, Waldemar Brodkorb w...@openadk.org wrote: I am trying to build a M68K (Coldfire no-MMU) kernel for Qemu-system-m68k. With 4.0.4 everything is fine. With 4.0.5 I get following compile

Re: [PATCH] m68k: Use vsprintf %pM extension

Hi Joe, On 15/06/15 12:01, Joe Perches wrote: Format mac addresses with the normal kernel extension. Signed-off-by: Joe Perches j...@perches.com Thanks. I have pushed this into the m68knommu git tree (for-next branch) on kernel.org. Regards Greg --- arch/m68k/68000/m68EZ328.c | 3 +--

[git pull] m68knommu arch fixes for 4.1

) Greg Ungerer (2): m68knommu: ColdFire 5271 only has a single FEC controller m68knommu: fix fec setup warning for ColdFire 5271 builds Yannick Guerrini (1): m68k: Fix trivial typos in comments arch/m68k/coldfire/m527x.c | 3 ++- arch

[git pull] m68knommu arch fixes for 4.1

) Greg Ungerer (2): m68knommu: ColdFire 5271 only has a single FEC controller m68knommu: fix fec setup warning for ColdFire 5271 builds Yannick Guerrini (1): m68k: Fix trivial typos in comments arch/m68k/coldfire/m527x.c | 3 ++- arch

Re: [PATCH] m68k: Fix trivial typos in comments

Hi Yannick, On 10/03/15 07:29, Yannick Guerrini wrote: > Change 'Reaceive' to 'Receive' > Change 'alighnment' to 'alignment' > > Signed-off-by: Yannick Guerrini Thanks. I have put this in the m68knommu git tree, for-next branch. Regards Greg > --- > arch/m68k/include/asm/m68360_pram.h |

Re: [PATCH] m68k: Fix trivial typos in comments

Hi Yannick, On 10/03/15 07:29, Yannick Guerrini wrote: Change 'Reaceive' to 'Receive' Change 'alighnment' to 'alignment' Signed-off-by: Yannick Guerrini yguerr...@tomshardware.fr Thanks. I have put this in the m68knommu git tree, for-next branch. Regards Greg ---

[git pull] m68knommu arch fixes for 3.20

) Greg Ungerer (1): m68knommu: fix irq handler types in 68360/commproc.c Paul Bolle (1): m68k: remove check for CONFIG_BSEIP Rickard Strandqvist (1): arch: m68k: 68360: config: Remove unused function arch/m68k/68360/commproc.c | 8 arch

[git pull] m68knommu arch fixes for 3.20

) Greg Ungerer (1): m68knommu: fix irq handler types in 68360/commproc.c Paul Bolle (1): m68k: remove check for CONFIG_BSEIP Rickard Strandqvist (1): arch: m68k: 68360: config: Remove unused function arch/m68k/68360/commproc.c | 8 arch

[git pull] m68knommu arch fixes for 3.20

) Greg Ungerer (1): m68knommu: fix irq handler types in 68360/commproc.c Paul Bolle (1): m68k: remove check for CONFIG_BSEIP Rickard Strandqvist (1): arch: m68k: 68360: config: Remove unused function arch/m68k/68360/commproc.c | 8 arch

[git pull] m68knommu arch fixes for 3.20

) Greg Ungerer (1): m68knommu: fix irq handler types in 68360/commproc.c Paul Bolle (1): m68k: remove check for CONFIG_BSEIP Rickard Strandqvist (1): arch: m68k: 68360: config: Remove unused function arch/m68k/68360/commproc.c | 8 arch

Re: [PATCH 01/28] PCI: Rip out pci_bus_add_devices() from pci_scan_bus()

On 19/01/15 12:04, Yijing Wang wrote: > On 2015/1/17 7:16, Yinghai Lu wrote: >> On Fri, Jan 16, 2015 at 3:15 PM, Yinghai Lu wrote: >>> On Thu, Jan 15, 2015 at 5:43 PM, Yijing Wang wrote: Pci_bus_add_devices() should not be placed in pci_scan_bus(). Now pci device will be added to

Re: [PATCH 01/28] PCI: Rip out pci_bus_add_devices() from pci_scan_bus()

On 19/01/15 12:04, Yijing Wang wrote: On 2015/1/17 7:16, Yinghai Lu wrote: On Fri, Jan 16, 2015 at 3:15 PM, Yinghai Lu ying...@kernel.org wrote: On Thu, Jan 15, 2015 at 5:43 PM, Yijing Wang wangyij...@huawei.com wrote: Pci_bus_add_devices() should not be placed in pci_scan_bus(). Now pci

Re: [PATCH 09/16] ARM: ks8695: convert PCI to use generic config accesses

Hi Rob, On 10/01/15 12:34, Rob Herring wrote: Convert the ks8695 PCI driver to use the generic config access functions. This changes accesses from __raw_readX/__raw_writeX to readX/writeX variants. Signed-off-by: Rob Herring Cc: Greg Ungerer I wasn't CC'ed on the generic implementation

Re: [PATCH 09/16] ARM: ks8695: convert PCI to use generic config accesses

Hi Rob, On 10/01/15 12:34, Rob Herring wrote: Convert the ks8695 PCI driver to use the generic config access functions. This changes accesses from __raw_readX/__raw_writeX to readX/writeX variants. Signed-off-by: Rob Herring r...@kernel.org Cc: Greg Ungerer g...@uclinux.org I wasn't CC'ed

Re: [PATCH] arch: m68k: 68360: config: Remove unused function

Hi Rickard, On 03/01/15 07:05, Rickard Strandqvist wrote: > Remove the function BSP_set_clock_mmss() that is not used anywhere. > > This was partially found by using a static code analysis program called > cppcheck. > > Signed-off-by: Rickard Strandqvist Thanks, I'll add it to the m68knommu

Re: [PATCH] arch: m68k: 68360: config: Remove unused function

Hi Rickard, On 03/01/15 07:05, Rickard Strandqvist wrote: Remove the function BSP_set_clock_mmss() that is not used anywhere. This was partially found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se

Re: [PATCH] m68k: remove check for CONFIG_BSEIP

Hi Paul, On 20/05/14 17:56, Paul Bolle wrote: > There used to be a Kconfig symbol BSEIP. It was PPC specific and was > removed in v2.6.27. So the check for CONFIG_BSEIP can be removed. This > means a few defines will be removed. None of the macros involved are > used, so no one should care. > >

Re: [PATCH] m68k: remove check for CONFIG_BSEIP

Hi Paul, On 20/05/14 17:56, Paul Bolle wrote: There used to be a Kconfig symbol BSEIP. It was PPC specific and was removed in v2.6.27. So the check for CONFIG_BSEIP can be removed. This means a few defines will be removed. None of the macros involved are used, so no one should care.

Re: [PATCH v2 04/47] m68k: Replace mach_power_off with pm_power_off

Hi Guenter, On 21/10/14 14:12, Guenter Roeck wrote: > Replace mach_power_off with pm_power_off to simplify the subsequent > move of pm_power_off to generic code. > > Cc: Geert Uytterhoeven > Cc: Greg Ungerer > Cc: Joshua Thompson > Acked-by: Geert Uytterhoeven > Sign

Re: [PATCH v2 04/47] m68k: Replace mach_power_off with pm_power_off

Hi Guenter, On 21/10/14 14:12, Guenter Roeck wrote: Replace mach_power_off with pm_power_off to simplify the subsequent move of pm_power_off to generic code. Cc: Geert Uytterhoeven ge...@linux-m68k.org Cc: Greg Ungerer g...@uclinux.org Cc: Joshua Thompson fun...@jurai.org Acked-by: Geert

[git pull] m68knommu arch fixes for 3.18

for you to fetch changes up to e803d4bd31184b301a54352bb2c1a3fa93f80154: m68k: Fix typo 'COFNIG_MBAR' (2014-09-29 09:56:19 +1000) Fabian Frederick (1): m68k/coldfire: remove second asm/mcfclk.h inclusion in m54xx.c Greg Ungerer

[git pull] m68knommu arch fixes for 3.18

for you to fetch changes up to e803d4bd31184b301a54352bb2c1a3fa93f80154: m68k: Fix typo 'COFNIG_MBAR' (2014-09-29 09:56:19 +1000) Fabian Frederick (1): m68k/coldfire: remove second asm/mcfclk.h inclusion in m54xx.c Greg Ungerer

Re: [PATCH] [TRIVIAL] m68k: Fix typo 'COFNIG_MBAR'

Hi Paul, On 27/09/14 03:40, Paul Bolle wrote: > Signed-off-by: Paul Bolle > --- > Untested! Thanks. I have applied this to the m68knommu git tree (since that is where we tend to keep all ColdFire fixes). > Geert, PASR is obviously unused. Is it needed? Not at the moment. It will be if/when

Re: [PATCH] [TRIVIAL] m68k: Fix typo 'COFNIG_MBAR'

Hi Paul, On 27/09/14 03:40, Paul Bolle wrote: Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Untested! Thanks. I have applied this to the m68knommu git tree (since that is where we tend to keep all ColdFire fixes). Geert, PASR is obviously unused. Is it needed? Not at the moment. It

Re: [PATCH v3 09/17] m68k: io: implement dummy relaxed accessor macros for writes

Hi Will On 25/09/14 03:17, Will Deacon wrote: > write{b,w,l}_relaxed are implemented by some architectures in order to > permit memory-mapped I/O accesses with weaker barrier semantics than the > non-relaxed variants. > > This patch adds dummy macros for the write accessors to m68k, in the >

Re: [RFC PATCH] ARM: at91: remove no-MMU at91x40 support

nline now so this target is not interesting > for > building tests anymore. It would be better to start from these modern ARM !MMU > platforms to reintroduce at91x40 support if needed. > > Signed-off-by: Nicolas Ferre Acked-by: Greg Ungerer > --- > arch/arm/configs

Re: [RFC PATCH] ARM: at91: remove no-MMU at91x40 support

is not interesting for building tests anymore. It would be better to start from these modern ARM !MMU platforms to reintroduce at91x40 support if needed. Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com Acked-by: Greg Ungerer g...@uclinux.org --- arch/arm/configs/at91x40_defconfig

Re: [PATCH v3 09/17] m68k: io: implement dummy relaxed accessor macros for writes

Hi Will On 25/09/14 03:17, Will Deacon wrote: write{b,w,l}_relaxed are implemented by some architectures in order to permit memory-mapped I/O accesses with weaker barrier semantics than the non-relaxed variants. This patch adds dummy macros for the write accessors to m68k, in the same vein

Re: [PATCH 1/1 linux-next] m68k/coldfire: remove second asm/mcfclk.h inclusion in m54xx.c

Hi Fabian, On 17/09/14 04:43, Fabian Frederick wrote: > asm/mcfclk.h was included twice. > > Signed-off-by: Fabian Frederick Looks good, thanks. I have added it to the for-next branch of the m68knommu git tree. Regards Greg > --- > arch/m68k/coldfire/m54xx.c | 1 - > 1 file changed, 1

Re: [PATCH 1/1 linux-next] m68k/coldfire: remove second asm/mcfclk.h inclusion in m54xx.c

Hi Fabian, On 17/09/14 04:43, Fabian Frederick wrote: asm/mcfclk.h was included twice. Signed-off-by: Fabian Frederick f...@skynet.be Looks good, thanks. I have added it to the for-next branch of the m68knommu git tree. Regards Greg --- arch/m68k/coldfire/m54xx.c | 1 - 1 file

Re: [PATCH v9 4/9] arm: ks8695: Migrate debug_ll macros to shared directory

-macro.S until DEBUG_LL_UART_NONE has been removed. Signed-off-by: Daniel Thompson Cc: Russell King Cc: Greg Ungerer Cc: Arnd Bergmann --- arch/arm/Kconfig.debug | 8 .../include/mach/debug-macro.S => include/debug/ks8695.S} |

Re: [PATCH v9 4/9] arm: ks8695: Migrate debug_ll macros to shared directory

-macro.S until DEBUG_LL_UART_NONE has been removed. Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org Cc: Russell King li...@arm.linux.org.uk Cc: Greg Ungerer g...@uclinux.org Cc: Arnd Bergmann arnd.bergm...@linaro.org --- arch/arm/Kconfig.debug | 8

Re: [PATCH 0/3] fs/proc/task_nommu.c: copy-and-paste the changes from task_mmu.c

ill came out fine. Is there anything else I should check? I am happy to ack it: Acked-by: Greg Ungerer Regards Greg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vg

Re: [PATCH 0/3] fs/proc/task_nommu.c: copy-and-paste the changes from task_mmu.c

and that still came out fine. Is there anything else I should check? I am happy to ack it: Acked-by: Greg Ungerer g...@uclinux.org Regards Greg -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http

<    1   2   3   4   5   6   7   8   9   >