Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

Hi Geert, On 31/05/18 05:55, Geert Uytterhoeven wrote: On Wed, May 30, 2018 at 2:28 AM, Greg Ungerer wrote: On 28/05/18 20:15, Geert Uytterhoeven wrote: On Mon, May 28, 2018 at 7:26 AM, Finn Thain wrote: On Mon, 28 May 2018, Michael Schmitz wrote: Am 27.05.2018 um 17:49 schrieb Finn Thain

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

Hi Geert, On 31/05/18 05:55, Geert Uytterhoeven wrote: On Wed, May 30, 2018 at 2:28 AM, Greg Ungerer wrote: On 28/05/18 20:15, Geert Uytterhoeven wrote: On Mon, May 28, 2018 at 7:26 AM, Finn Thain wrote: On Mon, 28 May 2018, Michael Schmitz wrote: Am 27.05.2018 um 17:49 schrieb Finn Thain

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

Hi Geert, On 28/05/18 20:15, Geert Uytterhoeven wrote: On Mon, May 28, 2018 at 7:26 AM, Finn Thain wrote: On Mon, 28 May 2018, Michael Schmitz wrote: Am 27.05.2018 um 17:49 schrieb Finn Thain: On Sun, 27 May 2018, Michael Schmitz wrote: That should have fixed the warning already ...

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

Hi Geert, On 28/05/18 20:15, Geert Uytterhoeven wrote: On Mon, May 28, 2018 at 7:26 AM, Finn Thain wrote: On Mon, 28 May 2018, Michael Schmitz wrote: Am 27.05.2018 um 17:49 schrieb Finn Thain: On Sun, 27 May 2018, Michael Schmitz wrote: That should have fixed the warning already ...

Re: [PATCH 1/7] i2c: i2c-gpio: move header to platform_data

#include ... and this was the shortened diff for those. Greg, Russell, Ralf, James? Is it okay if I take this via my tree? Yes, I have no problem with that for the ks8695 part. Acked-by: Greg Ungerer <g...@uclinux.org> Thanks Greg Thanks, Wolfram

Re: [PATCH 1/7] i2c: i2c-gpio: move header to platform_data

#include ... and this was the shortened diff for those. Greg, Russell, Ralf, James? Is it okay if I take this via my tree? Yes, I have no problem with that for the ks8695 part. Acked-by: Greg Ungerer Thanks Greg Thanks, Wolfram

Re: [RFC] m68k: Set up dma mask for platform devices

Hi Finn, On 13/05/18 11:00, Finn Thain wrote: This avoids a WARNING splat when loading the macsonic or macmace driver. Please see commit 205e1b7f51e4 ("dma-mapping: warn when there is no coherent_dma_mask"). This implementation of arch_setup_pdev_archdata() differs from the one in arch/powerpc

Re: [RFC] m68k: Set up dma mask for platform devices

Hi Finn, On 13/05/18 11:00, Finn Thain wrote: This avoids a WARNING splat when loading the macsonic or macmace driver. Please see commit 205e1b7f51e4 ("dma-mapping: warn when there is no coherent_dma_mask"). This implementation of arch_setup_pdev_archdata() differs from the one in arch/powerpc

Re: [PATCH] m68k: Fix calendar month regression on M68328

he m68knommu tree. Either way: Acked-by: Greg Ungerer <g...@linux-m68k.org> Regards Greg > --- > arch/m68k/68000/timers.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/m68k/68000/timers.c b/arch/m68k/68000/timers.c > index 252455bce144..71

Re: [PATCH] m68k: Fix calendar month regression on M68328

een queued > by Geert. Should this patch be pushed together with that one > (presuming your ack)? Sorry for the inconvenience. If Geert is happy to add it to his tree that would seem to make sense. Otherwise I can take it via the m68knommu tree. Either way: Acked-by: Greg Ungerer Regard

Re: [PATCH] m68k: Remove read_persistent_clock()

On 23/04/18 21:47, Arnd Bergmann wrote: On Mon, Apr 23, 2018 at 11:47 AM, Geert Uytterhoeven wrote: Hi Arnd, On Mon, Apr 23, 2018 at 11:28 AM, Arnd Bergmann wrote: On Mon, Apr 23, 2018 at 11:07 AM, Geert Uytterhoeven wrote: On

Re: [PATCH] m68k: Remove read_persistent_clock()

On 23/04/18 21:47, Arnd Bergmann wrote: On Mon, Apr 23, 2018 at 11:47 AM, Geert Uytterhoeven wrote: Hi Arnd, On Mon, Apr 23, 2018 at 11:28 AM, Arnd Bergmann wrote: On Mon, Apr 23, 2018 at 11:07 AM, Geert Uytterhoeven wrote: On Fri, Apr 20, 2018 at 5:22 PM, Arnd Bergmann wrote: On Thu,

