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
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 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 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 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 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 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 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 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 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&id=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