Re: [PATCH 1/2] Input: synaptics-rmi4 - clear irqs before set irqs
Hi Dmitry and Chiristopher: Do you have any suggestion about these 2 patches? Many users confirmed that they fixed issues of Trackpoint/Touchpad after S3. Will you consider them be accepted? Thanks, Aaron
Re: [git pull v2] habanalabs fixes for 5.1-rc3
On Wed, Mar 27, 2019 at 3:09 AM Greg KH wrote: > > On Tue, Mar 26, 2019 at 10:13:35AM +0200, Oded Gabbay wrote: > > Hi Greg, > > > > A couple of important fixes for habanalabs driver: > > > > - Fix host crash upon resume after suspend > > - Fix MMU related bugs which result in user's jobs getting stuck > > - Fix race between user context cleanup and hard-reset which results in > > host crash > > - Fix sparse warning > > Much better, thanks, now pulled and pushed out. > > greg k-h Hi Greg, In which branch do I see that ? I tried to find it in your char-misc repo but couldn't find it. Thanks, Oded
Re: 答复: Re: [v5] coccinelle: semantic code search for missing put_device()
On Thu, 28 Mar 2019, wen.yan...@zte.com.cn wrote: > > > > When I searched "Wen Yang", v6 did not show up for some reasons. > > > > https://lore.kernel.org/patchwork/project/lkml/list/?series==22638=*=== > > > > > > I find such a situation also interesting somehow. > > > I assume that there was another temporary technical difficulty involved > > > with the Linux mailing list (and related information systems). > > > > > > I think v6 fell into a crack somehow. > > > > > > Check the LKML archive: > > https://lkml.org/lkml/2019/2/16 > > > > > > I see your reply: > > > > Re: [v6] coccinelle: semantic code search for missing put_device()Markus > > Elfring > > > > > > But, I cannot find the v6 patch itself. > > > > I am sorry to bother you. > I checked it again and found that I can not send mail to > > via my private mailbox . > The reject reply like this: > > for your MAIL FROM address policy analysis > reported: Your address is not liked source for email > > Is it looked my mail as spam mail? > Who should I send to for help me resolving this problem? Maybe Konstantin Ryabitsev? julia > > > -- > Best Regards > Wen
Re: [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework
On Wed, Mar 27, 2019 at 11:25 AM Greg KH wrote:
>
> On Tue, Mar 05, 2019 at 12:54:29PM -0800, John Stultz wrote:
> > From: "Andrew F. Davis"
> >
> > This framework allows a unified userspace interface for dma-buf
> > exporters, allowing userland to allocate specific types of
> > memory for use in dma-buf sharing.
> >
> > Each heap is given its own device node, which a user can
> > allocate a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
> >
> > This code is an evoluiton of the Android ION implementation,
> > and a big thanks is due to its authors/maintainers over time
> > for their effort:
> > Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard,
> > Laura Abbott, and many other contributors!
>
> Comments just on the user/kernel api and how it interacts with the
> driver model. Not on the "real" functionality of this code :)
Thanks so much for the feedback! In some cases Andrew and I have
already made the changes you've suggested, and hopefully will have a
new version to share soon.
> > +#define DEVNAME "dma_heap"
> > +
> > +#define NUM_HEAP_MINORS 128
>
> Why a max?
Mostly because other drivers do. I'll see if this can be removed with
the Xarray bits.
> > +static DEFINE_IDR(dma_heap_idr);
> > +static DEFINE_MUTEX(minor_lock); /* Protect idr accesses */
>
> Move to use xarray now so that Matthew doesn't have to send patches
> converting this code later :)
>
> It also allows you to drop the mutex.
Yep. Already converted to Xarray, it is nicer!
> > +dev_t dma_heap_devt;
> > +struct class *dma_heap_class;
> > +struct list_head dma_heap_list;
> > +struct dentry *dma_heap_debug_root;
>
> Global variables?
Oops. Will make those static. Thanks!
> > +
> > +static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
> > + unsigned int flags)
> > +{
> > + len = PAGE_ALIGN(len);
> > + if (!len)
> > + return -EINVAL;
> > +
> > + return heap->ops->allocate(heap, len, flags);
> > +}
> > +
> > +static int dma_heap_open(struct inode *inode, struct file *filp)
> > +{
> > + struct dma_heap *heap;
> > +
> > + mutex_lock(_lock);
> > + heap = idr_find(_heap_idr, iminor(inode));
> > + mutex_unlock(_lock);
> > + if (!heap) {
> > + pr_err("dma_heap: minor %d unknown.\n", iminor(inode));
> > + return -ENODEV;
> > + }
> > +
> > + /* instance data as context */
> > + filp->private_data = heap;
> > + nonseekable_open(inode, filp);
> > +
> > + return 0;
> > +}
> > +
> > +static int dma_heap_release(struct inode *inode, struct file *filp)
> > +{
> > + filp->private_data = NULL;
>
> Why does this matter? release should only be called on the way out of
> here, no need to do anything as nothing else can be called, right?
>
> release shouldn't be needed from what I can tell.
Yep. Christoph suggested the same and its been removed already.
> > + if (heap_allocation.flags & ~DMA_HEAP_VALID_FLAGS) {
> > + pr_warn_once("dma_heap: flags has invalid or
> > unsupported flags set\n");
> > + return -EINVAL;
> > + }
> > +
> > + fd = dma_heap_buffer_alloc(heap, heap_allocation.len,
> > +heap_allocation.flags);
>
> No max value checking for .len? Can you really ask for anything?
So I think any length caps would be heap specific, so we want to pass
them on here.
> > +static const struct file_operations dma_heap_fops = {
> > + .owner = THIS_MODULE,
> > + .open = dma_heap_open,
> > + .release= dma_heap_release,
> > + .unlocked_ioctl = dma_heap_ioctl,
> > +#ifdef CONFIG_COMPAT
> > + .compat_ioctl = dma_heap_ioctl,
> > +#endif
>
> Why is compat_ioctl even needed?
Probably my mistake. I didn't realize if we're running 32bit on 64bit
and there's no compat, the unlocked_ioctl gets called.
> > + /* Find unused minor number */
> > + mutex_lock(_lock);
> > + ret = idr_alloc(_heap_idr, heap, 0, NUM_HEAP_MINORS, GFP_KERNEL);
> > + mutex_unlock(_lock);
>
> Again, xarray.
Ack.
> But I will ask you to back up, why need a major number at all? Why not
> just use the misc subsystem? How many of these are you going to have
> over time in a "normal" system? How about a "abnormal system"?
So early implementations did use misc, but in order to get the
/dev/heap/cma_heap style directories, in both Android and classic udev
linux systems I had to create a class.
This v2 patch didn't get it quite right (got it working properly in
android but not on classic systems), but the next version does get the
subdir created properly (similar to how the input layer does it).
As for number of heaps, I wouldn't expect there to be a ton on any
given system. Most likely less then 16, but possibly up to 32. 128
seemed like a safe "crazy out there" cap. But perspectives on crazy
shift over time :)
> We have seen people running Android in "containers"
Re: [PATCH v4] kmemleak: survive in a low-memory situation
Hi, On 27/03/2019 2.59, Qian Cai wrote: Unless there is a brave soul to reimplement the kmemleak to embed it's metadata into the tracked memory itself in a foreseeable future, this provides a good balance between enabling kmemleak in a low-memory situation and not introducing too much hackiness into the existing code for now. Unfortunately I am not that brave soul, but I'm wondering what the complication here is? It shouldn't be too hard to teach calculate_sizes() in SLUB about a new SLAB_KMEMLEAK flag that reserves spaces for the metadata. - Pekka
Re: [PATCH] kernel/trace/trace.h: Remove duplicate header
On 3/28/2019 3:49 AM, jagdsh.li...@gmail.com wrote: From: Jagadeesh Pagadala Remove duplicate header which is included twice. Signed-off-by: Jagadeesh Pagadala Reviewed-by: Mukesh Ojha -Mukesh --- kernel/trace/trace.h | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h index d80cee4..e1e16f9 100644 --- a/kernel/trace/trace.h +++ b/kernel/trace/trace.h @@ -15,7 +15,6 @@ #include #include #include -#include #include #ifdef CONFIG_FTRACE_SYSCALLS
Re: [PATCH 3/7] RISC-V: Rework kernel's virtual address space mapping
On Thu, Mar 28, 2019 at 11:09 AM Palmer Dabbelt wrote: > > On Wed, 27 Mar 2019 14:36:39 PDT (-0700), log...@deltatee.com wrote: > > The motivation for this is to support P2P transactions. P2P requires > > having struct pages for IO memory which means the linear mapping must > > be able to cover all of the IO regions. Unfortunately with Sv39 we are > > not able to cover all the IO regions available on existing hardware, > > but we can do better than what we currently do (which only cover's > > physical memory). > > > > To this end, we restructure the kernel's virtual address space region. > > We position the vmemmap at the beginning of the region (based on how > > many virtual address bits we have) and the VMALLOC region comes > > immediately after. The linear mapping then takes up the remaining space. > > PAGE_OFFSET will need to be within the linear mapping but may not be > > the start of the mapping seeing many machines don't have RAM at address > > zero and we may still want to access lower addresses through the > > linear mapping. > > > > With these changes, on a 64-bit system the virtual memory map (with > > sparsemem enabled) will be: > > > > 32-bit: > > > > - 7fff user space, different per mm (2G) > > 8000 - 81ff virtual memory map (32MB) > > 8200 - bfff vmalloc/ioremap space (1GB - 32MB) > > c000 - direct mapping of all phys. memory (1GB) > > > > 64-bit, Sv39: > > > > - 003f user space, different per mm (256GB) > > hole caused by [38:63] sign extension > > ffc0 - ffc0 virtual memory map (4GB) > > ffc1 - ffd0 vmalloc/ioremap spac (64GB) > > ffd1 - linear mapping of phys. space (188GB) > > > > On the Sifive hardware this allows us to provide struct pages for > > the lower I/O TileLink address ranges, the 32-bit and 34-bit DRAM areas > > and 172GB of 240GB of the high I/O TileLink region. Once we progress to > > Sv48 we should be able to cover all the available memory regions.. > > > > For the MAXPHYSMEM_2GB case, the physical memory must be in the highest > > 2GB of address space, so we cannot cover the any of the I/O regions > > that are higher than it but we do cover the lower I/O TileLink range. > > IIRC there was another patch floating around to fix an issue with overlapping > regions in the 32-bit port, did you also fix that issue? It's somewhere in my > email queue... That was a patch I submitted to fix overlapping FIXMAP and VMALLOC regions. This patch does not consider FIXMAP region. I suggest we introduce asm/memory.h where we have all critical defines related to virtual memory layout. Also, this header should have detailed comments about virtual memory layout. > > > Signed-off-by: Logan Gunthorpe > > Cc: Palmer Dabbelt > > Cc: Albert Ou > > Cc: Antony Pavlov > > Cc: "Stefan O'Rear" > > Cc: Anup Patel > > --- > > arch/riscv/Kconfig | 2 +- > > arch/riscv/include/asm/page.h| 2 -- > > arch/riscv/include/asm/pgtable.h | 27 ++- > > 3 files changed, 19 insertions(+), 12 deletions(-) > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > > index 76fc340ae38e..d21e6a12e8b6 100644 > > --- a/arch/riscv/Kconfig > > +++ b/arch/riscv/Kconfig > > @@ -71,7 +71,7 @@ config PAGE_OFFSET > > hex > > default 0xC000 if 32BIT && MAXPHYSMEM_2GB > > default 0x8000 if 64BIT && MAXPHYSMEM_2GB > > - default 0xffe0 if 64BIT && MAXPHYSMEM_128GB > > + default 0xffd2 if 64BIT && MAXPHYSMEM_128GB > > > > config ARCH_FLATMEM_ENABLE > > def_bool y > > diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h > > index 2a546a52f02a..fa0b8058a246 100644 > > --- a/arch/riscv/include/asm/page.h > > +++ b/arch/riscv/include/asm/page.h > > @@ -31,8 +31,6 @@ > > */ > > #define PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL) > > > > -#define KERN_VIRT_SIZE (-PAGE_OFFSET) > > - > > #ifndef __ASSEMBLY__ > > > > #define PAGE_UP(addr)(((addr)+((PAGE_SIZE)-1))&(~((PAGE_SIZE)-1))) > > diff --git a/arch/riscv/include/asm/pgtable.h > > b/arch/riscv/include/asm/pgtable.h > > index 5a9fea00ba09..2a5070540996 100644 > > --- a/arch/riscv/include/asm/pgtable.h > > +++ b/arch/riscv/include/asm/pgtable.h > > @@ -89,22 +89,31 @@ extern pgd_t swapper_pg_dir[]; > > #define __S110 PAGE_SHARED_EXEC > > #define __S111 PAGE_SHARED_EXEC > > > > -#define VMALLOC_SIZE (KERN_VIRT_SIZE >> 1) > > -#define VMALLOC_END (PAGE_OFFSET - 1) > > -#define VMALLOC_START(PAGE_OFFSET - VMALLOC_SIZE) > > +#define KERN_SPACE_START (-1UL << (CONFIG_VA_BITS - 1)) > > > > /* > > * Roughly size the vmemmap space to be large enough to fit enough > > * struct pages to map half the virtual address space. Then > > * position vmemmap directly below the VMALLOC region. > > */ > > -#define VMEMMAP_SHIFT \ > > -
Re: [git pull v2] habanalabs fixes for 5.1-rc3
On Thu, Mar 28, 2019 at 08:09:13AM +0200, Oded Gabbay wrote: > On Wed, Mar 27, 2019 at 3:09 AM Greg KH wrote: > > > > On Tue, Mar 26, 2019 at 10:13:35AM +0200, Oded Gabbay wrote: > > > Hi Greg, > > > > > > A couple of important fixes for habanalabs driver: > > > > > > - Fix host crash upon resume after suspend > > > - Fix MMU related bugs which result in user's jobs getting stuck > > > - Fix race between user context cleanup and hard-reset which results in > > > host crash > > > - Fix sparse warning > > > > Much better, thanks, now pulled and pushed out. > > > > greg k-h > > Hi Greg, > In which branch do I see that ? I tried to find it in your char-misc > repo but couldn't find it. It should be in the char-misc-linus branch of the char-misc.git repo on git.kernel.org. Note, I was in the air for a long time yesterday, so the emails probably went out 8 hours before I was able to push out the git repo, but it should all be synced up now. Sorry for any confusion there. greg k-h
Re: [PATCH v2] tty:serial_core: Spelling mistake
On 3/28/2019 8:47 AM, Hariprasad Kelam wrote: fix spelling mistake "overriden" -> "overridden" This fix resolves warning reported by checkpatch tool. Signed-off-by: Hariprasad Kelam Reviewed-by: Mukesh Ojha -Mukesh --- Changes in V2: -Make commit message more clear --- drivers/tty/serial/serial_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index 351843f..69f4871 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -1514,7 +1514,7 @@ static void uart_set_termios(struct tty_struct *tty, } uart_change_speed(tty, state, old_termios); - /* reload cflag from termios; port driver may have overriden flags */ + /* reload cflag from termios; port driver may have overridden flags */ cflag = tty->termios.c_cflag; /* Handle transition to B0 status */
[PATCH v2] RISC-V: Implement ASID allocator
Currently, we do local TLB flush on every MM switch. This is very harsh
on performance because we are forcing page table walks after every MM
switch.
This patch implements ASID allocator for assigning an ASID to every MM
context. The number of ASIDs are limited in HW so we create a logical
entity named CONTEXTID for assigning to MM context. The lower bits of
CONTEXTID are ASID and upper bits are VERSION number. The number of
usable ASID bits supported by HW are detected at boot-time by writing
1s to ASID bits in SATP CSR. This means last ASID is always reserved
because it is used for initial MM context.
We allocate new CONTEXTID on first MM switch for a MM context where
the ASID is allocated from an ASID bitmap and VERSION is provide by
an atomic counter. At time of allocating new CONTEXTID, if we run out
of available ASIDs then:
1. We flush the ASID bitmap
2. Increment current VERSION atomic counter
3. Re-allocate ASID from ASID bitmap
4. Flush TLB on all CPUs
5. Try CONTEXTID re-assignment on all CPUs
Using above approach, we have virtually infinite CONTEXTIDs on-top-of
limited number of HW ASIDs. This approach is inspired from ASID allocator
used for Linux ARM/ARM64 but we have adapted it for RISC-V. Overall,
this ASID allocator helps us reduce rate of local TLB flushes on every
CPU thereby increasing performance.
This patch is tested on QEMU/virt machine and SiFive Unleashed board.
On QEMU/virt machine, we see 10% (approx) performance improvement with
SW emulated TLBs provided by QEMU. Unfortunately, ASID bits of SATP CSR
are not implemented on SiFive Unleashed board so we don't see any change
in performance.
Signed-off-by: Gary Guo
Signed-off-by: Anup Patel
---
Changes since v1:
- We adapt good aspects from Gary Guo's ASID allocator implementation
and provide due credit to him by adding his SoB.
- Track ASIDs active during context flush and mark them as reserved
- Set ASID bits to all 1s to simplify number of ASID bit detection
- Use atomic_long_t instead of atomic64_t for being 32bit friendly
- Use unsigned long instead of u64 for being 32bit friendly
- Use flush_tlb_all() instead of lazy local_tlb_flush_all() at time
of context flush
This patch is based on Linux-5.1-rc2 and TLB flush cleanup patches v4
from Gary Guo. It can be also found in riscv_asid_allocator_v2 branch
of https://github.com/avpatel/linux.git
---
arch/riscv/include/asm/csr.h | 6 +
arch/riscv/include/asm/mmu.h | 1 +
arch/riscv/include/asm/mmu_context.h | 1 +
arch/riscv/kernel/head.S | 2 +
arch/riscv/mm/context.c | 249 +--
5 files changed, 247 insertions(+), 12 deletions(-)
diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h
index 28a0d1cb374c..ce18ab8f53ed 100644
--- a/arch/riscv/include/asm/csr.h
+++ b/arch/riscv/include/asm/csr.h
@@ -45,10 +45,16 @@
#define SATP_PPN _AC(0x003F, UL)
#define SATP_MODE_32 _AC(0x8000, UL)
#define SATP_MODESATP_MODE_32
+#define SATP_ASID_BITS 9
+#define SATP_ASID_SHIFT22
+#define SATP_ASID_MASK _AC(0x1FF, UL)
#else
#define SATP_PPN _AC(0x0FFF, UL)
#define SATP_MODE_39 _AC(0x8000, UL)
#define SATP_MODESATP_MODE_39
+#define SATP_ASID_BITS 16
+#define SATP_ASID_SHIFT44
+#define SATP_ASID_MASK _AC(0x, UL)
#endif
/* Interrupt Enable and Interrupt Pending flags */
diff --git a/arch/riscv/include/asm/mmu.h b/arch/riscv/include/asm/mmu.h
index 5df2dccdba12..42a9ca0fe1fb 100644
--- a/arch/riscv/include/asm/mmu.h
+++ b/arch/riscv/include/asm/mmu.h
@@ -18,6 +18,7 @@
#ifndef __ASSEMBLY__
typedef struct {
+ atomic_long_t id;
void *vdso;
#ifdef CONFIG_SMP
/* A local icache flush is needed before user execution can resume. */
diff --git a/arch/riscv/include/asm/mmu_context.h
b/arch/riscv/include/asm/mmu_context.h
index bf4f097a9051..ba6ab35c18dc 100644
--- a/arch/riscv/include/asm/mmu_context.h
+++ b/arch/riscv/include/asm/mmu_context.h
@@ -30,6 +30,7 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
static inline int init_new_context(struct task_struct *task,
struct mm_struct *mm)
{
+ atomic_long_set(&(mm)->context.id, 0);
return 0;
}
diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
index fe884cd69abd..c3f9adc0d054 100644
--- a/arch/riscv/kernel/head.S
+++ b/arch/riscv/kernel/head.S
@@ -95,6 +95,8 @@ relocate:
la a2, swapper_pg_dir
srl a2, a2, PAGE_SHIFT
li a1, SATP_MODE
+ li a0, (SATP_ASID_MASK << SATP_ASID_SHIFT)
+ or a1, a1, a0
or a2, a2, a1
/*
diff --git a/arch/riscv/mm/context.c b/arch/riscv/mm/context.c
index 0f787bcd3a7a..1205d33d1b1b 100644
--- a/arch/riscv/mm/context.c
+++ b/arch/riscv/mm/context.c
@@ -2,13 +2,209 @@
/*
* Copyright (C) 2012 Regents of the University of California
* Copyright (C) 2017 SiFive
+ * Copyright (C) 2019 Western Digital Corporation or its affiliates.
*/
Re: [PATCH] selftests:powerpc/tm/tm-vmx-unavail.c : Remove duplicate header
On 3/28/2019 3:19 AM, jagdsh.li...@gmail.com wrote: From: Jagadeesh Pagadala Remove duplicate header which is included twice. Signed-off-by: Jagadeesh Pagadala Reviewed-by: Mukesh Ojha -Mukesh --- tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c b/tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c index 137185b..1cb963a 100644 --- a/tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c +++ b/tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c @@ -17,7 +17,6 @@ #include #include #include -#include #include "tm.h" #include "utils.h"
Re: [PATCH] arch:sparc:kernel/uprobes.c : Remove duplicate header
On 3/28/2019 2:58 AM, jagdsh.li...@gmail.com wrote: From: Jagadeesh Pagadala Remove duplicate header which is included twice. Signed-off-by: Jagadeesh Pagadala Looks good to me. but did you tested at least the compilation with these patches ? Reviewed-by: Mukesh Ojha -Mukesh --- arch/sparc/kernel/uprobes.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/sparc/kernel/uprobes.c b/arch/sparc/kernel/uprobes.c index d852ae5..c44bf5b 100644 --- a/arch/sparc/kernel/uprobes.c +++ b/arch/sparc/kernel/uprobes.c @@ -29,7 +29,6 @@ #include #include -#include /* Compute the address of the breakpoint instruction and return it. *
[PATCH v2] openvswitch: fix flow actions reallocation
The flow action buffer can be resized if it's not big enough to contain
all the requested flow actions. However, this resize doesn't take into
account the new requested size, the buffer is only increased by a factor
of 2x. This might be not enough to contain the new data, causing a
buffer overflow, for example:
[ 42.044472]
=
[ 42.045608] BUG kmalloc-96 (Not tainted): Redzone overwritten
[ 42.046415]
-
[ 42.047715] Disabling lock debugging due to kernel taint
[ 42.047716] INFO: 0x8bf2c4a5-0x720c0928. First byte 0x0 instead of 0xcc
[ 42.048677] INFO: Slab 0xbc6d2040 objects=29 used=18 fp=0xdc07dec4
flags=0x2808101
[ 42.049743] INFO: Object 0xd53a3464 @offset=2528 fp=0xccdcdebb
[ 42.050747] Redzone 76f1b237: cc cc cc cc cc cc cc cc
[ 42.051839] Object d53a3464: 6b 6b 6b 6b 6b 6b 6b 6b 0c 00 00 00 6c 00 00 00
l...
[ 42.053015] Object f49a30cc: 6c 00 0c 00 00 00 00 00 00 00 00 03 78 a3 15 f6
l...x...
[ 42.054203] Object acfe4220: 20 00 02 00 ff ff ff ff 00 00 00 00 00 00 00 00
...
[ 42.055370] Object 21024e91: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 42.056541] Object 070e04c3: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 42.057797] Object 948a777a: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 42.059061] Redzone 8bf2c4a5: 00 00 00 00
[ 42.060189] Padding a681b46e: 5a 5a 5a 5a 5a 5a 5a 5a
Fix by making sure the new buffer is properly resized to contain all the
requested data.
BugLink: https://bugs.launchpad.net/bugs/1813244
Signed-off-by: Andrea Righi
---
Changes in v2:
- correctly resize to current_size+req_size (thanks to Pravin)
net/openvswitch/flow_netlink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 691da853bef5..4bdf5e3ac208 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -2306,14 +2306,14 @@ static struct nlattr *reserve_sfa_size(struct
sw_flow_actions **sfa,
struct sw_flow_actions *acts;
int new_acts_size;
- int req_size = NLA_ALIGN(attr_len);
+ size_t req_size = NLA_ALIGN(attr_len);
int next_offset = offsetof(struct sw_flow_actions, actions) +
(*sfa)->actions_len;
if (req_size <= (ksize(*sfa) - next_offset))
goto out;
- new_acts_size = ksize(*sfa) * 2;
+ new_acts_size = max(next_offset + req_size, ksize(*sfa) * 2);
if (new_acts_size > MAX_ACTIONS_BUFSIZE) {
if ((MAX_ACTIONS_BUFSIZE - next_offset) < req_size) {
--
2.19.1
Re: [PATCH] arch:sh:mach-sh03/rtc.c : Remove duplicate header
On 3/28/2019 2:50 AM, jagdsh.li...@gmail.com wrote: From: Jagadeesh Pagadala Remove duplicate header which is included twice. Signed-off-by: Jagadeesh Pagadala Reviewed-by: Mukesh Ojha -Mukesh --- arch/sh/boards/mach-sh03/rtc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/sh/boards/mach-sh03/rtc.c b/arch/sh/boards/mach-sh03/rtc.c index 8b23ed7..165e2cc 100644 --- a/arch/sh/boards/mach-sh03/rtc.c +++ b/arch/sh/boards/mach-sh03/rtc.c @@ -14,7 +14,6 @@ #include #include #include -#include #include #define RTC_BASE 0xb000
Re: [PATCH] arm:mm/mmu.c : Remove duplicate header
On 3/23/2019 5:04 PM, jagdsh.li...@gmail.com wrote: From: Jagadeesh Pagadala Remove duplicate headers which are included twice. Signed-off-by: Jagadeesh Pagadala Reviewed-by: Mukesh Ojha -Mukesh --- arch/arm/mm/mmu.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c index f3ce341..a7863a5 100644 --- a/arch/arm/mm/mmu.c +++ b/arch/arm/mm/mmu.c @@ -23,7 +23,6 @@ #include #include #include -#include #include #include #include @@ -36,7 +35,6 @@ #include #include #include -#include #include "fault.h" #include "mm.h"
Re: Issues with i.MX SPI DMA transfers
Hello Igor, On Wed, Mar 27, 2019 at 08:40:00PM +0300, Igor Plyatov wrote: > please, help to resolve two issues with SPI DMA transfers at i.MX6Q > platform. > > First issue is > [ 4465.008003] spi_master spi0: I/O Error in DMA RX > > Second issue is duplication for one of received bytes. > > Probably, these issues related to each one. This is probably the same problem I hit some time ago. Check ERR009165 in the errata. You either need to disable DMA or need a fixed sdma-Script. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH v7 2/2] drivers/misc: Add Aspeed P2A control driver
On Wed, Mar 27, 2019 at 12:01:50PM -0700, Patrick Venture wrote:
> On Wed, Mar 27, 2019 at 11:54 AM Greg KH wrote:
> >
> > On Wed, Mar 27, 2019 at 11:44:36AM -0700, Patrick Venture wrote:
> > > On Wed, Mar 27, 2019 at 11:28 AM Greg KH
> > > wrote:
> > > >
> > > > On Tue, Mar 12, 2019 at 09:31:01AM -0700, Patrick Venture wrote:
> > > > > + phys_addr_t mem_base;
> > > >
> > > > Is this really a 32bit value?
> > >
> > > It's going to be a 32-bit value if this is in the dts for one of the
> > > correspondingly supported aspeed models.
> > >
> > > >
> > > > Your ioctl thinks it is:
> > > >
> > > > > +struct aspeed_p2a_ctrl_mapping {
> > > > > + __u32 addr;
> > > >
> > > > Does this driver not work on a 64bit kernel?
> > >
> > > This driver is aimed at only 32-bit hardware (ast2400/2500). I
> > > modeled the approach after the aspeed-lpc-ctrl driver as it's
> > > providing similar functionality.
> > >
> > > >
> > > > > + __u32 length;
> > > > > + __u32 flags;
> > > > > +};
> > > >
> > > > addr really should be __u32 here so you don't have to mess with 32/64
> > > > bit user/kernel issues, right?
> > >
> > > Add is __u32 there. Are you suggesting it shouldn't be?
> >
> > Ugh, yes, sorry, I meant to say "__u64".
> >
> > If you all insist that this is all that is ever going to be needed, ok,
> > but I reserve the right to complain in 4 years when this needs to be
> > changed :)
>
> In the event the ast2600 comes out and is 64-bit -- I can't imagine
> that's likely to happen. I can take solace that this won't be the
> only thing that needs retrofitting. But it wouldn't kill me to just
> make the change. I'll just have to tweak it to return failure in the
> event the address provided isn't found in any region...
>
> Is that all that needs to change for 64-bit addressing support - given
> your read of the driver?
That's all that I noticed at first glance, yes. I do dislike having
custom user/kernel apis for random chips like this, but I don't know of
a way to have a generic api for them at the moment as I really do not
know what these chips do :(
One would think that the firmware api would work for you, but given the
complexity here, it does not seem that it would match up.
thanks,
greg k-h
Re: [git pull v2] habanalabs fixes for 5.1-rc3
On Thu, Mar 28, 2019 at 8:29 AM Greg KH wrote: > > On Thu, Mar 28, 2019 at 08:09:13AM +0200, Oded Gabbay wrote: > > On Wed, Mar 27, 2019 at 3:09 AM Greg KH wrote: > > > > > > On Tue, Mar 26, 2019 at 10:13:35AM +0200, Oded Gabbay wrote: > > > > Hi Greg, > > > > > > > > A couple of important fixes for habanalabs driver: > > > > > > > > - Fix host crash upon resume after suspend > > > > - Fix MMU related bugs which result in user's jobs getting stuck > > > > - Fix race between user context cleanup and hard-reset which results in > > > > host crash > > > > - Fix sparse warning > > > > > > Much better, thanks, now pulled and pushed out. > > > > > > greg k-h > > > > Hi Greg, > > In which branch do I see that ? I tried to find it in your char-misc > > repo but couldn't find it. > > It should be in the char-misc-linus branch of the char-misc.git repo on > git.kernel.org. Note, I was in the air for a long time yesterday, so > the emails probably went out 8 hours before I was able to push out the > git repo, but it should all be synced up now. Sorry for any confusion > there. > > greg k-h ah, ok. no problem, just wanted to make sure I'm looking at the right location. Oded
Re: [PATCH v2] arch_topology: Make cpu_capacity sysfs node as ready-only
Thanks for making the change suggested.
Should not this be v3.
Please add version detail properly including what changes you made in
which version after ---, that makes the patch easy to review.
Thanks.
Mukesh
On 3/28/2019 10:17 AM, Lingutla Chandrasekhar wrote:
If user updates any cpu's cpu_capacity, then the new value is going to
be applied to all its online sibling cpus. But this need not to be correct
always, as sibling cpus (in ARM, same micro architecture cpus) would have
different cpu_capacity with different performance characteristics.
So, updating the user supplied cpu_capacity to all cpu siblings
is not correct.
And another problem is, current code assumes that 'all cpus in a cluster
or with same package_id (core_siblings), would have same cpu_capacity'.
But with commit '5bdd2b3f0f8 ("arm64: topology: add support to remove
cpu topology sibling masks")', when a cpu hotplugged out, the cpu
information gets cleared in its sibling cpus. So, user supplied
cpu_capacity would be applied to only online sibling cpus at the time.
After that, if any cpu hotplugged in, it would have different cpu_capacity
than its siblings, which breaks the above assumption.
So, instead of mucking around the core sibling mask for user supplied
value, use device-tree to set cpu capacity. And make the cpu_capacity
node as read-only to know the asymmetry between cpus in the system.
While at it, remove cpu_scale_mutex usage, which used for sysfs write
protection.
Tested-by: Dietmar Eggemann
Tested-by: Quentin Perret
Reviewed-by: Quentin Perret
Acked-by: Sudeep Holla
Signed-off-by: Lingutla Chandrasekhar
diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
index edfcf8d982e4..1739d7e1952a 100644
--- a/drivers/base/arch_topology.c
+++ b/drivers/base/arch_topology.c
@@ -7,7 +7,6 @@
*/
#include
-#include
#include
#include
#include
@@ -31,7 +30,6 @@ void arch_set_freq_scale(struct cpumask *cpus, unsigned long
cur_freq,
per_cpu(freq_scale, i) = scale;
}
-static DEFINE_MUTEX(cpu_scale_mutex);
DEFINE_PER_CPU(unsigned long, cpu_scale) = SCHED_CAPACITY_SCALE;
void topology_set_cpu_scale(unsigned int cpu, unsigned long capacity)
@@ -51,37 +49,7 @@ static ssize_t cpu_capacity_show(struct device *dev,
static void update_topology_flags_workfn(struct work_struct *work);
static DECLARE_WORK(update_topology_flags_work, update_topology_flags_workfn);
-static ssize_t cpu_capacity_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf,
- size_t count)
-{
- struct cpu *cpu = container_of(dev, struct cpu, dev);
- int this_cpu = cpu->dev.id;
- int i;
- unsigned long new_capacity;
- ssize_t ret;
-
- if (!count)
- return 0;
-
- ret = kstrtoul(buf, 0, _capacity);
- if (ret)
- return ret;
- if (new_capacity > SCHED_CAPACITY_SCALE)
- return -EINVAL;
-
- mutex_lock(_scale_mutex);
- for_each_cpu(i, _topology[this_cpu].core_sibling)
- topology_set_cpu_scale(i, new_capacity);
- mutex_unlock(_scale_mutex);
-
- schedule_work(_topology_flags_work);
-
- return count;
-}
-
-static DEVICE_ATTR_RW(cpu_capacity);
+static DEVICE_ATTR_RO(cpu_capacity);
static int register_cpu_capacity_sysctl(void)
{
@@ -141,7 +109,6 @@ void topology_normalize_cpu_scale(void)
return;
pr_debug("cpu_capacity: capacity_scale=%u\n", capacity_scale);
- mutex_lock(_scale_mutex);
for_each_possible_cpu(cpu) {
pr_debug("cpu_capacity: cpu=%d raw_capacity=%u\n",
cpu, raw_capacity[cpu]);
@@ -151,7 +118,6 @@ void topology_normalize_cpu_scale(void)
pr_debug("cpu_capacity: CPU%d cpu_capacity=%lu\n",
cpu, topology_get_cpu_scale(NULL, cpu));
}
- mutex_unlock(_scale_mutex);
}
bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu)
Re: [RFC PATCH 0/10] Another Approach to Use PMEM as NUMA Node
On Wed 27-03-19 19:09:10, Yang Shi wrote: > One question, when doing demote and promote we need define a path, for > example, DRAM <-> PMEM (assume two tier memory). When determining what nodes > are "DRAM" nodes, does it make sense to assume the nodes with both cpu and > memory are DRAM nodes since PMEM nodes are typically cpuless nodes? Do we really have to special case this for PMEM? Why cannot we simply go in the zonelist order? In other words why cannot we use the same logic for a larger NUMA machine and instead of swapping simply fallback to a less contended NUMA node? It can be a regular DRAM, PMEM or whatever other type of memory node. -- Michal Hocko SUSE Labs
Re: Issues with i.MX SPI DMA transfers
Dear developers, I have update about these issues. 12 hours testing show very fast (some seconds) appearance of byte duplication at interface spi4 (alias for ecspi5), while interfaces spi0 (alias for ecspi1) and spi1 (alias for ecspi2) work flawless (at least without any other OS load). Looks like, ecspi5 has some different configuration in SPI or SDMA drivers or bug in SDMA script. Any ideas? Best wishes. -- Igor Plyatov
Re: [PATCH] MIPS: KGDB: fix kgdb support for SMP platforms.
On Wed, Mar 27, 2019 at 03:27:26PM -0700, Doug Anderson wrote: > Hi, > > On Wed, Mar 27, 2019 at 3:25 PM qiaochong wrote: > > > > > > My name is QiaoChong， which is same to my username. > > Qiao is my family name. > > Thanks a lot. > > I guess it will be up to whichever maintainer lands this (maybe > Daniel?) TBH this is mips specific so I'd expect this to get picked up by the mips arch maintainers. I'll send in an ack in a moment though. Daniel. > on whether they want you to spin it. I think folks expect to > see a real name that is capitalized and usually a space between the > family name and the given name. > > -Doug
Re: Issues with i.MX SPI DMA transfers
Dear Uwe, Hello Igor, On Wed, Mar 27, 2019 at 08:40:00PM +0300, Igor Plyatov wrote: please, help to resolve two issues with SPI DMA transfers at i.MX6Q platform. First issue is [ 4465.008003] spi_master spi0: I/O Error in DMA RX Second issue is duplication for one of received bytes. Probably, these issues related to each one. This is probably the same problem I hit some time ago. Check ERR009165 in the errata. You either need to disable DMA or need a fixed sdma-Script. disabling of DMA is not an option, because high throughput required for SPI bus to communicate with DSPs. I'm aware of ERR009165, but as I write some minutes earlier to list, spi0 (alias for ecspi1) and spi1 (alias for ecspi2) work flawless, while spi4 (alias for ecspi5) fails very fast. Does same SDMA script used for all SPI interfaces or scripts are different? Best wishes. -- Igor Plyatov
Re: [PATCH] MIPS: KGDB: fix kgdb support for SMP platforms.
On Thu, Mar 28, 2019 at 07:08:01AM +0800, Chong Qiao wrote:
> KGDB_call_nmi_hook is called by other cpu through smp call.
> MIPS smp call is processed in ipi irq handler and regs is saved in
> handle_int.
> So kgdb_call_nmi_hook get regs by get_irq_regs and regs will be passed
> to kgdb_cpu_enter.
>
> Signed-off-by: Chong Qiao
Acked-by: Daniel Thompson
> ---
> arch/mips/kernel/kgdb.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
> index 6e574c02e4c3b..ea781b29f7f17 100644
> --- a/arch/mips/kernel/kgdb.c
> +++ b/arch/mips/kernel/kgdb.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
>
> static struct hard_trap_info {
> unsigned char tt; /* Trap type code for MIPS R3xxx and R4xxx */
> @@ -214,7 +215,7 @@ void kgdb_call_nmi_hook(void *ignored)
> old_fs = get_fs();
> set_fs(KERNEL_DS);
>
> - kgdb_nmicallback(raw_smp_processor_id(), NULL);
> + kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
>
> set_fs(old_fs);
> }
> --
> 2.17.0
>
>
[PATCH] habanalabs: improve error messages
This patch improves two error messages to help the user to
better understand what error occurred.
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/command_submission.c | 3 ++-
drivers/misc/habanalabs/memory.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/habanalabs/command_submission.c
b/drivers/misc/habanalabs/command_submission.c
index f908643f871f..02c48da0b645 100644
--- a/drivers/misc/habanalabs/command_submission.c
+++ b/drivers/misc/habanalabs/command_submission.c
@@ -261,7 +261,8 @@ static void cs_timedout(struct work_struct *work)
ctx_asid = cs->ctx->asid;
/* TODO: add information about last signaled seq and last emitted seq */
- dev_err(hdev->dev, "CS %d.%llu got stuck!\n", ctx_asid, cs->sequence);
+ dev_err(hdev->dev, "User %d command submission %llu got stuck!\n",
+ ctx_asid, cs->sequence);
cs_put(cs);
diff --git a/drivers/misc/habanalabs/memory.c b/drivers/misc/habanalabs/memory.c
index ce1fda40a8b8..39788b1cf8d0 100644
--- a/drivers/misc/habanalabs/memory.c
+++ b/drivers/misc/habanalabs/memory.c
@@ -109,7 +109,7 @@ static int alloc_device_memory(struct hl_ctx *ctx, struct
hl_mem_in *args,
page_size);
if (!phys_pg_pack->pages[i]) {
dev_err(hdev->dev,
- "ioctl failed to allocate page\n");
+ "Failed to allocate device memory (out
of memory)\n");
rc = -ENOMEM;
goto page_err;
}
--
2.17.1
Re: [PATCH 4/6] x86, mm: make split_mem_range() more easy to read
On Sun, Mar 24, 2019 at 03:29:04PM +0100, Thomas Gleixner wrote:
>
>+static int __meminit split_mem_range(struct map_range *mr, unsigned long
>start,
>+ unsigned long end)
>+{
>+ static const struct mapinfo mapinfos[] = {
> #ifdef CONFIG_X86_64
>+ { .mask = 1U << PG_LEVEL_1G, .size = PUD_SIZE },
> #endif
>+ { .mask = 1U << PG_LEVEL_2M, .size = PMD_SIZE },
>+ { .mask = 0, .size = PAGE_SIZE },
>+ };
>+ const struct mapinfo *mi;
>+ struct map_range *curmr;
>+ unsigned long addr;
>+ int idx;
>+
>+ for (idx = 0, addr = start, curmr = mr; addr < end; idx++, curmr++) {
>+ BUG_ON(idx == NR_RANGE_MR);
>+ mr_setup(curmr, addr, end);
>
>+ /* Try map sizes top down. PAGE_SIZE will always succeed. */
>+ for (mi = mapinfos; !mr_try_map(curmr, mi); mi++);
>
>+ /* Get the start address for the next range */
>+ addr = curmr->end;
> }
I re-arrange the code to make split_mem_range() here easy to read.
My question is to the for loop.
For example, we have a range
+--+-+---+
^ 128M 1G 2G
128M - 4K
If my understanding is correct, the original behavior will split this into
three ranges:
4K size: [128M - 4K, 128M]
2M size: [128M, 1G]
1G size: [1G, 2G]
While after your change, it will split this into two ranges:
?? size: [128M - 4K, 1G]
2M size: [1G, 2G]
The question mark here is because you leave the page_size_mask unchanged in
this case.
Is my understanding correct? Or I missed something?
--
Wei Yang
Help you, Help me
RE: Issues with i.MX SPI DMA transfers
> -Original Message- > From: Igor Plyatov > Sent: 2019年3月28日 15:04 > To: Uwe Kleine-König > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-...@vger.kernel.org; dl-linux-imx ; Fabio Estevam > ; Pengutronix Kernel Team ; > Sascha Hauer ; Shawn Guo > ; Mark Brown ; > dmaeng...@vger.kernel.org; Vinod Koul ; Dan Williams > ; Andy Duan ; Han Xu > ; Robin Gong ; Clark Wang > > Subject: Re: Issues with i.MX SPI DMA transfers > > Dear Uwe, > > > > Hello Igor, > > > > On Wed, Mar 27, 2019 at 08:40:00PM +0300, Igor Plyatov wrote: > >> please, help to resolve two issues with SPI DMA transfers at i.MX6Q > >> platform. > >> > >> First issue is > >> [ 4465.008003] spi_master spi0: I/O Error in DMA RX > >> > >> Second issue is duplication for one of received bytes. > >> > >> Probably, these issues related to each one. > > This is probably the same problem I hit some time ago. Check ERR009165 > > in the errata. You either need to disable DMA or need a fixed > > sdma-Script. > > disabling of DMA is not an option, because high throughput required for SPI > bus > to communicate with DSPs. > > I'm aware of ERR009165, but as I write some minutes earlier to list, > spi0 (alias for ecspi1) and spi1 (alias for ecspi2) work flawless, while > spi4 (alias for ecspi5) fails very fast. > > Does same SDMA script used for all SPI interfaces or scripts are different? No different handle inside sdma script for different ecspi port. Agree Uwe, your duplicate data caught seems like ERR009165. Anyway I'll create ecspi patch for you to try in these days. > > Best wishes. > > -- > > Igor Plyatov
Re: [PATCH] x86/asm: add __user on copy_user_handle_tail() pointers
On Thu, Feb 28, 2019 at 06:50:27PM +, Ben Dooks wrote:
> The copy_user_handle_tail() clearly uses both from and to as pointers
> to user-space memory. This triggers sparse warning on using the calls
> to get and put to user-space. This can be fixed easily by changing the
> call to take __user annotated pointer.s
Well, but copy_user_generic() (which ends up calling the
copy_user_handle_tail() eventually) casts those __user pointers to
(__force void *). Converting them back to __user looks strange to me.
Linus?
Leaving in the rest for reference.
> arch/x86/lib/usercopy_64.c:68:21: warning: incorrect type in argument 1
> (different address spaces)
> arch/x86/lib/usercopy_64.c:68:21:expected void const volatile [noderef]
> *
> arch/x86/lib/usercopy_64.c:68:21:got char *
> arch/x86/lib/usercopy_64.c:70:21: warning: incorrect type in argument 1
> (different address spaces)
> arch/x86/lib/usercopy_64.c:70:21:expected void const volatile [noderef]
> *
> arch/x86/lib/usercopy_64.c:70:21:got char *to
>
> Signed-off-by: Ben Dooks
> ---
> arch/x86/include/asm/uaccess_64.h | 2 +-
> arch/x86/lib/usercopy_64.c| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/uaccess_64.h
> b/arch/x86/include/asm/uaccess_64.h
> index a9d637bc301d..cbca2cb28939 100644
> --- a/arch/x86/include/asm/uaccess_64.h
> +++ b/arch/x86/include/asm/uaccess_64.h
> @@ -208,7 +208,7 @@ __copy_from_user_flushcache(void *dst, const void __user
> *src, unsigned size)
> }
>
> unsigned long
> -copy_user_handle_tail(char *to, char *from, unsigned len);
> +copy_user_handle_tail(char __user *to, char __user *from, unsigned len);
>
> unsigned long
> mcsafe_handle_tail(char *to, char *from, unsigned len);
> diff --git a/arch/x86/lib/usercopy_64.c b/arch/x86/lib/usercopy_64.c
> index ee42bb0cbeb3..aa180424e77a 100644
> --- a/arch/x86/lib/usercopy_64.c
> +++ b/arch/x86/lib/usercopy_64.c
> @@ -60,7 +60,7 @@ EXPORT_SYMBOL(clear_user);
> * it is not necessary to optimize tail handling.
> */
> __visible unsigned long
> -copy_user_handle_tail(char *to, char *from, unsigned len)
> +copy_user_handle_tail(char __user *to, char __user *from, unsigned len)
> {
> for (; len; --len, to++) {
> char c;
> --
> 2.20.1
>
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v13 01/11] bitops: Introduce the for_each_set_clump8 macro
On Thu, Mar 28, 2019 at 01:30:13PM +0900, William Breathitt Gray wrote: > On Wed, Mar 27, 2019 at 07:42:54AM +0100, Lukas Wunner wrote: > > On Wed, Mar 27, 2019 at 01:58:45PM +0900, William Breathitt Gray wrote: > > > This macro iterates for each 8-bit group of bits (clump) with set bits, > > > within a bitmap memory region. For each iteration, "start" is set to the > > > bit offset of the found clump, while the respective clump value is > > > stored to the location pointed by "clump". Additionally, the > > > bitmap_get_value8 and bitmap_set_value8 functions are introduced to > > > respectively get and set an 8-bit value in a bitmap memory region. > > > > I would have preferred static inlines for bitmap_get_value8(), > > bitmap_set_value8() and find_next_clump8() to make this as fast > > as possible in the callers because I've personally worked with > > an industrial application where the GPIO pins of a 74x164 are > > written every 250 usec. > > I'm not sure these can be static inline since the symbols are exported > for use outside this file. By static inlines I meant that the functions are moved to the appropriate header file in include/linux/. You don't need to worry about exporting in that case as the code is local to each module. For smallish functions like these, static inlines are usually fine. See drivers/dma/virt-dma.h for an extreme case of static inlines (as compared to the much smaller virt-dma.c). Thanks, Lukas
RE: [RESEND] i2c: imx: defer probing on dma channel request
> From: laurentiu.tu...@nxp.com [mailto:laurentiu.tu...@nxp.com]
> Sent: Monday, March 25, 2019 11:30 PM
>
> From: Laurentiu Tudor
>
> If the dma controller is not yet probed, defer i2c probe.
> The error path in probe was slightly modified (no functional change) to avoid
> triggering this WARN_ON():
> "cg-pll0-div1 already disabled
> WARNING: CPU: 1 PID: 1 at drivers/clk/clk.c:828 clk_core_disable+0xa8/0xb0"
We may need more information to understand how this issue happens and it's also
better to put them in commit message to help review.
Regards
Dong Aisheng
>
> Signed-off-by: Laurentiu Tudor
> ---
> drivers/i2c/busses/i2c-imx.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c index
> 42fed40198a0..4e34b1572756 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -,7 +,8 @@ static int i2c_imx_probe(struct platform_device
> *pdev)
> pdev->name, i2c_imx);
> if (ret) {
> dev_err(>dev, "can't claim irq %d\n", irq);
> - goto clk_disable;
> + clk_disable_unprepare(i2c_imx->clk);
> + return ret;
> }
>
> /* Init queue */
> @@ -1161,19 +1162,25 @@ static int i2c_imx_probe(struct platform_device
> *pdev)
> pm_runtime_mark_last_busy(>dev);
> pm_runtime_put_autosuspend(>dev);
>
> + /* Init DMA config if supported */
> + ret = i2c_imx_dma_request(i2c_imx, phy_addr);
> + if (ret) {
> + if (ret != -EPROBE_DEFER)
> + dev_info(>dev, "can't use DMA, using PIO
> instead.\n");
> + else
> + goto del_adapter;
> + }
> +
> dev_dbg(_imx->adapter.dev, "claimed irq %d\n", irq);
> dev_dbg(_imx->adapter.dev, "device resources: %pR\n", res);
> dev_dbg(_imx->adapter.dev, "adapter name: \"%s\"\n",
> i2c_imx->adapter.name);
>
> - /* Init DMA config if supported */
> - ret = i2c_imx_dma_request(i2c_imx, phy_addr);
> - if (ret < 0)
> - goto clk_notifier_unregister;
> -
> dev_info(_imx->adapter.dev, "IMX I2C adapter registered\n");
> return 0; /* Return OK */
>
> +del_adapter:
> + i2c_del_adapter(_imx->adapter);
> clk_notifier_unregister:
> clk_notifier_unregister(i2c_imx->clk, _imx->clk_change_nb);
> rpm_disable:
> @@ -1182,8 +1189,6 @@ static int i2c_imx_probe(struct platform_device
> *pdev)
> pm_runtime_set_suspended(>dev);
> pm_runtime_dont_use_autosuspend(>dev);
>
> -clk_disable:
> - clk_disable_unprepare(i2c_imx->clk);
> return ret;
> }
>
> --
> 2.17.1
Page-allocation-failure
Hello , I am facing issue related to page allocation failure. If anyone is familiar with this issue, let me know what is the issue? How to solved/debug it. Failure logs -: - [ 45.073877] kswapd0: page allocation failure: order:0, mode:0x1080020(GFP_ATOMIC), nodemask=(null) [ 45.073897] CPU: 1 PID: 716 Comm: kswapd0 Tainted: P O4.14.65 #3 [ 45.073899] Hardware name: Android (Flattened Device Tree) [ 45.073901] Backtrace: [ 45.073915] [<8020dbec>] (dump_backtrace) from [<8020ded0>] (show_stack+0x18/0x1c) [ 45.073920] r6:600f0093 r5:8141bd5c r4: r3:3abdc664 [ 45.073928] [<8020deb8>] (show_stack) from [<80ba5e30>] (dump_stack+0x94/0xa8) [ 45.073936] [<80ba5d9c>] (dump_stack) from [<80350610>] (warn_alloc+0xe0/0x194) [ 45.073940] r6:80e090cc r5: r4:81216588 r3:3abdc664 [ 45.073946] [<80350534>] (warn_alloc) from [<803514e0>] (__alloc_pages_nodemask+0xd70/0x124c) [ 45.073949] r3: r2:80e090cc [ 45.073952] r6:0001 r5: r4:8121696c [ 45.073959] [<80350770>] (__alloc_pages_nodemask) from [<803a6c20>] (allocate_slab+0x364/0x3e4) [ 45.073964] r10:0080 r9: r8:01081220 r7: r6: r5:01080020 [ 45.073966] r4:bd00d180 [ 45.073971] [<803a68bc>] (allocate_slab) from [<803a8c98>] (___slab_alloc.constprop.6+0x420/0x4b8) [ 45.073977] r10: r9: r8:bd00d180 r7:01080020 r6:81216588 r5:be586360 [ 45.073978] r4: [ 45.073984] [<803a8878>] (___slab_alloc.constprop.6) from [<803a8d54>] (__slab_alloc.constprop.5+0x24/0x2c) [ 45.073989] r10:0004e299 r9:bd00d180 r8:01080020 r7:8147b954 r6:bd6e5a68 r5: [ 45.073991] r4:600f0093 [ 45.073996] [<803a8d30>] (__slab_alloc.constprop.5) from [<803a9058>] (kmem_cache_alloc+0x16c/0x2d0) [ 45.073999] r4:bd00d180 r3:be586360 --- Regards, Pankaj * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. *
Re: Page-allocation-failure
From: Pankaj Suryawanshi Sent: 28 March 2019 13:12 To: linux-kernel@vger.kernel.org; linux...@kvack.org Subject: Page-allocation-failure Hello , I am facing issue related to page allocation failure. If anyone is familiar with this issue, let me know what is the issue? How to solved/debug it. Failure logs -: - [ 45.073877] kswapd0: page allocation failure: order:0, mode:0x1080020(GFP_ATOMIC), nodemask=(null) [ 45.073897] CPU: 1 PID: 716 Comm: kswapd0 Tainted: P O4.14.65 #3 [ 45.073899] Hardware name: Android (Flattened Device Tree) [ 45.073901] Backtrace: [ 45.073915] [<8020dbec>] (dump_backtrace) from [<8020ded0>] (show_stack+0x18/0x1c) [ 45.073920] r6:600f0093 r5:8141bd5c r4: r3:3abdc664 [ 45.073928] [<8020deb8>] (show_stack) from [<80ba5e30>] (dump_stack+0x94/0xa8) [ 45.073936] [<80ba5d9c>] (dump_stack) from [<80350610>] (warn_alloc+0xe0/0x194) [ 45.073940] r6:80e090cc r5: r4:81216588 r3:3abdc664 [ 45.073946] [<80350534>] (warn_alloc) from [<803514e0>] (__alloc_pages_nodemask+0xd70/0x124c) [ 45.073949] r3: r2:80e090cc [ 45.073952] r6:0001 r5: r4:8121696c [ 45.073959] [<80350770>] (__alloc_pages_nodemask) from [<803a6c20>] (allocate_slab+0x364/0x3e4) [ 45.073964] r10:0080 r9: r8:01081220 r7: r6: r5:01080020 [ 45.073966] r4:bd00d180 [ 45.073971] [<803a68bc>] (allocate_slab) from [<803a8c98>] (___slab_alloc.constprop.6+0x420/0x4b8) [ 45.073977] r10: r9: r8:bd00d180 r7:01080020 r6:81216588 r5:be586360 [ 45.073978] r4: [ 45.073984] [<803a8878>] (___slab_alloc.constprop.6) from [<803a8d54>] (__slab_alloc.constprop.5+0x24/0x2c) [ 45.073989] r10:0004e299 r9:bd00d180 r8:01080020 r7:8147b954 r6:bd6e5a68 r5: [ 45.073991] r4:600f0093 [ 45.073996] [<803a8d30>] (__slab_alloc.constprop.5) from [<803a9058>] (kmem_cache_alloc+0x16c/0x2d0) [ 45.073999] r4:bd00d180 r3:be586360 --- [ 44.966861] Mem-Info: [ 44.966872] active_anon:106078 inactive_anon:142 isolated_anon:0 [ 44.966872] active_file:39117 inactive_file:34254 isolated_file:101 [ 44.966872] unevictable:597 dirty:157 writeback:0 unstable:0 [ 44.966872] slab_reclaimable:4967 slab_unreclaimable:9288 [ 44.966872] mapped:60971 shmem:185 pagetables:5905 bounce:0 [ 44.966872] free:2363 free_pcp:334 free_cma:0 [ 44.966879] Node 0 active_anon:424312kB inactive_anon:568kB active_file:156468kB inactive_file:137016kB unevictable:2388kB isolated(anon):0kB isolated(file):404kB mapped:243884kB dirty:628kB writeback:0kB shmem:740kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no [ 44.966889] DMA free:9348kB min:3772kB low:15684kB high:16624kB active_anon:420592kB inactive_anon:284kB active_file:155116kB inactive_file:135724kB unevictable:1592kB writepending:628kB present:928768kB managed:892508kB mlocked:1592kB kernel_stack:9304kB pagetables:23440kB bounce:0kB free_pcp:1336kB local_pcp:672kB free_cma:0kB [ 44.966890] lowmem_reserve[]: 0 0 8 8 [ 44.966903] HighMem free:104kB min:128kB low:236kB high:244kB active_anon:2632kB inactive_anon:284kB active_file:1912kB inactive_file:1732kB unevictable:796kB writepending:0kB present:1056768kB managed:8192kB mlocked:796kB kernel_stack:0kB pagetables:180kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [ 44.966904] lowmem_reserve[]: 0 0 0 0 [ 44.966909] DMA: 148*4kB (UMH) 52*8kB (UMH) 30*16kB (UMH) 19*32kB (MH) 7*64kB (MH) 4*128kB (H) 5*256kB (H) 0*512kB 0*1024kB 1*2048kB (H) 1*4096kB (H) 0*8192kB 0*16384kB = 10480kB [ 44.966936] HighMem: 2*4kB (UM) 2*8kB (UM) 1*16kB (U) 0*32kB 1*64kB (U) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 104kB [ 44.966958] 74134 total pagecache pages [ 44.966961] 0 pages in swap cache [ 44.966963] Swap cache stats: add 0, delete 0, find 0/0 [ 44.966965] Free swap = 0kB [ 44.966966] Total swap = 0kB [ 44.966967] 496384 pages RAM [ 44.966969] 264192 pages HighMem/MovableOnly [ 44.966972] 271209 pages reserved [ 44.966975] 262144 pages cma reserved Regards, Pankaj * eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby
RE: [PATCH] Input: elan_i2c - Add i2c_reset in sysfs for ELAN touchpad recovery
Hi Dmitry,
-Original Message-
From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
Sent: Wednesday, March 27, 2019 12:34 PM
To: KT Liao
Cc: linux-kernel@vger.kernel.org; linux-in...@vger.kernel.org;
ulrik.debie...@e2big.org; roger.whitta...@suse.com
Subject: Re: [PATCH] Input: elan_i2c - Add i2c_reset in sysfs for ELAN
touchpad recovery
Hi KT,
On Sat, Feb 02, 2019 at 03:54:56PM +0800, KT Liao wrote:
> Roger from SUSE reported the touchpad on Lenovo yoga2 crush sometimes.
> He found that rmmod/modprobe elan_i2c will recover the issue.
> He add the workaround on SUSE and solve the problem.
> Recently, the workaround fails in kernel 4.20 becasue IRQ mismatch.
> genirq: Flags mismatch irq 0. 2002 (ELAN0600:00) vs. 00015a00
> (timer) I can't reproduce the issue in SUSE with the same kernel.
> And it's a 5 years old laptop, ELAN can't find the module for testing.
> Instead of IRQ debugging IRQ, I tried another approach.
> I added i2c_reset in sysfs to avoid IRQ requesting in probe.
How will users discover this flag? I do not think this is the best approach.
Can we detect that the touchpad firmware crashed from the kernel and reset
automatically?
Agree your better idea.
I will modify the driver for Roger's testing.
Will upstream after his testing.
Thanks.
>
> Signed-off-by: KT Liao
> Acked-by: Roger Whittaker
> ---
> drivers/input/mouse/elan_i2c_core.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/input/mouse/elan_i2c_core.c
> b/drivers/input/mouse/elan_i2c_core.c
> index 2690a4b..388b1f0 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -670,6 +670,29 @@ static ssize_t calibrate_store(struct device *dev,
> return retval ?: count;
> }
>
> +static ssize_t i2c_reset_store(struct device *dev,
> +struct device_attribute *attr,
> +const char *buf, size_t count) {
> + struct i2c_client *client = to_i2c_client(dev);
> + struct elan_tp_data *data = i2c_get_clientdata(client);
> + int retval;
> +
> + retval = mutex_lock_interruptible(>sysfs_mutex);
> + if (retval)
> + return retval;
> +
> + disable_irq(client->irq);
> +
> + retval = elan_initialize(data);
> + if (retval)
> + dev_err(dev, "failed to re-initialize touchpad: %d\n",
retval);
> +
> + enable_irq(client->irq);
> + mutex_unlock(>sysfs_mutex);
> + return retval ?: count;
> +}
> +
> static ssize_t elan_sysfs_read_mode(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> @@ -702,6 +725,7 @@ static DEVICE_ATTR(mode, S_IRUGO,
> elan_sysfs_read_mode, NULL); static DEVICE_ATTR(update_fw, S_IWUSR,
> NULL, elan_sysfs_update_fw);
>
> static DEVICE_ATTR_WO(calibrate);
> +static DEVICE_ATTR_WO(i2c_reset);
>
> static struct attribute *elan_sysfs_entries[] = {
> _attr_product_id.attr,
> @@ -710,6 +734,7 @@ static struct attribute *elan_sysfs_entries[] = {
> _attr_iap_version.attr,
> _attr_fw_checksum.attr,
> _attr_calibrate.attr,
> + _attr_i2c_reset.attr,
> _attr_mode.attr,
> _attr_update_fw.attr,
> NULL,
> --
> 2.7.4
>
--
Dmitry
[PATCH V2] misc: fastrpc: add checked value for dma_set_mask
There be should check return value from dma_set_mask to throw some info
if fail to set dma mask.
Detected by CoverityScan, CID# 1443983: Error handling issues (CHECKED_RETURN)
Fixes:f6f9279f2bf0 (misc: fastrpc: Add Qualcomm fastrpc basic driver model)
Signed-off-by: Bo YU
---
V2: rebase misc tree
---
drivers/misc/fastrpc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 39f832d27288..36d0d5c9cfba 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -1184,6 +1184,7 @@ static int fastrpc_cb_probe(struct platform_device *pdev)
struct fastrpc_session_ctx *sess;
struct device *dev = >dev;
int i, sessions = 0;
+ int rc;
cctx = dev_get_drvdata(dev->parent);
if (!cctx)
@@ -1213,7 +1214,11 @@ static int fastrpc_cb_probe(struct platform_device *pdev)
}
cctx->sesscount++;
spin_unlock(>lock);
- dma_set_mask(dev, DMA_BIT_MASK(32));
+ rc = dma_set_mask(dev, DMA_BIT_MASK(32));
+ if (rc) {
+ dev_err(dev, "32-bit DMA enable failed\n");
+ return rc;
+ }
return 0;
}
--
2.11.0
Re: [PATCH 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v7)
On Wed, 27 Mar 2019 16:38:32 -0400 "Carlos O'Donell" wrote: > On 3/27/19 5:16 AM, Martin Schwidefsky wrote: > > On Mon, 25 Mar 2019 11:54:32 -0400 (EDT) > > Mathieu Desnoyers wrote: > > > +++ b/sysdeps/unix/sysv/linux/s390/bits/rseq.h > >> [...] > + > +/* Signature required before each abort handler code. */ > +#define RSEQ_SIG 0x53053053 > >>> > >>> Why not a s390 specific value here? > >> > >> s390 also has the abort handler in a __rseq_failure section: > >> > >> #define RSEQ_ASM_DEFINE_ABORT(label, teardown, abort_label) \ > >> ".pushsection __rseq_failure, \"ax\"\n\t" \ > >> ".long " __rseq_str(RSEQ_SIG) "\n\t"\ > >> __rseq_str(label) ":\n\t" \ > >> teardown\ > >> "j %l[" __rseq_str(abort_label) "]\n\t" \ > >> ".popsection\n\t" > >> > >> Same question applies as powerpc: since disassemblers will try to decode > >> that instruction, would it be better to define it as a valid one ? > >> > >> [...] > > > > A 4-byte sequence starting with 0x53 is decoded as a "diebr" instruction. > > And please replace that "j %l[...]" with a "jg %l[...]", the branch target > > range of the "j" instruction is 64K, not enough for the general case. > > Why was this particular operated selected? > > So on s390 the RSEQ_SIG will show up as an unexpected "divide to integer" > instruction that can't be reached by any control flow? > > Can we use a NOP with a unique value in an immediate operand? > > The goal being to have something that won't confuse during a debug > session, or that the debugger can ignore (like constant pools on Arm) I was looking at the wrong table in regard to opcode 0x53. The pattern 0x53.. is not a known instruction as far as the disassembler is concerned. As Mathieu pointed out "diebr" is actually 0xb353 Sorry about the confusion. But why do we need this value in the first place if it can not be reached? -- blue skies, Martin. "Reality continues to ruin my life." - Calvin.
URGENT,
Dear Friend, I came across your e-mail contact prior a private search while in need of your assistance. My name is Aisha Gaddafi a single Mother and a Widow with three Children. I am the only biological Daughter of late Libyan President (Late Colonel Muammar Gaddafi). I have an investment funds worth Twenty Seven Million Five Hundred Thousand United State Dollar ($27.500.000.00) and i need an investment Manager/Partner and because of the asylum status i will authorize you the ownership of the funds, however, I am interested in you for investment project assistance in your country, may be from there, we can build a business relationship in the near future. I am willing to negotiate investment/business profit sharing ratio with you base on the future investment earning profits. If you are willing to handle this project kindly reply urgent to enable me provide you more information about the investment funds. Your Urgent Reply Will Be Appreciated Please Reply me in my box. Best Regards Mrs Aisha Gaddafi
Re: [PATCH v7 0/9] EDAC drivers for Armada XP L2 and DDR
On Wed, Feb 27, 2019 at 08:05:45PM +, Chris Packham wrote: > Hi Borislav, Russell, > > This seems to have fallen off the radar. Is there anything stopping this > series from being merged? I was told this is not going through my tree and so I gave Reviewed-by's for the EDAC bits. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v3 4/4] RISC-V: Allow booting kernel from any 4KB aligned address
On Wed, Mar 27, 2019 at 12:54:41AM -0700, Christoph Hellwig wrote: > On Mon, Mar 25, 2019 at 09:46:59PM +0530, Anup Patel wrote: > > > Why do you even care about kernel mappings for non-existant ram. > > > > We care because there will always be some buggy kernel driver/code going > > out-of-bound and accessing non-existent RAM. If we by default map all > > possible kernel virtual address then behaviour of buggy accesses will be > > unpredictable. > > > > Further, I think we should also make .text and .rodata sections of kernel > > as read-only. This will protect kernel code and rodata. > > All of that is useful at the final_setup_vm() time - but none of it > matters during early setup_vm where life is complicated. > > Mike suggested on the previous iteration that you only do smaller > mappings when setting up the final mapping to avoid the ops churn, > and I fully agree with him. > > So I would suggest we avoid complicated the fiddly early boot changes > that just add complxity, and you instead redirect your efforts to > say implemented proper ro and non-executable sections using 4k mappings > in the final VM setup only. That should actuall lead to less code > and complexity, and provide more benefits. It might be worth keeping trampoline_pg_dir if we are to split setup_vm(). Then setup_vm() will only initialize the trampoline_pg_dir and final_setup_vm() will setup the swapper_pg_dir and switch to it. Otherwise final_setup_vm() would need to update live mappings which might be fragile. -- Sincerely yours, Mike.
Re: [PATCH 1/2] regulator: as3722: Convert to use regulator_set/get_current_limit_regmap
On Wednesday 27 March 2019 06:59 AM, Axel Lin wrote: Use regulator_set/get_current_limit_regmap helpers to save some code. Signed-off-by: Axel Lin Acked-by: Laxman Dewangan
Re: [PATCH 2/2] regulator: as3722: Slightly improve readability
On Wednesday 27 March 2019 06:59 AM, Axel Lin wrote: Add a local variable *desc to avoid too many change lines due to over 80 characters. Signed-off-by: Axel Lin Acked-by: Laxman Dewangan
Re: [linux-sunxi] [PATCH 4/7] ARM: dts: sun8i: a83t: Add UART2 PB pins
On Wed, Mar 27, 2019 at 8:18 AM megous via linux-sunxi
wrote:
>
> From: Ondrej Jirman
>
> Add pin definitions for UART2 PB pins. These are used on TBS-A711
> tablet.
>
> Signed-off-by: Ondrej Jirman
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
> b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index e5c39eef1c29..921cfb30ab46 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -768,6 +768,11 @@
> pins = "PG8", "PG9";
> function = "uart1";
> };
> +
Please add "/omit-if-no-ref/" before the pin definitions.
See
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/dt-for-5.2=73b670023327a014688c2d5309a43604cd553f1e
for such an example. This is a new policy.
ChenYu
> + uart2_pb_pins: uart2-pb-pins {
> + pins = "PB0", "PB1";
> + function = "uart2";
> + };
> };
>
> timer@1c20c00 {
> --
> 2.21.0
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Re: [PATCH 4/6] x86, mm: make split_mem_range() more easy to read
Wei,
On Thu, 28 Mar 2019, Wei Yang wrote:
please trim your replies. It's annoying if one has to search the content in
the middle of a large useless quote.
> On Sun, Mar 24, 2019 at 03:29:04PM +0100, Thomas Gleixner wrote:
> >Wei,
> >-static int __meminit split_mem_range(struct map_range *mr, int nr_range,
> >- unsigned long start,
> >- unsigned long end)
> >-{
> >-unsigned long start_pfn, end_pfn, limit_pfn;
> >-unsigned long pfn;
> >-int i;
> >+if (!IS_ALIGNED(mr->end, mi->size)) {
> >+/* Try to fit as much as possible */
> >+len = round_down(mr->end - mr->start, mi->size);
> >+if (!len)
> >+return false;
> >+mr->end = mr->start + len;
> >+}
> >
> >-limit_pfn = PFN_DOWN(end);
> >+/* Store the effective page size mask */
> >+mr->page_size_mask = mi->mask;
>
> I don't get the point here. Why store the effective page size mask just for
> the "middle" range.
>
> The original behavior will set the "head" and "tail" range with a lower level
> page size mask.
What has this to do with the middle range? Nothing. This is the path where
the current map level (1g, 2m, 4k) is applied from mr->start to
mr->end. That's the effective mapping of this map_range entry.
Thanks,
tglx
Re: [PATCH 4/6] x86, mm: make split_mem_range() more easy to read
On Thu, 28 Mar 2019, Wei Yang wrote: > On Sun, Mar 24, 2019 at 03:29:04PM +0100, Thomas Gleixner wrote: > My question is to the for loop. > > For example, we have a range > >+--+-+---+ >^ 128M 1G 2G >128M - 4K > > If my understanding is correct, the original behavior will split this into > three ranges: > >4K size: [128M - 4K, 128M] >2M size: [128M, 1G] >1G size: [1G, 2G] > > While after your change, it will split this into two ranges: > >?? size: [128M - 4K, 1G] >2M size: [1G, 2G] > > The question mark here is because you leave the page_size_mask unchanged in > this case. > > Is my understanding correct? Or I missed something? Yes. You misread mr_try_map(). Thanks, tglx
Re: [PATCH v4 2/2] mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
On 27/03/19 1:47 PM, Faiz Abbas wrote:
> Hi Adrian,
>
> On 27/03/19 4:45 PM, Adrian Hunter wrote:
>> On 26/03/19 1:00 PM, Faiz Abbas wrote:
>>> commit 5b0d62108b46 ("mmc: sdhci-omap: Add platform specific reset
>>> callback") skips data resets during tuning operation. Because of this,
>>> a data error or data finish interrupt might still arrive after a command
>>> error has been handled and the mrq ended. This ends up with a "mmc0: Got
>>> data interrupt 0x0002 even though no data operation was in progress"
>>> error message.
>>>
>>> Fix this by adding a platform specific callback for sdhci_irq. Mark the
>>> mrq as a failure but wait for a data interrupt instead of calling
>>> finish_mrq().
>>>
>>> Signed-off-by: Faiz Abbas
>>> ---
>>> drivers/mmc/host/sdhci-omap.c | 37 +++
>>> 1 file changed, 37 insertions(+)
>>>
>>> diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
>>> index 5bbed477c9b1..9da2ff9ede8b 100644
>>> --- a/drivers/mmc/host/sdhci-omap.c
>>> +++ b/drivers/mmc/host/sdhci-omap.c
>>> @@ -797,6 +797,42 @@ void sdhci_omap_reset(struct sdhci_host *host, u8 mask)
>>> sdhci_reset(host, mask);
>>> }
>>>
>>> +#define CMD_ERR_MASK (SDHCI_INT_CRC | SDHCI_INT_END_BIT | SDHCI_INT_INDEX
>>> |\
>>> + SDHCI_INT_TIMEOUT)
>>> +#define CMD_MASK (CMD_ERR_MASK | SDHCI_INT_RESPONSE)
>>> +
>>> +static irqreturn_t sdhci_omap_irq(struct sdhci_host *host, u32 intmask)
>>> +{
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host);
>>> +
>>> + if (omap_host->is_tuning && (intmask & CMD_ERR_MASK)) {
>>> +
>>> + /*
>>> +* Since we are not resetting data lines during tuning
>>> +* operation, data error or data complete interrupts
>>> +* might still arrive. Mark this request as a failure
>>> +* but still wait for the data interrupt
>>> +*/
>>> + if (intmask & SDHCI_INT_TIMEOUT)
>>> + host->cmd->error = -ETIMEDOUT;
>>> + else
>>> + host->cmd->error = -EILSEQ;
>>> +
>>> + sdhci_finish_command(host);
>>
>> Would it be possible to set SDHCI_INT_RESPONSE instead of calling
>> sdhci_finish_command() directly?
>>
>
> It should be possible. But what we are trying to do won't be very clear
> from the code. Ideally an interrupt handler should not set any interrupt
> bits, just handle and clear them. Also, setting the RESPONSE bit even
> when there has been no response seems wrong and makes the code more
> convoluted.
Well, I am not in favour of exporting sdhci_finish_command().
So I had a look and it is not obvious why you need to call it.
What about something this:
if (omap_host->is_tuning && host->cmd && !host->data_early &&
(intmask & CMD_ERR_MASK)) {
if (intmask & SDHCI_INT_TIMEOUT)
host->cmd->error = -ETIMEDOUT;
else
host->cmd->error = -EILSEQ;
host->cmd = NULL;
sdhci_writel(host, intmask & CMD_MASK, SDHCI_INT_STATUS);
intmask &= ~CMD_MASK;
}
Re: [RFC PATCH 0/10] Another Approach to Use PMEM as NUMA Node
On Wed, Mar 27, 2019 at 7:09 PM Yang Shi wrote: > On 3/27/19 1:09 PM, Michal Hocko wrote: > > On Wed 27-03-19 11:59:28, Yang Shi wrote: > >> > >> On 3/27/19 10:34 AM, Dan Williams wrote: > >>> On Wed, Mar 27, 2019 at 2:01 AM Michal Hocko wrote: > On Tue 26-03-19 19:58:56, Yang Shi wrote: > > [...] > > It is still NUMA, users still can see all the NUMA nodes. > No, Linux NUMA implementation makes all numa nodes available by default > and provides an API to opt-in for more fine tuning. What you are > suggesting goes against that semantic and I am asking why. How is pmem > NUMA node any different from any any other distant node in principle? > >>> Agree. It's just another NUMA node and shouldn't be special cased. > >>> Userspace policy can choose to avoid it, but typical node distance > >>> preference should otherwise let the kernel fall back to it as > >>> additional memory pressure relief for "near" memory. > >> In ideal case, yes, I agree. However, in real life world the performance is > >> a concern. It is well-known that PMEM (not considering NVDIMM-F or HBM) has > >> higher latency and lower bandwidth. We observed much higher latency on PMEM > >> than DRAM with multi threads. > > One rule of thumb is: Do not design user visible interfaces based on the > > contemporary technology and its up/down sides. This will almost always > > fire back. > > Thanks. It does make sense to me. > > > > > Btw. if you keep arguing about performance without any numbers. Can you > > present something specific? > > Yes, I did have some numbers. We did simple memory sequential rw latency > test with a designed-in-house test program on PMEM (bind to PMEM) and > DRAM (bind to DRAM). When running with 20 threads the result is as below: > > Threads w/latr/lat > PMEM 20537.15 68.06 > DRAM 2014.19 6.47 > > And, sysbench test with command: sysbench --time=600 memory > --memory-block-size=8G --memory-total-size=1024T --memory-scope=global > --memory-oper=read --memory-access-mode=rnd --rand-type=gaussian > --rand-pareto-h=0.1 --threads=1 run > > The result is: > lat/ms > PMEM 103766.09 > DRAM 31946.30 > > > > >> In real production environment we don't know what kind of applications > >> would > >> end up on PMEM (DRAM may be full, allocation fall back to PMEM) then have > >> unexpected performance degradation. I understand to have mempolicy to > >> choose > >> to avoid it. But, there might be hundreds or thousands of applications > >> running on the machine, it sounds not that feasible to me to have each > >> single application set mempolicy to avoid it. > > we have cpuset cgroup controller to help here. > > > >> So, I think we still need a default allocation node mask. The default value > >> may include all nodes or just DRAM nodes. But, they should be able to be > >> override by user globally, not only per process basis. > >> > >> Due to the performance disparity, currently our usecases treat PMEM as > >> second tier memory for demoting cold page or binding to not memory access > >> sensitive applications (this is the reason for inventing a new mempolicy) > >> although it is a NUMA node. > > If the performance sucks that badly then do not use the pmem as NUMA, > > really. There are certainly other ways to export the pmem storage. Use > > it as a fast swap storage. Or try to work on a swap caching mechanism > > that still allows much faster access than a slow swap storage. But do > > not try to pretend to abuse the NUMA interface while you are breaking > > some of its long term established semantics. > > Yes, we are looking into using it as a fast swap storage too and perhaps > other usecases. > > Anyway, though nobody thought it makes sense to restrict default > allocation nodes, it sounds over-engineered. I'm going to drop it. > > One question, when doing demote and promote we need define a path, for > example, DRAM <-> PMEM (assume two tier memory). When determining what > nodes are "DRAM" nodes, does it make sense to assume the nodes with both > cpu and memory are DRAM nodes since PMEM nodes are typically cpuless nodes? For ACPI platforms the HMAT is effectively going to enforce "cpu-less" nodes for any memory range that has differentiated performance from the conventional memory pool, or differentiated performance for a specific initiator. So "memory-less == PMEM" is not a robust assumption. The plan is to use the HMAT to populate the default fallback order, but allow for an override if the HMAT information is missing or incorrect.
Re: INFO: rcu detected stall in __perf_sw_event
On Wed, Mar 27, 2019 at 12:28 AM Finn Thain wrote:
>
> On Tue, 26 Mar 2019, syzbot wrote:
>
> > syzbot has bisected this bug to:
> >
> > commit cf85d89562f39cc7ae73de54639f1915a9195b7a
> > Author: Finn Thain
> > Date: Fri May 25 07:34:36 2018 +
> >
> >m68k/mac: Enable PDMA for PowerBook 500 series
> >
>
> Looks like a false positive. But if you really are running syzkaller on a
> PowerBook 500, you'll want to check that you have an FPU, otherwise a CPU
> erratum will probably mess up your results.
Agree. I've included it into the big bisection analysis as "hard to
reproduce" case:
https://lkml.org/lkml/2019/3/27/788
> --
>
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1226cb8b20
> > start commit: b0314565 Merge tag 'for_linus' of git://git.kernel.org/pub..
> > git tree: upstream
> > final crash:https://syzkaller.appspot.com/x/report.txt?x=1126cb8b20
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1626cb8b20
> > kernel config: https://syzkaller.appspot.com/x/.config?x=8f00801d7b7c4fe6
> > dashboard link: https://syzkaller.appspot.com/bug?extid=a41ac89a0712acde0e84
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1707cd2f40
> >
> > Reported-by: syzbot+a41ac89a0712acde0...@syzkaller.appspotmail.com
> > Fixes: cf85d89562f3 ("m68k/mac: Enable PDMA for PowerBook 500 series")
> >
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/alpine.LNX.2.21.1903271021290.994%40nippy.intranet.
> For more options, visit https://groups.google.com/d/optout.
Re: Issues with i.MX SPI DMA transfers
On Thu, Mar 28, 2019 at 10:04:21AM +0300, Igor Plyatov wrote: > Dear Uwe, > > > > Hello Igor, > > > > On Wed, Mar 27, 2019 at 08:40:00PM +0300, Igor Plyatov wrote: > > > please, help to resolve two issues with SPI DMA transfers at i.MX6Q > > > platform. > > > > > > First issue is > > > [ 4465.008003] spi_master spi0: I/O Error in DMA RX > > > > > > Second issue is duplication for one of received bytes. > > > > > > Probably, these issues related to each one. > > This is probably the same problem I hit some time ago. Check ERR009165 > > in the errata. You either need to disable DMA or need a fixed > > sdma-Script. > > disabling of DMA is not an option, because high throughput required for SPI > bus to communicate with DSPs. Is this a theoretical reasoning, or is that backed by testing? People here on the list already said things like: The eCSPI appears to insert a 4 bit pause after each word in DMA mode, not done in PIO mode, which can make DMA transfers 50% slower than PIO. You might want to read the thread https://marc.info/?l=linux-spi=155191201208766=2 . > I'm aware of ERR009165, but as I write some minutes earlier to list, spi0 > (alias for ecspi1) and spi1 (alias for ecspi2) work flawless, while spi4 > (alias for ecspi5) fails very fast. As the issue is a timing race, it might depend on things like length of the SPI lines, load on the data lines and other electrical properties. So you might just be happy that spi0 and spi1 don't show the issue for you. Or you didn't apply the "right" work load yet. > Does same SDMA script used for all SPI interfaces or scripts are different? As answered already before: The same script is used for all interfaces. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: possible deadlock in acct_pin_kill
On Wed, Mar 27, 2019 at 8:16 AM Amir Goldstein wrote:
>
> On Wed, Mar 27, 2019 at 5:53 AM syzbot
> wrote:
> >
> > syzbot has bisected this bug to:
> >
> > commit e950564b97fd0f541b02eb207685d0746f5ecf29
> > Author: Miklos Szeredi
> > Date: Tue Jul 24 13:01:55 2018 +
> >
> > vfs: don't evict uninitialized inode
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1212314320
> > start commit: da5322e6 Merge tag 'selinux-pr-20181115' of git://git.kern..
> > git tree: upstream
> > final crash:https://syzkaller.appspot.com/x/report.txt?x=1112314320
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1612314320
> > kernel config: https://syzkaller.appspot.com/x/.config?x=d86f24333880b605
> > dashboard link: https://syzkaller.appspot.com/bug?extid=2a73a6ea9507b7112141
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1229853340
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17ff545d40
> >
> > Reported-by: syzbot+2a73a6ea9507b7112...@syzkaller.appspotmail.com
> > Fixes: e950564b97fd ("vfs: don't evict uninitialized inode")
> >
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
> The repro seems fine for catching the subject bug, but I can't get it
> to reproduce on my system. I have written a simpler reliable repro.
> Its in the commit message of the patch to test below:
>
> #syz test: https://github.com/amir73il/linux.git acct_pin_kill_deadlock
>
> I have been pinging Al about the fix above for a while, but no response:
>
> https://marc.info/?l=linux-fsdevel=155119096826039=2
I would ping it as well, but I can't find it in my inbox. Is it on LKML?
> However! the bisection did not lead the subject bug, it lead to another
> and IMO the bisected commit has nothing to do with the subject bug:
Agree. I've included it into the big bisection analysis as "inference
of other kernel bugs" case:
https://lkml.org/lkml/2019/3/27/788
> [ 95.294877] list_add double add: new=8801b47ebbd0,
> prev=8801b99ad438, next=8801b47ebbd0.
> [ 95.304706] [ cut here ]
> [ 95.309467] kernel BUG at lib/list_debug.c:31!
> [ 95.314361] invalid opcode: [#1] PREEMPT SMP KASAN
> [ 95.319735] CPU: 0 PID: 7172 Comm: syz-executor0 Not tainted 4.18.0-rc1+ #1
> [ 95.326823] Hardware name: Google Google Compute Engine/Google
> Compute Engine, BIOS Google 01/01/2011
> [ 95.336194] RIP: 0010:__list_add_valid+0xaa/0xb0
> [ 95.340942] Code: e8 eb a9 48 89 f7 48 89 75 e8 e8 91 9a 4c fe 48
> 8b 75 e8 eb bb 48 89 f2 48 89 d9 4c 89 e6 48 c7 c7 00 70 fd 87 e8 55
> ff f7 fd <0f> 0b 0f 1f 40 00 48 b8 00 00 00 00 00 fc ff df 55 48 89 e5
> 41 55
> [ 95.360083] RSP: 0018:8801b9407188 EFLAGS: 00010282
> [ 95.365438] RAX: 0058 RBX: 8801b47ebbd0 RCX:
>
> [ 95.372717] RDX: RSI: 87fd6dc0 RDI:
> 8a9fc860
> [ 95.380010] RBP: 8801b94071a0 R08: ed003b584f99 R09:
> ed003b584f98
> [ 95.387275] R10: ed003b584f98 R11: 8801dac27cc7 R12:
> 8801b47ebbd0
> [ 95.394536] R13: 8801b47ebbd0 R14: 8801b47eba48 R15:
> 8801b9407228
> [ 95.401813] FS: 7f81e0a32700() GS:8801dac0()
> knlGS:
> [ 95.410029] CS: 0010 DS: ES: CR0: 80050033
> [ 95.415910] CR2: 004cc248 CR3: 0001bf3dd000 CR4:
> 001406f0
> [ 95.423171] DR0: DR1: DR2:
>
> [ 95.430519] DR3: DR6: fffe0ff0 DR7:
> 0400
> [ 95.437781] Call Trace:
> [ 95.440363] ? _raw_spin_lock+0x35/0x40
> [ 95.444330] inode_sb_list_add+0xff/0x380
> [ 95.448470] ? evict_inodes+0x560/0x560
> [ 95.452448] ? kasan_check_write+0x14/0x20
> [ 95.456755] ? do_raw_spin_lock+0xc1/0x200
> [ 95.460984] inode_insert5+0x305/0x540
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/CAOQ4uxgUNDTWvFzFJR_OENBZ_hYtwLGHem_yUd406hr7f5QX%2Bg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
Re: [PATCH v2 1/7] x86/boot: Convert early_serial_base to unsigned long
On Tue, Mar 19, 2019 at 09:43:19PM +0300, Andy Shevchenko wrote:
> As a preparatory of adding flexible serial I/O accessors, convert
> early_serial_base to unsigned long to cover all possible bus addresses
> on the system.
>
> No functional change intended.
>
> Signed-off-by: Andy Shevchenko
> ---
> arch/x86/boot/boot.h| 2 +-
> arch/x86/boot/compressed/early_serial_console.c | 2 +-
> arch/x86/boot/compressed/misc.h | 4 ++--
> arch/x86/boot/early_serial_console.c| 6 +++---
> arch/x86/boot/tty.c | 2 +-
> 5 files changed, 8 insertions(+), 8 deletions(-)
...
> diff --git a/arch/x86/boot/early_serial_console.c
> b/arch/x86/boot/early_serial_console.c
> index 023bf1c3de8b..2b663beda582 100644
> --- a/arch/x86/boot/early_serial_console.c
> +++ b/arch/x86/boot/early_serial_console.c
> @@ -23,7 +23,7 @@
>
> #define DEFAULT_BAUD 9600
>
> -static void early_serial_init(int port, int baud)
> +static void early_serial_init(unsigned long port, int baud)
> {
> unsigned char c;
> unsigned divisor;
> @@ -48,7 +48,7 @@ static void parse_earlyprintk(void)
> int baud = DEFAULT_BAUD;
> char arg[32];
> int pos = 0;
> - int port = 0;
> + unsigned long port = 0;
>
> if (cmdline_find_option("earlyprintk", arg, sizeof(arg)) > 0) {
> char *e;
> @@ -118,7 +118,7 @@ static void parse_console_uart8250(void)
> {
> char optstr[64], *options;
> int baud = DEFAULT_BAUD;
> - int port = 0;
> + unsigned long port = 0;
Here and above:
Please sort function local variables declaration in a reverse christmas
tree order:
longest_variable_name;
shorter_var_name;
even_shorter;
i;
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] pinctrl: intel: save HOSTSW_OWN register over suspend/resume
On Wed, Mar 27, 2019 at 07:29:40PM +0200, Mika Westerberg wrote: > I wonder if it would be simpler to save it always and then upon resume > compare them and if changed, log this in dmesg and restore the saved > one. Actually I think better is to restore hostsw_own only for GPIOs that are already requested by us. The BIOS should have no business messing those anyway once they are owned by the GPIO driver.
Re: [PATCH v2] thunderbolt: property: fix a missing check of kzalloc
On Mon, Mar 25, 2019 at 03:23:08PM -0500, Kangjie Lu wrote: > No check is enforced for the return value of kzalloc, > which may lead to NULL-pointer dereference. > > The patch fixes this issue. > > Signed-off-by: Kangjie Lu > Reviewed-by: Mukesh Ojha Applied, thanks!
Re: [PATCH 1/2] mtd: maps: physmap: Store gpio_values correctly
On Thu, 28 Mar 2019 17:02:15 +1300
Chris Packham wrote:
> When the gpio-addr-flash.c driver was merged with physmap-core.c the
> code to store the current gpio_values was lost. This meant that once a
> gpio was asserted it was never de-asserted. Fix this by storing the
> current offset in gpio_values like the old driver used to.
>
> Fixes: commit ba32ce95cbd9 ("mtd: maps: Merge gpio-addr-flash.c into
> physmap-core.c")
You miss
Cc:
> Signed-off-by: Chris Packham
Reviewed-by: Boris Brezillon
> ---
> drivers/mtd/maps/physmap-core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mtd/maps/physmap-core.c b/drivers/mtd/maps/physmap-core.c
> index d9a3e4bebe5d..21b556afc305 100644
> --- a/drivers/mtd/maps/physmap-core.c
> +++ b/drivers/mtd/maps/physmap-core.c
> @@ -132,6 +132,8 @@ static void physmap_set_addr_gpios(struct
> physmap_flash_info *info,
>
> gpiod_set_value(info->gpios->desc[i], !!(BIT(i) & ofs));
> }
> +
> + info->gpio_values = ofs;
> }
>
> #define win_mask(order) (BIT(order) - 1)
Re: [PATCH v3] thunderbolt: Fix to check the return value of kmemdup
On Mon, Mar 25, 2019 at 04:25:22PM -0500, Aditya Pakki wrote: > uuid in add_switch is allocted via kmemdup which can fail. The patch > logs the error and cleans up the allocated memory for switch. > > Signed-off-by: Aditya Pakki Applied, thanks!
PRIVATE...
I have a business Proposal that will be of benefit to the both of us.Kindly contact me on mrmichealwu...@yahoo.com.hk should this be of interest to you.
Re: [PATCH] regulator: rc5t583: Get rid of struct rc5t583_regulator
On Wednesday 27 March 2019 05:24 PM, Axel Lin wrote: The struct rc5t583_regulator only has 2 members, the *rdev is no longer used because this driver is using devm_regulator_register now. After remove *rdev, only *reg_info left. We can use struct rc5t583_regulator_info directly, so remove struct rc5t583_regulator. Signed-off-by: Axel Lin Acked-by: Laxman Dewangan
Re: [PATCH v2 2/2] arm64: dts: imx8qxp: Add EDMA0/EDMA1 nodes
On Thu, Mar 28, 2019 at 4:32 AM Aisheng Dong wrote:
>
> > From: Daniel Baluta
> > Sent: Thursday, March 28, 2019 3:03 AM
> >
> > i.MX8QXP contains a total of 4 EDMA controllers of which two are primarily
> > for audio components and the other two are for non-audio periperhals.
> >
> > This patch adds the EDMA0/EDMA1 nodes used by audio peripherals.
> >
> > EDMA0 contains channels for:
> > * ASRC0
> > * ESAI0
> > * SPDIF0
> > * SAI0, SAI1, SAI2, SAI3
> >
> > EDMA1 contains channels for:
> > * ASRC1
> > * SAI4, SAI5
> >
> > See chapter Audio DMA Memory Maps (2.2.3) from i.MX8QXP RM [1]
> >
> > This patch is based on the dtsi file initially submitted by Teo Hall in
> > i.MX NXP
> > internal tree.
> >
> > [1] https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf
> >
> > Cc: Teo Hall
> > Signed-off-by: Daniel Baluta
> > ---
> > arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 72
> > ++
> > 1 file changed, 72 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > index 0cb939861a60..84c7c3eca1a1 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > @@ -182,6 +182,78 @@
> > #clock-cells = <1>;
> > };
> >
> > + edma0: dma-controller@591f {
> > + compatible = "fsl,imx8qxp-edma";
> > + reg = <0x5920 0x1>, /* asrc0 pair A input
> > req */
> > + <0x5921 0x1>, /* asrc0 pair B input
> > req */
> > + <0x5922 0x1>, /* asrc0 pair C input
> > req */
> > + <0x5923 0x1>, /* asrc0 pair A output
> > req */
> > + <0x5924 0x1>, /* asrc0 pair B output
> > req */
> > + <0x5925 0x1>, /* asrc0 pair C output
> > req */
> > + <0x5926 0x1>, /* esai0 rx */
> > + <0x5927 0x1>, /* esai0 tx */
> > + <0x5928 0x1>, /* spdif0 rx */
> > + <0x5929 0x1>, /* spdif0 tx */
> > + <0x592c 0x1>, /* sai0 rx */
> > + <0x592d 0x1>, /* sai0 tx */
> > + <0x592e 0x1>, /* sai1 rx */
> > + <0x592f 0x1>, /* sai1 tx */
> > + #dma-cells = <3>;
>
> In binding doc, it's 2.
> - #dma-cells : Must be <2>.
> The 1st cell specifies the DMAMUX(0 for DMAMUX0 and 1 for DMAMUX1).
> Specific request source can only be multiplexed by specific channels
> group called DMAMUX.
> The 2nd cell specifies the request source(slot) ID.
>
> Need update binding doc?
>
> > + shared-interrupt;
>
> Undocumented property?
>
> Checkpatch did not complain?
Thanks Aisheng for this comment. I think we might need to delay a little bit
this patch because (as pointed by Yibin) on i.MX8 QXP/QM we use
fsl-edma-v3 which *is not* yet upstream.
So, lets get back to adding the nodes after Yibin sends edma-v3 patches.
thanks,
Daniel.
Re: [PATCH] drivers/acpi: Clear status of an event before enabling it
On Thu, Mar 28, 2019 at 1:46 AM Furquan Shaikh wrote:
>
> On Wed, Mar 27, 2019 at 5:24 AM Rafael J. Wysocki wrote:
> >
> > On Thu, Mar 21, 2019 at 3:16 AM Furquan Shaikh wrote:
> > >
> > > On Wed, Mar 20, 2019 at 5:11 PM Rafael J. Wysocki
> > > wrote:
> > > >
> > > > On Wed, Mar 20, 2019 at 11:34 PM Furquan Shaikh
> > > > wrote:
> > > > >
> > > > > Commit 18996f2db918 ("ACPICA: Events: Stop unconditionally
> > > > > clearing ACPI IRQs during suspend/resume") was added to stop clearing
> > > > > of event status bits unconditionally on suspend and resume paths. This
> > > > > was done because of an issue
> > > > > reported (https://bugzilla.kernel.org/show_bug.cgi?id=196249) where
> > > > > lid status stays closed even on resume (which happens because event
> > > > > status bits are cleared unconditionally on resume). Though this change
> > > > > fixed the issue on suspend path, it introduced regressions on several
> > > > > resume paths.
> > > > >
> > > > > First regression was reported and fixed on S5 path by the following
> > > > > change: commit fa85015c0d95 ("ACPICA: Clear status of all events when
> > > > > entering S5"). Next regression was reported and fixed on all legacy
> > > > > sleep paths by the commit f317c7dc12b7 ("ACPICA: Clear status of all
> > > > > events when entering sleep states"). However, regression still exists
> > > > > on S0ix sleep path since it does not follow the legacy sleep path.
> > > >
> > > > What exactly is failing?
> > >
> > > Here is the failure scenario:
> > >
> > > 1. Consider the case of trackpad which acts as a wake source.
> > > 2. Since the pad is configured for SCI, GPE_STS gets set for that pad
> > > during normal interrupts as well (i.e. during probe at boot or when
> > > using the trackpad)
> >
> > I don't quite understand this.
> >
> > Is the same GPE used for signaling trackpad events in the system
> > working state and for wakeup?
>
> Yes. The same pad is being configured for interrupts (i.e. routed to
> APIC) during S0 as well as configured for GPE (i.e. routed for SCI) to
> cause wakes when in S0ix/S3. This pad is externally connected to
> trackpad interrupt line.
And the way the system is wired up causes the GPE status to be set
when it is enabled, I suppose?
So effectively, you need to disable the active-state IRQ, then clear
the GPE status and enable it for wakeup.
OK, I'll queue up the patch (and talk to the upstream ACPICA people
about taking it in there).
Thanks!
Re: KASAN: use-after-free Read in path_lookupat
On Wed 27-03-19 18:59:48, Al Viro wrote: > On Wed, Mar 27, 2019 at 05:58:31PM +0100, Jan Kara wrote: > > On Tue 26-03-19 04:15:10, Al Viro wrote: > > > On Mon, Mar 25, 2019 at 08:18:25PM -0700, Mark Fasheh wrote: > > > > > > > Hey Al, > > > > > > > > It's been a while since I've looked at that bit of code but it looks > > > > like > > > > Ocfs2 is syncing the inode to disk and disposing of it's memory > > > > representation (which would include the cluster locks held) so that > > > > other > > > > nodes get a chance to delete the potentially orphaned inode. In Ocfs2 we > > > > won't delete an inode if it exists in another nodes cache. > > > > > > Wait a sec - what's the reason for forcing that write_inode_now(); why > > > doesn't the normal mechanism work? I'm afraid I still don't get it - > > > we do wait for writeback in evict_inode(), or the local filesystems > > > wouldn't work. > > > > I'm just guessing here but they don't want an inode cached once its last > > dentry goes away (it makes cluster wide synchronization easier for them and > > they do play tricks with cluster lock on dentries). > > Sure, but that's as simple as "return 1 from ->drop_inode()". Right. > > There is some info in > > 513e2dae9422 "ocfs2: flush inode data to disk and free inode when i_count > > becomes zero" which adds this ocfs2_drop_inode() implementation. So when > > the last inode reference is dropped, they want to flush any dirty data to > > disk and evict the inode. But AFAICT they should be fine with flushing the > > inode from their ->evict_inode method. I_FREEING just stops the flusher > > thread from touching the inode but explicit writeback through > > write_inode_now(inode, 1) should go through just fine. > > Umm... Why is that write_inode_now() needed in either place? I agree that > moving it to ->evict_inode() ought to be safe, but what makes it necessary > in the first place? Put it another way, what dirties the data and/or > metadata without marking it dirty? Well, the inode & pages are marked dirty and they are dirty when we get to iput_final(). But if ->drop_inode() returns 1 (which normally happens only for unlinked files), we will not write out the inode in iput_final() and the dirty data just gets discarded in ->evict_inode(). OCFS2 doesn't want this so they have to write-out by hand. Honza -- Jan Kara SUSE Labs, CR
Re: [PATCH v3 2/4] lib/hexdump.c: factor out generic hexdump formatting for reuse.
On Wed, Mar 27, 2019 at 05:34:59PM -0700, Life is hard, and then you die wrote: > > On Wed, Mar 27, 2019 at 09:46:48AM +0200, Andy Shevchenko wrote: > > On Wed, Mar 27, 2019 at 3:49 AM Ronald Tschalär > > wrote: > > > > > > This introduces print_hex_dump_to_cb() which contains all the hexdump > > > formatting minus the actual printk() call, allowing an arbitrary print > > > function to be supplied instead. And print_hex_dump() is re-implemented > > > using print_hex_dump_to_cb(). > > > > > > This allows other hex-dump logging functions to be provided which call > > > printk() differently or even log the hexdump somewhere entirely > > > different. > > In any case, don't do it like this. smaller non-recursive printf() is > > better than one big receursive call. > > When it looks like an optimization, it's actually a regression. > > Not sure where you see recursion here - are you referring to the > callback approach? %pV is a recursive printf(). > Since dev_printk() ends up calling printk with a > dictionary as well as additional formatting, vs print_hex_dump()'s > stright use of printk, this seemed like the best way accommodate > various possible ways of logging the messages. But as per below I > guess this is moot. I recommend to read this: https://lwn.net/Articles/780556/ > > And yes, debugfs idea is not bad. > > So it seems like that is the consensus. As per my other response, I'll > do this then and leave the print_hex_dump() alone. > > > P.S. Also check %*ph specifier. -- With Best Regards, Andy Shevchenko
[GIT PULL] s390 patches for 5.1 #2
The following changes since commit 3717f613f48df0222311f974cf8a06c8a6c97bae: Merge branch 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2019-03-05 14:49:11 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux tags/s390-5.1-2 for you to fetch changes up to b6ffdf27f3d4f1e9af56effe6f86989170d71e95: s390/cpumf: Fix warning from check_processor_id (2019-03-28 09:28:42 +0100) s390 update with improvements and bug fixes for 5.1-rc2 - Fix early free of the channel program in vfio - On AP device removal make sure that all messages are flushed with the driver still attached that queued the message - Limit brk randomization to 32MB to reduce the chance that the heap of ld.so is placed after the main stack - Add a rolling average for the steal time of a CPU, this will be needed for KVM to decide when to do busy waiting - Fix a warning in the CPU-MF code - Add a notification handler for AP configuration change to react faster to new AP devices Cornelia Huck (1): vfio: ccw: only free cp on final interrupt Harald Freudenberger (1): s390/zcrypt: revisit ap device remove procedure Martin Schwidefsky (3): s390: limit brk randomization to 32MB s390/vtime: steal time exponential moving average Merge tag 'vfio-ccw-20190311' of git://git.kernel.org/.../kvms390/vfio-ccw into fixes Thomas Richter (1): s390/cpumf: Fix warning from check_processor_id Tony Krowiak (1): zcrypt: handle AP Info notification from CHSC SEI command arch/s390/include/asm/ap.h | 11 +++ arch/s390/include/asm/elf.h | 11 --- arch/s390/include/asm/lowcore.h | 61 ++-- arch/s390/kernel/perf_cpum_cf_diag.c | 19 +++ arch/s390/kernel/smp.c | 3 +- arch/s390/kernel/vtime.c | 19 ++- drivers/s390/cio/chsc.c | 13 drivers/s390/cio/vfio_ccw_drv.c | 8 +++-- drivers/s390/crypto/ap_bus.c | 19 ++- drivers/s390/crypto/ap_bus.h | 2 ++ drivers/s390/crypto/ap_queue.c | 26 --- drivers/s390/crypto/zcrypt_api.c | 30 +++--- 12 files changed, 154 insertions(+), 68 deletions(-)
Re: [PATCH] kbuild: do not overwrite .gitignore in output directory
On Thu, Mar 28, 2019 at 4:20 AM Andre Przywara wrote:
>
> On Tue, 26 Mar 2019 13:26:58 +0900
> Masahiro Yamada wrote:
>
> Masahiro,
>
> > Commit 3a51ff344204 ("kbuild: gitignore output directory") seemed to
> > bother people who version-control output directories.
>
> Thanks a lot for the patch, that works for me.
>
> > Andre Przywara says:
> > "Unfortunately this breaks my setup, because I keep a totally separate
> > git repository in my build directories to track (various versions of)
> > .config. So .gitignore there is carefully crafted to ignore most build
> > artefacts, but not .config, for instance."
> >
> > Link: https://lkml.org/lkml/2019/3/22/1819
> > Reported-by: Andre Przywara
> > Signed-off-by: Masahiro Yamada
>
> Tested-by: Andre Przywara
> Reviewed-by: Andre Przywara
Applied to linux-kbuild/fixes.
> Cheers,
> Andre.
>
> > ---
> >
> > Makefile | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 5fe5431..70fc778 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -499,7 +499,8 @@ outputmakefile:
> > ifneq ($(KBUILD_SRC),)
> > $(Q)ln -fsn $(srctree) source
> > $(Q)$(CONFIG_SHELL) $(srctree)/scripts/mkmakefile $(srctree)
> > - $(Q){ echo "# this is build directory, ignore it"; echo "*"; } >
> > .gitignore
> > + $(Q)test -e .gitignore || \
> > + { echo "# this is build directory, ignore it"; echo "*"; } >
> > .gitignore
> > endif
> >
> > ifneq ($(shell $(CC) --version 2>&1 | head -n 1 | grep clang),)
>
--
Best Regards
Masahiro Yamada
Re: [PATCH v2 1/7] x86/boot: Convert early_serial_base to unsigned long
On Thu, Mar 28, 2019 at 09:28:23AM +0100, Borislav Petkov wrote:
> On Tue, Mar 19, 2019 at 09:43:19PM +0300, Andy Shevchenko wrote:
> > As a preparatory of adding flexible serial I/O accessors, convert
> > early_serial_base to unsigned long to cover all possible bus addresses
> > on the system.
> > @@ -48,7 +48,7 @@ static void parse_earlyprintk(void)
> > int baud = DEFAULT_BAUD;
> > char arg[32];
> > int pos = 0;
> > - int port = 0;
> > + unsigned long port = 0;
> >
> > if (cmdline_find_option("earlyprintk", arg, sizeof(arg)) > 0) {
> > char *e;
> > @@ -118,7 +118,7 @@ static void parse_console_uart8250(void)
> > {
> > char optstr[64], *options;
> > int baud = DEFAULT_BAUD;
> > - int port = 0;
> > + unsigned long port = 0;
>
> Here and above:
Agree on above and will fix, but don't see how this different in the latter?
>
> Please sort function local variables declaration in a reverse christmas
> tree order:
>
>longest_variable_name;
>shorter_var_name;
>even_shorter;
>i;
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v13 10/11] gpio: 74x164: Utilize the for_each_set_clump8 macro
On Thu, Mar 28, 2019 at 01:40:04PM +0900, William Breathitt Gray wrote:
> On Wed, Mar 27, 2019 at 02:33:14PM +0200, Andy Shevchenko wrote:
> > On Wed, Mar 27, 2019 at 02:02:39PM +0900, William Breathitt Gray wrote:
> > > Replace verbose implementation in set_multiple callback with
> > > for_each_set_clump8 macro to simplify code and improve clarity.
> >
> > > + for_each_set_clump8(offset, bankmask, mask, chip->registers * 8) {
> >
> > > + bank = (chip->registers - 1) - (offset / 8);
> >
> > Excessive parens, but it's minor.
>
> Fair point, this could do without parens around (chip->registers - 1).
And around division too.
> Since this and renaming 'idx' to 'index' in find_bit.c are such a minor
> changes, I'll wait first to see if something else comes up to be fixed
> in this review. If so, I'll add these changes to the next version of
> this patchset.
It seems inline proposal would going to be implemented.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] pinctrl: intel: save HOSTSW_OWN register over suspend/resume
On Wed, Mar 27, 2019 at 07:29:40PM +0200, Mika Westerberg wrote: > On Wed, Mar 27, 2019 at 04:22:04PM +0800, Daniel Drake wrote: > > On Tue, Nov 21, 2017 at 8:13 PM Mika Westerberg > > wrote: > > > On Tue, Nov 21, 2017 at 07:54:26PM +0800, Chris Chiu wrote: > > > > Yup, I checked the value of the corresponded pin. It shows following > > > > before > > > > suspend > > > > pin 18 (GPIO_18) GPIO 0x40800102 0x00024075 > > > > > > > > Then after resume > > > > pin 18 (GPIO_18) GPIO 0x40800102 0x00024075 [ACPI] > > > > > > OK, so ownership is changed to ACPI. > > > > > > > What else register do you suggest me to compare? The PADCFG2 is invalid > > > > > > It's fine APL does not have PADCFG2. > > > > > > Hmm, I don't understand how this can work in Windows either. The Windows > > > people told me that they don't save and restore anything else than > > > padcfg registers + ie. If the ownership is changed to ACPI it means you > > > don't get interrupts anymore (only GPEs) and that applies to Windows as > > > well. > > > > In the mails after the one quoted above, we reported back to you that > > the new BIOS from Asus solved the issue. > > > > However, during the time that has followed, we have had numerous user > > reports from Asus E403NA, X540NA, and X541NA laptops (basically the > > same models that we originally discussed) where the touchpad stops > > working after suspend/resume, even with the latest BIOS. We managed to > > get an affected E403NA unit in-hands again, and confirmed that > > HOSTSW_OWN was being lost like we had observed before. Hmm... Can you confirm that laptop you declared as a fixed case and the mentioned here is the same one? If they are different, I have a theory that PCBs of those two are not the same and used GPIO pin can be also not the same, therefore the BIOS fixes only one revision of the model, but didn't consider the rest. If it's the case, I recommend to ping Asus again and make them check and fix. Meanwhile, Mika's proposal sounds feasible and not so intrusive. We may implement this later on. > > > > Unfortunately as this was a customer laptop we had to return it > > immediately, before we could investigate further. We don't have access > > to any more units since they are old models now. > > > > However I'm wondering if you have any other ideas or if you think > > something like our workaround patch might be acceptable under these > > circumstances: > > https://github.com/endlessm/linux/commit/f391452299f62a3d0cbe5333be90f69e9895d8ff > > I wonder if it would be simpler to save it always and then upon resume > compare them and if changed, log this in dmesg and restore the saved > one. -- With Best Regards, Andy Shevchenko
Re: pidfd design
On Mon, Mar 25, 2019 at 05:24:49PM -0700, Andy Lutomirski wrote:
> On Mon, Mar 25, 2019 at 5:12 PM Christian Brauner
> wrote:
> >
> > On Mon, Mar 25, 2019 at 05:00:17PM -0700, Andy Lutomirski wrote:
> > > On Mon, Mar 25, 2019 at 4:45 PM Christian Brauner
> > > wrote:
> > > >
> > > > On Mon, Mar 25, 2019 at 04:42:14PM -0700, Andy Lutomirski wrote:
> > > > > On Mon, Mar 25, 2019 at 1:23 PM Daniel Colascione
> > > > > wrote:
> > > > > >
> > > > > > On Mon, Mar 25, 2019 at 1:14 PM Jann Horn wrote:
> > > > > > >
> > > > > > > On Mon, Mar 25, 2019 at 8:44 PM Andy Lutomirski
> > > > > > > wrote:
> > > > >
> > > > > > > One ioctl on procfs roots to translate pidfds into that procfs,
> > > > > > > subject to both the normal lookup permission checks and only
> > > > > > > working
> > > > > > > if the pidfd has a translation into the procfs:
> > > > > > >
> > > > > > > int proc_root_fd = open("/proc", O_RDONLY);
> > > > > > > int proc_dir_fd = ioctl(proc_root_fd, PROC_PIDFD_TO_PROCFSFD,
> > > > > > > pidfd);
> > > > > > >
> > > > > > > And one ioctl on procfs directories to translate from PGIDs and
> > > > > > > PIDs to pidfds:
> > > > > > >
> > > > > > > int proc_pgid_fd = open("/proc/self", O_RDONLY);
> > > > > > > int self_pg_pidfd = ioctl(proc_pgid_fd, PROC_PROCFSFD_TO_PIDFD,
> > > > > > > 0);
> > > > > > > int proc_pid_fd = open("/proc/thread-self", O_RDONLY);
> > > > > > > int self_p_pidfd = ioctl(proc_pid_fd, PROC_PROCFSFD_TO_PIDFD, 0);
> > > > > > >
> > > > >
> > > > > This sounds okay to me. Or we could make it so that a procfs
> > > > > directory fd also works as a pidfd, but that seems more likely to be
> > > > > problematic than just allowing two-way translation like this
> > > > >
> > > > > > >
> > > > > > > And then, as you proposed, the new sys_clone() can just return a
> > > > > > > pidfd, and you can convert it into a procfs fd yourself if you
> > > > > > > want.
> > > > > >
> > > > > > I think that's the consensus we reached on the other thread. The
> > > > > > O_DIRECTORY open on /proc/self/fd/mypidfd seems like it'd work well
> > > > > > enough.
> > > > >
> > > > > I must have missed this particular email.
> > > > >
> > > > > IMO, if /proc/self/fd/mypidfd allows O_DIRECTORY open to work, then it
> > > > > really ought to do function just like /proc/self/fd/mypidfd/. and
> > > > > /proc/self/fd/mypidfd/status should work. And these latter two
> > > > > options seem nutty.
> > > > >
> > > > > Also, this O_DIRECTORY thing is missing the entire point of the ioctl
> > > > > interface -- it doesn't require procfs access.
> > > >
> > > > The other option was to encode the pid in the callers pid namespace into
> > > > the pidfd's fdinfo so that you can parse it out and open /proc/.
> > > > You'd just need an event on the pidfd to tell you when the process has
> > > > died. Jonathan and I just discussed this.
> > >
> > > From an application developer's POV, the ioctl interface sounds much,
> > > much nicer.
> >
> > Some people are strongly against ioctl()s some don't. I'm not against
> > them so both options are fine with me if people can agree.
> >
>
> There are certainly non-ioctl equivalents that are functionally
> equivalent. For example, there could be a syscall
> procfs_open_pidfd(procfs_fd, pid_fd). I personally don't really mind
> ioctl() when it's really an operation on an fd.
I totally missed that mail somehow.
Yes, I agree that an ioctl() makes sense for that.
[PATCH] drivers/fmc: remove unneeded NULL check
The variable will check in debugfs_remove_recursive, so
the NULL check here is not needed
Signed-off-by: Ding Xiang
---
drivers/fmc/fmc-debug.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/fmc/fmc-debug.c b/drivers/fmc/fmc-debug.c
index 3293072..ab868a3 100644
--- a/drivers/fmc/fmc-debug.c
+++ b/drivers/fmc/fmc-debug.c
@@ -168,6 +168,5 @@ int fmc_debug_init(struct fmc_device *fmc)
void fmc_debug_exit(struct fmc_device *fmc)
{
- if (fmc->dbg_dir)
- debugfs_remove_recursive(fmc->dbg_dir);
+ debugfs_remove_recursive(fmc->dbg_dir);
}
--
1.9.1
RE: Issues with i.MX SPI DMA transfers
Hi Igor, Please have a try with the attached patch, assume you have already used the sdma firmware From https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/imx/sdma/sdma-imx6q.bin > -Original Message- > From: Igor Plyatov > Sent: 2019年3月28日 15:04 > To: Uwe Kleine-König > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-...@vger.kernel.org; dl-linux-imx ; Fabio Estevam > ; Pengutronix Kernel Team ; > Sascha Hauer ; Shawn Guo > ; Mark Brown ; > dmaeng...@vger.kernel.org; Vinod Koul ; Dan Williams > ; Andy Duan ; Han Xu > ; Robin Gong ; Clark Wang > > Subject: Re: Issues with i.MX SPI DMA transfers > > Dear Uwe, > > > > Hello Igor, > > > > On Wed, Mar 27, 2019 at 08:40:00PM +0300, Igor Plyatov wrote: > >> please, help to resolve two issues with SPI DMA transfers at i.MX6Q > >> platform. > >> > >> First issue is > >> [ 4465.008003] spi_master spi0: I/O Error in DMA RX > >> > >> Second issue is duplication for one of received bytes. > >> > >> Probably, these issues related to each one. > > This is probably the same problem I hit some time ago. Check ERR009165 > > in the errata. You either need to disable DMA or need a fixed > > sdma-Script. > > disabling of DMA is not an option, because high throughput required for SPI > bus > to communicate with DSPs. > > I'm aware of ERR009165, but as I write some minutes earlier to list, > spi0 (alias for ecspi1) and spi1 (alias for ecspi2) work flawless, while > spi4 (alias for ecspi5) fails very fast. > > Does same SDMA script used for all SPI interfaces or scripts are different? > > Best wishes. > > -- > > Igor Plyatov 0001-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch Description: 0001-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch 0002-spi-spi-imx-fix-ERR009165.patch Description: 0002-spi-spi-imx-fix-ERR009165.patch
RE: [PATCH v2 2/2] arm64: dts: imx8qxp: Add EDMA0/EDMA1 nodes
> > > diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > > b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > > index 0cb939861a60..84c7c3eca1a1 100644
> > > --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > > @@ -182,6 +182,78 @@
> > > #clock-cells = <1>;
> > > };
> > >
> > > + edma0: dma-controller@591f {
> > > + compatible = "fsl,imx8qxp-edma";
> > > + reg = <0x5920 0x1>, /* asrc0 pair A
> input req */
> > > + <0x5921 0x1>, /* asrc0 pair B
> input req */
> > > + <0x5922 0x1>, /* asrc0 pair C
> input req */
> > > + <0x5923 0x1>, /* asrc0 pair A
> output req */
> > > + <0x5924 0x1>, /* asrc0 pair B
> output req */
> > > + <0x5925 0x1>, /* asrc0 pair C
> output req */
> > > + <0x5926 0x1>, /* esai0 rx */
> > > + <0x5927 0x1>, /* esai0 tx */
> > > + <0x5928 0x1>, /* spdif0 rx */
> > > + <0x5929 0x1>, /* spdif0 tx */
> > > + <0x592c 0x1>, /* sai0 rx */
> > > + <0x592d 0x1>, /* sai0 tx */
> > > + <0x592e 0x1>, /* sai1 rx */
> > > + <0x592f 0x1>, /* sai1 tx */
> > > + #dma-cells = <3>;
> >
> > In binding doc, it's 2.
> > - #dma-cells : Must be <2>.
> > The 1st cell specifies the DMAMUX(0 for DMAMUX0 and 1 for
> DMAMUX1).
> > Specific request source can only be multiplexed by specific
> channels
> > group called DMAMUX.
> > The 2nd cell specifies the request source(slot) ID.
> >
> > Need update binding doc?
> >
> > > + shared-interrupt;
> >
> > Undocumented property?
> >
> > Checkpatch did not complain?
>
> Thanks Aisheng for this comment. I think we might need to delay a little bit
> this patch because (as pointed by Yibin) on i.MX8 QXP/QM we use
> fsl-edma-v3 which *is not* yet upstream.
>
> So, lets get back to adding the nodes after Yibin sends edma-v3 patches.
>
Yes, Yibin could check the comments when resending with edma driver support.
Regards
Dong Aisheng
> thanks,
> Daniel.
Re: [PATCH v10 00/12] perf: enable compression of record mode trace to save storage space
Hi, This is a gentle reminder regarding the patch set below. Thanks, Alexey On 18.03.2019 20:36, Alexey Budankov wrote: > > The patch set implements runtime trace compression (-z option) in > record mode and trace auto decompression in report and inject modes. > Streaming Zstd API [1] is used for compression and decompression of > data that come from kernel mmaped data buffers. > > Usage of implemented -z,--compression_level=n option provides ~3-5x > avg. trace file size reduction on variety of tested workloads what > saves storage space on larger server systems where trace file size > can easily reach several tens or even hundreds of GiBs, especially > when profiling with dwarf-based stacks and tracing of context switches. > Default option value is 1 (fastest compression). > > Implemented --mmap-flush option can be used to specify minimal size > of data chunk that is extracted from mmaped kernel buffer to store > into a trace. The option is independent from -z setting and doesn't > vary with compression level. The default option value is 1 byte what > means every time trace writing thread finds some new data in the > mmaped buffer the data is extracted, possibly compressed and written > to a trace. The option serves two purposes the first one is to increase > the compression ratio of trace data and the second one is to avoid > live-lock self tool process monitoring in system wide (-a) profiling > mode. Profiling in system wide mode with compression (-a -z) can > additionally induce data into the kernel buffers along with the data > from monitored processes. If performance data rate and volume from > the monitored processes is high then trace streaming and compression > activity in the tool is also high. It can lead to subtle live-lock > effect of endless activity when compression of single new byte from > some of mmaped kernel buffer induces the next single byte at some > mmaped buffer. So perf tool thread never stops on polling event file > descriptors. Varying data chunk size to be extracted from mmap buffers > allows avoiding live-locking self monitoring in system wide mode and > makes mmap buffers polling loop manageable. Possible usage examples: > > $ tools/perf/perf record -z -e cycles -- matrix.gcc > $ tools/perf/perf record --aio -z -e cycles -- matrix.gcc > $ tools/perf/perf record -z --mmap-flush 1024 -e cycles -- matrix.gcc > $ tools/perf/perf record --aio -z --mmap-flush 1K -e cycles -- matrix.gcc > > Runtime compression overhead has been measured for serial and AIO > trace writing modes when profiling matrix multiplication workload: > > - > | SERIAL | AIO-1 | > |-|-| > |-z | OVH(x) | ratio(x) size(MiB) | OVH(x) | ratio(x) size(MiB) | > |---||||| > | 0 | 1,00 | 1,000179,424 | 1,00 | 1,000187,527 | > | 1 | 1,04 | 8,427181,148 | 1,01 | 8,474188,562 | > | 2 | 1,07 | 8,055186,953 | 1,03 | 7,912191,773 | > | 3 | 1,04 | 8,283181,908 | 1,03 | 8,220191,078 | > | 5 | 1,09 | 8,101187,705 | 1,05 | 7,780190,065 | > | 8 | 1,05 | 9,217179,191 | 1,12 | 6,111193,024 | > - > > OVH = (Execution time with -z N) / (Execution time with -z 0) > > ratio - compression ratio > size - number of bytes that was compressed > > size ~= trace file x ratio > > See complete description of measurement conditions with details below. > > Introduced compression functionality can be disabled or configured from > the command line using NO_LIBZSTD and LIBZSTD_DIR defines: > > $ make -C tools/perf NO_LIBZSTD=1 clean all > $ make -C tools/perf LIBZSTD_DIR=/path/to/zstd/sources/ clean all > > If your system has some version of the zstd package preinstalled then > the build system finds and uses it during the build. Auto detection > feature status is reported just before compilation starts, as usual. > If you still prefer to compile with some other version of zstd you have > capability to refer the compilation to that version using LIBZSTD_DIR > define. > > See 'perf test' results below for enabled and disabled (NO_LIBZSTD=1) > feature configurations. > > --- > Alexey Budankov (12): > feature: implement libzstd check, LIBZSTD_DIR and NO_LIBZSTD defines > perf record: implement --mmap-flush= option > perf session: define bytes_transferred and bytes_compressed metrics > perf record: implement COMPRESSED event record and its attributes > perf mmap: implement dedicated memory buffer for data compression > perf util: introduce Zstd streaming based compression API > perf record: implement compression for serial trace streaming > perf record: implement
Re: [PATCH] watchdog: Respect watchdog cpumask on CPU hotplug
On 3/27/19 8:10 PM, Thomas Gleixner wrote: On Wed, 27 Mar 2019, Oleg Nesterov wrote: On 03/26, Thomas Gleixner wrote: The rework of the watchdog core to use cpu_stop_work broke the watchdog cpumask on CPU hotplug. The watchdog_enable/disable() functions are now called unconditionally from the hotplug callback, i.e. even on CPUs which are not in the watchdog cpumask. Only invoke them when the plugged CPU is in the watchdog cpumask. IIUC without this fix an NMI watchdog can too be enabled at boot time even if the initial watchdog_cpumask = housekeeping_cpumask(HK_FLAG_TIMER) doesn't include the plugged CPU. Yes. And after that writing 0 to /proc/sys/kernel/nmi_watchdog clears NMI_WATCHDOG_ENABLED but this can't disable NMI watchdog's outside of watchdog_allowed_mask. Correct So may be this can explain the problem reported by Maxime ? See https://lore.kernel.org/lkml/b99c5a25-a5fe-18dd-2f1d-bdd6834f0...@redhat.com/ That looks so. I had a trial with your patch, and I can confirm it fixes my issue: Tested-by: Maxime Coquelin Thanks, Maxime Thanks, tglx
Re: [PATCH] pinctrl: intel: save HOSTSW_OWN register over suspend/resume
On Thu, Mar 28, 2019 at 5:17 PM Andy Shevchenko wrote: > Hmm... Can you confirm that laptop you declared as a fixed case and the > mentioned here is the same one? They are definitely not the same exact unit - originally we had a pre-production sample, and now we briefly diagnosed a real production unit that was sold to a customer. There could be subtle motherboard variations as you mention. > If it's the case, I recommend to ping Asus again and make them check and fix. We'll keep an eye open for any opportunities to go deeper here. However further investigation on both our side and theirs is blocked by not having any of the affected hardware (since the models are now so old), so I'm not very optimistic that we'll be able to make progress there. > Meanwhile, Mika's proposal sounds feasible and not so intrusive. We may > implement this later on. Chris will work on implementing this for your consideration. Thanks for the quick feedback! Daniel
Re: [PATCH v2 1/6] device property: Add functions for accessing node's parents
On Wed, Mar 27, 2019 at 3:20 PM Sakari Ailus
wrote:
>
> Hi Petr,
>
> On Wed, Mar 27, 2019 at 01:26:25PM +0100, Petr Mladek wrote:
> > On Tue 2019-03-26 14:41:01, Sakari Ailus wrote:
> > > Add two convenience functions for accessing node's parents:
> > >
> > > fwnode_count_parents() returns the number of parent nodes a given node
> > > has. fwnode_get_nth_parent() returns node's parent at a given distance
> > > from the node itself.
> > >
> > > Also reorder fwnode_get_parent() in property.c according to the same order
> > > as in property.h.
> > >
> > > diff --git a/drivers/base/property.c b/drivers/base/property.c
> > > index 8b91ab380d14..61eb6ceacc3f 100644
> > > --- a/drivers/base/property.c
> > > +++ b/drivers/base/property.c
> > > @@ -554,17 +567,49 @@ struct fwnode_handle *fwnode_get_next_parent(struct
> > > fwnode_handle *fwnode)
> > > EXPORT_SYMBOL_GPL(fwnode_get_next_parent);
> > >
> > > /**
> > > - * fwnode_get_parent - Return parent firwmare node
> > > - * @fwnode: Firmware whose parent is retrieved
> > > + * fwnode_count_parents - Return the number of parents a node has
> > > + * @fwnode: The node the parents of which are to be counted
> > > *
> > > - * Return parent firmware node of the given node if possible or %NULL if
> > > no
> > > - * parent was available.
> > > + * Returns the number of parents a node has.
> > > */
> > > -struct fwnode_handle *fwnode_get_parent(const struct fwnode_handle
> > > *fwnode)
> > > +unsigned int fwnode_count_parents(struct fwnode_handle *fwnode)
> > > {
> > > - return fwnode_call_ptr_op(fwnode, get_parent);
> > > + unsigned int count;
> > > +
> > > + fwnode_handle_get(fwnode);
> > > +
> > > + for (count = 0; fwnode; count++)
> > > + fwnode = fwnode_get_next_parent(fwnode);
> >
> > Is it guaranteed that all parents stay when
> > fwnode_get_next_parent() releases the reference count
> > for each counted member?
>
> fwnode_get_next_parent() only releases the child node after it has acquired
> the parent. The only implementation with refcounting for single nodes is
> actually OF.
>
> >
> > > +
> > > + return count - 1;
> >
> > We could start counting from count = -1;
>
> We could, but then count would need to be made signed (unless overflowing
> is preferred instead).
What if there are no parents?
Or is it guaranteed that there always will be at least one?
Re: [PATCH v2 2/6] device property: Add fwnode_get_name for returning the name of a node
On Tue, Mar 26, 2019 at 1:41 PM Sakari Ailus
wrote:
>
> The fwnode framework did not have means to obtain the name of a node. Add
> that now, in form of the fwnode_get_name() function and a corresponding
> get_name fwnode op. OF and ACPI support is included.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/acpi/property.c | 24
> drivers/base/property.c | 11 +++
> drivers/of/property.c| 6 ++
> include/linux/fwnode.h | 2 ++
> include/linux/property.h | 1 +
> 5 files changed, 44 insertions(+)
>
> diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
> index 77abe0ec4043..8c9a4c02cde2 100644
> --- a/drivers/acpi/property.c
> +++ b/drivers/acpi/property.c
> @@ -1291,6 +1291,29 @@ acpi_fwnode_get_reference_args(const struct
> fwnode_handle *fwnode,
> args_count, args);
> }
>
> +static const char *acpi_fwnode_get_name(const struct fwnode_handle *fwnode)
> +{
> + const struct acpi_device *adev;
> + struct fwnode_handle *parent;
> +
> + parent = fwnode_get_parent(fwnode);
> + /* Is this the root node? */
> + if (!parent)
> + return "\\";
> +
> + fwnode_handle_put(parent);
> +
> + if (is_acpi_data_node(fwnode)) {
> + const struct acpi_data_node *dn = to_acpi_data_node(fwnode);
> +
> + return dn->name;
> + }
> +
> + adev = to_acpi_device_node(fwnode);
> +
> + return adev ? acpi_device_bid(adev) : NULL;
I would do
if (WARN_ON(!adev))
return NULL;
return acpi_device_bid(adev);
> +}
> +
> static struct fwnode_handle *
> acpi_fwnode_get_parent(struct fwnode_handle *fwnode)
> {
> @@ -1331,6 +1354,7 @@ acpi_fwnode_device_get_match_data(const struct
> fwnode_handle *fwnode,
> .get_parent = acpi_node_get_parent, \
> .get_next_child_node = acpi_get_next_subnode, \
> .get_named_child_node = acpi_fwnode_get_named_child_node, \
> + .get_name = acpi_fwnode_get_name, \
> .get_reference_args = acpi_fwnode_get_reference_args, \
> .graph_get_next_endpoint = \
> acpi_graph_get_next_endpoint, \
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index 61eb6ceacc3f..04a8591cd1b0 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -533,6 +533,17 @@ int device_add_properties(struct device *dev,
> EXPORT_SYMBOL_GPL(device_add_properties);
>
> /**
> + * fwnode_get_name - Return the name of a node
> + * @fwnode: The firmware node
> + *
> + * Returns a pointer to the node name.
> + */
> +const char *fwnode_get_name(const struct fwnode_handle *fwnode)
> +{
> + return fwnode_call_ptr_op(fwnode, get_name);
> +}
> +
> +/**
> * fwnode_get_parent - Return parent firwmare node
> * @fwnode: Firmware whose parent is retrieved
> *
> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index 8631efa1daa1..f0a7b78f2d9f 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -872,6 +872,11 @@ of_fwnode_property_read_string_array(const struct
> fwnode_handle *fwnode,
> of_property_count_strings(node, propname);
> }
>
> +static const char *of_fwnode_get_name(const struct fwnode_handle *fwnode)
> +{
> + return kbasename(to_of_node(fwnode)->full_name);
> +}
> +
> static struct fwnode_handle *
> of_fwnode_get_parent(const struct fwnode_handle *fwnode)
> {
> @@ -993,6 +998,7 @@ const struct fwnode_operations of_fwnode_ops = {
> .property_present = of_fwnode_property_present,
> .property_read_int_array = of_fwnode_property_read_int_array,
> .property_read_string_array = of_fwnode_property_read_string_array,
> + .get_name = of_fwnode_get_name,
> .get_parent = of_fwnode_get_parent,
> .get_next_child_node = of_fwnode_get_next_child_node,
> .get_named_child_node = of_fwnode_get_named_child_node,
> diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
> index faebf0ca0686..85b7fa4dc727 100644
> --- a/include/linux/fwnode.h
> +++ b/include/linux/fwnode.h
> @@ -59,6 +59,7 @@ struct fwnode_reference_args {
> * otherwise.
> * @property_read_string_array: Read an array of string properties. Return
> zero
> * on success, a negative error code otherwise.
> + * @get_name: Return the name of an fwnode.
> * @get_parent: Return the parent of an fwnode.
> * @get_next_child_node: Return the next child node in an iteration.
> * @get_named_child_node: Return a child node with a given name.
> @@ -85,6 +86,7 @@ struct fwnode_operations {
> (*property_read_string_array)(const struct fwnode_handle
> *fwnode_handle,
> const char *propname, const char **val,
>
Re: [PATCH v3 3/4] cpufreq: schedutil: Simplify iowait boosting
Hi Rafael,
On Tuesday 26 Mar 2019 at 12:18:00 (+0100), Rafael J. Wysocki wrote:
> @@ -13,6 +13,8 @@
> #include
> #include
>
> +#define IOWAIT_BOOST_MIN (SCHED_CAPACITY_SCALE / 8)
> +
> struct sugov_tunables {
> struct gov_attr_set attr_set;
> unsigned intrate_limit_us;
> @@ -51,7 +53,6 @@ struct sugov_cpu {
> u64 last_update;
>
> unsigned long bw_dl;
> - unsigned long min;
> unsigned long max;
>
> /* The field below is for single-CPU policies only: */
> @@ -303,7 +304,7 @@ static bool sugov_iowait_reset(struct sua
The comment above this function needs updating I think.
> if (delta_ns <= TICK_NSEC)
> return false;
>
> - sg_cpu->iowait_boost = set_iowait_boost ? sg_cpu->min : 0;
> + sg_cpu->iowait_boost = set_iowait_boost ? IOWAIT_BOOST_MIN : 0;
> sg_cpu->iowait_boost_pending = set_iowait_boost;
>
> return true;
> @@ -349,7 +350,7 @@ static void sugov_iowait_boost(struct su
Ditto.
> }
>
> /* First wakeup after IO: start with minimum boost */
> - sg_cpu->iowait_boost = sg_cpu->min;
> + sg_cpu->iowait_boost = IOWAIT_BOOST_MIN;
> }
>
> /**
> @@ -389,7 +390,7 @@ static unsigned long sugov_iowait_apply(
>* No boost pending; reduce the boost value.
>*/
> sg_cpu->iowait_boost >>= 1;
> - if (sg_cpu->iowait_boost < sg_cpu->min) {
> + if (sg_cpu->iowait_boost < IOWAIT_BOOST_MIN) {
> sg_cpu->iowait_boost = 0;
> return util;
> }
> @@ -826,9 +827,6 @@ static int sugov_start(struct cpufreq_po
> memset(sg_cpu, 0, sizeof(*sg_cpu));
> sg_cpu->cpu = cpu;
> sg_cpu->sg_policy = sg_policy;
> - sg_cpu->min =
> - (SCHED_CAPACITY_SCALE * policy->cpuinfo.min_freq) /
> - policy->cpuinfo.max_freq;
> }
>
> for_each_cpu(cpu, policy->cpus) {
>
Other than that, I tried a backport of this on a Pixel 3 with Snapdragon
845 (which is relevant because it has tons of OPPs, so starting at 128
makes it ramp up faster) to check the impact on power, but the only
differences appeared to be in the noise margin, so it's all good :)
Full test results available at [1]. Note that I did enable the iowait
boost feature for these tests -- it is disabled by default on P3 ...
Thanks,
Quentin
---
[1] https://nbviewer.jupyter.org/gist/qperret/69c9bde13aad2d783689e78c9ba2d9bc
[PATCH v2] staging: pi433: Fix rf69_set_tx_cfg() logic
Moved code to configure sync to where check enable_sync option before.
There is no need to check enable_sync twice. Configuring sync should be
executed immediately after enabling sync.
Signed-off-by: Sidong Yang
---
v2: remove obvious comment. reordered size/value/enable sync functions.
drivers/staging/pi433/pi433_if.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 53928af696a6..8fa7b3346170 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -319,6 +319,12 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct
pi433_tx_cfg *tx_cfg)
}
if (tx_cfg->enable_sync == OPTION_ON) {
+ ret = rf69_set_sync_size(dev->spi, tx_cfg->sync_length);
+ if (ret < 0)
+ return ret;
+ ret = rf69_set_sync_values(dev->spi, tx_cfg->sync_pattern);
+ if (ret < 0)
+ return ret;
ret = rf69_enable_sync(dev->spi);
if (ret < 0)
return ret;
@@ -348,16 +354,6 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct
pi433_tx_cfg *tx_cfg)
return ret;
}
- /* configure sync, if enabled */
- if (tx_cfg->enable_sync == OPTION_ON) {
- ret = rf69_set_sync_size(dev->spi, tx_cfg->sync_length);
- if (ret < 0)
- return ret;
- ret = rf69_set_sync_values(dev->spi, tx_cfg->sync_pattern);
- if (ret < 0)
- return ret;
- }
-
return 0;
}
--
2.17.1
Re: [PATCH v3 4/4] RISC-V: Allow booting kernel from any 4KB aligned address
On Thu, Mar 28, 2019 at 1:25 PM Mike Rapoport wrote: > > On Wed, Mar 27, 2019 at 12:54:41AM -0700, Christoph Hellwig wrote: > > On Mon, Mar 25, 2019 at 09:46:59PM +0530, Anup Patel wrote: > > > > Why do you even care about kernel mappings for non-existant ram. > > > > > > We care because there will always be some buggy kernel driver/code going > > > out-of-bound and accessing non-existent RAM. If we by default map all > > > possible kernel virtual address then behaviour of buggy accesses will be > > > unpredictable. > > > > > > Further, I think we should also make .text and .rodata sections of kernel > > > as read-only. This will protect kernel code and rodata. > > > > All of that is useful at the final_setup_vm() time - but none of it > > matters during early setup_vm where life is complicated. > > > > Mike suggested on the previous iteration that you only do smaller > > mappings when setting up the final mapping to avoid the ops churn, > > and I fully agree with him. > > > > So I would suggest we avoid complicated the fiddly early boot changes > > that just add complxity, and you instead redirect your efforts to > > say implemented proper ro and non-executable sections using 4k mappings > > in the final VM setup only. That should actuall lead to less code > > and complexity, and provide more benefits. > > It might be worth keeping trampoline_pg_dir if we are to split setup_vm(). > Then setup_vm() will only initialize the trampoline_pg_dir and > final_setup_vm() will setup the swapper_pg_dir and switch to it. > Otherwise final_setup_vm() would need to update live mappings which might > be fragile. > We finally know the purpose trampoline_pg_dir page table. The trampoline_pg_dir is suppose to contain only one 2M/4M mapping to handle case where PAGE_OFFSET < load_address. For 64bit systems, the PAGE_OFFSET is very high value typically 0x compared to RAM start 0x8000. It is very unlikely that we will have enormous RAM ending somewhere 0x. For 32bit systems, it is quite possible that bootloader loads kernel at load_address > 0x8000. Let say PAGE_OFFSET = 0xC000 and load_address = 0xC010. Now the instruction which enables MMU will be 0xC0100xxx and after enabling it will try to fetch next instruction 0xC0100xxx + 4 but 0xC010 maps to 0xC020 as load_address > PAGE_OFFSET hence we will see wrong instruction after enabling MMU. (Note: Above explanation was provided by Anthony) I guess we will have to keep both trampoline_pg_dir and swapper_pg_dir init in setup_vm() because trampoline_pg_dir will only contain just one 2M/4M mapping. Regards, Anup
[PATCH 2/7] mtd: rawnand: Add Macronix MX25F0A NAND controller driver
Add a driver for Macronix MX25F0A NAND controller.
Signed-off-by: Mason Yang
---
drivers/mtd/nand/raw/Kconfig | 6 +
drivers/mtd/nand/raw/Makefile| 1 +
drivers/mtd/nand/raw/mxic_nand.c | 303 +++
3 files changed, 310 insertions(+)
create mode 100644 drivers/mtd/nand/raw/mxic_nand.c
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index e604625..e0329cc 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -522,6 +522,12 @@ config MTD_NAND_QCOM
Enables support for NAND flash chips on SoCs containing the EBI2 NAND
controller. This controller is found on IPQ806x SoC.
+config MTD_NAND_MXIC
+ tristate "Macronix MX25F0A NAND controller"
+ depends on HAS_IOMEM
+ help
+ This selects the Macronix MX25F0A NAND controller driver.
+
config MTD_NAND_MTK
tristate "Support for NAND controller on MTK SoCs"
depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index 5a5a72f..c8a6790 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o
obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o
obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/
obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o
+obj-$(CONFIG_MTD_NAND_MXIC)+= mxic_nand.o
obj-$(CONFIG_MTD_NAND_MTK) += mtk_ecc.o mtk_nand.o
obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o
obj-$(CONFIG_MTD_NAND_STM32_FMC2) += stm32_fmc2_nand.o
diff --git a/drivers/mtd/nand/raw/mxic_nand.c b/drivers/mtd/nand/raw/mxic_nand.c
new file mode 100644
index 000..03886b2
--- /dev/null
+++ b/drivers/mtd/nand/raw/mxic_nand.c
@@ -0,0 +1,303 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2019 Macronix International Co., Ltd.
+//
+// Authors:
+// Mason Yang
+// zhengxunli
+//
+
+#include
+#include
+#include
+
+#include "internals.h"
+
+struct mxic_nand_ctlr {
+ struct nand_controller base;
+ struct nand_chip nand;
+ void __iomem *regs;
+};
+
+static void mxic_host_init(struct mxic_nand_ctlr *mxic)
+{
+ writel(DATA_STROB_EDO_EN, mxic->regs + DATA_STROB);
+ writel(INT_STS_ALL, mxic->regs + INT_STS_EN);
+ writel(0x0, mxic->regs + ONFI_DIN_CNT(0));
+ writel(HC_CFG_NIO(8) | HC_CFG_SLV_ACT(0) | HC_CFG_IDLE_SIO_LVL(1) |
+ HC_CFG_TYPE(1, HC_CFG_TYPE_RAW_NAND) | HC_CFG_MAN_CS_EN,
+ mxic->regs + HC_CFG);
+ writel(0x0, mxic->regs + HC_EN);
+}
+
+static int mxic_nand_wait_ready(struct nand_chip *chip)
+{
+ struct mxic_nand_ctlr *mxic = nand_get_controller_data(chip);
+ u32 sts;
+
+ return readl_poll_timeout(mxic->regs + INT_STS, sts,
+ sts & INT_RDY_PIN, 0, USEC_PER_SEC);
+}
+
+static void mxic_nand_select_chip(struct nand_chip *chip, int chipnr)
+{
+ struct mxic_nand_ctlr *mxic = nand_get_controller_data(chip);
+
+ switch (chipnr) {
+ case 0:
+ case 1:
+ writel(HC_EN_BIT, mxic->regs + HC_EN);
+ writel(HC_CFG_MAN_CS_ASSERT | readl(mxic->regs + HC_CFG),
+ mxic->regs + HC_CFG);
+ break;
+
+ case -1:
+ writel(~HC_CFG_MAN_CS_ASSERT & readl(mxic->regs + HC_CFG),
+ mxic->regs + HC_CFG);
+ writel(0, mxic->regs + HC_EN);
+ break;
+
+ default:
+ break;
+ }
+}
+
+static int mxic_nand_data_xfer(struct mxic_nand_ctlr *mxic, const void *txbuf,
+ void *rxbuf, unsigned int len)
+{
+ unsigned int pos = 0;
+
+ while (pos < len) {
+ unsigned int nbytes = len - pos;
+ u32 data = 0x;
+ u32 sts;
+ int ret;
+
+ if (nbytes > 4)
+ nbytes = 4;
+
+ if (txbuf)
+ memcpy(, txbuf + pos, nbytes);
+
+ ret = readl_poll_timeout(mxic->regs + INT_STS, sts,
+sts & INT_TX_EMPTY, 0, USEC_PER_SEC);
+ if (ret)
+ return ret;
+
+ writel(data, mxic->regs + TXD(nbytes % 4));
+
+ if (rxbuf) {
+ ret = readl_poll_timeout(mxic->regs + INT_STS, sts,
+sts & INT_TX_EMPTY, 0,
+USEC_PER_SEC);
+ if (ret)
+ return ret;
+
+ ret = readl_poll_timeout(mxic->regs + INT_STS, sts,
+sts & INT_RX_NOT_EMPTY, 0,
+USEC_PER_SEC);
+ if (ret)
+
[PATCH 5/7] spi: Add direct mapping mode for Macronix SPI controller
Add direct mapping read mode for Macronix SPI controller driver.
Signed-off-by: Mason Yang
---
drivers/spi/spi-mxic.c | 129 ++---
1 file changed, 100 insertions(+), 29 deletions(-)
diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
index fbebf89..9f5ff2b 100644
--- a/drivers/spi/spi-mxic.c
+++ b/drivers/spi/spi-mxic.c
@@ -19,6 +19,7 @@ struct mxic_spi {
struct clk *send_clk;
struct clk *send_dly_clk;
void __iomem *regs;
+ void __iomem *dirmap;
u32 cur_speed_hz;
};
@@ -128,6 +129,42 @@ static void mxic_spi_hw_init(struct mxic_spi *mxic)
mxic->regs + HC_CFG);
}
+static u32 mxic_spi_mem_prep_op_cfg(const struct spi_mem_op *op)
+{
+ u32 cfg = OP_CMD_BYTES(1) | OP_CMD_BUSW(fls(op->cmd.buswidth) - 1);
+
+ if (op->addr.nbytes)
+ cfg |= OP_ADDR_BYTES(op->addr.nbytes) |
+ OP_ADDR_BUSW(fls(op->addr.buswidth) - 1);
+
+ if (op->dummy.nbytes)
+ cfg |= OP_DUMMY_CYC(op->dummy.nbytes);
+
+ if (op->data.nbytes) {
+ cfg |= OP_DATA_BUSW(fls(op->data.buswidth) - 1);
+ if (op->data.dir == SPI_MEM_DATA_IN)
+ cfg |= OP_READ;
+ }
+
+ return cfg;
+}
+
+static void mxic_spi_set_hc_cfg(struct spi_device *spi, u32 flags)
+{
+ struct mxic_spi *mxic = spi_master_get_devdata(spi->master);
+ int nio = 1;
+
+ if (spi->mode & (SPI_TX_QUAD | SPI_RX_QUAD))
+ nio = 4;
+ else if (spi->mode & (SPI_TX_DUAL | SPI_RX_DUAL))
+ nio = 2;
+
+ writel(flags | HC_CFG_NIO(nio) |
+ HC_CFG_TYPE(spi->chip_select, HC_CFG_TYPE_SPI_NOR) |
+ HC_CFG_SLV_ACT(spi->chip_select) | HC_CFG_IDLE_SIO_LVL(1),
+ mxic->regs + HC_CFG);
+}
+
static int mxic_spi_data_xfer(struct mxic_spi *mxic, const void *txbuf,
void *rxbuf, unsigned int len)
{
@@ -201,43 +238,18 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
const struct spi_mem_op *op)
{
struct mxic_spi *mxic = spi_master_get_devdata(mem->spi->master);
- int nio = 1, i, ret;
- u32 ss_ctrl;
+ int i, ret;
u8 addr[8];
ret = mxic_spi_set_freq(mxic, mem->spi->max_speed_hz);
if (ret)
return ret;
- if (mem->spi->mode & (SPI_TX_QUAD | SPI_RX_QUAD))
- nio = 4;
- else if (mem->spi->mode & (SPI_TX_DUAL | SPI_RX_DUAL))
- nio = 2;
+ mxic_spi_set_hc_cfg(mem->spi, HC_CFG_MAN_CS_EN);
- writel(HC_CFG_NIO(nio) |
- HC_CFG_TYPE(mem->spi->chip_select, HC_CFG_TYPE_SPI_NOR) |
- HC_CFG_SLV_ACT(mem->spi->chip_select) | HC_CFG_IDLE_SIO_LVL(1) |
- HC_CFG_MAN_CS_EN,
- mxic->regs + HC_CFG);
writel(HC_EN_BIT, mxic->regs + HC_EN);
-
- ss_ctrl = OP_CMD_BYTES(1) | OP_CMD_BUSW(fls(op->cmd.buswidth) - 1);
-
- if (op->addr.nbytes)
- ss_ctrl |= OP_ADDR_BYTES(op->addr.nbytes) |
- OP_ADDR_BUSW(fls(op->addr.buswidth) - 1);
-
- if (op->dummy.nbytes)
- ss_ctrl |= OP_DUMMY_CYC(op->dummy.nbytes);
-
- if (op->data.nbytes) {
- ss_ctrl |= OP_DATA_BUSW(fls(op->data.buswidth) - 1);
- if (op->data.dir == SPI_MEM_DATA_IN)
- ss_ctrl |= OP_READ;
- }
-
- writel(ss_ctrl, mxic->regs + SS_CTRL(mem->spi->chip_select));
-
+ writel(mxic_spi_mem_prep_op_cfg(op),
+ mxic->regs + SS_CTRL(mem->spi->chip_select));
writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_ASSERT,
mxic->regs + HC_CFG);
@@ -271,9 +283,64 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
return ret;
}
+static int mxic_spi_mem_dirmap_create(struct spi_mem_dirmap_desc *desc)
+{
+ struct mxic_spi *mxic = spi_master_get_devdata(desc->mem->spi->master);
+
+ if (!mxic->dirmap)
+ return -ENOTSUPP;
+
+/*
+ * TODO: overcome this limitation by moving LWR/LRD_ADDR during a
+ * read/write operation.
+ */
+ if (desc->info.offset + desc->info.length > U32_MAX)
+ return -ENOTSUPP;
+
+ if (!mxic_spi_mem_supports_op(desc->mem, >info.op_tmpl))
+ return -ENOTSUPP;
+
+ if (desc->info.op_tmpl.data.dir == SPI_MEM_DATA_OUT)
+ return -ENOTSUPP;
+
+ return 0;
+}
+
+static ssize_t mxic_spi_mem_dirmap_read(struct spi_mem_dirmap_desc *desc,
+ u64 offs, size_t len, void *buf)
+{
+ struct mxic_spi *mxic = spi_master_get_devdata(desc->mem->spi->master);
+ int ret;
+ u32 sts;
+
+ mxic_spi_set_hc_cfg(desc->mem->spi, 0);
+
+ writel(mxic_spi_mem_prep_op_cfg(>info.op_tmpl),
+ mxic->regs + LRD_CFG);
+ writel(LMODE_CMD0(desc->info.op_tmpl.cmd.opcode >>
[PATCH 1/7] mfd: Add Macronix MX25F0A MFD controller driver
Add a driver for Macronix MX25F0A multifunction device controller.
Signed-off-by: Mason Yang
---
drivers/mfd/Kconfig | 9 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/mxic-mx25f0a.c | 90
include/linux/mfd/mxic-mx25f0a.h | 173 +++
4 files changed, 273 insertions(+)
create mode 100644 drivers/mfd/mxic-mx25f0a.c
create mode 100644 include/linux/mfd/mxic-mx25f0a.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 0ce2d8d..68aaf2a 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -823,6 +823,15 @@ config MFD_MAX8998
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MXIC_MX25F0A
+ tristate "Macronix mx25f0a multifunction device support"
+ select MFD_CORE
+ help
+ This supports for Macronix mx25f0a multifunction device controller
+ for raw nand or spi. You have to select individual components like
+ raw nand controller or spi host controller under the corresponding
+ menus.
+
config MFD_MT6397
tristate "MediaTek MT6397 PMIC Support"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b4569ed7..dcfe8fd 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -163,6 +163,7 @@ max8925-objs:= max8925-core.o
max8925-i2c.o
obj-$(CONFIG_MFD_MAX8925) += max8925.o
obj-$(CONFIG_MFD_MAX8997) += max8997.o max8997-irq.o
obj-$(CONFIG_MFD_MAX8998) += max8998.o max8998-irq.o
+obj-$(CONFIG_MFD_MXIC_MX25F0A) += mxic-mx25f0a.o
pcf50633-objs := pcf50633-core.o pcf50633-irq.o
obj-$(CONFIG_MFD_PCF50633) += pcf50633.o
diff --git a/drivers/mfd/mxic-mx25f0a.c b/drivers/mfd/mxic-mx25f0a.c
new file mode 100644
index 000..04b1173
--- /dev/null
+++ b/drivers/mfd/mxic-mx25f0a.c
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2019 Macronix International Co., Ltd.
+//
+// Author:
+// Mason Yang
+//
+
+#include
+#include
+
+static const struct mfd_cell mx25f0a_nand_ctlr = {
+ .name = "mxic-nand-ctlr",
+ .of_compatible = "mxicy,mx25f0a-nand-ctlr",
+};
+
+static const struct mfd_cell mx25f0a_spi_ctlr = {
+ .name = "mxic-spi",
+ .of_compatible = "mxicy,mx25f0a-spi",
+};
+
+static int mx25f0a_mfd_probe(struct platform_device *pdev)
+{
+ struct device_node *ctlr;
+ const struct mfd_cell *cell;
+ struct mx25f0a_mfd *mxic;
+ struct resource *res;
+ int ret;
+
+ ctlr = of_get_next_child(pdev->dev.of_node, NULL);
+ if (!ctlr) {
+ dev_warn(>dev, "no spi/nand ctlr node found\n");
+ return -ENODEV;
+ }
+
+ ret = of_device_is_compatible(ctlr, "mxicy,mx25f0a-nand-ctlr");
+ if (ret) {
+ cell = _nand_ctlr;
+ } else {
+ ret = of_device_is_compatible(ctlr, "mxicy,mx25f0a-spi");
+ if (ret) {
+ cell = _spi_ctlr;
+ } else {
+ dev_warn(>dev, "no any spi/nand device found\n");
+ return -ENODEV;
+ }
+ }
+
+ mxic = devm_kzalloc(>dev, sizeof(*mxic), GFP_KERNEL);
+ if (!mxic)
+ return -ENOMEM;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
+ mxic->base = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(mxic->base))
+ return PTR_ERR(mxic->base);
+
+ if (cell == _spi_ctlr) {
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ "dirmap");
+ mxic->dirmap = devm_ioremap_resource(>dev, res);
+ if (IS_ERR(mxic->dirmap))
+ mxic->dirmap = NULL;
+ }
+
+ platform_set_drvdata(pdev, mxic);
+
+ ret = devm_mfd_add_devices(>dev, -1, cell, 1, NULL, 0, NULL);
+
+ return ret;
+}
+
+static const struct of_device_id mx25f0a_mfd_of_match[] = {
+ { .compatible = "mxic,mx25f0a-mfd", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mx25f0a_mfd_of_match);
+
+static struct platform_driver mx25f0a_mfd_driver = {
+ .probe = mx25f0a_mfd_probe,
+ .driver = {
+ .name = "mx25f0a-mfd",
+ .of_match_table = mx25f0a_mfd_of_match,
+ },
+};
+module_platform_driver(mx25f0a_mfd_driver);
+
+MODULE_AUTHOR("Mason Yang ");
+MODULE_DESCRIPTION("MX25F0A controller MFD driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/mfd/mxic-mx25f0a.h b/include/linux/mfd/mxic-mx25f0a.h
new file mode 100644
index 000..5a8cfc7
--- /dev/null
+++ b/include/linux/mfd/mxic-mx25f0a.h
@@ -0,0 +1,173 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2019 Macronix International Co., Ltd.
+//
+// Author:
+// Mason Yang
+//
+
+#ifndef __MFD_MXIC_MX25F0A_H
+#define __MFD_MXIC_MX25F0A_H
[PATCH 3/7] spi: Patch Macronix MX25F0A SPI controller driver
Patch a MFD driver for Macronix MX25F0A SPI controller. Signed-off-by: Mason Yang --- drivers/spi/spi-mxic.c | 159 + 1 file changed, 3 insertions(+), 156 deletions(-) diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c index e41ae6e..fbebf89 100644 --- a/drivers/spi/spi-mxic.c +++ b/drivers/spi/spi-mxic.c @@ -9,163 +9,11 @@ // #include -#include -#include -#include -#include +#include #include #include #include -#define HC_CFG 0x0 -#define HC_CFG_IF_CFG(x) ((x) << 27) -#define HC_CFG_DUAL_SLAVE BIT(31) -#define HC_CFG_INDIVIDUAL BIT(30) -#define HC_CFG_NIO(x) (((x) / 4) << 27) -#define HC_CFG_TYPE(s, t) ((t) << (23 + ((s) * 2))) -#define HC_CFG_TYPE_SPI_NOR0 -#define HC_CFG_TYPE_SPI_NAND 1 -#define HC_CFG_TYPE_SPI_RAM2 -#define HC_CFG_TYPE_RAW_NAND 3 -#define HC_CFG_SLV_ACT(x) ((x) << 21) -#define HC_CFG_CLK_PH_EN BIT(20) -#define HC_CFG_CLK_POL_INV BIT(19) -#define HC_CFG_BIG_ENDIAN BIT(18) -#define HC_CFG_DATA_PASS BIT(17) -#define HC_CFG_IDLE_SIO_LVL(x) ((x) << 16) -#define HC_CFG_MAN_START_ENBIT(3) -#define HC_CFG_MAN_START BIT(2) -#define HC_CFG_MAN_CS_EN BIT(1) -#define HC_CFG_MAN_CS_ASSERT BIT(0) - -#define INT_STS0x4 -#define INT_STS_EN 0x8 -#define INT_SIG_EN 0xc -#define INT_STS_ALLGENMASK(31, 0) -#define INT_RDY_PINBIT(26) -#define INT_RDY_SR BIT(25) -#define INT_LNR_SUSP BIT(24) -#define INT_ECC_ERRBIT(17) -#define INT_CRC_ERRBIT(16) -#define INT_LWR_DISBIT(12) -#define INT_LRD_DISBIT(11) -#define INT_SDMA_INT BIT(10) -#define INT_DMA_FINISH BIT(9) -#define INT_RX_NOT_FULLBIT(3) -#define INT_RX_NOT_EMPTY BIT(2) -#define INT_TX_NOT_FULLBIT(1) -#define INT_TX_EMPTY BIT(0) - -#define HC_EN 0x10 -#define HC_EN_BIT BIT(0) - -#define TXD(x) (0x14 + ((x) * 4)) -#define RXD0x24 - -#define SS_CTRL(s) (0x30 + ((s) * 4)) -#define LRD_CFG0x44 -#define LWR_CFG0x80 -#define RWW_CFG0x70 -#define OP_READBIT(23) -#define OP_DUMMY_CYC(x)((x) << 17) -#define OP_ADDR_BYTES(x) ((x) << 14) -#define OP_CMD_BYTES(x)(((x) - 1) << 13) -#define OP_OCTA_CRC_EN BIT(12) -#define OP_DQS_EN BIT(11) -#define OP_ENHC_EN BIT(10) -#define OP_PREAMBLE_EN BIT(9) -#define OP_DATA_DDRBIT(8) -#define OP_DATA_BUSW(x)((x) << 6) -#define OP_ADDR_DDRBIT(5) -#define OP_ADDR_BUSW(x)((x) << 3) -#define OP_CMD_DDR BIT(2) -#define OP_CMD_BUSW(x) (x) -#define OP_BUSW_1 0 -#define OP_BUSW_2 1 -#define OP_BUSW_4 2 -#define OP_BUSW_8 3 - -#define OCTA_CRC 0x38 -#define OCTA_CRC_IN_EN(s) BIT(3 + ((s) * 16)) -#define OCTA_CRC_CHUNK(s, x) ((fls((x) / 32)) << (1 + ((s) * 16))) -#define OCTA_CRC_OUT_EN(s) BIT(0 + ((s) * 16)) - -#define ONFI_DIN_CNT(s)(0x3c + (s)) - -#define LRD_CTRL 0x48 -#define RWW_CTRL 0x74 -#define LWR_CTRL 0x84 -#define LMODE_EN BIT(31) -#define LMODE_SLV_ACT(x) ((x) << 21) -#define LMODE_CMD1(x) ((x) << 8) -#define LMODE_CMD0(x) (x) - -#define LRD_ADDR 0x4c -#define LWR_ADDR 0x88 -#define LRD_RANGE 0x50 -#define LWR_RANGE 0x8c - -#define AXI_SLV_ADDR 0x54 - -#define DMAC_RD_CFG0x58 -#define DMAC_WR_CFG0x94 -#define DMAC_CFG_PERIPH_EN BIT(31) -#define DMAC_CFG_ALLFLUSH_EN BIT(30) -#define DMAC_CFG_LASTFLUSH_EN BIT(29) -#define DMAC_CFG_QE(x) (((x) + 1) << 16) -#define DMAC_CFG_BURST_LEN(x) (((x) + 1) << 12) -#define DMAC_CFG_BURST_SZ(x) ((x) << 8) -#define DMAC_CFG_DIR_READ BIT(1) -#define DMAC_CFG_START BIT(0) - -#define DMAC_RD_CNT0x5c -#define DMAC_WR_CNT0x98 - -#define SDMA_ADDR 0x60 - -#define DMAM_CFG 0x64 -#define DMAM_CFG_START BIT(31) -#define DMAM_CFG_CONT BIT(30) -#define DMAM_CFG_SDMA_GAP(x) (fls((x) / 8192) << 2) -#define DMAM_CFG_DIR_READ BIT(1) -#define DMAM_CFG_ENBIT(0) - -#define DMAM_CNT 0x68 - -#define LNR_TIMER_TH 0x6c - -#define RDM_CFG0 0x78 -#define RDM_CFG0_POLY(x) (x) - -#define RDM_CFG1 0x7c -#define RDM_CFG1_RDM_ENBIT(31) -#define RDM_CFG1_SEED(x) (x) - -#define LWR_SUSP_CTRL 0x90 -#define LWR_SUSP_CTRL_EN BIT(31) - -#define
[PATCH 6/7] mtd: rawnand: Add Macronix NAND read retry and randomizer support
Add a driver for Macronix NAND read retry and randomizer.
Signed-off-by: Mason Yang
---
drivers/mtd/nand/raw/nand_macronix.c | 169 +++
1 file changed, 169 insertions(+)
diff --git a/drivers/mtd/nand/raw/nand_macronix.c
b/drivers/mtd/nand/raw/nand_macronix.c
index 47d8cda..a19caa4 100644
--- a/drivers/mtd/nand/raw/nand_macronix.c
+++ b/drivers/mtd/nand/raw/nand_macronix.c
@@ -17,6 +17,174 @@
#include "internals.h"
+#define MACRONIX_READ_RETRY_BIT BIT(0)
+#define MACRONIX_RANDOMIZER_BIT BIT(1)
+#define MACRONIX_READ_RETRY_MODE 5
+
+#define ONFI_FEATURE_ADDR_MXIC_RANDOMIZER 0xB0
+
+struct nand_onfi_vendor_macronix {
+ u8 reserved[1];
+ u8 reliability_func;
+} __packed;
+
+struct nand_chip *mxic_sysfs;
+
+static int macronix_nand_setup_read_retry(struct nand_chip *chip, int mode)
+{
+ u8 feature[ONFI_SUBFEATURE_PARAM_LEN] = {0};
+ int ret;
+
+ if (mode > MACRONIX_READ_RETRY_MODE)
+ mode = MACRONIX_READ_RETRY_MODE;
+
+ feature[0] = mode;
+ ret = nand_set_features(chip, ONFI_FEATURE_ADDR_READ_RETRY, feature);
+ if (ret)
+ pr_err("failed to enter read retry moded:%d\n", mode);
+
+ if (mode == 0)
+ ret = nand_get_features(chip, ONFI_FEATURE_ADDR_READ_RETRY,
+feature);
+ if (ret)
+ pr_err("failed to exits read retry moded:%d\n", mode);
+
+ return ret;
+}
+
+static ssize_t mxic_nand_rand_type_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ struct nand_chip *chip = mxic_sysfs;
+ u8 feature[ONFI_SUBFEATURE_PARAM_LEN] = {0};
+ int ret;
+
+ nand_select_target(chip, 0);
+ ret = nand_get_features(chip, ONFI_FEATURE_ADDR_MXIC_RANDOMIZER,
+ feature);
+ nand_deselect_target(chip);
+ if (ret)
+ pr_err("failed to check mxic nand device randomizer\n");
+
+ return sprintf(buf, "MXIC NAND device randomizer %s(0x%x)\n",
+ feature[0] & MACRONIX_RANDOMIZER_BIT ?
+ "enable" : "disable", feature[0]);
+}
+
+static ssize_t mxic_nand_rand_type_store(struct kobject *kobj,
+struct kobj_attribute *attr,
+const char *buf, size_t count)
+{
+ struct nand_chip *chip = mxic_sysfs;
+ u8 feature[ONFI_SUBFEATURE_PARAM_LEN] = {0};
+ unsigned int rand_layout;
+ int ret;
+
+ nand_select_target(chip, 0);
+ ret = nand_get_features(chip, ONFI_FEATURE_ADDR_MXIC_RANDOMIZER,
+ feature);
+ nand_deselect_target(chip);
+
+ if (feature[0]) {
+ pr_err("Randomizer is enabled 0x%x\n", feature[0]);
+ goto err_out;
+ }
+
+ ret = kstrtouint(buf, 0, _layout);
+ if (ret)
+ goto err_out;
+
+ if (rand_layout > 7) {
+ pr_err("Error parameter value:0x%x\n", rand_layout);
+ goto err_out;
+ }
+
+ feature[0] = rand_layout & 0x07;
+ nand_select_target(chip, 0);
+ ret = nand_set_features(chip, ONFI_FEATURE_ADDR_MXIC_RANDOMIZER,
+ feature);
+ nand_deselect_target(chip);
+ if (ret) {
+ pr_err("device randomizer set feature failed\n");
+ goto err_out;
+ }
+
+ feature[0] = 0x0;
+ nand_select_target(chip, 0);
+ ret = nand_prog_page_op(chip, 0, 0, feature, 1);
+ nand_deselect_target(chip);
+ if (ret) {
+ pr_err("Prog device randomizer failed\n");
+ goto err_out;
+ }
+
+ feature[0] = 0x0;
+ nand_select_target(chip, 0);
+ ret = nand_set_features(chip, ONFI_FEATURE_ADDR_MXIC_RANDOMIZER,
+ feature);
+ nand_deselect_target(chip);
+ if (ret)
+ pr_err("failed to exits prog device randomizer\n");
+
+err_out:
+ return count;
+}
+
+static const struct kobj_attribute sysfs_mxic_nand =
+ __ATTR(nand_random, S_IRUGO | S_IWUSR,
+ mxic_nand_rand_type_show,
+ mxic_nand_rand_type_store);
+
+static void macronix_nand_onfi_init(struct nand_chip *chip)
+{
+ struct nand_parameters *p = >parameters;
+ struct kobject *kobj;
+ int ret;
+
+ mxic_sysfs = chip;
+ if (p->onfi) {
+ struct nand_onfi_vendor_macronix *mxic =
+ (void *)p->onfi->vendor;
+
+ if (mxic->reliability_func & MACRONIX_READ_RETRY_BIT) {
+ chip->read_retries = MACRONIX_READ_RETRY_MODE + 1;
+ chip->setup_read_retry =
+macronix_nand_setup_read_retry;
+ if (p->supports_set_get_features) {
+
[PATCH 0/7] Add Macronix MX25F0A MFD driver and NAND function
Hi, These patches support 1. Add Macronix MX25F0A MFD driver for SPI and raw NAND controller. 2. Add direct mapping read mode for SPI host controller. 3. Macronix NAND device read retry and randomizer function. 4. Macronix NAND device block protection function. thanks for your review. best regards, Mason Mason Yang (7): mfd: Add Macronix MX25F0A MFD controller driver mtd: rawnand: Add Macronix MX25F0A NAND controller driver spi: Patch Macronix MX25F0A SPI controller driver dt-bindings: mfd: Document Macronix MX25F0A controller bindings spi: Add direct mapping mode for Macronix SPI controller mtd: rawnand: Add Macronix NAND read retry and randomizer support mtd: rawnand: Add Macronix NAND block protection driver .../devicetree/bindings/mfd/mxic-mx25f0a.txt | 66 + drivers/mfd/Kconfig| 9 + drivers/mfd/Makefile | 1 + drivers/mfd/mxic-mx25f0a.c | 90 ++ drivers/mtd/nand/raw/Kconfig | 6 + drivers/mtd/nand/raw/Makefile | 1 + drivers/mtd/nand/raw/mxic_nand.c | 306 + drivers/mtd/nand/raw/nand_macronix.c | 216 +++ drivers/spi/spi-mxic.c | 288 +++ include/linux/mfd/mxic-mx25f0a.h | 176 10 files changed, 974 insertions(+), 185 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/mxic-mx25f0a.txt create mode 100644 drivers/mfd/mxic-mx25f0a.c create mode 100644 drivers/mtd/nand/raw/mxic_nand.c create mode 100644 include/linux/mfd/mxic-mx25f0a.h -- 1.9.1
Re: [RFC PATCH v2] random: add get_random_max() function
By the way, I just noticed that my fallback get_random_max64() algorithm (if there's no __int128 type) is completely broken and will need rewriting. It would work if I rejected and regenerated the high half if the low half were out of range, but that's not what it does. The worst case is a range of 0x1001, where it would return 0x1000 half the time. Needs rethinking to find something as simple as possible. I'm sure I can come up with something, but I'm not averse to suggestions if anyone has any. (If I had a reliably fast clz/fls, that would open some possibilities, but sigh...)
[PATCH 7/7] mtd: rawnand: Add Macronix NAND block protection driver
Add a driver for Macronix NAND block protection function.
Signed-off-by: Mason Yang
---
drivers/mtd/nand/raw/mxic_nand.c | 3 +++
drivers/mtd/nand/raw/nand_macronix.c | 47
include/linux/mfd/mxic-mx25f0a.h | 3 +++
3 files changed, 53 insertions(+)
diff --git a/drivers/mtd/nand/raw/mxic_nand.c b/drivers/mtd/nand/raw/mxic_nand.c
index 03886b2..9307ca2 100644
--- a/drivers/mtd/nand/raw/mxic_nand.c
+++ b/drivers/mtd/nand/raw/mxic_nand.c
@@ -262,6 +262,9 @@ static int mx25f0a_nand_probe(struct platform_device *pdev)
if (err)
goto fail;
+ mtd->_lock = mxic_nand_lock;
+ mtd->_unlock = mxic_nand_unlock;
+
err = mtd_device_register(mtd, NULL, 0);
if (err)
goto fail;
diff --git a/drivers/mtd/nand/raw/nand_macronix.c
b/drivers/mtd/nand/raw/nand_macronix.c
index a19caa4..db63350 100644
--- a/drivers/mtd/nand/raw/nand_macronix.c
+++ b/drivers/mtd/nand/raw/nand_macronix.c
@@ -21,8 +21,12 @@
#define MACRONIX_RANDOMIZER_BIT BIT(1)
#define MACRONIX_READ_RETRY_MODE 5
+#define ONFI_FEATURE_ADDR_MXIC_PROTECTION 0xA0
#define ONFI_FEATURE_ADDR_MXIC_RANDOMIZER 0xB0
+#define MXIC_BLOCK_PROTECTION_ALL_LOCK 0x38
+#define MXIC_BLOCK_PROTECTION_ALL_UNLOCK 0x0
+
struct nand_onfi_vendor_macronix {
u8 reserved[1];
u8 reliability_func;
@@ -146,6 +150,13 @@ static void macronix_nand_onfi_init(struct nand_chip *chip)
struct nand_onfi_vendor_macronix *mxic =
(void *)p->onfi->vendor;
+ if (p->supports_set_get_features) {
+ set_bit(ONFI_FEATURE_ADDR_MXIC_PROTECTION,
+ p->get_feature_list);
+ set_bit(ONFI_FEATURE_ADDR_MXIC_PROTECTION,
+ p->set_feature_list);
+ }
+
if (mxic->reliability_func & MACRONIX_READ_RETRY_BIT) {
chip->read_retries = MACRONIX_READ_RETRY_MODE + 1;
chip->setup_read_retry =
@@ -241,3 +252,39 @@ static int macronix_nand_init(struct nand_chip *chip)
const struct nand_manufacturer_ops macronix_nand_manuf_ops = {
.init = macronix_nand_init,
};
+
+int mxic_nand_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
+{
+ struct nand_chip *chip = mtd_to_nand(mtd);
+ u8 feature[ONFI_SUBFEATURE_PARAM_LEN] = {0};
+ int ret;
+
+ feature[0] = MXIC_BLOCK_PROTECTION_ALL_LOCK;
+ nand_select_target(chip, 0);
+ ret = nand_set_features(chip, ONFI_FEATURE_ADDR_MXIC_PROTECTION,
+ feature);
+ nand_deselect_target(chip);
+ if (ret)
+ pr_err("Lock MXIC NAND all blocks failed, err:%d\n", ret);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(mxic_nand_lock);
+
+int mxic_nand_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
+{
+ struct nand_chip *chip = mtd_to_nand(mtd);
+ u8 feature[ONFI_SUBFEATURE_PARAM_LEN] = {0};
+ int ret;
+
+ feature[0] = MXIC_BLOCK_PROTECTION_ALL_UNLOCK;
+ nand_select_target(chip, 0);
+ ret = nand_set_features(chip, ONFI_FEATURE_ADDR_MXIC_PROTECTION,
+ feature);
+ nand_deselect_target(chip);
+ if (ret)
+ pr_err("Unlock MXIC NAND all blocks failed, err:%d\n", ret);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(mxic_nand_unlock);
diff --git a/include/linux/mfd/mxic-mx25f0a.h b/include/linux/mfd/mxic-mx25f0a.h
index 5a8cfc7..cfce992 100644
--- a/include/linux/mfd/mxic-mx25f0a.h
+++ b/include/linux/mfd/mxic-mx25f0a.h
@@ -170,4 +170,7 @@ struct mx25f0a_mfd {
void __iomem *dirmap;
};
+int mxic_nand_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len);
+int mxic_nand_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len);
+
#endif // __MFD_MXIC_MX25F0A_H
--
1.9.1
[PATCH 4/7] dt-bindings: mfd: Document Macronix MX25F0A controller bindings
Document the bindings used by the Macronix MX25F0A MFD controller.
Signed-off-by: Mason Yang
---
.../devicetree/bindings/mfd/mxic-mx25f0a.txt | 66 ++
1 file changed, 66 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/mxic-mx25f0a.txt
diff --git a/Documentation/devicetree/bindings/mfd/mxic-mx25f0a.txt
b/Documentation/devicetree/bindings/mfd/mxic-mx25f0a.txt
new file mode 100644
index 000..53b4839
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/mxic-mx25f0a.txt
@@ -0,0 +1,66 @@
+Macronix MX25F0A Multi-Function Device Tree Bindings
+
+
+MX25F0A is a MultiFunction Device with SPI and raw NAND, which
+supports either spi host controller or raw nand controller.
+
+Required properties:
+- compatible: should be "mxic,mx25f0a-mfd"
+- #address-cells: should be 1
+- #size-cells: should be 0
+- reg: should contain 2 entries, one for the registers and one for the direct
+ mapping area in SPI mode.
+- reg-names: should contain "regs" and "dirmap"
+- interrupts: interrupt line connected to this MFD controller
+
+Required nodes:
+ - spi :
+ Node for configuring the SPI controller driver.
+ Required properties:
+ - compatible = "mxicy,mx25f0a-spi";
+ - clock-names: should contain "ps_clk", "send_clk" and
+ "send_dly_clk"
+ - clocks: should contain 3 entries for the "ps_clk", "send_clk"
+ and "send_dly_clk" clocks
+
+- nand :
+ Node for configuring the raw nand controller driver.
+ Required properties:
+ - compatible = "mxicy,mx25f0a-nand-ctlr";
+ - nand-ecc-mode = "soft";
+ - nand-ecc-algo = "bch";
+
+Example:
+
+ mxic: mx25f0a-mfd@43c3 {
+ compatible = "mxic,mx25f0a-mfd";
+ reg = <0x43c3 0x1>, <0xa000 0x400>;
+ reg-names = "regs", "dirmap";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* either spi or nand */
+ spi {
+ compatible = "mxicy,mx25f0a-spi";
+ clocks = < 0>, < 1>, < 15>;
+ clock-names = "send_clk", "send_dly_clk", "ps_clk";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <2500>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ };
+ };
+
+ nand {
+ compatible = "mxicy,mx25f0a-nand-ctlr";
+ nand-ecc-mode = "soft";
+ nand-ecc-algo = "bch";
+ nand-ecc-step-size = <512>;
+ nand-ecc-strength = <8>;
+ };
+ };
--
1.9.1
[PATCH RFC 1/1] gnss: get serial speed from subdrivers
The default serial speed was hardcoded in the code.
Rename current-speed to default-speed.
Add a function parameter that lets the subdrivers specify their
default speed.
If not specified fallback to the device-tree default-speed.
Signed-off-by: Loys Ollivier
---
drivers/gnss/mtk.c| 6 +-
drivers/gnss/serial.c | 21 +
drivers/gnss/serial.h | 3 ++-
drivers/gnss/ubx.c| 3 ++-
4 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/gnss/mtk.c b/drivers/gnss/mtk.c
index d1fc55560daf..a1a89f0cc75c 100644
--- a/drivers/gnss/mtk.c
+++ b/drivers/gnss/mtk.c
@@ -16,6 +16,10 @@
#include "serial.h"
+static uint serial_speed = 9600; /* Serial speed (baud rate) */
+module_param(serial_speed, uint, 0644);
+MODULE_PARM_DESC(serial_speed, "Serial baud rate (bit/s), (default = 9600)");
+
struct mtk_data {
struct regulator *vbackup;
struct regulator *vcc;
@@ -69,7 +73,7 @@ static int mtk_probe(struct serdev_device *serdev)
struct mtk_data *data;
int ret;
- gserial = gnss_serial_allocate(serdev, sizeof(*data));
+ gserial = gnss_serial_allocate(serdev, sizeof(*data), serial_speed);
if (IS_ERR(gserial)) {
ret = PTR_ERR(gserial);
return ret;
diff --git a/drivers/gnss/serial.c b/drivers/gnss/serial.c
index def64b36d994..706fc5b46811 100644
--- a/drivers/gnss/serial.c
+++ b/drivers/gnss/serial.c
@@ -103,17 +103,13 @@ static int gnss_serial_set_power(struct gnss_serial
*gserial,
return gserial->ops->set_power(gserial, state);
}
-/*
- * FIXME: need to provide subdriver defaults or separate dt parsing from
- * allocation.
- */
static int gnss_serial_parse_dt(struct serdev_device *serdev)
{
struct gnss_serial *gserial = serdev_device_get_drvdata(serdev);
struct device_node *node = serdev->dev.of_node;
- u32 speed = 4800;
+ uint speed;
- of_property_read_u32(node, "current-speed", );
+ of_property_read_u32(node, "default-speed", );
gserial->speed = speed;
@@ -121,7 +117,8 @@ static int gnss_serial_parse_dt(struct serdev_device
*serdev)
}
struct gnss_serial *gnss_serial_allocate(struct serdev_device *serdev,
- size_t data_size)
+size_t data_size,
+uint serial_speed)
{
struct gnss_serial *gserial;
struct gnss_device *gdev;
@@ -146,10 +143,18 @@ struct gnss_serial *gnss_serial_allocate(struct
serdev_device *serdev,
serdev_device_set_drvdata(serdev, gserial);
serdev_device_set_client_ops(serdev, _serial_serdev_ops);
- ret = gnss_serial_parse_dt(serdev);
+ /* Serial speed provided by subdriver takes precedence over dt*/
+ if (!serial_speed)
+ ret = gnss_serial_parse_dt(serdev);
+ else
+ gserial->speed = serial_speed;
+
if (ret)
goto err_put_device;
+ if (!gserial->speed)
+ return -EINVAL;
+
return gserial;
err_put_device:
diff --git a/drivers/gnss/serial.h b/drivers/gnss/serial.h
index 980ffdc86c2a..29212b57a739 100644
--- a/drivers/gnss/serial.h
+++ b/drivers/gnss/serial.h
@@ -33,7 +33,8 @@ struct gnss_serial_ops {
extern const struct dev_pm_ops gnss_serial_pm_ops;
struct gnss_serial *gnss_serial_allocate(struct serdev_device *gserial,
- size_t data_size);
+size_t data_size,
+uint serial_speed);
void gnss_serial_free(struct gnss_serial *gserial);
int gnss_serial_register(struct gnss_serial *gserial);
diff --git a/drivers/gnss/ubx.c b/drivers/gnss/ubx.c
index 12568aebb7f6..6cfcb2eebdfd 100644
--- a/drivers/gnss/ubx.c
+++ b/drivers/gnss/ubx.c
@@ -68,8 +68,9 @@ static int ubx_probe(struct serdev_device *serdev)
struct gnss_serial *gserial;
struct ubx_data *data;
int ret;
+ uint speed = 4800;
- gserial = gnss_serial_allocate(serdev, sizeof(*data));
+ gserial = gnss_serial_allocate(serdev, sizeof(*data), speed);
if (IS_ERR(gserial)) {
ret = PTR_ERR(gserial);
return ret;
--
2.7.4
[PATCH RFC 0/1] gnss: get serial speed from subdrivers
Hello, Here's a patch that moves the currently hardcoded, default serial speed to the subdrivers. If the default speed is not specified by the subdriver then it is read from the device tree. Please let me know what you think ! Cheers, Loys Loys Ollivier (1): gnss: get serial speed from subdrivers drivers/gnss/mtk.c| 6 +- drivers/gnss/serial.c | 21 + drivers/gnss/serial.h | 3 ++- drivers/gnss/ubx.c| 3 ++- 4 files changed, 22 insertions(+), 11 deletions(-) -- 2.7.4
Re: [PATCH 4/7] RISC-V: Update page tables to cover the whole linear mapping
On Thu, Mar 28, 2019 at 3:06 AM Logan Gunthorpe wrote:
>
> With the new virtual address changes in an earlier patch, we want the
> page tables to cover more of the linear mapping region. Instead of
> only mapping from PAGE_OFFSET and up, we instead map starting
> from an aligned version of va_pa_offset such that all of the physical
> address space will be mapped.
>
> Signed-off-by: Logan Gunthorpe
> Cc: Palmer Dabbelt
> Cc: Albert Ou
> Cc: Anup Patel
> Cc: Atish Patra
> Cc: Paul Walmsley
> Cc: Zong Li
> Cc: Mike Rapoport
> ---
> arch/riscv/kernel/setup.c | 1 -
> arch/riscv/mm/init.c | 27 +++
> 2 files changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> index ecb654f6a79e..8286df8be31a 100644
> --- a/arch/riscv/kernel/setup.c
> +++ b/arch/riscv/kernel/setup.c
> @@ -59,7 +59,6 @@ EXPORT_SYMBOL(empty_zero_page);
> /* The lucky hart to first increment this variable will boot the other cores
> */
> atomic_t hart_lottery;
> unsigned long boot_cpu_hartid;
> -
> void __init parse_dtb(unsigned int hartid, void *dtb)
> {
> if (early_init_dt_scan(__va(dtb)))
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index b9d50031e78f..315194557c3d 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -150,8 +150,8 @@ pgd_t swapper_pg_dir[PTRS_PER_PGD] __page_aligned_bss;
> pgd_t trampoline_pg_dir[PTRS_PER_PGD] __initdata __aligned(PAGE_SIZE);
>
> #ifndef __PAGETABLE_PMD_FOLDED
> -#define NUM_SWAPPER_PMDS ((uintptr_t)-PAGE_OFFSET >> PGDIR_SHIFT)
> -pmd_t swapper_pmd[PTRS_PER_PMD*((-PAGE_OFFSET)/PGDIR_SIZE)]
> __page_aligned_bss;
> +#define NUM_SWAPPER_PMDS ((uintptr_t)-VMALLOC_END >> PGDIR_SHIFT)
> +pmd_t swapper_pmd[PTRS_PER_PMD*((-VMALLOC_END)/PGDIR_SIZE)]
> __page_aligned_bss;
> pmd_t trampoline_pmd[PTRS_PER_PGD] __initdata __aligned(PAGE_SIZE);
> pmd_t fixmap_pmd[PTRS_PER_PMD] __page_aligned_bss;
> #endif
> @@ -180,13 +180,18 @@ asmlinkage void __init setup_vm(void)
> extern char _start;
> uintptr_t i;
> uintptr_t pa = (uintptr_t) &_start;
> + uintptr_t linear_start;
> + uintptr_t off;
> pgprot_t prot = __pgprot(pgprot_val(PAGE_KERNEL) | _PAGE_EXEC);
>
> va_pa_offset = PAGE_OFFSET - pa;
> pfn_base = PFN_DOWN(pa);
>
> + linear_start = ALIGN_DOWN(va_pa_offset, PGDIR_SIZE);
> + off = linear_start - va_pa_offset;
> +
> /* Sanity check alignment and size */
> - BUG_ON((PAGE_OFFSET % PGDIR_SIZE) != 0);
> + BUG_ON(linear_start <= VMALLOC_END);
> BUG_ON((pa % (PAGE_SIZE * PTRS_PER_PTE)) != 0);
>
> #ifndef __PAGETABLE_PMD_FOLDED
> @@ -195,15 +200,14 @@ asmlinkage void __init setup_vm(void)
> __pgprot(_PAGE_TABLE));
> trampoline_pmd[0] = pfn_pmd(PFN_DOWN(pa), prot);
>
> - for (i = 0; i < (-PAGE_OFFSET)/PGDIR_SIZE; ++i) {
> - size_t o = (PAGE_OFFSET >> PGDIR_SHIFT) % PTRS_PER_PGD + i;
> -
> + for (i = 0; i < (-linear_start)/PGDIR_SIZE; ++i) {
> + size_t o = (linear_start >> PGDIR_SHIFT) % PTRS_PER_PGD + i;
> swapper_pg_dir[o] =
> pfn_pgd(PFN_DOWN((uintptr_t)swapper_pmd) + i,
> __pgprot(_PAGE_TABLE));
> }
> for (i = 0; i < ARRAY_SIZE(swapper_pmd); i++)
> - swapper_pmd[i] = pfn_pmd(PFN_DOWN(pa + i * PMD_SIZE), prot);
> + swapper_pmd[i] = pfn_pmd(PFN_DOWN(off + i * PMD_SIZE), prot);
>
> swapper_pg_dir[(FIXADDR_START >> PGDIR_SHIFT) % PTRS_PER_PGD] =
> pfn_pgd(PFN_DOWN((uintptr_t)fixmap_pmd),
> @@ -215,11 +219,10 @@ asmlinkage void __init setup_vm(void)
> trampoline_pg_dir[(PAGE_OFFSET >> PGDIR_SHIFT) % PTRS_PER_PGD] =
> pfn_pgd(PFN_DOWN(pa), prot);
>
> - for (i = 0; i < (-PAGE_OFFSET)/PGDIR_SIZE; ++i) {
> - size_t o = (PAGE_OFFSET >> PGDIR_SHIFT) % PTRS_PER_PGD + i;
> -
> - swapper_pg_dir[o] =
> - pfn_pgd(PFN_DOWN(pa + i * PGDIR_SIZE), prot);
> + for (i = 0; i < (-linear_start)/PGDIR_SIZE; ++i) {
> + size_t o = (linear_start >> PGDIR_SHIFT) % PTRS_PER_PGD + i;
> + swapper_pg_dir[o] = pfn_pgd(PFN_DOWN(off + i * PGDIR_SIZE),
> + prot);
> }
>
> swapper_pg_dir[(FIXADDR_START >> PGDIR_SHIFT) % PTRS_PER_PGD] =
> --
> 2.20.1
>
I understand that this patch is inline with your virtual memory layout cleanup
but the way we map virtual memory in swapper_pg_dir is bound to change.
We should not be mapping complete virtual memory in swapper_pd_dir()
rather we should only map based on amount of RAM available.
Refer, https://www.lkml.org/lkml/2019/3/24/3
The setup_vm() should only map vmlinux_start to vmlinux_end plus the
FDT. Complete virtual memory mapping should be done after we have
done early parsing of FDT when we
Re: [PATCH net-next v5 16/22] ethtool: provide link settings and link modes in GET_SETTINGS request
On Wed, Mar 27, 2019 at 08:44:58PM -0700, Florian Fainelli wrote: > > > On 3/25/2019 10:08 AM, Michal Kubecek wrote: > > Implement GET_SETTINGS netlink request to get link settings and link mode > > information provided by ETHTOOL_GLINKSETTINGS ioctl command. > > > > The information in SET_SETTINGS message sent as reply is divided into two > > parts: autonegotiation, speed, duplex and supported, advertised and peer > > advertised link modes when ETH_SETTINGS_IM_LINKMODES flag is set in the > > request and other settings when ETH_SETTINGS_IM_LINKINFO is set. > > > > Send notification in the same format as the reply message when relevant > > fields are modified using the ioctl interface (ETHTOOL_SLINKSETTINGS or > > ETHTOOL_SSET command). > > > > Signed-off-by: Michal Kubecek > > --- > > [snip] > > > +ETHA_SETTINGS_DEV (nested)device identification > > +ETHA_SETTINGS_LINK_INFO(nested)link settings > > +ETHA_LINKINFO_PORT (u8)physical port > > +ETHA_LINKINFO_PHYADDR (u8)MDIO address of > > phy > > +ETHA_LINKINFO_TP_MDIX (u8)MDI(-X) status > > +ETHA_LINKINFO_TP_MDIX_CTRL (u8)MDI(-X) control > > +ETHA_LINKINFO_TRANSCEIVER (u8)transceiver > > +ETHA_SETTINGS_LINK_MODES (nested)link modes > > +ETHA_LINKMODES_AUTONEG (u8)autoneotiation > > status > > Typo: auto-negotiation status. Will fix, thanks. Michal
Re: [PATCH 1/4] ACPI/PPTT: Add function to return ACPI 6.3 Identical tokens
On Tue, Mar 26, 2019 at 11:40 PM Jeremy Linton wrote:
>
> ACPI 6.3 adds a flag to indicate that child nodes are all
> identical cores. This is useful to authoritatively determine
> if a set of (possibly offline) cores are identical or not.
>
> Since the flag doesn't give us a unique id we can generate
> one and use it to create bitmaps of sibling nodes, or simply
> in a loop to determine if a subset of cores are identical.
>
> Signed-off-by: Jeremy Linton
> ---
> drivers/acpi/pptt.c | 26 ++
> include/linux/acpi.h | 5 +
> 2 files changed, 31 insertions(+)
>
> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
> index 065c4fc245d1..472c95ec816b 100644
> --- a/drivers/acpi/pptt.c
> +++ b/drivers/acpi/pptt.c
> @@ -660,3 +660,29 @@ int find_acpi_cpu_topology_package(unsigned int cpu)
> return find_acpi_cpu_topology_tag(cpu, PPTT_ABORT_PACKAGE,
> ACPI_PPTT_PHYSICAL_PACKAGE);
> }
> +
> +/**
> + * find_acpi_cpu_topology_hetero_id() - Determine a unique implementation
Maybe "Get a core architecture tag"?
> + * @cpu: Kernel logical cpu number
s/logical cpu/logical CPU/ please.
> + *
> + * Determine a unique heterogeneous ID for the given CPU. CPUs with the same
> + * implementation should have matching IDs. Since this is a tree we can only
> + * detect implementations where the heterogeneous flag is the parent to all
> + * matching cores. AKA if a two socket machine has two different core types
> + * in each socket this will end up being represented as four unique core
> types
> + * rather than two.
I find it quite difficult to parse that comment, honestly.
AFAICS, the function returns a tag that will be the same for all cores
with the same architecture in one package. That is, if the package is
heterogeneous and there are two types of cores in it, there will be
two different tags. Is this correct?
> + *
> + * The returned ID can be used to group peers with identical implementation.
> + *
> + * The search terminates when a level is found with the identical
> implementation
> + * flag set or we reach a root node.
> + *
> + * Return: -ENOENT if the PPTT doesn't exist, or the cpu cannot be found.
> + * Otherwise returns a value which represents a group of identical cores
> + * similar to this cpu.
> + */
> +int find_acpi_cpu_topology_hetero_id(unsigned int cpu)
> +{
> + return find_acpi_cpu_topology_tag(cpu, PPTT_ABORT_PACKAGE,
> + ACPI_PPTT_ACPI_IDENTICAL);
> +}
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index d5dcebd7aad3..1444fb042898 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -1309,6 +1309,7 @@ static inline int lpit_read_residency_count_address(u64
> *address)
> #ifdef CONFIG_ACPI_PPTT
> int find_acpi_cpu_topology(unsigned int cpu, int level);
> int find_acpi_cpu_topology_package(unsigned int cpu);
> +int find_acpi_cpu_topology_hetero_id(unsigned int cpu);
> int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
> #else
> static inline int find_acpi_cpu_topology(unsigned int cpu, int level)
> @@ -1319,6 +1320,10 @@ static inline int
> find_acpi_cpu_topology_package(unsigned int cpu)
> {
> return -EINVAL;
> }
> +static int find_acpi_cpu_topology_hetero_id(unsigned int cpu)
> +{
> + return -EINVAL;
> +}
> static inline int find_acpi_cpu_cache_topology(unsigned int cpu, int level)
> {
> return -EINVAL;
> --
> 2.20.1
>
Misplaced driver_sysfs_remove in really_probe?
Hi,
since commit 1901fb2604fbcd53201f38725182ea807581159e
Author: Kay Sievers
Date: Sat Oct 7 21:55:55 2006 +0200
Driver core: fix "driver" symlink timing
driver_sysfs_remove seems to be misplaced in the fail path of
really_probe. When driver_sysfs_add fails (or anything which is
currently above it in dd.c -- be it pinctrl_bind_pins or
dev->bus->dma_configure), driver_sysfs_remove is called. Given
dev->driver is set, attempt to remove sysfs device and driver links is
performed, but it is supposed to fail, as the links do not exist yet.
I am dealing with a Syzkaller WARNING from SLE15-SP1 (4.12) which
corresponds to the described scenario. Perhaps Syzkaller fault-injected
a kzalloc failure to pinctrl_bind_pins as I cannot reproduce the report
at all:
> WARNING: CPU: 1 PID: 2091 at ../fs/kernfs/dir.c:1481
kernfs_remove_by_name_ns+0xfa/0x120 fs/kernfs/dir.c:1480
> Supported: No, Unreleased kernel
> CPU: 1 PID: 2091 Comm: systemd-udevd Not tainted 4.12.14-396-default
#1 SLE15-SP1 (unreleased)
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.12.0-0-ga698c89-prebuilt.qemu.org 04/01/2014
> task: 880053794fc0 task.stack: 880040ea
> RIP: 0010:kernfs_remove_by_name_ns+0xfa/0x120 fs/kernfs/dir.c:1480
> RSP: 0018:880040ea7488 EFLAGS: 00010282
> RAX: 002d RBX: RCX:
> RDX: 002d RSI: 1100081d4e48 RDI: ed00081d4e85
> RBP: a772a380 R08: R09:
> R10: aa1872c4 R11: R12:
> R13: R14: R15: 0037
> FS: 7f0d24dc0f80() GS:88005e08()
knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 0045c061 CR3: 3b878006 CR4: 00060ee0
> Call Trace:
> driver_sysfs_remove+0xb0/0x110 drivers/base/dd.c:290
> really_probe drivers/base/dd.c:433 [inline]
> driver_probe_device+0x2b3/0x1200 drivers/base/dd.c:530
> __driver_attach+0x1dc/0x280 drivers/base/dd.c:763
> bus_for_each_dev+0x146/0x1e0 drivers/base/bus.c:316
> bus_add_driver+0x40f/0x850 drivers/base/bus.c:710
> driver_register+0x1c9/0x410 drivers/base/driver.c:168
> __hid_register_driver+0x1e0/0x2d0 drivers/hid/hid-core.c:2974
> ? 0xc151
> do_one_initcall+0xb7/0x300 init/main.c:808
> do_init_module+0x23e/0x641 kernel/module.c:3515
> load_module+0x47d6/0x60b0 kernel/module.c:3867
> SYSC_finit_module+0x239/0x2a0 kernel/module.c:3980
> do_syscall_64+0x26c/0x6e0 arch/x86/entry/common.c:284
> entry_SYSCALL_64_after_hwframe+0x3d/0xa2
I believe it survived from 2.6.20 to the current tree.
Does it look correct to you? This should help IMO and if you agree I
will send a proper patch:
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -496,7 +496,7 @@ static int really_probe(struct device *dev, struct
device_driver *drv)
if (driver_sysfs_add(dev)) {
printk(KERN_ERR "%s: driver_sysfs_add(%s) failed\n",
__func__, dev_name(dev));
- goto probe_failed;
+ goto sysfs_failed;
}
if (dev->pm_domain && dev->pm_domain->activate) {
@@ -546,6 +546,8 @@ static int really_probe(struct device *dev, struct
device_driver *drv)
goto done;
probe_failed:
+ driver_sysfs_remove(dev);
+sysfs_failed:
arch_teardown_dma_ops(dev);
dma_failed:
if (dev->bus)
@@ -554,7 +556,6 @@ static int really_probe(struct device *dev, struct
device_driver *drv)
pinctrl_bind_failed:
device_links_no_driver(dev);
devres_release_all(dev);
- driver_sysfs_remove(dev);
dev->driver = NULL;
dev_set_drvdata(dev, NULL);
if (dev->pm_domain && dev->pm_domain->dismiss)
thanks,
--
js
suse labs
[PATCH -next] Input: uinput - Avoid Use-After-Free with udev lock
uinput_destroy_device() gets called from two places. In one place, uinput_ioctl_handler() it is protected under a lock udev->mutex but same is not true for other place inside uinput_release(). This can result in a race where udev device gets freed while it is in use. [ 160.093398] Call trace: [ 160.093417] kernfs_get+0x64/0x88 [ 160.093438] kernfs_new_node+0x94/0xc8 [ 160.093450] kernfs_create_dir_ns+0x44/0xfc [ 160.093463] sysfs_create_dir_ns+0xa8/0x130 [ 160.093479] kobject_add_internal+0x278/0x650 [ 160.093491] kobject_add_varg+0xe0/0x130 [ 160.093502] kobject_add+0x15c/0x1d0 [ 160.093518] device_add+0x2bc/0xde0 [ 160.093533] input_register_device+0x5f4/0xa0c [ 160.093547] uinput_ioctl_handler+0x1184/0x2198 [ 160.093560] uinput_ioctl+0x38/0x48 [ 160.093573] vfs_ioctl+0x7c/0xb4 [ 160.093585] do_vfs_ioctl+0x9ec/0x2350 [ 160.093597] SyS_ioctl+0x6c/0xa4 [ 160.093610] el0_svc_naked+0x34/0x38 [ 160.093621] ---[ end trace bccf0093cda2c538 ]--- [ 160.099041] = [ 160.107459] BUG kernfs_node_cache (Tainted: G S W O ): Object already free [ 160.115235] - [ 160.115235] [ 160.125151] Disabling lock debugging due to kernel taint [ 160.130626] INFO: Allocated in __kernfs_new_node+0x8c/0x3c0 age=11 cpu=2 pid=7098 [ 160.138314] kmem_cache_alloc+0x358/0x388 [ 160.142445] __kernfs_new_node+0x8c/0x3c0 [ 160.146590] kernfs_new_node+0x80/0xc8 [ 160.150462] kernfs_create_dir_ns+0x44/0xfc [ 160.154777] sysfs_create_dir_ns+0xa8/0x130 [ 160.158416] CPU5: update max cpu_capacity 1024 [ 160.159085] kobject_add_internal+0x278/0x650 [ 160.163567] kobject_add_varg+0xe0/0x130 [ 160.167606] kobject_add+0x15c/0x1d0 [ 160.168452] CPU5: update max cpu_capacity 780 [ 160.171287] get_device_parent+0x2d0/0x34c [ 160.175510] device_add+0x240/0xde0 [ 160.178371] CPU6: update max cpu_capacity 916 [ 160.179108] input_register_device+0x5f4/0xa0c [ 160.183686] uinput_ioctl_handler+0x1184/0x2198 [ 160.188346] uinput_ioctl+0x38/0x48 [ 160.191941] vfs_ioctl+0x7c/0xb4 [ 160.195261] do_vfs_ioctl+0x9ec/0x2350 [ 160.199111] SyS_ioctl+0x6c/0xa4 [ 160.202436] INFO: Freed in kernfs_put+0x2c8/0x434 age=14 cpu=0 pid=7096 [ 160.209230] kernfs_put+0x2c8/0x434 [ 160.212825] kobject_del+0x50/0xcc [ 160.216332] cleanup_glue_dir+0x124/0x16c [ 160.220456] device_del+0x55c/0x5c8 [ 160.224047] __input_unregister_device+0x274/0x2a8 [ 160.228974] input_unregister_device+0x90/0xd0 [ 160.233553] uinput_destroy_device+0x15c/0x1dc [ 160.238131] uinput_release+0x44/0x5c [ 160.241898] __fput+0x1f4/0x4e4 [ 160.245127] fput+0x20/0x2c [ 160.248358] task_work_run+0x9c/0x174 [ 160.252127] do_notify_resume+0x104/0x6bc [ 160.256253] work_pending+0x8/0x14 [ 160.259751] INFO: Slab 0xffbf0215ff00 objects=33 used=11 fp=0xffc0857ffd08 flags=0x8101 [ 160.268693] INFO: Object 0xffc0857ffd08 @offset=15624 fp=0xffc0857fefb0 [ 160.268693] [ 160.277721] Redzone ffc0857ffd00: bb bb bb bb bb bb bb bb [ 160.286656] Object ffc0857ffd08: 00 00 00 00 01 00 00 80 58 a2 37 45 c1 ff ff ff X.7E [ 160.296207] Object ffc0857ffd18: ae 21 10 0b 90 ff ff ff 20 fd 7f 85 c0 ff ff ff .!.. ... [ 160.305780] Object ffc0857ffd28: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 160.315342] Object ffc0857ffd38: 00 00 00 00 00 00 00 00 7d a3 25 69 00 00 00 00 }.%i [ 160.324896] Object ffc0857ffd48: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 160.334446] Object ffc0857ffd58: 80 c0 28 47 c1 ff ff ff 00 00 00 00 00 00 00 00 ..(G [ 160.344000] Object ffc0857ffd68: 80 4a ce d1 c0 ff ff ff dc 32 01 00 01 00 00 00 .J...2.. [ 160.353554] Object ffc0857ffd78: 11 00 ed 41 00 00 00 00 00 00 00 00 00 00 00 00 ...A [ 160.363099] Redzone ffc0857ffd88: bb bb bb bb bb bb bb bb [ 160.372032] Padding ffc0857ffee0: 5a 5a 5a 5a 5a 5a 5a 5a [ 160.378299] CPU6: update max cpu_capacity 780 [ 160.380971] CPU: 4 PID: 7098 Comm: syz-executor Tainted: G S B W O 4.14.98+ #1 So, avoid the race by taking a udev lock inside `uinput_release()`. Change-Id: I3bbb07589b7b6e0e1b3bea572b5eb4f6b09774d6 Signed-off-by: Mukesh Ojha Cc:Gaurav Kohli Cc:Peter Hutterer Cc:Martin Kepplinger Cc:"Paul E. McKenney" --- drivers/input/misc/uinput.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c index 26ec603f..a3fb3b1 100644 --- a/drivers/input/misc/uinput.c +++ b/drivers/input/misc/uinput.c @@ -714,9 +714,15 @@ static __poll_t uinput_poll(struct file *file, poll_table *wait) static int uinput_release(struct inode
Re: [PATCH AUTOSEL 5.0 009/262] i2c: sis630: correct format strings
> From: Louis Taylor > > [ Upstream commit 60f7691c624b41a05bfc3493d9b0519e7951b7ef ] > > When compiling with -Wformat, clang warns: > > drivers/i2c/busses/i2c-sis630.c:482:4: warning: format specifies type > 'unsigned short' but the argument has type 'int' [-Wformat] > smbus_base + SMB_STS, > ^~~~ > > drivers/i2c/busses/i2c-sis630.c:483:4: warning: format specifies type > 'unsigned short' but the argument has type 'int' [-Wformat] > smbus_base + SMB_STS + SIS630_SMB_IOREGION - 1); > ^~ > > drivers/i2c/busses/i2c-sis630.c:531:37: warning: format specifies type > 'unsigned short' but the argument has type 'int' [-Wformat] > "SMBus SIS630 adapter at %04hx", smbus_base + SMB_STS); > ~ ^~~~ Warning with unsupported compiler; not a "serious bug". Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH AUTOSEL 5.0 010/262] apparmor: fix double free when unpack of secmark rules fails
> From: John Johansen
>
> [ Upstream commit d8dbb581d4f86a2ac669c056fc71a28ebeb367f4 ]
>
> if secmark rules fail to unpack a double free happens resulting in
> the following oops
>
> Fixes: 9caafbe2b4cf ("apparmor: Parse secmark policy")
> Reported-by: Alex Murray
> Signed-off-by: John Johansen
> Signed-off-by: Sasha Levin
Acked-for-stable: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[BUG] net: core: netif_receive_skb_list() crash on non-standard ptypes forwarding
Hi Edward,
Seems like I've found another poisoned skb->next crash with
netif_receive_skb_list().
This is similar to the one than has been already fixed in 22f6bbb7bcfc
("net: use skb_list_del_init() to remove from RX sublists"). This one
however
applies only to non-standard ptypes (in my case -- ETH_P_XDSA).
I use simple VLAN NAT setup through nft. After switching my in-dev
driver to
netif_receive_skb_list(), system started to crash on forwarding:
[ 88.606777] CPU 0 Unable to handle kernel paging request at virtual
address 000e, epc == 80687078, ra == 8052cc7c
[ 88.618666] Oops[#1]:
[ 88.621196] CPU: 0 PID: 0 Comm: swapper Not tainted
5.1.0-rc2-dlink-00206-g4192a172-dirty #1473
[ 88.630885] $ 0 : 1400 0002 864d7850
[ 88.636709] $ 4 : 87c0ddf0 864d7800 87c0ddf0
[ 88.642526] $ 8 : 4960 0001 0001
[ 88.648342] $12 : c288617b dadbee27 25d17c41
[ 88.654159] $16 : 87c0ddf0 85cff080 8079 fffd
[ 88.659975] $20 : 80797b20 0001 864d7800
[ 88.665793] $24 : 8011e658
[ 88.671609] $28 : 8079 87c0dbc0 87cabf00 8052cc7c
[ 88.677427] Hi : 0003
[ 88.680622] Lo : 7b5b4220
[ 88.683840] epc : 80687078 vlan_dev_hard_start_xmit+0x1c/0x1a0
[ 88.690532] ra : 8052cc7c dev_hard_start_xmit+0xac/0x188
[ 88.696734] Status: 1404 IEp
[ 88.700422] Cause : 5008 (ExcCode 02)
[ 88.704874] BadVA : 000e
[ 88.708069] PrId : 0001a120 (MIPS interAptiv (multi))
[ 88.713005] Modules linked in:
[ 88.716407] Process swapper (pid: 0, threadinfo=(ptrval),
task=(ptrval), tls=)
[ 88.725219] Stack : 85f61c28 000e 8078 87c0ddf0
85cff080 8079 8052cc7c
[ 88.734529] 87cabf00 0001 85f5fb40 807b 864d7850
87cabf00 807d
[ 88.743839] 864d7800 8655f600 85cff080 87c1c000 006a
8052d96c
[ 88.753149] 807a 8057adb8 87c0dcc8 87c0dc50 85cfff08 0558
87cabf00 85f58c50
[ 88.762460] 0002 85f58c00 864d7800 80543308 fff4 0001
85f58c00 864d7800
[ 88.771770] ...
[ 88.774483] Call Trace:
[ 88.777199] [<80687078>] vlan_dev_hard_start_xmit+0x1c/0x1a0
[ 88.783504] [<8052cc7c>] dev_hard_start_xmit+0xac/0x188
[ 88.789326] [<8052d96c>] __dev_queue_xmit+0x6e8/0x7d4
[ 88.794955] [<805a8640>] ip_finish_output2+0x238/0x4d0
[ 88.800677] [<805ab6a0>] ip_output+0xc8/0x140
[ 88.805526] [<805a68f4>] ip_forward+0x364/0x560
[ 88.810567] [<805a4ff8>] ip_rcv+0x48/0xe4
[ 88.815030] [<80528d44>] __netif_receive_skb_one_core+0x44/0x58
[ 88.821635] [<8067f220>] dsa_switch_rcv+0x108/0x1ac
[ 88.827067] [<80528f80>] __netif_receive_skb_list_core+0x228/0x26c
[ 88.833951] [<8052ed84>] netif_receive_skb_list+0x1d4/0x394
[ 88.840160] [<80355a88>] lunar_rx_poll+0x38c/0x828
[ 88.845496] [<8052fa78>] net_rx_action+0x14c/0x3cc
[ 88.850835] [<806ad300>] __do_softirq+0x178/0x338
[ 88.856077] [<8012a2d4>] irq_exit+0xbc/0x100
[ 88.860846] [<802f8b70>] plat_irq_dispatch+0xc0/0x144
[ 88.866477] [<80105974>] handle_int+0x14c/0x158
[ 88.871516] [<806acfb0>] r4k_wait+0x30/0x40
[ 88.876462] Code: afb10014 8c8200a0 00803025 <9443000c> 94a20468
10620042 00a08025 9605046a
[ 88.887332]
[ 88.888982] ---[ end trace eb863d007da11cf1 ]---
[ 88.894122] Kernel panic - not syncing: Fatal exception in interrupt
[ 88.901202] ---[ end Kernel panic - not syncing: Fatal exception in
interrupt ]---
Some additional debug have showed that skb->next is poisoned on
dsa_switch_rcv()
-- ETH_P_XDSA ptype .func() callback. So when skb enters
dev_hard_start_xmit(),
function tries to "schedule" backpointer to list_head for transmitting.
Here's a working possible fix for that, not sure if it can break
anything
though.
diff --git a/net/core/dev.c b/net/core/dev.c
index 2b67f2aa59dd..fdcff29df915 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5014,8 +5014,10 @@ static inline void
__netif_receive_skb_list_ptype(struct list_head *head,
if (pt_prev->list_func != NULL)
pt_prev->list_func(head, pt_prev, orig_dev);
else
- list_for_each_entry_safe(skb, next, head, list)
+ list_for_each_entry_safe(skb, next, head, list) {
+ skb_list_del_init(skb);
pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
+ }
}
static void __netif_receive_skb_list_core(struct list_head *head, bool
pfmemalloc)
Maybe you could look into this and find another/better solution (or I
could
submit this one if that's pretty enough).
BTW, great work with netif_receive_skb_list() -- I've got 70 Mbps gain
(~15%)
on my setup in comparsion to napi_gro_receive().
Thanks,
Alexander.
Regards,
ᚷ ᛖ ᚢ ᚦ ᚠ ᚱ
[PATCH 2/3] PM / EM: Expose perf domain struct
In the current state, the perf_domain struct is fully defined only when
CONFIG_ENERGY_MODEL=y. Since we need to write code that compiles both
with or without that option in the thermal framework, make sure to
actually define the struct regardless of the config option. That allows
to avoid using stubbed accessor functions all the time in code paths
that use the EM.
Signed-off-by: Quentin Perret
---
include/linux/energy_model.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
index aa027f7bcb3e..fb32b86a467d 100644
--- a/include/linux/energy_model.h
+++ b/include/linux/energy_model.h
@@ -9,7 +9,6 @@
#include
#include
-#ifdef CONFIG_ENERGY_MODEL
/**
* em_cap_state - Capacity state of a performance domain
* @frequency: The CPU frequency in KHz, for consistency with CPUFreq
@@ -40,6 +39,7 @@ struct em_perf_domain {
unsigned long cpus[0];
};
+#ifdef CONFIG_ENERGY_MODEL
#define EM_CPU_MAX_POWER 0x
struct em_data_callback {
@@ -160,7 +160,6 @@ static inline int em_pd_nr_cap_states(struct em_perf_domain
*pd)
}
#else
-struct em_perf_domain {};
struct em_data_callback {};
#define EM_DATA_CB(_active_power_cb) { }
--
2.21.0
Re: [PATCH AUTOSEL 5.0 011/262] tracing: kdb: Fix ftdump to not sleep
> From: Douglas Anderson > > [ Upstream commit 31b265b3baaf55f209229888b7ffea523ddab366 ] > > As reported back in 2016-11 [1], the "ftdump" kdb command triggers a > BUG for "sleeping function called from invalid context". > > kdb's "ftdump" command wants to call ring_buffer_read_prepare() in > atomic context. A very simple solution for this is to add allocation > flags to ring_buffer_read_prepare() so kdb can call it without > triggering the allocation error. This patch does that. I see solution is simple, but now we have a loop with GFP_ATOMIC allocations inside. How many "tracing spus" is this expected to loop over? Will not it exhaust atomically available pages and reliably fail in common configurations? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[PATCH 0/3] cpu_cooling: Make IPA use PM_EM
The Intelligent Power Allocator (IPA) thermal governor uses an Energy Model (or EM) of the CPUs to re-distribute the power budget. To do so, it builds a table of tuples where the power values are computed using the 'dynamic-power-coefficient' DT property. All of this is done in and only for the thermal subsystem, and more specifically for CPUs -- the power of other types of devices is obtained differently. Recently, the CPU scheduler has seen the introduction of Energy Aware Scheduling (EAS) patches, which also rely on an EM of the CPUs. This EM, however, is managed by an independent framework, called PM_EM, aimed to be used by all kernel subsystems interested in the power consumed by CPUs, and not only the scheduler. This patch series follows this logic and removes the (now redundant) thermal-specific EM computation code to migrate IPA to use PM_EM instead. Doing so should have no visible functional impact for existing users of IPA since: - during the 5.1 development cycle, a series of patches [1] introduced in PM_OPP some infrastructure (dev_pm_opp_of_register_em()) enabling the registration of EMs in PM_EM using the DT property used by IPA; - the existing upstream cpufreq drivers marked with the 'CPUFREQ_IS_COOLING_DEV' flag all call dev_pm_opp_of_register_em(), which means they all support PM_EM (the only two exceptions are qoriq-cpufreq which doesn't in fact use an EM and scmi-cpufreq which already supports PM_EM without using the PM_OPP infrastructurei because it read power costs directly from firmware); So, migrating IPA to using PM_EM should effectively be just plumbing since for the existing IPA users the PM_EM tables will contain the exact same power values that IPA used to compute on its own until now. The only new dependency is to compile in CONFIG_ENERGY_MODEL. Why is this migration still a good thing ? For three main reasons. 1. it removes redundant code; 2. it introduces an abstraction layer between IPA and the EM computation. PM_EM offers to EAS and IPA (and potentially other clients) standardized EM tables and hides 'how' these tables have been obtained. PM_EM as of now supports power values either coming from the 'dynamic-power-coefficient' DT property or obtained directly from firmware using SCMI. The latter is a new feature for IPA and that comes 'for free' with the migration. This will also be true in the future every time PM_EM gets support for other ways of loading the EM. Moreover, PM_EM is documented and has a debugfs interface which should help adding support for new platforms. 3. it builds a consistent view of the EM of CPUs across kernel subsystems, which is a pre-requisite for any kind of future work aiming at a smarter power allocation using scheduler knowledge about the system for example. [1] https://lore.kernel.org/lkml/20190204110952.16025-1-quentin.per...@arm.com/ Quentin Perret (3): arm64: defconfig: Enable CONFIG_ENERGY_MODEL PM / EM: Expose perf domain struct thermal: cpu_cooling: Migrate to using the EM framework arch/arm64/configs/defconfig | 1 + drivers/thermal/cpu_cooling.c | 231 +++--- include/linux/energy_model.h | 3 +- 3 files changed, 77 insertions(+), 158 deletions(-) -- 2.21.0
[PATCH 1/3] arm64: defconfig: Enable CONFIG_ENERGY_MODEL
The recently introduced Energy Model (EM) framework manages power cost tables for the CPUs of the system. Its only user right now is the scheduler, in the context of Energy Aware Scheduling (EAS). However, the EM framework also offers a generic infrastructure that could replace subsystem-specific implementations of the same concepts, as this is the case in the thermal framework. So, in order to prepare the migration of the thermal subsystem to use the EM framework, enable it in the default arm64 defconfig, which is the most commonly used architecture for IPA. This will also compile-in all of the EAS code, although it won't be enabled by default -- EAS requires to use the 'schedutil' CPUFreq governor while arm64 defaults to 'performance'. Signed-off-by: Quentin Perret --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 2d9c39033c1a..3c09bdaaefd3 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -97,6 +97,7 @@ CONFIG_XEN=y CONFIG_COMPAT=y CONFIG_HIBERNATION=y CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y +CONFIG_ENERGY_MODEL=n CONFIG_ARM_CPUIDLE=y CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_STAT=y -- 2.21.0
[PATCH 3/3] thermal: cpu_cooling: Migrate to using the EM framework
The newly introduced Energy Model framework manages power cost tables in
a generic way. Moreover, it supports a several types of models since the
tables can come from DT or firmware (through SCMI) for example. On the
other hand, the cpu_cooling subsystem manages its own power cost tables
using only DT data.
In order to avoid the duplication of data in the kernel, and in order to
enable IPA with EMs coming from more than just DT, remove the private
tables from cpu_cooling.c and migrate it to using the centralized EM
framework.
The case where the thermal subsystem is used without an Energy Model
(cpufreq_cooling_ops) is handled by looking directly at CPUFreq's
frequency table which is already a dependency for cpu_cooling.c anyway.
Signed-off-by: Quentin Perret
---
drivers/thermal/cpu_cooling.c | 231 +++---
1 file changed, 75 insertions(+), 156 deletions(-)
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index f7c1f49ec87f..a74ec8269b7b 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
@@ -48,19 +49,6 @@
* ...
*/
-/**
- * struct freq_table - frequency table along with power entries
- * @frequency: frequency in KHz
- * @power: power in mW
- *
- * This structure is built when the cooling device registers and helps
- * in translating frequency to power and vice versa.
- */
-struct freq_table {
- u32 frequency;
- u32 power;
-};
-
/**
* struct time_in_idle - Idle time stats
* @time: previous reading of the absolute time that this cpu was idle
@@ -82,7 +70,7 @@ struct time_in_idle {
* frequency.
* @max_level: maximum cooling level. One less than total number of valid
* cpufreq frequencies.
- * @freq_table: Freq table in descending order of frequencies
+ * @em: Reference on the Energy Model of the device
* @cdev: thermal_cooling_device pointer to keep track of the
* registered cooling device.
* @policy: cpufreq policy.
@@ -98,7 +86,7 @@ struct cpufreq_cooling_device {
unsigned int cpufreq_state;
unsigned int clipped_freq;
unsigned int max_level;
- struct freq_table *freq_table; /* In descending order */
+ struct em_perf_domain *em;
struct thermal_cooling_device *cdev;
struct cpufreq_policy *policy;
struct list_head node;
@@ -121,14 +109,14 @@ static LIST_HEAD(cpufreq_cdev_list);
static unsigned long get_level(struct cpufreq_cooling_device *cpufreq_cdev,
unsigned int freq)
{
- struct freq_table *freq_table = cpufreq_cdev->freq_table;
- unsigned long level;
+ int i;
- for (level = 1; level <= cpufreq_cdev->max_level; level++)
- if (freq > freq_table[level].frequency)
+ for (i = cpufreq_cdev->max_level - 1; i >= 0; i--) {
+ if (freq > cpufreq_cdev->em->table[i].frequency)
break;
+ }
- return level - 1;
+ return cpufreq_cdev->max_level - i - 1;
}
/**
@@ -184,105 +172,30 @@ static int cpufreq_thermal_notifier(struct
notifier_block *nb,
return NOTIFY_OK;
}
-/**
- * update_freq_table() - Update the freq table with power numbers
- * @cpufreq_cdev: the cpufreq cooling device in which to update the table
- * @capacitance: dynamic power coefficient for these cpus
- *
- * Update the freq table with power numbers. This table will be used in
- * cpu_power_to_freq() and cpu_freq_to_power() to convert between power and
- * frequency efficiently. Power is stored in mW, frequency in KHz. The
- * resulting table is in descending order.
- *
- * Return: 0 on success, -EINVAL if there are no OPPs for any CPUs,
- * or -ENOMEM if we run out of memory.
- */
-static int update_freq_table(struct cpufreq_cooling_device *cpufreq_cdev,
-u32 capacitance)
-{
- struct freq_table *freq_table = cpufreq_cdev->freq_table;
- struct dev_pm_opp *opp;
- struct device *dev = NULL;
- int num_opps = 0, cpu = cpufreq_cdev->policy->cpu, i;
-
- dev = get_cpu_device(cpu);
- if (unlikely(!dev)) {
- dev_warn(_cdev->cdev->device,
-"No cpu device for cpu %d\n", cpu);
- return -ENODEV;
- }
-
- num_opps = dev_pm_opp_get_opp_count(dev);
- if (num_opps < 0)
- return num_opps;
-
- /*
-* The cpufreq table is also built from the OPP table and so the count
-* should match.
-*/
- if (num_opps != cpufreq_cdev->max_level + 1) {
- dev_warn(dev, "Number of OPPs not matching with max_levels\n");
- return -EINVAL;
- }
-
- for (i = 0; i <= cpufreq_cdev->max_level; i++) {
- unsigned long freq = freq_table[i].frequency * 1000;
- u32 freq_mhz = freq_table[i].frequency / 1000;
- u64