Re: [PATCH -next] m68k: fix return value check in mcf_pci_init()

Hi Wei, On 18/04/18 23:57, Wei Yongjun wrote: > In case of error, the function ioremap() returns NULL pointer not > ERR_PTR(). The IS_ERR() test in the return value check should be > replaced with NULL test. > > Fixes: bf114d773167 ("m68k: force use of __raw_read/__raw_write address to be >

Re: [PATCH -next] m68k: fix return value check in mcf_pci_init()

Hi Wei, On 18/04/18 23:57, Wei Yongjun wrote: > In case of error, the function ioremap() returns NULL pointer not > ERR_PTR(). The IS_ERR() test in the return value check should be > replaced with NULL test. > > Fixes: bf114d773167 ("m68k: force use of __raw_read/__raw_write address to be >

[git pull] m68knommu changes for v4.17

for platform FEC ethernets (2018-03-28 22:27:09 +1000) Greg Ungerer (1): m68k: set dma and coherent masks for platform FEC ethernets arch/m68k/coldfire/device.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-)

[git pull] m68knommu changes for v4.17

for platform FEC ethernets (2018-03-28 22:27:09 +1000) Greg Ungerer (1): m68k: set dma and coherent masks for platform FEC ethernets arch/m68k/coldfire/device.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-)

Re: Removing architectures without upstream gcc support

On 24/02/18 03:10, Guenter Roeck wrote: On Fri, Feb 23, 2018 at 03:43:16PM +, Alan Cox wrote: Regarding the older architectures I mentioned (m32r, frv, mn10300), the situation is a bit different as they don't have the problems with build testing but they do have problems with using less of

Re: Removing architectures without upstream gcc support

On 24/02/18 03:10, Guenter Roeck wrote: On Fri, Feb 23, 2018 at 03:43:16PM +, Alan Cox wrote: Regarding the older architectures I mentioned (m32r, frv, mn10300), the situation is a bit different as they don't have the problems with build testing but they do have problems with using less of

Re: [PATCH net 1/4] net/8390: Remove redundant make dependencies

is patch has no effect on the module binaries. > > The superfluous additions of 8390.o were introduced in > commit 644570b83026 ("8390: Move the 8390 related drivers"). > > Cc: Greg Ungerer <g...@linux-m68k.org> Looks right for mcf8390.c. Acked-by: Greg Ungerer <g...@linu

Re: [PATCH net 1/4] net/8390: Remove redundant make dependencies

is patch has no effect on the module binaries. > > The superfluous additions of 8390.o were introduced in > commit 644570b83026 ("8390: Move the 8390 related drivers"). > > Cc: Greg Ungerer Looks right for mcf8390.c. Acked-by: Greg Ungerer Regards Greg > Cc: Geert

[git pull] m68knommu fixes for v4.15

compilation (2017-12-04 22:36:43 +1000) Angelo Dureghello (1): m68k/defconfig: fix stmark2 broken local compilation Greg Ungerer (1): m68k: add missing SOFTIRQENTRY_TEXT linker section arch/m68k/configs

[git pull] m68knommu fixes for v4.15

compilation (2017-12-04 22:36:43 +1000) Angelo Dureghello (1): m68k/defconfig: fix stmark2 broken local compilation Greg Ungerer (1): m68k: add missing SOFTIRQENTRY_TEXT linker section arch/m68k/configs

Re: [PATCH] m68k: add missing SOFTIRQENTRY_TEXT linker section

Hi Geert, On 14/11/17 18:11, Geert Uytterhoeven wrote: On Tue, Nov 14, 2017 at 7:04 AM, Greg Ungerer <g...@linux-m68k.org> wrote: Commit be7635e7287e ("arch, ftrace: for KASAN put hard/soft IRQ entries into separate sections") added a new linker section, SOFTIRQENTRY_TEX

Re: [PATCH] m68k: add missing SOFTIRQENTRY_TEXT linker section

Hi Geert, On 14/11/17 18:11, Geert Uytterhoeven wrote: On Tue, Nov 14, 2017 at 7:04 AM, Greg Ungerer wrote: Commit be7635e7287e ("arch, ftrace: for KASAN put hard/soft IRQ entries into separate sections") added a new linker section, SOFTIRQENTRY_TEXT, to the linker script

[git pull] m68knommu changes for v4.15

