[PATCH v4 4/4] m68k: generate uapi header and syscall table header files

2018-10-25 Thread Firoz Khan
System call table generation script must be run to gener-
ate unistd_32.h and syscall_table.h files. This patch will
have changes which will invokes the script.

This patch will generate unistd_32.h and syscall_table.h
files by the syscall table generation script invoked by
m68k/Makefile and the generated files against the removed
files must be identical.

The generated uapi header file will be included in uapi/-
asm/unistd.h and generated system call table header file
will be included by kernel/syscall_table.S file.

Signed-off-by: Firoz Khan 
---
 arch/m68k/Makefile  |   3 +
 arch/m68k/include/asm/Kbuild|   1 +
 arch/m68k/include/uapi/asm/Kbuild   |   1 +
 arch/m68k/include/uapi/asm/unistd.h | 389 +---
 arch/m68k/kernel/syscall_table.S| 387 +--
 5 files changed, 11 insertions(+), 770 deletions(-)

diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile
index 997c9f2..f00ca53 100644
--- a/arch/m68k/Makefile
+++ b/arch/m68k/Makefile
@@ -154,5 +154,8 @@ endif
 archclean:
rm -f vmlinux.gz vmlinux.bz2
 
+archheaders:
+   $(Q)$(MAKE) $(build)=arch/m68k/kernel/syscalls all
+
 install:
sh $(srctree)/arch/m68k/install.sh $(KERNELRELEASE) vmlinux.gz 
System.map "$(INSTALL_PATH)"
diff --git a/arch/m68k/include/asm/Kbuild b/arch/m68k/include/asm/Kbuild
index a4b8d33..147f89c 100644
--- a/arch/m68k/include/asm/Kbuild
+++ b/arch/m68k/include/asm/Kbuild
@@ -24,3 +24,4 @@ generic-y += topology.h
 generic-y += trace_clock.h
 generic-y += word-at-a-time.h
 generic-y += xor.h
+generic-y += syscall_table.h
diff --git a/arch/m68k/include/uapi/asm/Kbuild 
b/arch/m68k/include/uapi/asm/Kbuild
index c2e26a4..89776ec 100644
--- a/arch/m68k/include/uapi/asm/Kbuild
+++ b/arch/m68k/include/uapi/asm/Kbuild
@@ -21,3 +21,4 @@ generic-y += statfs.h
 generic-y += termbits.h
 generic-y += termios.h
 generic-y += types.h
+generic-y += unistd_32.h
diff --git a/arch/m68k/include/uapi/asm/unistd.h 
b/arch/m68k/include/uapi/asm/unistd.h
index ba4176aa..cdbd090 100644
--- a/arch/m68k/include/uapi/asm/unistd.h
+++ b/arch/m68k/include/uapi/asm/unistd.h
@@ -2,393 +2,6 @@
 #ifndef _UAPI_ASM_M68K_UNISTD_H_
 #define _UAPI_ASM_M68K_UNISTD_H_
 
-/*
- * This file contains the system call numbers.
- */
-
-#define __NR_restart_syscall 0
-#define __NR_exit1
-#define __NR_fork2
-#define __NR_read3
-#define __NR_write   4
-#define __NR_open5
-#define __NR_close   6
-#define __NR_waitpid 7
-#define __NR_creat   8
-#define __NR_link9
-#define __NR_unlink 10
-#define __NR_execve 11
-#define __NR_chdir  12
-#define __NR_time   13
-#define __NR_mknod  14
-#define __NR_chmod  15
-#define __NR_chown  16
-/*#define __NR_break17*/
-#define __NR_oldstat18
-#define __NR_lseek  19
-#define __NR_getpid 20
-#define __NR_mount  21
-#define __NR_umount 22
-#define __NR_setuid 23
-#define __NR_getuid 24
-#define __NR_stime  25
-#define __NR_ptrace 26
-#define __NR_alarm  27
-#define __NR_oldfstat   28
-#define __NR_pause  29
-#define __NR_utime  30
-/*#define __NR_stty 31*/
-/*#define __NR_gtty 32*/
-#define __NR_access 33
-#define __NR_nice   34
-/*#define __NR_ftime35*/
-#define __NR_sync   36
-#define __NR_kill   37
-#define __NR_rename 38
-#define __NR_mkdir  39
-#define __NR_rmdir  40
-#define __NR_dup41
-#define __NR_pipe   42
-#define __NR_times  43
-/*#define __NR_prof 44*/
-#define __NR_brk45
-#define __NR_setgid 46
-#define __NR_getgid 47
-#define __NR_signal 48
-#define __NR_geteuid49
-#define __NR_getegid50
-#define __NR_acct   51
-#define __NR_umount252
-/*#define __NR_lock 53*/
-#define __NR_ioctl  54
-#define __NR_fcntl  55
-/*#define __NR_mpx  56*/
-#define __NR_setpgid57
-/*#define __NR_ulimit   58*/
-/*#define __NR_oldolduname  59*/
-#define __NR_umask  60
-#define __NR_chroot 61
-#define __NR_ustat  62
-#define __NR_dup2   63
-#define __NR_getppid64
-#define __NR_getpgrp65
-#define __NR_setsid 66
-#define __NR_sigaction  67
-#define __NR_sgetmask   68
-#define __NR_ssetmask   69
-#define __NR_setreuid   70
-#define __NR_setregid   71
-#define __NR_sigsuspend 72
-#define __NR_sigpending 

