On 17/4/21 2:54 pm, Damien Le Moal wrote:
On 2021/04/17 13:52, Greg Ungerer wrote:
On 17/4/21 11:10 am, Damien Le Moal wrote:
Commit 2217b9826246 ("binfmt_flat: revert "binfmt_flat: don't offset
the data start"") restored offsetting the start of the data section
automatically when CONFIG_RISCV is enabled and CONFIG_MMU is disabled.
Signed-off-by: Damien Le Moal
Acked-by: Palmer Dabbelt
Acked-by: Greg Ungerer
Palmer do you want me to take this via my tree with 1/2 in the series,
or are you going to pick it up?
Regards
Greg
---
arch/riscv/Kconfig
ra +
- MAX_SHARED_LIBS * sizeof(u32));
+ DATA_START_OFFSET_WORDS * sizeof(u32));
goto err;
}
}
Thanks, otherwise looks good.
Acked-by: Greg Ungerer
I will push this into my m68knommu tree, for-next branch.
On 16/4/21 10:26 am, Damien Le Moal wrote:
On 2021/04/16 9:22, Al Viro wrote:
On Thu, Apr 15, 2021 at 07:56:05AM +0200, Christoph Hellwig wrote:
binfmt_flat tends to go through Greg's uclinux tree, adding him and
the list.
FWIW, my involvement with binfmt_flat had been pretty much
On 16/4/21 9:22 am, Damien Le Moal wrote:
On 2021/04/15 23:04, Greg Ungerer wrote:
Hi Damien,
On 15/4/21 4:15 pm, Damien Le Moal wrote:
Commit 2217b9826246 ("binfmt_flat: revert "binfmt_flat: don't offset
the data start"") restored offsetting the start of the data
Hi Damien,
On 15/4/21 4:15 pm, Damien Le Moal wrote:
Commit 2217b9826246 ("binfmt_flat: revert "binfmt_flat: don't offset
the data start"") restored offsetting the start of the data section by
a number of words defined by MAX_SHARED_LIBS. As a result, since
MAX_SHARED_LIBS is never 0, a gap
Hi Linus,
Please pull the m68knommu tree for-linus branch.
It contains a single regression fix.
Some m68k platforms with non-zero memory base fail to boot
with recent flatmem changes.
Sorry for getting this to you so late.
I have been out on vacation and this slipped through the cracks.
+0xdc/0xec
arch_call_rest_init+0x1c/0x28
start_kernel+0x4ac/0x4e4
Code: 91392021 912c2000 d377d8c6 97f24d96 (d421)
Cc: # v4.10+
Fixes: 8126d88162a5 ("arm64: dts: add QorIQ LS1046A SoC support")
Link:
https://lore.kernel.org/linux-crypto/fe6faa24-d8f7-d18f-adfa-44fa0caa1...@arm.com
Repor
Hi Linus,
Please pull the m68knommu changes for v5.12.
Only a single change. NULL parameter check in the local ColdFire
clocking code.
Regards
Greg
The following changes since commit 92bf22614b21a2706f4993b278017e437f7785b3:
Linux 5.11-rc7 (2021-02-07 13:57:38 -0800)
are available in
stead of the
"void *" domain.
Note that for now this is only seen when compiling btrfs, due to commit
e9aa7c285d20a69c ("btrfs: enable W=1 checks for btrfs"), but as people
are doing more W=1 compile testing, it will start to show up elsewhere,
too.
Signed-off-by: Geert Uytterho
Hi Geert,
On 17/2/21 9:42 pm, Geert Uytterhoeven wrote:
Hi Greg,
On Wed, Feb 17, 2021 at 5:59 AM Greg Ungerer wrote:
On 12/2/21 8:05 pm, Arnd Bergmann wrote:
On Fri, Feb 12, 2021 at 6:48 AM kernel test robot wrote:
FYI, the error/warning still remains
Hi Arnd,
On 12/2/21 8:05 pm, Arnd Bergmann wrote:
On Fri, Feb 12, 2021 at 6:48 AM kernel test robot wrote:
FYI, the error/warning still remains.
| ^~~~
arch/m68k/68000/dragen2.c: In function 'init_dragen2':
arch/m68k/68000/dragen2.c:73:16: error:
Hi Defang,
On 28/12/20 12:07 pm, Defang Bo wrote:
Similar to commit<742859adc721>("m68k: let clk_disable() return immediately if clk
is NULL").
there should be a check for clk to prevent NULL pointer dereference.
Signed-off-by: Defang Bo
I have applied this to the m68knommu git tree,
On 11/1/21 7:36 pm, Geert Uytterhoeven wrote:
Hi Adrian,
On Mon, Jan 11, 2021 at 10:26 AM John Paul Adrian Glaubitz
wrote:
On 1/11/21 10:20 AM, Geert Uytterhoeven wrote:
Sounds interesting. Do these SoCs come with an MMU? And do they use the
ColdFire instruction set or do they run plain
Hi John,
On 7/1/21 7:02 pm, John Ogness wrote:
On 2021-01-06, Vineet Gupta wrote:
This breaks ARC booting (no output on console).
Could you provide the kernel boot arguments that you use? This series is
partly about addressing users that have used boot arguments that are
technically
to 32bit
Arnd Bergmann (2):
m68k: m68328: move platform code to separate files
m68k: m68328: remove duplicate code
Greg Ungerer (1):
m68knommu: align BSS section to 4-byte boundaries
arch/m68k/68000/Makefile
On 31/10/20 12:26 am, Arnd Bergmann wrote:
From: Arnd Bergmann
The dragen2 and ucsimm/ucdimm files require a bit of
custom code compared to the other dragonball platforms,
move them into separate files as a preparation for a
build fix.
Signed-off-by: Arnd Bergmann
---
Just a small cleanup
Hi Arnd,
On 31/10/20 12:25 am, Arnd Bergmann wrote:
On Mon, Oct 19, 2020 at 2:06 PM Arnd Bergmann wrote:
On Mon, Oct 19, 2020 at 1:45 AM Greg Ungerer wrote:
On 15/10/20 10:32 pm, Arnd Bergmann wrote:
diff --git a/arch/m68k/Kconfig.machine b/arch/m68k/Kconfig.machine
index 17e8c3a292d7
On 30/10/20 10:41 am, Finn Thain wrote:
On Fri, 23 Oct 2020, Arnd Bergmann wrote:
On Sun, Oct 18, 2020 at 2:55 AM Finn Thain wrote:
On Thu, 15 Oct 2020, Arnd Bergmann wrote:
On Thu, Oct 15, 2020 at 3:19 AM Finn Thain wrote:
On Sat, 10 Oct 2020, Arnd Bergmann wrote:
That configuration
On 24/10/20 1:28 am, Krzysztof Kozlowski wrote:
On Fri, Oct 23, 2020 at 04:18:23PM +0800, peng@nxp.com wrote:
From: Peng Fan
The legacy platform device code has been removed under arch/arm/mach-imx,
so we no need id_table entry here.
Cc: Greg, Geert, Angelo,
Aren't you breaking
ldFire serial driver
Angelo Dureghello (1):
serial: mcf: add sysrq capability
Greg Ungerer (3):
m68knommu: switch to using asm-generic/uaccess.h
m68knommu: fix sparse warnings in signal code
m68knommu: include SDHC support only when hardware has it
Hi Arnd,
Overall looks good.
On 15/10/20 10:32 pm, Arnd Bergmann wrote:
[snip]
diff --git a/arch/m68k/Kconfig.cpu b/arch/m68k/Kconfig.cpu
index 694c4fca9f5d..a65ce7618232 100644
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
@@ -35,7 +35,7 @@ endchoice
if M68KCLASSIC
config
.
Signed-off-by: Arnd Bergmann
I tested this series on a couple of different ColdFire parts
(5208 and 5475) and under QEMU emulating the 5208. All checked
out good, all worked as expected. So for the ColdFire changes:
Tested-by: Greg Ungerer
Regards
Greg
---
arch/m68k/Kconfig.cpu
in commit
cddafa3500fde4a0 ("m68k/m68knommu: merge MMU and non-MMU
thread_info.h"), to avoid future nasty surprises.
Signed-off-by: Geert Uytterhoeven
Acked-by: Greg Ungerer
Regards
Greg
arch/m68k/include/asm/thread_info.h | 8
1 file changed, 8 insertions(+)
diff --git a
Hi Geert,
On 26/8/20 11:04 pm, Geert Uytterhoeven wrote:
The return type of memblock_alloc*() is a void pointer, so there is no
need to cast it to "void *" or some other pointer type, before assigning
it to a pointer variable.
Signed-off-by: Geert Uytterhoeven
Acked-by: Gr
Hi Linus,
Please pull the m68knommu changes for v5.9-rc3.
Only a single fix for the binfmt_flat loader (reverting a recent change).
Regards
Greg
The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd:
Linux 5.9-rc2 (2020-08-23 14:08:43 -0700)
are available in the Git
Hi Max,
On 9/8/20 4:37 am, Max Filippov wrote:
binfmt_flat loader uses the gap between text and data to store data
segment pointers for the libraries. Even in the absence of shared
libraries it stores at least one pointer to the executable's own data
segment. Text and data can go back to back
):
m68k: stmark2: defconfig updates
m68k: stmark2: enable edma support for dspi
Greg Ungerer (5):
m68knommu: __force type casts for raw IO access
m68knommu: fix use of cpu_to_le() on IO access
m68k: fix ColdFire mmu init compile warning
m68knommu: fix overwriting
Hi Linus,
Please pull important m68knommu fixes for v5.8-rc4
Regards
Greg
The following changes since commit 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68:
Linux 5.8-rc3 (2020-06-28 15:00:24 -0700)
are available in the Git repository at:
Hi Mike,
On 29/6/20 2:14 pm, Mike Rapoport wrote:
On Mon, Jun 29, 2020 at 11:10:16AM +1000, Greg Ungerer wrote:
On 17/6/20 10:33 pm, Greg Ungerer wrote:
On 17/6/20 4:53 pm, Mike Rapoport wrote:
From: Mike Rapoport
The m68k nommu setup code didn't register the beginning of the physical
Hi Mike,
On 17/6/20 10:33 pm, Greg Ungerer wrote:
Hi Mike,
On 17/6/20 4:53 pm, Mike Rapoport wrote:
From: Mike Rapoport
The m68k nommu setup code didn't register the beginning of the physical
memory with memblock because it was anyway occupied by the kernel. However,
commit fa3354e4ea39
-off-by: Angelo Dureghello
Signed-off-by: Mike Rapoport
Acked-by: Greg Ungerer
Regards
Greg
---
arch/m68k/mm/mcfmmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c
index 29f47923aa46..7d04210d34f0 100644
--- a/arch/m68k
ry registration with memblock to include the beginning of
the physical memory and make sure that the area occupied by the kernel is
marked as reserved.
Signed-off-by: Mike Rapoport
Acked-by: Greg Ungerer
Regards
Greg
---
arch/m68k/kernel/setup_no.c | 3 ++-
1 file changed, 2 insertions(+
Hi Mike,
On 15/6/20 6:29 pm, Mike Rapoport wrote:
(reduced the spam list)
On Mon, Jun 15, 2020 at 05:17:28PM +1000, Greg Ungerer wrote:
On 15/6/20 4:22 pm, Mike Rapoport wrote:
On Mon, Jun 15, 2020 at 01:53:42PM +1000, Greg Ungerer wrote:
From: Mike Rapoport
Currently, architectures
Hi Mike,
On 15/6/20 4:22 pm, Mike Rapoport wrote:
On Mon, Jun 15, 2020 at 01:53:42PM +1000, Greg Ungerer wrote:
From: Mike Rapoport
Currently, architectures that use free_area_init() to initialize memory map
and node and zone structures need to calculate zone and hole sizes. We can
use
On 13/6/20 2:35 am, Luc Van Oostenryck wrote:
On Sat, Jun 13, 2020 at 01:33:16AM +1000, Greg Ungerer wrote:
arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted
__le32
This one I am not sure about yet.
Still investigating.
swab32(__raw_readl(addr
Hi Mike,
From: Mike Rapoport
Currently, architectures that use free_area_init() to initialize memory map
and node and zone structures need to calculate zone and hole sizes. We can
use free_area_init_nodes() instead and let it detect the zone boundaries
while the architectures will only have to
On 13/6/20 2:35 am, Luc Van Oostenryck wrote:
On Sat, Jun 13, 2020 at 01:33:16AM +1000, Greg Ungerer wrote:
On 12/6/20 5:48 pm, Marc Kleine-Budde wrote:
I think this one is due to not forcing the volatile cast in __raw_write().
So this change will fix that:
diff --git a/arch/m68k/include/asm
Hi Marc,
On 12/6/20 5:48 pm, Marc Kleine-Budde wrote:
the k-build robot found this sparse problem, triggered by building a CAN driver
for m68k. Is this a problem in our CAN driver or in the m68k headers?
I suspect a problem with the m68k (specifically non-mmu) headers.
On 6/12/20 7:28 AM,
Hi Linus,
Please pull the m68knommu changes for v5.8.
Regards
Greg
The following changes since commit 9cb1fd0efd195590b828b9b865421ad345a4a145:
Linux 5.7-rc7 (2020-05-24 15:32:54 -0700)
are available in the Git repository at:
Hi Luc,
On 30/5/20 5:02 am, Luc Van Oostenryck wrote:
I received a bug report for an unrelated patch when used with m68k-nommu.
It appears that the origin of the problem is that __get_user() and
__put_user() doesn't handle correctly __user. These 2 patches fix this.
Note: this is only minimaly
Hi Luc,
On 29/5/20 6:25 am, Luc Van Oostenryck wrote:
The assembly for __get_user_asm() & __put_user_asm() uses memcpy()
when the size is 8.
However, the pointer is always a __user one while memcpy() expect
a plan one and so this cast creates a lot of warnings when using
Did you mean
On 26/5/20 10:38 pm, Masahiro Yamada wrote:
Use the standard obj-y form to specify the sub-directories under
arch/m68k/. No functional change intended.
Signed-off-by: Masahiro Yamada
Acked-by: Greg Ungerer
Regards
Greg
---
arch/m68k/Kbuild | 19 +++
arch/m68k
On 26/5/20 10:38 pm, Masahiro Yamada wrote:
Precisely, -D is a preprocessor option.
KBUILD_CPPFLAGS is passed to for compiling .c and .S files too.
Signed-off-by: Masahiro Yamada
Acked-by: Greg Ungerer
Regards
Greg
---
arch/m68k/Makefile | 5 ++---
1 file changed, 2 insertions
'.
Use '=' to expand the value _lazily_. The evaluation for cc-option is
delayed until $(cpuflags-y) is expanded. So, the cc-option test happens
just once at most.
This commit mimics tune-y of arch/arm/Makefile.
Signed-off-by: Masahiro Yamada
Acked-by: Greg Ungerer
Regards
Greg
Hi Christoph,
On 10/5/20 5:55 pm, Christoph Hellwig wrote:
load_flat_file works on user addresses.
Signed-off-by: Christoph Hellwig
Acked-by: Greg Ungerer
Regards
Greg
---
fs/binfmt_flat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/binfmt_flat.c b/fs
Hi Christoph,
On 10/5/20 5:54 pm, Christoph Hellwig wrote:
m68knommu needs almost no cache flushing routines of its own. Rely on
asm-generic/cacheflush.h for the defaults.
Signed-off-by: Christoph Hellwig
Acked-by: Greg Ungerer
Regards
Greg
---
arch/m68k/include/asm/cacheflush_no.h
doing the same things the same way makes exec
easier to reason about and easier to maintain.
The binfmt_flagt bits were tested by Greg Ungerer
^
flat
Regards
Greg
Ref: 9f834ec18def ("binfmt_elf: switch to new creds when switching to new mm")
Signed-off-b
(exercising binfmt_flat) and it all tested out with no problems,
so for the binfmt_flat changes:
Tested-by: Greg Ungerer
I reviewed the whole series too, and looks good to me:
Reviewed-by: Greg Ungerer
Regards
Greg
---
These changes are against v5.7-rc3.
My intention once everything passes
Hi Bin,
On 2/5/20 2:30 pm, Bin Meng wrote:
From: Bin Meng
Drop CONFIG_MTD_M25P80 that was removed in
commit b35b9a10362d ("mtd: spi-nor: Move m25p80 code in spi-nor.c")
Signed-off-by: Bin Meng
Thanks, I will push into the m68knommu git tree, for-next branch.
Regards
Greg
---
On 1/5/20 2:54 am, Linus Torvalds wrote:
On Thu, Apr 30, 2020 at 7:10 AM Greg Ungerer wrote:
in load_flat_file() - which is also used to loading _libraries_. Where
it makes no sense at all.
I haven't looked at the shared lib support in there for a long time,
but I thought that &qu
On 1/5/20 12:51 am, Rich Felker wrote:
On Fri, May 01, 2020 at 12:10:05AM +1000, Greg Ungerer wrote:
On 30/4/20 9:03 am, Linus Torvalds wrote:
On Wed, Apr 29, 2020 at 2:57 PM Russell King - ARM Linux admin
wrote:
I've never had any reason to use FDPIC, and I don't have any binaries
On 1/5/20 5:07 am, Eric W. Biederman wrote:
Linus Torvalds writes:
On Thu, Apr 30, 2020 at 7:10 AM Greg Ungerer wrote:
Most of that file goes back to pre-git days. And most of the commits
since are not so much about binfmt_flat, as they are about cleanups or
changes elsewhere where
me routine that is also loading libraries (and called from
'calc_reloc()' from binary loading too).
Adding Greg Ungerer for m68knommu. Can somebody sort out why that
flush_old_exec/setup_new_exec() isn't in load_flat_binary() like
install_exec_creds() is?
Most of that file goes back to pre-git days
Hi Sebastian,
On 16/10/19 5:55 pm, Sebastian Andrzej Siewior wrote:
On 2019-10-16 10:50:41 [+1000], Greg Ungerer wrote:
Hi Sebastian,
Hi Greg,
On 16/10/19 5:17 am, Sebastian Andrzej Siewior wrote:
From: Thomas Gleixner
CONFIG_PREEMPTION is selected by CONFIG_PREEMPT
to use CONFIG_PREEMPTION.
Cc: Greg Ungerer
Acked-by: Greg Ungerer
Do you want me to take this via the m68knommu git tree?
Or are you taking the whole series via some other tree?
Regards
Greg
Cc: Geert Uytterhoeven
Cc: linux-m...@lists.linux-m68k.org
Signed-off-by: Thomas Gleixner
Signed-off
Hi Linus,
Can you please pull the m68knommu git tree, for-next branch.
Only a single change, fix up header include in ColdFire specific GPIO
handling code.
Regards
Greg
The following changes since commit f74c2bb98776e2de508f4d607cd519873065118e:
Linux 5.3-rc8 (2019-09-08 13:33:15
Hi Arnd,
On 10/8/19 6:27 am, Arnd Bergmann wrote:
ks8695 is an older SoC originally made by Kendin, which was later acquired
by Micrel, and subsequently by Microchip.
The platform port was originally contributed by Andrew Victor and Ben
Dooks, and later maintained by Greg Ungerer.
When I
Hi Geert,
On 5/8/19 5:14 pm, Geert Uytterhoeven wrote:
On Sat, Aug 3, 2019 at 1:36 AM Greg Ungerer wrote:
On 2/8/19 10:10 am, Finn Thain wrote:
Since commit d3b41b6bb49e ("m68k: Dispatch nvram_ops calls to Atari or
Mac functions"), Coldfire builds generate compiler wa
ntosh.h
@@ -4,6 +4,7 @@
#include
#include
+#include
#include
Looks good to me:
Acked-by: Greg Ungerer
Geert: I can take this via the m68knommu tree if you like?
Or if you want to pick it up then no problem.
Regards
Greg
Hi Arnd,
On 23/7/19 12:44 am, Arnd Bergmann wrote:
On Sat, May 4, 2019 at 4:27 PM Greg Ungerer wrote:
On 4/5/19 3:06 am, Guenter Roeck wrote:
On Fri, May 03, 2019 at 08:16:05AM +0100, Linus Walleij wrote:
On Fri, May 3, 2019 at 8:02 AM Greg Ungerer wrote:
Ultimately though I am left
Hi Linus,
Can you please pull the m68knommu git tree, for-next branch.
A series of cleanups for the FLAT format binary loader, binfmt_flat,
from Christoph. The end goal is to support no-MMU on RISC-V, and the
last patch enables that.
Regards
Greg
The following changes since commit
Hi Geert,
On 26/6/19 6:18 pm, Geert Uytterhoeven wrote:
Hi Greg,
On Wed, Jun 26, 2019 at 9:23 AM Greg Ungerer wrote:
On 26/6/19 8:29 am, Al Viro wrote:
On Thu, Jun 13, 2019 at 09:08:54AM +0200, Christoph Hellwig wrote:
Two branches of the ifdef maze actually have the same content, so merge
On 26/6/19 8:29 am, Al Viro wrote:
On Thu, Jun 13, 2019 at 09:08:54AM +0200, Christoph Hellwig wrote:
Two branches of the ifdef maze actually have the same content, so merge
them.
Signed-off-by: Christoph Hellwig
---
include/linux/flat.h | 6 ++
1 file changed, 2 insertions(+), 4
Hi Christoph,
On 13/6/19 5:08 pm, Christoph Hellwig wrote:
below is a larger stash of cleanups for the binfmt_misc code,
preparing for the last patch that now trivially adds RISC-V
support, which will be used for the RISC-V nommu series I am
about to post.
Changes since v2:
- fix the
On 11/6/19 5:36 pm, Christoph Hellwig wrote:
On Tue, Jun 11, 2019 at 04:04:39PM +1000, Greg Ungerer wrote:
index c0e4535dc1ec..18d82fd5f57c 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -488,7 +488,8 @@ static int load_flat_file(struct linux_binprm *bprm,
* fix up
On 11/6/19 5:38 pm, Christoph Hellwig wrote:
On Tue, Jun 11, 2019 at 04:51:02PM +1000, Greg Ungerer wrote:
Hi Christoph,
On 11/6/19 7:20 am, Christoph Hellwig wrote:
below is a larger stash of cleanups for the binfmt_misc code,
preparing for the last patch that now trivially adds RISC-V
Hi Christoph,
On 11/6/19 7:20 am, Christoph Hellwig wrote:
below is a larger stash of cleanups for the binfmt_misc code,
preparing for the last patch that now trivially adds RISC-V
support, which will be used for the RISC-V nommu series I am
about to post.
Whole series looks pretty good. Just
Hi Christoph,
On 11/6/19 7:20 am, Christoph Hellwig wrote:
Instead add a Kconfig variable that only h8300 selects.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/flat.h| 1 -
arch/c6x/include/asm/flat.h| 1 -
arch/h8300/Kconfig | 1 +
Hi Geert,
On 4/6/19 5:34 pm, Geert Uytterhoeven wrote:
On Tue, Jun 4, 2019 at 9:18 AM Greg Ungerer wrote:
On 3/6/19 10:26 pm, Angelo Dureghello wrote:
couldn't seen any follow up on this patch. I tested it and at least
for mcf5441x it works properly and solves all issues.
Do you think
Hi Angelo,
On 3/6/19 10:26 pm, Angelo Dureghello wrote:
couldn't seen any follow up on this patch. I tested it and at least
for mcf5441x it works properly and solves all issues.
Do you think it may be accepted as an initial fix ?
I'll add it to the m68knommu git tree.
Seeing as you wrote it
On 29/5/19 10:32 pm, John Paul Adrian Glaubitz wrote:
On 5/28/19 12:56 PM, Greg Ungerer wrote:
Maybe... but I didn't want to rip it out without having one of the
maintainers confirm that this really isn't likely to be used anymore.
I have not used shared libraries on m68k non-mmu setups
On 29/5/19 10:05 pm, Arnd Bergmann wrote:
On Tue, May 28, 2019 at 12:56 PM Greg Ungerer wrote:
On 27/5/19 11:38 pm, Jann Horn wrote:
On Sat, May 25, 2019 at 11:43 PM Andrew Morton
wrote:
On Fri, 24 May 2019 22:18:17 +0200 Jann Horn wrote:
load_flat_shared_library() is broken: It only
On 27/5/19 11:38 pm, Jann Horn wrote:
On Sat, May 25, 2019 at 11:43 PM Andrew Morton
wrote:
On Fri, 24 May 2019 22:18:17 +0200 Jann Horn wrote:
load_flat_shared_library() is broken: It only calls load_flat_file() if
prepare_binprm() returns zero, but prepare_binprm() returns the number of
On 27/5/19 11:38 pm, Jann Horn wrote:
On Sat, May 25, 2019 at 11:43 PM Andrew Morton
wrote:
On Fri, 24 May 2019 22:18:17 +0200 Jann Horn wrote:
load_flat_shared_library() is broken: It only calls load_flat_file() if
prepare_binprm() returns zero, but prepare_binprm() returns the number of
On 4/5/19 3:06 am, Guenter Roeck wrote:
On Fri, May 03, 2019 at 08:16:05AM +0100, Linus Walleij wrote:
On Fri, May 3, 2019 at 8:02 AM Greg Ungerer wrote:
I dug out some old ks8695 based hardware to try this out.
I had a lot of trouble getting anything modern working on it.
In the end I
working on it.
In the end I still don't have a reliable test bed to test this properly.
Your patch series works as well as the kernel before the changes,
so I am happy enough to ack them as they are.
Acked-by: Greg Ungerer
Ultimately though I am left wondering if the ks8695 support in the
kernel
Hi Arnd,
On 16/4/19 6:24 am, Arnd Bergmann wrote:
drivers should not rely on machine specific headers but
get their information from the platform device.
Signed-off-by: Arnd Bergmann
I like the whole series, thanks for doing this.
I haven't looked at the KS8695 in a long time now. I am not
Hi Arnd,
On 16/4/19 6:24 am, Arnd Bergmann wrote:
The TX interrupt is marked as edge triggered, so it will
already be acked by the top-level irq code, and does not
need the ack in the driver.
Removing this avoids a nasty dependency on the regs-irq.h
file that is otherwise reserved for the
Hi Linus,
Can you please pull the m68knommu git tree, for-next branch.
Only a single change to provide platform side support for the eDMA
hardware module on the ColdFire MCF5441X SoC.
Regards
Greg
The following changes since commit 5908e6b738e3357af42c10e1183753c70a0117a9:
Linux
Hi Christoph,
On 17/12/18 9:59 pm, Christoph Hellwig wrote:
On Sat, Dec 15, 2018 at 12:14:29AM +1000, Greg Ungerer wrote:
Yep, that is right. Certainly the MMU case is broken. Some noMMU cases work
by virtue of the SoC only having an instruction cache (the older V2 cores).
Is there a good
On 14/12/18 9:47 pm, Christoph Hellwig wrote:
On Fri, Dec 14, 2018 at 10:54:32AM +0100, Geert Uytterhoeven wrote:
- page = alloc_pages(flag, order);
+ page = alloc_pages(flag | GFP_ZERO, order);
if (!page)
return NULL;
There's second implementation
Hi Linus,
Can you please pull the m68knommu git tree, for-next branch.
Only a single change to fix an out of bounds array access when
parsing boot command line.
Regards
Greg
The following changes since commit 35a7f35ad1b150ddf59a41dcac7b2fa32982be0e:
Linux 4.19-rc8 (2018-10-15
Hi Linus,
Can you please pull the m68knommu git tree, for-next branch.
Only a single change to fix an out of bounds array access when
parsing boot command line.
Regards
Greg
The following changes since commit 35a7f35ad1b150ddf59a41dcac7b2fa32982be0e:
Linux 4.19-rc8 (2018-10-15
allyesconfig and *_defconfig.
[1] https://github.com/vivier/qemu-m68k.git
v2:
* fix reservation of the kernel text/data/bss for ColdFire MMU
I am happy with all of these, so for me:
Acked-by: Greg Ungerer
Regards
Greg
Mike Rapoport (3):
m68k/bitops: convert __ffs to match generic
allyesconfig and *_defconfig.
[1] https://github.com/vivier/qemu-m68k.git
v2:
* fix reservation of the kernel text/data/bss for ColdFire MMU
I am happy with all of these, so for me:
Acked-by: Greg Ungerer
Regards
Greg
Mike Rapoport (3):
m68k/bitops: convert __ffs to match generic
Hi Mike,
On 04/07/18 14:22, Mike Rapoport wrote:
On Wed, Jul 04, 2018 at 12:02:52PM +1000, Greg Ungerer wrote:
On 04/07/18 11:39, Greg Ungerer wrote:
On 03/07/18 20:29, Mike Rapoport wrote:
In m68k the physical memory is described by [memory_start, memory_end] for
!MMU variant
Hi Mike,
On 04/07/18 14:22, Mike Rapoport wrote:
On Wed, Jul 04, 2018 at 12:02:52PM +1000, Greg Ungerer wrote:
On 04/07/18 11:39, Greg Ungerer wrote:
On 03/07/18 20:29, Mike Rapoport wrote:
In m68k the physical memory is described by [memory_start, memory_end] for
!MMU variant
Hi Mike,
On 04/07/18 11:39, Greg Ungerer wrote:
On 03/07/18 20:29, Mike Rapoport wrote:
In m68k the physical memory is described by [memory_start, memory_end] for
!MMU variant and by m68k_memory array of memory ranges for the MMU version.
This information is directly used to register
Hi Mike,
On 04/07/18 11:39, Greg Ungerer wrote:
On 03/07/18 20:29, Mike Rapoport wrote:
In m68k the physical memory is described by [memory_start, memory_end] for
!MMU variant and by m68k_memory array of memory ranges for the MMU version.
This information is directly used to register
Hi Mike,
On 03/07/18 20:29, Mike Rapoport wrote:
In m68k the physical memory is described by [memory_start, memory_end] for
!MMU variant and by m68k_memory array of memory ranges for the MMU version.
This information is directly used to register the physical memory with
memblock.
The
Hi Mike,
On 03/07/18 20:29, Mike Rapoport wrote:
In m68k the physical memory is described by [memory_start, memory_end] for
!MMU variant and by m68k_memory array of memory ranges for the MMU version.
This information is directly used to register the physical memory with
memblock.
The
Hi Geert,
On 02/07/18 23:35, Geert Uytterhoeven wrote:
Hi all,
This patch series contains fixes and cleanups for I/O accessors on m68k
platforms (with MMU).
The first patch contains small fixes without any dependencies.
Patches 2 and 3 make small adjustments to drivers that are
Hi Geert,
On 02/07/18 23:35, Geert Uytterhoeven wrote:
Hi all,
This patch series contains fixes and cleanups for I/O accessors on m68k
platforms (with MMU).
The first patch contains small fixes without any dependencies.
Patches 2 and 3 make small adjustments to drivers that are
Hi Geert,
On 22/06/18 16:35, Geert Uytterhoeven wrote:
On Fri, Jun 22, 2018 at 2:20 AM Greg Ungerer wrote:
On 22/06/18 06:30, Geert Uytterhoeven wrote:
If DEBUG_DMA is defined:
include/asm/dma.h: In function ‘set_dma_mode’:
include/asm/dma.h:393: error: ‘dmabp’ undeclared (first
Hi Geert,
On 22/06/18 16:35, Geert Uytterhoeven wrote:
On Fri, Jun 22, 2018 at 2:20 AM Greg Ungerer wrote:
On 22/06/18 06:30, Geert Uytterhoeven wrote:
If DEBUG_DMA is defined:
include/asm/dma.h: In function ‘set_dma_mode’:
include/asm/dma.h:393: error: ‘dmabp’ undeclared (first
only
once
include/asm/dma.h:393: error: for each function it appears in.)
include/asm/dma.h: In function ‘set_dma_addr’:
include/asm/dma.h:424: error: ‘dmawp’ undeclared (first use in this
function)
Reported-by: kbuild test robot
Signed-off-by: Geert Uytterhoeven
Acked-by: Greg
only
once
include/asm/dma.h:393: error: for each function it appears in.)
include/asm/dma.h: In function ‘set_dma_addr’:
include/asm/dma.h:424: error: ‘dmawp’ undeclared (first use in this
function)
Reported-by: kbuild test robot
Signed-off-by: Geert Uytterhoeven
Acked-by: Greg
Hi Geert,
On 18/06/18 16:58, Geert Uytterhoeven wrote:
Hi Greg,
On Mon, Jun 18, 2018 at 8:06 AM Greg Ungerer wrote:
Booting a ColdFire m68k core with MMU enabled causes a "bad page state"
oops since commit 1d40a5ea01d5 ("mm: mark pages in use for page tables"):
Hi Geert,
On 18/06/18 16:58, Geert Uytterhoeven wrote:
Hi Greg,
On Mon, Jun 18, 2018 at 8:06 AM Greg Ungerer wrote:
Booting a ColdFire m68k core with MMU enabled causes a "bad page state"
oops since commit 1d40a5ea01d5 ("mm: mark pages in use for page tables"):
1 - 100 of 866 matches
Mail list logo