support (2017-11-07 13:27:38 +1000) Alexandre Belloni (1): m68k: pull mach_beep in setup.c Angelo Dureghello (2): m68k: coldfire: add dspi0 module support m68k: add Sysam stmark2 open board support Greg Ungerer (3

[git pull] m68knommu changes for v4.15

support (2017-11-07 13:27:38 +1000) Alexandre Belloni (1): m68k: pull mach_beep in setup.c Angelo Dureghello (2): m68k: coldfire: add dspi0 module support m68k: add Sysam stmark2 open board support Greg Ungerer (3

Re: [PATCH] m68k: pull mach_beep in setup.c

Hi Alexandre, On 28/09/17 19:44, Alexandre Belloni wrote: > It is possible to select INPUT_M68K_BEEP in a nommu configuration. This > results in the following link error: > > drivers/input/misc/m68kspkr.o: In function `m68kspkr_event': > m68kspkr.c:(.text+0x3a): undefined reference to

Re: [PATCH] m68k: pull mach_beep in setup.c

Hi Alexandre, On 28/09/17 19:44, Alexandre Belloni wrote: > It is possible to select INPUT_M68K_BEEP in a nommu configuration. This > results in the following link error: > > drivers/input/misc/m68kspkr.o: In function `m68kspkr_event': > m68kspkr.c:(.text+0x3a): undefined reference to

[git pull] m68knommu changes for v4.14

Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only 2 changes. One removes unused code, the other makes local clock code arguments consistent with generic clock code. Regards Greg The following changes since commit cc4a41fe5541a73019a864883297bd5043aa6d98: Linux

[git pull] m68knommu changes for v4.14

Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only 2 changes. One removes unused code, the other makes local clock code arguments consistent with generic clock code. Regards Greg The following changes since commit cc4a41fe5541a73019a864883297bd5043aa6d98: Linux

Re: [PATCH] input: misc: don't build m68kspkr when mach_beep is undefined

Hi Geert, Dmitry, Alexandre, On 29/08/17 03:15, Geert Uytterhoeven wrote: > On Mon, Aug 28, 2017 at 6:50 PM, Dmitry Torokhov > wrote: >> On Thu, Aug 24, 2017 at 04:44:27PM +0200, Alexandre Belloni wrote: >>> mach_beep is defined arch/m68k/kernel/setup_mm.c which is

Re: [PATCH] input: misc: don't build m68kspkr when mach_beep is undefined

Hi Geert, Dmitry, Alexandre, On 29/08/17 03:15, Geert Uytterhoeven wrote: > On Mon, Aug 28, 2017 at 6:50 PM, Dmitry Torokhov > wrote: >> On Thu, Aug 24, 2017 at 04:44:27PM +0200, Alexandre Belloni wrote: >>> mach_beep is defined arch/m68k/kernel/setup_mm.c which is compiled only >>> when MMU is

Re: [PATCH] m68knommu: remove dead code

Hi Alexandre, On 25/08/17 00:34, Alexandre Belloni wrote: > As CONFIG_RTC_DRV_M5441x doesn't exist because the driver never made it > upstream, there is no device to register. Remove code that is never > compiled and init_BSP() as it doesn't do anything. > > Signed-off-by: Alexandre Belloni

Re: [PATCH] m68knommu: remove dead code

Hi Alexandre, On 25/08/17 00:34, Alexandre Belloni wrote: > As CONFIG_RTC_DRV_M5441x doesn't exist because the driver never made it > upstream, there is no device to register. Remove code that is never > compiled and init_BSP() as it doesn't do anything. > > Signed-off-by: Alexandre Belloni

Re: [PATCH 4/9] m68k: allow NULL clock for clk_get_rate

Hi Jonas, On 19/07/17 19:06, Jonas Gorski wrote: Hi Greg, On 18 July 2017 at 14:03, Greg Ungerer <g...@linux-m68k.org> wrote: Hi Jonas, On 18/07/17 20:17, Jonas Gorski wrote: Make the behaviour of clk_get_rate consistent with common clk's clk_get_rate by accepting NULL clocks as par

Re: [PATCH 4/9] m68k: allow NULL clock for clk_get_rate

Hi Jonas, On 19/07/17 19:06, Jonas Gorski wrote: Hi Greg, On 18 July 2017 at 14:03, Greg Ungerer wrote: Hi Jonas, On 18/07/17 20:17, Jonas Gorski wrote: Make the behaviour of clk_get_rate consistent with common clk's clk_get_rate by accepting NULL clocks as parameter. Some device drivers

Re: [PATCH 4/9] m68k: allow NULL clock for clk_get_rate

c clk infrastructure") Cc: Greg Ungerer <g...@linux-m68k.org> Acked-by: Greg Ungerer <g...@linux-m68k.org> Do you want me to push this via the m68knommu git tree? Or are you (or someone) taking the series as a whole? Regards Greg Cc: Geert Uytterhoeven <ge...@linux-m68k.org>

Re: [PATCH 4/9] m68k: allow NULL clock for clk_get_rate

c clk infrastructure") Cc: Greg Ungerer Acked-by: Greg Ungerer Do you want me to push this via the m68knommu git tree? Or are you (or someone) taking the series as a whole? Regards Greg Cc: Geert Uytterhoeven Cc: linux-m...@lists.linux-m68k.org Cc: linux-kernel@vger.kernel.org Reported-b

[git pull] m68knommu changes for v4.13

Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only a single change, to remove old Kconfig options from defconfigs. Regards Greg The following changes since commit c0bc126f97fb929b3ae02c1c62322645d70eb408: Linux 4.12-rc7 (2017-06-25 18:30:05 -0700) are available

[git pull] m68knommu changes for v4.13

Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only a single change, to remove old Kconfig options from defconfigs. Regards Greg The following changes since commit c0bc126f97fb929b3ae02c1c62322645d70eb408: Linux 4.12-rc7 (2017-06-25 18:30:05 -0700) are available

Re: [PATCH 08/18] m68k: coldfire: Move inline before return type

On 06/07/17 06:02, Joe Perches wrote: > Make the code like the rest of the kernel. > > Signed-off-by: Joe Perches <j...@perches.com> Acked-by: Greg Ungerer <g...@linux-m68k.org> > --- > arch/m68k/coldfire/intc-simr.c | 4 ++-- > 1 file changed, 2 insertions(+),

Re: [PATCH 08/18] m68k: coldfire: Move inline before return type

On 06/07/17 06:02, Joe Perches wrote: > Make the code like the rest of the kernel. > > Signed-off-by: Joe Perches Acked-by: Greg Ungerer > --- > arch/m68k/coldfire/intc-simr.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/m68k/col

Re: [PATCH 18/35] m68k: defconfig: Cleanup from old Kconfig options

Hi Krzyszto, On 09/06/17 02:10, Krzysztof Kozlowski wrote: > Remove old, dead Kconfig option INET_LRO. It is gone since > commit 7bbf3cae65b6 ("ipv4: Remove inet_lro library"). > > Signed-off-by: Krzysztof Kozlowski I will take that via the m68knommu git tree. Thanks. Its in

Re: [PATCH 18/35] m68k: defconfig: Cleanup from old Kconfig options

Hi Krzyszto, On 09/06/17 02:10, Krzysztof Kozlowski wrote: > Remove old, dead Kconfig option INET_LRO. It is gone since > commit 7bbf3cae65b6 ("ipv4: Remove inet_lro library"). > > Signed-off-by: Krzysztof Kozlowski I will take that via the m68knommu git tree. Thanks. Its in the for-next

Re: [PATCH] m68k/coldfire/pit: set ->min_delta_ticks and ->max_delta_ticks

> clockevents core still looks exclusively at the (untouched) ->min_delta_ns > and ->max_delta_ns. As soon as this has changed, a followup patch will > purge the initialization of ->min_delta_ns and ->max_delta_ns from this > driver. > > Signed-off-by: Nicolai Stange <nicsta.

Re: [PATCH] m68k/coldfire/pit: set ->min_delta_ticks and ->max_delta_ticks

> clockevents core still looks exclusively at the (untouched) ->min_delta_ns > and ->max_delta_ns. As soon as this has changed, a followup patch will > purge the initialization of ->min_delta_ns and ->max_delta_ns from this > driver. > > Signed-off-by: Nicolai Stange Looks ok to m

Re: [PATCH] ARM: nommu: access ID_PFR1 only if CPUID scheme

processors need not have processor feature registers, only for architectures defined by CPUID scheme would have it. Hence check for it before accessing processor feature register, ID_PFR1. Fixes: f8300a0b5de0 ("ARM: 8647/2: nommu: dynamic exception base address setting") Reported-by: Gr

Re: [PATCH] ARM: nommu: access ID_PFR1 only if CPUID scheme

processors need not have processor feature registers, only for architectures defined by CPUID scheme would have it. Hence check for it before accessing processor feature register, ID_PFR1. Fixes: f8300a0b5de0 ("ARM: 8647/2: nommu: dynamic exception base address setting") Reported-by: Gr

[git pull] m68knommu changes for v4.11

Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only a single change, to update the amcore board defconfig. Regards Greg The following changes since commit 7089db84e356562f8ba737c29e472cc42d530dbc: Linux 4.10-rc8 (2017-02-12 13:03:20 -0800) are available in the git

[git pull] m68knommu changes for v4.11

Hi Linus, Can you please pull the m68knommu git tree, for-next branch. Only a single change, to update the amcore board defconfig. Regards Greg The following changes since commit 7089db84e356562f8ba737c29e472cc42d530dbc: Linux 4.10-rc8 (2017-02-12 13:03:20 -0800) are available in the git

Re: regression for m68k/coldfire

Hi Laurent, On 04/02/17 19:49, Laurent Vivier wrote: Le 04/02/2017 à 03:03, Greg Ungerer a écrit : Hi Laurent, On 04/02/17 01:22, Laurent Vivier wrote: Le 03/02/2017 à 16:17, Waldemar Brodkorb a écrit : [snip] Btw: Laurent, are you m68k with mmu support are going to be included upstream? I

Re: regression for m68k/coldfire

Hi Laurent, On 04/02/17 19:49, Laurent Vivier wrote: Le 04/02/2017 à 03:03, Greg Ungerer a écrit : Hi Laurent, On 04/02/17 01:22, Laurent Vivier wrote: Le 03/02/2017 à 16:17, Waldemar Brodkorb a écrit : [snip] Btw: Laurent, are you m68k with mmu support are going to be included upstream? I

Re: regression for m68k/coldfire

Hi Laurent, On 04/02/17 01:22, Laurent Vivier wrote: Le 03/02/2017 à 16:17, Waldemar Brodkorb a écrit : [snip] Btw: Laurent, are you m68k with mmu support are going to be included upstream? I always carry an old binary for any m68k with mmu testing. I'm working to have the FPU included for

Re: regression for m68k/coldfire

Hi Laurent, On 04/02/17 01:22, Laurent Vivier wrote: Le 03/02/2017 à 16:17, Waldemar Brodkorb a écrit : [snip] Btw: Laurent, are you m68k with mmu support are going to be included upstream? I always carry an old binary for any m68k with mmu testing. I'm working to have the FPU included for

Re: regression for m68k/coldfire

Hi Waldemar, On 03/02/17 06:15, Waldemar Brodkorb wrote: > your commit 80cca775cdc4f8555612d2943a2872076b33e0ff breaks Linux > booting in qemu-system-m68k: > > qemu-system-m68k -nographic -M mcf5208evb -cpu m5208 -kernel > qemu-m68k-mcf5208-initramfspiggyback-kernel [snip] > [3.46]

Re: regression for m68k/coldfire

Hi Waldemar, On 03/02/17 06:15, Waldemar Brodkorb wrote: > your commit 80cca775cdc4f8555612d2943a2872076b33e0ff breaks Linux > booting in qemu-system-m68k: > > qemu-system-m68k -nographic -M mcf5208evb -cpu m5208 -kernel > qemu-m68k-mcf5208-initramfspiggyback-kernel [snip] > [3.46]

Re: [PATCH 2/2] m68k: replaced gcc specific macros with ones from compiler.h

This patch depends on the previous with changes in > /include/linux/compiler-gcc.h > > Signed-off-by: Gideon Israel Dsouza <gidisr...@gmail.com> Acked-by: Greg Ungerer <g...@linux-m68k.org> Regards Greg > --- > arch/m68k/68000/bootlogo-vz.h | 4 +++- > arch/m6

Re: [PATCH 2/2] m68k: replaced gcc specific macros with ones from compiler.h

This patch depends on the previous with changes in > /include/linux/compiler-gcc.h > > Signed-off-by: Gideon Israel Dsouza Acked-by: Greg Ungerer Regards Greg > --- > arch/m68k/68000/bootlogo-vz.h | 4 +++- > arch/m68k/68000/bootlogo.h| 4 +++- > arch/m68k/inclu

Re: [PATCH] m68k: Replaced all gcc specific macros with macros from compiler.h

Hi Gideon, On 17/01/17 19:39, Gideon Israel Dsouza wrote: > There is which provides macros for various gcc specific > constructs. Eg: __weak for __attribute__((weak)). I've cleaned all > instances of gcc specific attributes with the right macros for all files > under /arch/m68k There is a lot

Re: [PATCH] m68k: Replaced all gcc specific macros with macros from compiler.h

Hi Gideon, On 17/01/17 19:39, Gideon Israel Dsouza wrote: > There is which provides macros for various gcc specific > constructs. Eg: __weak for __attribute__((weak)). I've cleaned all > instances of gcc specific attributes with the right macros for all files > under /arch/m68k There is a lot

[git pull] m68knommu changes for v4.10

Hi Linus, Can you please pull the m68knommu git tree, for-next branch. There are two sets of changes in this pull. The largest is the addition of the ColdFire platform side i2c support (the IO addressing, setup and clock definitions). The i2c hardware module itself is driven by the kernels

[git pull] m68knommu changes for v4.10

Hi Linus, Can you please pull the m68knommu git tree, for-next branch. There are two sets of changes in this pull. The largest is the addition of the ColdFire platform side i2c support (the IO addressing, setup and clock definitions). The i2c hardware module itself is driven by the kernels

Re: [PATCH 06/22] m68k/coldfire: Modernize printing of kernel messages

Hi Finn, Geert, On 08/12/16 08:53, Finn Thain wrote: On Wed, 7 Dec 2016, Geert Uytterhoeven wrote: - Introduce helpers for printing debug messages, incl. dummies for validating format strings when debugging is disabled, - Convert from printk() to pr_*(), - Correct printf()-style

Re: [PATCH 06/22] m68k/coldfire: Modernize printing of kernel messages

Hi Finn, Geert, On 08/12/16 08:53, Finn Thain wrote: On Wed, 7 Dec 2016, Geert Uytterhoeven wrote: - Introduce helpers for printing debug messages, incl. dummies for validating format strings when debugging is disabled, - Convert from printk() to pr_*(), - Correct printf()-style

Re: [PATCH 04/22] m68k/68000: Modernize printing of kernel messages

Hi Geert, On 08/12/16 01:09, Geert Uytterhoeven wrote: Convert from printk() to pr_*(). Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org> Looks good to me, so: Acked-by: Greg Ungerer <g...@linux-m68k.org> Regards Greg --- arch/m68k/68000/m68328.c | 6 +++--- arc

Re: [PATCH 04/22] m68k/68000: Modernize printing of kernel messages

Hi Geert, On 08/12/16 01:09, Geert Uytterhoeven wrote: Convert from printk() to pr_*(). Signed-off-by: Geert Uytterhoeven Looks good to me, so: Acked-by: Greg Ungerer Regards Greg --- arch/m68k/68000/m68328.c | 6 +++--- arch/m68k/68000/m68EZ328.c | 6 +++--- arch/m68k/68000

[git pull] m68knommu changes for v4.9

up to 742859adc721da65ff4e8b59412d73bd3d2a57fe: m68k: let clk_disable() return immediately if clk is NULL (2016-09-26 12:02:59 +1000) Greg Ungerer (14): m68knommu: fix early setup to not access variables m68knommu

[git pull] m68knommu changes for v4.9

up to 742859adc721da65ff4e8b59412d73bd3d2a57fe: m68k: let clk_disable() return immediately if clk is NULL (2016-09-26 12:02:59 +1000) Greg Ungerer (14): m68knommu: fix early setup to not access variables m68knommu

Re: [PATCH v4] m68k: let clk_disable() return immediately if clk is NULL

L pointer check. > > Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com> > Acked-by: Greg Ungerer <g...@uclinux.org> I will apply to my m68knommu git tree (for-next) branch. Thanks Greg > --- > > Changes in v4: > - Split into per-arch patches > >

Re: [PATCH v4] m68k: let clk_disable() return immediately if clk is NULL

L pointer check. > > Signed-off-by: Masahiro Yamada > Acked-by: Greg Ungerer I will apply to my m68knommu git tree (for-next) branch. Thanks Greg > --- > > Changes in v4: > - Split into per-arch patches > > Changes in v3: > - Return only when clk is NULL. Do not t

[git pull] m68knommu changes for v4.8-rc1

) Greg Ungerer (1): m68knommu: fix user a5 register being overwritten arch/m68k/kernel/signal.c | 1 - 1 file changed, 1 deletion(-)

[git pull] m68knommu changes for v4.8-rc1

) Greg Ungerer (1): m68knommu: fix user a5 register being overwritten arch/m68k/kernel/signal.c | 1 - 1 file changed, 1 deletion(-)