[PATCH v4 2/4] m68k: add __NR_syscalls along with NR_syscalls

2018-10-25 Thread Firoz Khan
NR_syscalls macro holds the number of system call exist
in m68k architecture. We have to change the value of NR-
_syscalls, if we add or delete a system call.

One of the patch in this patch series has a script which
will generate a uapi header based on syscall.tbl file.
The syscall.tbl file contains the total number of system
calls information. So we have two option to update NR_sy-
scalls value.

1. Update NR_syscalls in asm/unistd.h manually by count-
   ing the no.of system calls. No need to update NR_sys-
   calls until we either add a new system call or delete
   existing system call.

2. We can keep this feature it above mentioned script,
   that will count the number of syscalls and keep it in
   a generated file. In this case we don't need to expli-
   citly update NR_syscalls in asm/unistd.h file.

The 2nd option will be the recommended one. For that, I
added the __NR_syscalls macro in uapi/asm/unistd.h along
with NR_syscalls asm/unistd.h. The macro __NR_syscalls
also added for making the name convention same across all
architecture. While __NR_syscalls isn't strictly part of
the uapi, having it as part of the generated header to
simplifies the implementation. We also need to enclose
this macro with #ifdef __KERNEL__ to avoid side effects.

Signed-off-by: Firoz Khan 
---
 arch/m68k/include/asm/unistd.h  | 3 +--
 arch/m68k/include/uapi/asm/unistd.h | 4 
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/include/asm/unistd.h b/arch/m68k/include/asm/unistd.h
index 30d0d3f..5072e94 100644
--- a/arch/m68k/include/asm/unistd.h
+++ b/arch/m68k/include/asm/unistd.h
@@ -4,8 +4,7 @@
 
 #include 
 
-
-#define NR_syscalls380
+#define NR_syscalls __NR_syscalls
 
 #define __ARCH_WANT_OLD_READDIR
 #define __ARCH_WANT_OLD_STAT
diff --git a/arch/m68k/include/uapi/asm/unistd.h 
b/arch/m68k/include/uapi/asm/unistd.h
index de3054f..ba4176aa 100644
--- a/arch/m68k/include/uapi/asm/unistd.h
+++ b/arch/m68k/include/uapi/asm/unistd.h
@@ -387,4 +387,8 @@
 #define __NR_pwritev2  378
 #define __NR_statx 379
 
+#ifdef __KERNEL__
+#define __NR_syscalls  380
+#endif
+
 #endif /* _UAPI_ASM_M68K_UNISTD_H_ */
-- 
1.9.1



[PATCH v4 0/4] m68k: system call table generation support

2018-10-25 Thread Firoz Khan
The purpose of this patch series is, we can easily add/modify/delete
system call table support by changing entry in syscall.tbl file 
instead of manually changing many files. The other goal is to unify 
the system call table generation support implementation across all 
the architectures. 

The system call tables are in different format in all architecture. 
It will be difficult to manually add, modify or delete the system 
calls in the respective files manually. To make it easy by keeping
a script and which'll generate uapi header file and syscall table 
file.

syscall.tbl contains the list of available system calls along with 
system call number and corresponding entry point. Add a new system 
call in this architecture will be possible by adding new entry in 
the syscall.tbl file.

Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.

ARM, s390 and x86 architecuture does exist the similar support. I 
leverage their implementation to come up with a generic solution.

I have done the same support for work for alpha, ia64, microblaze,
mips, parisc, powerpc, sh, sparc, and xtensa. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/

Finally, this is the ground work to solve the Y2038 issue. We need 
to add two dozen of system calls to solve Y2038 issue. So this patch
series will help to add new system calls easily by adding new entry 
in the syscall.tbl.

Firoz Khan (4):
  m68k: rename system call table file name
  m68k: add __NR_syscalls along with NR_syscalls
  m68k: add system call table generation support
  m68k: generate uapi header and syscall table header files

 arch/m68k/Makefile  |   3 +
 arch/m68k/include/asm/Kbuild|   1 +
 arch/m68k/include/asm/unistd.h  |   3 +-
 arch/m68k/include/uapi/asm/Kbuild   |   1 +
 arch/m68k/include/uapi/asm/unistd.h | 385 +-
 arch/m68k/kernel/Makefile   |   2 +-
 arch/m68k/kernel/syscall_table.S|  26 +++
 arch/m68k/kernel/syscalls/Makefile  |  38 +++
 arch/m68k/kernel/syscalls/syscall.tbl   | 389 ++
 arch/m68k/kernel/syscalls/syscallhdr.sh |  36 +++
 arch/m68k/kernel/syscalls/syscalltbl.sh |  32 +++
 arch/m68k/kernel/syscalltable.S | 403 
 12 files changed, 529 insertions(+), 790 deletions(-)
 create mode 100644 arch/m68k/kernel/syscall_table.S
 create mode 100644 arch/m68k/kernel/syscalls/Makefile
 create mode 100644 arch/m68k/kernel/syscalls/syscall.tbl
 create mode 100644 arch/m68k/kernel/syscalls/syscallhdr.sh
 create mode 100644 arch/m68k/kernel/syscalls/syscalltbl.sh
 delete mode 100644 arch/m68k/kernel/syscalltable.S

-- 
1.9.1



[PATCH v4 1/4] m68k: rename system call table file name

2018-10-25 Thread Firoz Khan
The system call table entries are present in syscalltable.S.
One of the patch in this patch series will generate the sys-
tem call table entries using the system call table generation
script and which will replace the existig table file.

