Re: [PATCH V7 5/7] c6x: use new common dtc rule
On Tue, 2012-11-27 at 16:29 -0700, Stephen Warren wrote: > From: Stephen Warren > > The current rules have the .dtb files build in a different directory > from the .dts files. This patch changes c6x to use the generic dtb > rule which builds .dtb files in the same directory as the source .dts. > > This requires moving parts of arch/c6x/boot/Makefile into newly created > arch/c6x/boot/dts/Makefile, and updating arch/c6x/Makefile to call the > new Makefile. linked_dtb.S is also moved into boot/dts/ since it's used > by rules that were moved. > > Cc: Mark Salter > Cc: Aurelien Jacquiot > Cc: linux-c6x-...@linux-c6x.org > Signed-off-by: Stephen Warren > --- Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Fix AT_EXECFN auxv for no-MMU fdpic
In the no-MMU case, the FDPIC loader was passing an offset as the value for the AT_EXECFN auxv. This patch translates that offset into an actual user address. Signed-off-by: Mark Salter --- fs/binfmt_elf_fdpic.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c index cb240dd..af4c9a4 100644 --- a/fs/binfmt_elf_fdpic.c +++ b/fs/binfmt_elf_fdpic.c @@ -496,6 +496,7 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm, sp = arch_align_stack(bprm->p); #else sp = mm->start_stack; + bprm->exec = sp - (MAX_ARG_PAGES * PAGE_SIZE - bprm->exec); /* stack the program arguments and environment */ if (elf_fdpic_transfer_args_to_stack(bprm, &sp) < 0) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Fix /proc//auxv for FDPIC binaries
The FDPIC loader is not storing aux vector info in mm->saved_aux so the aux
vectors were
not being exposed through /proc//auxv. This patch copies the aux vectors
stored on
the user stack into mm->saved_aux so that they may be available through procfs.
Signed-off-by: Mark Salter
---
fs/binfmt_elf_fdpic.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index af4c9a4..9651918 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -478,7 +478,7 @@ static int create_elf_fdpic_tables(struct linux_binprm
*bprm,
struct elf_fdpic_params *interp_params)
{
const struct cred *cred = current_cred();
- unsigned long sp, csp, nitems;
+ unsigned long sp, csp, nitems, auxv_end;
elf_caddr_t __user *argv, *envp;
size_t platform_len = 0, len;
char *k_platform, *k_base_platform;
@@ -594,6 +594,7 @@ static int create_elf_fdpic_tables(struct linux_binprm
*bprm,
} while (0)
nr = 0;
+ auxv_end = csp;
csp -= 2 * sizeof(unsigned long);
NEW_AUX_ENT(AT_NULL, 0);
if (k_platform) {
@@ -645,6 +646,10 @@ static int create_elf_fdpic_tables(struct linux_binprm
*bprm,
#endif
#undef NEW_AUX_ENT
+ if (copy_from_user(current->mm->saved_auxv,
+ (const char __user *) csp, auxv_end - csp))
+ return -EFAULT;
+
/* allocate room for argv[] and envv[] */
csp -= (bprm->envc + 1) * sizeof(elf_caddr_t);
envp = (elf_caddr_t __user *) csp;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] c6x: Use generic asm/mmu.h
On Thu, 2012-11-01 at 11:24 +0100, Lars-Peter Clausen wrote: > c6x's asm/mmu.h is basically identical to asm-generic/mmu.h, so use it > instead > of the custom version. > > Signed-off-by: Lars-Peter Clausen > > --- > Note, due to lack of toolchain, etc this patch is completely untested. > --- > arch/c6x/include/asm/Kbuild |1 + > arch/c6x/include/asm/mmu.h | 22 -- > 2 files changed, 1 insertions(+), 22 deletions(-) > delete mode 100644 arch/c6x/include/asm/mmu.h Acked-by: Mark Salter Tested-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFT RESEND linux-next] c6x: dma-mapping: support debug_dma_mapping_error
On Fri, 2012-11-02 at 10:44 -0600, Shuah Khan wrote: > On Fri, 2012-10-26 at 09:40 -0600, Shuah Khan wrote: > > Add support for debug_dma_mapping_error() call to avoid warning from > > debug_dma_unmap() interface when it checks for mapping error checked > > status. Without this patch, device driver failed to check map error > > warning is generated. > > > > Signed-off-by: Shuah Khan > > --- > > arch/c6x/include/asm/dma-mapping.h |1 + > > 1 file changed, 1 insertion(+) > Would you like to this patch go through c6x arch tree or linux-next? > Please let me know your preference. I tried to test this but I get a build error with CONFIG_DMA_API_DEBUG: /linux-next/lib/dma-debug.c: In function 'has_mapping_error': /linux-next/lib/dma-debug.c:863:15: error: implicit declaration of function 'get_dma_ops' [-Werror=implicit-function-declaration] /linux-next/lib/dma-debug.c:863:34: warning: initialization makes pointer from integer without a cast [enabled by default] C6X (along with some other architectures) doesn't have a get_dma_ops() function defined. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFT RESEND linux-next] c6x: dma-mapping: support debug_dma_mapping_error
On Fri, 2012-11-02 at 13:53 -0600, Shuah Khan wrote: > On Fri, 2012-11-02 at 15:10 -0400, Mark Salter wrote: > > On Fri, 2012-11-02 at 10:44 -0600, Shuah Khan wrote: > > > On Fri, 2012-10-26 at 09:40 -0600, Shuah Khan wrote: > > > > Add support for debug_dma_mapping_error() call to avoid warning from > > > > debug_dma_unmap() interface when it checks for mapping error checked > > > > status. Without this patch, device driver failed to check map error > > > > warning is generated. > > > > > > > > Signed-off-by: Shuah Khan > > > > --- > > > > arch/c6x/include/asm/dma-mapping.h |1 + > > > > 1 file changed, 1 insertion(+) > > > > > Would you like to this patch go through c6x arch tree or linux-next? > > > Please let me know your preference. > > > > I tried to test this but I get a build error with CONFIG_DMA_API_DEBUG: > > > > /linux-next/lib/dma-debug.c: In function 'has_mapping_error': > > /linux-next/lib/dma-debug.c:863:15: error: implicit declaration of function > > 'get_dma_ops' [-Werror=implicit-function-declaration] > > /linux-next/lib/dma-debug.c:863:34: warning: initialization makes pointer > > from integer without a cast [enabled by default] > > > > C6X (along with some other architectures) doesn't have a get_dma_ops() > > function defined. > > That is a problem I didn't think about. I did a check and looks like c6x > and frv are the only ones that don't have get_dma_ops() defined. frv is By my count, there are 14 architectures with get_dma_ops() and 14 without. > in a different category as it doesn't use dma_debug interfaces. IN the > case c6x, now with my change to add debug_dma_mapping_error(), we will > start seeing warnings since dma_map_page() and dma_map_single() are > debugged with a call to debug_dma_map_page() and the corresponding > dma_mapping_error() interface doesn't call debug_dma_mapping_error() > interface > > - Does adding get_dma_ops() make sense? Doesn't look like c6x exports > dma_ops? > > Any other ideas? I'm not sure. I don't know what get_dma_ops() does and it doesn't seem to be documented anywhere. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFT RESEND linux-next] c6x: dma-mapping: support debug_dma_mapping_error
On Fri, 2012-11-02 at 14:26 -0600, Shuah Khan wrote:
> On Fri, 2012-11-02 at 16:15 -0400, Mark Salter wrote:
> > On Fri, 2012-11-02 at 13:53 -0600, Shuah Khan wrote:
> > > On Fri, 2012-11-02 at 15:10 -0400, Mark Salter wrote:
> > > > On Fri, 2012-11-02 at 10:44 -0600, Shuah Khan wrote:
> > > > > On Fri, 2012-10-26 at 09:40 -0600, Shuah Khan wrote:
> > > > > > Add support for debug_dma_mapping_error() call to avoid warning from
> > > > > > debug_dma_unmap() interface when it checks for mapping error checked
> > > > > > status. Without this patch, device driver failed to check map error
> > > > > > warning is generated.
> > > > > >
> > > > > > Signed-off-by: Shuah Khan
> > > > > > ---
> > > > > > arch/c6x/include/asm/dma-mapping.h |1 +
> > > > > > 1 file changed, 1 insertion(+)
> > > >
> > > > > Would you like to this patch go through c6x arch tree or linux-next?
> > > > > Please let me know your preference.
> > > >
> > > > I tried to test this but I get a build error with CONFIG_DMA_API_DEBUG:
> > > >
> > > > /linux-next/lib/dma-debug.c: In function 'has_mapping_error':
> > > > /linux-next/lib/dma-debug.c:863:15: error: implicit declaration of
> > > > function 'get_dma_ops' [-Werror=implicit-function-declaration]
> > > > /linux-next/lib/dma-debug.c:863:34: warning: initialization makes
> > > > pointer from integer without a cast [enabled by default]
> > > >
> > > > C6X (along with some other architectures) doesn't have a get_dma_ops()
> > > > function defined.
> > >
> > > That is a problem I didn't think about. I did a check and looks like c6x
> > > and frv are the only ones that don't have get_dma_ops() defined. frv is
> >
> > By my count, there are 14 architectures with get_dma_ops() and 14
> > without.
> Right. I should have explained more. The following archs
>
> arch/avr32/include/asm/dma-mapping.h
> arch/blackfin/include/asm/dma-mapping.h
> arch/cris/include/asm/dma-mapping.h
> arch/mn10300/include/asm/dma-mapping.h
> arch/parisc/include/asm/dma-mapping.h
> arch/xtensa/include/asm/dma-mapping.h
>
> define dma_map_page() and dma_map_single() and not call
> debug_dma_map_page() interface. There is no risk of mis-matched debug
> and non-debug mapping and mapping error checks like in the case of other
> archs and c6x.
Ah, okay. Not all architectures support HAVE_DMA_API_DEBUG. So, of those
that do, c6x seems to be the only one with dma_ops.
>
> > > in a different category as it doesn't use dma_debug interfaces. IN the
> > > case c6x, now with my change to add debug_dma_mapping_error(), we will
> > > start seeing warnings since dma_map_page() and dma_map_single() are
> > > debugged with a call to debug_dma_map_page() and the corresponding
> > > dma_mapping_error() interface doesn't call debug_dma_mapping_error()
> > > interface
> > >
> > > - Does adding get_dma_ops() make sense? Doesn't look like c6x exports
> > > dma_ops?
> > >
> > > Any other ideas?
> >
> > I'm not sure. I don't know what get_dma_ops() does and it doesn't seem
> > to be documented anywhere.
>
> It returns pointer to dma_ops like the one on alpha:
>
> static inline struct dma_map_ops *get_dma_ops(struct device *dev)
> {
> return dma_ops;
> }
Okay, so what is dma_ops used for? Looks like maybe supporting different
dma features/functionality on different busses/devices.
>
> c6x doesn't define dma_ops looks like. Is that correct? Returning null
> from get_dma_ops() is not an option as get_dma_ops() return is assumed
> to be not null.
As things stand, c6x DMA hw doesn't really need dma_ops and until this
patch, I could build in DMA debug support without dma_ops. So do we
really want to require dma_ops for dma debug support even for those
architectures which don't otherwise need it? I could add dma_ops, but
it seems silly to do so only for dma debug.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] c6x: switch to generic kernel_execve
Signed-off-by: Mark Salter --- arch/c6x/include/asm/unistd.h |2 ++ arch/c6x/kernel/entry.S | 13 ++--- 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/arch/c6x/include/asm/unistd.h b/arch/c6x/include/asm/unistd.h index 6d54ea4..1ce3a6f 100644 --- a/arch/c6x/include/asm/unistd.h +++ b/arch/c6x/include/asm/unistd.h @@ -16,6 +16,8 @@ #if !defined(_ASM_C6X_UNISTD_H) || defined(__SYSCALL) #define _ASM_C6X_UNISTD_H +#define __ARCH_WANT_KERNEL_EXECVE + /* Use the standard ABI for syscalls. */ #include diff --git a/arch/c6x/kernel/entry.S b/arch/c6x/kernel/entry.S index 6e6bd9d..32e3683 100644 --- a/arch/c6x/kernel/entry.S +++ b/arch/c6x/kernel/entry.S @@ -420,6 +420,12 @@ ENTRY(ret_from_kernel_thread) BNOP.S2 B11,5 /* jump to sys_exit */ ENDPROC(ret_from_kernel_thread) +ENTRY(ret_from_kernel_execve) + GET_THREAD_INFO A12 + BNOP.S2 syscall_exit,4 + ADD .D2XA4,-8,SP +ENDPROC(ret_from_kernel_execve) + ;; ;; These are the interrupt handlers, responsible for calling __do_IRQ() ;; int6 is used for syscalls (see _system_call entry) @@ -613,13 +619,6 @@ ENTRY(sys_sigaltstack) NOP 4 ENDPROC(sys_sigaltstack) - ;; kernel_execve -ENTRY(kernel_execve) - MVK .S2 __NR_execve,B0 - SWE - BNOP.S2 B3,5 -ENDPROC(kernel_execve) - ;; ;; Special system calls ;; return address is in B3 -- 1.7.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] c6x: switch to generic sys_execve
Signed-off-by: Mark Salter
---
arch/c6x/include/asm/syscalls.h |5 -
arch/c6x/include/asm/unistd.h |1 +
arch/c6x/kernel/entry.S | 23 ---
arch/c6x/kernel/process.c | 22 --
4 files changed, 1 insertions(+), 50 deletions(-)
diff --git a/arch/c6x/include/asm/syscalls.h b/arch/c6x/include/asm/syscalls.h
index aed53da..e7b8991 100644
--- a/arch/c6x/include/asm/syscalls.h
+++ b/arch/c6x/include/asm/syscalls.h
@@ -44,11 +44,6 @@ extern int sys_cache_sync(unsigned long s, unsigned long e);
struct pt_regs;
extern asmlinkage long sys_c6x_clone(struct pt_regs *regs);
-extern asmlinkage long sys_c6x_execve(const char __user *name,
- const char __user *const __user *argv,
- const char __user *const __user *envp,
- struct pt_regs *regs);
-
#include
diff --git a/arch/c6x/include/asm/unistd.h b/arch/c6x/include/asm/unistd.h
index 1ce3a6f..3c131d5 100644
--- a/arch/c6x/include/asm/unistd.h
+++ b/arch/c6x/include/asm/unistd.h
@@ -17,6 +17,7 @@
#define _ASM_C6X_UNISTD_H
#define __ARCH_WANT_KERNEL_EXECVE
+#define __ARCH_WANT_SYS_EXECVE
/* Use the standard ABI for syscalls. */
#include
diff --git a/arch/c6x/kernel/entry.S b/arch/c6x/kernel/entry.S
index 32e3683..5449c36 100644
--- a/arch/c6x/kernel/entry.S
+++ b/arch/c6x/kernel/entry.S
@@ -647,29 +647,6 @@ ENTRY(sys_rt_sigreturn)
#endif
ENDPROC(sys_rt_sigreturn)
-ENTRY(sys_execve)
- ADDAW .D2 SP,2,B6 ; put regs addr in 4th parameter
- ; & adjust regs stack addr
- LDW .D2T2 *+SP(REGS_B4+8),B4
-
- ;; c6x_execve(char *name, char **argv,
- ;;char **envp, struct pt_regs *regs)
-#ifdef CONFIG_C6X_BIG_KERNEL
- ||MVKL.S1 sys_c6x_execve,A0
- MVKH.S1 sys_c6x_execve,A0
- B .S2XA0
-#else
- ||B .S2 sys_c6x_execve
-#endif
- STW .D2T2 B3,*SP--[2]
- ADDKPC .S2 ret_from_c6x_execve,B3,3
-
-ret_from_c6x_execve:
- LDW .D2T2 *++SP[2],B3
- NOP 4
- BNOP.S2 B3,5
-ENDPROC(sys_execve)
-
ENTRY(sys_pread_c6x)
MV .D2XA8,B7
#ifdef CONFIG_C6X_BIG_KERNEL
diff --git a/arch/c6x/kernel/process.c b/arch/c6x/kernel/process.c
index d2ffc9b..f98616d 100644
--- a/arch/c6x/kernel/process.c
+++ b/arch/c6x/kernel/process.c
@@ -207,28 +207,6 @@ int copy_thread(unsigned long clone_flags, unsigned long
usp,
return 0;
}
-/*
- * c6x_execve() executes a new program.
- */
-SYSCALL_DEFINE4(c6x_execve, const char __user *, name,
- const char __user *const __user *, argv,
- const char __user *const __user *, envp,
- struct pt_regs *, regs)
-{
- int error;
- char *filename;
-
- filename = getname(name);
- error = PTR_ERR(filename);
- if (IS_ERR(filename))
- goto out;
-
- error = do_execve(filename, argv, envp, regs);
- putname(filename);
-out:
- return error;
-}
-
unsigned long get_wchan(struct task_struct *p)
{
return p->thread.wchan;
--
1.7.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] status of execve() work - per-architecture patches solicited
Here are a set of c6x patches to work with your experimental-kernel_thread branch. Mark Salter (3): c6x: add ret_from_kernel_thread(), simplify kernel_thread() c6x: switch to generic kernel_execve c6x: switch to generic sys_execve arch/c6x/include/asm/syscalls.h |5 --- arch/c6x/include/asm/unistd.h |3 ++ arch/c6x/kernel/entry.S | 56 +--- arch/c6x/kernel/process.c | 60 --- 4 files changed, 41 insertions(+), 83 deletions(-) -- 1.7.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] c6x: add ret_from_kernel_thread(), simplify kernel_thread()
Signed-off-by: Mark Salter
---
arch/c6x/kernel/entry.S | 20
arch/c6x/kernel/process.c | 38 --
2 files changed, 32 insertions(+), 26 deletions(-)
diff --git a/arch/c6x/kernel/entry.S b/arch/c6x/kernel/entry.S
index 30b37e5..6e6bd9d 100644
--- a/arch/c6x/kernel/entry.S
+++ b/arch/c6x/kernel/entry.S
@@ -400,6 +400,26 @@ ret_from_fork_2:
STW .D2T2 B0,*+SP(REGS_A4+8)
ENDPROC(ret_from_fork)
+ENTRY(ret_from_kernel_thread)
+#ifdef CONFIG_C6X_BIG_KERNEL
+ MVKL.S1 schedule_tail,A0
+ MVKH.S1 schedule_tail,A0
+ B .S2XA0
+#else
+ B .S2 schedule_tail
+#endif
+ LDW .D2T2 *+SP(REGS_A0+8),B10 /* get fn */
+ ADDKPC .S2 0f,B3,3
+0:
+ B .S2 B10/* call fn */
+ LDW .D2T1 *+SP(REGS_A1+8),A4 /* get arg */
+ MVKL.S2 sys_exit,B11
+ MVKH.S2 sys_exit,B11
+ ADDKPC .S2 0f,B3,1
+0:
+ BNOP.S2 B11,5 /* jump to sys_exit */
+ENDPROC(ret_from_kernel_thread)
+
;;
;; These are the interrupt handlers, responsible for calling __do_IRQ()
;; int6 is used for syscalls (see _system_call entry)
diff --git a/arch/c6x/kernel/process.c b/arch/c6x/kernel/process.c
index 45e924a..d2ffc9b 100644
--- a/arch/c6x/kernel/process.c
+++ b/arch/c6x/kernel/process.c
@@ -25,6 +25,7 @@ void (*c6x_restart)(void);
void (*c6x_halt)(void);
extern asmlinkage void ret_from_fork(void);
+extern asmlinkage void ret_from_kernel_thread(void);
/*
* power off function, if any
@@ -103,36 +104,21 @@ void machine_power_off(void)
halt_loop();
}
-static void kernel_thread_helper(int dummy, void *arg, int (*fn)(void *))
-{
- do_exit(fn(arg));
-}
-
/*
* Create a kernel thread
*/
int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
{
- struct pt_regs regs;
-
- /*
-* copy_thread sets a4 to zero (child return from fork)
-* so we can't just set things up to directly return to
-* fn.
-*/
- memset(®s, 0, sizeof(regs));
- regs.b4 = (unsigned long) arg;
- regs.a6 = (unsigned long) fn;
- regs.pc = (unsigned long) kernel_thread_helper;
- local_save_flags(regs.csr);
- regs.csr |= 1;
- regs.tsr = 5; /* Set GEE and GIE in TSR */
+ struct pt_regs regs = {
+ .a0 = (unsigned long)fn,
+ .a1 = (unsigned long)arg,
+ .tsr = 0, /* kernel mode */
+ };
/* Ok, create the new process.. */
return do_fork(flags | CLONE_VM | CLONE_UNTRACED, -1, ®s,
0, NULL, NULL);
}
-EXPORT_SYMBOL(kernel_thread);
void flush_thread(void)
{
@@ -192,21 +178,21 @@ int copy_thread(unsigned long clone_flags, unsigned long
usp,
childregs = task_pt_regs(p);
*childregs = *regs;
- childregs->a4 = 0;
- if (usp == -1)
+ if (usp == -1) {
/* case of __kernel_thread: we return to supervisor space */
childregs->sp = (unsigned long)(childregs + 1);
- else
+ p->thread.pc = (unsigned long) ret_from_kernel_thread;
+ } else {
/* Otherwise use the given stack */
childregs->sp = usp;
+ p->thread.pc = (unsigned long) ret_from_fork;
+ }
/* Set usp/ksp */
p->thread.usp = childregs->sp;
- /* switch_to uses stack to save/restore 14 callee-saved regs */
thread_saved_ksp(p) = (unsigned long)childregs - 8;
- p->thread.pc = (unsigned int) ret_from_fork;
- p->thread.wchan = (unsigned long) ret_from_fork;
+ p->thread.wchan = p->thread.pc;
#ifdef __DSBT__
{
unsigned long dp;
--
1.7.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sys_kcmp (was: Re: [PATCH 1/2] ARM: add finit_module syscall to ARM)
On Sat, 2012-09-22 at 11:47 -0700, Andrew Morton wrote: > > 2. There allegedly exists a patch to remove x86isms from sys_kcmp - > >allegedly also in akpm's tree. However, I've looked through the code in > >mainline, and nothing stands out. Ralf Beachle also said yesterday that > >he has looked through from the MIPS PoV and also can't see any x86isms, > >so we're both thinking that it should merely have the x86 dependency > >removed. > > http://ozlabs.org/~akpm/mmotm/broken-out/syscalls-make-kcmp-syscall-available-for-all-architectures.patch The following is needed to get rid of the syscall warning on architectures using the generic syscall list: diff --git a/include/asm-generic/unistd.h b/include/asm-generic/unistd.h index 991ef01..3748ec9 100644 --- a/include/asm-generic/unistd.h +++ b/include/asm-generic/unistd.h @@ -691,9 +691,11 @@ __SC_COMP(__NR_process_vm_readv, sys_process_vm_readv, \ #define __NR_process_vm_writev 271 __SC_COMP(__NR_process_vm_writev, sys_process_vm_writev, \ compat_sys_process_vm_writev) +#define __NR_kcmp 272 +__SYSCALL(__NR_kcmp, sys_kcmp) #undef __NR_syscalls -#define __NR_syscalls 272 +#define __NR_syscalls 273 > > I have that queued for 3.7. There is of course a little risk here. We > do have a test in tools/testing/selftests/kcmp/ - I suggest that arch > people run it! In fact all the tools/testing/selftests should execute > successfully on all architectures - if not, please let's fix things > up. I ran into a build error on C6X (no-MMU) when I enabled CHECKPOINT_RESTORE: linux-next/kernel/sys.c: In function 'prctl_set_mm': linux-next/kernel/sys.c:1869:34: error: 'mmap_min_addr' undeclared (first use in this function) I got past that with: diff --git a/include/linux/security.h b/include/linux/security.h index 01ef030..14e394d 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -118,6 +118,7 @@ void reset_security_ops(void); extern unsigned long mmap_min_addr; extern unsigned long dac_mmap_min_addr; #else +#define mmap_min_addr 0UL #define dac_mmap_min_addr 0UL #endif Looking at kcmp_test.c, it uses fork, so won't work without MMU. Is the kcmp syscall even meaningful for no-MMU? I suppose some of the tests in kcmp_test.c could be accomplished using clone directly rather than fork. --Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sys_kcmp (was: Re: [PATCH 1/2] ARM: add finit_module syscall to ARM)
On Mon, 2012-09-24 at 21:42 +0400, Cyrill Gorcunov wrote: > On Mon, Sep 24, 2012 at 08:49:42PM +0400, Cyrill Gorcunov wrote: > > > I got past that with: > > > > > > diff --git a/include/linux/security.h b/include/linux/security.h > > > index 01ef030..14e394d 100644 > > > --- a/include/linux/security.h > > > +++ b/include/linux/security.h > > > @@ -118,6 +118,7 @@ void reset_security_ops(void); > > > extern unsigned long mmap_min_addr; > > > extern unsigned long dac_mmap_min_addr; > > > #else > > > +#define mmap_min_addr 0UL > > > #define dac_mmap_min_addr 0UL > > > #endif > > > > > I think better to add CONFIG_MMU test here. Well, my patch was just something quick to get the kernel to build, but thinking about it a bit, I still prefer it. The CONFIG_MMU check is in security.h already so I think it is less clutter and better for future code which may use mmap_min_addr. In any case, the compiler will drop any test for "x < 0UL" so the end result is the same. > --- > From: Cyrill Gorcunov > Subject: prctl: prctl_set_mm -- Don't test for mmap_min_addr on non-MMU config > > In case if CONFIG_MMU is not set the @mmap_min_addr > is undefined leading to build error. Thus test for > it iif CONFIG_MMU is present. > > Note this code snippet depends on CONFIG_CHECKPOINT_RESTORE=y. > > Reported-by: Mark Salter > Signed-off-by: Cyrill Gorcunov > --- > kernel/sys.c |4 > 1 file changed, 4 insertions(+) > > Index: linux-2.6.git/kernel/sys.c > === > --- linux-2.6.git.orig/kernel/sys.c > +++ linux-2.6.git/kernel/sys.c > @@ -1865,7 +1865,11 @@ static int prctl_set_mm(int opt, unsigne > if (opt == PR_SET_MM_EXE_FILE) > return prctl_set_mm_exe_file(mm, (unsigned int)addr); > > +#ifdef CONFIG_MMU > if (addr >= TASK_SIZE || addr < mmap_min_addr) > +#else > + if (addr >= TASK_SIZE) > +#endif > return -EINVAL; > > error = -EINVAL; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] syscalls: add __NR_kcmp syscall to generic unistd.h
Commit d97b46a64 added a new syscall (__NR_kcmp) to support checkpoint restore. It is currently x86-only, but that restriction will be removed in a subsequent patch. Unfortunately, the kernel checksyscalls script had a bug which suppressed any warning to other architectures that the kcmp syscall was not implemented. A patch to checksyscalls is being tested in linux-next and other architectures are seeing warnings about kcmp being unimplemented. This patch adds __NR_kcmp to so that kcmp is wired in for architectures using the generic syscall list. Signed-off-by: Mark Salter --- include/asm-generic/unistd.h |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/include/asm-generic/unistd.h b/include/asm-generic/unistd.h index 991ef01..3748ec9 100644 --- a/include/asm-generic/unistd.h +++ b/include/asm-generic/unistd.h @@ -691,9 +691,11 @@ __SC_COMP(__NR_process_vm_readv, sys_process_vm_readv, \ #define __NR_process_vm_writev 271 __SC_COMP(__NR_process_vm_writev, sys_process_vm_writev, \ compat_sys_process_vm_writev) +#define __NR_kcmp 272 +__SYSCALL(__NR_kcmp, sys_kcmp) #undef __NR_syscalls -#define __NR_syscalls 272 +#define __NR_syscalls 273 /* * All syscalls below here should go away really, -- 1.7.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] syscalls: add __NR_kcmp syscall to generic unistd.h
On Mon, 2012-09-24 at 20:01 +, Arnd Bergmann wrote: > On Monday 24 September 2012, Mark Salter wrote: > > > > Commit d97b46a64 added a new syscall (__NR_kcmp) to support checkpoint > > restore. It is currently x86-only, but that restriction will be removed > > in a subsequent patch. Unfortunately, the kernel checksyscalls script > > had a bug which suppressed any warning to other architectures that the > > kcmp syscall was not implemented. A patch to checksyscalls is being > > tested in linux-next and other architectures are seeing warnings about > > kcmp being unimplemented. > > > > This patch adds __NR_kcmp to so that kcmp is > > wired in for architectures using the generic syscall list. > > > > Signed-off-by: Mark Salter > > Acked-by: Arnd Bergmann > > If you have other patches lined up, can you add this one as well? Yes. I can push it from the c6x tree. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] c/r: prctl: fix build error for no-MMU case
Commit 1ad75b9e1 added some address checking to prctl_set_mm() used by checkpoint-restore. This causes a build error for no-MMU systems: kernel/sys.c: In function 'prctl_set_mm': kernel/sys.c:1868:34: error: 'mmap_min_addr' undeclared (first use in this function) The test for mmap_min_addr doesn't make a lot of sense for no-MMU code as noted in commit 6e1415467. This patch defines mmap_min_addr as 0UL in the no-MMU case so that the compiler will optimize away tests for "addr < mmap_min_addr". Signed-off-by: Mark Salter --- include/linux/security.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/security.h b/include/linux/security.h index 3dea6a9..d143b8e 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -118,6 +118,7 @@ void reset_security_ops(void); extern unsigned long mmap_min_addr; extern unsigned long dac_mmap_min_addr; #else +#define mmap_min_addr 0UL #define dac_mmap_min_addr 0UL #endif -- 1.7.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: move elf notes into readonly segment
On Tue, 2013-08-27 at 11:49 +0100, Catalin Marinas wrote: > On Fri, Aug 23, 2013 at 04:16:42PM +0100, Mark Salter wrote: > > The current vmlinux.lds.S places the notes sections between the > > end of rw data and start of bss. This means that _edata doesn't > > really point to the end of data. Since notes are read-only, this > > patch moves them to the read-only segment so that _edata does > > point to the end of initialized rw data. > > > > Signed-off-by: Mark Salter > > --- > > arch/arm64/kernel/vmlinux.lds.S | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/arch/arm64/kernel/vmlinux.lds.S > > b/arch/arm64/kernel/vmlinux.lds.S > > index f5e5574..f8ab9d8 100644 > > --- a/arch/arm64/kernel/vmlinux.lds.S > > +++ b/arch/arm64/kernel/vmlinux.lds.S > > @@ -71,6 +71,7 @@ SECTIONS > > > > RO_DATA(PAGE_SIZE) > > EXCEPTION_TABLE(8) > > + NOTES > > _etext = .; /* End of text and rodata section */ > > > > . = ALIGN(PAGE_SIZE); > > @@ -122,8 +123,6 @@ SECTIONS > > } > > _edata_loc = __data_loc + SIZEOF(.data); > > > > - NOTES > > - > > BSS_SECTION(0, 0, 0) > > _end = .; > > The _edata is set before NOTES, so I don't fully understand where the > problem is. > The problem *is* _edata before the NOTES. We need a symbol to mark the end of initialized data. This should be _edata but _edata doesn't currently account for NOTES. In the EFI stub I'm working on, the PE/COFF header needs to know the end of the image. If we use _edata, we wouldn't include NOTES, so we're left with __bss_start. But _bss_start may not be exactly right because of alignment rounding and it is ugly to use for that purpose. So we either need a new symbol following NOTES, or move _edata past NOTES, or move NOTES. I chose the latter because NOTES are readonly and don't really need to be part of the RW segment. --Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] Add shared update_fdt() function for ARM/ARM64
On Thu, 2013-10-03 at 10:52 +0100, Matt Fleming wrote: > > +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64) > > +static efi_status_t update_fdt(efi_system_table_t *sys_table, void > > *orig_fdt, > > +void *fdt, int new_fdt_size, char *cmdline_ptr, > > +u64 initrd_addr, u64 initrd_size, > > +efi_memory_desc_t *memory_map, > > +unsigned long map_size, unsigned long > > desc_size, > > +u32 desc_ver) > > Hmm... does this function really belong in efi-stub-helper.c? That file > should be for architecture independent functionality only. > It isn't really arm-specific although arm is the only user right now. We're using the FDT to pass EFI boot info that is passed in the boot params block on x86. So potentially other architectures could use the same code. How about making it someting like: #ifdef ARCH_NEEDS_EFI_FDT static efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt, ... #endif so the architecture can decide whether to include it or not. --Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/6] Add shared update_fdt() function for ARM/ARM64
On Thu, 2013-10-03 at 15:27 +0100, Matt Fleming wrote: > On Thu, 03 Oct, at 09:43:24AM, Mark Salter wrote: > > On Thu, 2013-10-03 at 10:52 +0100, Matt Fleming wrote: > > > > +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64) > > > > +static efi_status_t update_fdt(efi_system_table_t *sys_table, void > > > > *orig_fdt, > > > > +void *fdt, int new_fdt_size, char > > > > *cmdline_ptr, > > > > +u64 initrd_addr, u64 initrd_size, > > > > +efi_memory_desc_t *memory_map, > > > > +unsigned long map_size, unsigned long > > > > desc_size, > > > > +u32 desc_ver) > > > > > > Hmm... does this function really belong in efi-stub-helper.c? That file > > > should be for architecture independent functionality only. > > > > > > > It isn't really arm-specific although arm is the only user right now. > > We're using the FDT to pass EFI boot info that is passed in the boot > > params block on x86. So potentially other architectures could use the > > same code. > > It's not EFI-specific either, apart from the fdt property names. Not EFI-specific in the sense that it uses the EFI services, but it is EFI-specific in its function. > > > How about making it someting like: > > > > #ifdef ARCH_NEEDS_EFI_FDT > > static efi_status_t update_fdt(efi_system_table_t *sys_table, void > > *orig_fdt, > > ... > > #endif > > > > so the architecture can decide whether to include it or not. > > Is one implementation of this function going to fit all architectures? > Can we be sure of that ahead of time? > > I'd prefer this to be kept in arch/ for now, and possibly moved into > efi-stub-helper.c at a later date if indeed it turns out to be generally > useful. Fair enough. I don't have a strong opinion about it either way. Just a natural instinct to share the code if possible, but it is easy enough to change later if others want to use it. --Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64: add early_ioremap support
EFI runtime support needs to make temporary short term mappings at early
boot time before ioremap is available. This patch adds support for such
early mappings based on "fixmap" support found in a number of other
architectures. This also allows for a number of permanent mappings which
may need to persist beyond paging_init(). This implementation uses the
2MiB of address space currently dedicated to the earlyprintk console
registers. This allows for mapping up to 32 64K pages or 512 4K pages.
Signed-off-by: Mark Salter
---
Documentation/arm64/memory.txt | 2 +-
arch/arm64/include/asm/fixmap.h | 117
arch/arm64/include/asm/io.h | 6 +
arch/arm64/include/asm/memory.h | 2 +-
arch/arm64/kernel/early_printk.c | 8 +-
arch/arm64/kernel/head.S | 9 +-
arch/arm64/kernel/setup.c| 3 +
arch/arm64/mm/ioremap.c | 285 +++
arch/arm64/mm/mmu.c | 41 --
9 files changed, 422 insertions(+), 51 deletions(-)
create mode 100644 arch/arm64/include/asm/fixmap.h
diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt
index 78a37712..f2bf9e1 100644
--- a/Documentation/arm64/memory.txt
+++ b/Documentation/arm64/memory.txt
@@ -35,7 +35,7 @@ ffbc ffbd 8GB
vmemmap
ffbe ffbffbbf ~8GB [guard, future
vmmemap]
-ffbffbc0 ffbffbdf 2MB earlyprintk
device
+ffbffbc0 ffbffbdf 2MB fixed mappings
ffbffbe0 ffbffbe0 64KB PCI I/O space
diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
new file mode 100644
index 000..e73b219
--- /dev/null
+++ b/arch/arm64/include/asm/fixmap.h
@@ -0,0 +1,117 @@
+/*
+ * fixmap.h: compile-time virtual memory allocation
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 1998 Ingo Molnar
+ *
+ */
+
+#ifndef _ASM_ARM64_FIXMAP_H
+#define _ASM_ARM64_FIXMAP_H
+
+#ifndef __ASSEMBLY__
+#include
+#include
+
+/*
+ * Here we define all the compile-time 'special' virtual
+ * addresses. The point is to have a constant address at
+ * compile time, but to set the physical address only
+ * in the boot process.
+ *
+ * These 'compile-time allocated' memory buffers are
+ * page-sized. Use set_fixmap(idx,phys) to associate
+ * physical memory with fixmap indices.
+ *
+ */
+enum fixed_addresses {
+ FIX_EARLYCON,
+ __end_of_permanent_fixed_addresses,
+
+ /*
+* Temporary boot-time mappings, used by early_ioremap(),
+* before ioremap() is functional.
+*/
+#ifdef CONFIG_ARM64_64K_PAGES
+#define NR_FIX_BTMAPS 4
+#else
+#define NR_FIX_BTMAPS 64
+#endif
+#define FIX_BTMAPS_SLOTS 7
+#define TOTAL_FIX_BTMAPS (NR_FIX_BTMAPS * FIX_BTMAPS_SLOTS)
+ FIX_BTMAP_END = __end_of_permanent_fixed_addresses,
+ FIX_BTMAP_BEGIN = FIX_BTMAP_END + TOTAL_FIX_BTMAPS - 1,
+ __end_of_fixed_addresses
+};
+
+#define FIXADDR_SIZE (__end_of_permanent_fixed_addresses << PAGE_SHIFT)
+#define FIXADDR_BOOT_SIZE (__end_of_fixed_addresses << PAGE_SHIFT)
+#define FIXADDR_START (FIXADDR_TOP - FIXADDR_SIZE)
+#define FIXADDR_BOOT_START (FIXADDR_TOP - FIXADDR_BOOT_SIZE)
+
+extern void __set_fixmap(enum fixed_addresses idx,
+phys_addr_t phys, pgprot_t flags);
+
+#define set_fixmap(idx, phys) \
+ __set_fixmap(idx, phys, PAGE_KERNEL)
+
+#define set_fixmap_io(idx, phys) \
+ __set_fixmap(idx, phys, __pgprot(PROT_DEVICE_nGnRE))
+
+#define clear_fixmap(idx) \
+ __set_fixmap(idx, 0, __pgprot(0))
+
+#define __fix_to_virt(x) (FIXADDR_TOP - ((x) << PAGE_SHIFT))
+#define __virt_to_fix(x) ((FIXADDR_TOP - ((x)&PAGE_MASK)) >> PAGE_SHIFT)
+
+extern void __this_fixmap_does_not_exist(void);
+
+/*
+ * 'index to address' translation. If anyone tries to use the idx
+ * directly without translation, we catch the bug with a NULL-deference
+ * kernel oops. Illegal ranges of incoming indices are caught too.
+ */
+static __always_inline unsigned long fix_to_virt(const unsigned int idx)
+{
+ /*
+* this branch gets completely eliminated after inlining,
+* except when someone tries to use fixaddr indices in an
+* illegal way. (such as mixing up address types or using
+* out-of-range indices).
+*
+* If it doesn't get removed, the linker will complain
+* loudly with a reasonably clear error message..
+*/
+ if (idx >= __end_of_fixed_addresses)
+ __this_fixm
Re: [PATCH] arm64: add early_ioremap support
On Fri, 2013-10-04 at 16:04 +0100, Catalin Marinas wrote:
> Hi Mark,
>
> > --- /dev/null
> > +++ b/arch/arm64/include/asm/fixmap.h
> > @@ -0,0 +1,117 @@
> > +/*
> > + * fixmap.h: compile-time virtual memory allocation
> > + *
> > + * This file is subject to the terms and conditions of the GNU General
> > Public
> > + * License. See the file "COPYING" in the main directory of this archive
> > + * for more details.
> > + *
> > + * Copyright (C) 1998 Ingo Molnar
> > + *
> > + */
>
> I can see several architectures having very similar macros/functions in
> fixmap.h. It would make sense to create a generic fixmap.h holding at
> least the fix_to_virt and related macros, FIXADDR_START etc. with enum
> fixed_addresses in arch code.
Right, there are a quite a few using similar fixmap code. I actually
looked at consolidating them, but I gave up so that I could get
something working for EFI work in progress. But yeah, I think I
will step back and have another go at it. I think I can get at a
few of the architectures using common code and make it so others
can be converted as desired.
>
> > --- a/arch/arm64/kernel/setup.c
> > +++ b/arch/arm64/kernel/setup.c
> > @@ -42,6 +42,7 @@
> > #include
> > #include
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -252,6 +253,8 @@ void __init setup_arch(char **cmdline_p)
> >
> > *cmdline_p = boot_command_line;
> >
> > + early_ioremap_init();
> > +
> > parse_early_param();
>
> Should the early_ioremap_init() call happen after parse_early_param()?
> Is early_ioremap_debug initialised already?
No, early_ioremap_debug is not initialized which makes the debug
prints in early_ioremap_init() unreachable. I'll fix that. On x86,
the init comes first, but there is other code between that and
parse_early_param() which uses early_ioremap(). Not the case for
arm64.
>
> > --- a/arch/arm64/mm/ioremap.c
> > +++ b/arch/arm64/mm/ioremap.c
> > @@ -25,6 +25,10 @@
> > #include
> > #include
> >
> > +#include
> > +#include
> > +#include
> > +
> > static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size,
> > pgprot_t prot, void *caller)
> > {
> > @@ -82,3 +86,284 @@ void __iounmap(volatile void __iomem *io_addr)
> > vunmap(addr);
> > }
> > EXPORT_SYMBOL(__iounmap);
> > +
> > +static int early_ioremap_debug __initdata;
> > +
> > +static int __init early_ioremap_debug_setup(char *str)
> > +{
> > + early_ioremap_debug = 1;
> > +
> > + return 0;
> > +}
> > +early_param("early_ioremap_debug", early_ioremap_debug_setup);
> > +
> > +static int after_paging_init __initdata;
> > +#ifndef CONFIG_ARM64_64K_PAGES
> > +static pte_t bm_pte[PAGE_SIZE/sizeof(pte_t)] __page_aligned_bss;
> > +#endif
>
> bm_pte[PTRS_PER_PTE];
ok
>
> > +
> > +static inline pmd_t * __init early_ioremap_pmd(unsigned long addr)
> > +{
> > + pgd_t *pgd = &swapper_pg_dir[pgd_index(addr)];
>
> pgd_offset_k(addr);
ok
>
> > + pud_t *pud = pud_offset(pgd, addr);
> > + pmd_t *pmd = pmd_offset(pud, addr);
> > +
> > + return pmd;
> > +}
> > +
> > +static inline pte_t * __init early_ioremap_pte(unsigned long addr)
> > +{
> > +#ifdef CONFIG_ARM64_64K_PAGES
> > + pmd_t *pmd = early_ioremap_pmd(addr);
> > + return pte_offset_kernel(pmd, addr);
> > +#else
> > + return &bm_pte[pte_index(addr)];
> > +#endif
>
> If we populate the pmd correctly with 4K pages (and I think we do in
> early_ioremap_init()), can we not just use this function without the
> #ifdef-else part (always pte_offset_kernel())?
Ah, yes. Nice!
>
> > +static unsigned long slot_virt[FIX_BTMAPS_SLOTS] __initdata;
> > +
> > +void __init early_ioremap_init(void)
> > +{
> > + pmd_t *pmd;
> > + int i;
> > +
> > + if (early_ioremap_debug)
> > + pr_info("early_ioremap_init()\n");
> > +
> > + for (i = 0; i < FIX_BTMAPS_SLOTS; i++)
> > + slot_virt[i] = __fix_to_virt(FIX_BTMAP_BEGIN -
> > NR_FIX_BTMAPS*i);
> > +
> > + pmd = early_ioremap_pmd(fix_to_virt(FIX_BTMAP_BEGIN));
> > +#ifndef CONFIG_ARM64_64K_PAGES
> > + /* need to populate pmd for 4k pagesize only */
> > + memset(bm_pte, 0, sizeof(bm_pte));
>
> Do we need memset() here? bm_pte[] is placed in the .bss section.
No we don't. If .bss isn't cleared here, we have bigger problems.
>
> > + pmd_populate_kernel(&init_mm, pmd, bm_pte);
> > +#endif
> > +
> > + /*
> > +* The boot-ioremap range spans multiple pmds, for which
> > +* we are not prepared:
> > +*/
> > +#define __FIXADDR_TOP (-PAGE_SIZE)
> > + BUILD_BUG_ON((__fix_to_virt(FIX_BTMAP_BEGIN) >> PMD_SHIFT)
> > +!= (__fix_to_virt(FIX_BTMAP_END) >> PMD_SHIFT));
> > +#undef __FIXADDR_TOP
>
> Why this #define/#undef? FIXADDR_TOP is statically defined.
Right. Copy and paste from x86 where is isn't static, so the trick to
trigger a BUILD_BUG_ON isn't needed here.
>
>
Re: [PATCH] c6x: remove unused parameter in Kconfig
On Mon, 2013-07-08 at 07:09 +0200, Michael Opdenacker wrote: > This patch proposes to remove the TMS320C6X_CACHES_ON kernel configuration > parameter defined in arch/c6x/Kconfig, but used nowhere > in the makefiles and source code. > > Signed-off-by: Michael Opdenacker > --- Acked by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/28] c6x: use early_init_dt_scan
On Mon, 2013-09-16 at 18:09 -0500, Rob Herring wrote: > From: Rob Herring > > Convert c6x to use new early_init_dt_scan function. > > Signed-off-by: Rob Herring > Cc: Mark Salter > Cc: Aurelien Jacquiot > Cc: linux-c6x-...@linux-c6x.org > --- > arch/c6x/kernel/devicetree.c | 19 --- > arch/c6x/kernel/setup.c | 2 +- > 2 files changed, 1 insertion(+), 20 deletions(-) Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/28] c6x: use boot_command_line instead of private c6x_command_line
On Mon, 2013-09-16 at 18:08 -0500, Rob Herring wrote:
> From: Rob Herring
>
> Save some pointless copying of the kernel command line and just use
> boot_command_line instead.
>
> Also remove default_command_line as it is not referenced anywhere, and
> the DT code already handles the default command line.
>
The default_command_line is leftover cruft from the kernel before it was
upstreamed. It was a mechanism to place the commandline at a known fixed
offset in the Image. It was needed for simple (serial eeprom based)
loaders which didn't know about DT. Anyway, bits of that support are
missing, so I don't see a reason to keep it around. If anyone complains
we can add it back in as a completely functional patch. There is also
a fragment of arch/c6x/kernel/vmlinux.lds.S which should also be
removed:
diff --git a/arch/c6x/kernel/vmlinux.lds.S b/arch/c6x/kernel/vmlinux.lds.S
index 279d807..5a6e141 100644
--- a/arch/c6x/kernel/vmlinux.lds.S
+++ b/arch/c6x/kernel/vmlinux.lds.S
@@ -37,12 +37,6 @@ SECTIONS
_vectors_end = .;
}
- . = ALIGN(0x1000);
- .cmdline :
- {
- *(.cmdline)
- }
-
/*
* This section contains data which may be shared with other
* cores. It needs to be a fixed offset from PAGE_OFFSET
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RESEND] c6x: remove unused parameter in Kconfig
On Tue, 2013-09-17 at 05:21 +0200, Michael Opdenacker wrote: > This patch proposes to remove the TMS320C6X_CACHES_ON kernel configuration > parameter defined in arch/c6x/Kconfig, but used nowhere > in the makefiles and source code. > > Signed-off-by: Michael Opdenacker > Acked by: Mark Salter Thanks for the reminder. I have added it to the c6x tree now. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Kconfig cleanup (PARPORT_PC dependencies)
On Thu, 2013-09-12 at 15:04 -0400, Chris Metcalf wrote: > On 9/12/2013 2:53 PM, Mark Salter wrote: > > Remove messy dependencies from PARPORT_PC by having it depend on one > > Kconfig symbol (ARCH_MAY_HAVE_PC_PARPORT) and having architectures > > which need it declare ARCH_MAY_HAVE_PC_PARPORT in arch/*/Kconfig. > > New architectures are unlikely to need PARPORT_PC, so this avoids > > having an ever growing list of architectures to exclude. Those > > architectures which do declare ARCH_MAY_HAVE_PC_PARPORT in this > > patch are the ones which have an asm/parport.h. > > > > Signed-off-by: Mark Salter > > You can actually omit the arch/tile change, since as far as I know there's no > way for tile to have PARPORT_PC. > Yeah, I thought that the list of architectures in the patch would end up being a superset of what was really needed. Especially for those which used the generic parport.h. I can drop tile from this patch but you may want to get rid of the parport.h from arch/tile/include/asm/Kbuild. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Kconfig cleanup (PARPORT_PC dependencies)
Remove messy dependencies from PARPORT_PC by having it depend on one Kconfig symbol (ARCH_MAY_HAVE_PC_PARPORT) and having architectures which need it declare ARCH_MAY_HAVE_PC_PARPORT in arch/*/Kconfig. New architectures are unlikely to need PARPORT_PC, so this avoids having an ever growing list of architectures to exclude. Those architectures which do declare ARCH_MAY_HAVE_PC_PARPORT in this patch are the ones which have an asm/parport.h. Signed-off-by: Mark Salter --- arch/alpha/Kconfig | 3 +++ arch/arc/Kconfig| 3 +++ arch/arm/Kconfig| 3 +++ arch/ia64/Kconfig | 3 +++ arch/m68k/Kconfig | 4 arch/microblaze/Kconfig | 3 +++ arch/mips/Kconfig | 3 +++ arch/parisc/Kconfig | 3 +++ arch/powerpc/Kconfig| 3 +++ arch/sh/Kconfig | 3 +++ arch/sparc/Kconfig | 4 arch/tile/Kconfig | 3 +++ arch/unicore32/Kconfig | 3 +++ arch/x86/Kconfig| 3 +++ drivers/parport/Kconfig | 4 +--- 15 files changed, 45 insertions(+), 3 deletions(-) diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 082d9b4..0f8fa2c 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -520,6 +520,9 @@ config EISA config ARCH_MAY_HAVE_PC_FDC def_bool y +config ARCH_MAY_HAVE_PC_PARPORT + def_bool y + config SMP bool "Symmetric multi-processing support" depends on ALPHA_SABLE || ALPHA_LYNX || ALPHA_RAWHIDE || ALPHA_DP264 || ALPHA_WILDFIRE || ALPHA_TITAN || ALPHA_GENERIC || ALPHA_SHARK || ALPHA_MARVEL diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index 68fcbb2..fb24bb2 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -70,6 +70,9 @@ config HAVE_LATENCYTOP_SUPPORT config NO_DMA def_bool n +config ARCH_MAY_HAVE_PC_PARPORT + def_bool y + source "init/Kconfig" source "kernel/Kconfig.freezer" diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index b5eee26..5ded688 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -71,6 +71,9 @@ config ARM Europe. There is an ARM Linux project with a web page at <http://www.arm.linux.org.uk/>. +config ARCH_MAY_HAVE_PC_PARPORT + def_bool y + config ARM_HAS_SG_CHAIN bool diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index a86a56d..3ae7dd3 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -126,6 +126,9 @@ config AUDIT_ARCH bool default y +config ARCH_MAY_HAVE_PC_PARPORT + def_bool y + menuconfig PARAVIRT_GUEST bool "Paravirtualized guest support" depends on BROKEN diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig index 821170e..dadea9a 100644 --- a/arch/m68k/Kconfig +++ b/arch/m68k/Kconfig @@ -35,6 +35,10 @@ config ARCH_HAS_ILOG2_U32 config ARCH_HAS_ILOG2_U64 bool +config ARCH_MAY_HAVE_PC_PARPORT + depends on ISA + def_bool y + config GENERIC_HWEIGHT bool default y diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig index 3f6659c..00c3443 100644 --- a/arch/microblaze/Kconfig +++ b/arch/microblaze/Kconfig @@ -67,6 +67,9 @@ config LOCKDEP_SUPPORT config HAVE_LATENCYTOP_SUPPORT def_bool y +config ARCH_MAY_HAVE_PC_PARPORT + def_bool y + source "init/Kconfig" source "kernel/Kconfig.freezer" diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 71f15e7..e8d5d33 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -861,6 +861,9 @@ config FW_ARC config ARCH_MAY_HAVE_PC_FDC bool +config ARCH_MAY_HAVE_PC_PARPORT + def_bool y + config BOOT_RAW bool diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index aa399a5..d2dcd1b 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -102,6 +102,9 @@ config ARCH_MAY_HAVE_PC_FDC depends on BROKEN default y +config ARCH_MAY_HAVE_PC_PARPORT + def_bool y + source "init/Kconfig" source "kernel/Kconfig.freezer" diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 6b7530f..e706eea 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -169,6 +169,9 @@ config ARCH_MAY_HAVE_PC_FDC bool default !PPC_PSERIES || PCI +config ARCH_MAY_HAVE_PC_PARPORT + def_bool y + config PPC_OF def_bool y diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index 1018ed3..f49c057 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -143,6 +143,9 @@ config HAVE_LATENCYTOP_SUPPORT config ARCH_HAS_ILOG2_U32 def_bool n +config ARCH_MAY_HAVE_PC_PARPORT + def_bool y + config ARCH_HAS_ILOG2_U64 def_bool n diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig index 1570ad2..493867e 100644 --- a/arch/sparc/Kconfig +++ b/arch/sparc/Kconfig @@ -197,6 +197,10 @@ config ARCH_MAY_HAVE_PC_FDC bool default y +config ARCH_MAY_HAVE_PC_PARPORT + depends on SPARC64 && PCI + def_bool y + config EMULATED_CMPXCHG bool default
Re: [PATCH] Kconfig cleanup (PARPORT_PC dependencies)
On Thu, 2013-09-12 at 22:32 +0200, Sam Ravnborg wrote: > It is much nicer if you provide a config symbol only once. > And then let the architectures who want it select this symbol. > > This is the pattern we use for similar things in many places today, > so it is best to follow that pattern. Okay, I'm ahead of you on that. I actually had two versions of the patch. The other uses select. If that is the preferred way these days, I'll go with it for V2 of the patch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 01/29] c6x: use boot_command_line instead of private c6x_command_line
On Mon, 2013-10-07 at 11:29 -0500, Rob Herring wrote: > From: Rob Herring > > Save some pointless copying of the kernel command line and just use > boot_command_line instead. > > Also remove default_command_line as it is not referenced anywhere, and > the DT code already handles the default command line. > > Signed-off-by: Rob Herring > Cc: Mark Salter > Cc: Aurelien Jacquiot > Cc: linux-c6x-...@linux-c6x.org > Reviewed-by: Grant Likely > --- Tested and Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 04/14] ia64: select ARCH_MAY_HAVE_PC_PARPORT
Architectures which support CONFIG_PARPORT_PC should select ARCH_MAY_HAVE_PC_PARPORT. Signed-off-by: Mark Salter CC: Tony Luck CC: Fenghua Yu CC: linux-i...@vger.kernel.org --- arch/ia64/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 7740ab1..f88117a 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -6,6 +6,7 @@ menu "Processor type and features" config IA64 bool + select ARCH_MAY_HAVE_PC_PARPORT select PCI if (!IA64_HP_SIM) select ACPI if (!IA64_HP_SIM) select PM if (!IA64_HP_SIM) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 01/14] alpha: select ARCH_MAY_HAVE_PC_PARPORT
Architectures which support CONFIG_PARPORT_PC should select ARCH_MAY_HAVE_PC_PARPORT. Signed-off-by: Mark Salter Acked-by: Richard Henderson CC: linux-al...@vger.kernel.org --- arch/alpha/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 35a300d..626949c 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -1,6 +1,7 @@ config ALPHA bool default y + select ARCH_MAY_HAVE_PC_PARPORT select HAVE_AOUT select HAVE_IDE select HAVE_OPROFILE -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 13/14] x86: select ARCH_MAY_HAVE_PC_PARPORT
Architectures which support CONFIG_PARPORT_PC should select ARCH_MAY_HAVE_PC_PARPORT. Signed-off-by: Mark Salter CC: Thomas Gleixner CC: Ingo Molnar CC: "H. Peter Anvin" CC: x...@kernel.org --- arch/x86/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index ee2fb9d..72fca40 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -22,6 +22,7 @@ config X86_64 config X86 def_bool y select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS + select ARCH_MAY_HAVE_PC_PARPORT select HAVE_AOUT if X86_32 select HAVE_UNSTABLE_SCHED_CLOCK select ARCH_SUPPORTS_NUMA_BALANCING -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 12/14] unicore32: select ARCH_MAY_HAVE_PC_PARPORT
Architectures which support CONFIG_PARPORT_PC should select ARCH_MAY_HAVE_PC_PARPORT. Signed-off-by: Mark Salter CC: Guan Xuetao --- arch/unicore32/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig index 82cdd89..9e0b8bd 100644 --- a/arch/unicore32/Kconfig +++ b/arch/unicore32/Kconfig @@ -1,5 +1,6 @@ config UNICORE32 def_bool y + select ARCH_MAY_HAVE_PC_PARPORT select HAVE_MEMBLOCK select HAVE_GENERIC_DMA_COHERENT select HAVE_DMA_ATTRS -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 09/14] powerpc: select ARCH_MAY_HAVE_PC_PARPORT
Architectures which support CONFIG_PARPORT_PC should select ARCH_MAY_HAVE_PC_PARPORT. Signed-off-by: Mark Salter CC: Benjamin Herrenschmidt CC: Paul Mackerras CC: linuxppc-...@lists.ozlabs.org --- arch/powerpc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 38f3b7e..9211207 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -85,6 +85,7 @@ config GENERIC_HWEIGHT config PPC bool default y + select ARCH_MAY_HAVE_PC_PARPORT select BINFMT_ELF select OF select OF_EARLY_FLATTREE -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 06/14] microblaze: select ARCH_MAY_HAVE_PC_PARPORT
Architectures which support CONFIG_PARPORT_PC should select ARCH_MAY_HAVE_PC_PARPORT. Signed-off-by: Mark Salter CC: Michal Simek CC: microblaze-ucli...@itee.uq.edu.au --- arch/microblaze/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig index b82f82b..19caa61 100644 --- a/arch/microblaze/Kconfig +++ b/arch/microblaze/Kconfig @@ -1,5 +1,6 @@ config MICROBLAZE def_bool y + select ARCH_MAY_HAVE_PC_PARPORT select HAVE_MEMBLOCK select HAVE_MEMBLOCK_NODE_MAP select HAVE_FUNCTION_TRACER -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 10/14] sh: select ARCH_MAY_HAVE_PC_PARPORT
Architectures which support CONFIG_PARPORT_PC should select ARCH_MAY_HAVE_PC_PARPORT. Signed-off-by: Mark Salter CC: Paul Mundt CC: linux...@vger.kernel.org --- arch/sh/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index 224f4bc..a5d1d2e 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -1,5 +1,6 @@ config SUPERH def_bool y + select ARCH_MAY_HAVE_PC_PARPORT select EXPERT select CLKDEV_LOOKUP select HAVE_IDE if HAS_IOPORT -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 11/14] sparc: select ARCH_MAY_HAVE_PC_PARPORT
Architectures which support CONFIG_PARPORT_PC should select ARCH_MAY_HAVE_PC_PARPORT. Signed-off-by: Mark Salter CC: "David S. Miller" CC: sparcli...@vger.kernel.org --- arch/sparc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig index 78c4fdb..362229a 100644 --- a/arch/sparc/Kconfig +++ b/arch/sparc/Kconfig @@ -12,6 +12,7 @@ config 64BIT config SPARC bool default y + select ARCH_MAY_HAVE_PC_PARPORT if SPARC64 && PCI select OF select OF_PROMTREE select HAVE_IDE -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 08/14] parisc: select ARCH_MAY_HAVE_PC_PARPORT
Architectures which support CONFIG_PARPORT_PC should select ARCH_MAY_HAVE_PC_PARPORT. Signed-off-by: Mark Salter CC: "James E.J. Bottomley" CC: Helge Deller CC: linux-par...@vger.kernel.org --- arch/parisc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index ad2ce8d..9af24ac 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -1,6 +1,7 @@ config PARISC def_bool y select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS + select ARCH_MAY_HAVE_PC_PARPORT select HAVE_IDE select HAVE_OPROFILE select HAVE_FUNCTION_TRACER if 64BIT -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 02/14] arc: select ARCH_MAY_HAVE_PC_PARPORT
Architectures which support CONFIG_PARPORT_PC should select ARCH_MAY_HAVE_PC_PARPORT. Signed-off-by: Mark Salter CC: Vineet Gupta --- arch/arc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index 91dbb27..484b1a7 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -8,6 +8,7 @@ config ARC def_bool y + select ARCH_MAY_HAVE_PC_PARPORT select CLONE_BACKWARDS # ARC Busybox based initramfs absolutely relies on DEVTMPFS for /dev select DEVTMPFS if !INITRAMFS_SOURCE="" -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 00/14] Kconfig cleanup (PARPORT_PC dependencies)
This patch series removes the messy dependencies from PARPORT_PC by having it depend on one symbol (ARCH_MAY_HAVE_PC_PARPORT) and having architectures which need it, select ARCH_MAY_HAVE_PC_PARPORT in arch/*/Kconfig. New architectures are unlikely to need PARPORT_PC, so this avoids having an ever growing list of architectures to exclude. Those architectures which do select ARCH_MAY_HAVE_PC_PARPORT in this patch are the ones which have an asm/parport.h (or use the generic version). V1 or this patch can be found here: http://www.spinics.net/lists/linux-arch/msg23167.html V2 changes: * Use select instead of adding config option to arch/*/Kconfig * Split into multiple patches for individual architectures * Dropped tile architecture Mark Salter (14): alpha: select ARCH_MAY_HAVE_PC_PARPORT arc: select ARCH_MAY_HAVE_PC_PARPORT arm: select ARCH_MAY_HAVE_PC_PARPORT ia64: select ARCH_MAY_HAVE_PC_PARPORT m68k: select ARCH_MAY_HAVE_PC_PARPORT microblaze: select ARCH_MAY_HAVE_PC_PARPORT mips: select ARCH_MAY_HAVE_PC_PARPORT parisc: select ARCH_MAY_HAVE_PC_PARPORT powerpc: select ARCH_MAY_HAVE_PC_PARPORT sh: select ARCH_MAY_HAVE_PC_PARPORT sparc: select ARCH_MAY_HAVE_PC_PARPORT unicore32: select ARCH_MAY_HAVE_PC_PARPORT x86: select ARCH_MAY_HAVE_PC_PARPORT Kconfig cleanup (PARPORT_PC dependencies) arch/alpha/Kconfig | 1 + arch/arc/Kconfig| 1 + arch/arm/Kconfig| 1 + arch/ia64/Kconfig | 1 + arch/m68k/Kconfig | 1 + arch/microblaze/Kconfig | 1 + arch/mips/Kconfig | 1 + arch/parisc/Kconfig | 1 + arch/powerpc/Kconfig| 1 + arch/sh/Kconfig | 1 + arch/sparc/Kconfig | 1 + arch/unicore32/Kconfig | 1 + arch/x86/Kconfig| 1 + drivers/parport/Kconfig | 10 +++--- 14 files changed, 20 insertions(+), 3 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 07/14] mips: select ARCH_MAY_HAVE_PC_PARPORT
Architectures which support CONFIG_PARPORT_PC should select ARCH_MAY_HAVE_PC_PARPORT. Signed-off-by: Mark Salter CC: Ralf Baechle CC: linux-m...@linux-mips.org --- arch/mips/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index f75ab4a..199fde67 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -1,6 +1,7 @@ config MIPS bool default y + select ARCH_MAY_HAVE_PC_PARPORT select HAVE_CONTEXT_TRACKING select HAVE_GENERIC_DMA_COHERENT select HAVE_IDE -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 05/14] m68k: select ARCH_MAY_HAVE_PC_PARPORT
Architectures which support CONFIG_PARPORT_PC should select ARCH_MAY_HAVE_PC_PARPORT. Signed-off-by: Mark Salter Acked by: Geert Uytterhoeven CC: linux-m...@lists.linux-m68k.org --- arch/m68k/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig index 311a300..0d88a0b 100644 --- a/arch/m68k/Kconfig +++ b/arch/m68k/Kconfig @@ -1,6 +1,7 @@ config M68K bool default y + select ARCH_MAY_HAVE_PC_PARPORT if ISA select HAVE_IDE select HAVE_AOUT if MMU select HAVE_DEBUG_BUGVERBOSE -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 03/14] arm: select ARCH_MAY_HAVE_PC_PARPORT
Architectures which support CONFIG_PARPORT_PC should select ARCH_MAY_HAVE_PC_PARPORT. Signed-off-by: Mark Salter CC: Russell King CC: linux-arm-ker...@lists.infradead.org --- arch/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 1ad6fb6..2734ec1 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -5,6 +5,7 @@ config ARM select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST select ARCH_HAVE_CUSTOM_GPIO_H + select ARCH_MAY_HAVE_PC_PARPORT select ARCH_WANT_IPC_PARSE_VERSION select BUILDTIME_EXTABLE_SORT if MMU select CLONE_BACKWARDS -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: add asm-generic parport.h
On Mon, 2013-10-07 at 16:44 -0500, Rob Herring wrote: > From: Rob Herring > > Add asm-generic/parport.h to help fix allyesconfig builds. > See: http://www.spinics.net/lists/arm-kernel/msg267957.html http://www.spinics.net/lists/linux-arch/msg23167.html and finally, https://lkml.org/lkml/2013/10/8/12 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/29] c6x: Use get_signal() signal_setup_done()
On Tue, 2013-10-08 at 13:27 +0200, Richard Weinberger wrote: > Use the more generic functions get_signal() signal_setup_done() > for signal delivery. > > Signed-off-by: Richard Weinberger > --- > arch/c6x/kernel/signal.c | 43 > ++- > 1 file changed, 18 insertions(+), 25 deletions(-) Tested-by: Mark Salter Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64: add PAGE_ALIGNED_DATA to linker script
The arm64 linker script doesn't use the PAGE_ALIGNED_DATA macro which leads to a ".data..page_aligned" section being placed between the end of .data and start of .bss: % readelf -e vmlinux ... Section to Segment mapping: Segment Sections... 00 .head.text .text .text.init .rodata __ksymtab __ksymtab_gpl \ __ksymtab_strings __param __modver __ex_table .notes \ .init.text .init.data .data..percpu .data .data..page_aligned .bss This causes problems for the EFI stub which may have to relocate the kernel image based on stext and _edata symbols. This patch adds PAGE_ALIGNED_DATA() to the linker script inside the the .data section. Signed-off-by: Mark Salter --- arch/arm64/kernel/vmlinux.lds.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S index f8ab9d8..e441556 100644 --- a/arch/arm64/kernel/vmlinux.lds.S +++ b/arch/arm64/kernel/vmlinux.lds.S @@ -110,6 +110,7 @@ SECTIONS */ INIT_TASK_DATA(THREAD_SIZE) NOSAVE_DATA + PAGE_ALIGNED_DATA(PAGE_SIZE) CACHELINE_ALIGNED_DATA(64) READ_MOSTLY_DATA(64) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: add PAGE_ALIGNED_DATA to linker script
On Wed, 2013-10-09 at 11:14 +0100, Will Deacon wrote: > On Tue, Oct 08, 2013 at 09:37:39PM +0100, Mark Salter wrote: > > The arm64 linker script doesn't use the PAGE_ALIGNED_DATA macro which > > leads to a ".data..page_aligned" section being placed between the end > > of .data and start of .bss: > > > > % readelf -e vmlinux > >... > > Section to Segment mapping: > > Segment Sections... > >00 .head.text .text .text.init .rodata __ksymtab __ksymtab_gpl \ > > __ksymtab_strings __param __modver __ex_table .notes \ > > .init.text .init.data .data..percpu .data .data..page_aligned .bss > > > > This causes problems for the EFI stub which may have to relocate the > > kernel image based on stext and _edata symbols. > > > > This patch adds PAGE_ALIGNED_DATA() to the linker script inside the > > the .data section. > > > > Signed-off-by: Mark Salter > > --- > > arch/arm64/kernel/vmlinux.lds.S | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/arm64/kernel/vmlinux.lds.S > > b/arch/arm64/kernel/vmlinux.lds.S > > index f8ab9d8..e441556 100644 > > --- a/arch/arm64/kernel/vmlinux.lds.S > > +++ b/arch/arm64/kernel/vmlinux.lds.S > > @@ -110,6 +110,7 @@ SECTIONS > > */ > > INIT_TASK_DATA(THREAD_SIZE) > > NOSAVE_DATA > > + PAGE_ALIGNED_DATA(PAGE_SIZE) > > CACHELINE_ALIGNED_DATA(64) > > READ_MOSTLY_DATA(64) > > Can we just replace this chunk with RW_DATA_SECTION(64, PAGE_SIZE, > THREAD_SIZE) instead? Possibly. The layout of the included macros is the same. The only difference being the placement of _data, _sdata, and _edata inside .data and the use of __data_loc. --Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] status of execve() work - per-architecture patches solicited
C6X works fine with these patches to switch over to generic code. Mark Salter (2): c6x: implement ret_from_kernel_execve() and switch to generic kernel_execve() c6x: switch to generic sys_execve() arch/c6x/include/asm/syscalls.h |5 --- arch/c6x/include/asm/unistd.h |3 ++ arch/c6x/kernel/entry.S | 54 +- arch/c6x/kernel/process.c | 22 4 files changed, 27 insertions(+), 57 deletions(-) -- 1.7.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] c6x: implement ret_from_kernel_execve() and switch to generic kernel_execve()
Signed-off-by: Mark Salter --- arch/c6x/include/asm/unistd.h |2 ++ arch/c6x/kernel/entry.S | 31 --- 2 files changed, 26 insertions(+), 7 deletions(-) diff --git a/arch/c6x/include/asm/unistd.h b/arch/c6x/include/asm/unistd.h index 6d54ea4..1ce3a6f 100644 --- a/arch/c6x/include/asm/unistd.h +++ b/arch/c6x/include/asm/unistd.h @@ -16,6 +16,8 @@ #if !defined(_ASM_C6X_UNISTD_H) || defined(__SYSCALL) #define _ASM_C6X_UNISTD_H +#define __ARCH_WANT_KERNEL_EXECVE + /* Use the standard ABI for syscalls. */ #include diff --git a/arch/c6x/kernel/entry.S b/arch/c6x/kernel/entry.S index 30b37e5..693002b 100644 --- a/arch/c6x/kernel/entry.S +++ b/arch/c6x/kernel/entry.S @@ -315,6 +315,30 @@ resume_userspace: [A0] BNOP.S1 work_pending,5 BNOP.S1 restore_all,5 + ;; extern void ret_from_kernel_execve(struct pt_regs *normal, + ;;struct pt_regs *new) + ;; + ;; Copy new regs to normal regs. + ;; Switch stack to normal regs and return to userspace. + ;; +ENTRY(ret_from_kernel_execve) +#ifdef CONFIG_C6X_BIG_KERNEL + MVKL.S2 memmove,B0 + MVKH.S2 memmove,B0 + B .S2 B0 +#else + B .S2 memmove +#endif + ADDKPC .S2 0f,B3,2 + MVK .S1 REGS__END,A6; sizeof(struct pt_regs) + SUB .L2XA4,8,B10; save new SP in callee-saved reg +0: + BNOP.S2 resume_userspace,2 + MV .S2 B10,SP ; switch stack + MVK .L2 0,B1 + STW .D2T2 B1,*+SP(REGS__END+8); clear syscall flag +ENDPROC(ret_from_kernel_execve) + ;; ;; System call handling ;; B0 = syscall number (in sys_call_table) @@ -593,13 +617,6 @@ ENTRY(sys_sigaltstack) NOP 4 ENDPROC(sys_sigaltstack) - ;; kernel_execve -ENTRY(kernel_execve) - MVK .S2 __NR_execve,B0 - SWE - BNOP.S2 B3,5 -ENDPROC(kernel_execve) - ;; ;; Special system calls ;; return address is in B3 -- 1.7.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] c6x: switch to generic sys_execve()
Signed-off-by: Mark Salter
---
arch/c6x/include/asm/syscalls.h |5 -
arch/c6x/include/asm/unistd.h |1 +
arch/c6x/kernel/entry.S | 23 ---
arch/c6x/kernel/process.c | 22 --
4 files changed, 1 insertions(+), 50 deletions(-)
diff --git a/arch/c6x/include/asm/syscalls.h b/arch/c6x/include/asm/syscalls.h
index aed53da..e7b8991 100644
--- a/arch/c6x/include/asm/syscalls.h
+++ b/arch/c6x/include/asm/syscalls.h
@@ -44,11 +44,6 @@ extern int sys_cache_sync(unsigned long s, unsigned long e);
struct pt_regs;
extern asmlinkage long sys_c6x_clone(struct pt_regs *regs);
-extern asmlinkage long sys_c6x_execve(const char __user *name,
- const char __user *const __user *argv,
- const char __user *const __user *envp,
- struct pt_regs *regs);
-
#include
diff --git a/arch/c6x/include/asm/unistd.h b/arch/c6x/include/asm/unistd.h
index 1ce3a6f..3c131d5 100644
--- a/arch/c6x/include/asm/unistd.h
+++ b/arch/c6x/include/asm/unistd.h
@@ -17,6 +17,7 @@
#define _ASM_C6X_UNISTD_H
#define __ARCH_WANT_KERNEL_EXECVE
+#define __ARCH_WANT_SYS_EXECVE
/* Use the standard ABI for syscalls. */
#include
diff --git a/arch/c6x/kernel/entry.S b/arch/c6x/kernel/entry.S
index 693002b..1c0e867 100644
--- a/arch/c6x/kernel/entry.S
+++ b/arch/c6x/kernel/entry.S
@@ -645,29 +645,6 @@ ENTRY(sys_rt_sigreturn)
#endif
ENDPROC(sys_rt_sigreturn)
-ENTRY(sys_execve)
- ADDAW .D2 SP,2,B6 ; put regs addr in 4th parameter
- ; & adjust regs stack addr
- LDW .D2T2 *+SP(REGS_B4+8),B4
-
- ;; c6x_execve(char *name, char **argv,
- ;;char **envp, struct pt_regs *regs)
-#ifdef CONFIG_C6X_BIG_KERNEL
- ||MVKL.S1 sys_c6x_execve,A0
- MVKH.S1 sys_c6x_execve,A0
- B .S2XA0
-#else
- ||B .S2 sys_c6x_execve
-#endif
- STW .D2T2 B3,*SP--[2]
- ADDKPC .S2 ret_from_c6x_execve,B3,3
-
-ret_from_c6x_execve:
- LDW .D2T2 *++SP[2],B3
- NOP 4
- BNOP.S2 B3,5
-ENDPROC(sys_execve)
-
ENTRY(sys_pread_c6x)
MV .D2XA8,B7
#ifdef CONFIG_C6X_BIG_KERNEL
diff --git a/arch/c6x/kernel/process.c b/arch/c6x/kernel/process.c
index 45e924a..e83d872 100644
--- a/arch/c6x/kernel/process.c
+++ b/arch/c6x/kernel/process.c
@@ -221,28 +221,6 @@ int copy_thread(unsigned long clone_flags, unsigned long
usp,
return 0;
}
-/*
- * c6x_execve() executes a new program.
- */
-SYSCALL_DEFINE4(c6x_execve, const char __user *, name,
- const char __user *const __user *, argv,
- const char __user *const __user *, envp,
- struct pt_regs *, regs)
-{
- int error;
- char *filename;
-
- filename = getname(name);
- error = PTR_ERR(filename);
- if (IS_ERR(filename))
- goto out;
-
- error = do_execve(filename, argv, envp, regs);
- putname(filename);
-out:
- return error;
-}
-
unsigned long get_wchan(struct task_struct *p)
{
return p->thread.wchan;
--
1.7.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] C6X uapi disintegration
The following changes since commit 547b1e81afe3119f7daf702cc03b158495535a25:
Fix staging driver use of VM_RESERVED (2012-10-09 21:06:41 +0900)
are available in the git repository at:
git://linux-c6x.org/git/projects/linux-c6x-upstreaming.git tags/for-linus
for you to fetch changes up to fbdd63d76c5ad6ae56a7bd1acebabefafc6aadf0:
UAPI: (Scripted) Disintegrate arch/c6x/include/asm (2012-10-09 14:56:38 -0400)
C6X UAPI Disintegration
David Howells (1):
UAPI: (Scripted) Disintegrate arch/c6x/include/asm
arch/c6x/include/asm/Kbuild |1 -
arch/c6x/include/asm/ptrace.h| 146 +---
arch/c6x/include/uapi/asm/Kbuild |7 +
arch/c6x/include/{ => uapi}/asm/byteorder.h |0
arch/c6x/include/{ => uapi}/asm/kvm_para.h |0
arch/c6x/include/uapi/asm/ptrace.h | 163 ++
arch/c6x/include/{ => uapi}/asm/setup.h |0
arch/c6x/include/{ => uapi}/asm/sigcontext.h |0
arch/c6x/include/{ => uapi}/asm/swab.h |0
arch/c6x/include/{ => uapi}/asm/unistd.h |0
10 files changed, 171 insertions(+), 146 deletions(-)
rename arch/c6x/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/c6x/include/{ => uapi}/asm/kvm_para.h (100%)
create mode 100644 arch/c6x/include/uapi/asm/ptrace.h
rename arch/c6x/include/{ => uapi}/asm/setup.h (100%)
rename arch/c6x/include/{ => uapi}/asm/sigcontext.h (100%)
rename arch/c6x/include/{ => uapi}/asm/swab.h (100%)
rename arch/c6x/include/{ => uapi}/asm/unistd.h (100%)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] C6X: fixes for v3.7
The following changes since commit 9489e9dcae718d5fde988e4a684a0f55b5f94d17: Linux 3.7-rc7 (2012-11-25 17:59:19 -0800) are available in the git repository at: git://linux-c6x.org/git/projects/linux-c6x-upstreaming.git tags/for-linus for you to fetch changes up to 93bbd0c087eb299e0fe11c59d340932180c082b5: c6x: use generic kvm_para.h (2012-11-28 14:33:03 -0500) C6X fixes for v3.7 Mark Salter (4): c6x: run do_notify_resume with interrupts enabled c6x: fix misleading comment c6x: remove internal kernel symbols from exported setup.h c6x: use generic kvm_para.h arch/c6x/include/asm/setup.h | 33 + arch/c6x/include/uapi/asm/Kbuild |2 ++ arch/c6x/include/uapi/asm/kvm_para.h |1 - arch/c6x/include/uapi/asm/setup.h| 33 +++-- arch/c6x/kernel/entry.S |5 +++-- 5 files changed, 41 insertions(+), 33 deletions(-) create mode 100644 arch/c6x/include/asm/setup.h delete mode 100644 arch/c6x/include/uapi/asm/kvm_para.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFT RESEND linux-next] c6x: dma-mapping: support debug_dma_mapping_error
On Thu, 2012-11-15 at 10:45 -0700, Shuah Khan wrote: > This is for c6x to go through Marek's tree with all the other arch > patches. Hope that is ok with you Mark. > > https://lkml.org/lkml/2012/11/3/219 fixes the > debug_dma_mapping_error() > dependency on get_dma_ops() that caused compile errors on c6x. Yes. Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: problem trying to fetch the c6x tree
On Tue, 2013-06-25 at 09:46 +1000, Stephen Rothwell wrote: > Hi Mark, > > Attempting to fetch the c6x tree > (git://linux-c6x.org/git/projects/linux-c6x-upstreaming.git#for-linux-next) > for the past two days has just produced hangs. I am using whatever I > have previously fetched. > Hi Stephen, I tried last night and saw the same problem. Now it is working again. I'll try to find out what happened. Probably some infrastructure change that I didn't get notice about. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2, part4 03/39] c6x: normalize global variables exported by vmlinux.lds
On Sun, 2013-03-24 at 15:24 +0800, Jiang Liu wrote:
> Normalize global variables exported by vmlinux.lds to conform usage
> guidelines from include/asm-generic/sections.h.
>
> Use _text to mark the start of the kernel image including the head text,
> and _stext to mark the start of the .text section.
>
> This patch also fixes possible bugs due to current address layout that
> [__init_begin, __init_end] is a sub-range of [_stext, _etext] and pages
> within range [__init_begin, __init_end] will be freed by free_initmem().
I won't have time to look at this in detail until later this week, but
the reason for that layout is because c6x commonly stores text in flash.
Not all of the xip support is in-tree yet, but when it is, we don't want
to free init text.
--Mark
>
> Signed-off-by: Jiang Liu
> Cc: Mark Salter
> Cc: Aurelien Jacquiot
> Cc: linux-c6x-...@linux-c6x.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/c6x/kernel/vmlinux.lds.S |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/c6x/kernel/vmlinux.lds.S b/arch/c6x/kernel/vmlinux.lds.S
> index 1d81c4c..279d807 100644
> --- a/arch/c6x/kernel/vmlinux.lds.S
> +++ b/arch/c6x/kernel/vmlinux.lds.S
> @@ -54,16 +54,15 @@ SECTIONS
> }
>
> . = ALIGN(PAGE_SIZE);
> + __init_begin = .;
> .init :
> {
> - _stext = .;
> _sinittext = .;
> HEAD_TEXT
> INIT_TEXT
> _einittext = .;
> }
>
> - __init_begin = _stext;
> INIT_DATA_SECTION(16)
>
> PERCPU_SECTION(128)
> @@ -74,6 +73,7 @@ SECTIONS
> .text :
> {
> _text = .;
> + _stext = .;
> TEXT_TEXT
> SCHED_TEXT
> LOCK_TEXT
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64: wire in generic parport.h
The arm64 port doesn't provide a parport.h which causes a build failure with some configurations: drivers/parport/parport_pc.c:67:25: fatal error: asm/parport.h: No such file or directory #include This patch wires in the generic parport.h for arm64. Signed-off-by: Mark Salter --- arch/arm64/include/asm/Kbuild | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild index 79a642d..487b0a2 100644 --- a/arch/arm64/include/asm/Kbuild +++ b/arch/arm64/include/asm/Kbuild @@ -25,6 +25,7 @@ generic-y += local64.h generic-y += mman.h generic-y += msgbuf.h generic-y += mutex.h +generic-y += parport.h generic-y += pci.h generic-y += percpu.h generic-y += poll.h -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64: add screen_info for console support
The arm64 port doesn't provide a screen_info struct for console support which leads to a build failure with some configurations: drivers/video/console/vgacon.c:820: undefined reference to `screen_info' This patch adds an empty declaration of screen_info to fix the build problem. Some additional runtime code is needed to actually make it useful. Signed-off-by: Mark Salter --- arch/arm64/kernel/setup.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c index add6ea6..eb9f93a 100644 --- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -64,6 +64,10 @@ static const char *cpu_name; static const char *machine_name; phys_addr_t __fdt_pointer __initdata; +#if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_DUMMY_CONSOLE) +struct screen_info screen_info; +#endif + /* * Standard memory resources */ -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: wire in generic parport.h
On Sun, 2013-08-18 at 22:25 +0200, Geert Uytterhoeven wrote: > On Sun, Aug 18, 2013 at 6:01 PM, Mark Salter wrote: > > The arm64 port doesn't provide a parport.h which causes a build failure > > with some configurations: > > > > drivers/parport/parport_pc.c:67:25: fatal error: asm/parport.h: No such > > file or directory > >#include > > > > This patch wires in the generic parport.h for arm64. > > Can arm64 have a PC-style parport? Good question. I'm not sure, but really doubt it. > > If not, you're better off disabling it in drivers/parport/Kconfig. > > You will receive bonus points for introducing ARCH_MAY_HAVE_PC_PARPORT, > cfr. ARCH_MAY_HAVE_PC_FDC. > Yes, good point. I'll work up a new patch. I can use some bonus points. --Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: wire in generic parport.h
On Sun, 2013-08-18 at 22:25 +0200, Geert Uytterhoeven wrote: > On Sun, Aug 18, 2013 at 6:01 PM, Mark Salter wrote: > > The arm64 port doesn't provide a parport.h which causes a build failure > > with some configurations: > > > > drivers/parport/parport_pc.c:67:25: fatal error: asm/parport.h: No such > > file or directory > >#include > > > > This patch wires in the generic parport.h for arm64. > > Can arm64 have a PC-style parport? > > If not, you're better off disabling it in drivers/parport/Kconfig. > > You will receive bonus points for introducing ARCH_MAY_HAVE_PC_PARPORT, > cfr. ARCH_MAY_HAVE_PC_FDC. Okay, I have two versions of the patch. One which follows the PC_FDC patch and adds something like this to arch//Kconfig: config ARCH_MAY_HAVE_PC_PARPORT def_bool y The other version adds: config ARCH_MAY_HAVE_PC_PARPORT bool to arch/Kconfig (or maybe that should be in drivers/parport/Kconfig) so that the various arches just need to select it. Is there any preference for one over the other? --Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: add screen_info for console support
On Tue, 2013-08-20 at 18:14 +0100, Catalin Marinas wrote: > I was wondering about this but do we need screen_info for DUMMY_CONSOLE > as well? I thought so because my grep turned up a reference to screen_info in dummycon.c but a closer look shows that only applies to arm. --Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64: move elf notes into readonly segment
The current vmlinux.lds.S places the notes sections between the end of rw data and start of bss. This means that _edata doesn't really point to the end of data. Since notes are read-only, this patch moves them to the read-only segment so that _edata does point to the end of initialized rw data. Signed-off-by: Mark Salter --- arch/arm64/kernel/vmlinux.lds.S | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S index f5e5574..f8ab9d8 100644 --- a/arch/arm64/kernel/vmlinux.lds.S +++ b/arch/arm64/kernel/vmlinux.lds.S @@ -71,6 +71,7 @@ SECTIONS RO_DATA(PAGE_SIZE) EXCEPTION_TABLE(8) + NOTES _etext = .; /* End of text and rodata section */ . = ALIGN(PAGE_SIZE); @@ -122,8 +123,6 @@ SECTIONS } _edata_loc = __data_loc + SIZEOF(.data); - NOTES - BSS_SECTION(0, 0, 0) _end = .; -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/17] Add proper definitions for some EFI function pointers.
On Tue, 2013-08-06 at 20:45 -0700, Roy Franz wrote:
> The x86/AMD64 EFI stubs must us a call wrapper to convert between
> the Linux and EFI ABIs, so void pointers are sufficient. For ARM,
> the ABIs are compatible, so we can directly invoke the function
> pointers. The functions that are used by the ARM stub are updated
> to match the EFI definitions.
>
> Signed-off-by: Roy Franz
> ---
> include/linux/efi.h | 42 +-
> 1 file changed, 25 insertions(+), 17 deletions(-)
>
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 51f5641..96bb866 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -39,6 +39,8 @@
> typedef unsigned long efi_status_t;
> typedef u8 efi_bool_t;
> typedef u16 efi_char16_t;/* UNICODE character */
> +typedef u64 efi_physical_addr_t;
> +typedef void *efi_handle_t;
>
>
> typedef struct {
> @@ -96,6 +98,7 @@ typedef struct {
> #define EFI_MEMORY_DESCRIPTOR_VERSION1
>
> #define EFI_PAGE_SHIFT 12
> +#define EFI_PAGE_SIZE(1UL << EFI_PAGE_SHIFT)
>
> typedef struct {
> u32 type;
> @@ -157,11 +160,12 @@ typedef struct {
> efi_table_hdr_t hdr;
> void *raise_tpl;
> void *restore_tpl;
> - void *allocate_pages;
> - void *free_pages;
> - void *get_memory_map;
> - void *allocate_pool;
> - void *free_pool;
> + int (*allocate_pages)(int, int, unsigned long, efi_physical_addr_t *);
> + int (*free_pages)(efi_physical_addr_t, unsigned long);
All of the actual function pointers that were added should return an
efi_status_t instead of int. On arm64, I was seeing an unrecognizable
error status because the truncation from 64 to 32 bits.
--Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote:
> * Change FDT memory allocation to retry with a larger allocation if
> first educated guess is inadequate.
With this change, it looks like you no longer free the original cmdline
and fdt memory. The current flow looks like:
retry:
allocate_memory_for_expanded_fdt
get_memory_map
if (update_fdt() fails) {
free new_fdt and memory_map
goto retry
}
So, this keeps the original fdt around and uses it as a starting point
for newly allocated expanded fdt. You don't know if the new fdt is big
enough until update_fdt() succeeds. But at that point, you already wrote
the efi-runtime-mmap property with the memory_map still having the
original cmdline and fdt in it.
I think you should be able to have an expand_fdt() function which bumps
the fdt size and uses the current fdt as the starting point instead of
the original fdt. That way you can free the original fdt on the first
iteration and free the original cmdline as soon as it is successfully
written. Then the last thing you do if get the memory_map and write it.
--Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/16] Add EFI stub for ARM
On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote:
> +static int relocate_kernel(efi_system_table_t *sys_table,
> + unsigned long *zimage_addr,
> + unsigned long zimage_size,
> + unsigned long min_addr, unsigned long max_addr)
> +{
> + /* Get current address of kernel. */
> + unsigned long cur_zimage_addr = *zimage_addr;
> + unsigned long new_addr = 0;
> +
> + efi_status_t status;
> +
> + if (!zimage_addr || !zimage_size)
> + return EFI_INVALID_PARAMETER;
> +
This parameter check is too late. You already used zimage_addr to
initialize cur_zimage_addr.
--Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/16] Move common EFI stub code from x86 arch code to common location
On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote: > No code changes made, just moving functions from x86 arch directory > to common location. > Code is shared using #include, similar to how decompression code > is shared among architectures. > > Signed-off-by: Roy Franz > --- Tested on arm64. Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/16] Add system pointer argument to shared EFI stub related functions so they no longer use global system table pointer as they did when part of eboot.c. This code is now shared, so using
On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote: > Signed-off-by: Roy Franz > --- > arch/x86/boot/compressed/eboot.c | 38 +++-- > drivers/firmware/efi/efi-stub-helper.c | 96 > +--- > 2 files changed, 72 insertions(+), 62 deletions(-) Tested on arm64. Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/16] Generalize handle_ramdisks() and rename to handle_cmdline_files().
On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote: > The handle_cmdline_files now takes the option to handle as a string, > and returns the loaded data through parameters, rather than taking > an x86 specific setup_header structure. For ARM, this will be used > to load a device tree blob in addition to initrd images. > > Signed-off-by: Roy Franz > --- Tested on arm64. Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/16] Renames in handle_cmdline_files() to complete generalization.
On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote: > Rename variables to be not initrd specific, as now the function > loads arbitrary files. > > Signed-off-by: Roy Franz > --- Tested on arm64. Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/16] rename __get_map() to efi_get_memory_map(), add parameter to optionally return mmap key. The mmap key is required to exit EFI boot services, and allows efi_get_memory_map() to be use
On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote: > Signed-off-by: Roy Franz > --- > drivers/firmware/efi/efi-stub-helper.c | 17 +++-- > 1 file changed, 11 insertions(+), 6 deletions(-) Tested on arm64. Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/16] Add minimum address parameter to efi_low_alloc()
On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote: > This allows allocations to be made low in memory while > avoiding allocations at the base of memory. > > Signed-off-by: Roy Franz > --- Tested on arm64. Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 12/16] Fix types in EFI calls to match EFI function definitions.
On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote: > EFI calls can made directly on ARM, so the function pointers > are directly invoked. This allows types to be checked at > compile time, so here we ensure that the parameters match > the function signature. > > Signed-off-by: Roy Franz > --- Tested on arm64. Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/16] Move EFI_READ_CHUNK_SIZE define to shared location.
On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote: > This #define is only used the the shared code, so move > it there. > > Signed-off-by: Roy Franz > --- Tested on arm64. Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/16] Add proper definitions for some EFI function pointers.
On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote: > The x86/AMD64 EFI stubs must us a call wrapper to convert between > the Linux and EFI ABIs, so void pointers are sufficient. For ARM, > the ABIs are compatible, so we can directly invoke the function > pointers. The functions that are used by the ARM stub are updated > to match the EFI definitions. > > Signed-off-by: Roy Franz > --- Tested on arm64. Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/16] resolve warnings found on ARM compile
On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote: > 2 unused labels > 1 "value computed is not used" > > > Signed-off-by: Roy Franz > --- Tested on arm64. Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/16] Rename memory allocation/free functions
On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote: > Rename them to be more similar, as low_free() could be used to free > memory allocated by both high_alloc() and low_alloc(). > high_alloc() -> efi_high_alloc() > low_alloc() -> efi_low_alloc() > low_free() -> efi_free() > > Signed-off-by: Roy Franz > --- Tested on arm64. Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/16] Enforce minimum alignment of 1 page on allocations. The efi_high_alloc() and efi_low_alloc() functions use the EFI_ALLOCATE_ADDRESS option to the EFI function allocate_pages(), which
On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote: > The existing code could fail to allocate depending > on allocation size, as although repeated allocation > attempts were made, none were guaranteed to be page > aligned. > > > > Signed-off-by: Roy Franz > --- Tested on arm64. Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Mon, 2013-08-12 at 18:13 -0700, Roy Franz wrote:
> On Mon, Aug 12, 2013 at 7:02 AM, Mark Salter wrote:
> > On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote:
> >> * Change FDT memory allocation to retry with a larger allocation if
> >> first educated guess is inadequate.
> >
> > With this change, it looks like you no longer free the original cmdline
> > and fdt memory. The current flow looks like:
> >
> > retry:
> > allocate_memory_for_expanded_fdt
> > get_memory_map
> > if (update_fdt() fails) {
> > free new_fdt and memory_map
> > goto retry
> > }
> >
> > So, this keeps the original fdt around and uses it as a starting point
> > for newly allocated expanded fdt. You don't know if the new fdt is big
> > enough until update_fdt() succeeds. But at that point, you already wrote
> > the efi-runtime-mmap property with the memory_map still having the
> > original cmdline and fdt in it.
> >
> > I think you should be able to have an expand_fdt() function which bumps
> > the fdt size and uses the current fdt as the starting point instead of
> > the original fdt. That way you can free the original fdt on the first
> > iteration and free the original cmdline as soon as it is successfully
> > written. Then the last thing you do if get the memory_map and write it.
> >
> > --Mark
>
> Hi Mark,
>
> I think this will work with the current FDT fields that are being set
> by the stub. In earlier
> versions, I was also updating the reserved memory map using
> fdt_add_mem_rsv(), so
> iteratively updating the device tree wouldn't work. The reserved
> regions would change,
> and so the repeated updates would cause there to be repeated and
> incorrect reserved regions.
> I'm inclined to leave it as is, which should correctly update the
> device tree even if methods like
> fdt_add_mem_rsv() are used, with the tradeoff being there will be a
> few more memory regions
> for the kernel to free when it processes the EFI memory map. The
> kernel already needs to process
> the EFI memory map to free the buffers use to load the kernel and
> initrd, so these buffers will get freed, just not
> by the stub.
>
Got it. Thanks for the explanation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] c6x: add memory barrier to arch_local_irq_restore
The following changes since commit 31880c37c11e28cb81c70757e38392b42e695dc6: Linux 3.9-rc6 (2013-04-07 20:49:54 -0700) are available in the git repository at: git://linux-c6x.org/git/projects/linux-c6x-upstreaming.git tags/for-linus for you to fetch changes up to f934af05cb1bf20558542185299394a69060b829: add memory barrier to arch_local_irq_restore (2013-04-09 15:35:46 -0400) C6X fixes for v3.9 Mark Salter (1): add memory barrier to arch_local_irq_restore arch/c6x/include/asm/irqflags.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] c6x: Provide default implementation for dma_{alloc,free}_attrs
On Tue, 2013-04-30 at 12:02 +0900, Damian Hobson-Garcia wrote: > Most architectures that define CONFIG_HAVE_DMA, have implementations for > both dma_alloc_attrs() and dma_free_attrs(). All achitectures that do > not define CONFIG_HAVE_DMA also have both of these definitions provided by > dma-mapping-broken.h. > > Add default implementations for these functions on c6x. > > Signed-off-by: Damian Hobson-Garcia > --- Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] c6x: Wire up asm-generic/xor.h
On Tue, 2013-05-14 at 09:32 +0200, Geert Uytterhoeven wrote: > Signed-off-by: Geert Uytterhoeven > Cc: Mark Salter > Cc: linux-c6x-...@linux-c6x.org > --- > Completely untested due to lack of cross-compiler > > arch/c6x/include/asm/Kbuild |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/arch/c6x/include/asm/Kbuild b/arch/c6x/include/asm/Kbuild > index 4258b08..e49f918 100644 > --- a/arch/c6x/include/asm/Kbuild > +++ b/arch/c6x/include/asm/Kbuild > @@ -55,3 +55,4 @@ generic-y += types.h > generic-y += ucontext.h > generic-y += user.h > generic-y += vga.h > +generic-y += xor.h Acked-by: Mark Salter Tested-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] select GENERIC_ATOMIC64 for c6x/score/unicore32 archs
On Tue, 2012-08-14 at 23:34 +0800, Fengguang Wu wrote: > Sorry I have no compilers for build testing these changes, however the > risk looks low and it's much better than to leave the arch broken, > considering that Eric will do atomic64_t in the core fs/namespace.c > code. > > CC: "Eric W. Biederman" > Signed-off-by: Fengguang Wu > --- > > Andrew: the arch maintainers have been CCed. Best is the maintainers > respond, test and perhaps take the corresponding change. Let's see how > this will work out.. > > > arch/c6x/Kconfig |1 + The c6x port also needs this: C6X: add L*_CACHE_SHIFT defines C6X currently lacks L*_CACHE_SHIFT defines which are used in a few places in the generic kernel. This patch adds those missing defines. Signed-off-by: Mark Salter --- diff --git a/arch/c6x/include/asm/cache.h b/arch/c6x/include/asm/cache.h index 6d521d9..feff1d7 100644 --- a/arch/c6x/include/asm/cache.h +++ b/arch/c6x/include/asm/cache.h @@ -1,7 +1,7 @@ /* * Port on Texas Instruments TMS320C6x architecture * - * Copyright (C) 2005, 2006, 2009, 2010 Texas Instruments Incorporated + * Copyright (C) 2005, 2006, 2009, 2010, 2012 Texas Instruments Incorporated * Author: Aurelien Jacquiot (aurelien.jacqu...@jaluna.com) * * This program is free software; you can redistribute it and/or modify @@ -16,9 +16,14 @@ /* * Cache line size */ -#define L1D_CACHE_BYTES 64 -#define L1P_CACHE_BYTES 32 -#define L2_CACHE_BYTES 128 +#define L1D_CACHE_SHIFT 6 +#define L1D_CACHE_BYTES (1 << L1D_CACHE_SHIFT) + +#define L1P_CACHE_SHIFT 5 +#define L1P_CACHE_BYTES (1 << L1P_CACHE_SHIFT) + +#define L2_CACHE_SHIFT7 +#define L2_CACHE_BYTES(1 << L2_CACHE_SHIFT) /* * L2 used as cache @@ -29,7 +34,8 @@ * For practical reasons the L1_CACHE_BYTES defines should not be smaller than * the L2 line size */ -#define L1_CACHE_BYTESL2_CACHE_BYTES +#define L1_CACHE_SHIFTL2_CACHE_SHIFT +#define L1_CACHE_BYTES(1 << L2_CACHE_SHIFT) #define L2_CACHE_ALIGN_LOW(x) \ (((x) & ~(L2_CACHE_BYTES - 1))) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] select GENERIC_ATOMIC64 for c6x/score/unicore32 archs
On Wed, 2012-08-15 at 10:36 +0800, Fengguang Wu wrote: > > -#define L1_CACHE_BYTESL2_CACHE_BYTES > > +#define L1_CACHE_SHIFTL2_CACHE_SHIFT > > +#define L1_CACHE_BYTES(1 << L2_CACHE_SHIFT) > > Nitpick: the last line could better be: > > +#define L1_CACHE_BYTES(1 << L1_CACHE_SHIFT) > > Reviewed-by: Fengguang Wu Yes, I noticed that after sending the patch. Should I push this through the c6x tree? --Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] select GENERIC_ATOMIC64 for c6x/score/unicore32 archs
On Wed, 2012-08-15 at 22:12 +0800, Fengguang Wu wrote: > > Should I push this through the c6x tree? > > That'd be good. For consistency, will you also include the > GENERIC_ATOMIC64 chunk in the titled patch? > > I can send Andrew an updated series (reducing the c6x changes, and > possibly the score/unicore32 bits) later on. Ok. Will do. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] C6X changes for v3.6
The following changes since commit 84a1caf1453c3d44050bd22db958af4a7f99315c: Linux 3.5-rc7 (2012-07-14 15:40:28 -0700) are available in the git repository at: git://linux-c6x.org/git/projects/linux-c6x-upstreaming.git tags/for-linus for you to fetch changes up to b9b8722d4704137d1c85b8e62364b487cbbe8bf0: C6X: clean up compiler warning (2012-07-18 23:52:54 -0400) C6X changes for 3.6 merge window. - remove use of legacy irqs which really wasn't needed - add support for C66x SoC on EVMC6678 board - clean up compiler warning Ken Cox (1): C6X: add basic support for TMS320C6678 SoC Mark Salter (3): C6X: remove megamod-pic requirement on direct-mapped core pic C6X: remove dependence on legacy IRQs C6X: clean up compiler warning arch/c6x/boot/dts/evmc6678.dts | 83 arch/c6x/boot/dts/tms320c6678.dtsi | 146 +++ arch/c6x/configs/evmc6678_defconfig | 42 ++ arch/c6x/include/asm/irq.h |2 - arch/c6x/kernel/irq.c | 21 +++--- arch/c6x/kernel/setup.c |4 + arch/c6x/kernel/signal.c|2 - arch/c6x/platforms/Kconfig |4 + arch/c6x/platforms/megamod-pic.c| 28 +-- arch/c6x/platforms/plldata.c| 65 10 files changed, 373 insertions(+), 24 deletions(-) create mode 100644 arch/c6x/boot/dts/evmc6678.dts create mode 100644 arch/c6x/boot/dts/tms320c6678.dtsi create mode 100644 arch/c6x/configs/evmc6678_defconfig -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] C6X atomic64 support
The following changes since commit 28a33cbc24e4256c143dce96c7d93bf423229f92: Linux 3.5 (2012-07-21 13:58:29 -0700) are available in the git repository at: git://linux-c6x.org/git/projects/linux-c6x-upstreaming.git tags/for-linus for you to fetch changes up to 01ddd9a809b9a95df097ff1b5565f806e681a606: C6X: select GENERIC_ATOMIC64 (2012-08-15 12:27:00 -0400) Enable atomic64 ops in C6X - define L1_CACHE_SHIFT - select GENERIC_ATOMIC64 Mark Salter (2): C6X: add Lx_CACHE_SHIFT defines C6X: select GENERIC_ATOMIC64 arch/c6x/Kconfig |1 + arch/c6x/include/asm/cache.h | 16 +++- 2 files changed, 12 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/11] C6X: defconfig: Remove CONFIG_MISC_DEVICES
On Sat, 2012-08-18 at 13:23 -0300, Fabio Estevam wrote: > From: Fabio Estevam > > commit 7c5763 (drivers:misc: Remove MISC_DEVICES config option) removed > CONFIG_MISC_DEVICES option, so remove the occurrences from the config files > as well > > Cc: Mark Salter > Signed-off-by: Fabio Estevam > --- Acked-by: Mark Salter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-c6x-dev] [PATCH 3/9] c6x: Provide dma_mmap_coherent() and dma_get_sgtable()
On Sun, 2013-01-13 at 11:44 +0100, Geert Uytterhoeven wrote: > c6x/allmodconfig (assumed): > > drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’: > drivers/media/v4l2-core/videobuf2-dma-contig.c:204: error: implicit > declaration of function ‘dma_mmap_coherent’ > drivers/media/v4l2-core/videobuf2-dma-contig.c: In function > ‘vb2_dc_get_base_sgt’: > drivers/media/v4l2-core/videobuf2-dma-contig.c:387: error: implicit > declaration of function ‘dma_get_sgtable’ > > For architectures using dma_map_ops, dma_mmap_coherent() and > dma_get_sgtable() are provided in . > > C6x does not use dma_map_ops, hence it should implement them as inline > stubs using dma_common_mmap() and dma_common_get_sgtable(). > So are dma_mmap_coherent() and dma_get_sgtable() part of the DMA API now? I don't them in Documentation/DMA*.txt anywhere. Why does the default dma_common_mmap() for !CONFIG_MMU return an error? Wouldn't it be better to provide default implementations that an arch could override rather than having to patch all "no dma_map_ops" architectures? --Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] generic syscall and c6x fixes
The following changes since commit 979570e02981d4a8fc20b3cc8fd651856c98ee9d: Linux 3.6-rc7 (2012-09-23 18:10:57 -0700) are available in the git repository at: git://linux-c6x.org/git/projects/linux-c6x-upstreaming.git tags/for-linus for you to fetch changes up to 11ef4cfac935ab45eb4c7f98d26c78ee69627909: syscalls: add __NR_kcmp syscall to generic unistd.h (2012-09-26 15:26:30 -0400) Some fixes for v3.6 - Add __NR_kcmp to generic syscall list - C6X: Use generic asm/barrier.h Mark Salter (2): c6x: use asm-generic/barrier.h syscalls: add __NR_kcmp syscall to generic unistd.h arch/c6x/include/asm/Kbuild|1 + arch/c6x/include/asm/barrier.h | 27 --- include/asm-generic/unistd.h |4 +++- 3 files changed, 4 insertions(+), 28 deletions(-) delete mode 100644 arch/c6x/include/asm/barrier.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 3/4] ARM64: ACPI: enable ACPI_SPCR_TABLE
On Thu, 2016-09-08 at 12:16 +0100, Will Deacon wrote: > On Wed, Sep 07, 2016 at 12:30:19PM +0300, Aleksey Makarov wrote: > > > > > > On 09/05/2016 03:36 PM, Aleksey Makarov wrote: > > > > > > SBBR mentions SPCR as a mandatory ACPI table. So enable it for ARM64 > > > > > > Earlycon should be set up as early as possible. ACPI boot tables are > > > mapped in arch/arm64/kernel/acpi.c:acpi_boot_table_init() that > > > is called from setup_arch() and that's where we parse SPCR. > > > So it has to be opted-in per-arch. > > > > > > When ACPI_SPCR_TABLE is defined initialization of DT earlycon is > > > deferred until the DT/ACPI decision is done. Initialize DT earlycon > > > if ACPI is disabled. > > Hi Will, Catalin, > > > > Can you review this patch and consider ACKing it please? > Hanjun, Al, Mark, Graeme -- any comments on this? > > Will I think there is a problem still with systems using 32-bit access to 8250 UARTs (i.e. Mustang) but that will need a DBG2 table spec change and followup patch to resolve.
Re: [PATCH v10 3/4] ARM64: ACPI: enable ACPI_SPCR_TABLE
On Fri, 2016-09-09 at 17:28 +0800, Hanjun Guo wrote: > On 2016/9/9 0:34, Mark Salter wrote: > > > > On Thu, 2016-09-08 at 12:16 +0100, Will Deacon wrote: > > > > > > On Wed, Sep 07, 2016 at 12:30:19PM +0300, Aleksey Makarov wrote: > > > > > > > > > > > > > > > > On 09/05/2016 03:36 PM, Aleksey Makarov wrote: > > > > > > > > > > > > > > > SBBR mentions SPCR as a mandatory ACPI table. So enable it for ARM64 > > > > > > > > > > Earlycon should be set up as early as possible. ACPI boot tables are > > > > > mapped in arch/arm64/kernel/acpi.c:acpi_boot_table_init() that > > > > > is called from setup_arch() and that's where we parse SPCR. > > > > > So it has to be opted-in per-arch. > > > > > > > > > > When ACPI_SPCR_TABLE is defined initialization of DT earlycon is > > > > > deferred until the DT/ACPI decision is done. Initialize DT earlycon > > > > > if ACPI is disabled. > > > > Hi Will, Catalin, > > > > > > > > Can you review this patch and consider ACKing it please? > > > Hanjun, Al, Mark, Graeme -- any comments on this? > > > > > > Will > > I think there is a problem still with systems using 32-bit access to 8250 > > UARTs (i.e. Mustang) but that will need a DBG2 table spec change and > > followup patch to resolve. > Hmm, I think you mean we can add patches later with the spec updated, > and this patch works with SBSA pl011 can go for now? Yes, I think this series is fine for now. > > Thanks > Hanjun
Re: [RFC PATCH V5 3/5] PCI: Check platform specific ECAM quirks
On Mon, 2016-08-08 at 15:05 +0200, Tomasz Nowicki wrote:
> Some platforms may not be fully compliant with generic set of PCI config
> accessors. For these cases we implement the way to overwrite accessors
> set. Algorithm traverses available quirk list (static array),
> matches against and
> returns pci_config_window structure with fancy PCI config ops.
> oem_id, oem_table_id and rev come from MCFG table standard header.
>
> It is possible to define custom init call which is responsible for
> setting up PCI configuration access accordingly to quirk requirements.
> If custom init call is not defined, use standard
> pci_acpi_setup_ecam_mapping().
>
> pci_generic_ecam_ops will be used for platforms free from quirks.
>
> Signed-off-by: Tomasz Nowicki
> Signed-off-by: Dongdong Liu
> Signed-off-by: Christopher Covington
> ---
> drivers/pci/host/Makefile | 1 +
> drivers/pci/host/mcfg-quirks.c | 86
> ++
> drivers/pci/host/mcfg-quirks.h | 20 ++
> include/linux/pci-acpi.h | 2 +
> 4 files changed, 109 insertions(+)
> create mode 100644 drivers/pci/host/mcfg-quirks.c
> create mode 100644 drivers/pci/host/mcfg-quirks.h
>
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 8843410..500cf78 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -31,3 +31,4 @@ obj-$(CONFIG_PCI_HOST_THUNDER_ECAM) += pci-thunder-ecam.o
> obj-$(CONFIG_PCI_HOST_THUNDER_PEM) += pci-thunder-pem.o
> obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
> obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
> +obj-$(CONFIG_ACPI_MCFG) += mcfg-quirks.o
> diff --git a/drivers/pci/host/mcfg-quirks.c b/drivers/pci/host/mcfg-quirks.c
> new file mode 100644
> index 000..aa9907b
> --- /dev/null
> +++ b/drivers/pci/host/mcfg-quirks.c
> @@ -0,0 +1,86 @@
> +/*
> + * Copyright (C) 2016 Semihalf
> + * Author: Tomasz Nowicki
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License, version 2, as
> + * published by the Free Software Foundation (the "GPL").
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License version 2 (GPLv2) for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * version 2 (GPLv2) along with this source code.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "mcfg-quirks.h"
> +
> +struct pci_cfg_fixup {
> + char oem_id[ACPI_OEM_ID_SIZE + 1];
> + char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
> + u32 oem_revision;
> + struct resource domain_range;
> + struct resource bus_range;
> + struct pci_ops *ops;
> + struct pci_config_window *(*init)(struct acpi_pci_root *root,
> + struct pci_ops *ops);
> +};
> +
> +#define MCFG_DOM_RANGE(start, end) DEFINE_RES_NAMED((start), \
> + ((end) - (start) + 1), NULL, 0)
> +#define MCFG_DOM_ANY MCFG_DOM_RANGE(0x0, 0x)
> +#define MCFG_BUS_RANGE(start, end) DEFINE_RES_NAMED((start), \
> + ((end) - (start) + 1), \
> + NULL, IORESOURCE_BUS)
> +#define MCFG_BUS_ANY MCFG_BUS_RANGE(0x0, 0xff)
> +
> +static struct pci_cfg_fixup mcfg_quirks[] __initconst = {
^^
I get section warnings because pci_cfg_fixup_match() is not
an init function.
WARNING: vmlinux.o(.text+0x3f6c74): Section mismatch in reference from the
function pci_mcfg_match_quirks() to the variable .init.rodata:$d
The function pci_mcfg_match_quirks() references
the variable __initconst $d.
This is often because pci_mcfg_match_quirks lacks a __initconst
annotation or the annotation of $d is wrong.
> +/* { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, pci_ops, init_hook }, */
> +};
> +
> +static bool pci_mcfg_fixup_match(struct pci_cfg_fixup *f,
> + struct acpi_table_header *mcfg_header)
> +{
> + return (!memcmp(f->oem_id, mcfg_header->oem_id, ACPI_OEM_ID_SIZE) &&
> + !memcmp(f->oem_table_id, mcfg_header->oem_table_id,
> + ACPI_OEM_TABLE_ID_SIZE) &&
> + f->oem_revision == mcfg_header->oem_revision);
> +}
> +
> +struct pci_config_window *pci_mcfg_match_quirks(struct acpi_pci_root *root)
> +{
> + struct resource dom_res = MCFG_DOM_RANGE(root->segment, root->segment);
> + struct resource *bus_res = &root->secondary;
> + struct pci_cfg_fixup *f = mcfg_quirks;
> + struct acpi_table_header *mcfg_header;
> + acpi_status status;
> + int i;
> +
> + status = acpi_get_table(ACPI_SIG_
Re: [RFC PATCH V5 0/5] ECAM quirks handling for ARM64 platforms
On Mon, 2016-08-08 at 15:05 +0200, Tomasz Nowicki wrote: > Quirk handling relies on an idea of matching MCFG OEM ID, TABLE ID and > revision (the ones from standard header of MCFG table). > > Static array is used to keep quirk entries. Each entry consists of > mentioned MCFG IDs along with custom pci_ops structure and initialization > call. > > As an example, the last patch presents quirk handling mechanism usage for > ThunderX PEM driver. > > v4 -> v5 > - rebase against v4.8-rc1 > - rework to exact MCFG OEM ID, TABLE ID, rev match > - use memcmp instead of strncmp > - no substring match > - fix typos and dmesg message > > Tomasz Nowicki (5): > PCI: Embed pci_ecam_ops in pci_config_window structure > PCI/ACPI: Move ACPI ECAM mapping to generic MCFG driver > PCI: Check platform specific ECAM quirks > ARM64/PCI: Start using quirks handling for ACPI based PCI host > controller > PCI: thunder-pem: Support quirky configuration space access for ACPI > based PCI host controller > > arch/arm64/kernel/pci.c| 42 + > drivers/acpi/pci_mcfg.c| 40 > drivers/pci/ecam.c | 6 +-- > drivers/pci/host/Makefile | 1 + > drivers/pci/host/mcfg-quirks.c | 93 > drivers/pci/host/mcfg-quirks.h | 24 ++ > drivers/pci/host/pci-thunder-pem.c | 96 > -- > include/linux/pci-acpi.h | 5 ++ > include/linux/pci-ecam.h | 2 +- > 9 files changed, 252 insertions(+), 57 deletions(-) > create mode 100644 drivers/pci/host/mcfg-quirks.c > create mode 100644 drivers/pci/host/mcfg-quirks.h > Tested-by: Mark Salter
Re: [PATCH V4 2/3] arm64: support initrd outside kernel linear map
On Tue, 2015-10-06 at 18:11 +0100, Mark Rutland wrote: > On Tue, Sep 08, 2015 at 12:31:13PM +0100, Mark Rutland wrote: > > Hi Mark, > > > > On Mon, Aug 17, 2015 at 06:01:06PM +0100, Mark Salter wrote: > > > The use of mem= could leave part or all of the initrd outside of > > > the kernel linear map. This will lead to an error when unpacking > > > the initrd and a probable failure to boot. This patch catches that > > > situation and relocates the initrd to be fully within the linear > > > map. > > > > With next-20150908, this patch results in a confusing message at boot when > > not > > using an initrd: > > > > Moving initrd from [408000-407fff] to [9fff49000-9fff48fff] > > > > I think that can be solved by folding in the diff below. > > Mark, it looks like this fell by the wayside. > > Do you have any objection to this? I'll promote this to it's own patch > if not. > > Mark. > > > > > Thanks, > > Mark. > > > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c > > index 6bab21f..2322479 100644 > > --- a/arch/arm64/kernel/setup.c > > +++ b/arch/arm64/kernel/setup.c > > @@ -364,6 +364,8 @@ static void __init relocate_initrd(void) > > to_free = ram_end - orig_start; > > > > size = orig_end - orig_start; > > + if (!size) > > + return; > > > > /* initrd needs to be relocated completely inside linear mapping */ > > new_start = memblock_find_in_range(0, PFN_PHYS(max_pfn), Sorry, no. That looks perfectly good to me. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] phylib: fix device deletion order in mdiobus_unregister()
commit 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus, not
the bus' parent.") uncovered a problem in mdiobus_unregister() which
leads to this warning when I reboot an APM Mustang (arm64) platform:
WARNING: CPU: 7 PID: 4239 at fs/sysfs/group.c:224
sysfs_remove_group+0xa0/0xa4()
sysfs group fee07a10 not found for kobject 'xgene-mii-eth0:03'
...
CPU: 7 PID: 4239 Comm: reboot Tainted: GE
4.2.0-0.18.el7.test15.aarch64 #1
Hardware name: AppliedMicro Mustang/Mustang, BIOS 1.1.0 Aug 26 2015
Call Trace:
[] dump_backtrace+0x0/0x170
[] show_stack+0x20/0x2c
[] dump_stack+0x78/0x9c
[] warn_slowpath_common+0xa0/0xd8
[] warn_slowpath_fmt+0x74/0x88
[] sysfs_remove_group+0x9c/0xa4
[] dpm_sysfs_remove+0x5c/0x70
[] device_del+0x44/0x208
[] device_unregister+0x2c/0x7c
[] mdiobus_unregister+0x48/0x94
[] xgene_enet_mdio_remove+0x28/0x44
[] xgene_enet_remove+0xd0/0xd8
[] xgene_enet_shutdown+0x2c/0x3c
[] platform_drv_shutdown+0x24/0x40
[] device_shutdown+0xf0/0x1b4
[] kernel_restart_prepare+0x40/0x4c
[] kernel_restart+0x1c/0x80
[] SyS_reboot+0x17c/0x250
The problem is that mdiobus_unregister() deletes the bus device before
unregistering the phy devices on the bus. This wasn't a problem before
because the phys were not children of the bus:
/sys/devices/platform/APMC0D05:00/net/eth0/xgene-mii-eth0:03
/sys/devices/platform/APMC0D05:00/net/eth0/xgene-mii-eth0
But now that they are:
/sys/devices/platform/APMC0D05:00/net/eth0/xgene-mii-eth0/xgene-mii-eth0:03
when mdiobus_unregister deletes the bus device, the phy subdirs are
removed from sysfs also. So when the phys are unregistered afterward,
we get the warning. This patch changes the order so that phys are
unregistered before the bus device is deleted.
Signed-off-by: Mark Salter
---
drivers/net/phy/mdio_bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 46a14cb..02a4615 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -303,12 +303,12 @@ void mdiobus_unregister(struct mii_bus *bus)
BUG_ON(bus->state != MDIOBUS_REGISTERED);
bus->state = MDIOBUS_UNREGISTERED;
- device_del(&bus->dev);
for (i = 0; i < PHY_MAX_ADDR; i++) {
if (bus->phy_map[i])
device_unregister(&bus->phy_map[i]->dev);
bus->phy_map[i] = NULL;
}
+ device_del(&bus->dev);
}
EXPORT_SYMBOL(mdiobus_unregister);
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Linaro-acpi] [RFC 3/5] acpi/serial: add DBG2 earlycon support
On Tue, 2015-09-08 at 13:43 +0100, Leif Lindholm wrote:
> The ACPI DBG2 table defines a debug console. Add support for parsing it
> and using it to select earlycon destination when no arguments provided.
>
> Signed-off-by: Leif Lindholm
> ---
> arch/arm64/kernel/acpi.c | 2 +
> drivers/acpi/Makefile | 1 +
> drivers/acpi/console.c| 103
> ++
> drivers/of/fdt.c | 2 +-
> drivers/tty/serial/earlycon.c | 16 ---
> include/linux/acpi.h | 4 ++
> include/linux/serial_core.h | 9 ++--
> 7 files changed, 126 insertions(+), 11 deletions(-)
> create mode 100644 drivers/acpi/console.c
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index b9a5623..be7600a 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -207,6 +207,8 @@ void __init acpi_boot_table_init(void)
> if (!param_acpi_force)
> disable_acpi();
> }
> +
> + acpi_early_console_probe();
> }
>
> void __init acpi_gic_init(void)
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index b5e7cd8..a89587d 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -10,6 +10,7 @@ ccflags-$(CONFIG_ACPI_DEBUG)+= -DACPI_DEBUG_OUTPUT
> #
> obj-y+= tables.o
> obj-$(CONFIG_X86)+= blacklist.o
> +obj-y+= console.o
obj-$(CONFIG_SERIAL_EARLYCON) += console.o
to eliminate whole-file #ifdef
>
> #
> # ACPI Core Subsystem (Interpreter)
> diff --git a/drivers/acpi/console.c b/drivers/acpi/console.c
> new file mode 100644
> index 000..a985890
> --- /dev/null
> +++ b/drivers/acpi/console.c
> @@ -0,0 +1,103 @@
> +/*
> + * Copyright (c) 2012, Intel Corporation
> + * Copyright (c) 2015, Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#define DEBUG
> +#define pr_fmt(fmt) "ACPI: " KBUILD_MODNAME ": " fmt
> +
> +#include
> +#include
> +#include
> +
> +#define NUM_ELEMS(x) (sizeof(x) / sizeof(*x))
> +
> +#ifdef CONFIG_SERIAL_EARLYCON
> +static int use_earlycon __initdata;
> +static int __init setup_acpi_earlycon(char *buf)
> +{
> + if (!buf)
> + use_earlycon = 1;
> +
> + return 0;
> +}
> +early_param("earlycon", setup_acpi_earlycon);
> +
> +extern struct earlycon_id __earlycon_table[];
> +
> +static __initdata struct {
> + int id;
> + const char *name;
> +} subtypes[] = {
> + {0, "uart8250"},
> + {1, "uart8250"},
> + {2, NULL},
> + {3, "pl011"},
> +};
Instead of having a table here, why not have an ACPI_EARLYCON_DECLARE()
where individual drivers can provide an id similar to OF_EARLYCON_DECLARE()
providing compatible strings?
> +
> +static int __init acpi_setup_earlycon(unsigned long addr, const char *driver)
> +{
> + const struct earlycon_id *match;
> +
> + for (match = __earlycon_table; match->name[0]; match++)
> + if (strcmp(driver, match->name) == 0)
> + return setup_earlycon_driver(addr, match->setup);
> +
> + return -ENODEV;
> +}
> +
> +static int __init acpi_parse_dbg2(struct acpi_table_header *table)
> +{
> + struct acpi_table_dbg2 *dbg2;
> + struct acpi_dbg2_device *entry;
> + void *tbl_end;
> +
> + dbg2 = (struct acpi_table_dbg2 *)table;
> + if (!dbg2) {
> + pr_debug("DBG2 not present.\n");
> + return -ENODEV;
> + }
> +
> + tbl_end = (void *)table + table->length;
> +
> + entry = (struct acpi_dbg2_device *)((void *)dbg2 + dbg2->info_offset);
> +
> + while (((void *)entry) + sizeof(struct acpi_dbg2_device) < tbl_end) {
> + struct acpi_generic_address *addr;
> +
> + if (entry->revision != 0) {
> + pr_debug("DBG2 revision %d not supported.\n",
> + entry->revision);
> + return -ENODEV;
> + }
> +
> + addr = (void *)entry + entry->base_address_offset;
> +
> + pr_debug("DBG2 PROBE - console (%04x:%04x).\n",
> + entry->port_type, entry->port_subtype);
> +
> + if (use_earlycon &&
> + (entry->port_type == ACPI_DBG2_SERIAL_PORT) &&
> + (entry->port_subtype < NUM_ELEMS(subtypes)))
> + acpi_setup_earlycon(addr->address,
> + subtypes[entry->port_subtype].name);
Don't we need to handle space_id (and bit width) as well as address?
> +
> + entry = (struct acpi_dbg2_device *)
> + ((void *)entry + entry->length);
> + }
> +
> + return 0;
> +}
> +
> +int __init acpi_early_console_probe(void)
> +{
> + acpi_table_parse(ACPI_SIG_DBG2, acpi_parse_dbg2);
> +
>
Re: [Linaro-acpi] [RFC 3/5] acpi/serial: add DBG2 earlycon support
On Tue, 2015-09-08 at 18:17 +0100, Leif Lindholm wrote:
> On Tue, Sep 08, 2015 at 12:38:59PM -0400, Mark Salter wrote:
> > On Tue, 2015-09-08 at 13:43 +0100, Leif Lindholm wrote:
> > > The ACPI DBG2 table defines a debug console. Add support for parsing it
> > > and using it to select earlycon destination when no arguments provided.
> > >
> > > Signed-off-by: Leif Lindholm
> > > ---
> > > arch/arm64/kernel/acpi.c | 2 +
> > > drivers/acpi/Makefile | 1 +
> > > drivers/acpi/console.c| 103
> > > ++
> > > drivers/of/fdt.c | 2 +-
> > > drivers/tty/serial/earlycon.c | 16 ---
> > > include/linux/acpi.h | 4 ++
> > > include/linux/serial_core.h | 9 ++--
> > > 7 files changed, 126 insertions(+), 11 deletions(-)
> > > create mode 100644 drivers/acpi/console.c
> > >
> > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> > > index b9a5623..be7600a 100644
> > > --- a/arch/arm64/kernel/acpi.c
> > > +++ b/arch/arm64/kernel/acpi.c
> > > @@ -207,6 +207,8 @@ void __init acpi_boot_table_init(void)
> > > if (!param_acpi_force)
> > > disable_acpi();
> > > }
> > > +
> > > + acpi_early_console_probe();
> > > }
> > >
> > > void __init acpi_gic_init(void)
> > > diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> > > index b5e7cd8..a89587d 100644
> > > --- a/drivers/acpi/Makefile
> > > +++ b/drivers/acpi/Makefile
> > > @@ -10,6 +10,7 @@ ccflags-$(CONFIG_ACPI_DEBUG)+= -DACPI_DEBUG_OUTPUT
> > > #
> > > obj-y+= tables.o
> > > obj-$(CONFIG_X86)+= blacklist.o
> > > +obj-y+= console.o
> >
> > obj-$(CONFIG_SERIAL_EARLYCON) += console.o
> >
> > to eliminate whole-file #ifdef
>
> Yes, that makes more sense for this patch standalone, but I felt it
> would be a bit weird to add the conditionality here only to delete it
> in the subsequent patch. I don't feel strongly about it.
OIC. I didn't read ahead far enough.
>
> > >
> > > #
> > > # ACPI Core Subsystem (Interpreter)
> > > diff --git a/drivers/acpi/console.c b/drivers/acpi/console.c
> > > new file mode 100644
> > > index 000..a985890
> > > --- /dev/null
> > > +++ b/drivers/acpi/console.c
> > > @@ -0,0 +1,103 @@
> > > +/*
> > > + * Copyright (c) 2012, Intel Corporation
> > > + * Copyright (c) 2015, Linaro Ltd.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License version 2 as
> > > + * published by the Free Software Foundation.
> > > + *
> > > + */
> > > +
> > > +#define DEBUG
> > > +#define pr_fmt(fmt) "ACPI: " KBUILD_MODNAME ": " fmt
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#define NUM_ELEMS(x) (sizeof(x) / sizeof(*x))
> > > +
> > > +#ifdef CONFIG_SERIAL_EARLYCON
> > > +static int use_earlycon __initdata;
> > > +static int __init setup_acpi_earlycon(char *buf)
> > > +{
> > > + if (!buf)
> > > + use_earlycon = 1;
> > > +
> > > + return 0;
> > > +}
> > > +early_param("earlycon", setup_acpi_earlycon);
> > > +
> > > +extern struct earlycon_id __earlycon_table[];
> > > +
> > > +static __initdata struct {
> > > + int id;
> > > + const char *name;
> > > +} subtypes[] = {
> > > + {0, "uart8250"},
> > > + {1, "uart8250"},
> > > + {2, NULL},
> > > + {3, "pl011"},
> > > +};
> >
> > Instead of having a table here, why not have an ACPI_EARLYCON_DECLARE()
> > where individual drivers can provide an id similar to OF_EARLYCON_DECLARE()
> > providing compatible strings?
>
> The IDs are defined by the DBG2 specification, so it felt more
> natural to encapsulate it here. However, a comment to that effect
> would be useful. Or would you still prefer
> ACPI_EARLYCON_DECLARE(0, uart8250)
> ACPI_EARLYCON_DECLARE(1, uart8250)
> ...
> ?
The idea is that the driver itself is only place that needs to handle
a new uart type being supported rather than two places.
>
>
Re: [Linaro-acpi] [RFC 3/5] acpi/serial: add DBG2 earlycon support
On Tue, 2015-09-08 at 18:17 +0100, Leif Lindholm wrote:
> > > */
> > > - if (!buf || !buf[0])
> > > - if (IS_ENABLED(CONFIG_OF_FLATTREE))
> > > + if (!buf || !buf[0]) {
> > > + if (!acpi_disabled)
> >
> > How do we know for sure that "acpi" has been parsed before "earlycon"?
>
> Because "arch" comes before "drivers" in kernel image link order.
> *twitch*
> Yes, not the best argument ever.
>
I don't think that matters. Things are parsed in order they are
found on cmdline (except for early vs late distinction).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] c6x: fix platforms/plldata.c get_coreid build error
On Fri, 2018-01-19 at 11:19 -0800, Randy Dunlap wrote: > From: Randy Dunlap > > Fix build error reported by the 0day bot by including the header > file for that macro. Thanks. I pulled this into the c6x tree. > > Fixes this build error: (should fix; not tested) > arch/c6x/platforms/plldata.c: In function 'c6472_setup_clocks': > arch/c6x/platforms/plldata.c:279:33: error: implicit declaration of function > 'get_coreid'; did you mean 'get_order'? > [-Werror=implicit-function-declaration] > c6x_core_clk.parent = &sysclks[get_coreid() + 1]; > > Reported-by: Fengguang Wu > Cc: Mark Salter > Cc: Aurelien Jacquiot > Cc: linux-c6x-...@linux-c6x.org > Cc: Ingo Molnar > > Signed-off-by: Randy Dunlap > --- > arch/c6x/platforms/plldata.c |1 + > 1 file changed, 1 insertion(+) > > --- lnx-415-rc8.orig/arch/c6x/platforms/plldata.c > +++ lnx-415-rc8/arch/c6x/platforms/plldata.c > @@ -19,6 +19,7 @@ > > #include > #include > +#include > #include > > /* >
Re: [PATCH] arm64: turn off xgene branch prediction while in kernel space
On Wed, 2018-01-24 at 10:58 +, Marc Zyngier wrote:
> Khuong,
>
> On 24/01/18 02:13, Khuong Dinh wrote:
> > Aliasing attacks against CPU branch predictors can allow an attacker to
> > redirect speculative control flow on some CPUs and potentially divulge
> > information from one context to another.
> >
> > This patch only supports for XGene processors.
> >
> > Signed-off-by: Mark Salter
> > Signed-off-by: Khuong Dinh
> > ---
> > arch/arm64/include/asm/cpucaps.h |3 ++-
> > arch/arm64/include/asm/fixmap.h |4
> > arch/arm64/kernel/cpu_errata.c | 18 ++
> > arch/arm64/kernel/entry.S| 28
> > arch/arm64/kernel/smp.c | 34 ++
> > 5 files changed, 86 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/cpucaps.h
> > b/arch/arm64/include/asm/cpucaps.h
> > index bb26382..dc9ada1 100644
> > --- a/arch/arm64/include/asm/cpucaps.h
> > +++ b/arch/arm64/include/asm/cpucaps.h
> > @@ -45,7 +45,8 @@
> > #define ARM64_HARDEN_BRANCH_PREDICTOR 24
> > #define ARM64_HARDEN_BP_POST_GUEST_EXIT25
> > #define ARM64_HAS_RAS_EXTN 26
> > +#define ARM64_XGENE_HARDEN_BRANCH_PREDICTOR27
> >
>
> Why isn't this using the infrastructure that is already in place?
That infrastructure relies on a cpu-specific flush of the branch
predictor. XGene does not have the ability to flush the branch
predictor. It can only turn it on or off.
>
> > -#define ARM64_NCAPS27
> > +#define ARM64_NCAPS28
> >
> > #endif /* __ASM_CPUCAPS_H */
> > diff --git a/arch/arm64/include/asm/fixmap.h
> > b/arch/arm64/include/asm/fixmap.h
> > index ec1e6d6..d5400ca 100644
> > --- a/arch/arm64/include/asm/fixmap.h
> > +++ b/arch/arm64/include/asm/fixmap.h
> > @@ -63,6 +63,10 @@ enum fixed_addresses {
> > FIX_ENTRY_TRAMP_TEXT,
> > #define TRAMP_VALIAS (__fix_to_virt(FIX_ENTRY_TRAMP_TEXT))
> > #endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
> > +
> > +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
> > + FIX_BOOT_CPU_BP_CTLREG,
> > +#endif /* CONFIG_HARDEN_BRANCH_PREDICTOR */
> > __end_of_permanent_fixed_addresses,
> >
> > /*
> > diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> > index ed68818..1554014 100644
> > --- a/arch/arm64/kernel/cpu_errata.c
> > +++ b/arch/arm64/kernel/cpu_errata.c
> > @@ -53,6 +53,18 @@
> > (arm64_ftr_reg_ctrel0.sys_val &
> > arm64_ftr_reg_ctrel0.strict_mask);
> > }
> >
> > +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
> > +static bool is_xgene_cpu(const struct arm64_cpu_capabilities *entry, int
> > scope)
> > +{
> > + unsigned int midr = read_cpuid_id();
> > + unsigned int variant = MIDR_VARIANT(midr);
> > +
> > + WARN_ON(scope != SCOPE_LOCAL_CPU);
> > + return MIDR_IMPLEMENTOR(midr) == ARM_CPU_IMP_APM && (variant <= 3) &&
> > + is_hyp_mode_available();
> > +}
>
> So what happens in a guest? No BP invalidation whatsoever? I don't think
> that's acceptable.
>
> > +#endif
> > +
> > static int cpu_enable_trap_ctr_access(void *__unused)
> > {
> > /* Clear SCTLR_EL1.UCT */
> > @@ -369,6 +381,12 @@ static int qcom_enable_link_stack_sanitization(void
> > *data)
> > MIDR_ALL_VERSIONS(MIDR_CAVIUM_THUNDERX2),
> > .enable = enable_psci_bp_hardening,
> > },
> > + {
> > + .desc = "ARM64 XGENE branch predictors control",
> > + .capability = ARM64_XGENE_HARDEN_BRANCH_PREDICTOR,
> > + .def_scope = SCOPE_LOCAL_CPU,
> > + .matches = is_xgene_cpu,
> > + },
> > #endif
> > {
> > }
> > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > index b34e717..8c7d98e 100644
> > --- a/arch/arm64/kernel/entry.S
> > +++ b/arch/arm64/kernel/entry.S
> > @@ -62,6 +62,32 @@
> > #endif
> > .endm
> >
> > + .macro bp_disable, tmp1, tmp2
> > +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
> > + alternative_if ARM64_XGENE_HARDEN_BRANCH_PREDICTOR
> > + adr_l x\tmp1, bp_ctlreg
> > + mrs x\tmp2, tpidr_el1
> > + ldr x\tmp1, [x\tmp1, x\tmp2]
> > + ldr w\tmp2, [x\tmp1]
> > + orr w\tmp2, w\tmp2, #(1 << 25)
>
Re: [PATCH] acpi, spcr: Make SPCR available to x86
is a valid param for devicetree earlycons;
> - * don't generate a warning from parse_early_params() in that case
> - */
> + /* Just 'earlycon' is a valid param for devicetree and ACPI SPCR. */
> if (!buf || !buf[0]) {
> if (IS_ENABLED(CONFIG_ACPI_SPCR_TABLE)) {
> - earlycon_init_is_deferred = true;
> + earlycon_acpi_spcr_enable = true;
> return 0;
> } else if (!buf) {
> return early_init_dt_scan_chosen_stdout();
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index dc1ebfeeb5ec..9aac8f0ebe23 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -1242,9 +1242,12 @@ static inline void acpi_table_upgrade(void) { }
>
> #ifdef CONFIG_ACPI_SPCR_TABLE
> extern bool qdf2400_e44_present;
> -int parse_spcr(bool earlycon);
> +int acpi_parse_spcr(bool enable_earlycon, bool enable_console);
> #else
> -static inline int parse_spcr(bool earlycon) { return 0; }
> +static inline int acpi_parse_spcr(bool enable_earlycon, bool enable_console)
> +{
> + return 0;
> +}
> #endif
>
> #if IS_ENABLED(CONFIG_ACPI_GENERIC_GSI)
> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> index 37b044e78333..aefd0e5115da 100644
> --- a/include/linux/serial_core.h
> +++ b/include/linux/serial_core.h
> @@ -376,10 +376,10 @@ extern int of_setup_earlycon(const struct earlycon_id
> *match,
>const char *options);
>
> #ifdef CONFIG_SERIAL_EARLYCON
> -extern bool earlycon_init_is_deferred __initdata;
> +extern bool earlycon_acpi_spcr_enable __initdata;
> int setup_earlycon(char *buf);
> #else
> -static const bool earlycon_init_is_deferred;
> +static const bool earlycon_acpi_spcr_enable;
> static inline int setup_earlycon(char *buf) { return 0; }
> #endif
>
This looks okay to me. Tested on a variety of arm64 platforms.
Reviewed-by: Mark Salter
Tested-by: Mark Salter