[git pull] m68knommu changes for v4.8

/kernel/git/gerg/m68knommu.git for-linus for you to fetch changes up to 002d2f01f13f1671d771e1493a3405ed4986694d: m68k: enable binfmt_flat on systems with an MMU (2016-07-28 13:29:13 +1000) Greg Ungerer (3): m68k: fix bFLT

[git pull] m68knommu changes for v4.8

/kernel/git/gerg/m68knommu.git for-linus for you to fetch changes up to 002d2f01f13f1671d771e1493a3405ed4986694d: m68k: enable binfmt_flat on systems with an MMU (2016-07-28 13:29:13 +1000) Greg Ungerer (3): m68k: fix bFLT

Re: [PATCH v5 00/15] allow BFLT executables on systems with a MMU

gt; > And while elf_fdpic binaries can run on MMU systems, flat binaries still > couldn't, which just felt wrong. > > So here it is. The no-MMU support should remain unaffected, confirmed by > Greg Ungerer. Tested with MMU on ARM and M68K. > > Changes since v4: > > -

Re: [PATCH v5 00/15] allow BFLT executables on systems with a MMU

gt; > And while elf_fdpic binaries can run on MMU systems, flat binaries still > couldn't, which just felt wrong. > > So here it is. The no-MMU support should remain unaffected, confirmed by > Greg Ungerer. Tested with MMU on ARM and M68K. > > Changes since v4: > > -

