Re: [PATCH] x86: mtrr: cyrix: Mark expected switch fall-through
On Mon, Aug 05, 2019 at 03:17:12PM -0500, Gustavo A. R. Silva wrote: > Mark switch cases where we are expecting to fall through. > > Fix the following warning (Building: i386_defconfig i386): > > arch/x86/kernel/cpu/mtrr/cyrix.c:99:6: warning: this statement may fall > through [-Wimplicit-fallthrough=] > > Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kees Cook -Kees > --- > arch/x86/kernel/cpu/mtrr/cyrix.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/kernel/cpu/mtrr/cyrix.c > b/arch/x86/kernel/cpu/mtrr/cyrix.c > index 4296c702a3f7..72182809b333 100644 > --- a/arch/x86/kernel/cpu/mtrr/cyrix.c > +++ b/arch/x86/kernel/cpu/mtrr/cyrix.c > @@ -98,6 +98,7 @@ cyrix_get_free_region(unsigned long base, unsigned long > size, int replace_reg) > case 7: > if (size < 0x40) > break; > + /* Else, fall through */ > case 6: > case 5: > case 4: > -- > 2.22.0 > -- Kees Cook
Re: [PATCH] x86/ptrace: Mark expected switch fall-through
On Mon, Aug 05, 2019 at 02:56:54PM -0500, Gustavo A. R. Silva wrote: > Mark switch cases where we are expecting to fall through. > > Fix the following warning (Building: allnoconfig i386): > > arch/x86/kernel/ptrace.c:202:6: warning: this statement may fall through > [-Wimplicit-fallthrough=] >if (unlikely(value == 0)) > ^ > arch/x86/kernel/ptrace.c:206:2: note: here > default: > ^~~ > > Signed-off-by: Gustavo A. R. Silva Reviewed-by: Kees Cook -Kees > --- > arch/x86/kernel/ptrace.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c > index 0fdbe89d0754..3c5bbe8e4120 100644 > --- a/arch/x86/kernel/ptrace.c > +++ b/arch/x86/kernel/ptrace.c > @@ -201,6 +201,7 @@ static int set_segment_reg(struct task_struct *task, > case offsetof(struct user_regs_struct, ss): > if (unlikely(value == 0)) > return -EIO; > + /* Else, fall through */ > > default: > *pt_regs_access(task_pt_regs(task), offset) = value; > -- > 2.22.0 > -- Kees Cook
Re: [PATCH] pcmcia: db1xxx_ss: Mark expected switch fall-throughs
On Mon, Aug 05, 2019 at 02:49:42PM -0500, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warnings (Building: db1xxx_defconfig mips):
>
> drivers/pcmcia/db1xxx_ss.c:257:3: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
> drivers/pcmcia/db1xxx_ss.c:269:3: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
>
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Kees Cook
-Kees
> ---
> drivers/pcmcia/db1xxx_ss.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/pcmcia/db1xxx_ss.c b/drivers/pcmcia/db1xxx_ss.c
> index eb6168e6ac43..590e594092f2 100644
> --- a/drivers/pcmcia/db1xxx_ss.c
> +++ b/drivers/pcmcia/db1xxx_ss.c
> @@ -255,8 +255,10 @@ static int db1x_pcmcia_configure(struct pcmcia_socket
> *skt,
> switch (state->Vcc) {
> case 50:
> ++v;
> + /* fall through */
> case 33:
> ++v;
> + /* fall through */
> case 0:
> break;
> default:
> @@ -267,9 +269,11 @@ static int db1x_pcmcia_configure(struct pcmcia_socket
> *skt,
> switch (state->Vpp) {
> case 12:
> ++p;
> + /* fall through */
> case 33:
> case 50:
> ++p;
> + /* fall through */
> case 0:
> break;
> default:
> --
> 2.22.0
>
--
Kees Cook
Re: [PATCH] page flags: prioritize kasan bits over last-cpuid
On Mon, Aug 05, 2019 at 09:57:59PM +0200, Arnd Bergmann wrote: > On Mon, Aug 5, 2019 at 8:52 PM Guenter Roeck wrote: > > On Mon, Aug 05, 2019 at 08:35:40PM +0200, Arnd Bergmann wrote: > > > On Mon, Aug 5, 2019 at 6:51 PM Guenter Roeck wrote: > > > > On Fri, Aug 02, 2019 at 09:49:02PM -0700, Arnd Bergmann wrote: > > > > > ARM64 randdconfig builds regularly run into a build error, especially > > > > > when NUMA_BALANCING and SPARSEMEM are enabled but not > > > > > SPARSEMEM_VMEMMAP: > > > > > > > > > > #error "KASAN: not enough bits in page flags for tag" > > > > > > > > > > The last-cpuid bits are already contitional on the available space, so > > > > > the result of the calculation is a bit random on whether they were > > > > > already left out or not. > > > > > > > > > > Adding the kasan tag bits before last-cpuid makes it much more likely > > > > > to > > > > > end up with a successful build here, and should be reliable for > > > > > randconfig at least, as long as that does not randomize NR_CPUS or > > > > > NODES_SHIFT but uses the defaults. > > > > > > > > > > In order for the modified check to not trigger in the x86 vdso32 code > > > > > where all constants are wrong (building with -m32), enclose all the > > > > > definitions with an #ifdef. > > > > > > > > > > > > > This results in > > > > > > > > ./include/linux/page-flags-layout.h:95:2: error: #error "Not enough > > > > bits in page flags" > > > > #error "Not enough bits in page flags" > > > > > > > > when trying to build mipsel64:fuloong2e_defconfig. > > > > > > Do you have my follow-up fix applied? > > > > > > https://ozlabs.org/~akpm/mmots/broken-out/page-flags-prioritize-kasan-bits-over-last-cpuid-fix.patch > > > > > > > No. I see the failure in next-20190729..next-20190805. > > > > I didn't try to apply that patch, but I don't see > > arch/mips/vdso/vdso.h in the tree. I only see > > > > arch/mips/include/asm/vdso.h > > arch/mips/include/asm/vdso/vdso.h > > > > Are you sure that your patch can be applied as-is ? > > Ah, right, we now have support for the generic vdso on mips, > so the file got moved from arch/mips/vdso/vdso.h to > arch/mips/include/asm/vdso/vdso.h > > Try applying it to the new location then. I think it should still apply, > but have not tried it. > Turns out it is applied there (it looks like it was merged into the original patch). But it doesn't help; the build failure is still there. Reverting "page flags: prioritize kasan bits over last-cpuid" on top of next-20190805 fixes the problem for me. Guenter
Re: [PATCH] ARC: unwind: Mark expected switch fall-throughs
On Mon, Aug 05, 2019 at 02:32:32PM -0500, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warnings (Building: haps_hs_defconfig arc):
>
> arch/arc/kernel/unwind.c:827:20: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
> arch/arc/kernel/unwind.c:836:20: warning: this statement may fall through
> [-Wimplicit-fallthrough=]
>
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Kees Cook
-Kees
> ---
> arch/arc/kernel/unwind.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arc/kernel/unwind.c b/arch/arc/kernel/unwind.c
> index c2663fce7f6c..445e4d702f43 100644
> --- a/arch/arc/kernel/unwind.c
> +++ b/arch/arc/kernel/unwind.c
> @@ -826,7 +826,7 @@ static int processCFI(const u8 *start, const u8 *end,
> unsigned long targetLoc,
> case DW_CFA_def_cfa:
> state->cfa.reg = get_uleb128(&ptr.p8, end);
> unw_debug("cfa_def_cfa: r%lu ", state->cfa.reg);
> - /*nobreak*/
> + /* fall through */
> case DW_CFA_def_cfa_offset:
> state->cfa.offs = get_uleb128(&ptr.p8, end);
> unw_debug("cfa_def_cfa_offset: 0x%lx ",
> @@ -834,7 +834,7 @@ static int processCFI(const u8 *start, const u8 *end,
> unsigned long targetLoc,
> break;
> case DW_CFA_def_cfa_sf:
> state->cfa.reg = get_uleb128(&ptr.p8, end);
> - /*nobreak */
> + /* fall through */
> case DW_CFA_def_cfa_offset_sf:
> state->cfa.offs = get_sleb128(&ptr.p8, end)
> * state->dataAlign;
> --
> 2.22.0
>
--
Kees Cook
Re: [PATCH 4.9 00/42] 4.9.188-stable review
On Mon, Aug 05, 2019 at 11:11:01PM +0300, Jari Ruusu wrote:
> Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.188 release.
>
> Peter Zijlstra's "x86/atomic: Fix smp_mb__{before,after}_atomic()"
> upstream commit 69d927bba39517d0980462efc051875b7f4db185 seems to
> be missing/lost from 4.9 and older stable kernels.
>
> That patch has 10 hunks, first one of those does not apply cleanly to
> 4.9 kernel because it attempts to modify Documentation/atomic_t.txt
> file which does not exist in older kernels. Other 9 hunks apply with
> small offsets and fuzz, but modifications find their correct places anyway.
> Those other 9 hunks are the important ones, first hunk can be ignored.
>
> Greg,
> Please take Peter Zijlstra's original patch and "force" apply it like this
> to 4.9 kernels:
>
> patch -p1 -f
> and for 4.4 kernels like this:
>
> cat ORIGINAL.patch | sed -e 's/__smp_mb__/smp_mb__/' | patch -p1 -f -l
Can you send properly backported and tested patches?
thanks,
greg k-h
Re: oom-killer
On Mon 05-08-19 21:04:53, Pankaj Suryawanshi wrote: > On Mon, Aug 5, 2019 at 5:35 PM Michal Hocko wrote: > > > > On Mon 05-08-19 13:56:20, Vlastimil Babka wrote: > > > On 8/5/19 1:24 PM, Michal Hocko wrote: > > > >> [ 727.954355] CPU: 0 PID: 56 Comm: kworker/u8:2 Tainted: P > > > >> O 4.14.65 #606 > > > > [...] > > > >> [ 728.029390] [] (oom_kill_process) from [] > > > >> (out_of_memory+0x140/0x368) > > > >> [ 728.037569] r10:0001 r9:c12169bc r8:0041 r7:c121e680 > > > >> r6:c1216588 r5:dd347d7c > [ 728.045392] r4:d5737080 > > > >> [ 728.047929] [] (out_of_memory) from [] > > > >> (__alloc_pages_nodemask+0x1178/0x124c) > > > >> [ 728.056798] r7:c141e7d0 r6:c12166a4 r5: r4:1155 > > > >> [ 728.062460] [] (__alloc_pages_nodemask) from [] > > > >> (copy_process.part.5+0x114/0x1a28) > > > >> [ 728.071764] r10: r9:dd358000 r8: r7:c1447e08 > > > >> r6:c1216588 r5:00808111 > > > >> [ 728.079587] r4:d1063c00 > > > >> [ 728.082119] [] (copy_process.part.5) from [] > > > >> (_do_fork+0xd0/0x464) > > > >> [ 728.090034] r10: r9: r8:dd008400 r7: > > > >> r6:c1216588 r5:d2d58ac0 > > > >> [ 728.097857] r4:00808111 > > > > > > > > The call trace tells that this is a fork (of a usermodhlper but that is > > > > not all that important. > > > > [...] > > > >> [ 728.260031] DMA free:17960kB min:16384kB low:25664kB high:29760kB > > > >> active_anon:3556kB inactive_anon:0kB active_file:280kB > > > >> inactive_file:28kB unevictable:0kB writepending:0kB present:458752kB > > > >> managed:422896kB mlocked:0kB kernel_stack:6496kB pagetables:9904kB > > > >> bounce:0kB free_pcp:348kB local_pcp:0kB free_cma:0kB > > > >> [ 728.287402] lowmem_reserve[]: 0 0 579 579 > > > > > > > > So this is the only usable zone and you are close to the min watermark > > > > which means that your system is under a serious memory pressure but not > > > > yet under OOM for order-0 request. The situation is not great though > > > > > > Looking at lowmem_reserve above, wonder if 579 applies here? What does > > > /proc/zoneinfo say? > > > What is lowmem_reserve[]: 0 0 579 579 ? This controls how much of memory from a lower zone you might an allocation request for a higher zone consume. E.g. __GFP_HIGHMEM is allowed to use both lowmem and highmem zones. It is preferable to use highmem zone because other requests are not allowed to use it. Please see __zone_watermark_ok for more details. > > This is GFP_KERNEL request essentially so there shouldn't be any lowmem > > reserve here, no? > > > Why only low 1G is accessible by kernel in 32-bit system ? https://www.kernel.org/doc/gorman/, https://lwn.net/Articles/75174/ and many more articles. In very short, the 32b virtual address space is quite small and it has to cover both the users space and the kernel. That is why we do split it into 3G reserved for userspace and 1G for kernel. Kernel can only access its 1G portion directly everything else has to be mapped explicitly (e.g. while data is copied). > My system configuration is :- > 3G/1G - vmsplit > vmalloc = 480M (I think vmalloc size will set your highmem ?) No, vmalloc is part of the 1GB kernel adress space. -- Michal Hocko SUSE Labs
Re: [RFC PATCH v3 00/16] Core scheduling v3
Hi, On Fri, Aug 02, 2019 at 11:37:15AM -0400 Julien Desfossez wrote: > We tested both Aaron's and Tim's patches and here are our results. > > Test setup: > - 2 1-thread sysbench, one running the cpu benchmark, the other one the > mem benchmark > - both started at the same time > - both are pinned on the same core (2 hardware threads) > - 10 30-seconds runs > - test script: https://paste.debian.net/plainh/834cf45c > - only showing the CPU events/sec (higher is better) > - tested 4 tag configurations: > - no tag > - sysbench mem untagged, sysbench cpu tagged > - sysbench mem tagged, sysbench cpu untagged > - both tagged with a different tag > - "Alone" is the sysbench CPU running alone on the core, no tag > - "nosmt" is both sysbench pinned on the same hardware thread, no tag > - "Tim's full patchset + sched" is an experiment with Tim's patchset > combined with Aaron's "hack patch" to get rid of the remaining deep > idle cases > - In all test cases, both tasks can run simultaneously (which was not > the case without those patches), but the standard deviation is a > pretty good indicator of the fairness/consistency. > > No tag > -- > TestAverage Stdev > Alone 1306.90 0.94 > nosmt 649.95 1.44 > Aaron's full patchset: 828.15 32.45 > Aaron's first 2 patches:832.12 36.53 > Aaron's 3rd patch alone:864.21 3.68 > Tim's full patchset:852.50 4.11 > Tim's full patchset + sched:852.59 8.25 > > Sysbench mem untagged, sysbench cpu tagged > -- > TestAverage Stdev > Alone 1306.90 0.94 > nosmt 649.95 1.44 > Aaron's full patchset: 586.06 1.77 > Aaron's first 2 patches:630.08 47.30 > Aaron's 3rd patch alone:1086.65 246.54 > Tim's full patchset:852.50 4.11 > Tim's full patchset + sched:390.49 15.76 > > Sysbench mem tagged, sysbench cpu untagged > -- > TestAverage Stdev > Alone 1306.90 0.94 > nosmt 649.95 1.44 > Aaron's full patchset: 583.77 3.52 > Aaron's first 2 patches:513.63 63.09 > Aaron's 3rd patch alone:1171.23 3.35 > Tim's full patchset:564.04 58.05 > Tim's full patchset + sched:1026.16 49.43 > > Both sysbench tagged > > TestAverage Stdev > Alone 1306.90 0.94 > nosmt 649.95 1.44 > Aaron's full patchset: 582.15 3.75 > Aaron's first 2 patches:561.07 91.61 > Aaron's 3rd patch alone:638.49 231.06 > Tim's full patchset:679.43 70.07 > Tim's full patchset + sched:664.34 210.14 > Sorry if I'm missing something obvious here but with only 2 processes of interest shouldn't one tagged and one untagged be about the same as both tagged? In both cases the 2 sysbenches should not be running on the core at the same time. There will be times when oher non-related threads could share the core with the untagged one. Is that enough to account for this difference? Thanks, Phil > So in terms of fairness, Aaron's full patchset is the most consistent, but > only > Tim's patchset performs better than nosmt in some conditions. > > Of course, this is one of the worst case scenario, as soon as we have > multithreaded applications on overcommitted systems, core scheduling performs > better than nosmt. > > Thanks, > > Julien --
Re: [PATCH v3] nvme-pci: Support shared tags across queues for Apple 2018 controllers
Ping ? I had another look today and I don't feel like mucking around with all the AQ size logic, AEN magic tag etc... just for that sake of that Apple gunk. I'm happy to have it give up IO tags, it doesn't seem to make much of a difference in practice anyway. But if you feel strongly about it, then I'll implement the "proper" way sometimes this week, adding a way to shrink the AQ down to something like 3 (one admin request, one async event (AEN), and the empty slot) by making a bunch of the constants involved variables instead. I don't feel too strongly about it. I think your patch is fine, so Acked-by: Keith Busch Should we pick this up for 5.3-rc? No, it's not a regression fix. Queue it up for 5.4 instead. OK, will queue it up for nvme-5.4 Doesn't apply.. Ben, can you please respin a patch that applies on nvme-5.4? http://git.infradead.org/nvme.git/shortlog/refs/heads/nvme-5.4
Re: [PATCH v2] net/mlx5e: Use refcount_t for refcount
On Mon, 2019-08-05 at 14:55 +0800, Chuhong Yuan wrote: > On Mon, Aug 5, 2019 at 2:13 PM Leon Romanovsky > wrote: > > On Sun, Aug 04, 2019 at 10:44:47PM +0800, Chuhong Yuan wrote: > > > On Sun, Aug 4, 2019 at 8:59 PM Leon Romanovsky > > > wrote: > > > > On Sat, Aug 03, 2019 at 12:48:28AM +0800, Chuhong Yuan wrote: > > > > > refcount_t is better for reference counters since its > > > > > implementation can prevent overflows. > > > > > So convert atomic_t ref counters to refcount_t. > > > > > > > > I'm not thrilled to see those automatic conversion patches, > > > > especially > > > > for flows which can't overflow. There is nothing wrong in using > > > > atomic_t > > > > type of variable, do you have in mind flow which will cause to > > > > overflow? > > > > > > > > Thanks > > > > > > I have to say that these patches are not done automatically... > > > Only the detection of problems is done by a script. > > > All conversions are done manually. > > > > Even worse, you need to audit usage of atomic_t and replace there > > it can overflow. > > > > > I am not sure whether the flow can cause an overflow. > > > > It can't. > > > > > But I think it is hard to ensure that a data path is impossible > > > to have problems in any cases including being attacked. > > > > It is not data path, and I doubt that such conversion will be > > allowed > > in data paths without proving that no performance regression is > > introduced. > > > So I think it is better to do this minor revision to prevent > > > potential risk, just like we have done in mlx5/core/cq.c. > > > > mlx5/core/cq.c is a different beast, refcount there means actual > > users > > of CQ which are limited in SW, so in theory, they have potential > > to be overflown. > > > > It is not the case here, there your are adding new port. > > There is nothing wrong with atomic_t. > > > > Thanks for your explanation! > I will pay attention to this point in similar cases. > But it seems that the semantic of refcount is not always as clear as > here... > Semantically speaking, there is nothing wrong with moving to refcount_t in the case of vxlan ports.. it also seems more accurate and will provide the type protection, even if it is not necessary. Please let me know what is the verdict here, i can apply this patch to net-next-mlx5. Thanks, Saeed.
Re: [PATCH] page flags: prioritize kasan bits over last-cpuid
On Mon, Aug 5, 2019 at 8:52 PM Guenter Roeck wrote: > On Mon, Aug 05, 2019 at 08:35:40PM +0200, Arnd Bergmann wrote: > > On Mon, Aug 5, 2019 at 6:51 PM Guenter Roeck wrote: > > > On Fri, Aug 02, 2019 at 09:49:02PM -0700, Arnd Bergmann wrote: > > > > ARM64 randdconfig builds regularly run into a build error, especially > > > > when NUMA_BALANCING and SPARSEMEM are enabled but not SPARSEMEM_VMEMMAP: > > > > > > > > #error "KASAN: not enough bits in page flags for tag" > > > > > > > > The last-cpuid bits are already contitional on the available space, so > > > > the result of the calculation is a bit random on whether they were > > > > already left out or not. > > > > > > > > Adding the kasan tag bits before last-cpuid makes it much more likely to > > > > end up with a successful build here, and should be reliable for > > > > randconfig at least, as long as that does not randomize NR_CPUS or > > > > NODES_SHIFT but uses the defaults. > > > > > > > > In order for the modified check to not trigger in the x86 vdso32 code > > > > where all constants are wrong (building with -m32), enclose all the > > > > definitions with an #ifdef. > > > > > > > > > > This results in > > > > > > ./include/linux/page-flags-layout.h:95:2: error: #error "Not enough bits > > > in page flags" > > > #error "Not enough bits in page flags" > > > > > > when trying to build mipsel64:fuloong2e_defconfig. > > > > Do you have my follow-up fix applied? > > > > https://ozlabs.org/~akpm/mmots/broken-out/page-flags-prioritize-kasan-bits-over-last-cpuid-fix.patch > > > > No. I see the failure in next-20190729..next-20190805. > > I didn't try to apply that patch, but I don't see > arch/mips/vdso/vdso.h in the tree. I only see > > arch/mips/include/asm/vdso.h > arch/mips/include/asm/vdso/vdso.h > > Are you sure that your patch can be applied as-is ? Ah, right, we now have support for the generic vdso on mips, so the file got moved from arch/mips/vdso/vdso.h to arch/mips/include/asm/vdso/vdso.h Try applying it to the new location then. I think it should still apply, but have not tried it. Arnd
[PATCH] x86/ptrace: Mark expected switch fall-through
Mark switch cases where we are expecting to fall through. Fix the following warning (Building: allnoconfig i386): arch/x86/kernel/ptrace.c:202:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (unlikely(value == 0)) ^ arch/x86/kernel/ptrace.c:206:2: note: here default: ^~~ Signed-off-by: Gustavo A. R. Silva --- arch/x86/kernel/ptrace.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c index 0fdbe89d0754..3c5bbe8e4120 100644 --- a/arch/x86/kernel/ptrace.c +++ b/arch/x86/kernel/ptrace.c @@ -201,6 +201,7 @@ static int set_segment_reg(struct task_struct *task, case offsetof(struct user_regs_struct, ss): if (unlikely(value == 0)) return -EIO; + /* Else, fall through */ default: *pt_regs_access(task_pt_regs(task), offset) = value; -- 2.22.0
Re: [PATCH v3] nvme-pci: Support shared tags across queues for Apple 2018 controllers
Ping ? I had another look today and I don't feel like mucking around with all the AQ size logic, AEN magic tag etc... just for that sake of that Apple gunk. I'm happy to have it give up IO tags, it doesn't seem to make much of a difference in practice anyway. But if you feel strongly about it, then I'll implement the "proper" way sometimes this week, adding a way to shrink the AQ down to something like 3 (one admin request, one async event (AEN), and the empty slot) by making a bunch of the constants involved variables instead. I don't feel too strongly about it. I think your patch is fine, so Acked-by: Keith Busch Should we pick this up for 5.3-rc? No, it's not a regression fix. Queue it up for 5.4 instead. OK, will queue it up for nvme-5.4
Re: [PATCH] linux/bits.h: Add compile time sanity check of GENMASK inputs
On Sun, Aug 04, 2019 at 03:45:16PM +0900, Masahiro Yamada wrote: > On Sun, Aug 4, 2019 at 3:36 AM Rikard Falkeborn > wrote: > > > > On Sat, Aug 03, 2019 at 12:12:46PM +0900, Masahiro Yamada wrote: > > > On Sat, Aug 3, 2019 at 12:03 PM Masahiro Yamada > > > wrote: > > > > > > > > > > > BTW, v2 is already inconsistent. > > > > If you wanted GENMASK_INPUT_CHECK() to return 'unsigned long',, > > > > you would have to cast (low) > (high) as well: > > > > > > > >(unsigned long)((low) > (high)), UL(0 > > > > > > > > This is totally redundant, and weird. > > > > > > I take back this comment. > > > You added (unsigned long) to the beginning of this macro. > > > So, the type is consistent, but I believe all casts should be removed. > > > > Maybe you're right. BUILD_BUG_ON_ZERO returns size_t regardless of > > inputs. I was worried that on some platform, size_t would be larger than > > unsigned long (as far as I could see, the standard does not give any > > guarantees), and thus all of a sudden GENMASK would be 8 bytes instead > > of 4, but perhaps that is not a problem? > > > How about adding (int) cast to BUILD_BUG_ON_ZERO() ? I'll have a look.
Re: [PATCH v2] mm: memcontrol: switch to rcu protection in drain_all_stock()
On Mon, Aug 05, 2019 at 01:11:35PM +0200, Michal Hocko wrote:
> On Fri 02-08-19 12:22:41, Roman Gushchin wrote:
> > Commit 72f0184c8a00 ("mm, memcg: remove hotplug locking from try_charge")
> > introduced css_tryget()/css_put() calls in drain_all_stock(),
> > which are supposed to protect the target memory cgroup from being
> > released during the mem_cgroup_is_descendant() call.
> >
> > However, it's not completely safe. In theory, memcg can go away
> > between reading stock->cached pointer and calling css_tryget().
> >
> > This can happen if drain_all_stock() races with drain_local_stock()
> > performed on the remote cpu as a result of a work, scheduled
> > by the previous invocation of drain_all_stock().
>
> Maybe I am still missing something but I do not see how 72f0184c8a00
> changed the existing race. get_online_cpus doesn't prevent the same race
> right? If this is the case then it would be great to clarify that. I
> know that you are mostly after clarifying that css_tryget is
> insufficient but the above sounds like 72f0184c8a00 has introduced a
> regression.
Yeah, I'm not blaming 72f0184c8a00 for the race, which as I said,
is barely reproducible at all. There is no "Fixes" tag, and I don't think
we need to backport it to stable.
Let's think about this patch as a refactoring patch, which makes the code
cleaner.
>
> > The race is a bit theoretical and there are few chances to trigger
> > it, but the current code looks a bit confusing, so it makes sense
> > to fix it anyway. The code looks like as if css_tryget() and
> > css_put() are used to protect stocks drainage. It's not necessary
> > because stocked pages are holding references to the cached cgroup.
> > And it obviously won't work for works, scheduled on other cpus.
> >
> > So, let's read the stock->cached pointer and evaluate the memory
> > cgroup inside a rcu read section, and get rid of
> > css_tryget()/css_put() calls.
> >
> > v2: added some explanations to the commit message, no code changes
> >
> > Signed-off-by: Roman Gushchin
> > Cc: Michal Hocko
> > Cc: Hillf Danton
>
> Other than that.
> Acked-by: Michal Hocko
Thanks!
[PATCH] pcmcia: db1xxx_ss: Mark expected switch fall-throughs
Mark switch cases where we are expecting to fall through.
This patch fixes the following warnings (Building: db1xxx_defconfig mips):
drivers/pcmcia/db1xxx_ss.c:257:3: warning: this statement may fall through
[-Wimplicit-fallthrough=]
drivers/pcmcia/db1xxx_ss.c:269:3: warning: this statement may fall through
[-Wimplicit-fallthrough=]
Signed-off-by: Gustavo A. R. Silva
---
drivers/pcmcia/db1xxx_ss.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/pcmcia/db1xxx_ss.c b/drivers/pcmcia/db1xxx_ss.c
index eb6168e6ac43..590e594092f2 100644
--- a/drivers/pcmcia/db1xxx_ss.c
+++ b/drivers/pcmcia/db1xxx_ss.c
@@ -255,8 +255,10 @@ static int db1x_pcmcia_configure(struct pcmcia_socket *skt,
switch (state->Vcc) {
case 50:
++v;
+ /* fall through */
case 33:
++v;
+ /* fall through */
case 0:
break;
default:
@@ -267,9 +269,11 @@ static int db1x_pcmcia_configure(struct pcmcia_socket *skt,
switch (state->Vpp) {
case 12:
++p;
+ /* fall through */
case 33:
case 50:
++p;
+ /* fall through */
case 0:
break;
default:
--
2.22.0
[PATCH] power: supply: ab8500_charger: Mark expected switch fall-through
Mark switch cases where we are expecting to fall through. This patch fixes the following warning (Building: allmodconfig arm): drivers/power/supply/ab8500_charger.c:738:6: warning: this statement may fall through [-Wimplicit-fallthrough=] Signed-off-by: Gustavo A. R. Silva --- drivers/power/supply/ab8500_charger.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/power/supply/ab8500_charger.c b/drivers/power/supply/ab8500_charger.c index 30de448de802..1be75a2fed9b 100644 --- a/drivers/power/supply/ab8500_charger.c +++ b/drivers/power/supply/ab8500_charger.c @@ -742,6 +742,7 @@ static int ab8500_charger_max_usb_curr(struct ab8500_charger *di, USB_CH_IP_CUR_LVL_1P5; break; } + /* else, fall through */ case USB_STAT_HM_IDGND: dev_err(di->dev, "USB Type - Charging not allowed\n"); di->max_usb_in_curr.usb_type_max = USB_CH_IP_CUR_LVL_0P05; -- 2.22.0
Re: Issue with sequence to switch to HS400
No problem. Thanks Al On Tue, Jul 30, 2019 at 4:00 AM Adrian Hunter wrote: > > On 26/07/19 12:37 AM, Alan Cooper wrote: > > That's an even better solution and it gets my HS400 mode working. > > Will you add this change or should I? > > You, if you wouldn't mind. > > > > > Thanks > > Al > > > > On Thu, Jul 25, 2019 at 3:33 AM Adrian Hunter > > wrote: > >> > >> On 23/07/19 3:34 PM, Alan Cooper wrote: > >>> On Tue, Jul 23, 2019 at 1:21 AM Adrian Hunter > >>> wrote: > > On 23/07/19 1:31 AM, Alan Cooper wrote: > > I'm having a problem with a new SD/MMC controller and PHY in our > > latest SoC's. The issue I'm seeing is that I can't switch into HS400 > > mode. This looks like something the driver is doing that doesn't meet > > the JEDEC spec. In the "HS400 timing mode selection" section of the > > JEDEC spec , in step 7 it states: > > > > 7) Set the “Timing Interface” parameter in the HS_TIMING [185] field > > of the Extended CSD register to 0x1 to switch to High Speed mode and > > then set the clock frequency to a value not greater than 52 MHz. > > > > In the function mmc_select_hs400() in mmc.c, I see that a switch > > command is done to set the eMMC device to HS mode and then > > mmc_set_timing(card->host, MMC_TIMING_MMC_HS) is used to change the > > controller to HS mode. The problem is that the "SD Host Controller > > Standard Specification" states that "UHS Mode Select" field of the > > "Host Control 2 Register" controls the mode when the "1.8V Signaling > > Enable" bit in the same register is set, so mmc_set_timing() is > > actually leaving the controller in SDR12 mode and mmc_select_hs400() > > will then set the clock to 52MHz. This causes our PHY to detect an > > illegal combination and return an error. > > > > I think the easiest fix would be to change mmc_set_timing(card->host, > > MMC_TIMING_MMC_HS) to mmc_set_timing(card->host, > > MMC_TIMING_UHS_SDR25). The other possibility would be to change > > mmc_set_timing to handle the "1.8V Signaling Enable" bit properly. > > I'll submit a patch based on the feedback I get. > > eMMC is governed by JEDEC specs not SD specs. > >>> > >>> My understanding is that JEDEC does not have a host controller spec so > >>> this driver uses the "SD Host Controller Standard Specification". > >> > >> There is no spec for using eMMC with SDHCI. > >> > >>> > > Please consider making a change in your driver instead. For example, > hook > ->set_ios() and if 1.8V is enabled and timing is set to MMC_TIMING_MMC_HS > then change it to MMC_TIMING_UHS_SDR25. > >>> > >>> That's an easy fix, but it still leaves all other drivers/systems > >>> temporarily using SDR12 at 52MHz during the switch to HS400. > >> > >> Yes, I changed my mind. Does this work: > >> > >> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c > >> index 59acf8e3331e..f9d241458dcd 100644 > >> --- a/drivers/mmc/host/sdhci.c > >> +++ b/drivers/mmc/host/sdhci.c > >> @@ -1849,7 +1849,9 @@ void sdhci_set_uhs_signaling(struct sdhci_host > >> *host, unsigned timing) > >> ctrl_2 |= SDHCI_CTRL_UHS_SDR104; > >> else if (timing == MMC_TIMING_UHS_SDR12) > >> ctrl_2 |= SDHCI_CTRL_UHS_SDR12; > >> - else if (timing == MMC_TIMING_UHS_SDR25) > >> + else if (timing == MMC_TIMING_SD_HS || > >> +timing == MMC_TIMING_MMC_HS || > >> +timing == MMC_TIMING_UHS_SDR25) > >> ctrl_2 |= SDHCI_CTRL_UHS_SDR25; > >> else if (timing == MMC_TIMING_UHS_SDR50) > >> ctrl_2 |= SDHCI_CTRL_UHS_SDR50; > > >
Re: [PATCH] mm: workingset: fix vmstat counters for shadow nodes
On Thu, Aug 01, 2019 at 04:35:32PM -0700, Roman Gushchin wrote:
> Memcg counters for shadow nodes are broken because the memcg pointer is
> obtained in a wrong way. The following approach is used:
> virt_to_page(xa_node)->mem_cgroup
>
> Since commit 4d96ba353075 ("mm: memcg/slab: stop setting page->mem_cgroup
> pointer for slab pages") page->mem_cgroup pointer isn't set for slab pages,
> so memcg_from_slab_page() should be used instead.
>
> Also I doubt that it ever worked correctly: virt_to_head_page() should be
> used instead of virt_to_page(). Otherwise objects residing on tail pages
> are not accounted, because only the head page contains a valid mem_cgroup
> pointer. That was a case since the introduction of these counters by the
> commit 68d48e6a2df5 ("mm: workingset: add vmstat counter for shadow nodes").
You're right. slub uses order-2 compound pages for radix_tree_node, so
we've been underreporting shadow nodes placed in the three tail pages.
Nice catch.
> Fixes: 4d96ba353075 ("mm: memcg/slab: stop setting page->mem_cgroup pointer
> for slab pages")
> Signed-off-by: Roman Gushchin
> Cc: Johannes Weiner
> Cc: Andrew Morton
Acked-by: Johannes Weiner
[PATCH] tty: serial: Introduce uart_tx_stoppped_or_empty()
The vast majority of the serial drivers check for
uart_tx_stopped(&p->port) || uart_circ_empty(xmit)
condition one or more times. Create a dedicated helper function and
convert drivers to use it.
Signed-off-by: Andrey Smirnov
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Chris Healy
Cc: linux-ser...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Looks like lpuart_stopped_or_empty() helper function I created for
fsl_lpuart.c can be useful in a lot of drivers, so this patch makes it
into a generic function.
Thanks,
Andrey Smirnov
drivers/tty/serial/21285.c | 2 +-
drivers/tty/serial/8250/8250_dma.c | 2 +-
drivers/tty/serial/8250/8250_omap.c | 7 +++
drivers/tty/serial/amba-pl010.c | 2 +-
drivers/tty/serial/amba-pl011.c | 6 +++---
drivers/tty/serial/apbuart.c| 2 +-
drivers/tty/serial/atmel_serial.c | 6 +++---
drivers/tty/serial/clps711x.c | 2 +-
drivers/tty/serial/cpm_uart/cpm_uart_core.c | 2 +-
drivers/tty/serial/digicolor-usart.c| 2 +-
drivers/tty/serial/dz.c | 2 +-
drivers/tty/serial/efm32-uart.c | 2 +-
drivers/tty/serial/fsl_lpuart.c | 15 +--
drivers/tty/serial/imx.c| 7 +++
drivers/tty/serial/ioc3_serial.c| 2 +-
drivers/tty/serial/ioc4_serial.c| 2 +-
drivers/tty/serial/lpc32xx_hs.c | 2 +-
drivers/tty/serial/max3100.c| 6 ++
drivers/tty/serial/max310x.c| 2 +-
drivers/tty/serial/milbeaut_usio.c | 2 +-
drivers/tty/serial/mpc52xx_uart.c | 2 +-
drivers/tty/serial/mps2-uart.c | 2 +-
drivers/tty/serial/msm_serial.c | 2 +-
drivers/tty/serial/mux.c| 2 +-
drivers/tty/serial/mvebu-uart.c | 2 +-
drivers/tty/serial/mxs-auart.c | 4 ++--
drivers/tty/serial/omap-serial.c| 2 +-
drivers/tty/serial/pch_uart.c | 2 +-
drivers/tty/serial/pnx8xxx_uart.c | 2 +-
drivers/tty/serial/pxa.c| 2 +-
drivers/tty/serial/sa1100.c | 2 +-
drivers/tty/serial/samsung.c| 2 +-
drivers/tty/serial/sb1250-duart.c | 2 +-
drivers/tty/serial/sc16is7xx.c | 2 +-
drivers/tty/serial/sccnxp.c | 2 +-
drivers/tty/serial/serial_ks8695.c | 2 +-
drivers/tty/serial/serial_txx9.c| 2 +-
drivers/tty/serial/sifive.c | 2 +-
drivers/tty/serial/sirfsoc_uart.c | 4 ++--
drivers/tty/serial/sn_console.c | 2 +-
drivers/tty/serial/sprd_serial.c| 5 ++---
drivers/tty/serial/stm32-usart.c| 2 +-
drivers/tty/serial/sunhv.c | 2 +-
drivers/tty/serial/sunsab.c | 4 ++--
drivers/tty/serial/timbuart.c | 2 +-
drivers/tty/serial/uartlite.c | 2 +-
drivers/tty/serial/ucc_uart.c | 2 +-
drivers/tty/serial/vr41xx_siu.c | 2 +-
drivers/tty/serial/vt8500_serial.c | 2 +-
drivers/tty/serial/zs.c | 2 +-
include/linux/serial_core.h | 5 +
51 files changed, 72 insertions(+), 77 deletions(-)
diff --git a/drivers/tty/serial/21285.c b/drivers/tty/serial/21285.c
index 32b3acf8150a..f46d5ee8cbb9 100644
--- a/drivers/tty/serial/21285.c
+++ b/drivers/tty/serial/21285.c
@@ -128,7 +128,7 @@ static irqreturn_t serial21285_tx_chars(int irq, void
*dev_id)
port->x_char = 0;
goto out;
}
- if (uart_circ_empty(xmit) || uart_tx_stopped(port)) {
+ if (uart_tx_stopped_or_empty(port)) {
serial21285_stop_tx(port);
goto out;
}
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index 890fa7ddaa7f..65cc7bea62ef 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -69,7 +69,7 @@ int serial8250_tx_dma(struct uart_8250_port *p)
if (dma->tx_running)
return 0;
- if (uart_tx_stopped(&p->port) || uart_circ_empty(xmit)) {
+ if (uart_tx_stopped_or_empty(&p->port)) {
/* We have been called from __dma_tx_complete() */
serial8250_rpm_put_tx(p);
return 0;
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index c68e2b3a1634..baf47a50e26d 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -920,7 +920,7 @@ static void omap_8250_dma_tx_complete(void *param)
if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
uart_write_wakeup(&p->port);
- if (!uart_circ_empty(xmit) && !uart_tx_stopped(&p->port)) {
+ if (!uart_tx_stopped_or_empty(&p->port)) {
int ret;
[PATCH] ARC: unwind: Mark expected switch fall-throughs
Mark switch cases where we are expecting to fall through.
This patch fixes the following warnings (Building: haps_hs_defconfig arc):
arch/arc/kernel/unwind.c:827:20: warning: this statement may fall through
[-Wimplicit-fallthrough=]
arch/arc/kernel/unwind.c:836:20: warning: this statement may fall through
[-Wimplicit-fallthrough=]
Signed-off-by: Gustavo A. R. Silva
---
arch/arc/kernel/unwind.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arc/kernel/unwind.c b/arch/arc/kernel/unwind.c
index c2663fce7f6c..445e4d702f43 100644
--- a/arch/arc/kernel/unwind.c
+++ b/arch/arc/kernel/unwind.c
@@ -826,7 +826,7 @@ static int processCFI(const u8 *start, const u8 *end,
unsigned long targetLoc,
case DW_CFA_def_cfa:
state->cfa.reg = get_uleb128(&ptr.p8, end);
unw_debug("cfa_def_cfa: r%lu ", state->cfa.reg);
- /*nobreak*/
+ /* fall through */
case DW_CFA_def_cfa_offset:
state->cfa.offs = get_uleb128(&ptr.p8, end);
unw_debug("cfa_def_cfa_offset: 0x%lx ",
@@ -834,7 +834,7 @@ static int processCFI(const u8 *start, const u8 *end,
unsigned long targetLoc,
break;
case DW_CFA_def_cfa_sf:
state->cfa.reg = get_uleb128(&ptr.p8, end);
- /*nobreak */
+ /* fall through */
case DW_CFA_def_cfa_offset_sf:
state->cfa.offs = get_sleb128(&ptr.p8, end)
* state->dataAlign;
--
2.22.0
Re: Let's talk about the elephant in the room - the Linux kernel's inability to gracefully handle low memory pressure
On Mon, Aug 05, 2019 at 02:13:16PM +0200, Vlastimil Babka wrote: > On 8/4/19 11:23 AM, Artem S. Tashkinov wrote: > > Hello, > > > > There's this bug which has been bugging many people for many years > > already and which is reproducible in less than a few minutes under the > > latest and greatest kernel, 5.2.6. All the kernel parameters are set to > > defaults. > > > > Steps to reproduce: > > > > 1) Boot with mem=4G > > 2) Disable swap to make everything faster (sudo swapoff -a) > > 3) Launch a web browser, e.g. Chrome/Chromium or/and Firefox > > 4) Start opening tabs in either of them and watch your free RAM decrease > > > > Once you hit a situation when opening a new tab requires more RAM than > > is currently available, the system will stall hard. You will barely be > > able to move the mouse pointer. Your disk LED will be flashing > > incessantly (I'm not entirely sure why). You will not be able to run new > > applications or close currently running ones. > > > This little crisis may continue for minutes or even longer. I think > > that's not how the system should behave in this situation. I believe > > something must be done about that to avoid this stall. > > Yeah that's a known problem, made worse SSD's in fact, as they are able > to keep refaulting the last remaining file pages fast enough, so there > is still apparent progress in reclaim and OOM doesn't kick in. > > At this point, the likely solution will be probably based on pressure > stall monitoring (PSI). I don't know how far we are from a built-in > monitor with reasonable defaults for a desktop workload, so CCing > relevant folks. Yes, psi was specifically developed to address this problem. Before it, the kernel had to make all decisions based on relative event rates but had no notion of time. Whereas to the user, time is clearly an issue, and in fact makes all the difference. So psi quantifies the time the workload spends executing vs. spinning its wheels. But choosing a universal cutoff for killing is not possible, since it depends on the workload and the user's expectation: GUI and other latency-sensitive applications care way before a compile job or video encoding would care. Because of that, there are things like oomd and lmkd as mentioned, to leave the exact policy decision to userspace. That being said, I think we should be able to provide a bare minimum inside the kernel to avoid complete livelocks where the user does not believe the machine would be able to recover without a reboot. The goal wouldn't be a glitch-free user experience - the kernel does not know enough about the applications to even attempt that. It should just not hang indefinitely. Maybe similar to the hung task detector. How about something like the below patch? With that, the kernel catches excessive thrashing that happens before reclaim fails: [root@ham ~]# stress -d 128 -m 5 stress: info: [344] dispatching hogs: 0 cpu, 0 io, 5 vm, 128 hdd Excessive and sustained system-wide memory pressure! kworker/1:2 invoked oom-killer: gfp_mask=0x0(), order=0, oom_score_adj=0 CPU: 1 PID: 77 Comm: kworker/1:2 Not tainted 5.3.0-rc1-mm1-00121-ge34a5cf28771 #142 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-20181126_142135-anatol 04/01/2014 Workqueue: events psi_avgs_work Call Trace: dump_stack+0x46/0x60 dump_header+0x5c/0x3d5 ? irq_work_queue+0x46/0x50 ? wake_up_klogd+0x2b/0x30 ? vprintk_emit+0xe5/0x190 oom_kill_process.cold.10+0xb/0x10 out_of_memory+0x1ea/0x260 update_averages.cold.8+0x14/0x25 ? collect_percpu_times+0x84/0x1f0 psi_avgs_work+0x80/0xc0 process_one_work+0x1bb/0x310 worker_thread+0x28/0x3c0 ? process_one_work+0x310/0x310 kthread+0x108/0x120 ? __kthread_create_on_node+0x170/0x170 ret_from_fork+0x35/0x40 Mem-Info: active_anon:109463 inactive_anon:109564 isolated_anon:298 active_file:4676 inactive_file:4073 isolated_file:455 unevictable:0 dirty:8475 writeback:8 unstable:0 slab_reclaimable:2585 slab_unreclaimable:4932 mapped:413 shmem:2 pagetables:1747 bounce:0 free:13472 free_pcp:17 free_cma:0 Possible snags and questions: 1. psi is an optional feature right now, but these livelocks commonly affect desktop users. What should be the default behavior? 2. Should we make the pressure cutoff and time period configurable? I fear we would open a can of worms similar to the existing OOM killer, where users are trying to use a kernel self-protection mechanism to implement workload QoS and priorities - things that should firmly be kept in userspace. 3. swapoff annotation. Due to the swapin annotation, swapoff currently raises memory pressure. It probably shouldn't. But this will be a bigger problem if we trigger the oom killer based on it. 4. Killing once every 10s assumes basically one big culprit. If the pressure is created by many different processes, fixing the situation could take quite a while. What oomd does to solve this is to monitor the PGSCAN counters after a kill, to t
Re: [GIT PULL] SafeSetID MAINTAINERS file update for v5.3
On Mon, Aug 05, 2019 at 12:17:49PM -0700, Linus Torvalds wrote: However, I suspect that getting message-ids for all your pull requests would significantly complicate your workflow. Yeah, that would be a noticeable annoyance. If I were to process pull requests the way I used to process emailed patches (ie "git am -s" on a mailbox) that would be a natural thing to perhaps do, but it's not at all how it ends up working. Having to save the pull request email to then process it with some script would turn it into a chore. I think the pr-tracker-bot clearly catches most cases as it is, and it's only the occasional "somebody did something odd" that then misses an automated response. Not a huge deal. For me it was actually more the "I didn't understand why the response didn't happen", not so much "I really want to always see responses". Ok, let me add a fix for Re: at the start -- this won't make things significantly more expensive, but will catch this particular corner case. Best regards, -K
Re: [PATCH RFC] mm/memcontrol: reclaim severe usage over high limit in get_user_pages loop
On Mon, Aug 5, 2019 at 7:32 AM Michal Hocko wrote: > > On Fri 02-08-19 11:56:28, Yang Shi wrote: > > On Fri, Aug 2, 2019 at 2:35 AM Michal Hocko wrote: > > > > > > On Thu 01-08-19 14:00:51, Yang Shi wrote: > > > > On Mon, Jul 29, 2019 at 11:48 AM Michal Hocko wrote: > > > > > > > > > > On Mon 29-07-19 10:28:43, Yang Shi wrote: > > > > > [...] > > > > > > I don't worry too much about scale since the scale issue is not > > > > > > unique > > > > > > to background reclaim, direct reclaim may run into the same problem. > > > > > > > > > > Just to clarify. By scaling problem I mean 1:1 kswapd thread to memcg. > > > > > You can have thousands of memcgs and I do not think we really do want > > > > > to create one kswapd for each. Once we have a kswapd thread pool then > > > > > we > > > > > get into a tricky land where a determinism/fairness would be non > > > > > trivial > > > > > to achieve. Direct reclaim, on the other hand is bound by the workload > > > > > itself. > > > > > > > > Yes, I agree thread pool would introduce more latency than dedicated > > > > kswapd thread. But, it looks not that bad in our test. When memory > > > > allocation is fast, even though dedicated kswapd thread can't catch > > > > up. So, such background reclaim is best effort, not guaranteed. > > > > > > > > I don't quite get what you mean about fairness. Do you mean they may > > > > spend excessive cpu time then cause other processes starvation? I > > > > think this could be mitigated by properly organizing and setting > > > > groups. But, I agree this is tricky. > > > > > > No, I meant that the cost of reclaiming a unit of charges (e.g. > > > SWAP_CLUSTER_MAX) is not constant and depends on the state of the memory > > > on LRUs. Therefore any thread pool mechanism would lead to unfair > > > reclaim and non-deterministic behavior. > > > > Yes, the cost depends on the state of pages, but I still don't quite > > understand what does "unfair" refer to in this context. Do you mean > > some cgroups may reclaim much more than others? > > > Or the work may take too long so it can't not serve other cgroups in time? > > exactly. > How about allowing the users to implement their own user space kswapd? A memcg interface similar to MADV_PAGEOUT. Users can register for MEMCG_HIGH notification (it needs some modification) and on receiving the notification, the uswapd (User's kswapd) will trigger reclaim through memory.pageout (or memory.try_to_free_pages). One can argue why not just use MADV_PAGEOUT? In real workload, a job can be a combination of different sub-jobs and most probably may not know the importance of the memory layout of the tasks of the sub-jobs. So, a memcg level interface makes more sense there. Shakeel
Re: [RESEND PATCH v5 4/4] mailbox: imx: add support for imx v1 mu
On Mon, Aug 5, 2019 at 8:16 AM Richard Zhu wrote:
>
> There is a version 1.0 MU on i.MX7ULP platform.
> One new version ID register is added, and it's offset is 0.
> TRn registers are defined at the offset 0x20 ~ 0x2C.
> RRn registers are defined at the offset 0x40 ~ 0x4C.
> SR/CR registers are defined at 0x60/0x64.
> Extend this driver to support it.
>
> Signed-off-by: Richard Zhu
> Suggested-by: Oleksij Rempel
> Reviewed-by: Dong Aisheng
> Reviewed-by: Oleksij Rempel
Very clean solution. Thanks Richard!
Reviewed-by: Daniel Baluta
> ---
> drivers/mailbox/imx-mailbox.c | 55
> ++-
> 1 file changed, 38 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
> index afe625e..2cdcdc5 100644
> --- a/drivers/mailbox/imx-mailbox.c
> +++ b/drivers/mailbox/imx-mailbox.c
> @@ -12,19 +12,11 @@
> #include
> #include
>
> -/* Transmit Register */
> -#define IMX_MU_xTRn(x) (0x00 + 4 * (x))
> -/* Receive Register */
> -#define IMX_MU_xRRn(x) (0x10 + 4 * (x))
> -/* Status Register */
> -#define IMX_MU_xSR 0x20
> #define IMX_MU_xSR_GIPn(x) BIT(28 + (3 - (x)))
> #define IMX_MU_xSR_RFn(x) BIT(24 + (3 - (x)))
> #define IMX_MU_xSR_TEn(x) BIT(20 + (3 - (x)))
> #define IMX_MU_xSR_BRDIP BIT(9)
>
> -/* Control Register */
> -#define IMX_MU_xCR 0x24
> /* General Purpose Interrupt Enable */
> #define IMX_MU_xCR_GIEn(x) BIT(28 + (3 - (x)))
> /* Receive Interrupt Enable */
> @@ -44,6 +36,13 @@ enum imx_mu_chan_type {
> IMX_MU_TYPE_RXDB, /* Rx doorbell */
> };
>
> +struct imx_mu_dcfg {
> + u32 xTR[4]; /* Transmit Registers */
> + u32 xRR[4]; /* Receive Registers */
> + u32 xSR;/* Status Register */
> + u32 xCR;/* Control Register */
> +};
> +
> struct imx_mu_con_priv {
> unsigned intidx;
> charirq_desc[IMX_MU_CHAN_NAME_SIZE];
> @@ -61,12 +60,27 @@ struct imx_mu_priv {
> struct mbox_chanmbox_chans[IMX_MU_CHANS];
>
> struct imx_mu_con_priv con_priv[IMX_MU_CHANS];
> + const struct imx_mu_dcfg*dcfg;
> struct clk *clk;
> int irq;
>
> boolside_b;
> };
>
> +static const struct imx_mu_dcfg imx_mu_cfg_imx6sx = {
> + .xTR= {0x0, 0x4, 0x8, 0xc},
> + .xRR= {0x10, 0x14, 0x18, 0x1c},
> + .xSR= 0x20,
> + .xCR= 0x24,
> +};
> +
> +static const struct imx_mu_dcfg imx_mu_cfg_imx7ulp = {
> + .xTR= {0x20, 0x24, 0x28, 0x2c},
> + .xRR= {0x40, 0x44, 0x48, 0x4c},
> + .xSR= 0x60,
> + .xCR= 0x64,
> +};
> +
> static struct imx_mu_priv *to_imx_mu_priv(struct mbox_controller *mbox)
> {
> return container_of(mbox, struct imx_mu_priv, mbox);
> @@ -88,10 +102,10 @@ static u32 imx_mu_xcr_rmw(struct imx_mu_priv *priv, u32
> set, u32 clr)
> u32 val;
>
> spin_lock_irqsave(&priv->xcr_lock, flags);
> - val = imx_mu_read(priv, IMX_MU_xCR);
> + val = imx_mu_read(priv, priv->dcfg->xCR);
> val &= ~clr;
> val |= set;
> - imx_mu_write(priv, val, IMX_MU_xCR);
> + imx_mu_write(priv, val, priv->dcfg->xCR);
> spin_unlock_irqrestore(&priv->xcr_lock, flags);
>
> return val;
> @@ -111,8 +125,8 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
> struct imx_mu_con_priv *cp = chan->con_priv;
> u32 val, ctrl, dat;
>
> - ctrl = imx_mu_read(priv, IMX_MU_xCR);
> - val = imx_mu_read(priv, IMX_MU_xSR);
> + ctrl = imx_mu_read(priv, priv->dcfg->xCR);
> + val = imx_mu_read(priv, priv->dcfg->xSR);
>
> switch (cp->type) {
> case IMX_MU_TYPE_TX:
> @@ -138,10 +152,10 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
> imx_mu_xcr_rmw(priv, 0, IMX_MU_xCR_TIEn(cp->idx));
> mbox_chan_txdone(chan, 0);
> } else if (val == IMX_MU_xSR_RFn(cp->idx)) {
> - dat = imx_mu_read(priv, IMX_MU_xRRn(cp->idx));
> + dat = imx_mu_read(priv, priv->dcfg->xRR[cp->idx]);
> mbox_chan_received_data(chan, (void *)&dat);
> } else if (val == IMX_MU_xSR_GIPn(cp->idx)) {
> - imx_mu_write(priv, IMX_MU_xSR_GIPn(cp->idx), IMX_MU_xSR);
> + imx_mu_write(priv, IMX_MU_xSR_GIPn(cp->idx), priv->dcfg->xSR);
> mbox_chan_received_data(chan, NULL);
> } else {
> dev_warn_ratelimited(priv->dev, "Not handled interrupt\n");
> @@ -159,7 +173,7 @@ static int imx_mu_send_data(struct mbox_chan *chan, void
> *data)
>
> switch (cp->type) {
> case IMX_MU_TYPE_TX:
> - imx_mu_write(priv, *arg, IMX_MU_xTRn(cp->idx));
> + imx_mu_write(priv, *arg, priv->dcfg->xTR[cp->idx]);
> imx_mu_xcr_rmw(priv,
Re: [RESEND PATCH v5 3/4] dt-bindings: mailbox: imx-mu: add imx7ulp MU support
+ Rob On Mon, Aug 5, 2019 at 8:18 AM Richard Zhu wrote: > > There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu" compatible > to support it. > > Signed-off-by: Richard Zhu > Reviewed-by: Dong Aisheng Reviewed-by: Daniel Baluta > --- > Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > index f3cf77e..9c43357 100644 > --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > @@ -21,6 +21,8 @@ Required properties: > imx6sx, imx7s, imx8qxp, imx8qm. > The "fsl,imx6sx-mu" compatible is seen as generic and should > be included together with SoC specific compatible. > + There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu" > + compatible to support it. > - reg :Should contain the registers location and length > - interrupts : Interrupt number. The interrupt specifier format depends > on the interrupt controller parent. > -- > 2.7.4 >
Re: [alsa-devel] [RFC PATCH 28/40] soundwire: intel: handle disabled links
On 8/5/19 11:57 AM, Sanyog Kale wrote:
On Thu, Jul 25, 2019 at 06:40:20PM -0500, Pierre-Louis Bossart wrote:
On most hardware platforms, SoundWire interfaces are pin-muxed with
other interfaces (typically DMIC or I2S) and the status of each link
needs to be checked at boot time.
For Intel platforms, the BIOS provides a menu to enable/disable the
links separately, and the information is provided to the OS with an
Intel-specific _DSD property. The same capability will be added to
revisions of the MIPI DisCo specification.
[snip]
diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h
index c7dfc824be80..f78b076a8782 100644
--- a/include/linux/soundwire/sdw.h
+++ b/include/linux/soundwire/sdw.h
@@ -380,6 +380,7 @@ struct sdw_slave_prop {
* @err_threshold: Number of times that software may retry sending a single
* command
* @mclk_freq: clock reference passed to SoundWire Master, in Hz.
+ * @hw_disabled: if true, the Master is not functional, typically due to
pin-mux
*/
struct sdw_master_prop {
u32 revision;
@@ -395,6 +396,7 @@ struct sdw_master_prop {
bool dynamic_frame;
u32 err_threshold;
u32 mclk_freq;
+ bool hw_disabled;
Do we have such cases where some of SoundWire links are disabled and
some enabled?
Yes, by default my ICL test board uses HDaudio for the codec so the
SoundWire link0 is disabled. If I rework the board and change the BIOS
advanced menu then SoundWire link0 is enabled. This information is
dynamically provided to the OS after the _INI step.
SoundWire-2/3 are used typically for attached DMICs or for a combination
of SoundWire amplifier and mic capture. It's really platform-specific.
};
int sdw_master_read_prop(struct sdw_bus *bus);
--
2.20.1
Re: [GIT PULL] SafeSetID MAINTAINERS file update for v5.3
On Mon, Aug 5, 2019 at 12:11 PM Konstantin Ryabitsev wrote: > > However, I suspect that getting message-ids for all your pull requests > would significantly complicate your workflow. Yeah, that would be a noticeable annoyance. If I were to process pull requests the way I used to process emailed patches (ie "git am -s" on a mailbox) that would be a natural thing to perhaps do, but it's not at all how it ends up working. Having to save the pull request email to then process it with some script would turn it into a chore. I think the pr-tracker-bot clearly catches most cases as it is, and it's only the occasional "somebody did something odd" that then misses an automated response. Not a huge deal. For me it was actually more the "I didn't understand why the response didn't happen", not so much "I really want to always see responses". Linus
Re: [PATCH 1/2] ARM: dts: meson8b: add the nvmem cell with the board's MAC address
On Mon, Jul 29, 2019 at 11:45 PM Martin Blumenstingl
wrote:
>
> On Mon, Jul 29, 2019 at 9:11 AM Neil Armstrong
> wrote:
> >
> > Hi Martin,
> >
> > On 27/07/2019 21:46, Martin Blumenstingl wrote:
> > > Amlogic's BSP kernel defines that all boards with a MAC address stored
> > > in the eFuse have it at offset 0x1b4. It is up to the board to
> > > decide whether to use this MAC address or not:
> > > - Odroid-C1 uses the MAC address from the eFuse
> > > - EC-100 seems to read the MAC address from eMMC
> > >
> > > Add the nvmem cell which describes the Ethernet MAC address. Don't
> > > assign it to the Ethernet controller, because depending on the board the
> > > actual MAC address may be read from somewhere else.
> > >
> > > Signed-off-by: Martin Blumenstingl
> > > ---
> > > arch/arm/boot/dts/meson8b.dtsi | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/meson8b.dtsi
> > > b/arch/arm/boot/dts/meson8b.dtsi
> > > index 30fca9bb4bbe..c7de58b71d08 100644
> > > --- a/arch/arm/boot/dts/meson8b.dtsi
> > > +++ b/arch/arm/boot/dts/meson8b.dtsi
> > > @@ -402,6 +402,10 @@
> > > clocks = <&clkc CLKID_EFUSE>;
> > > clock-names = "core";
> > >
> > > + ethernet_mac_address: mac@1b4 {
> > > + reg = <0x1b4 0x6>;
> > > + };
> >
> > Is this a fixed position for all boards ? if not, I'll suggest moving
> > it to the odroid-c1 dt until you have more users.
> the 0x1b4 offset is hardcoded in Amlogic's kernel sources
> if some board uses another offset then the manufacturer had to patch
> the kernel to make it work (like Endless did)
>
> +Cc hexdump0815 - can you please run the following command on your
> Meson8b MXQ board:
> $ hexdump -C /sys/bus/nvmem/devices/meson8b-efuse0/nvmem | grep
> 01b0 | cut -d' ' -f7,8,9,10,12,13
>
> this should print the MAC address that is also used by the stock
> firmware and/or printed on the board
> if it is then I'm happy to provide a patch also for your MXQ board so
> it also uses the correct MAC address
hexdump got back to me on IRC (thank you!) with unfortunate news:
the MXQ board doesn't seem to have the MAC address in the eFuse at all
thus I'll go with Neil's suggestion and move this to meson8b-odroidc1.dts
Martin
Re: [PATCH] MIPS: BCM63XX: Mark expected switch fall-through
On Mon, 2019-08-05 at 13:55 -0500, Gustavo A. R. Silva wrote: > Mark switch cases where we are expecting to fall through. > > This patch fixes the following warning (Building: bcm63xx_defconfig mips): > > arch/mips/pci/ops-bcm63xx.c: In function ‘bcm63xx_pcie_can_access’: > arch/mips/pci/ops-bcm63xx.c:474:6: warning: this statement may fall through > [-Wimplicit-fallthrough=] >if (PCI_SLOT(devfn) == 0) > ^ > arch/mips/pci/ops-bcm63xx.c:477:2: note: here > default: > ^~~ > > Signed-off-by: Gustavo A. R. Silva > --- > arch/mips/pci/ops-bcm63xx.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/mips/pci/ops-bcm63xx.c b/arch/mips/pci/ops-bcm63xx.c > index d02eb9d16b55..925c72348fb6 100644 > --- a/arch/mips/pci/ops-bcm63xx.c > +++ b/arch/mips/pci/ops-bcm63xx.c > @@ -474,6 +474,7 @@ static int bcm63xx_pcie_can_access(struct pci_bus *bus, > int devfn) > if (PCI_SLOT(devfn) == 0) > return bcm_pcie_readl(PCIE_DLSTATUS_REG) > & DLSTATUS_PHYLINKUP; > + /* else, fall through */ > default: > return false; > } Perhaps clearer as: --- arch/mips/pci/ops-bcm63xx.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/arch/mips/pci/ops-bcm63xx.c b/arch/mips/pci/ops-bcm63xx.c index d02eb9d16b55..a5e4b1905958 100644 --- a/arch/mips/pci/ops-bcm63xx.c +++ b/arch/mips/pci/ops-bcm63xx.c @@ -471,12 +471,11 @@ static int bcm63xx_pcie_can_access(struct pci_bus *bus, int devfn) case PCIE_BUS_BRIDGE: return PCI_SLOT(devfn) == 0; case PCIE_BUS_DEVICE: - if (PCI_SLOT(devfn) == 0) - return bcm_pcie_readl(PCIE_DLSTATUS_REG) - & DLSTATUS_PHYLINKUP; - default: - return false; + return PCI_SLOT(devfn) == 0 && + bcm_pcie_readl(PCIE_DLSTATUS_REG) & DLSTATUS_PHYLINKUP; } + + return false; } static int bcm63xx_pcie_read(struct pci_bus *bus, unsigned int devfn,
Re: [Regression] Commit "nvme/pci: Use host managed power state for suspend" has problems
at 19:04, Rafael J. Wysocki wrote: On Fri, Aug 2, 2019 at 12:55 PM Kai-Heng Feng wrote: at 06:26, Rafael J. Wysocki wrote: On Thu, Aug 1, 2019 at 9:05 PM wrote: -Original Message- From: Rafael J. Wysocki Sent: Thursday, August 1, 2019 12:30 PM To: Kai-Heng Feng; Keith Busch; Limonciello, Mario Cc: Keith Busch; Christoph Hellwig; Sagi Grimberg; linux-nvme; Linux PM; Linux Kernel Mailing List; Rajat Jain Subject: Re: [Regression] Commit "nvme/pci: Use host managed power state for suspend" has problems [EXTERNAL EMAIL] On Thu, Aug 1, 2019 at 11:06 AM Kai-Heng Feng wrote: at 06:33, Rafael J. Wysocki wrote: On Thu, Aug 1, 2019 at 12:22 AM Keith Busch wrote: On Wed, Jul 31, 2019 at 11:25:51PM +0200, Rafael J. Wysocki wrote: A couple of remarks if you will. First, we don't know which case is the majority at this point. For now, there is one example of each, but it may very well turn out that the SK Hynix BC501 above needs to be quirked. Second, the reference here really is 5.2, so if there are any systems that are not better off with 5.3-rc than they were with 5.2, well, we have not made progress. However, if there are systems that are worse off with 5.3, that's bad. In the face of the latest findings the only way to avoid that is to be backwards compatible with 5.2 and that's where my patch is going. That cannot be achieved by quirking all cases that are reported as "bad", because there still may be unreported ones. I have to agree. I think your proposal may allow PCI D3cold, Yes, it may. Somehow the 9380 with Toshiba NVMe never hits SLP_S0 with or without Rafael’s patch. But the “real” s2idle power consumption does improve with the patch. Do you mean this patch: https://lore.kernel.org/linux-pm/70D536BE-8DC7-4CA2-84A9- afb067ba5...@canonical.com/T/#m456aa5c69973a3b68f2cdd4713a1ce83be5145 8f or the $subject one without the above? Can we use a DMI based quirk for this platform? It seems like a platform specific issue. We seem to see too many "platform-specific issues" here. :-) To me, the status quo (ie. what we have in 5.3-rc2) is not defensible. Something needs to be done to improve the situation. Rafael, would it be possible to try popping out PC401 from the 9380 and into a 9360 to confirm there actually being a platform impact or not? Not really, sorry. I was hoping to have something useful from Hynix by now before responding, but oh well. In terms of what is the majority, I do know that between folks at Dell, Google, Compal, Wistron, Canonical, Micron, Hynix, Toshiba, LiteOn, and Western Digital we tested a wide variety of SSDs with this patch series. I would like to think that they are representative of what's being manufactured into machines now. Well, what about drives already in the field? My concern is mostly about those ones. Notably the LiteOn CL1 was tested with the HMB flushing support and and Hynix PC401 was tested with older firmware though. In which case we do need to reintroduce the HMB handling. Right. The patch alone doesn’t break HMB Toshiba NVMe I tested. But I think it’s still safer to do proper HMB handling. Well, so can anyone please propose something specific? Like an alternative patch? This was proposed a few days ago: http://lists.infradead.org/pipermail/linux-nvme/2019-July/026056.html However we're still not sure why it is needed, and it will take some time to get a proper failure analysis from LiteOn regarding the CL1. Thanks for the update, but IMO we still need to do something before final 5.3 while the investigation continues. Honestly, at this point I would vote for going back to the 5.2 behavior at least by default and only running the new code on the drives known to require it (because they will block PC10 otherwise). Possibly (ideally) with an option for users who can't get beyond PC3 to test whether or not the new code helps them. I just found out that the XPS 9380 at my hand never reaches SLP_S0 but only PC10. That's the case for me too. This happens with or without putting the device to D3. On my system, though, it only can get to PC3 without putting the NVMe into D3 (as reported previously). I forgot to ask, what BIOS version does the system have? I don’t see this issue on BIOS v1.5.0. Kai-Heng
Re: [alsa-devel] [RFC PATCH 23/40] soundwire: stream: fix disable sequence
On 8/5/19 11:32 AM, Sanyog Kale wrote:
On Mon, Aug 05, 2019 at 10:33:25AM -0500, Pierre-Louis Bossart wrote:
On 8/5/19 4:56 AM, Sanyog Kale wrote:
On Thu, Jul 25, 2019 at 06:40:15PM -0500, Pierre-Louis Bossart wrote:
When we disable the stream and then call hw_free, two bank switches
will be handled and as a result we re-enable the stream on hw_free.
I didnt quite get why there will be two bank switches as part of disable flow
which leads to enabling of stream?
You have two bank switches, one to stop streaming and on in de-prepare. It's
symmetrical with the start sequence, where we do a bank switch to prepare
and another to enable.
Got it. I misunderstood it that two bank switches are performed as part of
disable_stream.
Let's assume we are using bank0 when streaming.
Before the first bank switch, the channel_enable is set to false in the
alternate bank1. When the bank switch happens, bank1 become active and the
streaming stops. But bank0 registers have not been modified so when we do
the second bank switch in de-prepare we make bank0 active, and the ch_enable
bits are still set so streaming will restart... When we stop streaming, we
need to make sure the ch_enable bits are cleared in the two banks.
This is clear. Even though the channels remains enabled, i believe there
won't be any data pushed on lines as stream will be closed.
Actually the link remains active. We tested this by setting the PRBS
data mode and the Slave device detects when we artificially inject errors.
There is however no data consumption on the DMA side of the Master IP
since the DMA is indeed stopped.
Regarding mirroring approach, I assume after bank switch we will take
snapshot of active bank and program same in inactive bank.
That should be the approach yes.
Make sure the stream is disabled on both banks.
TODO: we need to completely revisit all this and make sure we have a
mirroring mechanism between current and alternate banks.
Signed-off-by: Pierre-Louis Bossart
---
drivers/soundwire/stream.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c
index 53f5e790fcd7..75b9ad1fb1a6 100644
--- a/drivers/soundwire/stream.c
+++ b/drivers/soundwire/stream.c
@@ -1637,7 +1637,24 @@ static int _sdw_disable_stream(struct sdw_stream_runtime
*stream)
}
}
- return do_bank_switch(stream);
+ ret = do_bank_switch(stream);
+ if (ret < 0) {
+ dev_err(bus->dev, "Bank switch failed: %d\n", ret);
+ return ret;
+ }
+
+ /* make sure alternate bank (previous current) is also disabled */
+ list_for_each_entry(m_rt, &stream->master_list, stream_node) {
+ bus = m_rt->bus;
+ /* Disable port(s) */
+ ret = sdw_enable_disable_ports(m_rt, false);
+ if (ret < 0) {
+ dev_err(bus->dev, "Disable port(s) failed: %d\n", ret);
+ return ret;
+ }
+ }
+
+ return 0;
}
/**
--
2.20.1
Re: [GIT PULL] SafeSetID MAINTAINERS file update for v5.3
On Mon, Aug 05, 2019 at 11:20:59AM -0700, Linus Torvalds wrote: I don't know if it's worth changing the pr-tracker-bot rules. I *do* think that the whole unquoted for you to fetch changes up to [hex string] is by far the strongest single signal for a pull request, but it's not clear that it's worth spending a lot of CPU time looking for that unless you have a strong signal in the subject line. The way we do it currently is by hooking into public-inbox where the email subject is in the commit log. So for us to grab all new subjects it's a single git call, whereas getting the message body requires a git call per message. This is why we pre-filter by subject, as it's a cheap way to avoid needing to issue hundreds of git calls looking for possible matches in message bodies. So I consider this "solved", and maybe people should just realize that they won't get the automated responses unless they do everything just right. Would you consider recording the message-id of the pull request as part of the commit message? This would be a sure way for us to be able to catch all possible cases. In fact, this would allow me to throw out most of the bot logic, as it would become unnecessary. E.g. the merge commit would look like: Merge tag 'foo' of git://git.kernel.org/bar Pull foo features * foo * bar * baz Link: https://lore.kernel.org/r/ However, I suspect that getting message-ids for all your pull requests would significantly complicate your workflow. -K
Re: [alsa-devel] [RFC PATCH 27/40] soundwire: Add Intel resource management algorithm
+static int sdw_select_row_col(struct sdw_bus *bus, int clk_freq)
+{
+ struct sdw_master_prop *prop = &bus->prop;
+ int frame_int, frame_freq;
+ int r, c;
+
+ for (c = 0; c < SDW_FRAME_COLS; c++) {
+ for (r = 0; r < SDW_FRAME_ROWS; r++) {
+ if (sdw_rows[r] != prop->default_row ||
+ sdw_cols[c] != prop->default_col)
+ continue;
Are we only supporting default rows and cols?
for now yes. Note that the default is defined by firmware and e.g.
different for ICL (50x4) and CML (125x2). The firmware itself also
provides a single clock value so we'd need to override the DSDT or force
the properties to be different to use multiple gears.
This will probably change at some point when we have multiple device per
link. SoundWire 1.2 devices also provide a standard means to control the
clock, otherwise with SoundWire 1.1 the clock management requires quite
a bit of imp-def changes that we have not tested.
+
+ frame_int = sdw_rows[r] * sdw_cols[c];
+ frame_freq = clk_freq / frame_int;
+
+ if ((clk_freq - (frame_freq * SDW_FRAME_CTRL_BITS)) <
+ bus->params.bandwidth)
+ continue;
+
+ bus->params.row = sdw_rows[r];
+ bus->params.col = sdw_cols[c];
+ return 0;
+ }
+ }
+
+ return -EINVAL;
+}
+
--
2.20.1
Re: [PATCH v3] nvme-pci: Support shared tags across queues for Apple 2018 controllers
On 8/5/19 11:27 AM, Sagi Grimberg wrote: > >>> Ping ? I had another look today and I don't feel like mucking around >>> with all the AQ size logic, AEN magic tag etc... just for that sake of >>> that Apple gunk. I'm happy to have it give up IO tags, it doesn't seem >>> to make much of a difference in practice anyway. >>> >>> But if you feel strongly about it, then I'll implement the "proper" way >>> sometimes this week, adding a way to shrink the AQ down to something >>> like 3 (one admin request, one async event (AEN), and the empty slot) >>> by making a bunch of the constants involved variables instead. >> >> I don't feel too strongly about it. I think your patch is fine, so >> >> Acked-by: Keith Busch > > Should we pick this up for 5.3-rc? No, it's not a regression fix. Queue it up for 5.4 instead. -- Jens Axboe
Re: [PATCH 0/6] arm64: g12a: add support for DVFS
Neil Armstrong writes: > The G12A & G12B SoCs has kernel controllable CPU clocks and PWMs for > voltage regulators. > > This patchsets moves the meson-g12a.dtsi to meson-g12-common.dtsi to simplify > handling the G12A & G12B differences in the meson-g12a.dtsi & meson-g12b.dtsi > files, like the OPPs and CPU nodes. > > Then G12A & G12B OPP tables are added, followed by the CPU voltages regulators > in each boards DT. > > It was voluntary chosen to enabled DVFS (CPU regulator and CPU clocks) only > in boards, to make sure only tested boards has DVFS enabled. > > This patchset : > - moves the G12A DT to a common g12a-common dtsi > - adds the G12A and G12B OPPs > - enables DVFS on all supported boards > > Dependencies: > - None Not quite. The last patch to enable DVFS on odroid-n2 has a build-time dependency on the clock series that adds the CPUB clock. I'll apply the rest of the series to v5.4/dt64 until there's a stable clock tag I can use for the clocks. Kevin
Re: [GIT PULL] SPI fixes for v5.3
The pull request you sent on Mon, 5 Aug 2019 15:50:14 +0100: > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git > tags/spi-fix-v5.3-rc3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0eb0ce0a78e1f57082bca6cbdea6fd04feedb876 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Kselftest update for Linux 5.3-rc4
The pull request you sent on Mon, 5 Aug 2019 09:56:41 -0600: > git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest > tags/linux-kselftest-5.3-rc4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9e9671cea72e0652a8a0d03b7c96a8a798470c43 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] regulator fixes for v5.3
The pull request you sent on Mon, 5 Aug 2019 15:34:31 +0100: > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git > tags/regulator-fix-v5.3-rc3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/df9edcba0b1146da5e4a2d1921bbc10c1a2fb55d Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[PATCH net-next] net: phy: modify assignment to OR for dev_flags in phy_attach_direct
Modify the assignment to OR when dealing with phydev->dev_flags in phy_attach_direct function, and this is to make sure dev_flags set in driver's probe callback won't be lost. Suggested-by: Andrew Lunn CC: Heiner Kallweit CC: Vladimir Oltean Signed-off-by: Tao Ren --- drivers/net/phy/phy_device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index 6b5cb87f3866..9259eb45c794 100644 --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c @@ -1270,7 +1270,7 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev, phydev_err(phydev, "error creating 'phy_standalone' sysfs entry\n"); } - phydev->dev_flags = flags; + phydev->dev_flags |= flags; phydev->interface = interface; -- 2.17.1
[PATCH v3 5/6] tty: serial: fsl_lpuart: Don't enable TIE in .startup() or .resume()
Enabling TIE in .startup() callback causes the driver to start (or at least try) to transmit data before .start_tx() is called. Which, while harmless (since TIE handler will immediately disable it), is a no-op and shouldn't really happen. Drop UARTCR2_TIE from list of bits set in lpuart_startup(). This change will also not enable TIE in .resume(), but it seems that, similart to .startup(), transmit interrupt shouldn't be enabled there either. Signed-off-by: Andrey Smirnov Cc: Stefan Agner Cc: Chris Healy Cc: Cory Tusar Cc: Lucas Stach Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: linux-...@nxp.com Cc: linux-ser...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/tty/serial/fsl_lpuart.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c index fb9961edce3a..5c3cc1051aa8 100644 --- a/drivers/tty/serial/fsl_lpuart.c +++ b/drivers/tty/serial/fsl_lpuart.c @@ -1410,7 +1410,7 @@ static void lpuart_setup_watermark_enable(struct lpuart_port *sport) lpuart_setup_watermark(sport); cr2 = readb(sport->port.membase + UARTCR2); - cr2 |= UARTCR2_RIE | UARTCR2_TIE | UARTCR2_RE | UARTCR2_TE; + cr2 |= UARTCR2_RIE | UARTCR2_RE | UARTCR2_TE; writeb(cr2, sport->port.membase + UARTCR2); } -- 2.21.0
[PATCH v3 4/6] tty: serial: fsl_lpuart: Introduce lpuart*_setup_watermark_enable()
Most users of lpuart*_setup_watermark() enable identical set of flags
right after the call, so combine those two action into a subroutine
and make use of it.
Signed-off-by: Andrey Smirnov
Cc: Stefan Agner
Cc: Chris Healy
Cc: Cory Tusar
Cc: Lucas Stach
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: linux-...@nxp.com
Cc: linux-ser...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/tty/serial/fsl_lpuart.c | 50 ++---
1 file changed, 28 insertions(+), 22 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 1286daa1be79..fb9961edce3a 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -1403,6 +1403,17 @@ static void lpuart_setup_watermark(struct lpuart_port
*sport)
writeb(cr2_saved, sport->port.membase + UARTCR2);
}
+static void lpuart_setup_watermark_enable(struct lpuart_port *sport)
+{
+ unsigned char cr2;
+
+ lpuart_setup_watermark(sport);
+
+ cr2 = readb(sport->port.membase + UARTCR2);
+ cr2 |= UARTCR2_RIE | UARTCR2_TIE | UARTCR2_RE | UARTCR2_TE;
+ writeb(cr2, sport->port.membase + UARTCR2);
+}
+
static void lpuart32_setup_watermark(struct lpuart_port *sport)
{
unsigned long val, ctrl;
@@ -1428,6 +1439,17 @@ static void lpuart32_setup_watermark(struct lpuart_port
*sport)
lpuart32_write(&sport->port, ctrl_saved, UARTCTRL);
}
+static void lpuart32_setup_watermark_enable(struct lpuart_port *sport)
+{
+ u32 temp;
+
+ lpuart32_setup_watermark(sport);
+
+ temp = lpuart32_read(&sport->port, UARTCTRL);
+ temp |= UARTCTRL_RE | UARTCTRL_TE | UARTCTRL_ILIE;
+ lpuart32_write(&sport->port, temp, UARTCTRL);
+}
+
static void rx_dma_timer_init(struct lpuart_port *sport)
{
timer_setup(&sport->lpuart_timer, lpuart_timer_func, 0);
@@ -1488,11 +1510,7 @@ static int lpuart_startup(struct uart_port *port)
spin_lock_irqsave(&sport->port.lock, flags);
- lpuart_setup_watermark(sport);
-
- temp = readb(sport->port.membase + UARTCR2);
- temp |= UARTCR2_RIE | UARTCR2_TIE | UARTCR2_RE | UARTCR2_TE;
- writeb(temp, sport->port.membase + UARTCR2);
+ lpuart_setup_watermark_enable(sport);
lpuart_rx_dma_startup(sport);
lpuart_tx_dma_startup(sport);
@@ -1538,11 +1556,7 @@ static int lpuart32_startup(struct uart_port *port)
spin_lock_irqsave(&sport->port.lock, flags);
- lpuart32_setup_watermark(sport);
-
- temp = lpuart32_read(&sport->port, UARTCTRL);
- temp |= UARTCTRL_RE | UARTCTRL_TE | UARTCTRL_ILIE;
- lpuart32_write(&sport->port, temp, UARTCTRL);
+ lpuart32_setup_watermark_enable(sport);
lpuart_rx_dma_startup(sport);
@@ -2558,22 +2572,14 @@ static int lpuart_resume(struct device *dev)
{
struct lpuart_port *sport = dev_get_drvdata(dev);
bool irq_wake = irqd_is_wakeup_set(irq_get_irq_data(sport->port.irq));
- unsigned long temp;
if (sport->port.suspended && !irq_wake)
lpuart_enable_clks(sport);
- if (lpuart_is_32(sport)) {
- lpuart32_setup_watermark(sport);
- temp = lpuart32_read(&sport->port, UARTCTRL);
- temp |= UARTCTRL_RE | UARTCTRL_TE | UARTCTRL_ILIE;
- lpuart32_write(&sport->port, temp, UARTCTRL);
- } else {
- lpuart_setup_watermark(sport);
- temp = readb(sport->port.membase + UARTCR2);
- temp |= UARTCR2_RIE | UARTCR2_TIE | UARTCR2_RE | UARTCR2_TE;
- writeb(temp, sport->port.membase + UARTCR2);
- }
+ if (lpuart_is_32(sport))
+ lpuart32_setup_watermark_enable(sport);
+ else
+ lpuart_setup_watermark_enable(sport);
if (sport->lpuart_dma_rx_use) {
if (irq_wake) {
--
2.21.0
[PATCH v3 0/6] LPUART fixes and improvements
Everyone: This series contains fixes/improvements to LPUART dirver I came up with recently as well as fixes picked up from Toradex and NXP Vybrid repos. Feedback is welcome! Changes since [v2]: - Series rebased on Greg's tty-testing branch Changes since [v1]: - Dropped "tty: serial: fsl_lpuart: Drop unnecessary sg_set_buf() call" due to being a duplicate of "tty: serial: fsl_lpuart: remove sg_set_buf() for sport->rx_sgl" - Fixed build break in "tty: serial: fsl_lpuart: Introduce lpuart_tx_dma_startup()" Thanks, Andrey Smirnov [v2] lore.kernel.org/r/20190731173045.11718-1-andrew.smir...@gmail.com [v1] lore.kernel.org/r/20190729195226.8862-1-andrew.smir...@gmail.com Andrey Smirnov (6): tty: serial: fsl_lpuart: Introduce lpuart_tx_dma_startup() tty: serial: fsl_lpuart: Introduce lpuart_rx_dma_startup() tty: serial: fsl_lpuart: Introduce lpuart32_configure() tty: serial: fsl_lpuart: Introduce lpuart*_setup_watermark_enable() tty: serial: fsl_lpuart: Don't enable TIE in .startup() or .resume() tty: serial: fsl_lpuart: Ignore TX/RX interrupts if DMA is enabled drivers/tty/serial/fsl_lpuart.c | 195 +++- 1 file changed, 91 insertions(+), 104 deletions(-) -- 2.21.0
[PATCH v3 6/6] tty: serial: fsl_lpuart: Ignore TX/RX interrupts if DMA is enabled
In a mixed DMA/IRQ use-case (e.g.: DMA for TX, IRQ for RX), interrupt handler might try to handle Rx/Tx condition it shouldn't. Change the code to only handle TX/RX event if corresponding path isn't being handled by DMA. Signed-off-by: Andrey Smirnov Cc: Stefan Agner Cc: Chris Healy Cc: Cory Tusar Cc: Lucas Stach Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: linux-...@nxp.com Cc: linux-ser...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/tty/serial/fsl_lpuart.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c index 5c3cc1051aa8..3e17bb8a0b16 100644 --- a/drivers/tty/serial/fsl_lpuart.c +++ b/drivers/tty/serial/fsl_lpuart.c @@ -967,10 +967,10 @@ static irqreturn_t lpuart_int(int irq, void *dev_id) sts = readb(sport->port.membase + UARTSR1); - if (sts & UARTSR1_RDRF) + if (sts & UARTSR1_RDRF && !sport->lpuart_dma_rx_use) lpuart_rxint(sport); - if (sts & UARTSR1_TDRE) + if (sts & UARTSR1_TDRE && !sport->lpuart_dma_tx_use) lpuart_txint(sport); return IRQ_HANDLED; -- 2.21.0
[PATCH v3 3/6] tty: serial: fsl_lpuart: Introduce lpuart32_configure()
Code doing final steps of TX/RX configuration in lpuart32_startup()
and lpuart_resume() is identical, so move it into a standalone
subroutine.
Signed-off-by: Andrey Smirnov
Cc: Stefan Agner
Cc: Chris Healy
Cc: Cory Tusar
Cc: Lucas Stach
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: linux-...@nxp.com
Cc: linux-ser...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/tty/serial/fsl_lpuart.c | 48 +++--
1 file changed, 21 insertions(+), 27 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 4b59801a0a0c..1286daa1be79 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -1502,6 +1502,24 @@ static int lpuart_startup(struct uart_port *port)
return 0;
}
+static void lpuart32_configure(struct lpuart_port *sport)
+{
+ unsigned long temp;
+
+ if (sport->lpuart_dma_rx_use) {
+ /* RXWATER must be 0 */
+ temp = lpuart32_read(&sport->port, UARTWATER);
+ temp &= ~(UARTWATER_WATER_MASK << UARTWATER_RXWATER_OFF);
+ lpuart32_write(&sport->port, temp, UARTWATER);
+ }
+ temp = lpuart32_read(&sport->port, UARTCTRL);
+ if (!sport->lpuart_dma_rx_use)
+ temp |= UARTCTRL_RIE;
+ if (!sport->lpuart_dma_tx_use)
+ temp |= UARTCTRL_TIE;
+ lpuart32_write(&sport->port, temp, UARTCTRL);
+}
+
static int lpuart32_startup(struct uart_port *port)
{
struct lpuart_port *sport = container_of(port, struct lpuart_port,
port);
@@ -1530,18 +1548,7 @@ static int lpuart32_startup(struct uart_port *port)
lpuart_rx_dma_startup(sport);
lpuart_tx_dma_startup(sport);
- if (sport->lpuart_dma_rx_use) {
- /* RXWATER must be 0 */
- temp = lpuart32_read(&sport->port, UARTWATER);
- temp &= ~(UARTWATER_WATER_MASK << UARTWATER_RXWATER_OFF);
- lpuart32_write(&sport->port, temp, UARTWATER);
- }
- temp = lpuart32_read(&sport->port, UARTCTRL);
- if (!sport->lpuart_dma_rx_use)
- temp |= UARTCTRL_RIE;
- if (!sport->lpuart_dma_tx_use)
- temp |= UARTCTRL_TIE;
- lpuart32_write(&sport->port, temp, UARTCTRL);
+ lpuart32_configure(sport);
spin_unlock_irqrestore(&sport->port.lock, flags);
return 0;
@@ -2579,21 +2586,8 @@ static int lpuart_resume(struct device *dev)
lpuart_tx_dma_startup(sport);
- if (lpuart_is_32(sport)) {
- if (sport->lpuart_dma_rx_use) {
- /* RXWATER must be 0 */
- temp = lpuart32_read(&sport->port, UARTWATER);
- temp &= ~(UARTWATER_WATER_MASK <<
- UARTWATER_RXWATER_OFF);
- lpuart32_write(&sport->port, temp, UARTWATER);
- }
- temp = lpuart32_read(&sport->port, UARTCTRL);
- if (!sport->lpuart_dma_rx_use)
- temp |= UARTCTRL_RIE;
- if (!sport->lpuart_dma_tx_use)
- temp |= UARTCTRL_TIE;
- lpuart32_write(&sport->port, temp, UARTCTRL);
- }
+ if (lpuart_is_32(sport))
+ lpuart32_configure(sport);
uart_resume_port(&lpuart_reg, &sport->port);
--
2.21.0
[PATCH v3 1/6] tty: serial: fsl_lpuart: Introduce lpuart_tx_dma_startup()
Code configure DMA TX path in lpuart_startup(), lpuart32_startup() and
lpuart_resume() is doing exactly the same thing, so move it into a
standalone subroutine.
Signed-off-by: Andrey Smirnov
Cc: Stefan Agner
Cc: Chris Healy
Cc: Cory Tusar
Cc: Lucas Stach
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: linux-...@nxp.com
Cc: linux-ser...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/tty/serial/fsl_lpuart.c | 53 ++---
1 file changed, 23 insertions(+), 30 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 0e09e6dc5ccb..9da4529ee223 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -1435,6 +1435,26 @@ static void rx_dma_timer_init(struct lpuart_port *sport)
add_timer(&sport->lpuart_timer);
}
+static void lpuart_tx_dma_startup(struct lpuart_port *sport)
+{
+ u32 uartbaud;
+
+ if (sport->dma_tx_chan && !lpuart_dma_tx_request(&sport->port)) {
+ init_waitqueue_head(&sport->dma_wait);
+ sport->lpuart_dma_tx_use = true;
+ if (lpuart_is_32(sport)) {
+ uartbaud = lpuart32_read(&sport->port, UARTBAUD);
+ lpuart32_write(&sport->port,
+ uartbaud | UARTBAUD_TDMAE, UARTBAUD);
+ } else {
+ writeb(readb(sport->port.membase + UARTCR5) |
+ UARTCR5_TDMAS, sport->port.membase + UARTCR5);
+ }
+ } else {
+ sport->lpuart_dma_tx_use = false;
+ }
+}
+
static int lpuart_startup(struct uart_port *port)
{
struct lpuart_port *sport = container_of(port, struct lpuart_port,
port);
@@ -1471,14 +1491,7 @@ static int lpuart_startup(struct uart_port *port)
sport->lpuart_dma_rx_use = false;
}
- if (sport->dma_tx_chan && !lpuart_dma_tx_request(port)) {
- init_waitqueue_head(&sport->dma_wait);
- sport->lpuart_dma_tx_use = true;
- temp = readb(port->membase + UARTCR5);
- writeb(temp | UARTCR5_TDMAS, port->membase + UARTCR5);
- } else {
- sport->lpuart_dma_tx_use = false;
- }
+ lpuart_tx_dma_startup(sport);
spin_unlock_irqrestore(&sport->port.lock, flags);
@@ -1521,14 +1534,7 @@ static int lpuart32_startup(struct uart_port *port)
sport->lpuart_dma_rx_use = false;
}
- if (sport->dma_tx_chan && !lpuart_dma_tx_request(port)) {
- init_waitqueue_head(&sport->dma_wait);
- sport->lpuart_dma_tx_use = true;
- temp = lpuart32_read(&sport->port, UARTBAUD);
- lpuart32_write(&sport->port, temp | UARTBAUD_TDMAE, UARTBAUD);
- } else {
- sport->lpuart_dma_tx_use = false;
- }
+ lpuart_tx_dma_startup(sport);
if (sport->lpuart_dma_rx_use) {
/* RXWATER must be 0 */
@@ -2577,20 +2583,7 @@ static int lpuart_resume(struct device *dev)
}
}
- if (sport->dma_tx_chan && !lpuart_dma_tx_request(&sport->port)) {
- init_waitqueue_head(&sport->dma_wait);
- sport->lpuart_dma_tx_use = true;
- if (lpuart_is_32(sport)) {
- temp = lpuart32_read(&sport->port, UARTBAUD);
- lpuart32_write(&sport->port,
- temp | UARTBAUD_TDMAE, UARTBAUD);
- } else {
- writeb(readb(sport->port.membase + UARTCR5) |
- UARTCR5_TDMAS, sport->port.membase + UARTCR5);
- }
- } else {
- sport->lpuart_dma_tx_use = false;
- }
+ lpuart_tx_dma_startup(sport);
if (lpuart_is_32(sport)) {
if (sport->lpuart_dma_rx_use) {
--
2.21.0
[PATCH v3 2/6] tty: serial: fsl_lpuart: Introduce lpuart_rx_dma_startup()
Code doing initial DMA RX configuration in lpuart_startup() and
lpuart32_startup() is exactly the same, so move it into a standalone
subroutine.
Signed-off-by: Andrey Smirnov
Cc: Stefan Agner
Cc: Chris Healy
Cc: Cory Tusar
Cc: Lucas Stach
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: linux-...@nxp.com
Cc: linux-ser...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/tty/serial/fsl_lpuart.c | 40 ++---
1 file changed, 17 insertions(+), 23 deletions(-)
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 9da4529ee223..4b59801a0a0c 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -1455,6 +1455,21 @@ static void lpuart_tx_dma_startup(struct lpuart_port
*sport)
}
}
+static void lpuart_rx_dma_startup(struct lpuart_port *sport)
+{
+ if (sport->dma_rx_chan && !lpuart_start_rx_dma(sport)) {
+ /* set Rx DMA timeout */
+ sport->dma_rx_timeout = msecs_to_jiffies(DMA_RX_TIMEOUT);
+ if (!sport->dma_rx_timeout)
+ sport->dma_rx_timeout = 1;
+
+ sport->lpuart_dma_rx_use = true;
+ rx_dma_timer_init(sport);
+ } else {
+ sport->lpuart_dma_rx_use = false;
+ }
+}
+
static int lpuart_startup(struct uart_port *port)
{
struct lpuart_port *sport = container_of(port, struct lpuart_port,
port);
@@ -1479,18 +1494,7 @@ static int lpuart_startup(struct uart_port *port)
temp |= UARTCR2_RIE | UARTCR2_TIE | UARTCR2_RE | UARTCR2_TE;
writeb(temp, sport->port.membase + UARTCR2);
- if (sport->dma_rx_chan && !lpuart_start_rx_dma(sport)) {
- /* set Rx DMA timeout */
- sport->dma_rx_timeout = msecs_to_jiffies(DMA_RX_TIMEOUT);
- if (!sport->dma_rx_timeout)
-sport->dma_rx_timeout = 1;
-
- sport->lpuart_dma_rx_use = true;
- rx_dma_timer_init(sport);
- } else {
- sport->lpuart_dma_rx_use = false;
- }
-
+ lpuart_rx_dma_startup(sport);
lpuart_tx_dma_startup(sport);
spin_unlock_irqrestore(&sport->port.lock, flags);
@@ -1522,18 +1526,8 @@ static int lpuart32_startup(struct uart_port *port)
temp |= UARTCTRL_RE | UARTCTRL_TE | UARTCTRL_ILIE;
lpuart32_write(&sport->port, temp, UARTCTRL);
- if (sport->dma_rx_chan && !lpuart_start_rx_dma(sport)) {
- /* set Rx DMA timeout */
- sport->dma_rx_timeout = msecs_to_jiffies(DMA_RX_TIMEOUT);
- if (!sport->dma_rx_timeout)
- sport->dma_rx_timeout = 1;
-
- sport->lpuart_dma_rx_use = true;
- rx_dma_timer_init(sport);
- } else {
- sport->lpuart_dma_rx_use = false;
- }
+ lpuart_rx_dma_startup(sport);
lpuart_tx_dma_startup(sport);
if (sport->lpuart_dma_rx_use) {
--
2.21.0
[PATCH] MIPS: BCM63XX: Mark expected switch fall-through
Mark switch cases where we are expecting to fall through. This patch fixes the following warning (Building: bcm63xx_defconfig mips): arch/mips/pci/ops-bcm63xx.c: In function ‘bcm63xx_pcie_can_access’: arch/mips/pci/ops-bcm63xx.c:474:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (PCI_SLOT(devfn) == 0) ^ arch/mips/pci/ops-bcm63xx.c:477:2: note: here default: ^~~ Signed-off-by: Gustavo A. R. Silva --- arch/mips/pci/ops-bcm63xx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/mips/pci/ops-bcm63xx.c b/arch/mips/pci/ops-bcm63xx.c index d02eb9d16b55..925c72348fb6 100644 --- a/arch/mips/pci/ops-bcm63xx.c +++ b/arch/mips/pci/ops-bcm63xx.c @@ -474,6 +474,7 @@ static int bcm63xx_pcie_can_access(struct pci_bus *bus, int devfn) if (PCI_SLOT(devfn) == 0) return bcm_pcie_readl(PCIE_DLSTATUS_REG) & DLSTATUS_PHYLINKUP; + /* else, fall through */ default: return false; } -- 2.22.0
Re: Let's talk about the elephant in the room - the Linux kernel's inability to gracefully handle low memory pressure
On Mon, Aug 05, 2019 at 03:31:19PM +0200, Michal Hocko wrote: > On Mon 05-08-19 14:13:16, Vlastimil Babka wrote: > > On 8/4/19 11:23 AM, Artem S. Tashkinov wrote: > > > Hello, > > > > > > There's this bug which has been bugging many people for many years > > > already and which is reproducible in less than a few minutes under the > > > latest and greatest kernel, 5.2.6. All the kernel parameters are set to > > > defaults. > > > > > > Steps to reproduce: > > > > > > 1) Boot with mem=4G > > > 2) Disable swap to make everything faster (sudo swapoff -a) > > > 3) Launch a web browser, e.g. Chrome/Chromium or/and Firefox > > > 4) Start opening tabs in either of them and watch your free RAM decrease > > > > > > Once you hit a situation when opening a new tab requires more RAM than > > > is currently available, the system will stall hard. You will barely be > > > able to move the mouse pointer. Your disk LED will be flashing > > > incessantly (I'm not entirely sure why). You will not be able to run new > > > applications or close currently running ones. > > > > > This little crisis may continue for minutes or even longer. I think > > > that's not how the system should behave in this situation. I believe > > > something must be done about that to avoid this stall. > > > > Yeah that's a known problem, made worse SSD's in fact, as they are able > > to keep refaulting the last remaining file pages fast enough, so there > > is still apparent progress in reclaim and OOM doesn't kick in. > > > > At this point, the likely solution will be probably based on pressure > > stall monitoring (PSI). I don't know how far we are from a built-in > > monitor with reasonable defaults for a desktop workload, so CCing > > relevant folks. > > Another potential approach would be to consider the refault information > we have already for file backed pages. Once we start reclaiming only > workingset pages then we should be trashing, right? It cannot be as > precise as the cost model which can be defined around PSI but it might > give us at least a fallback measure. NAK, this does *not* work. Not even as fallback. There is no amount of refaults for which you can say whether they are a problem or not. It depends on the disk speed (obvious) but also on the workload's memory access patterns (somewhat less obvious). For example, we have workloads whose cache set doesn't quite fit into memory, but everything else is pretty much statically allocated and it rarely touches any new or one-off filesystem data. So there is always a steady rate of mostly uninterrupted refaults, however, most data accesses are hitting the cache! And we have fast SSDs that compensate for the refaults that do occur. The workload runs *completely fine*. If the cache hit rate was lower and refaults would make up a bigger share of overall page accesses, or if there was a spinning disk in that machine, the machine would be completely livelocked - with the same exact number of refaults and the same amount of RAM! That's not just an approximation error that we could compensate for. The same rate of refaults in a system could mean anything from 0% (all refaults readahead, and IO is done before workload notices) to 100% memory pressure (all refaults are cache misses and workload fully serialized on pages in question) - and anything in between (a subset of threads of the workload wait for a subset of the refaults). The refault rate by itself carries no signal on workload progress. This is the whole reason why psi was developed - to compare the time you spend on refaults (encodes IO speed and readhahead efficiency) compared to the time you spend on being productive (encodes refaults as share of overall memory accesses of a the workload).
Re: [Lkcamp] [PATCH] isdn: hysdn: fix code style error from checkpatch
Hi, On Fri, Aug 2, 2019 at 6:55 PM Stephen Hemminger wrote: > > On Fri, 2 Aug 2019 19:50:17 + > Ricardo Bruno Lopes da Silva wrote: > > > Fix error bellow from checkpatch. > > > > WARNING: Block comments use * on subsequent lines > > +/*** > > + > > > > Signed-off-by: Ricardo Bruno Lopes da Silva > > Read the TODO, these drivers are scheduled for removal, so changes > are not helpful at this time. I'm sorry, it was me who suggested Ricardo to make this change as his first contribution, I didn't see the TODO file. Ricardo, it would be great if you could send a patch to another staging driver to get starting and to learn how the kernel development cycle works. Feel free to ping me or the lkcamp group if you want some pointers/guidance. Thanks both for your contribution. Helen > > ___ > Lkcamp mailing list > lkc...@lists.libreplanetbr.org > https://lists.libreplanetbr.org/mailman/listinfo/lkcamp
Re: [PATCH] page flags: prioritize kasan bits over last-cpuid
On Mon, Aug 05, 2019 at 08:35:40PM +0200, Arnd Bergmann wrote: > On Mon, Aug 5, 2019 at 6:51 PM Guenter Roeck wrote: > > > > On Fri, Aug 02, 2019 at 09:49:02PM -0700, Arnd Bergmann wrote: > > > ARM64 randdconfig builds regularly run into a build error, especially > > > when NUMA_BALANCING and SPARSEMEM are enabled but not SPARSEMEM_VMEMMAP: > > > > > > #error "KASAN: not enough bits in page flags for tag" > > > > > > The last-cpuid bits are already contitional on the available space, so > > > the result of the calculation is a bit random on whether they were > > > already left out or not. > > > > > > Adding the kasan tag bits before last-cpuid makes it much more likely to > > > end up with a successful build here, and should be reliable for > > > randconfig at least, as long as that does not randomize NR_CPUS or > > > NODES_SHIFT but uses the defaults. > > > > > > In order for the modified check to not trigger in the x86 vdso32 code > > > where all constants are wrong (building with -m32), enclose all the > > > definitions with an #ifdef. > > > > > > > This results in > > > > ./include/linux/page-flags-layout.h:95:2: error: #error "Not enough bits in > > page flags" > > #error "Not enough bits in page flags" > > > > when trying to build mipsel64:fuloong2e_defconfig. > > Do you have my follow-up fix applied? > > https://ozlabs.org/~akpm/mmots/broken-out/page-flags-prioritize-kasan-bits-over-last-cpuid-fix.patch > No. I see the failure in next-20190729..next-20190805. I didn't try to apply that patch, but I don't see arch/mips/vdso/vdso.h in the tree. I only see arch/mips/include/asm/vdso.h arch/mips/include/asm/vdso/vdso.h Are you sure that your patch can be applied as-is ? Guenter
Re: [Lkcamp] [PATCH] staging: isdn: remove unnecessary parentheses
Hi, On Mon, Aug 5, 2019 at 11:51 AM Dan Carpenter wrote: > > This driver is obselete so we're just keeping it around for a couple > kernel releases and then deleting it. We're not taking cleanups for it. I'm sorry, it was me who suggested Thiago to make this change as his first contribution, I didn't see the TODO file. Thiago, it would be great if you could send a patch to another staging driver to get starting and to learn how the kernel development cycle works. Feel free to ping me or the lkcamp group if you want some pointers/guidance. Thanks both for your contribution. Helen > > regards, > dan carpenter > > > ___ > Lkcamp mailing list > lkc...@lists.libreplanetbr.org > https://lists.libreplanetbr.org/mailman/listinfo/lkcamp
Re: [PATCH] MAINTAINERS: floppy: take over maintainership
Hi Denis, I just saw this on LWN and would like to thank you for picking up floppy support as it’s important (especially for interfacing with esoteric hardware). I’m also collecting a few drives so I can use a spare if one breaks… usable discs are becoming a problem though ☹ bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Re: [GIT PULL] regulator fixes for v5.3
Mark, these got marked as spam once again, because dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org and I think it's because you have DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; but then you have From: Mark Brown so the DKIM signature is all correct, but it's correct for sirena.org.uk, not for the sender information.. Linus
Re: [PATCH v3] nvme-pci: Support shared tags across queues for Apple 2018 controllers
On Mon, Aug 05, 2019 at 11:27:54AM -0700, Sagi Grimberg wrote: > > > > Ping ? I had another look today and I don't feel like mucking around > > > with all the AQ size logic, AEN magic tag etc... just for that sake of > > > that Apple gunk. I'm happy to have it give up IO tags, it doesn't seem > > > to make much of a difference in practice anyway. > > > > > > But if you feel strongly about it, then I'll implement the "proper" way > > > sometimes this week, adding a way to shrink the AQ down to something > > > like 3 (one admin request, one async event (AEN), and the empty slot) > > > by making a bunch of the constants involved variables instead. > > > > I don't feel too strongly about it. I think your patch is fine, so > > > > Acked-by: Keith Busch > > Should we pick this up for 5.3-rc? Probably not. While I don't think this is a risky patch set, it's not a bug fix for anything we introduced during the merge window. Christoph also stated he wanted this to go in the 5.4 merge window.
Re: [PATCH 7/9] media: hantro: Add core bits to support H264 decoding
Hey Tomasz, On Thu, 2019-08-01 at 13:06 +0900, Tomasz Figa wrote: > Hi Boris, > > On Wed, Jun 19, 2019 at 9:15 PM Boris Brezillon > wrote: > [snip] > > @@ -533,10 +535,21 @@ hantro_queue_setup(struct vb2_queue *vq, unsigned int > > *num_buffers, > > return -EINVAL; > > } > > > > + /* The H264 decoder needs extra size on the output buffer. */ > > + if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_H264_SLICE_RAW) > > + extra_size0 = 128 * DIV_ROUND_UP(pixfmt->width, 16) * > > + DIV_ROUND_UP(pixfmt->height, 16); > > + > > I wonder if this shouldn't be accounted for already in the sizeimage > returned by TRY_/S_FMT, so that the application can know the required > buffer size if it uses some external allocator and DMABUF memory type. > I know we had it like this in our downstream code, but it wasn't the > problem because we use minigbm, where we explicitly add the same > padding in the rockchip backend. Any thoughts? > Nice catch. This should be fixed and accounted in TRY_FMT as you suggest. Thanks, Eze
Re: [PATCH 1/3] mm, reclaim: make should_continue_reclaim perform dryrun detection
On 8/5/19 6:58 PM, Mike Kravetz wrote: >> Signed-off-by: Vlastimil Babka > > Acked-by: Mike Kravetz > > Would you like me to add this to the series, or do you want to send later? Please add, thanks!
Re: [PATCH] PCI: hv: Detect and fix Hyper-V PCI domain number collision
On Fri, Aug 02, 2019 at 06:52:56PM +, Haiyang Zhang wrote: Due to Azure host agent settings, the device instance ID's bytes 8 and 9 are no longer unique. This causes some of the PCI devices not showing up in VMs with multiple passthrough devices, such as GPUs. So, as recommended by Azure host team, we now use the bytes 4 and 5 which usually provide unique numbers. In the rare cases of collision, we will detect and find another number that is not in use. Thanks to Michael Kelley for proposing this idea. Signed-off-by: Haiyang Zhang Acked-by: Sasha Levin Bjorn, will you take it through the PCI tree or do you want me to take it through hyper-v? -- Thanks, Sasha
Re: [PATCH] page flags: prioritize kasan bits over last-cpuid
On Mon, Aug 5, 2019 at 6:51 PM Guenter Roeck wrote: > > On Fri, Aug 02, 2019 at 09:49:02PM -0700, Arnd Bergmann wrote: > > ARM64 randdconfig builds regularly run into a build error, especially > > when NUMA_BALANCING and SPARSEMEM are enabled but not SPARSEMEM_VMEMMAP: > > > > #error "KASAN: not enough bits in page flags for tag" > > > > The last-cpuid bits are already contitional on the available space, so > > the result of the calculation is a bit random on whether they were > > already left out or not. > > > > Adding the kasan tag bits before last-cpuid makes it much more likely to > > end up with a successful build here, and should be reliable for > > randconfig at least, as long as that does not randomize NR_CPUS or > > NODES_SHIFT but uses the defaults. > > > > In order for the modified check to not trigger in the x86 vdso32 code > > where all constants are wrong (building with -m32), enclose all the > > definitions with an #ifdef. > > > > This results in > > ./include/linux/page-flags-layout.h:95:2: error: #error "Not enough bits in > page flags" > #error "Not enough bits in page flags" > > when trying to build mipsel64:fuloong2e_defconfig. Do you have my follow-up fix applied? https://ozlabs.org/~akpm/mmots/broken-out/page-flags-prioritize-kasan-bits-over-last-cpuid-fix.patch Arnd
Re: [PATCH 5.2 000/131] 5.2.7-stable review
stable-rc/linux-5.2.y boot: 134 boots: 0 failed, 93 passed with 41 offline (v5.2.6-132-ga312bfbb74da) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.2.y/kernel/v5.2.6-132-ga312bfbb74da/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.2.y/kernel/v5.2.6-132-ga312bfbb74da/ Tree: stable-rc Branch: linux-5.2.y Git Describe: v5.2.6-132-ga312bfbb74da Git Commit: a312bfbb74da87b0c6822845b2cb9932d43c9208 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 77 unique boards, 28 SoC families, 17 builds out of 209 Boot Regressions Detected: arm: qcom_defconfig: gcc-8: qcom-apq8064-cm-qs600: lab-baylibre-seattle: failing since 1 day (last pass: v5.2.4-235-g44397d30b22d - first fail: v5.2.6) qcom-apq8064-ifc6410: lab-baylibre-seattle: failing since 1 day (last pass: v5.2.4-235-g44397d30b22d - first fail: v5.2.6) sunxi_defconfig: gcc-8: sun4i-a10-cubieboard: lab-baylibre-seattle: failing since 1 day (last pass: v5.2.4-235-g44397d30b22d - first fail: v5.2.6) sun5i-r8-chip: lab-baylibre-seattle: failing since 1 day (last pass: v5.2.4-235-g44397d30b22d - first fail: v5.2.6) sun7i-a20-bananapi: lab-baylibre-seattle: failing since 1 day (last pass: v5.2.4-235-g44397d30b22d - first fail: v5.2.6) Offline Platforms: riscv: defconfig: gcc-8 sifive_fu540: 1 offline lab arm64: defconfig: gcc-8 apq8016-sbc: 1 offline lab meson-axg-s400: 1 offline lab meson-g12a-u200: 1 offline lab meson-g12a-x96-max: 1 offline lab meson-gxbb-odroidc2: 1 offline lab meson-gxl-s905d-p230: 1 offline lab meson-gxl-s905x-libretech-cc: 1 offline lab meson-gxl-s905x-nexbox-a95x: 1 offline lab meson-gxl-s905x-p212: 1 offline lab meson-gxm-nexbox-a1: 1 offline lab rk3399-firefly: 1 offline lab sun50i-a64-pine64-plus: 1 offline lab mips: pistachio_defconfig: gcc-8 pistachio_marduk: 1 offline lab arm: exynos_defconfig: gcc-8 exynos5250-arndale: 1 offline lab exynos5800-peach-pi: 1 offline lab multi_v7_defconfig: gcc-8 bcm4708-smartrg-sr400ac: 1 offline lab bcm72521-bcm97252sffe: 1 offline lab bcm7445-bcm97445c: 1 offline lab exynos5800-peach-pi: 1 offline lab imx6dl-wandboard_solo: 1 offline lab imx6q-wandboard: 1 offline lab imx7s-warp: 1 offline lab meson8b-odroidc1: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab stih410-b2120: 1 offline lab sun4i-a10-cubieboard: 1 offline lab sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab vf610-colibri-eval-v3: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab davinci_all_defconfig: gcc-8 da850-evm: 1 offline lab dm365evm,legacy: 1 offline lab imx_v6_v7_defconfig: gcc-8 imx6dl-wandboard_solo: 1 offline lab imx7s-warp: 1 offline lab vf610-colibri-eval-v3: 1 offline lab sunxi_defconfig: gcc-8 sun4i-a10-cubieboard: 1 offline lab sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab --- For more info write to
Re: [PATCH 4.19 00/74] 4.19.65-stable review
stable-rc/linux-4.19.y boot: 65 boots: 1 failed, 64 passed (v4.19.64-75-g27e5d9acda64) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.64-75-g27e5d9acda64/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.64-75-g27e5d9acda64/ Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.64-75-g27e5d9acda64 Git Commit: 27e5d9acda64f19f64a7db74e3bff765c11248bf Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 34 unique boards, 17 SoC families, 12 builds out of 206 Boot Regressions Detected: arm: multi_v7_defconfig: gcc-8: exynos5250-snow: lab-collabora: new failure (last pass: v4.19.64) Boot Failure Detected: arm: multi_v7_defconfig: gcc-8: exynos5250-snow: 1 failed lab --- For more info write to
Re: [PATCH] ARM: Replace strncmp with str_has_prefix
Chuhong Yuan writes:
> In commit b6b2735514bc
> ("tracing: Use str_has_prefix() instead of using fixed sizes")
> the newly introduced str_has_prefix() was used
> to replace error-prone strncmp(str, const, len).
> Here fix codes with the same pattern.
>
> Signed-off-by: Chuhong Yuan
> ---
> arch/arm/kernel/module-plts.c| 2 +-
> arch/arm/mach-omap2/omap_device.c| 4 ++--
> arch/arm/mach-omap2/pm-debug.c | 8
> arch/arm/mach-omap2/pm.c | 2 +-
> arch/arm/mach-omap2/pm44xx.c | 2 +-
> arch/arm/mach-omap2/sr_device.c | 8
> arch/arm/mach-orion5x/ts78xx-setup.c | 4 ++--
For the OMAP stuff:
Reviewed-by: Kevin Hilman # arch/arm/mach-omap2/*
Kevin
Re: [PATCH v2] PM/sleep: Expose suspend stats in sysfs
On Thu, Aug 1, 2019 at 9:34 AM Kalesh Singh wrote: > > On Wed, Jul 31, 2019 at 11:19 PM Greg KH wrote: > > > > On Wed, Jul 31, 2019 at 02:29:33PM -0700, Kalesh Singh wrote: > > > Userspace can get suspend stats from the suspend stats debugfs node. > > > Since debugfs doesn't have stable ABI, expose suspend stats in > > > sysfs under /sys/power/suspend_stats. > > > > > > Signed-off-by: Kalesh Singh > > > --- > > > Changes in v2: > > > - Added separate show functions for last_failed_* stats, as per Greg > > > - Updated ABI Documentation > > > > This is nice, I didn't even know some of these were in the debugfs > > entries, so this should be more helpful to people. > > > > Reviewed-by: Greg Kroah-Hartman Reviewed-by: Tri Vo
Re: [PATCH v3] nvme-pci: Support shared tags across queues for Apple 2018 controllers
Ping ? I had another look today and I don't feel like mucking around with all the AQ size logic, AEN magic tag etc... just for that sake of that Apple gunk. I'm happy to have it give up IO tags, it doesn't seem to make much of a difference in practice anyway. But if you feel strongly about it, then I'll implement the "proper" way sometimes this week, adding a way to shrink the AQ down to something like 3 (one admin request, one async event (AEN), and the empty slot) by making a bunch of the constants involved variables instead. I don't feel too strongly about it. I think your patch is fine, so Acked-by: Keith Busch Should we pick this up for 5.3-rc?
Re: [GIT PULL] SafeSetID MAINTAINERS file update for v5.3
On Mon, Aug 5, 2019 at 7:28 AM Konstantin Ryabitsev wrote: > > On Sun, Aug 04, 2019 at 10:47:54AM -0700, Linus Torvalds wrote: > > - maybe pr-tracker-bot ignores follow-up emails with "Re:" in the > > subject? > > Yes, this is the culprit. Here are the matching regexes: > > https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/pr-tracker-bot.py#n41 > > Normally, pull requests don't come in as replies -- this is the first > one that got missed in months, to my knowledge. Most pull requests certainly are proper starts of threads. And I generally wish they were, because I know I myself tend to skim over emails much more quickly if it's some old discussion that I either consider solved or where somebody else is handling it, so if I see a pull request in the middle of a thread, it's much more likely that I'd miss it. It does happen, though. Not just in situations like this, where I replied to the original pull request with some reason for why I wouldn't pull it, and then the fixed pull came in as part of the thread. Al Viro does that to me occasionally, for example. Some discussion about a vfs problem, and then the pull request is in the middle of that thread. You can see an example of that here: https://lore.kernel.org/lkml/20180125002151.gr13...@zeniv.linux.org.uk/ although in that case it was Davem who merged it (in merge commit 8ec59b44a006. Of course, pr-tracker-bot wouldn't have noticed that one anyway, because it also doesn't have "GIT PULL" or anything like that in the subject line at all. So maybe it's not a great example. I don't know if it's worth changing the pr-tracker-bot rules. I *do* think that the whole unquoted for you to fetch changes up to [hex string] is by far the strongest single signal for a pull request, but it's not clear that it's worth spending a lot of CPU time looking for that unless you have a strong signal in the subject line. So I consider this "solved", and maybe people should just realize that they won't get the automated responses unless they do everything just right. Linus
Re: [PATCH net] mvpp2: fix panic on module removal
On Mon, Aug 5, 2019 at 7:58 PM David Miller wrote: > > From: Matteo Croce > Date: Wed, 31 Jul 2019 20:31:16 +0200 > > > mvpp2 uses a delayed workqueue to gather traffic statistics. > > On module removal the workqueue can be destroyed before calling > > cancel_delayed_work_sync() on its works. > > Fix it by moving the destroy_workqueue() call after mvpp2_port_remove(). > > Please post a new version with the flush_workqueue() removed. Hi, I thought that it was already merged: https://lore.kernel.org/netdev/20190801121330.30823-1-mcr...@redhat.com/ Let me know if it's ok already. Regards, -- Matteo Croce per aspera ad upstream
Re: [PATCH v2] net/mlx5e: always initialize frag->last_in_page
From: Qian Cai
Date: Thu, 1 Aug 2019 09:52:54 -0400
> The commit 069d11465a80 ("net/mlx5e: RX, Enhance legacy Receive Queue
> memory scheme") introduced an undefined behaviour below due to
> "frag->last_in_page" is only initialized in mlx5e_init_frags_partition()
> when,
>
> if (next_frag.offset + frag_info[f].frag_stride > PAGE_SIZE)
>
> or after bailed out the loop,
>
> for (i = 0; i < mlx5_wq_cyc_get_size(&rq->wqe.wq); i++)
>
> As the result, there could be some "frag" have uninitialized
> value of "last_in_page".
>
> Later, get_frag() obtains those "frag" and check "frag->last_in_page" in
> mlx5e_put_rx_frag() and triggers the error during boot. Fix it by always
> initializing "frag->last_in_page" to "false" in
> mlx5e_init_frags_partition().
...
> Fixes: 069d11465a80 ("net/mlx5e: RX, Enhance legacy Receive Queue memory
> scheme")
> Signed-off-by: Qian Cai
Applied and queued up for -stable.
Re: [PATCH] MAINTAINERS: Update e-mail address for Andrea Parri
On Mon, 2019-08-05 at 10:43 -0700, Paul E. McKenney wrote:
> On Mon, Aug 05, 2019 at 08:23:38AM -0700, James Bottomley wrote:
> > On Mon, 2019-08-05 at 17:15 +0200, Andrea Parri wrote:
> > > > Why don't you also add an entry in .mailmap as Will did in
> > > > commit
> > > > c584b1202f2d ("MAINTAINERS: Update my email address to use
> > > > @kernel.org")?
> > >
> > > I considered it but could not understand its purpose... Maybe
> > > you can explain it to me? ;-) (can resend with this change if
> > > needed/desired).
> >
> > man git-shortlog gives you the gory detail, but its use is to
> > "coalesce together commits by the same person in the shortlog,
> > where their name and/or email address was spelled
> > differently." The usual way this happens is that people have the
> > name that appears in the From field with and without initials.
>
> New one on me, thank you! So I should have a line in .mailmap like
> this?
>
> Paul E. McKenney rg>
Well, you could, but there's no need. As long as your email has 'Paul
E. McKenney' as the text prefix, git-shortlog will do the correct
aggregation without any need for a .mailmap entry. However, if, say,
your linaro email had been
Paul McKenney
Then you would need one because git-shortlog would think 'Paul
McKenney' and 'Paul E. McKenney' were two different people.
James
Re: [PATCH v7 01/20] pinctrl: tegra: Add suspend and resume support
On 8/5/19 3:50 AM, Dmitry Osipenko wrote:
01.08.2019 0:10, Sowjanya Komatineni пишет:
This patch adds support for Tegra pinctrl driver suspend and resume.
During suspend, context of all pinctrl registers are stored and
on resume they are all restored to have all the pinmux and pad
configuration for normal operation.
Acked-by: Thierry Reding
Reviewed-by: Dmitry Osipenko
Signed-off-by: Sowjanya Komatineni
---
drivers/pinctrl/tegra/pinctrl-tegra.c | 59 +++
drivers/pinctrl/tegra/pinctrl-tegra.h | 3 ++
2 files changed, 62 insertions(+)
diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.c
b/drivers/pinctrl/tegra/pinctrl-tegra.c
index 186ef98e7b2b..e3a237534281 100644
--- a/drivers/pinctrl/tegra/pinctrl-tegra.c
+++ b/drivers/pinctrl/tegra/pinctrl-tegra.c
@@ -631,6 +631,58 @@ static void tegra_pinctrl_clear_parked_bits(struct
tegra_pmx *pmx)
}
}
+static size_t tegra_pinctrl_get_bank_size(struct device *dev,
+ unsigned int bank_id)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct resource *res;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, bank_id);
+
+ return resource_size(res) / 4;
+}
+
+static int tegra_pinctrl_suspend(struct device *dev)
+{
+ struct tegra_pmx *pmx = dev_get_drvdata(dev);
+ u32 *backup_regs = pmx->backup_regs;
+ u32 *regs;
+ size_t bank_size;
+ unsigned int i, k;
+
+ for (i = 0; i < pmx->nbanks; i++) {
+ bank_size = tegra_pinctrl_get_bank_size(dev, i);
+ regs = pmx->regs[i];
+ for (k = 0; k < bank_size; k++)
+ *backup_regs++ = readl_relaxed(regs++);
+ }
+
+ return pinctrl_force_sleep(pmx->pctl);
+}
+
+static int tegra_pinctrl_resume(struct device *dev)
+{
+ struct tegra_pmx *pmx = dev_get_drvdata(dev);
+ u32 *backup_regs = pmx->backup_regs;
+ u32 *regs;
+ size_t bank_size;
+ unsigned int i, k;
+
+ for (i = 0; i < pmx->nbanks; i++) {
+ bank_size = tegra_pinctrl_get_bank_size(dev, i);
+ regs = pmx->regs[i];
+ for (k = 0; k < bank_size; k++)
+ writel_relaxed(*backup_regs++, regs++);
+ }
I'm now curious whether any kind of barrier is needed after the
writings. The pmx_writel() doesn't insert a barrier after the write and
seems it just misuses writel, which actually should be writel_relaxed()
+ barrier, IIUC.
pmx_writel uses writel and it has wmb before raw_write which complete
all writes initiated prior to this.
By misusing writel, you mean to have barrier after register write?
It's also not obvious whether PINCTRL HW has any kind of write-FIFO and
thus maybe read-back + rmb() is needed in order ensure that writes are
actually completed.
I believe adding write barrier wmb after writel_relaxed should be good
rather than doing readback + rmb
The last thing which is not obvious is when the new configuration
actually takes into effect, does it happen immediately or maybe some
delay is needed?
[snip]
Based on internal design there is no internal delay and it all depends
on APB rate that it takes to write to register.
Pinmux value change to reflect internally might take couple of clock
cycles which is much faster than SW can read.
[PATCH net-next 03/10] net: stmmac: Fix issues when number of Queues >= 4
When queues >= 4 we use different registers but we were not subtracting the offset of 4. Fix this. Found out by Coverity. Signed-off-by: Jose Abreu --- Cc: Giuseppe Cavallaro Cc: Alexandre Torgue Cc: Jose Abreu Cc: "David S. Miller" Cc: Maxime Coquelin Cc: net...@vger.kernel.org Cc: linux-st...@st-md-mailman.stormreply.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 4 drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 4 2 files changed, 8 insertions(+) diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c index 01c2e2d83e76..fc9954e4a772 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c @@ -85,6 +85,8 @@ static void dwmac4_rx_queue_priority(struct mac_device_info *hw, u32 value; base_register = (queue < 4) ? GMAC_RXQ_CTRL2 : GMAC_RXQ_CTRL3; + if (queue >= 4) + queue -= 4; value = readl(ioaddr + base_register); @@ -102,6 +104,8 @@ static void dwmac4_tx_queue_priority(struct mac_device_info *hw, u32 value; base_register = (queue < 4) ? GMAC_TXQ_PRTY_MAP0 : GMAC_TXQ_PRTY_MAP1; + if (queue >= 4) + queue -= 4; value = readl(ioaddr + base_register); diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c index 03a6a59650ca..85c68b7ee8c6 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c @@ -108,6 +108,8 @@ static void dwxgmac2_rx_queue_prio(struct mac_device_info *hw, u32 prio, u32 value, reg; reg = (queue < 4) ? XGMAC_RXQ_CTRL2 : XGMAC_RXQ_CTRL3; + if (queue >= 4) + queue -= 4; value = readl(ioaddr + reg); value &= ~XGMAC_PSRQ(queue); @@ -171,6 +173,8 @@ static void dwxgmac2_map_mtl_to_dma(struct mac_device_info *hw, u32 queue, u32 value, reg; reg = (queue < 4) ? XGMAC_MTL_RXQ_DMA_MAP0 : XGMAC_MTL_RXQ_DMA_MAP1; + if (queue >= 4) + queue -= 4; value = readl(ioaddr + reg); value &= ~XGMAC_QxMDMACH(queue); -- 2.7.4
[PATCH net-next 08/10] net: stmmac: Implement VLAN Hash Filtering in XGMAC
Implement the VLAN Hash Filtering feature in XGMAC core.
Signed-off-by: Jose Abreu
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/common.h | 1 +
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 10 +++
.../net/ethernet/stmicro/stmmac/dwxgmac2_core.c| 41 +++
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 1 +
drivers/net/ethernet/stmicro/stmmac/hwif.h | 5 ++
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 2 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 79 ++
7 files changed, 139 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 45a997fe571c..e1e6f67041ec 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -355,6 +355,7 @@ struct dma_features {
unsigned int frpes;
unsigned int addr64;
unsigned int rssen;
+ unsigned int vlhash;
};
/* GMAC TX FIFO is 8K, Rx FIFO is 16K */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
index eb7c7726fcd6..29bbe8218600 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
@@ -44,6 +44,7 @@
#define XGMAC_CORE_INIT_RX 0
#define XGMAC_PACKET_FILTER0x0008
#define XGMAC_FILTER_RABIT(31)
+#define XGMAC_FILTER_VTFE BIT(16)
#define XGMAC_FILTER_HPF BIT(10)
#define XGMAC_FILTER_PCF BIT(7)
#define XGMAC_FILTER_PMBIT(4)
@@ -51,6 +52,14 @@
#define XGMAC_FILTER_PRBIT(0)
#define XGMAC_HASH_TABLE(x)(0x0010 + (x) * 4)
#define XGMAC_MAX_HASH_TABLE 8
+#define XGMAC_VLAN_TAG 0x0050
+#define XGMAC_VLAN_EDVLP BIT(26)
+#define XGMAC_VLAN_VTHMBIT(25)
+#define XGMAC_VLAN_DOVLTC BIT(20)
+#define XGMAC_VLAN_ESVLBIT(18)
+#define XGMAC_VLAN_ETV BIT(16)
+#define XGMAC_VLAN_VID GENMASK(15, 0)
+#define XGMAC_VLAN_HASH_TABLE 0x0058
#define XGMAC_RXQ_CTRL00x00a0
#define XGMAC_RXQEN(x) GENMASK((x) * 2 + 1, (x) * 2)
#define XGMAC_RXQEN_SHIFT(x) ((x) * 2)
@@ -87,6 +96,7 @@
#define XGMAC_HWFEAT_MMCSELBIT(8)
#define XGMAC_HWFEAT_MGKSELBIT(7)
#define XGMAC_HWFEAT_RWKSELBIT(6)
+#define XGMAC_HWFEAT_VLHASHBIT(4)
#define XGMAC_HWFEAT_GMIISEL BIT(1)
#define XGMAC_HW_FEATURE1 0x0120
#define XGMAC_HWFEAT_RSSEN BIT(20)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index 04eec85acc59..e2dbebeb59e9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -490,6 +490,46 @@ static int dwxgmac2_rss_configure(struct mac_device_info
*hw,
return 0;
}
+static void dwxgmac2_update_vlan_hash(struct mac_device_info *hw, u32 hash,
+ bool is_double)
+{
+ void __iomem *ioaddr = hw->pcsr;
+
+ writel(hash, ioaddr + XGMAC_VLAN_HASH_TABLE);
+
+ if (hash) {
+ u32 value = readl(ioaddr + XGMAC_PACKET_FILTER);
+
+ value |= XGMAC_FILTER_VTFE;
+
+ writel(value, ioaddr + XGMAC_PACKET_FILTER);
+
+ value |= XGMAC_VLAN_VTHM | XGMAC_VLAN_ETV;
+ if (is_double) {
+ value |= XGMAC_VLAN_EDVLP;
+ value |= XGMAC_VLAN_ESVL;
+ value |= XGMAC_VLAN_DOVLTC;
+ }
+
+ writel(value, ioaddr + XGMAC_VLAN_TAG);
+ } else {
+ u32 value = readl(ioaddr + XGMAC_PACKET_FILTER);
+
+ value &= ~XGMAC_FILTER_VTFE;
+
+ writel(value, ioaddr + XGMAC_PACKET_FILTER);
+
+ value = readl(ioaddr + XGMAC_VLAN_TAG);
+
+ value &= ~(XGMAC_VLAN_VTHM | XGMAC_VLAN_ETV);
+ value &= ~(XGMAC_VLAN_EDVLP | XGMAC_VLAN_ESVL);
+ value &= ~XGMAC_VLAN_DOVLTC;
+ value &= ~XGMAC_VLAN_VID;
+
+ writel(value, ioaddr + XGMAC_VLAN_TAG);
+ }
+}
+
const struct stmmac_ops dwxgmac210_ops = {
.core_init = dwxgmac2_core_init,
.set_mac = dwxgmac2_set_mac,
@@ -521,6 +561,7 @@ const struct stmmac_ops dwxgmac210_ops = {
.set_filter = dwxgmac2_set_filter,
.set_mac_loopback = dwxgmac2_set_mac_loopback,
.rss_configu
[PATCH net-next 02/10] net: stmmac: xgmac: Implement MMC counters
Implement the MMC counters feature in XGMAC core.
Signed-off-by: Jose Abreu
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 1 +
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 1 +
drivers/net/ethernet/stmicro/stmmac/hwif.c | 4 +-
drivers/net/ethernet/stmicro/stmmac/hwif.h | 1 +
drivers/net/ethernet/stmicro/stmmac/mmc.h | 9 +
drivers/net/ethernet/stmicro/stmmac/mmc_core.c | 192 +
.../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 6 +
7 files changed, 212 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
index 3174b701aa90..86a42bc39d21 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
@@ -84,6 +84,7 @@
#define XGMAC_HWFEAT_AVSEL BIT(11)
#define XGMAC_HWFEAT_RAVSELBIT(10)
#define XGMAC_HWFEAT_ARPOFFSEL BIT(9)
+#define XGMAC_HWFEAT_MMCSELBIT(8)
#define XGMAC_HWFEAT_MGKSELBIT(7)
#define XGMAC_HWFEAT_RWKSELBIT(6)
#define XGMAC_HWFEAT_GMIISEL BIT(1)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
index a4f236e3593e..0f1c772e892a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c
@@ -356,6 +356,7 @@ static void dwxgmac2_get_hw_feature(void __iomem *ioaddr,
dma_cap->atime_stamp = (hw_cap & XGMAC_HWFEAT_TSSEL) >> 12;
dma_cap->av = (hw_cap & XGMAC_HWFEAT_AVSEL) >> 11;
dma_cap->av &= (hw_cap & XGMAC_HWFEAT_RAVSEL) >> 10;
+ dma_cap->rmon = (hw_cap & XGMAC_HWFEAT_MMCSEL) >> 8;
dma_cap->pmt_magic_frame = (hw_cap & XGMAC_HWFEAT_MGKSEL) >> 7;
dma_cap->pmt_remote_wake_up = (hw_cap & XGMAC_HWFEAT_RWKSEL) >> 6;
dma_cap->mbps_1000 = (hw_cap & XGMAC_HWFEAT_GMIISEL) >> 1;
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c
b/drivers/net/ethernet/stmicro/stmmac/hwif.c
index 6c61b753b55e..3af2e5015245 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
@@ -201,7 +201,7 @@ static const struct stmmac_hwif_entry {
.min_id = DWXGMAC_CORE_2_10,
.regs = {
.ptp_off = PTP_XGMAC_OFFSET,
- .mmc_off = 0,
+ .mmc_off = MMC_XGMAC_OFFSET,
},
.desc = &dwxgmac210_desc_ops,
.dma = &dwxgmac210_dma_ops,
@@ -209,7 +209,7 @@ static const struct stmmac_hwif_entry {
.hwtimestamp = &stmmac_ptp,
.mode = NULL,
.tc = &dwmac510_tc_ops,
- .mmc = NULL,
+ .mmc = &dwxgmac_mmc_ops,
.setup = dwxgmac2_setup,
.quirks = NULL,
},
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h
b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index 278c0dbec9d9..00539a09d1db 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -503,6 +503,7 @@ extern const struct stmmac_ops dwxgmac210_ops;
extern const struct stmmac_dma_ops dwxgmac210_dma_ops;
extern const struct stmmac_desc_ops dwxgmac210_desc_ops;
extern const struct stmmac_mmc_ops dwmac_mmc_ops;
+extern const struct stmmac_mmc_ops dwxgmac_mmc_ops;
#define GMAC_VERSION 0x0020 /* GMAC CORE Version */
#define GMAC4_VERSION 0x0110 /* GMAC4+ CORE Version */
diff --git a/drivers/net/ethernet/stmicro/stmmac/mmc.h
b/drivers/net/ethernet/stmicro/stmmac/mmc.h
index 3587ceb9faf5..a0c05925883e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/mmc.h
+++ b/drivers/net/ethernet/stmicro/stmmac/mmc.h
@@ -24,6 +24,7 @@
#define MMC_GMAC4_OFFSET 0x700
#define MMC_GMAC3_X_OFFSET 0x100
+#define MMC_XGMAC_OFFSET 0x800
struct stmmac_counters {
unsigned int mmc_tx_octetcount_gb;
@@ -116,6 +117,14 @@ struct stmmac_counters {
unsigned int mmc_rx_tcp_err_octets;
unsigned int mmc_rx_icmp_gd_octets;
unsigned int mmc_rx_icmp_err_octets;
+
+ /* FPE */
+ unsigned int mmc_tx_fpe_fragment_cntr;
+ unsigned int mmc_tx_hold_req_cntr;
+ unsigned int mmc_rx_packet_assembly_err_cntr;
+ unsigned int mmc_rx_packet_smd_err_cntr;
+ unsigned int mmc_rx_packet_assembly_ok_cntr;
+ unsigned int mmc_rx_fpe_fragment_cntr;
};
#endif /* __MMC_H__ */
diff --git a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
index a471db6d7b11..a223584
[PATCH net-next 05/10] net: stmmac: xgmac: Implement tx_queue_prio()
Implement the TX Queue Priority callback in XGMAC core.
Signed-off-by: Jose Abreu
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 4
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 19 ++-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
index 86a42bc39d21..b77091161765 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
@@ -127,6 +127,10 @@
#define XGMAC_MTL_RXQ_DMA_MAP1 0x1034
#define XGMAC_QxMDMACH(x) GENMASK((x) * 8 + 3, (x) * 8)
#define XGMAC_QxMDMACH_SHIFT(x)((x) * 8)
+#define XGMAC_TC_PRTY_MAP0 0x1040
+#define XGMAC_TC_PRTY_MAP1 0x1044
+#define XGMAC_PSTC(x) GENMASK((x) * 8 + 7, (x) * 8)
+#define XGMAC_PSTC_SHIFT(x)((x) * 8)
#define XGMAC_MTL_TXQ_OPMODE(x)(0x1100 + (0x80 * (x)))
#define XGMAC_TQS GENMASK(25, 16)
#define XGMAC_TQS_SHIFT16
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index ce6503dfc86d..bfbd5ae11540 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -118,6 +118,23 @@ static void dwxgmac2_rx_queue_prio(struct mac_device_info
*hw, u32 prio,
writel(value, ioaddr + reg);
}
+static void dwxgmac2_tx_queue_prio(struct mac_device_info *hw, u32 prio,
+ u32 queue)
+{
+ void __iomem *ioaddr = hw->pcsr;
+ u32 value, reg;
+
+ reg = (queue < 4) ? XGMAC_TC_PRTY_MAP0 : XGMAC_TC_PRTY_MAP1;
+ if (queue >= 4)
+ queue -= 4;
+
+ value = readl(ioaddr + reg);
+ value &= ~XGMAC_PSTC(queue);
+ value |= (prio << XGMAC_PSTC_SHIFT(queue)) & XGMAC_PSTC(queue);
+
+ writel(value, ioaddr + reg);
+}
+
static void dwxgmac2_prog_mtl_rx_algorithms(struct mac_device_info *hw,
u32 rx_alg)
{
@@ -428,7 +445,7 @@ const struct stmmac_ops dwxgmac210_ops = {
.rx_ipc = dwxgmac2_rx_ipc,
.rx_queue_enable = dwxgmac2_rx_queue_enable,
.rx_queue_prio = dwxgmac2_rx_queue_prio,
- .tx_queue_prio = NULL,
+ .tx_queue_prio = dwxgmac2_tx_queue_prio,
.rx_queue_routing = NULL,
.prog_mtl_rx_algorithms = dwxgmac2_prog_mtl_rx_algorithms,
.prog_mtl_tx_algorithms = dwxgmac2_prog_mtl_tx_algorithms,
--
2.7.4
[PATCH net-next 01/10] net: stmmac: xgmac: Fix XGMAC selftests
Fixup the XGMAC selftests by correctly finishing the implementation of
set_filter callback.
Result:
$ ethtool -t enp4s0
The test result is PASS
The test extra info:
1. MAC Loopback 0
2. PHY Loopback -95
3. MMC Counters -95
4. EEE -95
5. Hash Filter MC 0
6. Perfect Filter UC0
7. MC Filter0
8. UC Filter0
9. Flow Control 0
Signed-off-by: Jose Abreu
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 7 +-
.../net/ethernet/stmicro/stmmac/dwxgmac2_core.c| 83 +++---
2 files changed, 79 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
index 7f86dffb264d..3174b701aa90 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
@@ -44,11 +44,13 @@
#define XGMAC_CORE_INIT_RX 0
#define XGMAC_PACKET_FILTER0x0008
#define XGMAC_FILTER_RABIT(31)
+#define XGMAC_FILTER_HPF BIT(10)
#define XGMAC_FILTER_PCF BIT(7)
#define XGMAC_FILTER_PMBIT(4)
#define XGMAC_FILTER_HMC BIT(2)
#define XGMAC_FILTER_PRBIT(0)
#define XGMAC_HASH_TABLE(x)(0x0010 + (x) * 4)
+#define XGMAC_MAX_HASH_TABLE 8
#define XGMAC_RXQ_CTRL00x00a0
#define XGMAC_RXQEN(x) GENMASK((x) * 2 + 1, (x) * 2)
#define XGMAC_RXQEN_SHIFT(x) ((x) * 2)
@@ -99,11 +101,12 @@
#define XGMAC_MDIO_ADDR0x0200
#define XGMAC_MDIO_DATA0x0204
#define XGMAC_MDIO_C22P0x0220
-#define XGMAC_ADDR0_HIGH 0x0300
+#define XGMAC_ADDRx_HIGH(x)(0x0300 + (x) * 0x8)
+#define XGMAC_ADDR_MAX 32
#define XGMAC_AE BIT(31)
#define XGMAC_DCS GENMASK(19, 16)
#define XGMAC_DCS_SHIFT16
-#define XGMAC_ADDR0_LOW0x0304
+#define XGMAC_ADDRx_LOW(x) (0x0304 + (x) * 0x8)
#define XGMAC_ARP_ADDR 0x0c10
#define XGMAC_TIMESTAMP_STATUS 0x0d20
#define XGMAC_TXTSCBIT(15)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index 0a32c96a7854..03a6a59650ca 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -4,6 +4,8 @@
* stmmac XGMAC support.
*/
+#include
+#include
#include "stmmac.h"
#include "dwxgmac2.h"
@@ -278,10 +280,10 @@ static void dwxgmac2_set_umac_addr(struct mac_device_info
*hw,
u32 value;
value = (addr[5] << 8) | addr[4];
- writel(value | XGMAC_AE, ioaddr + XGMAC_ADDR0_HIGH);
+ writel(value | XGMAC_AE, ioaddr + XGMAC_ADDRx_HIGH(reg_n));
value = (addr[3] << 24) | (addr[2] << 16) | (addr[1] << 8) | addr[0];
- writel(value, ioaddr + XGMAC_ADDR0_LOW);
+ writel(value, ioaddr + XGMAC_ADDRx_LOW(reg_n));
}
static void dwxgmac2_get_umac_addr(struct mac_device_info *hw,
@@ -291,8 +293,8 @@ static void dwxgmac2_get_umac_addr(struct mac_device_info
*hw,
u32 hi_addr, lo_addr;
/* Read the MAC address from the hardware */
- hi_addr = readl(ioaddr + XGMAC_ADDR0_HIGH);
- lo_addr = readl(ioaddr + XGMAC_ADDR0_LOW);
+ hi_addr = readl(ioaddr + XGMAC_ADDRx_HIGH(reg_n));
+ lo_addr = readl(ioaddr + XGMAC_ADDRx_LOW(reg_n));
/* Extract the MAC address from the high and low words */
addr[0] = lo_addr & 0xff;
@@ -303,19 +305,82 @@ static void dwxgmac2_get_umac_addr(struct mac_device_info
*hw,
addr[5] = (hi_addr >> 8) & 0xff;
}
+static void dwxgmac2_set_mchash(void __iomem *ioaddr, u32 *mcfilterbits,
+ int mcbitslog2)
+{
+ int numhashregs, regs;
+
+ switch (mcbitslog2) {
+ case 6:
+ numhashregs = 2;
+ break;
+ case 7:
+ numhashregs = 4;
+ break;
+ case 8:
+ numhashregs = 8;
+ break;
+ default:
+ return;
+ }
+
+ for (regs = 0; regs < numhashregs; regs++)
+ writel(mcfilterbits[regs], ioaddr + XGMAC_HASH_TABLE(regs));
+}
+
static void dwxgmac2_set_filter(struct mac_device_info *hw,
struct net_device *dev)
{
void __iomem *ioad
[PATCH net-next 10/10] net: stmmac: Implement Safety Features in XGMAC core
XGMAC also supports Safety Features. This patch implements the
configuration and handling of this feature in XGMAC core.
Signed-off-by: Jose Abreu
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 26 ++
.../net/ethernet/stmicro/stmmac/dwxgmac2_core.c| 281 +
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 4 +
3 files changed, 311 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
index 29bbe8218600..3d8782f99f64 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
@@ -110,6 +110,12 @@
#define XGMAC_HWFEAT_RXCHCNT GENMASK(15, 12)
#define XGMAC_HWFEAT_TXQCNTGENMASK(9, 6)
#define XGMAC_HWFEAT_RXQCNTGENMASK(3, 0)
+#define XGMAC_HW_FEATURE3 0x0128
+#define XGMAC_HWFEAT_ASP GENMASK(15, 14)
+#define XGMAC_MAC_DPP_FSM_INT_STATUS 0x0150
+#define XGMAC_MAC_FSM_CONTROL 0x0158
+#define XGMAC_PRTYEN BIT(1)
+#define XGMAC_TMOUTEN BIT(0)
#define XGMAC_MDIO_ADDR0x0200
#define XGMAC_MDIO_DATA0x0204
#define XGMAC_MDIO_C22P0x0220
@@ -154,6 +160,16 @@
#define XGMAC_TC_PRTY_MAP1 0x1044
#define XGMAC_PSTC(x) GENMASK((x) * 8 + 7, (x) * 8)
#define XGMAC_PSTC_SHIFT(x)((x) * 8)
+#define XGMAC_MTL_ECC_CONTROL 0x10c0
+#define XGMAC_MTL_SAFETY_INT_STATUS0x10c4
+#define XGMAC_MEUISBIT(1)
+#define XGMAC_MECISBIT(0)
+#define XGMAC_MTL_ECC_INT_ENABLE 0x10c8
+#define XGMAC_RPCEIE BIT(12)
+#define XGMAC_ECEIEBIT(8)
+#define XGMAC_RXCEIE BIT(4)
+#define XGMAC_TXCEIE BIT(0)
+#define XGMAC_MTL_ECC_INT_STATUS 0x10cc
#define XGMAC_MTL_TXQ_OPMODE(x)(0x1100 + (0x80 * (x)))
#define XGMAC_TQS GENMASK(25, 16)
#define XGMAC_TQS_SHIFT16
@@ -218,6 +234,16 @@
#define XGMAC_TDPS GENMASK(29, 0)
#define XGMAC_RX_EDMA_CTRL 0x3044
#define XGMAC_RDPS GENMASK(29, 0)
+#define XGMAC_DMA_SAFETY_INT_STATUS0x3064
+#define XGMAC_MCSISBIT(31)
+#define XGMAC_MSUISBIT(29)
+#define XGMAC_MSCISBIT(28)
+#define XGMAC_DEUISBIT(1)
+#define XGMAC_DECISBIT(0)
+#define XGMAC_DMA_ECC_INT_ENABLE 0x3068
+#define XGMAC_DCEIEBIT(1)
+#define XGMAC_TCEIEBIT(0)
+#define XGMAC_DMA_ECC_INT_STATUS 0x306c
#define XGMAC_DMA_CH_CONTROL(x)(0x3100 + (0x80 * (x)))
#define XGMAC_PBLx8BIT(16)
#define XGMAC_DMA_CH_TX_CONTROL(x) (0x3104 + (0x80 * (x)))
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index e2dbebeb59e9..19dfb72cab11 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -530,6 +530,284 @@ static void dwxgmac2_update_vlan_hash(struct
mac_device_info *hw, u32 hash,
}
}
+struct dwxgmac3_error_desc {
+ bool valid;
+ const char *desc;
+ const char *detailed_desc;
+};
+
+#define STAT_OFF(field)offsetof(struct stmmac_safety_stats,
field)
+
+static void dwxgmac3_log_error(struct net_device *ndev, u32 value, bool corr,
+ const char *module_name,
+ const struct dwxgmac3_error_desc *desc,
+ unsigned long field_offset,
+ struct stmmac_safety_stats *stats)
+{
+ unsigned long loc, mask;
+ u8 *bptr = (u8 *)stats;
+ unsigned long *ptr;
+
+ ptr = (unsigned long *)(bptr + field_offset);
+
+ mask = value;
+ for_each_set_bit(loc, &mask, 32) {
+ netdev_err(ndev, "Found %s error in %s: '%s: %s'\n", corr ?
+ "correctable" : "uncorrectable", module_name,
+ desc[loc].desc, desc[loc].detailed_desc);
+
+ /* Update counters */
+ ptr[loc]++;
+ }
+}
+
+static const struct dwxgmac3_error_desc dwxgmac3_mac_errors[32]= {
+ { true, "ATPES", "Application Transmit Interface Parity Check Error" },
+ { true, "DPES", "Descriptor Cache Data Path Parity Check Error" },
+ { true, "TPES", "TSO Dat
[PATCH net-next 06/10] net: stmmac: Implement RSS and enable it in XGMAC core
Implement the RSS functionality and add the corresponding callbacks in
XGMAC core.
Signed-off-by: Jose Abreu
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/common.h | 5 ++
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 18 +-
.../net/ethernet/stmicro/stmmac/dwxgmac2_core.c| 52 +++
.../net/ethernet/stmicro/stmmac/dwxgmac2_descs.c | 29 +
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 1 +
drivers/net/ethernet/stmicro/stmmac/hwif.h | 11
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 9 +++
.../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 75 ++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 38 ++-
include/linux/stmmac.h | 1 +
10 files changed, 236 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index ed872eed1cab..45a997fe571c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -354,6 +354,7 @@ struct dma_features {
unsigned int frpbs;
unsigned int frpes;
unsigned int addr64;
+ unsigned int rssen;
};
/* GMAC TX FIFO is 8K, Rx FIFO is 16K */
@@ -381,6 +382,10 @@ struct dma_features {
#define JUMBO_LEN 9000
+/* Receive Side Scaling */
+#define STMMAC_RSS_HASH_KEY_SIZE 40
+#define STMMAC_RSS_MAX_TABLE_SIZE 256
+
extern const struct stmmac_desc_ops enh_desc_ops;
extern const struct stmmac_desc_ops ndesc_ops;
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
index b77091161765..eb7c7726fcd6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
@@ -89,6 +89,7 @@
#define XGMAC_HWFEAT_RWKSELBIT(6)
#define XGMAC_HWFEAT_GMIISEL BIT(1)
#define XGMAC_HW_FEATURE1 0x0120
+#define XGMAC_HWFEAT_RSSEN BIT(20)
#define XGMAC_HWFEAT_TSOEN BIT(18)
#define XGMAC_HWFEAT_ADDR64GENMASK(15, 14)
#define XGMAC_HWFEAT_TXFIFOSIZEGENMASK(10, 6)
@@ -109,6 +110,17 @@
#define XGMAC_DCS_SHIFT16
#define XGMAC_ADDRx_LOW(x) (0x0304 + (x) * 0x8)
#define XGMAC_ARP_ADDR 0x0c10
+#define XGMAC_RSS_CTRL 0x0c80
+#define XGMAC_UDP4TE BIT(3)
+#define XGMAC_TCP4TE BIT(2)
+#define XGMAC_IP2TEBIT(1)
+#define XGMAC_RSSE BIT(0)
+#define XGMAC_RSS_ADDR 0x0c88
+#define XGMAC_RSSIA_SHIFT 8
+#define XGMAC_ADDRTBIT(2)
+#define XGMAC_CT BIT(1)
+#define XGMAC_OB BIT(0)
+#define XGMAC_RSS_DATA 0x0c8c
#define XGMAC_TIMESTAMP_STATUS 0x0d20
#define XGMAC_TXTSCBIT(15)
#define XGMAC_TXTIMESTAMP_NSEC 0x0d30
@@ -125,8 +137,9 @@
#define XGMAC_MTL_INT_STATUS 0x1020
#define XGMAC_MTL_RXQ_DMA_MAP0 0x1030
#define XGMAC_MTL_RXQ_DMA_MAP1 0x1034
-#define XGMAC_QxMDMACH(x) GENMASK((x) * 8 + 3, (x) * 8)
+#define XGMAC_QxMDMACH(x) GENMASK((x) * 8 + 7, (x) * 8)
#define XGMAC_QxMDMACH_SHIFT(x)((x) * 8)
+#define XGMAC_QDDMACH BIT(7)
#define XGMAC_TC_PRTY_MAP0 0x1040
#define XGMAC_TC_PRTY_MAP1 0x1044
#define XGMAC_PSTC(x) GENMASK((x) * 8 + 7, (x) * 8)
@@ -261,6 +274,9 @@
#define XGMAC_RDES3_IOCBIT(30)
#define XGMAC_RDES3_LD BIT(28)
#define XGMAC_RDES3_CDABIT(27)
+#define XGMAC_RDES3_RSVBIT(26)
+#define XGMAC_RDES3_L34T GENMASK(23, 20)
+#define XGMAC_RDES3_L34T_SHIFT 20
#define XGMAC_RDES3_ES BIT(15)
#define XGMAC_RDES3_PL GENMASK(13, 0)
#define XGMAC_RDES3_TSDBIT(6)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index bfbd5ae11540..04eec85acc59 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include "stmmac.h"
#include "dwxgmac2.h"
@@ -439,6 +440,56 @@ static void dwxgmac2_set_mac_loopback(void __iomem
*ioaddr, bool enable)
writel(value, ioaddr + XGMAC_RX_CONFIG);
}
+static int dwxgmac2_rss_write_reg(void __iomem *ioaddr, bool is_k
[PATCH net-next 07/10] net: stmmac: selftests: Add RSS test
Add a test for RSS in the stmmac selftests.
Signed-off-by: Jose Abreu
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
.../net/ethernet/stmicro/stmmac/stmmac_selftests.c| 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
index a97b1ea76438..83b775a8cedc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
@@ -700,6 +700,21 @@ static int stmmac_test_flowctrl(struct stmmac_priv *priv)
return ret;
}
+static int stmmac_test_rss(struct stmmac_priv *priv)
+{
+ struct stmmac_packet_attrs attr = { };
+
+ if (!priv->dma_cap.rssen || !priv->rss.enable)
+ return -EOPNOTSUPP;
+
+ attr.dst = priv->dev->dev_addr;
+ attr.exp_hash = true;
+ attr.sport = 0x321;
+ attr.dport = 0x123;
+
+ return __stmmac_test_loopback(priv, &attr);
+}
+
#define STMMAC_LOOPBACK_NONE 0
#define STMMAC_LOOPBACK_MAC1
#define STMMAC_LOOPBACK_PHY2
@@ -745,6 +760,10 @@ static const struct stmmac_test {
.name = "Flow Control ",
.lb = STMMAC_LOOPBACK_PHY,
.fn = stmmac_test_flowctrl,
+ }, {
+ .name = "RSS ",
+ .lb = STMMAC_LOOPBACK_PHY,
+ .fn = stmmac_test_rss,
},
};
--
2.7.4
[PATCH net-next 09/10] net: stmmac: selftests: Add test for VLAN and Double VLAN Filtering
Add a selftest for VLAN and Double VLAN Filtering in stmmac.
Signed-off-by: Jose Abreu
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
.../net/ethernet/stmicro/stmmac/stmmac_selftests.c | 205 +
1 file changed, 205 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
index 83b775a8cedc..6b08bb15af15 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
@@ -715,6 +715,203 @@ static int stmmac_test_rss(struct stmmac_priv *priv)
return __stmmac_test_loopback(priv, &attr);
}
+static int stmmac_test_vlan_validate(struct sk_buff *skb,
+struct net_device *ndev,
+struct packet_type *pt,
+struct net_device *orig_ndev)
+{
+ struct stmmac_test_priv *tpriv = pt->af_packet_priv;
+ struct stmmachdr *shdr;
+ struct ethhdr *ehdr;
+ struct udphdr *uhdr;
+ struct iphdr *ihdr;
+
+ skb = skb_unshare(skb, GFP_ATOMIC);
+ if (!skb)
+ goto out;
+
+ if (skb_linearize(skb))
+ goto out;
+ if (skb_headlen(skb) < (STMMAC_TEST_PKT_SIZE - ETH_HLEN))
+ goto out;
+
+ ehdr = (struct ethhdr *)skb_mac_header(skb);
+ if (!ether_addr_equal(ehdr->h_dest, tpriv->packet->dst))
+ goto out;
+
+ ihdr = ip_hdr(skb);
+ if (tpriv->double_vlan)
+ ihdr = (struct iphdr *)(skb_network_header(skb) + 4);
+ if (ihdr->protocol != IPPROTO_UDP)
+ goto out;
+
+ uhdr = (struct udphdr *)((u8 *)ihdr + 4 * ihdr->ihl);
+ if (uhdr->dest != htons(tpriv->packet->dport))
+ goto out;
+
+ shdr = (struct stmmachdr *)((u8 *)uhdr + sizeof(*uhdr));
+ if (shdr->magic != cpu_to_be64(STMMAC_TEST_PKT_MAGIC))
+ goto out;
+
+ tpriv->ok = true;
+ complete(&tpriv->comp);
+
+out:
+ kfree_skb(skb);
+ return 0;
+}
+
+static int stmmac_test_vlanfilt(struct stmmac_priv *priv)
+{
+ struct stmmac_packet_attrs attr = { };
+ struct stmmac_test_priv *tpriv;
+ struct sk_buff *skb = NULL;
+ int ret = 0, i;
+
+ if (!priv->dma_cap.vlhash)
+ return -EOPNOTSUPP;
+
+ tpriv = kzalloc(sizeof(*tpriv), GFP_KERNEL);
+ if (!tpriv)
+ return -ENOMEM;
+
+ tpriv->ok = false;
+ init_completion(&tpriv->comp);
+
+ tpriv->pt.type = htons(ETH_P_IP);
+ tpriv->pt.func = stmmac_test_vlan_validate;
+ tpriv->pt.dev = priv->dev;
+ tpriv->pt.af_packet_priv = tpriv;
+ tpriv->packet = &attr;
+
+ /*
+* As we use HASH filtering, false positives may appear. This is a
+* specially chosen ID so that adjacent IDs (+4) have different
+* HASH values.
+*/
+ tpriv->vlan_id = 0x123;
+ dev_add_pack(&tpriv->pt);
+
+ ret = vlan_vid_add(priv->dev, htons(ETH_P_8021Q), tpriv->vlan_id);
+ if (ret)
+ goto cleanup;
+
+ for (i = 0; i < 4; i++) {
+ attr.vlan = 1;
+ attr.vlan_id_out = tpriv->vlan_id + i;
+ attr.dst = priv->dev->dev_addr;
+ attr.sport = 9;
+ attr.dport = 9;
+
+ skb = stmmac_test_get_udp_skb(priv, &attr);
+ if (!skb) {
+ ret = -ENOMEM;
+ goto vlan_del;
+ }
+
+ skb_set_queue_mapping(skb, 0);
+ ret = dev_queue_xmit(skb);
+ if (ret)
+ goto vlan_del;
+
+ wait_for_completion_timeout(&tpriv->comp, STMMAC_LB_TIMEOUT);
+ ret = !tpriv->ok;
+ if (ret && !i) {
+ goto vlan_del;
+ } else if (!ret && i) {
+ ret = -1;
+ goto vlan_del;
+ } else {
+ ret = 0;
+ }
+
+ tpriv->ok = false;
+ }
+
+vlan_del:
+ vlan_vid_del(priv->dev, htons(ETH_P_8021Q), tpriv->vlan_id);
+cleanup:
+ dev_remove_pack(&tpriv->pt);
+ kfree(tpriv);
+ return ret;
+}
+
+static int stmmac_test_dvlanfilt(struct stmmac_priv *priv)
+{
+ struct stmmac_packet_attrs attr = { };
+ struct stmmac_test_priv *tpriv;
+ struct sk_buff *skb = NULL;
+ int ret = 0, i;
+
+ if (!priv->dma_cap.vlhash)
+ return -EOPNOTSUPP;
+
+ tpriv = kzalloc(sizeof(*tpriv), GFP_KERNEL);
+ if (!tpriv)
+ return -ENOMEM;
+
+ tpriv->ok = false;
+ tpriv->double_vlan = true;
+
[PATCH net-next 00/10] net: stmmac: Misc improvements for XGMAC (Part 1 of 3)
[ Breaking down the previous 26 patch series into 3 series ]
[ This series depend on 3caa61c20875 ("net: stmmac: Sync RX Buffer upon
allocation")
which is already in -net but not -next ]
Misc improvements for -next which adds new features in XGMAC cores.
More info in commit logs.
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
Jose Abreu (10):
net: stmmac: xgmac: Fix XGMAC selftests
net: stmmac: xgmac: Implement MMC counters
net: stmmac: Fix issues when number of Queues >= 4
net: stmmac: xgmac: Implement set_mtl_tx_queue_weight()
net: stmmac: xgmac: Implement tx_queue_prio()
net: stmmac: Implement RSS and enable it in XGMAC core
net: stmmac: selftests: Add RSS test
net: stmmac: Implement VLAN Hash Filtering in XGMAC
net: stmmac: selftests: Add test for VLAN and Double VLAN Filtering
net: stmmac: Implement Safety Features in XGMAC core
drivers/net/ethernet/stmicro/stmmac/common.h | 6 +
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 4 +
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 66 ++-
.../net/ethernet/stmicro/stmmac/dwxgmac2_core.c| 502 -
.../net/ethernet/stmicro/stmmac/dwxgmac2_descs.c | 29 ++
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_dma.c | 7 +
drivers/net/ethernet/stmicro/stmmac/hwif.c | 4 +-
drivers/net/ethernet/stmicro/stmmac/hwif.h | 17 +
drivers/net/ethernet/stmicro/stmmac/mmc.h | 9 +
drivers/net/ethernet/stmicro/stmmac/mmc_core.c | 192
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 11 +
.../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 81
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 117 -
.../net/ethernet/stmicro/stmmac/stmmac_selftests.c | 224 +
include/linux/stmmac.h | 1 +
15 files changed, 1252 insertions(+), 18 deletions(-)
--
2.7.4
[PATCH net-next 04/10] net: stmmac: xgmac: Implement set_mtl_tx_queue_weight()
Implement the TX Queue Weight callback. In order for this to be active
we also need to set ETS algorithm when configuring Queue.
Signed-off-by: Jose Abreu
---
Cc: Giuseppe Cavallaro
Cc: Alexandre Torgue
Cc: Jose Abreu
Cc: "David S. Miller"
Cc: Maxime Coquelin
Cc: net...@vger.kernel.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
.../net/ethernet/stmicro/stmmac/dwxgmac2_core.c| 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index 85c68b7ee8c6..ce6503dfc86d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -144,7 +144,9 @@ static void dwxgmac2_prog_mtl_tx_algorithms(struct
mac_device_info *hw,
u32 tx_alg)
{
void __iomem *ioaddr = hw->pcsr;
+ bool ets = true;
u32 value;
+ int i;
value = readl(ioaddr + XGMAC_MTL_OPMODE);
value &= ~XGMAC_ETSALG;
@@ -160,10 +162,28 @@ static void dwxgmac2_prog_mtl_tx_algorithms(struct
mac_device_info *hw,
value |= XGMAC_DWRR;
break;
default:
+ ets = false;
break;
}
writel(value, ioaddr + XGMAC_MTL_OPMODE);
+
+ /* Set ETS if desired */
+ for (i = 0; i < MTL_MAX_TX_QUEUES; i++) {
+ value = readl(ioaddr + XGMAC_MTL_TCx_ETS_CONTROL(i));
+ value &= ~XGMAC_TSA;
+ if (ets)
+ value |= XGMAC_ETS;
+ writel(value, ioaddr + XGMAC_MTL_TCx_ETS_CONTROL(i));
+ }
+}
+
+static void dwxgmac2_set_mtl_tx_queue_weight(struct mac_device_info *hw,
+u32 weight, u32 queue)
+{
+ void __iomem *ioaddr = hw->pcsr;
+
+ writel(weight, ioaddr + XGMAC_MTL_TCx_QUANTUM_WEIGHT(queue));
}
static void dwxgmac2_map_mtl_to_dma(struct mac_device_info *hw, u32 queue,
@@ -412,7 +432,7 @@ const struct stmmac_ops dwxgmac210_ops = {
.rx_queue_routing = NULL,
.prog_mtl_rx_algorithms = dwxgmac2_prog_mtl_rx_algorithms,
.prog_mtl_tx_algorithms = dwxgmac2_prog_mtl_tx_algorithms,
- .set_mtl_tx_queue_weight = NULL,
+ .set_mtl_tx_queue_weight = dwxgmac2_set_mtl_tx_queue_weight,
.map_mtl_to_dma = dwxgmac2_map_mtl_to_dma,
.config_cbs = dwxgmac2_config_cbs,
.dump_regs = NULL,
--
2.7.4
[PATCH v7 1/3] PM / wakeup: Drop wakeup_source_init(), wakeup_source_prepare()
wakeup_source_init() has no users. Remove it.
As a result, wakeup_source_prepare() is only called from
wakeup_source_create(). Merge wakeup_source_prepare() into
wakeup_source_create() and remove it.
Signed-off-by: Tri Vo
---
drivers/base/power/wakeup.c | 33 +
include/linux/pm_wakeup.h | 11 ---
2 files changed, 13 insertions(+), 31 deletions(-)
diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
index ee31d4f8d856..3938892c8903 100644
--- a/drivers/base/power/wakeup.c
+++ b/drivers/base/power/wakeup.c
@@ -72,23 +72,6 @@ static struct wakeup_source deleted_ws = {
.lock = __SPIN_LOCK_UNLOCKED(deleted_ws.lock),
};
-/**
- * wakeup_source_prepare - Prepare a new wakeup source for initialization.
- * @ws: Wakeup source to prepare.
- * @name: Pointer to the name of the new wakeup source.
- *
- * Callers must ensure that the @name string won't be freed when @ws is still
in
- * use.
- */
-void wakeup_source_prepare(struct wakeup_source *ws, const char *name)
-{
- if (ws) {
- memset(ws, 0, sizeof(*ws));
- ws->name = name;
- }
-}
-EXPORT_SYMBOL_GPL(wakeup_source_prepare);
-
/**
* wakeup_source_create - Create a struct wakeup_source object.
* @name: Name of the new wakeup source.
@@ -96,13 +79,23 @@ EXPORT_SYMBOL_GPL(wakeup_source_prepare);
struct wakeup_source *wakeup_source_create(const char *name)
{
struct wakeup_source *ws;
+ const char *ws_name;
- ws = kmalloc(sizeof(*ws), GFP_KERNEL);
+ ws = kzalloc(sizeof(*ws), GFP_KERNEL);
if (!ws)
- return NULL;
+ goto err_ws;
+
+ ws_name = kstrdup_const(name, GFP_KERNEL);
+ if (!ws_name)
+ goto err_name;
+ ws->name = ws_name;
- wakeup_source_prepare(ws, name ? kstrdup_const(name, GFP_KERNEL) :
NULL);
return ws;
+
+err_name:
+ kfree(ws);
+err_ws:
+ return NULL;
}
EXPORT_SYMBOL_GPL(wakeup_source_create);
diff --git a/include/linux/pm_wakeup.h b/include/linux/pm_wakeup.h
index 91027602d137..c0cad2d8f800 100644
--- a/include/linux/pm_wakeup.h
+++ b/include/linux/pm_wakeup.h
@@ -81,7 +81,6 @@ static inline void device_set_wakeup_path(struct device *dev)
}
/* drivers/base/power/wakeup.c */
-extern void wakeup_source_prepare(struct wakeup_source *ws, const char *name);
extern struct wakeup_source *wakeup_source_create(const char *name);
extern void wakeup_source_destroy(struct wakeup_source *ws);
extern void wakeup_source_add(struct wakeup_source *ws);
@@ -112,9 +111,6 @@ static inline bool device_can_wakeup(struct device *dev)
return dev->power.can_wakeup;
}
-static inline void wakeup_source_prepare(struct wakeup_source *ws,
-const char *name) {}
-
static inline struct wakeup_source *wakeup_source_create(const char *name)
{
return NULL;
@@ -181,13 +177,6 @@ static inline void pm_wakeup_dev_event(struct device *dev,
unsigned int msec,
#endif /* !CONFIG_PM_SLEEP */
-static inline void wakeup_source_init(struct wakeup_source *ws,
- const char *name)
-{
- wakeup_source_prepare(ws, name);
- wakeup_source_add(ws);
-}
-
static inline void __pm_wakeup_event(struct wakeup_source *ws, unsigned int
msec)
{
return pm_wakeup_ws_event(ws, msec, false);
--
2.22.0.770.g0f2c4a37fd-goog
[PATCH v7 2/3] PM / wakeup: Use wakeup_source_register() in wakelock.c
kernel/power/wakelock.c duplicates wakeup source creation and
registration code from drivers/base/power/wakeup.c.
Change struct wakelock's wakeup source to a pointer and use
wakeup_source_register() function to create and register said wakeup
source. Use wakeup_source_unregister() on cleanup path.
Signed-off-by: Tri Vo
---
kernel/power/wakelock.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/kernel/power/wakelock.c b/kernel/power/wakelock.c
index 4210152e56f0..d1eb7fd98b64 100644
--- a/kernel/power/wakelock.c
+++ b/kernel/power/wakelock.c
@@ -27,7 +27,7 @@ static DEFINE_MUTEX(wakelocks_lock);
struct wakelock {
char*name;
struct rb_node node;
- struct wakeup_sourcews;
+ struct wakeup_source*ws;
#ifdef CONFIG_PM_WAKELOCKS_GC
struct list_headlru;
#endif
@@ -46,7 +46,7 @@ ssize_t pm_show_wakelocks(char *buf, bool show_active)
for (node = rb_first(&wakelocks_tree); node; node = rb_next(node)) {
wl = rb_entry(node, struct wakelock, node);
- if (wl->ws.active == show_active)
+ if (wl->ws->active == show_active)
str += scnprintf(str, end - str, "%s ", wl->name);
}
if (str > buf)
@@ -112,16 +112,16 @@ static void __wakelocks_gc(struct work_struct *work)
u64 idle_time_ns;
bool active;
- spin_lock_irq(&wl->ws.lock);
- idle_time_ns = ktime_to_ns(ktime_sub(now, wl->ws.last_time));
- active = wl->ws.active;
- spin_unlock_irq(&wl->ws.lock);
+ spin_lock_irq(&wl->ws->lock);
+ idle_time_ns = ktime_to_ns(ktime_sub(now, wl->ws->last_time));
+ active = wl->ws->active;
+ spin_unlock_irq(&wl->ws->lock);
if (idle_time_ns < ((u64)WL_GC_TIME_SEC * NSEC_PER_SEC))
break;
if (!active) {
- wakeup_source_remove(&wl->ws);
+ wakeup_source_unregister(wl->ws);
rb_erase(&wl->node, &wakelocks_tree);
list_del(&wl->lru);
kfree(wl->name);
@@ -187,9 +187,15 @@ static struct wakelock *wakelock_lookup_add(const char
*name, size_t len,
kfree(wl);
return ERR_PTR(-ENOMEM);
}
- wl->ws.name = wl->name;
- wl->ws.last_time = ktime_get();
- wakeup_source_add(&wl->ws);
+
+ wl->ws = wakeup_source_register(wl->name);
+ if (!wl->ws) {
+ kfree(wl->name);
+ kfree(wl);
+ return ERR_PTR(-ENOMEM);
+ }
+ wl->ws->last_time = ktime_get();
+
rb_link_node(&wl->node, parent, node);
rb_insert_color(&wl->node, &wakelocks_tree);
wakelocks_lru_add(wl);
@@ -233,9 +239,9 @@ int pm_wake_lock(const char *buf)
u64 timeout_ms = timeout_ns + NSEC_PER_MSEC - 1;
do_div(timeout_ms, NSEC_PER_MSEC);
- __pm_wakeup_event(&wl->ws, timeout_ms);
+ __pm_wakeup_event(wl->ws, timeout_ms);
} else {
- __pm_stay_awake(&wl->ws);
+ __pm_stay_awake(wl->ws);
}
wakelocks_lru_most_recent(wl);
@@ -271,7 +277,7 @@ int pm_wake_unlock(const char *buf)
ret = PTR_ERR(wl);
goto out;
}
- __pm_relax(&wl->ws);
+ __pm_relax(wl->ws);
wakelocks_lru_most_recent(wl);
wakelocks_gc();
--
2.22.0.770.g0f2c4a37fd-goog
[PATCH v7 3/3] PM / wakeup: Show wakeup sources stats in sysfs
Add an ID and a device pointer to 'struct wakeup_source'. Use them to to expose wakeup sources statistics in sysfs under /sys/class/wakeup/wakeup/*. Co-developed-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman Co-developed-by: Stephen Boyd Signed-off-by: Stephen Boyd Signed-off-by: Tri Vo Tested-by: Tri Vo Tested-by: Kalesh Singh --- Documentation/ABI/testing/sysfs-class-wakeup | 76 + drivers/acpi/device_pm.c | 3 +- drivers/base/power/Makefile | 2 +- drivers/base/power/power.h | 9 ++ drivers/base/power/wakeup.c | 28 +++- drivers/base/power/wakeup_stats.c| 161 +++ fs/eventpoll.c | 4 +- include/linux/pm_wakeup.h| 10 +- kernel/power/autosleep.c | 2 +- kernel/power/wakelock.c | 2 +- kernel/time/alarmtimer.c | 2 +- 11 files changed, 286 insertions(+), 13 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-wakeup create mode 100644 drivers/base/power/wakeup_stats.c diff --git a/Documentation/ABI/testing/sysfs-class-wakeup b/Documentation/ABI/testing/sysfs-class-wakeup new file mode 100644 index ..754aab8b6dcd --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-wakeup @@ -0,0 +1,76 @@ +What: /sys/class/wakeup/ +Date: June 2019 +Contact: Tri Vo +Description: + The /sys/class/wakeup/ directory contains pointers to all + wakeup sources in the kernel at that moment in time. + +What: /sys/class/wakeup/.../name +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the name of the wakeup source. + +What: /sys/class/wakeup/.../active_count +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the number of times the wakeup source was + activated. + +What: /sys/class/wakeup/.../event_count +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the number of signaled wakeup events + associated with the wakeup source. + +What: /sys/class/wakeup/.../wakeup_count +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the number of times the wakeup source might + abort suspend. + +What: /sys/class/wakeup/.../expire_count +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the number of times the wakeup source's + timeout has expired. + +What: /sys/class/wakeup/.../active_time_ms +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the amount of time the wakeup source has + been continuously active, in milliseconds. If the wakeup + source is not active, this file contains '0'. + +What: /sys/class/wakeup/.../total_time_ms +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the total amount of time this wakeup source + has been active, in milliseconds. + +What: /sys/class/wakeup/.../max_time_ms +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the maximum amount of time this wakeup + source has been continuously active, in milliseconds. + +What: /sys/class/wakeup/.../last_change_ms +Date: June 2019 +Contact: Tri Vo +Description: + This file contains the monotonic clock time when the wakeup + source was touched last time, in milliseconds. + +What: /sys/class/wakeup/.../prevent_suspend_time_ms +Date: June 2019 +Contact: Tri Vo +Description: + The file contains the total amount of time this wakeup source + has been preventing autosleep, in milliseconds. diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c index 28cffaaf9d82..91634e2dba8a 100644 --- a/drivers/acpi/device_pm.c +++ b/drivers/acpi/device_pm.c @@ -495,7 +495,8 @@ acpi_status acpi_add_pm_notifier(struct acpi_device *adev, struct device *dev, goto out; mutex_lock(&acpi_pm_notifier_lock); - adev->wakeup.ws = wakeup_source_register(dev_name(&adev->dev)); + adev->wakeup.ws = wakeup_source_register(&adev->dev, +dev_name(&adev->dev)); adev->wakeup.context.dev = dev; adev->wakeup.context.func = func; adev->wakeup.flags.notifier_present = true; diff --git a/drivers/base/power/Makefile b/drivers/base/power/Makefile index e1bb691cf8f1..ec5bb190b9d0 100644 --- a/drivers/base/power/Makefile +++ b/drivers/base/power/Makefile @@ -1,6 +1,6 @@ # SPDX-License-Identifier:
[PATCH v7 0/3] PM / wakeup: show wakeup sources stats in sysfs
Userspace can use wakeup_sources debugfs node to plot history of suspend blocking wakeup sources over device's boot cycle. This information can then be used (1) for power-specific bug reporting and (2) towards attributing battery consumption to specific processes over a period of time. However, debugfs doesn't have stable ABI. For this reason, create a 'struct device' to expose wakeup sources statistics in sysfs under /sys/class/wakeup/wakeup/*. Patch 1 and 2 do some cleanup to simplify our changes to how wakeup sources are created. Patch 3 implements wakeup sources stats in sysfs. Tri Vo (3): PM / wakeup: Drop wakeup_source_init(), wakeup_source_prepare() PM / wakeup: Use wakeup_source_register() in wakelock.c PM / wakeup: Show wakeup sources stats in sysfs Documentation/ABI/testing/sysfs-class-wakeup | 76 + drivers/acpi/device_pm.c | 3 +- drivers/base/power/Makefile | 2 +- drivers/base/power/power.h | 9 ++ drivers/base/power/wakeup.c | 59 --- drivers/base/power/wakeup_stats.c| 161 +++ fs/eventpoll.c | 4 +- include/linux/pm_wakeup.h| 21 +-- kernel/power/autosleep.c | 2 +- kernel/power/wakelock.c | 32 ++-- kernel/time/alarmtimer.c | 2 +- 11 files changed, 316 insertions(+), 55 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-wakeup create mode 100644 drivers/base/power/wakeup_stats.c v2: - Updated Documentation/ABI/, as per Greg. - Removed locks in attribute functions, as per Greg. - Lifetimes of struct wakelock and struck wakeup_source are now different due to the latter embedding a refcounted kobject. Changed it so that struct wakelock only has a pointer to struct wakeup_source, instead of embedding it. - Added CONFIG_PM_SLEEP_STATS that enables/disables wakeup source statistics in sysfs. v3: Changes by Greg: - Reworked code to use 'struct device' instead of raw kobjects. - Updated documentation file. - Only link wakeup_stats.o when CONFIG_PM_SLEEP_STATS is enabled. Changes by Tri: - Reverted changes to kernel/power/wakelock.c. 'struct device' hides kobject operations. So no need to handle lifetimes in wakelock.c v4: - Added 'Co-developed-by:' and 'Tested-by:' fields to commit message. - Moved new documentation to a separate file Documentation/ABI/testing/sysfs-class-wakeup, as per Greg. - Fixed copyright header in drivers/base/power/wakeup_stats.c, as per Greg. v5: - Removed CONFIG_PM_SLEEP_STATS - Used PTR_ERR_OR_ZERO instead of if(IS_ERR(...)) + PTR_ERR, reported by kbuild test robot - Stephen reported that a call to device_init_wakeup() and writing 'enabled' to that device's power/wakeup file results in multiple wakeup source being allocated for that device. Changed device_wakeup_enable() to check if device wakeup was previously enabled. Changes by Stephen: - Changed stats location from /sys/class/wakeup//* to /sys/class/wakeup/wakeup/*, where ID is an IDA-allocated integer. This avoids name collisions in /sys/class/wakeup/ directory. - Added a "name" attribute to wakeup sources, and updated documentation. - Device registering the wakeup source is now the parent of the wakeup source. Updated wakeup_source_register()'s signature and its callers accordingly. v6: - Changed stats location to /sys/class/wakeup/ws/* - Replaced ida_simple_get()/ida_simple_remove() with ida_alloc()/ida_free() as the former is deprecated. - Reverted changes to device_init_wakeup(). Rafael is preparing a patch to deal with extra wakeup source allocation in a separate patch. v7: - Removed wakeup_source_init(), wakeup_source_prepare(). - Removed duplicate wakeup source creation code from kernel/power/wakelock. - Moved ID allocation to wakeup source object creation time. - Changed stats location back to /sys/class/wakeup/wakeup/* - Remove wakeup source device's "power" attributes. -- 2.22.0.770.g0f2c4a37fd-goog
Re: [PATCH net] mvpp2: fix panic on module removal
From: Matteo Croce Date: Wed, 31 Jul 2019 20:31:16 +0200 > mvpp2 uses a delayed workqueue to gather traffic statistics. > On module removal the workqueue can be destroyed before calling > cancel_delayed_work_sync() on its works. > Fix it by moving the destroy_workqueue() call after mvpp2_port_remove(). Please post a new version with the flush_workqueue() removed.
Re: [PATCH V2 01/10] x86/CPU: Expose if cache is inclusive of lower level caches
Hi Borislav,
On 8/3/2019 2:44 AM, Borislav Petkov wrote:
> On Fri, Aug 02, 2019 at 01:11:13PM -0700, Reinette Chatre wrote:
>> This patch only makes it possible to determine whether cache is
>> inclusive for some x86 platforms while all platforms of all
>> architectures are given visibility into this new "inclusive" cache
>> information field within the global "struct cacheinfo".
>
> And this begs the question: do the other architectures even need that
> thing exposed? As it is now, this is x86-only so I'm wondering whether
> adding all that machinery to the generic struct cacheinfo is even needed
> at this point.
I do not know if more users would appear in the future but the goal of
this patch is to make this information available to resctrl. Since there
are a few ways to do so I really appreciate your guidance on how to do
this right. I'd be happy to make needed changes.
> TBH, I'd do it differently: read CPUID at init time and cache the
> information whether the cache is inclusive locally and be done with it.
> It is going to be a single system-wide bit anyway as I'd strongly assume
> cache settings like inclusivity should be the same across the whole
> system.
I've been digesting your comment and tried a few options but I have been
unable to come up with something that fulfill all your suggestions -
specifically the "single system-wide bit" one. These areas of code are
unfamiliar to me so I am not confident what I came up with for other
suggestions are the right way either.
So far it seems I can do the following:
Introduce a new bitfield into struct cpuinfo_x86. There is one existing
bitfield in this structure ("initialized") so we could add a new one
("x86_cache_l3_inclusive"?) just before it. With this information
included in this struct it becomes available via the global
boot_cpu_data, this seems to address the "system-wide bit" but this
struct is also maintained for all other CPUs on the system so may not be
what you had in mind (not a "single system-wide bit")?
If proceeding with inclusion into struct cpuinfo_x86 this new bitfield
can be initialized within init_intel_cacheinfo(). There are a few cache
properties within cpuinfo_x86 and they are initialized in a variety of
paths. init_intel_cacheinfo() is initialized via init_intel() and it
already has the needed CPUID information available making initialization
here straight forward. Alternatively there is also identify_cpu() that
also initializes many cache properties ... but would need some more code
to obtain needed values.
Finally, if the above is done, the resctrl code could just refer to this
new property directly as obtained from boot_cpu_data.x86_cache_l3_inclusive
What do you think?
>
> When the other arches do need it, we can extract that info "up" into the
> generic layer.
Reinette
Re: [PATCH net] net: dsa: mv88e6xxx: drop adjust_link to enabled phylink
From: Hubert Feurstein
Date: Wed, 31 Jul 2019 17:42:39 +0200
> We have to drop the adjust_link callback in order to finally migrate to
> phylink.
>
> Otherwise we get the following warning during startup:
> "mv88e6xxx 2188000.ethernet-1:10: Using legacy PHYLIB callbacks. Please
>migrate to PHYLINK!"
>
> The warning is generated in the function dsa_port_link_register_of in
> dsa/port.c:
>
> int dsa_port_link_register_of(struct dsa_port *dp)
> {
> struct dsa_switch *ds = dp->ds;
>
> if (!ds->ops->adjust_link)
> return dsa_port_phylink_register(dp);
>
> dev_warn(ds->dev,
>"Using legacy PHYLIB callbacks. Please migrate to PHYLINK!\n");
> [...]
> }
>
> Signed-off-by: Hubert Feurstein
Applied.
Re: [PATCH v2 2/2] cxgb4: smt: Use refcount_t for refcount
From: Chuhong Yuan
Date: Fri, 2 Aug 2019 16:35:47 +0800
> refcount_t is better for reference counters since its
> implementation can prevent overflows.
> So convert atomic_t ref counters to refcount_t.
>
> Signed-off-by: Chuhong Yuan
> ---
> Changes in v2:
> - Convert refcount from 0-base to 1-base.
The existing code is buggy and should be fixed before you start making
conversions to it.
> @@ -111,7 +111,7 @@ static void t4_smte_free(struct smt_entry *e)
> */
> void cxgb4_smt_release(struct smt_entry *e)
> {
> - if (atomic_dec_and_test(&e->refcnt))
> + if (refcount_dec_and_test(&e->refcnt))
> t4_smte_free(e);
This runs without any locking and therefore:
> if (e) {
> spin_lock(&e->lock);
> - if (!atomic_read(&e->refcnt)) {
> - atomic_set(&e->refcnt, 1);
> + if (refcount_read(&e->refcnt) == 1) {
> + refcount_set(&e->refcnt, 2);
This test is not safe, since the reference count can asynchronously decrement
to zero above outside of any locks.
Then you'll need to add locking, and as a result the need to an atomic
counter goes away and just a normal int can be used.
RE: [PATCH] x86/asm: Add support for MOVDIR64B instruction
+Dave, who is the DSA developer. Thanks, Jing -Original Message- From: Borislav Petkov Sent: Friday, August 2, 2019 7:41 AM To: Luck, Tony Cc: Kirill A. Shutemov ; Alexey Dobriyan ; kirill.shute...@linux.intel.com; linux-kernel@vger.kernel.org; Lin, Jing ; x...@kernel.org Subject: Re: [PATCH] x86/asm: Add support for MOVDIR64B instruction On Thu, Aug 01, 2019 at 10:06:27PM +, Luck, Tony wrote: > > I think Tony's in the right direction. We already do dst "sizing" > > like that for the compiler in clwb(). > > The clwb case does look like what we want for movdir64b(). > > But is it right for clwb() ... that doesn't modify anything, just > pushes things from cache to memory. So why is it using "+m"? Here some hints from to my notes, if you want to know more detail, I can ping my gcc guy. It needs to be an input and an output operand so that it prevents gcc from reordering accesses to it after the insn happens, i.e., you don't want to touch it after CLFLUSH has executed. And also, you want to make sure it works with all gcc versions and this is, I was told, the right way to do it. For example, some gcc versions consider it not limited to 64 bytes of memory being touched but a full memory clobber. HTH. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v9 04/11] x86/entry/64: Adapt assembly for PIE support
On Mon, Aug 5, 2019 at 10:28 AM Borislav Petkov wrote: > > On Tue, Jul 30, 2019 at 12:12:48PM -0700, Thomas Garnier wrote: > > Change the assembly code to use only relative references of symbols for the > > kernel to be PIE compatible. > > > > Position Independent Executable (PIE) support will allow to extend the > > KASLR randomization range below 0x8000. > > > > Signed-off-by: Thomas Garnier > > Reviewed-by: Kees Cook > > --- > > arch/x86/entry/entry_64.S | 16 +++- > > 1 file changed, 11 insertions(+), 5 deletions(-) > > > > diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S > > index 3f5a978a02a7..4b588a902009 100644 > > --- a/arch/x86/entry/entry_64.S > > +++ b/arch/x86/entry/entry_64.S > > @@ -1317,7 +1317,8 @@ ENTRY(error_entry) > > movl%ecx, %eax /* zero extend */ > > cmpq%rax, RIP+8(%rsp) > > je .Lbstep_iret > > - cmpq$.Lgs_change, RIP+8(%rsp) > > + leaq.Lgs_change(%rip), %rcx > > + cmpq%rcx, RIP+8(%rsp) > > jne .Lerror_entry_done > > > > /* > > @@ -1514,10 +1515,10 @@ ENTRY(nmi) > >* resume the outer NMI. > >*/ > > > > - movq$repeat_nmi, %rdx > > + leaqrepeat_nmi(%rip), %rdx > > cmpq8(%rsp), %rdx > > ja 1f > > - movq$end_repeat_nmi, %rdx > > + leaqend_repeat_nmi(%rip), %rdx > > cmpq8(%rsp), %rdx > > ja nested_nmi_out > > 1: > > @@ -1571,7 +1572,8 @@ nested_nmi: > > pushq %rdx > > pushfq > > pushq $__KERNEL_CS > > - pushq $repeat_nmi > > + leaqrepeat_nmi(%rip), %rdx > > + pushq %rdx > > > > /* Put stack back */ > > addq$(6*8), %rsp > > @@ -1610,7 +1612,11 @@ first_nmi: > > addq$8, (%rsp) /* Fix up RSP */ > > pushfq /* RFLAGS */ > > pushq $__KERNEL_CS/* CS */ > > - pushq $1f /* RIP */ > > + pushq $0 /* Future return address */ > > + pushq %rax/* Save RAX */ > > + leaq1f(%rip), %rax /* RIP */ > > + movq%rax, 8(%rsp) /* Put 1f on return address */ > > + popq%rax/* Restore RAX */ > > Can't you just use a callee-clobbered reg here instead of preserving > %rax? I saw that %rdx was used for temporary usage and restored before the end so I assumed that it was not an option. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH RFC tip/core/rcu 14/14] rcu/nohz: Make multi_cpu_stop() enable tick on all online CPUs
On Mon, Aug 05, 2019 at 05:50:24PM +0200, Peter Zijlstra wrote: > On Mon, Aug 05, 2019 at 07:54:48AM -0700, Paul E. McKenney wrote: > > > > Right; so clearly we're not understanding what's happening. That seems > > > like a requirement for actually doing a patch. > > > > Almost but not quite. It is a requirement for a patch *that* *is* > > *supposed* *to* *be* *a* *fix*. If you are trying to prohibit me from > > writing experimental patches, please feel free to take a long walk on > > a short pier. > > > > Understood??? > > Ah, my bad, I thought you were actually proposing this as an actual > patch. I now see that is my bad, I'd overlooked the RFC part. No problem! And of course adding tracing decreases the frequency and duration of the multi_cpu_stop(). Re-running with shorter-duration triggering. ;-) Thanx, Paul
Re: [PATCH net-next 00/26] net: stmmac: Misc improvements for XGMAC
This patch series is way too large. Break it down into smaller collections of changes, say a dozen at a time or so. Thank you.
Re: [PATCH v4 3/3] mtd: spi-nor: Rework hwcaps selection for the spi-mem case
On 08/01/2019 07:22 PM, Vignesh Raghavendra wrote:
> +static int spi_nor_spimem_check_op(struct spi_nor *nor,
> +struct spi_mem_op *op)
> +{
> + /*
> + * First test with 4 address bytes. The opcode itself might
> + * be a 3B addressing opcode but we don't care, because
> + * SPI controller implementation should not check the opcode,
> + * but just the sequence.
> + */
> + op->addr.nbytes = 4;
> + if (!spi_mem_supports_op(nor->spimem, op)) {
> + /* If flash size <16MB, 3 address bytes are sufficient */
> + if (nor->mtd.size <= SZ_16M) {
> + op->addr.nbytes = 3;
> + if (!spi_mem_supports_op(nor->spimem, op))
> + return -ENOTSUPP;
> + }
this returns success when:
op->addr.nbytes == 4 && !spi_mem_supports_op(nor->spimem, op) &&
!(nor->mtd.size <= SZ_16M))
which is wrong.
The patch looks good otherwise!
> + }
> +
> + return 0;
> +}
Re: [PATCH] MAINTAINERS: Update e-mail address for Andrea Parri
On Mon, Aug 05, 2019 at 08:23:38AM -0700, James Bottomley wrote:
> On Mon, 2019-08-05 at 17:15 +0200, Andrea Parri wrote:
> > > Why don't you also add an entry in .mailmap as Will did in commit
> > > c584b1202f2d ("MAINTAINERS: Update my email address to use
> > > @kernel.org")?
> >
> > I considered it but could not understand its purpose... Maybe you
> > can explain it to me? ;-) (can resend with this change if
> > needed/desired).
>
> man git-shortlog gives you the gory detail, but its use is to "coalesce
> together commits by the same person in the shortlog, where their name
> and/or email address was spelled differently." The usual way this
> happens is that people have the name that appears in the From field
> with and without initials.
New one on me, thank you! So I should have a line in .mailmap like this?
Paul E. McKenney
Thanx, Paul
Re: [PATCH net-next v2] net: dsa: mv88e6xxx: extend PTP gettime function to read system clock
> +static int mv88e6xxx_mdiobus_write_nested(struct mv88e6xxx_chip
> *chip, int addr, u32 regnum, u16 val)
> +{
> + int err;
> +
> + BUG_ON(in_interrupt());
> +
> + mutex_lock_nested(&chip->bus->mdio_lock, MDIO_MUTEX_NESTED);
> + ptp_read_system_prets(chip->ptp_sts);
> + err = __mdiobus_write(chip->bus, addr, regnum, val);
> + ptp_read_system_postts(chip->ptp_sts);
> + mutex_unlock(&chip->bus->mdio_lock);
> +
> + return err;
> +}
> +
> static int mv88e6xxx_smi_direct_write(struct mv88e6xxx_chip *chip,
> int dev, int reg, u16 data)
> {
>int ret;
>
> - ret = mdiobus_write_nested_ptp(chip->bus, dev, reg, data,
> chip->ptp_sts);
> + ret = mv88e6xxx_mdiobus_write_nested(chip, dev, reg, data);
>if (ret < 0)
>return ret;
>
> The result was:
> Min: -8052
> Max: 9988
> StdDev: 2490.17
> Count: 3592
>
> It got improved, but you still have the unpredictable latencies caused by the
> mdio_done-completion (=> wait_for_completion_timeout) in imx_fec.
O.K. So lets think about a more generic solution we can use inside the
mdio bus driver. I don't know if adding an sts pointer to struct
device will be accepted. But adding one to struct mii_bus should be
O.K. It can be assigned to once the mdio_lock is taken, to avoid race
conditions. Add mdio_ptp_read_system_prets(bus) and
mdio_ptp_read_system_postts(bus) which the bus driver can use.
We also need a fallback in case the bus driver does not use them, so
something like:
mdiobus_write_sts(...)
{
int retval;
BUG_ON(in_interrupt());
mutex_lock(&bus->mdio_lock);
bus->sts = sts;
sts->post_ts = 0;
ktime_get_real_ts64(&sts->pre_ts);
retval = __mdiobus_write(bus, addr, regnum, val);
if (!sts->post_ts)
ktime_get_real_ts64(sts->post_ts)
bus->sts = NULL;
mutex_unlock(&bus->mdio_lock);
return retval;
}
So at worse case, we get the time around the whole write operation,
but the MDIO bus driver can overwrite the pre_ts and set post_ts,
using mdio_ptp_read_system_prets(bus) and
mdio_ptp_read_system_postts(bus).
A similar scheme could be implemented to SPI devices, if the SPI
maintainer would accepted a sts pointer in the SPI bus driver
structure.
Andrew
Re: [PATCH 4.9 00/42] 4.9.188-stable review
stable-rc/linux-4.9.y boot: 101 boots: 0 failed, 60 passed with 41 offline (v4.9.187-43-g78dd396df223) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.187-43-g78dd396df223/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.187-43-g78dd396df223/ Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.187-43-g78dd396df223 Git Commit: 78dd396df223345521dd977f3974e6418c078296 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 49 unique boards, 22 SoC families, 15 builds out of 197 Boot Regressions Detected: arm: sunxi_defconfig: gcc-8: sun4i-a10-cubieboard: lab-baylibre-seattle: failing since 1 day (last pass: v4.9.186-224-g5380ded2525d - first fail: v4.9.187) sun5i-r8-chip: lab-baylibre-seattle: failing since 1 day (last pass: v4.9.186-224-g5380ded2525d - first fail: v4.9.187) sun7i-a20-bananapi: lab-baylibre-seattle: failing since 1 day (last pass: v4.9.186-224-g5380ded2525d - first fail: v4.9.187) Offline Platforms: arm64: defconfig: gcc-8 apq8016-sbc: 1 offline lab meson-gxbb-odroidc2: 1 offline lab arm: tegra_defconfig: gcc-8 tegra20-iris-512: 1 offline lab exynos_defconfig: gcc-8 exynos5250-arndale: 1 offline lab exynos5420-arndale-octa: 1 offline lab exynos5800-peach-pi: 1 offline lab multi_v7_defconfig: gcc-8 bcm4708-smartrg-sr400ac: 1 offline lab bcm72521-bcm97252sffe: 1 offline lab bcm7445-bcm97445c: 1 offline lab exynos5250-arndale: 1 offline lab exynos5420-arndale-octa: 1 offline lab exynos5800-peach-pi: 1 offline lab imx6dl-wandboard_dual: 1 offline lab imx6dl-wandboard_solo: 1 offline lab imx6q-wandboard: 1 offline lab imx7s-warp: 1 offline lab meson8b-odroidc1: 1 offline lab omap3-beagle: 1 offline lab omap4-panda: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab stih410-b2120: 1 offline lab sun4i-a10-cubieboard: 1 offline lab sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab tegra20-iris-512: 1 offline lab vf610-colibri-eval-v3: 1 offline lab omap2plus_defconfig: gcc-8 omap3-beagle: 1 offline lab omap4-panda: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab davinci_all_defconfig: gcc-8 da850-evm: 1 offline lab dm365evm,legacy: 1 offline lab imx_v6_v7_defconfig: gcc-8 imx6dl-wandboard_dual: 1 offline lab imx6dl-wandboard_solo: 1 offline lab imx6q-wandboard: 1 offline lab imx7s-warp: 1 offline lab vf610-colibri-eval-v3: 1 offline lab sunxi_defconfig: gcc-8 sun4i-a10-cubieboard: 1 offline lab sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab --- For more info write to
Re: [PATCH 4.4 00/22] 4.4.188-stable review
stable-rc/linux-4.4.y boot: 93 boots: 1 failed, 54 passed with 38 offline (v4.4.187-23-gb9a28e18ca89) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.187-23-gb9a28e18ca89/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.187-23-gb9a28e18ca89/ Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.187-23-gb9a28e18ca89 Git Commit: b9a28e18ca89602f69c795d8e0438f59d92cbf7b Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 44 unique boards, 20 SoC families, 14 builds out of 190 Boot Regressions Detected: arm: sunxi_defconfig: gcc-8: sun4i-a10-cubieboard: lab-baylibre-seattle: failing since 1 day (last pass: v4.4.186-157-gd9815060e3ec - first fail: v4.4.187) sun5i-r8-chip: lab-baylibre-seattle: failing since 1 day (last pass: v4.4.186-157-gd9815060e3ec - first fail: v4.4.187) sun7i-a20-bananapi: lab-baylibre-seattle: failing since 1 day (last pass: v4.4.186-157-gd9815060e3ec - first fail: v4.4.187) Boot Failure Detected: arm64: defconfig: gcc-8: qcom-qdf2400: 1 failed lab Offline Platforms: arm64: defconfig: gcc-8 apq8016-sbc: 1 offline lab arm: tegra_defconfig: gcc-8 tegra20-iris-512: 1 offline lab exynos_defconfig: gcc-8 exynos5250-arndale: 1 offline lab exynos5420-arndale-octa: 1 offline lab exynos5800-peach-pi: 1 offline lab multi_v7_defconfig: gcc-8 bcm4708-smartrg-sr400ac: 1 offline lab bcm72521-bcm97252sffe: 1 offline lab bcm7445-bcm97445c: 1 offline lab exynos5250-arndale: 1 offline lab exynos5420-arndale-octa: 1 offline lab exynos5800-peach-pi: 1 offline lab imx6dl-wandboard_dual: 1 offline lab imx6dl-wandboard_solo: 1 offline lab imx6q-wandboard: 1 offline lab meson8b-odroidc1: 1 offline lab omap3-beagle: 1 offline lab omap4-panda: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab stih410-b2120: 1 offline lab sun4i-a10-cubieboard: 1 offline lab sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab tegra20-iris-512: 1 offline lab vf610-colibri-eval-v3: 1 offline lab omap2plus_defconfig: gcc-8 omap3-beagle: 1 offline lab omap4-panda: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab davinci_all_defconfig: gcc-8 da850-evm: 1 offline lab dm365evm,legacy: 1 offline lab imx_v6_v7_defconfig: gcc-8 imx6dl-wandboard_dual: 1 offline lab imx6dl-wandboard_solo: 1 offline lab imx6q-wandboard: 1 offline lab vf610-colibri-eval-v3: 1 offline lab sunxi_defconfig: gcc-8 sun4i-a10-cubieboard: 1 offline lab sun5i-r8-chip: 1 offline lab sun7i-a20-bananapi: 1 offline lab --- For more info write to
Re: [PATCH 2/2] mm/zsmalloc.c: Fix race condition in zs_destroy_pool
On Sun, Aug 4, 2019 at 9:28 PM Minchan Kim wrote:
>
> Hi Henry,
>
> On Thu, Aug 01, 2019 at 06:53:32PM -0700, Henry Burns wrote:
> > In zs_destroy_pool() we call flush_work(&pool->free_work). However, we
> > have no guarantee that migration isn't happening in the background
> > at that time.
> >
> > Since migration can't directly free pages, it relies on free_work
> > being scheduled to free the pages. But there's nothing preventing an
> > in-progress migrate from queuing the work *after*
> > zs_unregister_migration() has called flush_work(). Which would mean
> > pages still pointing at the inode when we free it.
>
> We already unregister shrinker so there is no upcoming async free call
> via shrinker so the only concern is zs_compact API direct call from
> the user. Is that what what you desribe from the description?
What I am describing is a call to zsmalloc_aops->migratepage() by
kcompactd (which can call schedule work in either
zs_page_migrate() or zs_page_putback should the zspage become empty).
While we are migrating a page, we remove it from the class. Suppose
zs_free() loses a race with migration. We would schedule
async_free_zspage() to handle freeing that zspage, however we have no
guarantee that migration has finished
by the time we finish flush_work(&pool->work). In that case we then
call iput(inode), and now we have a page
pointing to a non-existent inode. (At which point something like
kcompactd would potentially BUG() if it tries to get a page
(from the inode) that doesn't exist anymore)
>
> If so, can't we add a flag to indicate destroy of the pool and
> global counter to indicate how many of zs_compact was nested?
>
> So, zs_unregister_migration in zs_destroy_pool can set the flag to
> prevent upcoming zs_compact call and wait until the global counter
> will be zero. Once it's done, finally flush the work.
>
> My point is it's not a per-class granuarity but global.
We could have a pool level counter of isolated pages, and wait for
that to finish before starting flush_work(&pool->work); However,
that would require an atomic_long in zs_pool, and we would have to eat
the cost of any contention over that lock. Still, it might be
preferable to a per-class granularity.
>
> Thanks.
>
> >
> > Since we know at destroy time all objects should be free, no new
> > migrations can come in (since zs_page_isolate() fails for fully-free
> > zspages). This means it is sufficient to track a "# isolated zspages"
> > count by class, and have the destroy logic ensure all such pages have
> > drained before proceeding. Keeping that state under the class
> > spinlock keeps the logic straightforward.
> >
> > Signed-off-by: Henry Burns
> > ---
> > mm/zsmalloc.c | 68 ---
> > 1 file changed, 65 insertions(+), 3 deletions(-)
> >
> > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > index efa660a87787..1f16ed4d6a13 100644
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -53,6 +53,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -206,6 +207,10 @@ struct size_class {
> > int objs_per_zspage;
> > /* Number of PAGE_SIZE sized pages to combine to form a 'zspage' */
> > int pages_per_zspage;
> > +#ifdef CONFIG_COMPACTION
> > + /* Number of zspages currently isolated by compaction */
> > + int isolated;
> > +#endif
> >
> > unsigned int index;
> > struct zs_size_stat stats;
> > @@ -267,6 +272,8 @@ struct zs_pool {
> > #ifdef CONFIG_COMPACTION
> > struct inode *inode;
> > struct work_struct free_work;
> > + /* A workqueue for when migration races with async_free_zspage() */
> > + struct wait_queue_head migration_wait;
> > #endif
> > };
> >
> > @@ -1917,6 +1924,21 @@ static void putback_zspage_deferred(struct zs_pool
> > *pool,
> >
> > }
> >
> > +static inline void zs_class_dec_isolated(struct zs_pool *pool,
> > + struct size_class *class)
> > +{
> > + assert_spin_locked(&class->lock);
> > + VM_BUG_ON(class->isolated <= 0);
> > + class->isolated--;
> > + /*
> > + * There's no possibility of racing, since wait_for_isolated_drain()
> > + * checks the isolated count under &class->lock after enqueuing
> > + * on migration_wait.
> > + */
> > + if (class->isolated == 0 && waitqueue_active(&pool->migration_wait))
> > + wake_up_all(&pool->migration_wait);
> > +}
> > +
> > static void replace_sub_page(struct size_class *class, struct zspage
> > *zspage,
> > struct page *newpage, struct page *oldpage)
> > {
> > @@ -1986,6 +2008,7 @@ static bool zs_page_isolate(struct page *page,
> > isolate_mode_t mode)
> >*/
> > if (!list_empty(&zspage->list) && !is_zspage_isolated(zspage)) {
> > get_zspage_mapping(zspage, &class_idx, &fullness);
> > + class->isolated++;
> > remove_zspage(class, zspa
[PATCH] kernfs: fix memleak in kernel_ops_readdir()
From: Andrea Arcangeli
If getdents64 is killed or hits on segfault, it'll leave cgroups
directories in sysfs pinned leaking memory because the kernfs node
won't be freed on rmdir and the parent neither.
Repro:
# for i in `seq 1000`; do mkdir $i; done
# rmdir *
# for i in `seq 1000`; do mkdir $i; done
# rmdir *
# for i in `seq 1000`; do while :; do ls $i/ >/dev/null; done & done
# while :; do killall ls; done
kernfs_node_cache in /proc/slabinfo keeps going up as expected.
Signed-off-by: Andrea Arcangeli
Signed-off-by: Tejun Heo
Cc: sta...@vger.kernel.org # goes way back to original sysfs days
---
fs/kernfs/dir.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/kernfs/dir.c b/fs/kernfs/dir.c
index 1e7a74b8e064..82b6c699fa34 100644
--- a/fs/kernfs/dir.c
+++ b/fs/kernfs/dir.c
@@ -1683,11 +1683,14 @@ static int kernfs_fop_readdir(struct file *file, struct
dir_context *ctx)
kernfs_get(pos);
mutex_unlock(&kernfs_mutex);
- if (!dir_emit(ctx, name, len, ino, type))
- return 0;
+ if (unlikely(!dir_emit(ctx, name, len, ino, type))) {
+ kernfs_put(pos);
+ goto out;
+ }
mutex_lock(&kernfs_mutex);
}
mutex_unlock(&kernfs_mutex);
+out:
file->private_data = NULL;
ctx->pos = INT_MAX;
return 0;
Re: [PATCH net-next v3] net: can: Fix compiling warnings for two functions
From: Mao Wenan Date: Mon, 5 Aug 2019 19:57:44 +0800 > @@ -1680,7 +1680,7 @@ static int bcm_recvmsg(struct socket *sock, struct > msghdr *msg, size_t size, > return size; > } > > -int bcm_sock_no_ioctlcmd(struct socket *sock, unsigned int cmd, > +static int bcm_sock_no_ioctlcmd(struct socket *sock, unsigned int cmd, >unsigned long arg) The alignment of the second line here needs to be adjusted, it must start precisely at the first column after the openning parenthesis of the first line. Same for the other change in this patch.
