Re: [PATCH v2 2/2] console: don't select first registered console if stdout-path used
Hi Eugeniy,
On Wednesday, 6 September 2017 10:57:18 PDT Eugeniy Paltsev wrote:
> > > We retain previous behavior for tty0 console (if "stdout-path" used)
> > > as a special case:
> > > tty0 will be registered even if it was specified neither
> > > in "bootargs" nor in "stdout-path".
> > > We had to retain this behavior because a lot of ARM boards (and some
> > > powerpc) rely on it.
> >
> > My main concern is the exception for "tty". Yes, it was regiression
> > reported in the commit c6c7d83b9c9e6a8b3e ("Revert "console: don't
> > prefer first registered if DT specifies stdout-path""). But is this
> > the only possible regression?
> >
> > All this is about the fallback code that tries to enable all
> > consoles until a real one with tty binding (newcon->device)
> > is enabled.
> >
> > v1 version of you patch disabled this fallback code when a console
> > was defined by stdout-path in the device tree. This emulates
> > defining the console by console= parameter on the command line.
> >
> > It might make sense until some complains that a console is not
> > longer automatically enabled while it was before. But wait.
> > Someone already complained about "tty0". We can solve this
> > by adding an exception for "tty0". And if anyone else complains
> > about another console, we might need more exceptions.
> >
> > We might endup with so many exceptions that the fallback code
> > will be always used. But then we are back in the square
> > and have the original behavior before your patch.
>
> Yes, I understand your concerns.
>
> But I also have another concern: If we decide to left current behavior
> untouched (like after reverting patch 05fd007e4629)
> more and more boards and devices will use current broken stdout-path
> behavior in any form and in the results we will get the situation when we
> can't fix stdout-path behavior at all - because every change will break
> something somewhere.
> (05fd007e4629 patch do absolutely the same as v1 version of my patch)
>
> > This is why I would like to know more info about your problem.
> > We need to decide if it is more important than a regression.
> > Or if it can be fixed another way.
After the troubles with commit 05fd007e4629 ("console: don't prefer first
registered if DT specifies stdout-path") I took an alternate approach: rather
than preventing the first console being registered, I instead prevent the
bootconsole from being unregistered until we see the stdout-path console
probed.
For my systems, where there are 3 consoles involved, this is how it goes:
- The 8250 earlycon is our boot console.
- tty0 (from CONFIG_VT) comes along & gets registered fairly early, and
becomes the "proper" console. With current mainline this causes the boot
console to be unregistered & lose output over the UART for a while.
- Eventually ttyS0, the proper 8250 console, gets registered & we re-gain
UART output. If the system died between the tty0 & ttyS0 registering, it
dies silently.
With my current approach the difference is that the boot console sticks around
until the last step where ttyS0 is registered (or until the late_initcall
stage if ttyS0 never registers). This solves my problem - would it solve
yours?
I haven't submitted this patch yet, but you can find it here in a v4.13 based
downstream if you want to give it a try:
https://git.linux-mips.org/cgit/linux-mti.git/commit/?
h=eng-201705051946=dd144b12c899b591c0370715328199bc958878fe
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 6/9] kbuild: consolidate Devicetree dtb build rules
Hi Rob, On Wed, Sep 05, 2018 at 06:53:24PM -0500, Rob Herring wrote: > There is nothing arch specific about building dtb files other than their > location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. > The dependencies and supported targets are all slightly different. > Also, a cross-compiler for each arch is needed, but really the host > compiler preprocessor is perfectly fine for building dtbs. Move the > build rules to a common location and remove the arch specific ones. This > is done in a single step to avoid warnings about overriding rules. > > The build dependencies had been a mixture of 'scripts' and/or 'prepare'. > These pull in several dependencies some of which need a target compiler > (specifically devicetable-offsets.h) and aren't needed to build dtbs. > All that is really needed is dtc, so adjust the dependencies to only be > dtc. > > This change enables support 'dtbs_install' on some arches which were > missing the target. > >% > Signed-off-by: Rob Herring > --- > Please ack so I can take the whole series via the DT tree. For MIPS: Acked-by: Paul Burton Thanks, Paul ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 12/21] arch: use memblock_alloc() instead of memblock_alloc_from(size, align, 0)
Hi Mike, On Wed, Jan 16, 2019 at 03:44:12PM +0200, Mike Rapoport wrote: > The last parameter of memblock_alloc_from() is the lower limit for the > memory allocation. When it is 0, the call is equivalent to > memblock_alloc(). > > Signed-off-by: Mike Rapoport Acked-by: Paul Burton # MIPS part Thanks, Paul ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 19/21] treewide: add checks for the return value of memblock_alloc*()
Hi Mike,
On Wed, Jan 16, 2019 at 03:44:19PM +0200, Mike Rapoport wrote:
> Add check for the return value of memblock_alloc*() functions and call
> panic() in case of error.
> The panic message repeats the one used by panicing memblock allocators with
> adjustment of parameters to include only relevant ones.
>
> The replacement was mostly automated with semantic patches like the one
> below with manual massaging of format strings.
>
> @@
> expression ptr, size, align;
> @@
> ptr = memblock_alloc(size, align);
> + if (!ptr)
> + panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__,
> size, align);
>
> Signed-off-by: Mike Rapoport
> ---
>%
> diff --git a/arch/mips/cavium-octeon/dma-octeon.c
> b/arch/mips/cavium-octeon/dma-octeon.c
> index e8eb60e..db1deb2 100644
> --- a/arch/mips/cavium-octeon/dma-octeon.c
> +++ b/arch/mips/cavium-octeon/dma-octeon.c
> @@ -245,6 +245,9 @@ void __init plat_swiotlb_setup(void)
> swiotlbsize = swiotlb_nslabs << IO_TLB_SHIFT;
>
> octeon_swiotlb = memblock_alloc_low(swiotlbsize, PAGE_SIZE);
> + if (!octeon_swiotlb)
> + panic("%s: Failed to allocate %lu bytes align=%lx\n",
> + __func__, swiotlbsize, PAGE_SIZE);
>
> if (swiotlb_init_with_tbl(octeon_swiotlb, swiotlb_nslabs, 1) == -ENOMEM)
> panic("Cannot allocate SWIOTLB buffer");
That one should be %zu rather than %lu. The rest looks good, so with
that one tweak:
Acked-by: Paul Burton # MIPS parts
Thanks,
Paul
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 1/2] mips/kgdb: prepare arch_kgdb_ops for constness
Hi Christophe & Daniel, On Thu, Dec 06, 2018 at 02:09:02PM +, Daniel Thompson wrote: > On Wed, Dec 05, 2018 at 04:41:09AM +, Christophe Leroy wrote: > > MIPS is the only architecture modifying arch_kgdb_ops during init. > > This patch makes the init static, so that it can be changed to > > const in following patch, as recommended by checkpatch.pl > > > > Suggested-by: Paul Burton > > Signed-off-by: Christophe Leroy > > From my side this is > Acked-by: Daniel Thompson > > Since this is a dependency for the next patch I'd be happy to take via > my tree... but would need an ack from the MIPS guys to do that. For both patches in this series: Acked-by: Paul Burton Thanks, Paul ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 16/15] syscall_get_arch: add "struct task_struct *" argument
Hi Dmitry,
On Wed, Nov 21, 2018 at 03:44:22AM +0300, Dmitry V. Levin wrote:
> This argument is required to extend the generic ptrace API
> with PTRACE_GET_SYSCALL_INFO request: syscall_get_arch() is going to be
> called from ptrace_request() along with other syscall_get_* functions
> with a tracee as their argument.
>
> This change partially reverts commit 5e937a9ae913 ("syscall_get_arch:
> remove useless function arguments").
>
>%
>
> diff --git a/arch/mips/include/asm/syscall.h b/arch/mips/include/asm/syscall.h
> index 0170602a1e4e..52b633f20abd 100644
> --- a/arch/mips/include/asm/syscall.h
> +++ b/arch/mips/include/asm/syscall.h
> @@ -73,7 +73,7 @@ static inline unsigned long mips_get_syscall_arg(unsigned
> long *arg,
> #ifdef CONFIG_64BIT
> case 4: case 5: case 6: case 7:
> #ifdef CONFIG_MIPS32_O32
> - if (test_thread_flag(TIF_32BIT_REGS))
> + if (test_ti_thread_flag(task_thread_info(task), TIF_32BIT_REGS))
> return get_user(*arg, (int *)usp + n);
> else
> #endif
This ought to be test_tsk_thread_flag(task, TIF_32BIT_REGS) instead of
open-coding test_tsk_thread_flag.
More fundamentally though, this change doesn't seem to be (directly)
related to the change you describe in the commit message - it's not
syscall_get_arch being modified here. I suspect this should be a
separate commit, or if not please explain in the commit message why this
change is included.
Compounding the lack of clarity is the fact that I only received this
patch, not the whole series, so I can't view the change in the context
of the rest of the series.
> @@ -140,14 +140,14 @@ extern const unsigned long sys_call_table[];
> extern const unsigned long sys32_call_table[];
> extern const unsigned long sysn32_call_table[];
>
> -static inline int syscall_get_arch(void)
> +static inline int syscall_get_arch(struct task_struct *task)
> {
> int arch = AUDIT_ARCH_MIPS;
> #ifdef CONFIG_64BIT
> - if (!test_thread_flag(TIF_32BIT_REGS)) {
> + if (!test_ti_thread_flag(task_thread_info(task), TIF_32BIT_REGS)) {
> arch |= __AUDIT_ARCH_64BIT;
> /* N32 sets only TIF_32BIT_ADDR */
> - if (test_thread_flag(TIF_32BIT_ADDR))
> + if (test_ti_thread_flag(task_thread_info(task), TIF_32BIT_ADDR))
> arch |= __AUDIT_ARCH_CONVENTION_MIPS64_N32;
> }
> #endif
This does seem like the described change, but there are 2 more instances
of open-coding test_tsk_thread_flag which ought to be cleaned up.
Thanks,
Paul
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 16/15 v2] syscall_get_arch: add "struct task_struct *" argument
Hi Dmitry,
On Wed, Nov 21, 2018 at 10:35:12PM +0300, Dmitry V. Levin wrote:
> This argument is required to extend the generic ptrace API with
> PTRACE_GET_SYSCALL_INFO request: syscall_get_arch() is going to be
> called from ptrace_request() along with other syscall_get_* functions
> with a tracee as their argument.
>
> This change partially reverts commit 5e937a9ae913 ("syscall_get_arch:
> remove useless function arguments").
>
> Reviewed-by: Andy Lutomirski # for x86
> Reviewed-by: Palmer Dabbelt
> Cc: linux-au...@redhat.com
> Cc: linux-al...@vger.kernel.org
> Cc: linux-a...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-c6x-...@linux-c6x.org
> Cc: linux-hexa...@vger.kernel.org
> Cc: linux-i...@vger.kernel.org
> Cc: linux-m...@lists.linux-m68k.org
> Cc: linux-m...@linux-mips.org
> Cc: linux-par...@vger.kernel.org
> Cc: linux-ri...@lists.infradead.org
> Cc: linux-s...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: linux-snps-arc@lists.infradead.org
> Cc: linux...@lists.infradead.org
> Cc: linux-xte...@linux-xtensa.org
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: nios2-...@lists.rocketboards.org
> Cc: openr...@lists.librecores.org
> Cc: sparcli...@vger.kernel.org
> Cc: uclinux-h8-de...@lists.sourceforge.jp
> Cc: x...@kernel.org
> Signed-off-by: Dmitry V. Levin
> ---
>
> v2: cleaned up mips part, added Reviewed-by
I thought the last one was v2? :)
Anyway, this looks fine to me now:
Acked-by: Paul Burton # MIPS parts
Thanks,
Paul
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 5/6 v3] syscalls: Remove start and number from syscall_get_arguments() args
Hi Steven, On Mon, Apr 01, 2019 at 09:41:09AM -0400, Steven Rostedt wrote: > From: "Steven Rostedt (Red Hat)" > > At Linux Plumbers, Andy Lutomirski approached me and pointed out that the > function call syscall_get_arguments() implemented in x86 was horribly > written and not optimized for the standard case of passing in 0 and 6 for > the starting index and the number of system calls to get. When looking at > all the users of this function, I discovered that all instances pass in only > 0 and 6 for these arguments. Instead of having this function handle > different cases that are never used, simply rewrite it to return the first 6 > arguments of a system call. > > This should help out the performance of tracing system calls by ptrace, > ftrace and perf. > > Link: http://lkml.kernel.org/r/20161107213233.754809...@goodmis.org > > Cc: Oleg Nesterov > Cc: Thomas Gleixner > Cc: Kees Cook > Cc: Andy Lutomirski > Cc: Dominik Brodowski > Cc: Dave Martin > Cc: "Dmitry V. Levin" > Cc: x...@kernel.org > Cc: linux-snps-arc@lists.infradead.org > Cc: linux-ker...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-c6x-...@linux-c6x.org > Cc: uclinux-h8-de...@lists.sourceforge.jp > Cc: linux-hexa...@vger.kernel.org > Cc: linux-i...@vger.kernel.org > Cc: linux-m...@vger.kernel.org > Cc: nios2-...@lists.rocketboards.org > Cc: openr...@lists.librecores.org > Cc: linux-par...@vger.kernel.org > Cc: linuxppc-...@lists.ozlabs.org > Cc: linux-ri...@lists.infradead.org > Cc: linux-s...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: sparcli...@vger.kernel.org > Cc: linux...@lists.infradead.org > Cc: linux-xte...@linux-xtensa.org > Cc: linux-a...@vger.kernel.org > Reported-by: Andy Lutomirski > Signed-off-by: Steven Rostedt (VMware) Acked-by: Paul Burton # MIPS parts Thanks, Paul ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 06/12] dma-mapping: improve selection of dma_declare_coherent availability
Hi Christoph, On Mon, Feb 11, 2019 at 02:35:48PM +0100, Christoph Hellwig wrote: > This API is primarily used through DT entries, but two architectures > and two drivers call it directly. So instead of selecting the config > symbol for random architectures pull it in implicitly for the actual > users. Also rename the Kconfig option to describe the feature better. > > Signed-off-by: Christoph Hellwig Acked-by: Paul Burton # MIPS Thanks, Paul ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 1/2] dma-mapping: add a kconfig symbol for arch_setup_dma_ops availability
Hi Christoph, On Mon, Feb 04, 2019 at 09:14:19AM +0100, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig > --- > arch/arc/Kconfig | 1 + > arch/arc/include/asm/Kbuild | 1 + > arch/arc/include/asm/dma-mapping.h | 13 - > arch/arm/Kconfig | 1 + > arch/arm/include/asm/dma-mapping.h | 4 > arch/arm64/Kconfig | 1 + > arch/arm64/include/asm/dma-mapping.h | 4 > arch/mips/Kconfig| 1 + > arch/mips/include/asm/dma-mapping.h | 10 -- > arch/mips/mm/dma-noncoherent.c | 8 Acked-by: Paul Burton # MIPS Thanks, Paul ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 04/26] mips: remove ioremap_cachable
Hi Christoph, On Sat, Aug 17, 2019 at 09:32:31AM +0200, Christoph Hellwig wrote: > Just define ioremap_cache directly. > > Signed-off-by: Christoph Hellwig Acked-by: Paul Burton Thanks, Paul > --- > arch/mips/include/asm/io.h | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h > index 97a280640daf..c02db986ddf5 100644 > --- a/arch/mips/include/asm/io.h > +++ b/arch/mips/include/asm/io.h > @@ -262,11 +262,11 @@ static inline void __iomem *ioremap_prot(phys_addr_t > offset, > #define ioremap_uc ioremap_nocache > > /* > - * ioremap_cachable -map bus memory into CPU space > + * ioremap_cache - map bus memory into CPU space > * @offset: bus address of the memory > * @size:size of the resource to map > * > - * ioremap_nocache performs a platform specific sequence of operations to > + * ioremap_cache performs a platform specific sequence of operations to > * make bus memory CPU accessible via the readb/readw/readl/writeb/ > * writew/writel functions and the other mmio helpers. The returned > * address is not guaranteed to be usable directly as a virtual > @@ -276,9 +276,8 @@ static inline void __iomem *ioremap_prot(phys_addr_t > offset, > * the CPU. Also enables full write-combining. Useful for some > * memory-like regions on I/O busses. > */ > -#define ioremap_cachable(offset, size) > \ > +#define ioremap_cache(offset, size) \ > __ioremap_mode((offset), (size), _page_cachable_default) > -#define ioremap_cache ioremap_cachable > > /* > * ioremap_wc - map bus memory into CPU space > -- > 2.20.1 > ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 04/26] mips: remove ioremap_cachable
Hello, Christoph Hellwig wrote: > Just define ioremap_cache directly. Applied to mips-next. > commit 60af0d94cc37 > https://git.kernel.org/mips/c/60af0d94cc37 > > Signed-off-by: Christoph Hellwig > Signed-off-by: Paul Burton Thanks, Paul [ This message was auto-generated; if you believe anything is incorrect then please email paul.bur...@mips.com to report it. ] ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