Re: [PATCH v4 00/12] allow BFLT executables on systems with a MMU

On 22/07/16 00:48, Nicolas Pitre wrote: > On Thu, 21 Jul 2016, Greg Ungerer wrote: >> Hi Nicolas, >> >> On 21/07/16 05:22, Nicolas Pitre wrote: >>> This series provides the necessary changes to allow "flat" executable >>> binaries meant for no-

Re: [PATCH v4 00/12] allow BFLT executables on systems with a MMU

On 22/07/16 00:48, Nicolas Pitre wrote: > On Thu, 21 Jul 2016, Greg Ungerer wrote: >> Hi Nicolas, >> >> On 21/07/16 05:22, Nicolas Pitre wrote: >>> This series provides the necessary changes to allow "flat" executable >>> binaries meant for no-

Re: [PATCH v4 00/12] allow BFLT executables on systems with a MMU

use this to support GOT/PIC flat built application code. Fix this so that D5 is always setup when loading/running a bFLT executable on m68k systems. Signed-off-by: Greg Ungerer <g...@linux-m68k.org> --- arch/m68k/include/asm/flat.h | 6 ++ arch/m68k/include/asm/processor.h |

Re: [PATCH v4 00/12] allow BFLT executables on systems with a MMU

use this to support GOT/PIC flat built application code. Fix this so that D5 is always setup when loading/running a bFLT executable on m68k systems. Signed-off-by: Greg Ungerer --- arch/m68k/include/asm/flat.h | 6 ++ arch/m68k/include/asm/processor.h | 2 -- 2 files changed, 6 inserti