In order to come up with a common naming convention across
all architecture, we need to change the file name to syscall-
_table.S. This change will unify the system call table gener-
tion implementation across all architecture.

Signed-off-by: Firoz Khan 
---
 arch/m68k/kernel/Makefile| 2 +-
 arch/m68k/kernel/{syscalltable.S => syscall_table.S} | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename arch/m68k/kernel/{syscalltable.S => syscall_table.S} (99%)

diff --git a/arch/m68k/kernel/Makefile b/arch/m68k/kernel/Makefile
index dbac7f8..5f40ce6 100644
--- a/arch/m68k/kernel/Makefile
+++ b/arch/m68k/kernel/Makefile
@@ -15,7 +15,7 @@ extra-$(CONFIG_SUN3)  := sun3-head.o
 extra-y+= vmlinux.lds
 
 obj-y  := entry.o irq.o module.o process.o ptrace.o
-obj-y  += setup.o signal.o sys_m68k.o syscalltable.o time.o traps.o
+obj-y  += setup.o signal.o sys_m68k.o syscall_table.o time.o traps.o
 
 obj-$(CONFIG_MMU_MOTOROLA) += ints.o vectors.o
 obj-$(CONFIG_MMU_SUN3) += ints.o vectors.o
diff --git a/arch/m68k/kernel/syscalltable.S b/arch/m68k/kernel/syscall_table.S
similarity index 99%
rename from arch/m68k/kernel/syscalltable.S
rename to arch/m68k/kernel/syscall_table.S
index 2c8402e..6145bc0 100644
--- a/arch/m68k/kernel/syscalltable.S
+++ b/arch/m68k/kernel/syscall_table.S
@@ -6,7 +6,7 @@
  *
  *  Copyright (C) 1998  D. Jeff Dionne ,
  *  Kenneth Albanowski ,
- *  Copyright (C) 2000  Lineo Inc. (www.lineo.com) 
+ *  Copyright (C) 2000  Lineo Inc. (www.lineo.com)
  *  Copyright (C) 1991, 1992  Linus Torvalds
  *
  *  Linux/m68k support by Hamish Macdonald
-- 
1.9.1



[PATCH v4 3/4] m68k: add system call table generation support

2018-10-25 Thread Firoz Khan
The system call tables are in different format in all
architecture and it will be difficult to manually add,
modify or delete the syscall table entries in the res-
pective files. To make it easy by keeping a script and
which will generate the uapi header and syscall table 
file. This change will also help to unify the implemen-
tation across all architectures.

The system call table generation script is added in
kernel/syscalls directory which contain the scripts to
generate both uapi header file and system call table
files. The syscall.tbl will be input for the scripts.

syscall.tbl contains the list of available system calls
along with system call number and corresponding entry
point. Add a new system call in this architecture will
be possible by adding new entry in the syscall.tbl file.

Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.

syscallhdr.sh and syscalltbl.sh will generate uapi header
unistd_32.h and syscall_table.h files respectively. Both
.sh files will parse the content syscall.tbl to generate
the header and table files. unistd_32.h will be included
by uapi/asm/unistd.h and syscall_table.h is included by
kernel/syscall_table.S - the real system call table.

ARM, s390 and x86 architecuture does have similar support.
I leverage their implementation to come up with a generic
solution.

Signed-off-by: Firoz Khan 
---
 arch/m68k/kernel/syscalls/Makefile  |  38 
 arch/m68k/kernel/syscalls/syscall.tbl   | 389 
 arch/m68k/kernel/syscalls/syscallhdr.sh |  36 +++
 arch/m68k/kernel/syscalls/syscalltbl.sh |  32 +++
 4 files changed, 495 insertions(+)
 create mode 100644 arch/m68k/kernel/syscalls/Makefile
 create mode 100644 arch/m68k/kernel/syscalls/syscall.tbl
 create mode 100644 arch/m68k/kernel/syscalls/syscallhdr.sh
 create mode 100644 arch/m68k/kernel/syscalls/syscalltbl.sh