Re: [PATCH v2 01/10] binfmt_flat: assorted cleanups

Hi Geert, On 20/07/16 16:54, Geert Uytterhoeven wrote: > Hi Nicolas, > > On Wed, Jul 20, 2016 at 6:09 AM, Nicolas Pitre <nicolas.pi...@linaro.org> > wrote: >> On Tue, 19 Jul 2016, Geert Uytterhoeven wrote: >> >>> On Tue, Jul 19, 2016 at 6:52 AM, G

Re: [PATCH v2 01/10] binfmt_flat: assorted cleanups

Hi Geert, On 20/07/16 16:54, Geert Uytterhoeven wrote: > Hi Nicolas, > > On Wed, Jul 20, 2016 at 6:09 AM, Nicolas Pitre > wrote: >> On Tue, 19 Jul 2016, Geert Uytterhoeven wrote: >> >>> On Tue, Jul 19, 2016 at 6:52 AM, Greg Ungerer wrote: >>>> S

Re: [PATCH v3 09/12] binfmt_flat: use clear_user() rather than memset() to clear .bss

On 20/07/16 14:20, Nicolas Pitre wrote: > This is needed on systems with a MMU. > > Signed-off-by: Nicolas Pitre <n...@linaro.org> > Reviewed-by: Greg Ungerer <g...@linux-m68k.org> > --- > fs/binfmt_flat.c | 5 +++-- > 1 file changed, 3 insertions(+), 2

Re: [PATCH v3 09/12] binfmt_flat: use clear_user() rather than memset() to clear .bss

On 20/07/16 14:20, Nicolas Pitre wrote: > This is needed on systems with a MMU. > > Signed-off-by: Nicolas Pitre > Reviewed-by: Greg Ungerer > --- > fs/binfmt_flat.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/fs/binfmt_flat.c

Re: [PULL REQUEST] [PATCH v2 00/10] allow BFLT executables on systems with a MMU

. I had a look over the patches and I didn't see any specific problems. So from me: Reviewed-by: Greg Ungerer <g...@linux-m68k.org> When I get a minute I'll dig a little into that bflat running on MMU problem on ColdFire. Regards Greg > Changes since v1: > > - Re

Re: [PULL REQUEST] [PATCH v2 00/10] allow BFLT executables on systems with a MMU

. I had a look over the patches and I didn't see any specific problems. So from me: Reviewed-by: Greg Ungerer When I get a minute I'll dig a little into that bflat running on MMU problem on ColdFire. Regards Greg > Changes since v1: > > - Removed SuperH and Xtensa from the Kconfig ru

Re: [PATCH v2 01/10] binfmt_flat: assorted cleanups

Hi Nicolas, On 18/07/16 13:31, Nicolas Pitre wrote: > Remove excessive casts, do some code grouping, etc. > No functional changes. > > Signed-off-by: Nicolas Pitre > --- > fs/binfmt_flat.c | 118 > ++- > 1 file changed, 56