diff --git a/arch/m68k/kernel/syscalls/Makefile 
b/arch/m68k/kernel/syscalls/Makefile
new file mode 100644
index 000..659faef
--- /dev/null
+++ b/arch/m68k/kernel/syscalls/Makefile
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0
+kapi := arch/$(SRCARCH)/include/generated/asm
+uapi := arch/$(SRCARCH)/include/generated/uapi/asm
+
+_dummy := $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)')  \
+ $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)')
+
+syscall := $(srctree)/$(src)/syscall.tbl
+syshdr := $(srctree)/$(src)/syscallhdr.sh
+systbl := $(srctree)/$(src)/syscalltbl.sh
+
+quiet_cmd_syshdr = SYSHDR  $@
+  cmd_syshdr = $(CONFIG_SHELL) '$(syshdr)' '$<' '$@'   \
+  '$(syshdr_abis_$(basetarget))'   \
+  '$(syshdr_pfx_$(basetarget))'\
+  '$(syshdr_offset_$(basetarget))'
+
+quiet_cmd_systbl = SYSTBL  $@
+  cmd_systbl = $(CONFIG_SHELL) '$(systbl)' '$<' '$@'   \
+  '$(systbl_abis_$(basetarget))'   \
+  '$(systbl_abi_$(basetarget))'\
+  '$(systbl_offset_$(basetarget))'
+
+$(uapi)/unistd_32.h: $(syscall) $(syshdr)
+   $(call if_changed,syshdr)
+
+$(kapi)/syscall_table.h: $(syscall) $(systbl)
+   $(call if_changed,systbl)
+
+uapisyshdr-y   += unistd_32.h
+kapisyshdr-y   += syscall_table.h
+
+targets+= $(uapisyshdr-y) $(kapisyshdr-y)
+
+PHONY += all
+all: $(addprefix $(uapi)/,$(uapisyshdr-y))
+all: $(addprefix $(kapi)/,$(kapisyshdr-y))
+   @:
diff --git a/arch/m68k/kernel/syscalls/syscall.tbl 
b/arch/m68k/kernel/syscalls/syscall.tbl
new file mode 100644
index 000..1a95c4a
--- /dev/null
+++ b/arch/m68k/kernel/syscalls/syscall.tbl
@@ -0,0 +1,389 @@
+# SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
+#
+# system call numbers and entry vectors for m68k
+#
+# The format is:
+#
+#
+# The  is always "common" for this file
+#
+0  common  restart_syscall sys_restart_syscall
+1  common  exitsys_exit
+2  common  fork__sys_fork
+3  common  readsys_read
+4  common  write   sys_write
+5  common  opensys_open
+6  common  close   sys_close
+7  common  waitpid sys_waitpid
+8  common  creat   sys_creat
+9  common  linksys_link
+10 common  unlink  sys_unlink
+11 common  execve  sys_execve
+12 common  chdir   sys_chdir
+13 common  timesys_time
+14 common  mknod   sys_mknod
+15 common  chmod   sys_chmod
+16 common  chown   sys_chown16
+# 17 was break
+18 common  oldstat sys_stat
+19 

Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD

2018-10-25 Thread Florian Fainelli
On 10/25/18 2:13 PM, Rob Herring wrote:
> On Thu, Oct 25, 2018 at 12:30 PM Mike Rapoport  wrote:
>>
>> On Thu, Oct 25, 2018 at 08:15:15AM -0500, Rob Herring wrote:
>>> +Ard
>>>
>>> On Thu, Oct 25, 2018 at 4:38 AM Mike Rapoport  wrote:

 On Wed, Oct 24, 2018 at 02:55:17PM -0500, Rob Herring wrote:
> On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli  
> wrote:
>>
>> Hi all,
>>
>> While investigating why ARM64 required a ton of objects to be rebuilt
>> when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was
>> because we define __early_init_dt_declare_initrd() differently and we do
>> that in arch/arm64/include/asm/memory.h which gets included by a fair
>> amount of other header files, and translation units as well.
>
> I scratch my head sometimes as to why some config options rebuild so
> much stuff. One down, ? to go. :)
>
>> Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with build
>> systems that generate two kernels: one with the initramfs and one
>> without. buildroot is one of these build systems, OpenWrt is also
>> another one that does this.
>>
>> This patch series proposes adding an empty initrd.h to satisfy the need
>> for drivers/of/fdt.c to unconditionally include that file, and moves the
>> custom __early_init_dt_declare_initrd() definition away from
>> asm/memory.h
>>
>> This cuts the number of objects rebuilds from 1920 down to 26, so a
>> factor 73 approximately.
>>
>> Apologies for the long CC list, please let me know how you would go
>> about merging that and if another approach would be preferable, e.g:
>> introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or
>> something like that.
>
> There may be a better way as of 4.20 because bootmem is now gone and
> only memblock is used. This should unify what each arch needs to do
> with initrd early. We need the physical address early for memblock
> reserving. Then later on we need the virtual address to access the
> initrd. Perhaps we should just change initrd_start and initrd_end to
> physical addresses (or add 2 new variables would be less invasive and
> allow for different translation than __va()). The sanity checks and
> memblock reserve could also perhaps be moved to a common location.
>
> Alternatively, given arm64 is the only oddball, I'd be fine with an
> "if (IS_ENABLED(CONFIG_ARM64))" condition in the default
> __early_init_dt_declare_initrd as long as we have a path to removing
> it like the above option.

 I think arm64 does not have to redefine __early_init_dt_declare_initrd().
 Something like this might be just all we need (completely untested,
 probably it won't even compile):

 diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
 index 9d9582c..e9ca238 100644
 --- a/arch/arm64/mm/init.c
 +++ b/arch/arm64/mm/init.c
 @@ -62,6 +62,9 @@ s64 memstart_addr __ro_after_init = -1;
  phys_addr_t arm64_dma_phys_limit __ro_after_init;

  #ifdef CONFIG_BLK_DEV_INITRD
 +
 +static phys_addr_t initrd_start_phys, initrd_end_phys;
 +
  static int __init early_initrd(char *p)
  {
 unsigned long start, size;
 @@ -71,8 +74,8 @@ static int __init early_initrd(char *p)
 if (*endp == ',') {
 size = memparse(endp + 1, NULL);

 -   initrd_start = start;
 -   initrd_end = start + size;
 +   initrd_start_phys = start;
 +   initrd_end_phys = end;
 }
 return 0;
  }
 @@ -407,14 +410,27 @@ void __init arm64_memblock_init(void)
 memblock_add(__pa_symbol(_text), (u64)(_end - _text));
 }

 -   if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
 +   if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) &&
 +   (initrd_start || initrd_start_phys)) {
 +   /*
 +* FIXME: ensure proper precendence between
 +* early_initrd and DT when both are present
>>>
>>> Command line takes precedence, so just reverse the order.
>>>
 +*/
 +   if (initrd_start) {
 +   initrd_start_phys = __phys_to_virt(initrd_start);
 +   initrd_end_phys = __phys_to_virt(initrd_end);
> 
> BTW, I think you meant virt_to_phys() here?
> 
>>>
>>> AIUI, the original issue was doing the P2V translation was happening
>>> too early and the VA could be wrong if the linear range is adjusted.
>>> So I don't think this would work.
>>
>> Probably things have changed since then, but in the current code there is
>>
>> initrd_start = __phys_to_virt(initrd_start);
>>
>> and in between only the code related to CONFIG_RANDOMIZE_BASE, so I believe
>> it's safe to use 

Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD

2018-10-25 Thread Rob Herring
On Thu, Oct 25, 2018 at 12:30 PM Mike Rapoport  wrote:
>
> On Thu, Oct 25, 2018 at 08:15:15AM -0500, Rob Herring wrote:
> > +Ard
> >
> > On Thu, Oct 25, 2018 at 4:38 AM Mike Rapoport  wrote:
> > >
> > > On Wed, Oct 24, 2018 at 02:55:17PM -0500, Rob Herring wrote:
> > > > On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli  
> > > > wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > While investigating why ARM64 required a ton of objects to be rebuilt
> > > > > when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was
> > > > > because we define __early_init_dt_declare_initrd() differently and we 
> > > > > do
> > > > > that in arch/arm64/include/asm/memory.h which gets included by a fair
> > > > > amount of other header files, and translation units as well.
> > > >
> > > > I scratch my head sometimes as to why some config options rebuild so
> > > > much stuff. One down, ? to go. :)
> > > >
> > > > > Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with 
> > > > > build
> > > > > systems that generate two kernels: one with the initramfs and one
> > > > > without. buildroot is one of these build systems, OpenWrt is also
> > > > > another one that does this.
> > > > >
> > > > > This patch series proposes adding an empty initrd.h to satisfy the 
> > > > > need
> > > > > for drivers/of/fdt.c to unconditionally include that file, and moves 
> > > > > the
> > > > > custom __early_init_dt_declare_initrd() definition away from
> > > > > asm/memory.h
> > > > >
> > > > > This cuts the number of objects rebuilds from 1920 down to 26, so a
> > > > > factor 73 approximately.
> > > > >
> > > > > Apologies for the long CC list, please let me know how you would go
> > > > > about merging that and if another approach would be preferable, e.g:
> > > > > introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or
> > > > > something like that.
> > > >
> > > > There may be a better way as of 4.20 because bootmem is now gone and
> > > > only memblock is used. This should unify what each arch needs to do
> > > > with initrd early. We need the physical address early for memblock
> > > > reserving. Then later on we need the virtual address to access the
> > > > initrd. Perhaps we should just change initrd_start and initrd_end to
> > > > physical addresses (or add 2 new variables would be less invasive and
> > > > allow for different translation than __va()). The sanity checks and
> > > > memblock reserve could also perhaps be moved to a common location.
> > > >
> > > > Alternatively, given arm64 is the only oddball, I'd be fine with an
> > > > "if (IS_ENABLED(CONFIG_ARM64))" condition in the default
> > > > __early_init_dt_declare_initrd as long as we have a path to removing
> > > > it like the above option.
> > >
> > > I think arm64 does not have to redefine __early_init_dt_declare_initrd().
> > > Something like this might be just all we need (completely untested,
> > > probably it won't even compile):
> > >
> > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > > index 9d9582c..e9ca238 100644
> > > --- a/arch/arm64/mm/init.c
> > > +++ b/arch/arm64/mm/init.c
> > > @@ -62,6 +62,9 @@ s64 memstart_addr __ro_after_init = -1;
> > >  phys_addr_t arm64_dma_phys_limit __ro_after_init;
> > >
> > >  #ifdef CONFIG_BLK_DEV_INITRD
> > > +
> > > +static phys_addr_t initrd_start_phys, initrd_end_phys;
> > > +
> > >  static int __init early_initrd(char *p)
> > >  {
> > > unsigned long start, size;
> > > @@ -71,8 +74,8 @@ static int __init early_initrd(char *p)
> > > if (*endp == ',') {
> > > size = memparse(endp + 1, NULL);
> > >
> > > -   initrd_start = start;
> > > -   initrd_end = start + size;
> > > +   initrd_start_phys = start;
> > > +   initrd_end_phys = end;
> > > }
> > > return 0;
> > >  }
> > > @@ -407,14 +410,27 @@ void __init arm64_memblock_init(void)
> > > memblock_add(__pa_symbol(_text), (u64)(_end - _text));
> > > }
> > >
> > > -   if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
> > > +   if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) &&
> > > +   (initrd_start || initrd_start_phys)) {
> > > +   /*
> > > +* FIXME: ensure proper precendence between
> > > +* early_initrd and DT when both are present
> >
> > Command line takes precedence, so just reverse the order.
> >
> > > +*/
> > > +   if (initrd_start) {
> > > +   initrd_start_phys = __phys_to_virt(initrd_start);
> > > +   initrd_end_phys = __phys_to_virt(initrd_end);

BTW, I think you meant virt_to_phys() here?

> >
> > AIUI, the original issue was doing the P2V translation was happening
> > too early and the VA could be wrong if the linear range is adjusted.
> > So I don't think this would work.
>
> Probably things have changed since then, but in the current code there is
>
> 

Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD

2018-10-25 Thread Mike Rapoport
On Thu, Oct 25, 2018 at 08:15:15AM -0500, Rob Herring wrote:
> +Ard
> 
> On Thu, Oct 25, 2018 at 4:38 AM Mike Rapoport  wrote:
> >
> > On Wed, Oct 24, 2018 at 02:55:17PM -0500, Rob Herring wrote:
> > > On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli  
> > > wrote:
> > > >
> > > > Hi all,
> > > >
> > > > While investigating why ARM64 required a ton of objects to be rebuilt
> > > > when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was
> > > > because we define __early_init_dt_declare_initrd() differently and we do
> > > > that in arch/arm64/include/asm/memory.h which gets included by a fair
> > > > amount of other header files, and translation units as well.
> > >
> > > I scratch my head sometimes as to why some config options rebuild so
> > > much stuff. One down, ? to go. :)
> > >
> > > > Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with build
> > > > systems that generate two kernels: one with the initramfs and one
> > > > without. buildroot is one of these build systems, OpenWrt is also
> > > > another one that does this.
> > > >
> > > > This patch series proposes adding an empty initrd.h to satisfy the need
> > > > for drivers/of/fdt.c to unconditionally include that file, and moves the
> > > > custom __early_init_dt_declare_initrd() definition away from
> > > > asm/memory.h
> > > >
> > > > This cuts the number of objects rebuilds from 1920 down to 26, so a
> > > > factor 73 approximately.
> > > >
> > > > Apologies for the long CC list, please let me know how you would go
> > > > about merging that and if another approach would be preferable, e.g:
> > > > introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or
> > > > something like that.
> > >
> > > There may be a better way as of 4.20 because bootmem is now gone and
> > > only memblock is used. This should unify what each arch needs to do
> > > with initrd early. We need the physical address early for memblock
> > > reserving. Then later on we need the virtual address to access the
> > > initrd. Perhaps we should just change initrd_start and initrd_end to
> > > physical addresses (or add 2 new variables would be less invasive and
> > > allow for different translation than __va()). The sanity checks and
> > > memblock reserve could also perhaps be moved to a common location.
> > >
> > > Alternatively, given arm64 is the only oddball, I'd be fine with an
> > > "if (IS_ENABLED(CONFIG_ARM64))" condition in the default
> > > __early_init_dt_declare_initrd as long as we have a path to removing
> > > it like the above option.
> >
> > I think arm64 does not have to redefine __early_init_dt_declare_initrd().
> > Something like this might be just all we need (completely untested,
> > probably it won't even compile):
> >
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 9d9582c..e9ca238 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -62,6 +62,9 @@ s64 memstart_addr __ro_after_init = -1;
> >  phys_addr_t arm64_dma_phys_limit __ro_after_init;
> >
> >  #ifdef CONFIG_BLK_DEV_INITRD
> > +
> > +static phys_addr_t initrd_start_phys, initrd_end_phys;
> > +
> >  static int __init early_initrd(char *p)
> >  {
> > unsigned long start, size;
> > @@ -71,8 +74,8 @@ static int __init early_initrd(char *p)
> > if (*endp == ',') {
> > size = memparse(endp + 1, NULL);
> >
> > -   initrd_start = start;
> > -   initrd_end = start + size;
> > +   initrd_start_phys = start;
> > +   initrd_end_phys = end;
> > }
> > return 0;
> >  }
> > @@ -407,14 +410,27 @@ void __init arm64_memblock_init(void)
> > memblock_add(__pa_symbol(_text), (u64)(_end - _text));
> > }
> >
> > -   if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
> > +   if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) &&
> > +   (initrd_start || initrd_start_phys)) {
> > +   /*
> > +* FIXME: ensure proper precendence between
> > +* early_initrd and DT when both are present
> 
> Command line takes precedence, so just reverse the order.
> 
> > +*/
> > +   if (initrd_start) {
> > +   initrd_start_phys = __phys_to_virt(initrd_start);
> > +   initrd_end_phys = __phys_to_virt(initrd_end);
> 
> AIUI, the original issue was doing the P2V translation was happening
> too early and the VA could be wrong if the linear range is adjusted.
> So I don't think this would work.

Probably things have changed since then, but in the current code there is

initrd_start = __phys_to_virt(initrd_start);

and in between only the code related to CONFIG_RANDOMIZE_BASE, so I believe
it's safe to use __phys_to_virt() here as well.
 
> I suppose you could convert the VA back to a PA before any adjustments
> and then back to a VA again after. But that's kind of hacky. 2 wrongs
> making a right.
> 
> > +

Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD

2018-10-25 Thread Rob Herring
+Ard

On Thu, Oct 25, 2018 at 4:38 AM Mike Rapoport  wrote:
>
> On Wed, Oct 24, 2018 at 02:55:17PM -0500, Rob Herring wrote:
> > On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli  
> > wrote:
> > >
> > > Hi all,
> > >
> > > While investigating why ARM64 required a ton of objects to be rebuilt
> > > when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was
> > > because we define __early_init_dt_declare_initrd() differently and we do
> > > that in arch/arm64/include/asm/memory.h which gets included by a fair
> > > amount of other header files, and translation units as well.
> >
> > I scratch my head sometimes as to why some config options rebuild so
> > much stuff. One down, ? to go. :)
> >
> > > Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with build
> > > systems that generate two kernels: one with the initramfs and one
> > > without. buildroot is one of these build systems, OpenWrt is also
> > > another one that does this.
> > >
> > > This patch series proposes adding an empty initrd.h to satisfy the need
> > > for drivers/of/fdt.c to unconditionally include that file, and moves the
> > > custom __early_init_dt_declare_initrd() definition away from
> > > asm/memory.h
> > >
> > > This cuts the number of objects rebuilds from 1920 down to 26, so a
> > > factor 73 approximately.
> > >
> > > Apologies for the long CC list, please let me know how you would go
> > > about merging that and if another approach would be preferable, e.g:
> > > introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or
> > > something like that.
> >
> > There may be a better way as of 4.20 because bootmem is now gone and
> > only memblock is used. This should unify what each arch needs to do
> > with initrd early. We need the physical address early for memblock
> > reserving. Then later on we need the virtual address to access the
> > initrd. Perhaps we should just change initrd_start and initrd_end to
> > physical addresses (or add 2 new variables would be less invasive and
> > allow for different translation than __va()). The sanity checks and
> > memblock reserve could also perhaps be moved to a common location.
> >
> > Alternatively, given arm64 is the only oddball, I'd be fine with an
> > "if (IS_ENABLED(CONFIG_ARM64))" condition in the default
> > __early_init_dt_declare_initrd as long as we have a path to removing
> > it like the above option.
>
> I think arm64 does not have to redefine __early_init_dt_declare_initrd().
> Something like this might be just all we need (completely untested,
> probably it won't even compile):
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 9d9582c..e9ca238 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -62,6 +62,9 @@ s64 memstart_addr __ro_after_init = -1;
>  phys_addr_t arm64_dma_phys_limit __ro_after_init;
>
>  #ifdef CONFIG_BLK_DEV_INITRD
> +
> +static phys_addr_t initrd_start_phys, initrd_end_phys;
> +
>  static int __init early_initrd(char *p)
>  {
> unsigned long start, size;
> @@ -71,8 +74,8 @@ static int __init early_initrd(char *p)
> if (*endp == ',') {
> size = memparse(endp + 1, NULL);
>
> -   initrd_start = start;
> -   initrd_end = start + size;
> +   initrd_start_phys = start;
> +   initrd_end_phys = end;
> }
> return 0;
>  }
> @@ -407,14 +410,27 @@ void __init arm64_memblock_init(void)
> memblock_add(__pa_symbol(_text), (u64)(_end - _text));
> }
>
> -   if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
> +   if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) &&
> +   (initrd_start || initrd_start_phys)) {
> +   /*
> +* FIXME: ensure proper precendence between
> +* early_initrd and DT when both are present

Command line takes precedence, so just reverse the order.

> +*/
> +   if (initrd_start) {
> +   initrd_start_phys = __phys_to_virt(initrd_start);
> +   initrd_end_phys = __phys_to_virt(initrd_end);

AIUI, the original issue was doing the P2V translation was happening
too early and the VA could be wrong if the linear range is adjusted.
So I don't think this would work.

I suppose you could convert the VA back to a PA before any adjustments
and then back to a VA again after. But that's kind of hacky. 2 wrongs
making a right.

> +   } else if (initrd_start_phys) {
> +   initrd_start = __va(initrd_start_phys);
> +   initrd_end = __va(initrd_start_phys);
> +   }
> +
> /*
>  * Add back the memory we just removed if it results in the
>  * initrd to become inaccessible via the linear mapping.
>  * Otherwise, this is a no-op
>  */
> -   u64 base = initrd_start & PAGE_MASK;
> -   u64 size = 

Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD

2018-10-25 Thread Russell King - ARM Linux
On Thu, Oct 25, 2018 at 10:38:34AM +0100, Mike Rapoport wrote:
> On Wed, Oct 24, 2018 at 02:55:17PM -0500, Rob Herring wrote:
> > On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli  
> > wrote:
> > >
> > > Hi all,
> > >
> > > While investigating why ARM64 required a ton of objects to be rebuilt
> > > when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was
> > > because we define __early_init_dt_declare_initrd() differently and we do
> > > that in arch/arm64/include/asm/memory.h which gets included by a fair
> > > amount of other header files, and translation units as well.
> > 
> > I scratch my head sometimes as to why some config options rebuild so
> > much stuff. One down, ? to go. :)
> > 
> > > Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with build
> > > systems that generate two kernels: one with the initramfs and one
> > > without. buildroot is one of these build systems, OpenWrt is also
> > > another one that does this.
> > >
> > > This patch series proposes adding an empty initrd.h to satisfy the need
> > > for drivers/of/fdt.c to unconditionally include that file, and moves the
> > > custom __early_init_dt_declare_initrd() definition away from
> > > asm/memory.h
> > >
> > > This cuts the number of objects rebuilds from 1920 down to 26, so a
> > > factor 73 approximately.
> > >
> > > Apologies for the long CC list, please let me know how you would go
> > > about merging that and if another approach would be preferable, e.g:
> > > introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or
> > > something like that.
> > 
> > There may be a better way as of 4.20 because bootmem is now gone and
> > only memblock is used. This should unify what each arch needs to do
> > with initrd early. We need the physical address early for memblock
> > reserving. Then later on we need the virtual address to access the
> > initrd. Perhaps we should just change initrd_start and initrd_end to
> > physical addresses (or add 2 new variables would be less invasive and
> > allow for different translation than __va()). The sanity checks and
> > memblock reserve could also perhaps be moved to a common location.
> >
> > Alternatively, given arm64 is the only oddball, I'd be fine with an
> > "if (IS_ENABLED(CONFIG_ARM64))" condition in the default
> > __early_init_dt_declare_initrd as long as we have a path to removing
> > it like the above option.
> 
> I think arm64 does not have to redefine __early_init_dt_declare_initrd().
> Something like this might be just all we need (completely untested,
> probably it won't even compile):

The alternative solution would be to replace initrd_start/initrd_end
with physical address versions of these everywhere - that's what
we're passed from DT, it's what 32-bit ARM would prefer, and seemingly
what 64-bit ARM would also like as well.

Grepping for initrd_start in arch/*/mm shows that there's lots of
architectures that have virtual/physical conversions on these, and
a number that have obviously been derived from 32-bit ARM's approach
(with maintaining a phys_initrd_start variable to simplify things).

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up


Re: [PATCH v2 0/2] arm64: Cut rebuild time when changing CONFIG_BLK_DEV_INITRD

2018-10-25 Thread Mike Rapoport
On Wed, Oct 24, 2018 at 02:55:17PM -0500, Rob Herring wrote:
> On Wed, Oct 24, 2018 at 2:33 PM Florian Fainelli  wrote:
> >
> > Hi all,
> >
> > While investigating why ARM64 required a ton of objects to be rebuilt
> > when toggling CONFIG_DEV_BLK_INITRD, it became clear that this was
> > because we define __early_init_dt_declare_initrd() differently and we do
> > that in arch/arm64/include/asm/memory.h which gets included by a fair
> > amount of other header files, and translation units as well.
> 
> I scratch my head sometimes as to why some config options rebuild so
> much stuff. One down, ? to go. :)
> 
> > Changing the value of CONFIG_DEV_BLK_INITRD is a common thing with build
> > systems that generate two kernels: one with the initramfs and one
> > without. buildroot is one of these build systems, OpenWrt is also
> > another one that does this.
> >
> > This patch series proposes adding an empty initrd.h to satisfy the need
> > for drivers/of/fdt.c to unconditionally include that file, and moves the
> > custom __early_init_dt_declare_initrd() definition away from
> > asm/memory.h
> >
> > This cuts the number of objects rebuilds from 1920 down to 26, so a
> > factor 73 approximately.
> >
> > Apologies for the long CC list, please let me know how you would go
> > about merging that and if another approach would be preferable, e.g:
> > introducing a CONFIG_ARCH_INITRD_BELOW_START_OK Kconfig option or
> > something like that.
> 
> There may be a better way as of 4.20 because bootmem is now gone and
> only memblock is used. This should unify what each arch needs to do
> with initrd early. We need the physical address early for memblock
> reserving. Then later on we need the virtual address to access the
> initrd. Perhaps we should just change initrd_start and initrd_end to
> physical addresses (or add 2 new variables would be less invasive and
> allow for different translation than __va()). The sanity checks and
> memblock reserve could also perhaps be moved to a common location.
>
> Alternatively, given arm64 is the only oddball, I'd be fine with an
> "if (IS_ENABLED(CONFIG_ARM64))" condition in the default
> __early_init_dt_declare_initrd as long as we have a path to removing
> it like the above option.

I think arm64 does not have to redefine __early_init_dt_declare_initrd().
Something like this might be just all we need (completely untested,
probably it won't even compile):

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 9d9582c..e9ca238 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -62,6 +62,9 @@ s64 memstart_addr __ro_after_init = -1;
 phys_addr_t arm64_dma_phys_limit __ro_after_init;
 
 #ifdef CONFIG_BLK_DEV_INITRD
+
+static phys_addr_t initrd_start_phys, initrd_end_phys;
+
 static int __init early_initrd(char *p)
 {
unsigned long start, size;
@@ -71,8 +74,8 @@ static int __init early_initrd(char *p)
if (*endp == ',') {
size = memparse(endp + 1, NULL);
 
-   initrd_start = start;
-   initrd_end = start + size;
+   initrd_start_phys = start;
+   initrd_end_phys = end;
}
return 0;
 }
@@ -407,14 +410,27 @@ void __init arm64_memblock_init(void)
memblock_add(__pa_symbol(_text), (u64)(_end - _text));
}
 
-   if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && initrd_start) {
+   if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) &&
+   (initrd_start || initrd_start_phys)) {
+   /*
+* FIXME: ensure proper precendence between
+* early_initrd and DT when both are present
+*/
+   if (initrd_start) {
+   initrd_start_phys = __phys_to_virt(initrd_start);
+   initrd_end_phys = __phys_to_virt(initrd_end);
+   } else if (initrd_start_phys) {
+   initrd_start = __va(initrd_start_phys);
+   initrd_end = __va(initrd_start_phys);
+   }
+
/*
 * Add back the memory we just removed if it results in the
 * initrd to become inaccessible via the linear mapping.
 * Otherwise, this is a no-op
 */
-   u64 base = initrd_start & PAGE_MASK;
-   u64 size = PAGE_ALIGN(initrd_end) - base;
+   u64 base = initrd_start_phys & PAGE_MASK;
+   u64 size = PAGE_ALIGN(initrd_end_phys) - base;
 
/*
 * We can only add back the initrd memory if we don't end up
@@ -458,7 +474,7 @@ void __init arm64_memblock_init(void)
 * pagetables with memblock.
 */
memblock_reserve(__pa_symbol(_text), _end - _text);
-#ifdef CONFIG_BLK_DEV_INITRD
+#if 0
if (initrd_start) {
memblock_reserve(initrd_start, initrd_end - initrd_start);
 
 
> Rob
> 

-- 
Sincerely yours,
Mike.