Re: [PATCH v2 01/10] binfmt_flat: assorted cleanups

Hi Nicolas, On 18/07/16 13:31, Nicolas Pitre wrote: > Remove excessive casts, do some code grouping, etc. > No functional changes. > > Signed-off-by: Nicolas Pitre > --- > fs/binfmt_flat.c | 118 > ++- > 1 file changed, 56 insertions(+), 62

[git pull] m68knommu changes

) Greg Ungerer (1): m68k: change m68knommu maintainer email address MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

[git pull] m68knommu changes

) Greg Ungerer (1): m68k: change m68knommu maintainer email address MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

Re: qemu m68k/mcf5208: problem with signal handler

Hi Waldemar, On 09/05/16 18:58, Waldemar Brodkorb wrote: Hi, forgot to add Greg in CC. And sorry for the whitespace fuckup in the example code. Waldemar Brodkorb wrote, Dear kernel hackers, I have a problem with the signal handling under qemu-system-m68k emulating coldfire mcf5208

Re: qemu m68k/mcf5208: problem with signal handler

Hi Waldemar, On 09/05/16 18:58, Waldemar Brodkorb wrote: Hi, forgot to add Greg in CC. And sorry for the whitespace fuckup in the example code. Waldemar Brodkorb wrote, Dear kernel hackers, I have a problem with the signal handling under qemu-system-m68k emulating coldfire mcf5208

[git pull] m68knommu/coldfire fixes

device (2016-04-11 12:03:18 +1000) Greg Ungerer (1): m68k/gpio: remove arch specific sysfs bus device arch/m68k/coldfire/gpio.c | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-)

[git pull] m68knommu/coldfire fixes

device (2016-04-11 12:03:18 +1000) Greg Ungerer (1): m68k/gpio: remove arch specific sysfs bus device arch/m68k/coldfire/gpio.c | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-)

Re: [PATCH] m68k/gpio: remove arch specific sysfs bus device

On 06/04/16 16:57, Linus Walleij wrote: On Wed, Apr 6, 2016 at 4:32 AM, Greg Ungerer <g...@uclinux.org> wrote: From: Greg Ungerer <gerg@gumby.(none)> The ColdFire architecture specific gpio support code registers a sysfs bus device named "gpio". This clashes with the

Re: [PATCH] m68k/gpio: remove arch specific sysfs bus device

On 06/04/16 16:57, Linus Walleij wrote: On Wed, Apr 6, 2016 at 4:32 AM, Greg Ungerer wrote: From: Greg Ungerer The ColdFire architecture specific gpio support code registers a sysfs bus device named "gpio". This clashes with the new generic API device added in commit 3c702e99 (

[PATCH] m68k/gpio: remove arch specific sysfs bus device

From: Greg Ungerer <gerg@gumby.(none)> The ColdFire architecture specific gpio support code registers a sysfs bus device named "gpio". This clashes with the new generic API device added in commit 3c702e99 ("gpio: add a userspace chardev ABI for GPIOs"). The old

[PATCH] m68k/gpio: remove arch specific sysfs bus device

From: Greg Ungerer The ColdFire architecture specific gpio support code registers a sysfs bus device named "gpio". This clashes with the new generic API device added in commit 3c702e99 ("gpio: add a userspace chardev ABI for GPIOs"). The old ColdFire sysfs gpio d

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

Hi Linus, On 01/04/16 18:16, Linus Walleij wrote: On Fri, Apr 1, 2016 at 3:33 AM, Greg Ungerer <gregunge...@westnet.com.au> wrote: On 01/04/16 10:53, Guenter Roeck wrote: Probably coldfire ? arch/m68k/coldfire/gpio.c: Yes, that is the one. static struct bus_type mcfgpio_

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

Hi Linus, On 01/04/16 18:16, Linus Walleij wrote: On Fri, Apr 1, 2016 at 3:33 AM, Greg Ungerer wrote: On 01/04/16 10:53, Guenter Roeck wrote: Probably coldfire ? arch/m68k/coldfire/gpio.c: Yes, that is the one. static struct bus_type mcfgpio_subsys = { .name = "

<    1   2   3   4   5   6   7   8   9   >