Re: [PATCH v7 1/5] tpm: dynamically allocate the allocated_banks array
On 1/10/2019 6:38 PM, Jarkko Sakkinen wrote: On Mon, Jan 07, 2019 at 11:06:33AM +0100, Roberto Sassu wrote: On 12/22/2018 1:03 AM, Jarkko Sakkinen wrote: On Fri, Dec 21, 2018 at 10:40:09AM +0100, Roberto Sassu wrote: On 12/20/2018 3:55 PM, Jarkko Sakkinen wrote: On Thu, Dec 13, 2018 at 11:29:41AM +0100, Roberto Sassu wrote: This patch renames active_banks (member of tpm_chip) to allocated_banks, stores the number of allocated PCR banks in nr_allocated_banks (new member of tpm_chip), and replaces the static array with a pointer to a dynamically allocated array. tpm2_get_pcr_allocation() determines if a PCR bank is allocated by checking the mask in the TPML_PCR_SELECTION structure returned by the TPM for TPM2_Get_Capability(). If a bank is not allocated, the TPM returns that bank in TPML_PCR_SELECTION, with all bits in the mask set to zero. In this case, the bank is not included in chip->allocated_banks, to avoid that TPM driver users unnecessarily calculate a digest for that bank. One PCR bank with algorithm set to SHA1 is always allocated for TPM 1.x. As a consequence of the introduction of nr_allocated_banks, tpm_pcr_extend() does not check anymore if the algorithm stored in tpm_chip is equal to zero. Signed-off-by: Roberto Sassu Tested-by: Jarkko Sakkinen --- drivers/char/tpm/tpm-chip.c | 1 + drivers/char/tpm/tpm-interface.c | 18 + drivers/char/tpm/tpm.h | 3 ++- drivers/char/tpm/tpm1-cmd.c | 10 ++ drivers/char/tpm/tpm2-cmd.c | 34 ++-- 5 files changed, 47 insertions(+), 19 deletions(-) diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c index 32db84683c40..ce851c62bb68 100644 --- a/drivers/char/tpm/tpm-chip.c +++ b/drivers/char/tpm/tpm-chip.c @@ -160,6 +160,7 @@ static void tpm_dev_release(struct device *dev) kfree(chip->log.bios_event_log); kfree(chip->work_space.context_buf); kfree(chip->work_space.session_buf); + kfree(chip->allocated_banks); kfree(chip); } diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index d9439f9abe78..7b80919228be 100644 --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -488,8 +488,7 @@ EXPORT_SYMBOL_GPL(tpm_pcr_read); int tpm_pcr_extend(struct tpm_chip *chip, u32 pcr_idx, const u8 *hash) { int rc; - struct tpm2_digest digest_list[ARRAY_SIZE(chip->active_banks)]; - u32 count = 0; + struct tpm2_digest *digest_list; int i; chip = tpm_find_get_ops(chip); @@ -497,16 +496,19 @@ int tpm_pcr_extend(struct tpm_chip *chip, u32 pcr_idx, const u8 *hash) return -ENODEV; if (chip->flags & TPM_CHIP_FLAG_TPM2) { - memset(digest_list, 0, sizeof(digest_list)); + digest_list = kcalloc(chip->nr_allocated_banks, + sizeof(*digest_list), GFP_KERNEL); + if (!digest_list) + return -ENOMEM; You could preallocate digest list and place it to struct tpm_chip instead of doing it everytime tpm_pcr_extend() called. This part will be removed with patch 5/5. Even if it did, it does not make this patch unbroken. Can two calls to tpm_pcr_extend() be executed at the same time? If yes, the digest list should be protected by a mutex. Good question: the answer is no. Mutex locking is done inside the transmit flow ATM. But data are copied before the mutex is locked. Can't a second call overwrite chip->preallocated_digest_list while the first call is still writing it? Roberto /Jarkko -- HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Bo PENG, Jian LI, Yanli SHI
Re: ppc64le reliable stack unwinder and scheduled tasks
Joe Lawrence writes: > On Fri, Jan 11, 2019 at 01:00:38AM +0100, Nicolai Stange wrote: >> Hi Joe, >> >> Joe Lawrence writes: >> >> > tl;dr: On ppc64le, what is top-most stack frame for scheduled tasks >> >about? >> >> If I'm reading the code in _switch() correctly, the first frame is >> completely uninitialized except for the pointer back to the caller's >> stack frame. >> >> For completeness: _switch() saves the return address, i.e. the link >> register into its parent's stack frame, as is mandated by the ABI and >> consistent with your findings below: it's always the second stack frame >> where the return address into __switch_to() is kept. >> > > Hi Nicolai, > > Good, that makes a lot of sense. I couldn't find any reference > explaining the contents of frame 0, only unwinding code here and there > (as in crash-utility) that stepped over it. FWIW, I learned about general stack frame usage on ppc from part 4 of the introductionary series starting at [1]: it's a good reading and I can definitely recommend it. Summary: - Callers of other functions always allocate a stack frame and only set the pointer to the previous stack frame (that's the 'stdu r1, -STACK_FRAME_OVERHEAD(r1)' insn). - Callees save their stuff into the stack frame allocated by the caller if needed. Where "if needed" == callee in turn calls another function. The insignificance of frame 0's contents follows from this ABI: the caller might not have called any callee yet, the callee might be a leaf and so on. Finally, as I understand it, the only purpose of _switch() creating a standard stack frame at the bottom of scheduled out tasks is that the higher ones can be found (for e.g. the backtracing): otherwise there would be a pt_regs at the bottom of the stack. But I might be wrong here. >> >> >> > >> > >> > Example 1 (RHEL-7) >> > == >> > >> > crash> struct task_struct.thread c0022fd015c0 | grep ksp >> > ksp = 0xc000288af9c0 >> > >> > crash> rd 0xc000288af9c0 -e 0xc000288b >> > >> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> > >> > sp[0]: >> > >> > c000288af9c0: c000288afb90 00dd ...( >> > c000288af9d0: c0002a94 c1c60a00 .*.. >> > >> > crash> sym c0002a94 >> > c0002a94 (T) hardware_interrupt_common+0x114 >> >> So that c0002a94 certainly wasn't stored by _switch(). I think >> what might have happened is that the switching frame aliased with some >> prior interrupt frame as setup by hardware_interrupt_common(). >> >> The interrupt and switching frames seem to share a common layout as far >> as the lower STACK_FRAME_OVERHEAD + sizeof(struct pt_regs) bytes are >> concerned. >> >> That address into hardware_interrupt_common() could have been written by >> the do_IRQ() called from there. >> > > That was my initial theory, but then when I saw an ordinary scheduled > task with a similarly strange frame 0, I thought that _switch() might > have been doing something clever (or not). But according your earlier > explanation, it would line up that these values may be inherited from > do_IRQ() or the like. > >> >> > c000288af9e0: c1c60a80 >> > c000288af9f0: c000288afbc0 00dd ...( >> > c000288afa00: c14322e0 c1c60a00 ."C. >> > c000288afa10: c002303ae380 c002303ae380 ..:0..:0 >> > c000288afa20: 7265677368657265 2200 erehsger.".. >> > >> > Uh-oh... >> > >> > /* Mark stacktraces with exception frames as unreliable. */ >> > stack[STACK_FRAME_MARKER] == STACK_FRAME_REGS_MARKER >> >> >> Aliasing of the switching stack frame with some prior interrupt stack >> frame would explain why that STACK_FRAME_REGS_MARKER is still found on >> the stack, i.e. it's a leftover. >> >> For testing, could you try whether clearing the word at STACK_FRAME_MARKER >> from _switch() helps? >> >> I.e. something like (completely untested): > > I'll kick off some builds tonight and try to get tests lined up > tomorrow. Unfortunately these take a bit of time to run setup, schedule > and complete, so perhaps by next week. Ok, that's probably still a good test for confirmation, but the solution you proposed below is much better. >> >> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S >> index 435927f549c4..b747d0647ec4 100644 >> --- a/arch/powerpc/kernel/entry_64.S >> +++ b/arch/powerpc/kernel/entry_64.S >> @@ -596,6 +596,10 @@ _GLOBAL(_switch) >> SAVE_8GPRS(14, r1) >> SAVE_10GPRS(22, r1) >> std r0,_NIP(r1) /* Return to switch caller */ >> + >> +li r23,0 >> +std r23,96(r1) /* 96 == STACK_FRAME_MARKER * sizeof(long) */ >> + >> mfcrr23 >> std r23,_CCR(r1) >> std r1,KSP(r3) /* Set old s
[tip:perf/urgent] tools headers powerpc: Remove unistd.h
Commit-ID: 15c03092a9fbcdd041f58e5f832bf76c21c42e6a Gitweb: https://git.kernel.org/tip/15c03092a9fbcdd041f58e5f832bf76c21c42e6a Author: Ravi Bangoria AuthorDate: Thu, 10 Jan 2019 15:19:36 +0530 Committer: Arnaldo Carvalho de Melo CommitDate: Thu, 10 Jan 2019 10:42:08 -0300 tools headers powerpc: Remove unistd.h We use syscall.tbl to generate system call table on powerpc. The unistd.h copy is no longer required now. Remove it. Signed-off-by: Ravi Bangoria Cc: Jiri Olsa Cc: Michael Ellerman Cc: Namhyung Kim Cc: linuxppc-...@lists.ozlabs.org Link: http://lkml.kernel.org/r/20190110094936.3132-2-ravi.bango...@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/arch/powerpc/include/uapi/asm/unistd.h | 404 --- tools/perf/check-headers.sh | 1 - 2 files changed, 405 deletions(-) diff --git a/tools/arch/powerpc/include/uapi/asm/unistd.h b/tools/arch/powerpc/include/uapi/asm/unistd.h deleted file mode 100644 index 985534d0b448.. --- a/tools/arch/powerpc/include/uapi/asm/unistd.h +++ /dev/null @@ -1,404 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */ -/* - * This file contains the system call numbers. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License - * as published by the Free Software Foundation; either version - * 2 of the License, or (at your option) any later version. - */ -#ifndef _UAPI_ASM_POWERPC_UNISTD_H_ -#define _UAPI_ASM_POWERPC_UNISTD_H_ - - -#define __NR_restart_syscall 0 -#define __NR_exit1 -#define __NR_fork2 -#define __NR_read3 -#define __NR_write 4 -#define __NR_open5 -#define __NR_close 6 -#define __NR_waitpid 7 -#define __NR_creat 8 -#define __NR_link9 -#define __NR_unlink 10 -#define __NR_execve 11 -#define __NR_chdir 12 -#define __NR_time 13 -#define __NR_mknod 14 -#define __NR_chmod 15 -#define __NR_lchown 16 -#define __NR_break 17 -#define __NR_oldstat18 -#define __NR_lseek 19 -#define __NR_getpid 20 -#define __NR_mount 21 -#define __NR_umount 22 -#define __NR_setuid 23 -#define __NR_getuid 24 -#define __NR_stime 25 -#define __NR_ptrace 26 -#define __NR_alarm 27 -#define __NR_oldfstat 28 -#define __NR_pause 29 -#define __NR_utime 30 -#define __NR_stty 31 -#define __NR_gtty 32 -#define __NR_access 33 -#define __NR_nice 34 -#define __NR_ftime 35 -#define __NR_sync 36 -#define __NR_kill 37 -#define __NR_rename 38 -#define __NR_mkdir 39 -#define __NR_rmdir 40 -#define __NR_dup41 -#define __NR_pipe 42 -#define __NR_times 43 -#define __NR_prof 44 -#define __NR_brk45 -#define __NR_setgid 46 -#define __NR_getgid 47 -#define __NR_signal 48 -#define __NR_geteuid49 -#define __NR_getegid50 -#define __NR_acct 51 -#define __NR_umount252 -#define __NR_lock 53 -#define __NR_ioctl 54 -#define __NR_fcntl 55 -#define __NR_mpx56 -#define __NR_setpgid57 -#define __NR_ulimit 58 -#define __NR_oldolduname59 -#define __NR_umask 60 -#define __NR_chroot 61 -#define __NR_ustat 62 -#define __NR_dup2 63 -#define __NR_getppid64 -#define __NR_getpgrp65 -#define __NR_setsid 66 -#define __NR_sigaction 67 -#define __NR_sgetmask 68 -#define __NR_ssetmask 69 -#define __NR_setreuid 70 -#define __NR_setregid 71 -#define __NR_sigsuspend 72 -#define __NR_sigpending 73 -#define __NR_sethostname74 -#define __NR_setrlimit 75 -#define __NR_getrlimit 76 -#define __NR_getrusage 77 -#define __NR_gettimeofday 78 -#define __NR_settimeofday 79 -#define __NR_getgroups 80 -#define __NR_setgroups 81 -#define __NR_select 82 -#define __NR_symlink83 -#define __NR_oldlstat 84 -#define __NR_readlink 85 -#define __NR_uselib 86 -#define __NR_swapon 87 -#define __NR_reboot 88 -#define __NR_readdir89 -#define __NR_mmap 90 -#define __NR_munmap 91 -#define __NR_truncate 92 -#define __NR_ftruncate 93 -#define __NR_fchmod
[tip:perf/urgent] perf powerpc: Rework syscall table generation
Commit-ID: 0206131811fa6e4b3ed64b5f1c107e2815dcab42 Gitweb: https://git.kernel.org/tip/0206131811fa6e4b3ed64b5f1c107e2815dcab42 Author: Ravi Bangoria AuthorDate: Thu, 10 Jan 2019 15:19:35 +0530 Committer: Arnaldo Carvalho de Melo CommitDate: Thu, 10 Jan 2019 10:34:52 -0300 perf powerpc: Rework syscall table generation Commit aff850393200 ("powerpc: add system call table generation support") changed how systemcall table is generated for powerpc. Incorporate these changes into perf as well. Committer testing: $ podman run --entrypoint=/bin/sh --privileged -v /home/acme/git:/git --rm -ti docker.io/acmel/linux-perf-tools-build-ubuntu:18.04-x-powerpc64 perfbuilder@d7a7af166a80:/git/perf$ head -2 /etc/os-release NAME="Ubuntu" VERSION="18.04.1 LTS (Bionic Beaver)" perfbuilder@d7a7af166a80:/git/perf$ perfbuilder@d7a7af166a80:/git/perf$ make ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- EXTRA_CFLAGS= -C /git/linux/tools/perf O=/tmp/build/perf make: Entering directory '/git/linux/tools/perf' BUILD: Doing 'make -j8' parallel build HOSTCC /tmp/build/perf/fixdep.o HOSTLD /tmp/build/perf/fixdep-in.o LINK /tmp/build/perf/fixdep Warning: Kernel ABI header at 'tools/include/uapi/linux/mman.h' differs from latest version at 'include/uapi/linux/mman.h' diff -u tools/include/uapi/linux/mman.h include/uapi/linux/mman.h sh: 1: command: Illegal option -c Auto-detecting system features: ... dwarf: [ on ] ...dwarf_getlocations: [ on ] ... glibc: [ on ] ... gtk2: [ OFF ] ... libaudit: [ OFF ] ...libbfd: [ OFF ] ...libelf: [ on ] ... libnuma: [ OFF ] ...numa_num_possible_cpus: [ OFF ] ... libperl: [ OFF ] ... libpython: [ OFF ] ... libslang: [ OFF ] ... libcrypto: [ OFF ] ... libunwind: [ OFF ] ...libdw-dwarf-unwind: [ on ] ... zlib: [ on ] ... lzma: [ OFF ] ... get_cpuid: [ OFF ] ... bpf: [ on ] Makefile.config:445: No sys/sdt.h found, no SDT events are defined, please install systemtap-sdt-devel or systemtap-sdt-dev Makefile.config:491: No libunwind found. Please install libunwind-dev[el] >= 1.1 and/or set LIBUNWIND_DIR Makefile.config:583: No libcrypto.h found, disables jitted code injection, please install libssl-devel or libssl-dev Makefile.config:598: slang not found, disables TUI support. Please install slang-devel, libslang-dev or libslang2-dev Makefile.config:612: GTK2 not found, disables GTK2 support. Please install gtk2-devel or libgtk2.0-dev Makefile.config:639: Missing perl devel files. Disabling perl scripting support, please install perl-ExtUtils-Embed/libperl-dev Makefile.config:666: No python interpreter was found: disables Python support - please install python-devel/python-dev Makefile.config:721: No bfd.h/libbfd found, please install binutils-dev[el]/zlib-static/libiberty-dev to gain symbol demangling Makefile.config:750: No liblzma found, disables xz kernel module decompression, please install xz-devel/liblzma-dev Makefile.config:763: No numa.h found, disables 'perf bench numa mem' benchmark, please install numactl-devel/libnuma-devel/libnuma-dev Makefile.config:814: No libbabeltrace found, disables 'perf data' CTF format support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev Makefile.config:840: No alternatives command found, you need to set JDIR= to point to the root of your Java directory GEN /tmp/build/perf/common-cmds.h CC /tmp/build/perf/util/syscalltbl.o LD /tmp/build/perf/libperf-in.o AR /tmp/build/perf/libperf.a LINK /tmp/build/perf/perf make: Leaving directory '/git/linux/tools/perf' perfbuilder@d7a7af166a80:/git/perf$ head /tmp/build/perf/arch/powerpc/include/generated/asm/syscalls_64.c static const char *syscalltbl_powerpc_64[] = { [0] = "restart_syscall", [1] = "exit", [2] = "fork", [3] = "read", [4] = "write", [5] = "open", [6] = "close", [7] = "waitpid", [8] = "creat", perfbuilder@d7a7af166a80:/git/perf$ tail /tmp/build/perf/arch/powerpc/include/generated/asm/syscalls_64.c [381] = "pwritev2", [382] = "kexec_file_load", [383] = "statx", [384] = "pkey_alloc", [385] = "pkey_free", [386] = "pkey_mprotect", [387] = "rseq", [388] = "io_pgetevents", }; #define SYSCALLTBL_POWERPC_64_MAX_ID 388 perfbuilder@d7a7af166a80:/git/perf$ head /tmp/build/perf/arch/powerpc/include/generated/asm/syscalls_32.c static const char *syscalltbl_powerpc_32[] = {
[tip:perf/urgent] perf symbols: Add 'arch_cpu_idle' to the list of kernel idle symbols
Commit-ID: 549aff770ccfec368aa8f0652dbce8b1e8e6715a Gitweb: https://git.kernel.org/tip/549aff770ccfec368aa8f0652dbce8b1e8e6715a Author: Arnaldo Carvalho de Melo AuthorDate: Wed, 9 Jan 2019 16:19:24 -0300 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 9 Jan 2019 16:21:15 -0300 perf symbols: Add 'arch_cpu_idle' to the list of kernel idle symbols When testing 'perf top' on a armhf system (32-bit, Orange Pi Zero), I noticed that 'arch_cpu_idle' dominated, add it to the list of idle symbols, so that we can see what is that being done when not idle. Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Link: https://lkml.kernel.org/n/tip-4q2b5g4p2hrstrhp9t2mr...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/symbol.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c index 01f2c7385e38..48efad6d0f90 100644 --- a/tools/perf/util/symbol.c +++ b/tools/perf/util/symbol.c @@ -614,6 +614,7 @@ out: static bool symbol__is_idle(const char *name) { const char * const idle_symbols[] = { + "arch_cpu_idle", "cpu_idle", "cpu_startup_entry", "intel_idle",
[tip:perf/urgent] tools include uapi: Sync linux/if_link.h copy with the kernel sources
Commit-ID: 498c203d855eaf6571b63ea860a53862c4fe91b7 Gitweb: https://git.kernel.org/tip/498c203d855eaf6571b63ea860a53862c4fe91b7 Author: Arnaldo Carvalho de Melo AuthorDate: Wed, 9 Jan 2019 10:02:12 -0300 Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 9 Jan 2019 10:02:12 -0300 tools include uapi: Sync linux/if_link.h copy with the kernel sources To pick the changes from: a428afe82f98 ("net: bridge: add support for user-controlled bool options") a025fb5f49ad ("geneve: Allow configuration of DF behaviour") b4d3069783bc ("vxlan: Allow configuration of DF behaviour") Silencing this tools/ build warning: Warning: Kernel ABI header at 'tools/include/uapi/linux/if_link.h' differs from latest version at 'include/uapi/linux/if_link.h' Cc: Adrian Hunter Cc: David S. Miller Cc: Jiri Olsa Cc: Namhyung Kim Cc: Nikolay Aleksandrov Cc: Stefano Brivio Link: https://lkml.kernel.org/n/tip-wq410s2wuqv5k980bidw0...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/include/uapi/linux/if_link.h | 19 +++ 1 file changed, 19 insertions(+) diff --git a/tools/include/uapi/linux/if_link.h b/tools/include/uapi/linux/if_link.h index 1debfa42cba1..d6533828123a 100644 --- a/tools/include/uapi/linux/if_link.h +++ b/tools/include/uapi/linux/if_link.h @@ -288,6 +288,7 @@ enum { IFLA_BR_MCAST_IGMP_VERSION, IFLA_BR_MCAST_MLD_VERSION, IFLA_BR_VLAN_STATS_PER_PORT, + IFLA_BR_MULTI_BOOLOPT, __IFLA_BR_MAX, }; @@ -533,6 +534,7 @@ enum { IFLA_VXLAN_LABEL, IFLA_VXLAN_GPE, IFLA_VXLAN_TTL_INHERIT, + IFLA_VXLAN_DF, __IFLA_VXLAN_MAX }; #define IFLA_VXLAN_MAX (__IFLA_VXLAN_MAX - 1) @@ -542,6 +544,14 @@ struct ifla_vxlan_port_range { __be16 high; }; +enum ifla_vxlan_df { + VXLAN_DF_UNSET = 0, + VXLAN_DF_SET, + VXLAN_DF_INHERIT, + __VXLAN_DF_END, + VXLAN_DF_MAX = __VXLAN_DF_END - 1, +}; + /* GENEVE section */ enum { IFLA_GENEVE_UNSPEC, @@ -557,10 +567,19 @@ enum { IFLA_GENEVE_UDP_ZERO_CSUM6_RX, IFLA_GENEVE_LABEL, IFLA_GENEVE_TTL_INHERIT, + IFLA_GENEVE_DF, __IFLA_GENEVE_MAX }; #define IFLA_GENEVE_MAX(__IFLA_GENEVE_MAX - 1) +enum ifla_geneve_df { + GENEVE_DF_UNSET = 0, + GENEVE_DF_SET, + GENEVE_DF_INHERIT, + __GENEVE_DF_END, + GENEVE_DF_MAX = __GENEVE_DF_END - 1, +}; + /* PPP section */ enum { IFLA_PPP_UNSPEC,
[GIT PULL] EFI fix
Linus, Please pull the latest efi-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-urgent-for-linus # HEAD: b12f5440d8ca02e8f9ab4f1461f9214295cc4f66 Merge branch 'linus' into efi/urgent, to resolve conflict A single fix that adds an annotation to resolve a kmemleak false positive. Thanks, Ingo --> Qian Cai (1): efi: Let kmemleak ignore false positives drivers/firmware/efi/efi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index 4c46ff6f2242..7ac09dd8f268 100644 --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -31,6 +31,7 @@ #include #include #include +#include #include @@ -1026,6 +1027,8 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size) if (!rsv) return -ENOMEM; + kmemleak_ignore(rsv); + rsv->size = EFI_MEMRESERVE_COUNT(PAGE_SIZE); atomic_set(&rsv->count, 1); rsv->entry[0].base = addr;
Re: [PATCH v3 0/5] kvm "virtio pmem" device
> > On Wed, Jan 09, 2019 at 08:17:31PM +0530, Pankaj Gupta wrote: > > This patch series has implementation for "virtio pmem". > > "virtio pmem" is fake persistent memory(nvdimm) in guest > > which allows to bypass the guest page cache. This also > > implements a VIRTIO based asynchronous flush mechanism. > > H. Sharing the host page cache direct into the guest VM. Sounds > like a good idea, but. > > This means the guest VM can now run timing attacks to observe host > side page cache residency, and depending on the implementation I'm > guessing that the guest will be able to control host side page > cache eviction, too (e.g. via discard or hole punch operations). Not sure how? this is similar to mmapping virtual memory by any userspace process. Any host userspace process can do such attack on host page cache using mincore & mmap shared file. But i don't think guest can do this alone. For virtio-pmem usecase guest won't be using page cache so timing attack from only guest side is not possible unless host userspace can run checks on page cache eviction state using mincore etc. As rightly described by Rik, guest will only access its own page cache pages and if guest page cache is managed directly by host, this saves alot of effort for guest in transferring guest state of page cache. > > Which means this functionality looks to me like a new vector for > information leakage into and out of the guest VM via guest > controlled host page cache manipulation. > > https://arxiv.org/pdf/1901.01161 > > I might be wrong, but if I'm not we're going to have to be very > careful about how guest VMs can access and manipulate host side > resources like the page cache. If I am following correctly the discussions in MM thread. Important steps to mitigate this: * Avoid running mincore in privilege mode: to safeguard page evict state of any page cache page. * tweaking RWF_NOWAIT I think if we secure ways to find current state(cached/evicted) of a page in host, we should be able to mitigate the impact for any page cache page access attack including virtio-pmem. Thanks, Pankaj
[GIT PULL] perf fixes
Linus, Please pull the latest perf-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-urgent-for-linus # HEAD: 4e72ee8872279a70ebe973172133b98e8acbf54e Merge tag 'perf-core-for-mingo-5.0-20190110' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Tooling changes only: fixes and a few stray improvements. Most of the diffstat is dominated by a PowerPC related fix of system call trace output beautification that allows us to (again) use the UAPI header version and sync up with the kernel's version of PowerPC system call names in the arch/powerpc/kernel/syscalls/syscall.tbl header. Thanks, Ingo --> Arnaldo Carvalho de Melo (19): tools headers x86: Sync disabled-features.h tools headers uapi: Sync prctl.h with the kernel sources tools beauty: Make the prctl option table generator catch all PR_ options tools headers uapi: Update i915_drm.h tools headers uapi: Sync linux/in.h copy from the kernel sources tools headers uapi: Sync linux/kvm.h with the kernel sources tools headers uapi: Sync copy of asm-generic/unistd.h with the kernel sources tools headers x86: Sync asm/cpufeatures.h copy with the kernel sources perf python: Make sure the python binding output directory is in place perf test shell: Use a fallback to get the pathname in vfs_getname perf trace: Fix ')' placement in "interrupted" syscall lines perf trace: Fix alignment for [continued] lines perf top: Lift restriction on using callchains without "sym" in --sort tools include uapi: Grab a copy of linux/mount.h perf beauty: Switch from using uapi/linux/fs.h to uapi/linux/mount.h tools include uapi: Sync linux/fs.h copy with the kernel sources tools include uapi: Sync linux/vhost.h with the kernel sources tools include uapi: Sync linux/if_link.h copy with the kernel sources perf symbols: Add 'arch_cpu_idle' to the list of kernel idle symbols Florian Fainelli (2): perf tools: Make find_vdso_map() more modular perf tests: Add a test for the ARM 32-bit [vectors] page Ivan Krylov (1): perf annotate: Pass filename to objdump via execl Jin Yao (2): perf stat: Fix endless wait for child process perf report: Fix wrong iteration count in --branch-history Jiri Olsa (2): tools thermal tmon: Use -O3 instead of -O1 if available tools iio: Override CFLAGS assignments Mattias Jacobsson (1): perf strbuf: Remove redundant va_end() in strbuf_addv() Ravi Bangoria (2): perf powerpc: Rework syscall table generation tools headers powerpc: Remove unistd.h Tzvetomir Stoyanov (7): tools lib traceevent: Introduce new libtracevent API: tep_override_comm() tools lib traceevent: Initialize host_bigendian at tep_handle allocation tools lib traceevent: Rename struct cmdline to struct tep_cmdline tools lib traceevent: Changed return logic of trace_seq_printf() and trace_seq_vprintf() APIs tools lib traceevent: Changed return logic of tep_register_event_handler() API tools lib traceevent: Rename tep_is_file_bigendian() to tep_file_bigendian() tools lib traceevent: Remove tep_data_event_from_type() API tools/arch/powerpc/include/uapi/asm/unistd.h | 404 --- tools/arch/x86/include/asm/cpufeatures.h | 2 + tools/arch/x86/include/asm/disabled-features.h | 8 +- tools/include/uapi/asm-generic/unistd.h| 4 +- tools/include/uapi/drm/i915_drm.h | 8 + tools/include/uapi/linux/fs.h | 60 +-- tools/include/uapi/linux/if_link.h | 19 + tools/include/uapi/linux/in.h | 10 +- tools/include/uapi/linux/kvm.h | 19 + tools/include/uapi/linux/mount.h | 58 +++ tools/include/uapi/linux/prctl.h | 8 + tools/include/uapi/linux/vhost.h | 113 +- tools/lib/traceevent/event-parse-api.c | 4 +- tools/lib/traceevent/event-parse-local.h | 4 +- tools/lib/traceevent/event-parse.c | 129 --- tools/lib/traceevent/event-parse.h | 17 +- tools/lib/traceevent/plugin_kvm.c | 2 +- tools/lib/traceevent/trace-seq.c | 17 +- tools/perf/Makefile.perf | 8 +- tools/perf/arch/arm/tests/Build| 1 + tools/perf/arch/arm/tests/arch-tests.c | 4 + tools/perf/arch/arm/tests/vectors-page.c | 24 ++ tools/perf/arch/powerpc/Makefile | 15 +- .../perf/arch/powerpc/entry/syscalls/mksyscalltbl | 22 +- tools/perf/arch/powerpc/entry/syscalls/syscall.tbl | 427 + tools/perf/builtin-stat.c
Re: [PATCH] usb: dwc3: gadget: Fail request submission if it was already queued
Hi, Manu Gautam writes: > If a function driver tries to re-submit an already queued request, > it can results in corruption of pending/started request lists. > Catch such conditions and fail the request submission to DCD. > > Signed-off-by: Manu Gautam > --- > drivers/usb/dwc3/gadget.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c > index 679c12e14522..51716c6b286a 100644 > --- a/drivers/usb/dwc3/gadget.c > +++ b/drivers/usb/dwc3/gadget.c > @@ -1290,6 +1290,12 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, > struct dwc3_request *req) > &req->request, req->dep->name)) > return -EINVAL; > > + if (req->request.status == -EINPROGRESS) { this test is really not enough. What if gadget driver set status to EINPROGRESS before submission? A better check would involve making sure req isn't part of dep->pending_list or dep->started_list or dep->cancelled_list. It's clear that this won't work very well as the amount of requests grow. Anyway, which gadget driver did this? Why is it only affecting dwc3? -- balbi signature.asc Description: PGP signature
Re: [PATCH 05/41] scsi: aic7xxx: aic79xx: mark expected switch fall-through
On 1/10/19 9:15 PM, Gustavo A. R. Silva wrote: Hi, Friendly ping (second one): Who can ack/review/take this patch, please? Thanks -- Gustavo On 12/19/18 9:36 AM, Gustavo A. R. Silva wrote: Hi, Friendly ping: Who can ack or review this patch, please? Thanks -- Gustavo On 11/27/18 10:26 PM, Gustavo A. R. Silva wrote: In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that, in some cases, I replaced "FALLTHROUGH" with a "fall through" annotation and then placed it at the bottom of the corresponding switch case, which is what GCC is expecting to find. Addresses-Coverity-ID: 114961 ("Missing break in switch") Addresses-Coverity-ID: 114962 ("Missing break in switch") Addresses-Coverity-ID: 114963 ("Missing break in switch") Addresses-Coverity-ID: 114964 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva --- drivers/scsi/aic7xxx/aic79xx_core.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) Sorry, I thought I'd done so already. Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.com +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Thu, 10 Jan 2019, Dave Chinner wrote: > Sounds nice from a theoretical POV, but reality has taught us very > different lessons. > > FWIW, a quick check of XFS's history so you understand how long this > behaviour has been around. It was introduced in the linux port in 2001 > as direct IO support was being added: > > commit e837eac23662afae603aaaef7c94bc839c1b8f67 > Author: Steve Lord > Date: Mon Mar 5 16:47:52 2001 + > > Add bounds checking for direct I/O, do the cache invalidation for > data coherency on direct I/O. Out of curiosity, which repository is this from please? Even google doesn't seem to know about this SHA. Thanks, -- Jiri Kosina SUSE Labs
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Thu, Jan 10, 2019 at 11:08:07PM -0800, Linus Torvalds wrote: > On Thu, Jan 10, 2019 at 8:04 PM Dave Chinner wrote: > > > > So it will only read the single page we tried to access and won't > > perturb the rest of the message encoded into subsequent pages in > > file. > > Dave, you're being intentionally obtuse, aren't you? > > It's only that single page that *matters*. That's the page that the > probe reveals the status of - but it's also the page that the probe > then *changes* the status of. It changes the state of it /after/ we've already got the information we need from it. It's not up to date, it has to come from disk, we return EAGAIN, which means it was not in the cache. i.e. if we return EAGAIN, we've leaked the inforation the attacker wants regardless of how the act of initiating readahead on the page change the state of the page. Yes, it raises the complexity bar a bit, and lowers the monitoring frequency somewhat, but that's about it. Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
Linus Torvalds wrote on Thu, Jan 10, 2019: > But those numbers aren't about the mincore() change. That's just from > dropping caches. > > Now, what's the difference with the mincore change, and without? Is it > actually measurable? > > Because that's all that matters: is the mincore change something you > can even notice? Is it a big regression? > > The fact that things are slower when they are cold in the cache isn't > the issue. The issue is whether the change to mincore semantics makes > any difference to real loads. mincore itself isn't used to reload the data, but is necessary to know *what* you need to reload. If you don't know what pages are hot, how can you preload them? For small enough a database and with enough memory you can act stupid and load the whole tables in cache, that's what I did because I was lazy and only had a big mysql data set around. But the container warming up automaton Dave mentioned and postgresql db preloading with pgfincore explicitely depend on being able to tell what they need to preload. pgfincore documentation states: set of PostgreSQL functions to manage blocks in memory Those functions let you know which and how many disk block from a relation are in the page cache of the operating system, and eventually write the result to a file. Then using this file, it is possible to restore the page cache state for each block of the relation. If you cannot dump an arbitrary "hot state" x, you cannot restore it. This is all basically a repeat of the other subthread; sure precaching itself doesn't need mincore and if you're all-knowing the syscall isn't needed, but mere mortals need it. If it's about the commit itself, vmtouch tells me 0 page in these database files are in cache when I reboot to a 5.0-rc1 kernel and run some queries, so the difference after a fresh boot is exactly what I stated. I'm probably missing something but I'm not quite sure in what situation the "new mincore" has any use right now. -- Dominique Martinet | Asmadeus
Re: [PATCH] xen: Fix x86 sched_clock() interface for xen
On 11/01/2019 08:15, Juergen Gross wrote: > On 11/01/2019 00:10, Boris Ostrovsky wrote: >> On 1/10/19 12:17 PM, Boris Ostrovsky wrote: >>> On 1/10/19 11:14 AM, Juergen Gross wrote: On 10/01/2019 16:34, Boris Ostrovsky wrote: > On 1/10/19 5:07 AM, Juergen Gross wrote: >> >> +void xen_clocksource_suspend(void) >> +{ >> +xen_clock_value_saved = xen_clocksource_read() - >> xen_sched_clock_offset; > xen_clock_value_saved = xen_sched_clock() maybe? I wanted xen_clocksource_suspend() and xen_clocksource_resume() to be symmetrical to each other. >>> OK. >>> >>> Reviewed-by: Boris Ostrovsky >>> In case you are feeling strong about that, I'm not. :-) So in case you insist on it I can change it. Or you can do so while committing. >> >> >> I did some basic testing and noticed this (at loglevel=8): >> >> [ 64.336488] Freezing user space processes ... (elapsed 0.001 seconds) >> done. >> [ 64.337805] OOM killer disabled. >> [ 64.337814] Freezing remaining freezable tasks ... (elapsed 0.000 >> seconds) done. >> [ 64.339066] suspending xenstore... >> [ 85.888340] xen:grant_table: Grant tables using version 1 layout >> [ 64.359729] OOM killer enabled. >> [ 64.359736] Restarting tasks ... done. >> >> >> Which made me think that perhaps we should do suspend/restore of the >> clocksource as close as possible to HYPERVISOR_suspend() call, e.g. in >> xen_arch_pre_suspend()/xen_arch_post_suspend(): >> >> diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c >> index 45fc9caf3880..80ecba3fcc8c 100644 >> --- a/arch/x86/xen/suspend.c >> +++ b/arch/x86/xen/suspend.c >> @@ -22,6 +22,7 @@ static DEFINE_PER_CPU(u64, spec_ctrl); >> >> void xen_arch_pre_suspend(void) >> { >> + xen_clocksource_suspend(); >> xen_save_time_memory_area(); >> >> if (xen_pv_domain()) >> @@ -36,6 +37,7 @@ void xen_arch_post_suspend(int cancelled) >> xen_hvm_post_suspend(cancelled); >> >> xen_restore_time_memory_area(); >> + xen_clocksource_resume(); >> } >> >> static void xen_vcpu_notify_restore(void *data) >> >> >> This still has a window of incorrect clock value (you can see it, for >> example, when xen_hvm_post_suspend() does pr_info("Xen HVM callback >> vector for event delivery is enabled\n")), but it's smaller than before. >> In particular, we will make time right before dpm_resume_start() call. > > You are right, this is better. In fact, I can just handle this entirely inside arch/x86/xen/time.c by moving the required statements into xen_save_time_memory_area() and xen_restore_time_memory_area(). Juergen
Re: [PATCH v2 3/4] tee: add supp_nowait flag in tee_context struct
On Thu, 10 Jan 2019 at 19:53, Daniel Thompson wrote: > > On Thu, Jan 10, 2019 at 05:54:56PM +0530, Sumit Garg wrote: > > This flag indicates that requests in this context should not wait for > > tee-supplicant daemon to be started if not present and just return > > with an error code. It is needed for requests which should be > > non-blocking in nature like ones arising from TEE based kernel drivers > > or any in kernel api that uses TEE internal client interface. > > This patch seems out of order in the patch set: Doesn't > optee_enumarate_devices() require this feature if it is to > work correctly with a TEE that does not implement the enumeate pTA. > > If so better to implement the feature first so that > optee_emumerate_devices() works correctly when it first appears. > Agree, will make this patch as #2 in next version. > > > > Signed-off-by: Sumit Garg > > --- > > drivers/tee/optee/supp.c | 10 +- > > drivers/tee/tee_core.c | 2 ++ > > include/linux/tee_drv.h | 6 ++ > > 3 files changed, 17 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/tee/optee/supp.c b/drivers/tee/optee/supp.c > > index 43626e1..92f56b8 100644 > > --- a/drivers/tee/optee/supp.c > > +++ b/drivers/tee/optee/supp.c > > @@ -88,10 +88,18 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 > > func, size_t num_params, > > { > > struct optee *optee = tee_get_drvdata(ctx->teedev); > > struct optee_supp *supp = &optee->supp; > > - struct optee_supp_req *req = kzalloc(sizeof(*req), GFP_KERNEL); > > + struct optee_supp_req *req; > > bool interruptable; > > u32 ret; > > > > + /* > > + * Return in case there is no supplicant available and > > + * non-blocking request. > > + */ > > + if (!supp->ctx && ctx->supp_nowait) > > + return TEEC_ERROR_COMMUNICATION; > > + > > + req = kzalloc(sizeof(*req), GFP_KERNEL); > > if (!req) > > return TEEC_ERROR_OUT_OF_MEMORY; > > > > diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c > > index 9ddb89e..5d6c317 100644 > > --- a/drivers/tee/tee_core.c > > +++ b/drivers/tee/tee_core.c > > @@ -105,6 +105,7 @@ static int tee_open(struct inode *inode, struct file > > *filp) > > if (IS_ERR(ctx)) > > return PTR_ERR(ctx); > > > > + ctx->supp_nowait = false; > > filp->private_data = ctx; > > return 0; > > } > > @@ -981,6 +982,7 @@ tee_client_open_context(struct tee_context *start, > > } while (IS_ERR(ctx) && PTR_ERR(ctx) != -ENOMEM); > > > > put_device(put_dev); > > + ctx->supp_nowait = true; > > Why automatically set supp_nowait inside open_context() ? > I think this is the default behaviour (non-blocking request) that any in kernel client would expect. Also this flag could be configured again before call to open_session() if any in kernel client requires different behaviour. -Sumit > > > return ctx; > > } > > EXPORT_SYMBOL_GPL(tee_client_open_context); > > diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h > > index ed16bf1..fe1a920 100644 > > --- a/include/linux/tee_drv.h > > +++ b/include/linux/tee_drv.h > > @@ -49,6 +49,11 @@ struct tee_shm_pool; > > * @releasing: flag that indicates if context is being released right now. > > * It is needed to break circular dependency on context during > > * shared memory release. > > + * @supp_nowait: flag that indicates that requests in this context should > > not > > + * wait for tee-supplicant daemon to be started if not present > > + * and just return with an error code. It is needed for > > requests > > + * that arises from TEE based kernel drivers that should be > > + * non-blocking in nature. > > */ > > struct tee_context { > > struct tee_device *teedev; > > @@ -56,6 +61,7 @@ struct tee_context { > > void *data; > > struct kref refcount; > > bool releasing; > > + bool supp_nowait; > > }; > > > > struct tee_param_memref { > > -- > > 2.7.4 > >
Re: [PATCHv3 1/5] ARM: dts: ls1021a: add num-viewport property for PCIe DT nodes
On Tue, Dec 18, 2018 at 04:19:26AM +, Z.q. Hou wrote: > From: Hou Zhiqiang > > Add num-viewport property for PCIe DT nodes to specify how many > viewports are implemented. > > Signed-off-by: Hou Zhiqiang Applied, thanks.
Re: [PATCHv3 2/5] arm64: dts: layerscape: add num-viewport property for PCIe DT nodes
On Tue, Dec 18, 2018 at 04:19:32AM +, Z.q. Hou wrote: > From: Hou Zhiqiang > > Add num-viewport property for PCIe DT nodes to specify how many > viewports are implemented. > > Signed-off-by: Hou Zhiqiang Applied, thanks.
Re: [V3, 4/4] media: platform: dwc: Add MIPI CSI-2 controller driver
On 10.01.2019 18:18, Luis de Oliveira wrote: > > > On 09-Jan-19 13:07, eugen.hris...@microchip.com wrote: >> >> >> On 19.10.2018 15:52, Luis Oliveira wrote: >>> Add the Synopsys MIPI CSI-2 controller driver. This >>> controller driver is divided in platform dependent functions >>> and core functions. It also includes a platform for future >>> DesignWare drivers. >>> >>> Signed-off-by: Luis Oliveira >>> --- >>> Changelog >>> v2-V3 >>> - exposed IPI settings to userspace >>> - fixed headers >>> >>>MAINTAINERS | 11 + >>>drivers/media/platform/dwc/Kconfig | 30 +- >>>drivers/media/platform/dwc/Makefile | 2 + >>>drivers/media/platform/dwc/dw-csi-plat.c | 699 >>> +++ >>>drivers/media/platform/dwc/dw-csi-plat.h | 77 >>>drivers/media/platform/dwc/dw-mipi-csi.c | 494 ++ >>>drivers/media/platform/dwc/dw-mipi-csi.h | 202 + >>>include/media/dwc/dw-mipi-csi-pltfrm.h | 102 + >>>8 files changed, 1616 insertions(+), 1 deletion(-) >>>create mode 100644 drivers/media/platform/dwc/dw-csi-plat.c >>>create mode 100644 drivers/media/platform/dwc/dw-csi-plat.h >>>create mode 100644 drivers/media/platform/dwc/dw-mipi-csi.c >>>create mode 100644 drivers/media/platform/dwc/dw-mipi-csi.h >>>create mode 100644 include/media/dwc/dw-mipi-csi-pltfrm.h >>> >> >> [snip] >> >>> +/* Video formats supported by the MIPI CSI-2 */ >>> +const struct mipi_fmt dw_mipi_csi_formats[] = { >>> + { >>> + /* RAW 8 */ >>> + .code = MEDIA_BUS_FMT_SBGGR8_1X8, >>> + .depth = 8, >>> + }, >>> + { >>> + /* RAW 10 */ >>> + .code = MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_BE, >>> + .depth = 10, >>> + }, >> >> Hi Luis, >> >> Any reason why RAW12 format is not handled here ? >> >> Here, namely MEDIA_BUS_FMT_SBGGR12_1X12 etc. >> > Hi Eugen, > > My Hw testing setup currently does not support it, so I didn't add it. > >>> + { >>> + /* RGB 565 */ >>> + .code = MEDIA_BUS_FMT_RGB565_2X8_BE, >>> + .depth = 16, >>> + }, >>> + { >>> + /* BGR 565 */ >>> + .code = MEDIA_BUS_FMT_RGB565_2X8_LE, >>> + .depth = 16, >>> + }, >>> + { >>> + /* RGB 888 */ >>> + .code = MEDIA_BUS_FMT_RGB888_2X12_LE, >>> + .depth = 24, >>> + }, >>> + { >>> + /* BGR 888 */ >>> + .code = MEDIA_BUS_FMT_RGB888_2X12_BE, >>> + .depth = 24, >>> + }, >>> +}; >> >> [snip] >> >>> + >>> +void dw_mipi_csi_set_ipi_fmt(struct mipi_csi_dev *csi_dev) >>> +{ >>> + struct device *dev = csi_dev->dev; >>> + >>> + if (csi_dev->ipi_dt) >>> + dw_mipi_csi_write(csi_dev, reg.IPI_DATA_TYPE, csi_dev->ipi_dt); >>> + else { >>> + switch (csi_dev->fmt->code) { >>> + case MEDIA_BUS_FMT_RGB565_2X8_BE: >>> + case MEDIA_BUS_FMT_RGB565_2X8_LE: >>> + dw_mipi_csi_write(csi_dev, >>> + reg.IPI_DATA_TYPE, CSI_2_RGB565); >>> + dev_dbg(dev, "DT: RGB 565"); >>> + break; >>> + >>> + case MEDIA_BUS_FMT_RGB888_2X12_LE: >>> + case MEDIA_BUS_FMT_RGB888_2X12_BE: >>> + dw_mipi_csi_write(csi_dev, >>> + reg.IPI_DATA_TYPE, CSI_2_RGB888); >>> + dev_dbg(dev, "DT: RGB 888"); >>> + break; >>> + case MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_BE: >>> + dw_mipi_csi_write(csi_dev, >>> + reg.IPI_DATA_TYPE, CSI_2_RAW10); >>> + dev_dbg(dev, "DT: RAW 10"); >>> + break; >>> + case MEDIA_BUS_FMT_SBGGR8_1X8: >>> + dw_mipi_csi_write(csi_dev, >>> + reg.IPI_DATA_TYPE, CSI_2_RAW8); >>> + dev_dbg(dev, "DT: RAW 8"); >>> + break; >> >> Same here, in CSI_2_RAW12 case it will default to a RGB565 case. >> >> Thanks, >> >> Eugen >> >> > I will try to add the support for this data type in my next patchset if not I > will flag it as unsupported for now in the commit message and code. Hi Luis, I am currently trying to see if your driver works , and I need the RAW12 type, that's why I am asking about it. One question related to the subdevice you create here, how do you register this subdev into the media subsystem ? sync or async, or not at all ? After the driver probes, there is no call to the set format functions, I added a node inside the Device tree, I see you are registering media pads, but the other endpoint needs to be an async waiting for completion node or your subdev registers in some other way ? (maybe some link validation required ?) Thanks for your help, Eugen > > Thanks for your review, > Luis > >> >>> + default: >>> + dw_mipi_csi_write(csi_dev
Re: [PATCH v2 2/4] tee: optee: add TEE bus device enumeration support
On Thu, 10 Jan 2019 at 19:49, Daniel Thompson wrote: > > On Thu, Jan 10, 2019 at 05:54:55PM +0530, Sumit Garg wrote: > > OP-TEE provides a pseudo TA to enumerate TAs which can act as devices/ > > services for TEE bus. So implement device enumeration using invoke > > function: PTA_CMD_GET_DEVICES provided by pseudo TA to fetch array of > > device UUIDs. Also register these enumerated devices with TEE bus as > > "optee-clntX" device. > > > > Signed-off-by: Sumit Garg > > --- > > drivers/tee/optee/Makefile| 1 + > > drivers/tee/optee/core.c | 4 + > > drivers/tee/optee/device.c| 150 > > ++ > > drivers/tee/optee/optee_private.h | 3 + > > 4 files changed, 158 insertions(+) > > create mode 100644 drivers/tee/optee/device.c > > > > diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile > > index 48d262a..56263ae 100644 > > --- a/drivers/tee/optee/Makefile > > +++ b/drivers/tee/optee/Makefile > > @@ -5,3 +5,4 @@ optee-objs += call.o > > optee-objs += rpc.o > > optee-objs += supp.o > > optee-objs += shm_pool.o > > +optee-objs += device.o > > diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c > > index e5efce3..ac59c77 100644 > > --- a/drivers/tee/optee/core.c > > +++ b/drivers/tee/optee/core.c > > @@ -634,6 +634,10 @@ static struct optee *optee_probe(struct device_node > > *np) > > if (optee->sec_caps & OPTEE_SMC_SEC_CAP_DYNAMIC_SHM) > > pr_info("dynamic shared memory is enabled\n"); > > > > + rc = optee_enumerate_devices(); > > + if (rc) > > + goto err; > > + > > pr_info("initialized driver\n"); > > return optee; > > err: > > diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c > > new file mode 100644 > > index 000..b38d24b > > --- /dev/null > > +++ b/drivers/tee/optee/device.c > > @@ -0,0 +1,150 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2019 Linaro Ltd. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include "optee_private.h" > > + > > +/* > > + * Get device UUIDs > > + * > > + * [out] memref[0]Array of device UUIDs > > + * > > + * Return codes: > > + * TEE_SUCCESS - Invoke command success > > + * TEE_ERROR_BAD_PARAMETERS - Incorrect input param > > + * TEE_ERROR_SHORT_BUFFER - Output buffer size less than required > > + */ > > +#define PTA_CMD_GET_DEVICES 0x0 > > + > > +static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void > > *data) > > +{ > > + if (ver->impl_id == TEE_IMPL_ID_OPTEE) > > + return 1; > > + else > > + return 0; > > +} > > + > > +static int get_devices(struct tee_context *ctx, u32 session, > > +struct tee_shm *device_uuid, u32 *shm_size) > > Missing const on device_uuid? > I don't think we should have a const for device_uuid here as this is shared memory struct pointer which is dynamically allocated and used to fetch device UUIDs. > > > +{ > > + u32 ret = 0; > > + struct tee_ioctl_invoke_arg inv_arg = {0}; > > + struct tee_param param[4] = {0}; > > + > > + /* Invoke PTA_CMD_GET_DEVICES function */ > > + inv_arg.func = PTA_CMD_GET_DEVICES; > > + inv_arg.session = session; > > + inv_arg.num_params = 4; > > + > > + /* Fill invoke cmd params */ > > + param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT; > > + param[0].u.memref.shm = device_uuid; > > + param[0].u.memref.size = *shm_size; > > + param[0].u.memref.shm_offs = 0; > > + > > + ret = tee_client_invoke_func(ctx, &inv_arg, param); > > + if ((ret < 0) || ((inv_arg.ret != TEEC_SUCCESS) && > > + (inv_arg.ret != TEEC_ERROR_SHORT_BUFFER))) { > > + pr_err("PTA_CMD_GET_DEVICES invoke function err: %x\n", > > +inv_arg.ret); > > + return -EINVAL; > > + } > > + > > + *shm_size = param[0].u.memref.size; > > + > > + return 0; > > +} > > + > > +static int optee_register_device(uuid_t *device_uuid, u32 device_id) > > const? > Will add const here. > > > +{ > > + struct tee_client_device *optee_device = NULL; > > + int rc; > > + > > + optee_device = kzalloc(sizeof(*optee_device), GFP_KERNEL); > > + if (!optee_device) > > + return -ENOMEM; > > + > > + optee_device->dev.bus = &tee_bus_type; > > + dev_set_name(&optee_device->dev, "optee-clnt%u", device_id); > > + uuid_copy(&optee_device->id.uuid, device_uuid); > > + > > + rc = device_register(&optee_device->dev); > > + if (rc) > > + pr_err("device registration failed, err: %d\n", rc); > > Leak optee_device? > Will fix. > > > + > > + return rc; > > +} > > + > > +int optee_enumerate_devices(void) > > +{ > > + uuid_t pta_uuid = > > + UUID_INIT(0x7011a688, 0xddde, 0x4053, > > + 0xa5, 0xa9, 0x7b, 0x3c, 0x4d, 0xdf, 0x13, 0xb8); > > I think this co
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Thu, Jan 10, 2019 at 08:08:37PM -0800, Andy Lutomirski wrote: > > On Jan 10, 2019, at 8:04 PM, Dave Chinner > > wrote: > > > >> On Thu, Jan 10, 2019 at 06:18:16PM -0800, Linus Torvalds > >> wrote: > >>> On Thu, Jan 10, 2019 at 6:03 PM Dave Chinner > >>> wrote: > >>> > On Thu, Jan 10, 2019 at 02:11:01PM -0800, Linus Torvalds > wrote: And we *can* do sane things about RWF_NOWAIT. For > example, we could start async IO on RWF_NOWAIT, and suddenly > it would go from "probe the page cache" to "probe and fill", > and be much harder to use as an attack vector.. > >>> > >>> We can only do that if the application submits the read via > >>> AIO and has an async IO completion reporting mechanism. > >> > >> Oh, no, you misunderstand. > >> > >> RWF_NOWAIT has a lot of situations where it will potentially > >> return early (the DAX and direct IO ones have their own), but I > >> was thinking of the one in generic_file_buffered_read(), which > >> triggers when you don't find a page mapping. That looks like > >> the obvious "probe page cache" case. > >> > >> But we could literally move that test down just a few lines. > >> Let it start read-ahead. > >> > >> .. and then it will actually trigger on the *second* case > >> instead, where we have > >> > >>if (!PageUptodate(page)) { if (iocb->ki_flags & > >>IOCB_NOWAIT) { put_page(page); goto would_block; > >>} > >> > >> and that's where RWF_MNOWAIT would act. > >> > >> It would still return EAGAIN. > >> > >> But it would have started filling the page cache. So now the > >> act of probing would fill the page cache, and the attacker > >> would be left high and dry - the fact that the page cache now > >> exists is because of the attack, not because of whatever it was > >> trying to measure. > >> > >> See? > > > > Except for fadvise(POSIX_FADV_RANDOM) which triggers this code > > in page_cache_sync_readahead(): > > > >/* be dumb */ if (filp && (filp->f_mode & FMODE_RANDOM)) > >{ force_page_cache_readahead(mapping, filp, offset, > >req_size); return; } > > > > So it will only read the single page we tried to access and > > won't perturb the rest of the message encoded into subsequent > > pages in file. > > There are two types of attacks. One is an intentional side > channel where two cooperating processes communicate. This is, > under some circumstances, a problem, Yes, that's the covert communication channel that can cross container and machine boundaries without any required privileges. > but it’s not one > we’re about to solve in general. The other is an attacker > monitoring an unwilling process. Which uses exactly the same mechanisms as the first case. i.e. controlled invalidation and page cache residency monitoring.If we aren't going to solve the first problem case, the we aren't going to solve the second because they are one and the same problem... However, I suspect you have misunderstood the monitoring mechanism here - dispatch IO for this page doesn't prevent the information leak about that page. It's when we return EAGAIN that we leak information about page cache residency. What Linus is attempting to do is perturb the nearby state of the page cache by triggering async readahead in the EAGAIN case. Async readahead will fill all the holes in readahead window and hence destroy the information about where the page fault landed and instantiated the page cache. That would prevent the attacker from determining what code the executable is running as they would only be able to check a single page in an executable at a time and that makes the attack highly impractical. But if the attacker uses FADV_RANDOM, readahead is only triggered for the page the attacker is trying to read. Hence it does not disturb the nearby page cache residency pattern the executable's page faults left behind and so doesn't destroy the information that they are trying to extract from the unwilling process. Sure, Linus's change makes monitoring the executable file after FADV_RANDOM a "read-once" mechanism. However, detection of what code is executing is a repeated invalidate-and-sweep exercise to begin with, so it basically doesn't change the information or the rate at which the monitoring process can extract information from the file. /me hasn't thought about this sort of stuff since he was running page cache invalidation attacks on Irix system libraries way back in 2002 when he found a libc bug that killed the init process and paniced the kernel. This isn't my first rodeo - it's been well known for a long, long time that the system page cache can be exploited to monitor executing code... Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH v4 0/3] bus: imx-weim
On Mon, Dec 17, 2018 at 10:47:57AM -0500, Sven Van Asbroeck wrote: > Sven Van Asbroeck (3): > dt-bindings: bus: imx-weim: document multiple address ranges per child > node > bus: imx-weim: support multiple address ranges per child node > bus: imx-weim: guard against timing configuration conflicts Applied all, thanks.
Re: [PATCH] xen: Fix x86 sched_clock() interface for xen
On 11/01/2019 00:10, Boris Ostrovsky wrote: > On 1/10/19 12:17 PM, Boris Ostrovsky wrote: >> On 1/10/19 11:14 AM, Juergen Gross wrote: >>> On 10/01/2019 16:34, Boris Ostrovsky wrote: On 1/10/19 5:07 AM, Juergen Gross wrote: > > +void xen_clocksource_suspend(void) > +{ > + xen_clock_value_saved = xen_clocksource_read() - xen_sched_clock_offset; xen_clock_value_saved = xen_sched_clock() maybe? >>> I wanted xen_clocksource_suspend() and xen_clocksource_resume() to >>> be symmetrical to each other. >> OK. >> >> Reviewed-by: Boris Ostrovsky >> >>> In case you are feeling strong about that, I'm not. :-) So in case >>> you insist on it I can change it. Or you can do so while committing. > > > I did some basic testing and noticed this (at loglevel=8): > > [ 64.336488] Freezing user space processes ... (elapsed 0.001 seconds) > done. > [ 64.337805] OOM killer disabled. > [ 64.337814] Freezing remaining freezable tasks ... (elapsed 0.000 > seconds) done. > [ 64.339066] suspending xenstore... > [ 85.888340] xen:grant_table: Grant tables using version 1 layout > [ 64.359729] OOM killer enabled. > [ 64.359736] Restarting tasks ... done. > > > Which made me think that perhaps we should do suspend/restore of the > clocksource as close as possible to HYPERVISOR_suspend() call, e.g. in > xen_arch_pre_suspend()/xen_arch_post_suspend(): > > diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c > index 45fc9caf3880..80ecba3fcc8c 100644 > --- a/arch/x86/xen/suspend.c > +++ b/arch/x86/xen/suspend.c > @@ -22,6 +22,7 @@ static DEFINE_PER_CPU(u64, spec_ctrl); > > void xen_arch_pre_suspend(void) > { > + xen_clocksource_suspend(); > xen_save_time_memory_area(); > > if (xen_pv_domain()) > @@ -36,6 +37,7 @@ void xen_arch_post_suspend(int cancelled) > xen_hvm_post_suspend(cancelled); > > xen_restore_time_memory_area(); > + xen_clocksource_resume(); > } > > static void xen_vcpu_notify_restore(void *data) > > > This still has a window of incorrect clock value (you can see it, for > example, when xen_hvm_post_suspend() does pr_info("Xen HVM callback > vector for event delivery is enabled\n")), but it's smaller than before. > In particular, we will make time right before dpm_resume_start() call. You are right, this is better. Sending out V2 soon. Juergen
[GIT PULL] x86 fixes
Linus, Please pull the latest x86-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus # HEAD: e4f358916d528d479c3c12bd2fd03f2d5a576380 x86, modpost: Replace last remnants of RETPOLINE with CONFIG_RETPOLINE A 32-bit build fix, CONFIG_RETPOLINE fixes and rename CONFIG_RESCTRL to CONFIG_X86_RESCTRL. out-of-topic modifications in x86-urgent-for-linus: - include/linux/module.h # e4f358916d52: x86, modpost: Replace last r samples/seccomp/Makefile # a77d1d196bc6: samples/seccomp: Fix 32-bit scripts/mod/modpost.c # e4f358916d52: x86, modpost: Replace last r Thanks, Ingo --> Borislav Petkov (1): x86/cache: Rename config option to CONFIG_X86_RESCTRL Tycho Andersen (1): samples/seccomp: Fix 32-bit build WANG Chao (1): x86, modpost: Replace last remnants of RETPOLINE with CONFIG_RETPOLINE Documentation/x86/resctrl_ui.txt | 2 +- arch/x86/Kconfig | 2 +- arch/x86/include/asm/resctrl_sched.h | 4 ++-- arch/x86/kernel/cpu/Makefile | 2 +- arch/x86/kernel/cpu/bugs.c | 2 +- arch/x86/kernel/cpu/resctrl/Makefile | 4 ++-- include/linux/compiler-gcc.h | 2 +- include/linux/module.h | 2 +- include/linux/sched.h| 2 +- samples/seccomp/Makefile | 1 + scripts/mod/modpost.c| 2 +- 11 files changed, 13 insertions(+), 12 deletions(-) diff --git a/Documentation/x86/resctrl_ui.txt b/Documentation/x86/resctrl_ui.txt index d9aed8303984..e8e8d14d3c4e 100644 --- a/Documentation/x86/resctrl_ui.txt +++ b/Documentation/x86/resctrl_ui.txt @@ -9,7 +9,7 @@ Fenghua Yu Tony Luck Vikas Shivappa -This feature is enabled by the CONFIG_RESCTRL and the X86 /proc/cpuinfo +This feature is enabled by the CONFIG_X86_RESCTRL and the x86 /proc/cpuinfo flag bits: RDT (Resource Director Technology) Allocation - "rdt_a" CAT (Cache Allocation Technology) - "cat_l3", "cat_l2" diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 6185d4f33296..15af091611e2 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -446,7 +446,7 @@ config RETPOLINE branches. Requires a compiler with -mindirect-branch=thunk-extern support for full protection. The kernel may run slower. -config RESCTRL +config X86_RESCTRL bool "Resource Control support" depends on X86 && (CPU_SUP_INTEL || CPU_SUP_AMD) select KERNFS diff --git a/arch/x86/include/asm/resctrl_sched.h b/arch/x86/include/asm/resctrl_sched.h index 54990fe2a3ae..40ebddde6ac2 100644 --- a/arch/x86/include/asm/resctrl_sched.h +++ b/arch/x86/include/asm/resctrl_sched.h @@ -2,7 +2,7 @@ #ifndef _ASM_X86_RESCTRL_SCHED_H #define _ASM_X86_RESCTRL_SCHED_H -#ifdef CONFIG_RESCTRL +#ifdef CONFIG_X86_RESCTRL #include #include @@ -88,6 +88,6 @@ static inline void resctrl_sched_in(void) static inline void resctrl_sched_in(void) {} -#endif /* CONFIG_RESCTRL */ +#endif /* CONFIG_X86_RESCTRL */ #endif /* _ASM_X86_RESCTRL_SCHED_H */ diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile index ac78f90aea56..b6fa0869f7aa 100644 --- a/arch/x86/kernel/cpu/Makefile +++ b/arch/x86/kernel/cpu/Makefile @@ -39,7 +39,7 @@ obj-$(CONFIG_CPU_SUP_UMC_32) += umc.o obj-$(CONFIG_X86_MCE) += mce/ obj-$(CONFIG_MTRR) += mtrr/ obj-$(CONFIG_MICROCODE)+= microcode/ -obj-$(CONFIG_RESCTRL) += resctrl/ +obj-$(CONFIG_X86_RESCTRL) += resctrl/ obj-$(CONFIG_X86_LOCAL_APIC) += perfctr-watchdog.o diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 8654b8b0c848..1de0f4170178 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -215,7 +215,7 @@ static enum spectre_v2_mitigation spectre_v2_enabled __ro_after_init = static enum spectre_v2_user_mitigation spectre_v2_user __ro_after_init = SPECTRE_V2_USER_NONE; -#ifdef RETPOLINE +#ifdef CONFIG_RETPOLINE static bool spectre_v2_bad_module; bool retpoline_module_ok(bool has_retpoline) diff --git a/arch/x86/kernel/cpu/resctrl/Makefile b/arch/x86/kernel/cpu/resctrl/Makefile index 6895049ceef7..1cabe6fd8e11 100644 --- a/arch/x86/kernel/cpu/resctrl/Makefile +++ b/arch/x86/kernel/cpu/resctrl/Makefile @@ -1,4 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 -obj-$(CONFIG_RESCTRL) += core.o rdtgroup.o monitor.o -obj-$(CONFIG_RESCTRL) += ctrlmondata.o pseudo_lock.o +obj-$(CONFIG_X86_RESCTRL) += core.o rdtgroup.o monitor.o +obj-$(CONFIG_X86_RESCTRL) += ctrlmondata.o pseudo_lock.o CFLAGS_pseudo_lock.o = -I$(src) diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h index 5776da43da97..dd8268f5f5f0 100644 --- a/include/linux/compiler-gcc.h +++ b/include/linux/compiler-gcc.h @@ -68,7 +68,7 @@ */ #define uninitialized
Re: [GIT PULL 0/4] perf/core fixes and improvements
* Arnaldo Carvalho de Melo wrote: > Hi Ingo, > > Please consider pulling, now there are no more ABI header > warnings, > > - Arnaldo > > Test results at the end of this message, as usual. > > The following changes since commit 576b50ea235699d83758c0c514c65b8d486a159d: > > Merge tag 'perf-core-for-mingo-5.0-20190108' of > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent > (2019-01-09 07:59:40 +0100) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-core-for-mingo-5.0-20190110 > > for you to fetch changes up to 15c03092a9fbcdd041f58e5f832bf76c21c42e6a: > > tools headers powerpc: Remove unistd.h (2019-01-10 10:42:08 -0300) > > > perf/core fixes and improvements: > > perf trace: > > Ravi Bangoria: > > - Rework PowerPC syscall table generation, now using a .tbl file just like > x86_64 and S/390, also silencing a tools build warning about headers out > of > sync with the kernel sources. > > tools include uapi: > > Arnaldo Carvalho de Melo: > > - Sync linux/if_link.h copy with the kernel sources, silencing a build > warning. > > perf top: > > Arnaldo Carvalho de Melo: > > - Add 'arch_cpu_idle' to the list of kernel idle symbols, noticed on a > Orange > Pi Zero ARM board, just like with other symbols in other arches. > > Signed-off-by: Arnaldo Carvalho de Melo > > > Arnaldo Carvalho de Melo (2): > tools include uapi: Sync linux/if_link.h copy with the kernel sources > perf symbols: Add 'arch_cpu_idle' to the list of kernel idle symbols > > Ravi Bangoria (2): > perf powerpc: Rework syscall table generation > tools headers powerpc: Remove unistd.h > > tools/arch/powerpc/include/uapi/asm/unistd.h | 404 --- > tools/include/uapi/linux/if_link.h | 19 + > tools/perf/arch/powerpc/Makefile | 15 +- > .../perf/arch/powerpc/entry/syscalls/mksyscalltbl | 22 +- > tools/perf/arch/powerpc/entry/syscalls/syscall.tbl | 427 > + > tools/perf/check-headers.sh| 1 - > tools/perf/util/symbol.c | 1 + > 7 files changed, 470 insertions(+), 419 deletions(-) > delete mode 100644 tools/arch/powerpc/include/uapi/asm/unistd.h > create mode 100644 tools/perf/arch/powerpc/entry/syscalls/syscall.tbl Pulled, thanks a lot Arnaldo! Ingo
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Thu, Jan 10, 2019 at 8:58 PM Dominique Martinet wrote: > > I get on average over a few queries approximately a real time of 350ms, > 230ms and 220ms immediately after drop cache and service restart, and > 150ms, 60ms and 60ms after a prefetch (hand-wavy average over 3 runs, I > didn't have the patience to do proper testing). > (In both cases, user/sys are less than 10ms; I don't see much difference > there) But those numbers aren't about the mincore() change. That's just from dropping caches. Now, what's the difference with the mincore change, and without? Is it actually measurable? Because that's all that matters: is the mincore change something you can even notice? Is it a big regression? The fact that things are slower when they are cold in the cache isn't the issue. The issue is whether the change to mincore semantics makes any difference to real loads. Linus
Re: [PATCH 4.19 000/170] 4.19.14-stable review
On Thu, Jan 10, 2019 at 06:27:33AM -0800, Guenter Roeck wrote: > On 1/10/19 5:17 AM, Greg Kroah-Hartman wrote: > > On Thu, Jan 10, 2019 at 07:52:07AM +0100, Greg Kroah-Hartman wrote: > > > On Wed, Jan 09, 2019 at 11:40:48AM -0800, Guenter Roeck wrote: > > > > On Wed, Jan 09, 2019 at 03:38:11PM +0100, Greg Kroah-Hartman wrote: > > > > > On Tue, Jan 08, 2019 at 03:07:31PM -0800, Guenter Roeck wrote: > > > > > > On Mon, Jan 07, 2019 at 01:30:27PM +0100, Greg Kroah-Hartman wrote: > > > > > > > This is the start of the stable review cycle for the 4.19.14 > > > > > > > release. > > > > > > > There are 170 patches in this series, all will be posted as a > > > > > > > response > > > > > > > to this one. If anyone has any issues with these being applied, > > > > > > > please > > > > > > > let me know. > > > > > > > > > > > > > > Responses should be made by Wed Jan 9 10:43:54 UTC 2019. > > > > > > > Anything received after that time might be too late. > > > > > > > > > > > > > > > > > > > For v4.19.13-171-gc68ce175c3b8: > > > > > > > > > > > > Build results: > > > > > > total: 155 pass: 152 fail: 3 > > > > > > Failed builds: > > > > > > powerpc:ppc64e_defconfig > > > > > > powerpc:cell_defconfig > > > > > > powerpc:maple_defconfig > > > > > > Qemu test results: > > > > > > total: 332 pass: 319 fail: 13 > > > > > > Failed tests: > > > > > > ppc64:mac99:ppc64_book3s_defconfig:nosmp:initrd > > > > > > ppc64:mac99:ppc64_book3s_defconfig:smp:initrd > > > > > > ppc64:mac99:ppc64_book3s_defconfig:smp:ide:rootfs > > > > > > ppc64:mac99:ppc64_book3s_defconfig:smp:mmc:rootfs > > > > > > ppc64:mac99:ppc64_book3s_defconfig:smp:nvme:rootfs > > > > > > ppc64:mac99:ppc64_book3s_defconfig:smp:scsi[DC395]:rootfs > > > > > > ppc64:mpc8544ds:ppc64_e5500_defconfig:nosmp:initrd > > > > > > ppc64:mpc8544ds:ppc64_e5500_defconfig:smp:initrd > > > > > > ppc64:ppce500:corenet64_smp_defconfig:e5500:initrd > > > > > > ppc64:ppce500:corenet64_smp_defconfig:e5500:nvme:rootfs > > > > > > ppc64:ppce500:corenet64_smp_defconfig:e5500:mmc:rootfs > > > > > > ppc64:ppce500:corenet64_smp_defconfig:e5500:scsi[53C895A]:rootfs > > > > > > ppc64:ppce500:corenet64_smp_defconfig:e5500:sata-sii3112:rootfs > > > > > > > > > > Ugh, I thought this was just the cell build, didn't realize it hit > > > > > more. > > > > > > > > > > Ok, I've dropped the patch from all queues. Odd that it only causes > > > > > problems on 4.19.y :( > > > > > > > > > I don't know what you dropped, but v4.19.14 fails to build with > > > > the same error. Did you drop it after the release ? > > > > > > No, I should have dropped it before the release. Let me go see what I > > > messed up... > > > > I dropped e1c3743e1a20 ("powerpc/tm: Set MSR[TS] just prior to > > recheckpoint") > > from the stable trees, which is what I was told was the commit that was > > causing the problems by Christoph and Breno (on to: now). > > > > Was that not the offending commit? If so, what one was? > > > $ git describe > v4.19.14 > groeck@server:~/src/linux-stable$ git log --oneline v4.19.13.. arch/powerpc/ > a9935a127688 powerpc/tm: Unset MSR[TS] if not recheckpointing > 34fc09193486 powerpc/fsl: Fix spectre_v2 mitigations reporting > groeck@server:~/src/linux-stable$ > > a9935a127688 is the culprit. Thanks for this, now reverted. greg k-h
Re: [GIT PULL] seccomp: build fix for v5.0-rc2
* Tycho Andersen wrote: > On Wed, Jan 09, 2019 at 07:59:16AM +0100, Ingo Molnar wrote: > > > > * Kees Cook wrote: > > > > > This was already picked up by x86-urgent... > > > > > > -Kees > > > > I'm fine with both routes - if Linus pulls this I'll zap the x86/urgent > > one. > > The patches are different actually. I've confirmed the one in > x86/urgent is correct, and this one is from the initial thread where I > was just guessing. The difference is HOSTCFLAGS vs. HOSTLDFLAGS for .o > files. So I think we should drop this and just keep the one in > x86/urgent. Ok - will send this to Linus now. Thanks, Ingo
Re: [PATCH 4.19 000/170] 4.19.14-stable review
On Thu, Jan 10, 2019 at 11:55:45PM +0100, Christoph Biedl wrote: > Greg Kroah-Hartman wrote... > > > Ok, Breno and Christoph, what should I do here? Should I drop this > > patch in the tree or add this new one? Ideally I can fix this soon as I > > don't like having broken trees out there... > > Whatever Breno says - I don't feel competent enough to decide what's > right here. Ok, I'm reverting it and adding back the patch that I accidentally dropped thinking it was the broken one. thanks, greg k-h
[PATCH] rtc: snvs: make sure clock is enabled for interrupt handle
During system suspend, the SNVS RTC's clock will be disabled in noirq suspend phase, but SNVS RTC's alarm interrupt could still arrive, system will hang if SNVS RTC driver tries to access register without clock enabled, this patch fixes the issue of this scenario. Signed-off-by: Anson Huang --- drivers/rtc/rtc-snvs.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/rtc/rtc-snvs.c b/drivers/rtc/rtc-snvs.c index b2483a7..0b9eff1 100644 --- a/drivers/rtc/rtc-snvs.c +++ b/drivers/rtc/rtc-snvs.c @@ -239,6 +239,9 @@ static irqreturn_t snvs_rtc_irq_handler(int irq, void *dev_id) u32 lpsr; u32 events = 0; + if (data->clk) + clk_enable(data->clk); + regmap_read(data->regmap, data->offset + SNVS_LPSR, &lpsr); if (lpsr & SNVS_LPSR_LPTA) { @@ -253,6 +256,9 @@ static irqreturn_t snvs_rtc_irq_handler(int irq, void *dev_id) /* clear interrupt status */ regmap_write(data->regmap, data->offset + SNVS_LPSR, lpsr); + if (data->clk) + clk_disable(data->clk); + return events ? IRQ_HANDLED : IRQ_NONE; } -- 2.7.4
Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged
On Thu, Jan 10, 2019 at 8:04 PM Dave Chinner wrote: > > So it will only read the single page we tried to access and won't > perturb the rest of the message encoded into subsequent pages in > file. Dave, you're being intentionally obtuse, aren't you? It's only that single page that *matters*. That's the page that the probe reveals the status of - but it's also the page that the probe then *changes* the status of. See? Think of it as "the act of measurement changes that which is measured". And that makes the measurement pointless. Linus
Re: kmemleak: Cannot allocate a kmemleak_object structure - Kernel 4.19.13
One more thought that may be nothing, but when kmemleak crashed, SUnreclaim was at 932552 kB, and after reclaimed/cleared 299840 kB. There weren't any performance issues like when I had a leak of 5.5 gB in the 4.18 kernel. On Mon, Jan 7, 2019 at 3:52 AM Catalin Marinas wrote: > > Under memory pressure, kmemleak may fail to allocate memory. See this > patch for an attempt to slightly improve things but it's not a proper > solution: > > http://lkml.kernel.org/r/20190102180619.12392-1-...@lca.pw > > -- > Catalin
[PATCH] Bluetooth: hci_uart: Add a local variable to store the result of h4_recv_buf()
In h4_recv(), if h4_recv_buf() returns error and h4_recv() is asynchronously called again before setting rx_skb to NULL, ERR_PTR will be dereferenced in h4_recv_buf(). Check return value in a local variable before writing to rx_skb. Reported-by: syzbot+017a32f149406df32...@syzkaller.appspotmail.com Signed-off-by: Myungho Jung --- drivers/bluetooth/hci_h4.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/bluetooth/hci_h4.c b/drivers/bluetooth/hci_h4.c index fb97a3bf069b..fa30ec9cebd4 100644 --- a/drivers/bluetooth/hci_h4.c +++ b/drivers/bluetooth/hci_h4.c @@ -124,19 +124,22 @@ static const struct h4_recv_pkt h4_recv_pkts[] = { static int h4_recv(struct hci_uart *hu, const void *data, int count) { struct h4_struct *h4 = hu->priv; + struct sk_buff *skb; if (!test_bit(HCI_UART_REGISTERED, &hu->flags)) return -EUNATCH; - h4->rx_skb = h4_recv_buf(hu->hdev, h4->rx_skb, data, count, -h4_recv_pkts, ARRAY_SIZE(h4_recv_pkts)); - if (IS_ERR(h4->rx_skb)) { - int err = PTR_ERR(h4->rx_skb); + skb = h4_recv_buf(hu->hdev, h4->rx_skb, data, count, + h4_recv_pkts, ARRAY_SIZE(h4_recv_pkts)); + if (IS_ERR(skb)) { + int err = PTR_ERR(skb); bt_dev_err(hu->hdev, "Frame reassembly failed (%d)", err); h4->rx_skb = NULL; return err; } + h4->rx_skb = skb; + return count; } -- 2.17.1
[PATCH] fs/cachefiles/namei.c: Remove duplicate header
Remove linux/xattr.h which is included more than once Signed-off-by: Sabyasachi Gupta --- fs/cachefiles/namei.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/cachefiles/namei.c b/fs/cachefiles/namei.c index 95983c7..edecb7f 100644 --- a/fs/cachefiles/namei.c +++ b/fs/cachefiles/namei.c @@ -20,7 +20,6 @@ #include #include #include -#include #include "internal.h" #define CACHEFILES_KEYBUF_SIZE 512 -- 2.7.4
Re: [PATCH v2 1/4] tee: add bus driver framework for TEE based devices
On Thu, 10 Jan 2019 at 19:36, Daniel Thompson wrote: > > On Thu, Jan 10, 2019 at 05:54:54PM +0530, Sumit Garg wrote: > > Introduce a generic TEE bus driver concept for TEE based kernel drivers > > which would like to communicate with TEE based devices/services. > > > > In this TEE bus concept, devices/services are identified via Universally > > Unique Identifier (UUID) and drivers register a table of device UUIDs > > which they can support. > > > > So this TEE bus framework registers a match() callback function which > > iterates over the driver UUID table to find a corresponding match for > > device UUID. If a match is found, then this particular device is probed > > via corresponding probe api registered by the driver. This process > > happens whenever a device or a driver is registered with TEE bus. > > > > Also this framework allows for device enumeration to be specific to > > corresponding TEE implementation like OP-TEE etc. > > > > Signed-off-by: Sumit Garg > > --- > > drivers/tee/tee_core.c | 41 ++--- > > include/linux/tee_drv.h | 36 > > 2 files changed, 74 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c > > index 7b2bb4c..9ddb89e 100644 > > --- a/drivers/tee/tee_core.c > > +++ b/drivers/tee/tee_core.c > > @@ -15,7 +15,6 @@ > > #define pr_fmt(fmt) "%s: " fmt, __func__ > > > > #include > > -#include > > #include > > #include > > #include > > @@ -1027,6 +1026,30 @@ int tee_client_invoke_func(struct tee_context *ctx, > > } > > EXPORT_SYMBOL_GPL(tee_client_invoke_func); > > > > +static int tee_client_device_match(struct device *dev, > > +struct device_driver *drv) > > +{ > > + struct tee_client_device *tee_device; > > + const struct tee_client_device_id *id_table; > > + > > + tee_device = to_tee_client_device(dev); > > + id_table = to_tee_client_driver(drv)->id_table; > > + > > + while (!uuid_is_null(&id_table->uuid)) { > > + if (uuid_equal(&tee_device->id.uuid, &id_table->uuid)) > > + return 1; > > + id_table++; > > + } > > + > > + return 0; > > +} > > + > > +struct bus_type tee_bus_type = { > > + .name = "tee", > > + .match = tee_client_device_match, > > +}; > > +EXPORT_SYMBOL_GPL(tee_bus_type); > > + > > static int __init tee_init(void) > > { > > int rc; > > @@ -1040,10 +1063,21 @@ static int __init tee_init(void) > > rc = alloc_chrdev_region(&tee_devt, 0, TEE_NUM_DEVICES, "tee"); > > if (rc) { > > pr_err("failed to allocate char dev region\n"); > > - class_destroy(tee_class); > > - tee_class = NULL; > > + goto class_err; > > } > > > > + rc = bus_register(&tee_bus_type); > > + if (rc) { > > + pr_err("failed to register tee bus\n"); > > + goto class_err; > > There is an unregister_chrdev_region() in tee_exit(). Why isn't it > needed on this error path? > Will add "unregister_chrdev_region()" on this error path. -Sumit > > > + } > > + > > + return 0; > > + > > +class_err: > > + class_destroy(tee_class); > > + tee_class = NULL; > > + > > return rc; > > } > > > > @@ -1052,6 +1086,7 @@ static void __exit tee_exit(void) > > class_destroy(tee_class); > > tee_class = NULL; > > unregister_chrdev_region(tee_devt, TEE_NUM_DEVICES); > > + bus_unregister(&tee_bus_type); > > } > > > > subsys_initcall(tee_init); > > diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h > > index 6cfe058..ed16bf1 100644 > > --- a/include/linux/tee_drv.h > > +++ b/include/linux/tee_drv.h > > @@ -20,6 +20,8 @@ > > #include > > #include > > #include > > +#include > > +#include > > > > /* > > * The file describes the API provided by the generic TEE driver to the > > @@ -538,4 +540,38 @@ static inline bool tee_param_is_memref(struct > > tee_param *param) > > } > > } > > > > +extern struct bus_type tee_bus_type; > > + > > +/** > > + * struct tee_client_device_id - tee based device identifier > > + * @uuid:For TEE based client devices we use the device uuid > > + * as the identifier. > > + */ > > +struct tee_client_device_id { > > + uuid_t uuid; > > +}; > > + > > +/** > > + * struct tee_client_device - tee based device > > + * @id: device identifier > > + * @dev: device structure > > + */ > > +struct tee_client_device { > > + struct tee_client_device_id id; > > + struct device dev; > > +}; > > +#define to_tee_client_device(d) container_of(d, struct tee_client_device, > > dev) > > + > > +/** > > + * struct tee_client_driver - tee client driver > > + * @id_table:device id table supported by this driver > > + * @driver: driver structure > > + */ > > +struct tee_client_driver { > > + const
Re: ufshcd_queuecommand() triggering after ufshcd_suspend()?
+Zang Thanks, Avri From: John Stultz Sent: Friday, January 11, 2019 1:02:21 AM To: Sahitya Tummala; Christoph Hellwig; Wei Li; Martin K. Petersen Cc: Evan Green; Avri Altman; Vijay Viswanath; lkml; linux-s...@vger.kernel.org Subject: ufshcd_queuecommand() triggering after ufshcd_suspend()? Hey all, Frequently, since support for the HiKey960's UFS code landed in 4.19, I've noticed the following warning on reboot: [ 23.086860] WARNING: CPU: 0 PID: 2507 at drivers/scsi/ufs/ufshcd.c:2460 ufshcd_queuecommand+0x59c/0x5a8 [ 23.096256] Modules linked in: [ 23.099313] CPU: 0 PID: 2507 Comm: kworker/0:1H Tainted: G S 5.0.0-rc1-00068-g3f81a19 #273 [ 23.108873] Hardware name: HiKey960 (DT) [ 23.112802] Workqueue: kblockd blk_mq_requeue_work [ 23.117591] pstate: 8045 (Nzcv daif +PAN -UAO) [ 23.122378] pc : ufshcd_queuecommand+0x59c/0x5a8 [ 23.126990] lr : ufshcd_queuecommand+0x58c/0x5a8 [ 23.131600] sp : ff8015e1ba80 [ 23.134907] x29: ff8015e1ba80 x28: ffc217f94048 [ 23.140214] x27: 0010 x26: ffc217a7c8b8 [ 23.145520] x25: ffc217a7c000 x24: ffc217a7ceb0 [ 23.150827] x23: x22: ffc217a7c808 [ 23.156133] x21: ffc217f94120 x20: 0010 [ 23.161440] x19: ff801186d000 x18: ff801186db08 [ 23.166746] x17: x16: [ 23.172053] x15: ff8095e1b7c7 x14: 692064616574736e [ 23.177360] x13: 6928204e4f5f534b x12: 4c43203d21206574 [ 23.182666] x11: 6174732e676e6974 x10: 61675f6b6c633e2d [ 23.187973] x9 : 61626820646e616d x8 : 6d6f636575657571 [ 23.193280] x7 : x6 : ff801186e000 [ 23.198586] x5 : ff801186e270 x4 : ff8010096dc0 [ 23.203894] x3 : 0001 x2 : 47dd99afde511d00 [ 23.209201] x1 : x0 : [ 23.214509] Call trace: [ 23.216952] ufshcd_queuecommand+0x59c/0x5a8 [ 23.221220] scsi_queue_rq+0x5b4/0x880 [ 23.224964] blk_mq_dispatch_rq_list+0xb0/0x510 [ 23.229492] blk_mq_sched_dispatch_requests+0xf4/0x198 [ 23.234626] __blk_mq_run_hw_queue+0xb4/0x120 [ 23.238978] __blk_mq_delay_run_hw_queue+0x110/0x200 [ 23.243937] blk_mq_run_hw_queue+0xb8/0x118 [ 23.248114] blk_mq_run_hw_queues+0x58/0x78 [ 23.252291] blk_mq_requeue_work+0x140/0x168 [ 23.256560] process_one_work+0x158/0x468 [ 23.260564] worker_thread+0x50/0x460 [ 23.264222] kthread+0x104/0x130 [ 23.267447] ret_from_fork+0x10/0x1c [ 23.271017] ---[ end trace 45f1ee04059cdf00 ]--- Since the warning is triggering from the WARN_ON(hba->clk_gating.state != CLKS_ON) line, I annotated the clk_gating.state changes, and am seeing on reboot: vdc: Waited 0ms for vold sd 0:0:0:3: [sdd] Synchronizing SCSI cache sd 0:0:0:2: [sdc] Synchronizing SCSI cache sd 0:0:0:1: [sdb] Synchronizing SCSI cache sd 0:0:0:0: [sda] Synchronizing SCSI cache ufshcd_suspend: setting clk_gating.state CLKS_OFF ufshcd_queuecommand hba->clk_gating.state != CLKS_ON (instead its 0) So it seems like ufshcd_suspend() is has run, but then the workqueue (occasionally) fires afterwards triggering the issue. Maybe should something in ufshcd_queuecommand be checking the clk_gating.is_suspended flag before proceeding? Other ideas? The logic all seems to be in the generic code, but I'm not sure if maybe the ufs-hisi.c code is mis-managing something? thanks -john
RE: [PATCH 1/2] ahci: qoriq: add lx2160 platforms support
>-Original Message- >From: Leo Li >Sent: 2019年1月11日 4:30 >To: Peng Ma ; shawn...@kernel.org; ax...@kernel.dk >Cc: robh...@kernel.org; mark.rutl...@arm.com; >linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org; >linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; Andy Tang > >Subject: RE: [PATCH 1/2] ahci: qoriq: add lx2160 platforms support > > > >> -Original Message- >> From: Peng Ma >> Sent: Thursday, January 10, 2019 4:32 AM >> To: Peng Ma ; shawn...@kernel.org; ax...@kernel.dk >> Cc: Leo Li ; robh...@kernel.org; >> mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org; >> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux- >> i...@vger.kernel.org; Andy Tang >> Subject: RE: [PATCH 1/2] ahci: qoriq: add lx2160 platforms support >> >> Hi Jens, >> >> I send the sata patchs to the upstream patchwork with >> ./scripts/get_maintainer.pl, but I find my patch on >> http://patchwork.ozlabs.org/project/linux-ide/list/ , I saw the >> MAINTAINERS, the driver/ata/* should be on >> https://patchwork.kernel.org/project/linux- >> block/list/ . could you please help me what the patchwork is right. > >Peng, > >The patchwork used is related to the mailing list which you send the patch to >not the maintainer's git tree used. Since the MAINTAINERS file says >drivers/ata should use linux-ide mailing list, patches will appear in linux-ide >patchwork. > >Regards, >Leo > [Peng Ma] got it, thanks. Best Regards, Peng >> Thanks a lot. >> >> Best Regards, >> Peng >> >> >-Original Message- >> >From: Peng Ma >> >Sent: 2019年1月10日 18:06 >> >To: shawn...@kernel.org; ax...@kernel.dk >> >Cc: Leo Li ; robh...@kernel.org; >> >mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org; >> >devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; >> >linux-...@vger.kernel.org; Peng Ma >> >Subject: [PATCH 1/2] ahci: qoriq: add lx2160 platforms support >> > >> >Lx2160a is a new introduced soc which supports ATA3.0 and Clean up >> >some code >> > >> >Signed-off-by: Peng Ma >> >--- >> > drivers/ata/ahci_qoriq.c | 44 >> > >> > 1 files changed, 12 insertions(+), 32 deletions(-) >> > >> >diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c >> >index >> >ce59253..1994bf2 100644 >> >--- a/drivers/ata/ahci_qoriq.c >> >+++ b/drivers/ata/ahci_qoriq.c >> >@@ -57,7 +57,7 @@ enum ahci_qoriq_type { >> >AHCI_LS2080A, >> >AHCI_LS1046A, >> >AHCI_LS1088A, >> >- AHCI_LS2088A, >> >+ AHCI_LX2160A, >> > }; >> > >> > struct ahci_qoriq_priv { >> >@@ -73,7 +73,7 @@ struct ahci_qoriq_priv { >> >{ .compatible = "fsl,ls2080a-ahci", .data = (void *)AHCI_LS2080A}, >> >{ .compatible = "fsl,ls1046a-ahci", .data = (void *)AHCI_LS1046A}, >> >{ .compatible = "fsl,ls1088a-ahci", .data = (void *)AHCI_LS1088A}, >> >- { .compatible = "fsl,ls2088a-ahci", .data = (void *)AHCI_LS2088A}, >> >+ { .compatible = "fsl,lx2160a-ahci", .data = (void *)AHCI_LX2160A}, >> >{}, >> > }; >> > MODULE_DEVICE_TABLE(of, ahci_qoriq_of_match); @@ -174,12 +174,10 >> @@ >> >static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv) >> >writel(LS1021A_PORT_PHY4, reg_base + PORT_PHY4); >> >writel(LS1021A_PORT_PHY5, reg_base + PORT_PHY5); >> >writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS); >> >- if (qpriv->is_dmacoherent) >> >- writel(AHCI_PORT_AXICC_CFG, >> >- reg_base + LS1021A_AXICC_ADDR); >> >break; >> > >> >case AHCI_LS1043A: >> >+ case AHCI_LS1046A: >> >if (!qpriv->ecc_addr) >> >return -EINVAL; >> >writel(readl(qpriv->ecc_addr) | ECC_DIS_ARMV8_CH2, @@ - >> 188,8 >> >+186,6 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv >> >+*hpriv) >> >writel(AHCI_PORT_PHY2_CFG, reg_base + PORT_PHY2); >> >writel(AHCI_PORT_PHY3_CFG, reg_base + PORT_PHY3); >> >writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS); >> >- if (qpriv->is_dmacoherent) >> >- writel(AHCI_PORT_AXICC_CFG, reg_base + >> PORT_AXICC); >> >break; >> > >> >case AHCI_LS2080A: >> >@@ -197,24 +193,10 @@ static int ahci_qoriq_phy_init(struct >> >ahci_host_priv >> >*hpriv) >> >writel(AHCI_PORT_PHY2_CFG, reg_base + PORT_PHY2); >> >writel(AHCI_PORT_PHY3_CFG, reg_base + PORT_PHY3); >> >writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS); >> >- if (qpriv->is_dmacoherent) >> >- writel(AHCI_PORT_AXICC_CFG, reg_base + >> PORT_AXICC); >> >- break; >> >- >> >- case AHCI_LS1046A: >> >- if (!qpriv->ecc_addr) >> >- return -EINVAL; >> >- writel(readl(qpriv->ecc_addr) | ECC_DIS_ARMV8_CH2, >> >- qpriv->ecc_addr); >> >- writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1); >> >- writel(AHCI_PORT_PHY2_CF
Re: [PATCH 3/4] crypto: hisilicon: Add HiSilicon ZIP accelerator support
On 2019/1/11 14:08, Herbert Xu wrote: > On Sat, Dec 22, 2018 at 03:51:44PM +0800, Zhou Wang wrote: >> >> +static struct crypto_alg hisi_zip_zlib = { >> +.cra_name = "zlib-deflate", >> +.cra_flags = CRYPTO_ALG_TYPE_COMPRESS, >> +.cra_ctxsize= sizeof(struct hisi_zip_ctx), >> +.cra_priority = 300, >> +.cra_module = THIS_MODULE, >> +.cra_init = hisi_zip_alloc_comp_ctx, >> +.cra_exit = hisi_zip_free_comp_ctx, >> +.cra_u = { >> +.compress = { >> +.coa_compress = hisi_zip_compress, >> +.coa_decompress = hisi_zip_decompress >> +} >> +} >> +}; > > Please do not add any new implementations using the compress > interface. You should either use scomp or acomp depending on > whether your driver is synchronous or async. OK, current this driver only supports synchronous interface. Will fix it in v2. Thanks, Zhou > > Thanks, >
Re: [Tee-dev] [PATCH v2 4/4] hwrng: add OP-TEE based rng driver
On Thu, 10 Jan 2019 at 19:26, Joakim Bech wrote: > > On Thu, Jan 10, 2019 at 05:54:57PM +0530, Sumit Garg wrote: > > On ARM SoC's with TrustZone enabled, peripherals like entropy sources > > might not be accessible to normal world (linux in this case) and rather > > accessible to secure world (OP-TEE in this case) only. So this driver > > aims to provides a generic interface to OP-TEE based random number > > generator service. > > > > This driver registers on TEE bus to interact with OP-TEE based rng > > > > device/service. > > > > Signed-off-by: Sumit Garg > > --- > > MAINTAINERS| 5 + > > drivers/char/hw_random/Kconfig | 15 ++ > > drivers/char/hw_random/Makefile| 1 + > > drivers/char/hw_random/optee-rng.c | 272 > > + > > 4 files changed, 293 insertions(+) > > create mode 100644 drivers/char/hw_random/optee-rng.c > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 32d7..502733c 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -11260,6 +11260,11 @@ M: Jens Wiklander > > S: Maintained > > F: drivers/tee/optee/ > > > > +OP-TEE RANDOM NUMBER GENERATOR (RNG) DRIVER > > +M: Sumit Garg > > +S: Maintained > > +F: drivers/char/hw_random/optee-rng.c > > + > > OPA-VNIC DRIVER > > M: Dennis Dalessandro > > M: Niranjana Vishwanathapura > > diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig > > index dac895d..25a7d8f 100644 > > --- a/drivers/char/hw_random/Kconfig > > +++ b/drivers/char/hw_random/Kconfig > > @@ -424,6 +424,21 @@ config HW_RANDOM_EXYNOS > > will be called exynos-trng. > > > > If unsure, say Y. > > + > > +config HW_RANDOM_OPTEE > > + tristate "OP-TEE based Random Number Generator support" > > + depends on OPTEE > > + default HW_RANDOM > > + help > > + This driver provides support for OP-TEE based Random Number > > + Generator on ARM SoCs where hardware entropy sources are not > > + accessible to normal world (Linux). > > + > > + To compile this driver as a module, choose M here: the module > > + will be called optee-rng. > > + > > + If unsure, say Y. > > + > > endif # HW_RANDOM > > > > config UML_RANDOM > > diff --git a/drivers/char/hw_random/Makefile > > b/drivers/char/hw_random/Makefile > > index e35ec3c..7c9ef4a 100644 > > --- a/drivers/char/hw_random/Makefile > > +++ b/drivers/char/hw_random/Makefile > > @@ -38,3 +38,4 @@ obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o > > cavium-rng-vf.o > > obj-$(CONFIG_HW_RANDOM_MTK) += mtk-rng.o > > obj-$(CONFIG_HW_RANDOM_S390) += s390-trng.o > > obj-$(CONFIG_HW_RANDOM_KEYSTONE) += ks-sa-rng.o > > +obj-$(CONFIG_HW_RANDOM_OPTEE) += optee-rng.o > > diff --git a/drivers/char/hw_random/optee-rng.c > > b/drivers/char/hw_random/optee-rng.c > > new file mode 100644 > > index 000..ebfe1f2c > > --- /dev/null > > +++ b/drivers/char/hw_random/optee-rng.c > > @@ -0,0 +1,272 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2018-2019 Linaro Ltd. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define DRIVER_NAME "optee-rng" > > + > > +#define TEE_ERROR_HEALTH_TEST_FAIL 0x0001 > > + > > +/* > > + * TA_CMD_GET_ENTROPY - Get Entropy from RNG > > + * > > + * param[0] (inout memref) - Entropy buffer memory reference > > + * param[1] unused > > + * param[2] unused > > + * param[3] unused > > + * > > + * Result: > > + * TEE_SUCCESS - Invoke command success > > + * TEE_ERROR_BAD_PARAMETERS - Incorrect input param > > + * TEE_ERROR_NOT_SUPPORTED - Requested entropy size greater than size of > > pool > > + * TEE_ERROR_HEALTH_TEST_FAIL - Continuous health testing failed > > + */ > > +#define TA_CMD_GET_ENTROPY 0x0 > > + > > +/* > > + * TA_CMD_GET_RNG_INFO - Get RNG information > > + * > > + * param[0] (out value) - value.a: RNG data-rate in bytes per second > > + *value.b: Quality/Entropy per 1024 bit of data > > + * param[1] unused > > + * param[2] unused > > + * param[3] unused > > + * > > + * Result: > > + * TEE_SUCCESS - Invoke command success > > + * TEE_ERROR_BAD_PARAMETERS - Incorrect input param > > + */ > > +#define TA_CMD_GET_RNG_INFO 0x1 > > + > > +#define MAX_ENTROPY_REQ_SZ (4 * 1024) > > + > > +static struct tee_context *ctx; > > +static struct tee_shm *entropy_shm_pool; > > +static u32 ta_rng_data_rate; > > +static u32 ta_rng_session_id; > > + > > +static size_t get_optee_rng_data(void *buf, size_t req_size) > > +{ > > + u32 ret = 0; > > + u8 *rng_data = NULL; > > + size_t rng_size = 0; > > + struct tee_ioctl_invoke_arg inv_arg = {0}; > > + struct tee_param param[4] = {0}; > > + > > + /* Invoke TA_CMD_GET_RNG function of Trusted App */ > > > TA_CMD_GET_ENTROPY? > Will correct. > > + inv_arg.func = TA_CMD_GET_ENTROPY; > > + inv_arg.ses
RE: [PATCH 11/41] scsi: bfa: bfa_fcs_rport: Mark expected switch fall-throughs
-Original Message- From: Gustavo A. R. Silva [mailto:gust...@embeddedor.com] Sent: 11 January 2019 01:42 To: Anil Gurumurthy ; Sudarsana Kalluru Cc: James E.J. Bottomley ; Martin K. Petersen ; linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH 11/41] scsi: bfa: bfa_fcs_rport: Mark expected switch fall-throughs External Email Hi, Friendly ping (second one): Who can ack/review/take this patch, please? Thanks -- Gustavo On 12/19/18 9:39 AM, Gustavo A. R. Silva wrote: > Hi, > > Friendly ping: > > Who can ack or review this patch, please? > > Thanks > -- > Gustavo > > On 11/27/18 10:27 PM, Gustavo A. R. Silva wrote: >> In preparation to enabling -Wimplicit-fallthrough, mark switch cases >> where we are expecting to fall through. >> >> Notice that I replaced "!! fall through !!" and "!!! fall through !!!" >> comments with "fall through" annotations, which is what GCC is >> expecting to find. >> >> Addresses-Coverity-ID: 744899 ("Missing break in switch") >> Addresses-Coverity-ID: 744900 ("Missing break in switch") >> Addresses-Coverity-ID: 744901 ("Missing break in switch") >> Signed-off-by: Gustavo A. R. Silva >> --- >> drivers/scsi/bfa/bfa_fcs_rport.c | 19 +++ >> 1 file changed, 7 insertions(+), 12 deletions(-) >> >> diff --git a/drivers/scsi/bfa/bfa_fcs_rport.c >> b/drivers/scsi/bfa/bfa_fcs_rport.c >> index de50349a39ce..1e400f2aaece 100644 >> --- a/drivers/scsi/bfa/bfa_fcs_rport.c >> +++ b/drivers/scsi/bfa/bfa_fcs_rport.c >> @@ -427,17 +427,13 @@ bfa_fcs_rport_sm_plogi(struct bfa_fcs_rport_s *rport, >> enum rport_event event) >> case RPSM_EVENT_LOGO_RCVD: >> bfa_fcs_rport_send_logo_acc(rport); >> -/* >> - * !! fall through !! >> - */ >> +/* fall through */ >> case RPSM_EVENT_PRLO_RCVD: >> if (rport->prlo == BFA_TRUE) >> bfa_fcs_rport_send_prlo_acc(rport); >> bfa_fcxp_discard(rport->fcxp); >> -/* >> - * !! fall through !! >> - */ >> +/* fall through */ >> case RPSM_EVENT_FAILED: >> if (rport->plogi_retries < BFA_FCS_RPORT_MAX_RETRIES) { >> rport->plogi_retries++; @@ -868,9 +864,7 @@ >> bfa_fcs_rport_sm_adisc_online(struct bfa_fcs_rport_s *rport, >>* At least go offline when a PLOGI is received. >>*/ >> bfa_fcxp_discard(rport->fcxp); >> -/* >> - * !!! fall through !!! >> - */ >> +/* fall through */ >> case RPSM_EVENT_FAILED: >> case RPSM_EVENT_ADDRESS_CHANGE: >> @@ -1056,6 +1050,7 @@ bfa_fcs_rport_sm_fc4_logosend(struct bfa_fcs_rport_s >> *rport, >> case RPSM_EVENT_LOGO_RCVD: >> bfa_fcs_rport_send_logo_acc(rport); >> +/* fall through */ >> case RPSM_EVENT_PRLO_RCVD: >> if (rport->prlo == BFA_TRUE) >> bfa_fcs_rport_send_prlo_acc(rport); >> @@ -1144,9 +1139,7 @@ bfa_fcs_rport_sm_hcb_offline(struct bfa_fcs_rport_s >> *rport, >> bfa_fcs_rport_send_plogiacc(rport, NULL); >> break; >> } >> -/* >> - * !! fall through !! >> - */ >> +/* fall through */ >> case RPSM_EVENT_ADDRESS_CHANGE: >> if (!bfa_fcs_lport_is_online(rport->port)) { @@ -1303,6 >> +1296,7 @@ bfa_fcs_rport_sm_hcb_logosend(struct bfa_fcs_rport_s *rport, >> case RPSM_EVENT_LOGO_RCVD: >> bfa_fcs_rport_send_logo_acc(rport); >> +/* fall through */ >> case RPSM_EVENT_PRLO_RCVD: >> if (rport->prlo == BFA_TRUE) >> bfa_fcs_rport_send_prlo_acc(rport); >> @@ -1346,6 +1340,7 @@ bfa_fcs_rport_sm_logo_sending(struct bfa_fcs_rport_s >> *rport, >> case RPSM_EVENT_LOGO_RCVD: >> bfa_fcs_rport_send_logo_acc(rport); >> +/* fall through */ >> case RPSM_EVENT_PRLO_RCVD: >> if (rport->prlo == BFA_TRUE) >> bfa_fcs_rport_send_prlo_acc(rport); >> Acked-by: Sudarsana Kalluru
RE: [PATCH 12/41] scsi: bfa: bfa_ioc: Mark expected switch fall-throughs
-Original Message- From: Gustavo A. R. Silva [mailto:gust...@embeddedor.com] Sent: 11 January 2019 01:41 To: Anil Gurumurthy ; Sudarsana Kalluru Cc: James E.J. Bottomley ; Martin K. Petersen ; linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH 12/41] scsi: bfa: bfa_ioc: Mark expected switch fall-throughs External Email Hi, Friendly ping (second one): Who can ack/review/take this patch, please? Thanks -- Gustavo On 12/19/18 9:39 AM, Gustavo A. R. Silva wrote: > Hi, > > Friendly ping: > > Who can ack or review this patch, please? > > Thanks > -- > Gustavo > > On 11/27/18 10:27 PM, Gustavo A. R. Silva wrote: >> In preparation to enabling -Wimplicit-fallthrough, mark switch cases >> where we are expecting to fall through. >> >> Notice that, in this particular case, I replaced "!!! fall through !!!" >> comment with "fall through" annotations, which is what GCC is >> expecting to find. >> >> Addresses-Coverity-ID: 146155 ("Missing break in switch") >> Signed-off-by: Gustavo A. R. Silva >> --- >> drivers/scsi/bfa/bfa_ioc.c | 9 +++-- >> 1 file changed, 3 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/scsi/bfa/bfa_ioc.c b/drivers/scsi/bfa/bfa_ioc.c >> index 16d3aeb0e572..32b24e51cce6 100644 >> --- a/drivers/scsi/bfa/bfa_ioc.c >> +++ b/drivers/scsi/bfa/bfa_ioc.c >> @@ -978,9 +978,7 @@ bfa_iocpf_sm_enabling(struct bfa_iocpf_s *iocpf, enum >> iocpf_event event) >> case IOCPF_E_INITFAIL: >> bfa_iocpf_timer_stop(ioc); >> -/* >> - * !!! fall through !!! >> - */ >> +/* fall through */ >> case IOCPF_E_TIMEOUT: >> writel(1, ioc->ioc_regs.ioc_sem_reg); @@ -1056,9 +1054,7 @@ >> bfa_iocpf_sm_disabling(struct bfa_iocpf_s *iocpf, enum iocpf_event event) >> case IOCPF_E_FAIL: >> bfa_iocpf_timer_stop(ioc); >> -/* >> - * !!! fall through !!! >> - */ >> +/* fall through */ >> case IOCPF_E_TIMEOUT: >> bfa_ioc_set_cur_ioc_fwstate(ioc, BFI_IOC_FAIL); @@ -6007,6 >> +6003,7 @@ bfa_dconf_sm_final_sync(struct bfa_dconf_mod_s *dconf, >> case BFA_DCONF_SM_IOCDISABLE: >> case BFA_DCONF_SM_FLASH_COMP: >> bfa_timer_stop(&dconf->timer); >> +/* fall through */ >> case BFA_DCONF_SM_TIMEOUT: >> bfa_sm_set_state(dconf, bfa_dconf_sm_uninit); >> bfa_fsm_send_event(&dconf->bfa->iocfc, IOCFC_E_DCONF_DONE); >> Acked-by: Sudarsana Kalluru
RE: [PATCH 10/41] scsi: bfa: bfa_fcs_lport: Mark expected switch fall-throughs
-Original Message- From: Gustavo A. R. Silva [mailto:gust...@embeddedor.com] Sent: 11 January 2019 01:42 To: Anil Gurumurthy ; Sudarsana Kalluru Cc: James E.J. Bottomley ; Martin K. Petersen ; linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: [PATCH 10/41] scsi: bfa: bfa_fcs_lport: Mark expected switch fall-throughs External Email Hi, Friendly ping (second one): Who can ack/review/take this patch, please? Thanks -- Gustavo On 12/19/18 9:39 AM, Gustavo A. R. Silva wrote: > Hi, > > Friendly ping: > > Who can ack or review this patch, please? > > Thanks > -- > Gustavo > > On 11/27/18 10:27 PM, Gustavo A. R. Silva wrote: >> In preparation to enabling -Wimplicit-fallthrough, mark switch cases >> where we are expecting to fall through. >> >> Notice that, in this particular case, I replaced "!!! fall through !!!" >> with a "fall through" annotation, which is what GCC is expecting to >> find. >> >> Signed-off-by: Gustavo A. R. Silva >> --- >> drivers/scsi/bfa/bfa_fcs_lport.c | 8 ++-- >> 1 file changed, 2 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/scsi/bfa/bfa_fcs_lport.c >> b/drivers/scsi/bfa/bfa_fcs_lport.c >> index b4f2c1d8742e..646f09f66443 100644 >> --- a/drivers/scsi/bfa/bfa_fcs_lport.c >> +++ b/drivers/scsi/bfa/bfa_fcs_lport.c >> @@ -6430,9 +6430,7 @@ bfa_fcs_vport_sm_logo_for_stop(struct bfa_fcs_vport_s >> *vport, >> switch (event) { >> case BFA_FCS_VPORT_SM_OFFLINE: >> bfa_sm_send_event(vport->lps, BFA_LPS_SM_OFFLINE); >> -/* >> - * !!! fall through !!! >> - */ >> +/* fall through */ >> case BFA_FCS_VPORT_SM_RSP_OK: >> case BFA_FCS_VPORT_SM_RSP_ERROR: >> @@ -6458,9 +6456,7 @@ bfa_fcs_vport_sm_logo(struct bfa_fcs_vport_s *vport, >> switch (event) { >> case BFA_FCS_VPORT_SM_OFFLINE: >> bfa_sm_send_event(vport->lps, BFA_LPS_SM_OFFLINE); >> -/* >> - * !!! fall through !!! >> - */ >> +/* fall through */ >> case BFA_FCS_VPORT_SM_RSP_OK: >> case BFA_FCS_VPORT_SM_RSP_ERROR: >> Acked-by: Sudarsana Kalluru
Re: [PATCH -next] crypto: chelsio - check set_msg_len overflow in generate_b0
On Fri, Dec 28, 2018 at 02:41:00PM +0800, YueHaibing wrote: > set_msg_len may fails with -EOVERFLOW, It should be propagate > to upstream. > > Fixes: 2debd3325e55 ("crypto: chcr - Add AEAD algos.") > Signed-off-by: YueHaibing > --- > drivers/crypto/chelsio/chcr_algo.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Fwd: [PATCH 4/7] CIFS: Do not hide EINTR after sending network packets
Pavel's patch looks correct to me, but since this may be a common issue, how to better handle unexpected EINTR on sock_sendmsg, others outside cifs/smb3 world may have run into this before and have additional comments. -- Forwarded message - From: Pavel Shilovsky Date: Thu, Jan 10, 2019 at 4:25 PM Subject: [PATCH 4/7] CIFS: Do not hide EINTR after sending network packets To: Cc: Steve French , Ronnie Sahlberg Currently we hide EINTR code returned from sock_sendmsg() and return 0 instead. This makes a caller think that we have successfully completed the network operation which is not true. Fix this by properly returning EINTR to callers. Cc: Signed-off-by: Pavel Shilovsky --- fs/cifs/transport.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/cifs/transport.c b/fs/cifs/transport.c index e047f06..aaff9c5 100644 --- a/fs/cifs/transport.c +++ b/fs/cifs/transport.c @@ -387,7 +387,7 @@ __smb_send_rqst(struct TCP_Server_Info *server, int num_rqst, if (rc < 0 && rc != -EINTR) cifs_dbg(VFS, "Error %d sending data on socket to server\n", rc); - else + else if (rc > 0) rc = 0; return rc; -- 2.7.4 -- Thanks, Steve
Re: linux-next: Signed-off-by missing for commit in the net tree
Should i make v3 with all tags or me as author? Regards Frank
Re: [PATCH RESEND] crypto: caam - move shared symbols in a common location
On Thu, Jan 10, 2019 at 03:58:12PM +0200, Horia Geantă wrote: > There are several issues with symbols shared b/w: > -caam/jr and caam/qi drivers on one hand > -caam/qi2 driver on the other hand > > Commit 52813ab24959 ("crypto: caam/qi2 - avoid double export") fixed > some of them, however compilation still fails for CRYPTO_DEV_FSL_CAAM=m > and CRYPTO_DEV_FSL_DPAA2_CAAM=y. > > Another issue is related to dependency cycles reported by depmod when > CRYPTO_DEV_FSL_CAAM=n and CRYPTO_DEV_FSL_DPAA2_CAAM=m, as mentioned in > 82c7b351be3f ("Revert "arm64: defconfig: Enable FSL_MC_BUS and FSL_MC_DPIO"") > > To fix all these, move the symbols shared by these drivers in a common > location. The only existing possibility is error.c file (note that naming > doesn't help and should probably change). > > Fixes: 52813ab24959 ("crypto: caam/qi2 - avoid double export") > Reported-by: Arnd Bergmann > Signed-off-by: Horia Geantă > --- > > Resending to fix patchwork tracking. > Initial submission done inline here: > https://patchwork.kernel.org/patch/10739071/ > > drivers/crypto/caam/caamalg_qi2.c | 7 --- > drivers/crypto/caam/ctrl.c| 4 > drivers/crypto/caam/error.c | 6 ++ > 3 files changed, 6 insertions(+), 11 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 1/5] fs: kernfs: add poll file operation
On Thu, Jan 10, 2019 at 02:07:14PM -0800, Suren Baghdasaryan wrote: > From: Johannes Weiner > > Kernfs has a standardized poll/notification mechanism for waking all > pollers on all fds when a filesystem node changes. To allow polling > for custom events, add a .poll callback that can override the default. > > This is in preparation for pollable cgroup pressure files which have > per-fd trigger configurations. > > Signed-off-by: Johannes Weiner > Signed-off-by: Suren Baghdasaryan Reviewed-by: Greg Kroah-Hartman
Fwd: [PATCH 7/7] CIFS: Fix error paths in writeback code
These changes in writepage and writepages for cifs remind me of loosely related writeback changes that Jeff and Brian have done in the VFS/MM layer, so was hopeful that others might have comments if they see anything missing from Pavel's patch. -- Forwarded message - From: Pavel Shilovsky Date: Thu, Jan 10, 2019 at 4:25 PM Subject: [PATCH 7/7] CIFS: Fix error paths in writeback code To: Cc: Steve French , Ronnie Sahlberg This patch aims to address writeback code problems related to error paths. In particular it respects EINTR and related error codes and stores the first error occured during writeback in order to return it to a caller. Signed-off-by: Pavel Shilovsky --- fs/cifs/cifsglob.h | 19 +++ fs/cifs/cifssmb.c | 7 --- fs/cifs/file.c | 29 +++-- fs/cifs/inode.c| 10 ++ 4 files changed, 56 insertions(+), 9 deletions(-) diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h index 7709268..94dbdbe 100644 --- a/fs/cifs/cifsglob.h +++ b/fs/cifs/cifsglob.h @@ -1575,6 +1575,25 @@ static inline void free_dfs_info_array(struct dfs_info3_param *param, kfree(param); } +static inline bool is_interrupt_error(int error) +{ + switch (error) { + case -EINTR: + case -ERESTARTSYS: + case -ERESTARTNOHAND: + case -ERESTARTNOINTR: + return true; + } + return false; +} + +static inline bool is_retryable_error(int error) +{ + if (is_interrupt_error(error) || error == -EAGAIN) + return true; + return false; +} + #define MID_FREE 0 #define MID_REQUEST_ALLOCATED 1 #define MID_REQUEST_SUBMITTED 2 diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c index b1f49c1..6930cdb 100644 --- a/fs/cifs/cifssmb.c +++ b/fs/cifs/cifssmb.c @@ -2114,7 +2114,7 @@ cifs_writev_requeue(struct cifs_writedata *wdata) for (j = 0; j < nr_pages; j++) { unlock_page(wdata2->pages[j]); - if (rc != 0 && rc != -EAGAIN) { + if (rc != 0 && !is_retryable_error(rc)) { SetPageError(wdata2->pages[j]); end_page_writeback(wdata2->pages[j]); put_page(wdata2->pages[j]); @@ -2123,7 +2123,7 @@ cifs_writev_requeue(struct cifs_writedata *wdata) if (rc) { kref_put(&wdata2->refcount, cifs_writedata_release); - if (rc == -EAGAIN) + if (is_retryable_error(rc)) continue; break; } @@ -2132,7 +2132,8 @@ cifs_writev_requeue(struct cifs_writedata *wdata) i += nr_pages; } while (i < wdata->nr_pages); - mapping_set_error(inode->i_mapping, rc); + if (rc != 0 && !is_retryable_error(rc)) + mapping_set_error(inode->i_mapping, rc); kref_put(&wdata->refcount, cifs_writedata_release); } diff --git a/fs/cifs/file.c b/fs/cifs/file.c index c23bf9d..109b1ef 100644 --- a/fs/cifs/file.c +++ b/fs/cifs/file.c @@ -732,7 +732,8 @@ cifs_reopen_file(struct cifsFileInfo *cfile, bool can_flush) if (can_flush) { rc = filemap_write_and_wait(inode->i_mapping); - mapping_set_error(inode->i_mapping, rc); + if (!is_interrupt_error(rc)) + mapping_set_error(inode->i_mapping, rc); if (tcon->unix_ext) rc = cifs_get_inode_info_unix(&inode, full_path, @@ -2109,6 +2110,7 @@ static int cifs_writepages(struct address_space *mapping, pgoff_t end, index; struct cifs_writedata *wdata; int rc = 0; + int saved_rc = 0; unsigned int xid; /* @@ -2137,8 +2139,10 @@ static int cifs_writepages(struct address_space *mapping, rc = server->ops->wait_mtu_credits(server, cifs_sb->wsize, &wsize, &credits); - if (rc) + if (rc != 0) { + done = true; break; + } tofind = min((wsize / PAGE_SIZE) - 1, end - index) + 1; @@ -2146,6 +2150,7 @@ static int cifs_writepages(struct address_space *mapping, &found_pages); if (!wdata) { rc = -ENOMEM; + done = true; add_credits_and_wake_if(server, credits, 0); break; } @@ -2174,7 +2179,7 @@ static int cifs_writepages(struct address_space *mapping, if (rc != 0) { add_credits_and_wake_if(server, wdata->credits, 0); for (i = 0; i < nr_pages; ++i) { - if (rc == -EAGAIN) + if (is_retryable_error(rc))
Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()
On 2019-01-10 9:40 p.m., Greg Kroah-Hartman wrote: > Sorry, no, we do not keep symbols exported for no in-kernel users. > > greg k-h Hi Greg, Can you please address the email that Lukas was responding to? Thanks. signature.asc Description: OpenPGP digital signature
Re: [PATCH v5 2/6] media: sun6i: Add mod_rate quirk
On Mon, Jan 7, 2019 at 6:59 PM Maxime Ripard wrote: > > On Mon, Dec 24, 2018 at 08:57:48PM +0530, Jagan Teki wrote: > > On Fri, Dec 21, 2018 at 6:30 PM Maxime Ripard > > wrote: > > > > > > On Thu, Dec 20, 2018 at 06:24:34PM +0530, Jagan Teki wrote: > > > > Unfortunately default CSI_SCLK rate cannot work properly to > > > > drive the connected sensor interface, particularly on few > > > > Allwinner SoC's like A64. > > > > > > > > So, add mod_rate quirk via driver data so-that the respective > > > > SoC's which require to alter the default mod clock rate can assign > > > > the operating clock rate. > > > > > > > > Signed-off-by: Jagan Teki > > > > --- > > > > .../platform/sunxi/sun6i-csi/sun6i_csi.c | 34 +++ > > > > 1 file changed, 28 insertions(+), 6 deletions(-) > > > > > > > > diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c > > > > b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c > > > > index ee882b66a5ea..fe002beae09c 100644 > > > > --- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c > > > > +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c > > > > @@ -15,6 +15,7 @@ > > > > #include > > > > #include > > > > #include > > > > +#include > > > > #include > > > > #include > > > > #include > > > > @@ -28,8 +29,13 @@ > > > > > > > > #define MODULE_NAME "sun6i-csi" > > > > > > > > +struct sun6i_csi_variant { > > > > + unsigned long mod_rate; > > > > +}; > > > > + > > > > struct sun6i_csi_dev { > > > > struct sun6i_csicsi; > > > > + const struct sun6i_csi_variant *variant; > > > > struct device *dev; > > > > > > > > struct regmap *regmap; > > > > @@ -822,33 +828,43 @@ static int sun6i_csi_resource_request(struct > > > > sun6i_csi_dev *sdev, > > > > return PTR_ERR(sdev->clk_mod); > > > > } > > > > > > > > + if (sdev->variant->mod_rate) > > > > + clk_set_rate_exclusive(sdev->clk_mod, > > > > sdev->variant->mod_rate); > > > > + > > > > > > It still doesn't make any sense to do it in the probe function... > > > > I'm not sure we discussed about the context wrt probe, we discussed > > about exclusive put clock. > > https://lkml.org/lkml/2018/12/18/584 > > "Doing it here is not really optimal either, since you'll put a > constraint on the system (maintaining that clock at 300MHz), while > it's not in use." But this constraint is only set, for SoC's who need mod_rate change not for whole SoCs. > > > Since clocks were enabling in set_power and clock rate can be set > > during probe in single time instead of setting it in set_power for > > every power enablement. anything wrong with that. > > See above. > > Plus, a clock running draws power. It doesn't really make sense to > draw power for something that is unused. True, but clock is enabled only on sun6i_csi_set_power so setting clock frequency in probe will draw power? (sorry same message sent accidentally) > > > > We discussed this in the previous iteration already. > > > > > > What we didn't discuss is the variant function that you introduce, > > > while the previous approach was enough. > > > > We discussed about clk_rate_exclusive_put, and that even handle it in > > .remove right? so I have variant to handle it in sun6i_csi_remove. > > We indeed discussed the clk_rate_exclusive_put. However, you chose to > implement it using a variant structure which really isn't needed. Because clk_rate_exclusive_put will also do it .remove so adding driver variant with mod_rate can do this job easily. do you have any suggestion?
[PATCH V2 1/3] dt-bindings: fsl: add imx7ulp system integration module binding
Add i.MX7ULP system integration module (SIM) binding. Signed-off-by: Anson Huang --- .../bindings/arm/freescale/fsl,imx7ulp-sim.txt | 16 1 file changed, 16 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-sim.txt diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-sim.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-sim.txt new file mode 100644 index 000..7d0c7f0 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-sim.txt @@ -0,0 +1,16 @@ +Freescale i.MX7ULP System Integration Module +-- +The system integration module (SIM) provides system control and chip configuration +registers. In this module, chip revision information is located in JTAG ID register, +and a set of registers have been made available in DGO domain for SW use, with the +objective to maintain its value between system resets. + +Required properties: +- compatible: Should be "fsl,imx7ulp-sim". +- reg: Specifies base physical address and size of the register sets. + +Example: +sim: sim@410a3000 { + compatible = "fsl,imx7ulp-sim", "syscon"; + reg = <0x410a3000 0x1000>; +}; -- 2.7.4
[PATCH V2 2/3] ARM: imx: add i.MX7ULP SoC revision support
i.MX7ULP SoC's revision info is inside the SIM module, bit[31:28] of JTAG_ID register defines revision as below from B0: 0001B0 0010B1 This patch adds SoC revision support for i.MX7ULP, test result as below: root@imx7ulp-evk ~$ cat /sys/devices/soc0/revision 2.1 Signed-off-by: Anson Huang --- arch/arm/mach-imx/mach-imx7ulp.c | 39 +++ 1 file changed, 39 insertions(+) diff --git a/arch/arm/mach-imx/mach-imx7ulp.c b/arch/arm/mach-imx/mach-imx7ulp.c index 19c5b30..11ac71a 100644 --- a/arch/arm/mach-imx/mach-imx7ulp.c +++ b/arch/arm/mach-imx/mach-imx7ulp.c @@ -6,18 +6,57 @@ */ #include +#include #include +#include #include #include "common.h" #include "cpuidle.h" #include "hardware.h" +#define SIM_JTAG_ID_REG0x8c + +static void __init imx7ulp_set_revision(void) +{ + struct regmap *sim; + u32 revision; + + sim = syscon_regmap_lookup_by_compatible("fsl,imx7ulp-sim"); + if (IS_ERR(sim)) { + pr_warn("failed to find fsl,imx7ulp-sim regmap!\n"); + return; + } + + if (regmap_read(sim, SIM_JTAG_ID_REG, &revision)) { + pr_warn("failed to read sim regmap!\n"); + return; + } + + /* +* bit[31:28] of JTAG_ID register defines revision as below from B0: +* 0001B0 +* 0010B1 +*/ + switch (revision >> 28) { + case 1: + imx_set_soc_revision(IMX_CHIP_REVISION_2_0); + break; + case 2: + imx_set_soc_revision(IMX_CHIP_REVISION_2_1); + break; + default: + imx_set_soc_revision(IMX_CHIP_REVISION_1_0); + break; + } +} + static void __init imx7ulp_init_machine(void) { imx7ulp_pm_init(); mxc_set_cpu_type(MXC_CPU_IMX7ULP); + imx7ulp_set_revision(); of_platform_default_populate(NULL, NULL, imx_soc_device_init()); } -- 2.7.4
[PATCH V2 3/3] ARM: dts: imx7ulp: add sim node
i.MX7ULP SoC revision info is inside the SIM mode's JTAG_ID register, add sim node to support SoC revision check. Signed-off-by: Anson Huang --- arch/arm/boot/dts/imx7ulp.dtsi | 13 + 1 file changed, 13 insertions(+) diff --git a/arch/arm/boot/dts/imx7ulp.dtsi b/arch/arm/boot/dts/imx7ulp.dtsi index b86daf7..fca6e50 100644 --- a/arch/arm/boot/dts/imx7ulp.dtsi +++ b/arch/arm/boot/dts/imx7ulp.dtsi @@ -347,4 +347,17 @@ gpio-ranges = <&iomuxc1 0 96 32>; }; }; + + m4aips1: bus@4108 { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x4108 0x8>; + ranges; + + sim: sim@410a3000 { + compatible = "fsl,imx7ulp-sim", "syscon"; + reg = <0x410a3000 0x1000>; + }; + }; }; -- 2.7.4
Fwd: [PATCH 0/7] SMB3 credit flow control handling and writeback fixes
This is an important series, addressing various problems with crediting (flow control) but more importantly patches 4 and 7 deal with error cases in writeback, in writepages and writepage which may be of more general interest. Brian and Jeff have changed loosely related code in the VFS and may have insight into whether additional changes would be helpful beyond what Pavel has done in patches 4 and 7 in this series. -- Forwarded message - From: Pavel Shilovsky Date: Thu, Jan 10, 2019 at 4:25 PM Subject: [PATCH 0/7] SMB3 credit flow control handling and writeback fixes To: Cc: Steve French , Ronnie Sahlberg This is the series of patches that address few problems with the current code. Patch #1 adjusts credits properly for MTU credits if we didn't use all the credits taken for an operation. This prevents loosing credits in error paths. Patch #2 removes resetting credit number to 1 if server didn't grant us any credits for the compounding chain. The current code didn't follow the protocol correctly. Patch #3 fixes credits handling for compounded requests by taking one credit per part of the chain. All error paths that return credits back are fixed accordingly. Patch #4 fixes hiding EINTR error code returned after an interrupted attemp to send SMB packet through the network. Patch #5 removes wrong assumption that the server grants us one credit for a cancelled request and parse the actual response to get the credit number. Patch #6 moves process credits granted by the server in the demultiplex thread in order to avoid races with reconnects. Patch #7 addresses few problems in writeback code, in particular related to interrupted error code returned by the transport layer. Patches #1-4 as marked for stable. Reviews are welcome. Pavel Shilovsky (7): CIFS: Fix adjustment of credits for MTU requests CIFS: Do not set credits to 1 if the server didn't grant anything CIFS: Fix credit computation for compounded requests CIFS: Do not hide EINTR while sending network packets CIFS: Fix credits calculation for cancelled requests CIFS: Move credit processing to mid callbacks for SMB3 CIFS: Fix error paths in writeback code fs/cifs/cifsglob.h | 20 + fs/cifs/cifssmb.c | 7 +-- fs/cifs/file.c | 29 ++--- fs/cifs/inode.c | 10 + fs/cifs/smb2pdu.c | 8 +++- fs/cifs/transport.c | 122 +++- 6 files changed, 155 insertions(+), 41 deletions(-) -- 2.7.4 -- Thanks, Steve
Re: [PATCH 1/3] riscv: Introduce huge page support for 32/64bit kernel
Hello Alexandre, On Mon, 10 Dec 2018, Alexandre Ghiti wrote: > This patch implements both 4MB huge page support for 32bit kernel > and 2MB/1GB huge pages support for 64bit kernel. > > Signed-off-by: Alexandre Ghiti This patch introduces a few minor checkpatch and strict checkpatch warnings, when tested against both v4.20 and v5.0-rc1 checkpatch versions. Could you fix those? The other two patches in the series look OK from that point of view. - Paul
Re:[PATCH] 8250_pci.c: Only check for communication class in serial_pci_guess_board
On Thu, Jan 10, 2019 at 04:12:12PM +0800, Guan Yung Tseng wrote: > Some multiport serial cards, such as the NI PXI-8430/2, NI PXI-8430/8, > and NI PXI-8432/4 use PCI_CLASS_COMMUNICATION_OTHER and this fail the > serial_pci_is_class_communication test added in the commit 7d8905d06405 > ("serial: 8250_pci: Enable device after we check black list"). > > Since these devices are correctly listed in serial_pci_tbl, we > shouldn't need to check the PCI class IDs. This change relocates the > class checking solely into "serial_pci_guess_board" where it had been > before so that the class-check doesn't hinder initialization. > > Signed-off-by: Guan Yung Tseng > --- > drivers/tty/serial/8250/8250_pci.c | 28 +--- > 1 file changed, 9 insertions(+), 19 deletions(-) > > diff --git a/drivers/tty/serial/8250/8250_pci.c > b/drivers/tty/serial/8250/8250_pci.c > index 4986b4a..e33a869 100644 > --- a/drivers/tty/serial/8250/8250_pci.c > +++ b/drivers/tty/serial/8250/8250_pci.c > @@ -3382,21 +3382,6 @@ static const struct pci_device_id blacklist[] = { > { PCI_VDEVICE(COMMTECH, PCI_ANY_ID), }, > }; > > -static int serial_pci_is_class_communication(struct pci_dev *dev) > -{ > - /* > - * If it is not a communications device or the programming > - * interface is greater than 6, give up. > - */ > - if dev->class >> 8) != PCI_CLASS_COMMUNICATION_SERIAL) && > - ((dev->class >> 8) != PCI_CLASS_COMMUNICATION_MULTISERIAL) && > - ((dev->class >> 8) != PCI_CLASS_COMMUNICATION_MODEM)) || > - (dev->class & 0xff) > 6) > - return -ENODEV; > - > - return 0; > -} > > Noted. > Please leave this as a function, no need to move it inside another function at this point in time. > static int serial_pci_is_blacklisted(struct pci_dev *dev) > { > const struct pci_device_id *bldev; > @@ -3427,6 +3412,15 @@ serial_pci_guess_board(struct pci_dev *dev, struct > pciserial_board *board) > int num_iomem, num_port, first_port = -1, i; > > /* > + * If it is not a communications device or the programming > + * interface is greater than 6, give up. > + * > + */ > + if dev->class >> 8) != PCI_CLASS_COMMUNICATION_SERIAL) && > + ((dev->class >> 8) != PCI_CLASS_COMMUNICATION_MODEM)) || > + (dev->class & 0xff) > 6) > + return -ENODEV; > + /* > > It was my mistake. I should not remove it. > I will fix them and submit another patch. > what happened to the multiserial check? You should just call the function here. thanks, greg k-h
Fwd: scp bug due to progress indicator when copying from remote to local on Linux
-- Forwarded message - From: Steve French Date: Fri, Jan 11, 2019 at 12:11 AM Subject: scp bug due to progress indicator when copying from remote to local on Linux To: CIFS , linux-fsdevel Cc: CIFS , Pavel Shilovsky In discussing an interesting problem with scp recently with Pavel, we found a fairly obvious bug in scp when it is run with a progress indicator (which is the default when the source file is remote). scp triggers "SIGALRM" probably from update_progress_meter() in progressmeter.c when executed with "scp localhost:somelargefile /mnt" ie with an ssh source path but a local path for the target, as long as the flush of the large amount of cached data to disk (which seems to be triggered by the ftruncate call in scp.c) takes more than a few seconds (which can be common depending on disk or network speed). It is interesting that this can be avoided easily by running in quiet mode ("-q") which disables the progress meter in scp, but it seems very, very broken that scp of a large file can 'fail' when using a progress meter (unless caching were disabled on the file system) due to the slight delay in ftruncate due to triggering a flush of a large amount of cached data to disk sequentially. Any thoughts of whether scp is actively maintained and best approach to fix progressmeter.c so it doesn't break on Linux? -- Thanks, Steve -- Thanks, Steve
Re: [PATCHv2 1/7] x86/mm: concentrate the code to memblock allocator enabled
On Fri, Jan 11, 2019 at 01:12:51PM +0800, Pingfan Liu wrote: >This patch identifies the point where memblock alloc start. It has no >functional. [...] >+#ifdef CONFIG_MEMORY_HOTPLUG >+ /* >+ * Memory used by the kernel cannot be hot-removed because Linux >+ * cannot migrate the kernel pages. When memory hotplug is >+ * enabled, we should prevent memblock from allocating memory >+ * for the kernel. >+ * >+ * ACPI SRAT records all hotpluggable memory ranges. But before >+ * SRAT is parsed, we don't know about it. >+ * >+ * The kernel image is loaded into memory at very early time. We >+ * cannot prevent this anyway. So on NUMA system, we set any >+ * node the kernel resides in as un-hotpluggable. >+ * >+ * Since on modern servers, one node could have double-digit >+ * gigabytes memory, we can assume the memory around the kernel >+ * image is also un-hotpluggable. So before SRAT is parsed, just >+ * allocate memory near the kernel image to try the best to keep >+ * the kernel away from hotpluggable memory. >+ */ >+ if (movable_node_is_enabled()) >+ memblock_set_bottom_up(true); Hi Pingfan, In my understanding, 'movable_node' is based on the that memory near kernel is considered as in the same node as kernel in high possibility. If SRAT has been parsed early, do we still need the kernel parameter 'movable_node'? Since you have got the memory information about hot-remove, so I wonder if it's OK to drop 'movable_node', and if memory-hotremove is enabled, change memblock allocation according to SRAT. If there is something wrong in my understanding, please let me know. Thanks, Chao Fan >+#endif > init_mem_mapping(); >+ memblock_set_current_limit(get_max_mapped()); > > idt_setup_early_pf(); > >@@ -1145,8 +1145,6 @@ void __init setup_arch(char **cmdline_p) >*/ > mmu_cr4_features = __read_cr4() & ~X86_CR4_PCIDE; > >- memblock_set_current_limit(get_max_mapped()); >- > /* >* NOTE: On x86-32, only from this point on, fixmaps are ready for use. >*/ >-- >2.7.4 > > >
Re: linux-next: Signed-off-by missing for commit in the net tree
On 11.01.2019 04:48, Stephen Rothwell wrote: > Hi all, > > Commit > > b19bce0335e2 ("net: ethernet: mediatek: fix warning in phy_start_aneg") > > is missing a Signed-off-by from its author. > I suggested the changes and Frank prepared the patch with me as author. Therefore: Suggested-by: Heiner Kallweit Signed-off-by: Frank Wunderlich
Re: [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc_*
Hi Christoph, On 17/12/18 9:59 pm, Christoph Hellwig wrote: On Sat, Dec 15, 2018 at 12:14:29AM +1000, Greg Ungerer wrote: Yep, that is right. Certainly the MMU case is broken. Some noMMU cases work by virtue of the SoC only having an instruction cache (the older V2 cores). Is there a good an easy case to detect if a core has a cache? Either runtime or in Kconfig? The MMU case is fixable, but I think it will mean changing away from the fall-back virtual:physical 1:1 mapping it uses for the kernel address space. So not completely trivial. Either that or a dedicated area of RAM for coherent allocations that we can mark as non-cachable via the really course grained and limited ACR registers - not really very appealing. What about CF_PAGE_NOCACHE? Reading arch/m68k/include/asm/mcf_pgtable.h suggest this would cause an uncached mapping, in which case something like this should work: http://git.infradead.org/users/hch/misc.git/commitdiff/4b8711d436e8d56edbc5ca19aa2be639705bbfef No, that won't work. The current MMU setup for ColdFire relies on a quirk of the cache control subsystem to map kernel mapping (actually all of RAM when accessed in supervisor mode). The effective address calculation by the CPU/MMU firstly checks the RAMBAR access, then From the ColdFire 5475 Reference Manual (section 5.5.1): If virtual mode is enabled, any normal mode access that does not hit in the MMUBAR, RAMBARs, ROMBARs, or ACRs is considered a normal mode virtual address request and generates its access attributes from the MMU. For this case, the default CACR address attributes are not used. The MMUBAR is the MMU control registers, the RAMBAR/ROMBAR are the internal static RAM/ROM regions and the ACR are the cache control registers. The code in arch/m68k/coldfire/head.S sets up the ACR registers so that all of RAM is accessible and cached when in supervisor mode. So kernel code and data accesses will hit this and use the address for access. User pages won't hit this and will go through to hit the MMU mappings. The net out is we don't need page mappings or use TLB entries for kernel code/data. The problem is we also can't map individual regions as not cached for coherent allocations... The ACR mapping means all-or-nothing. This leads back to what I mentioned earlier about changing the VM mapping to not use the ACR mapping method and actually page mapping the kernel space. Not completely trivial and I expect there will be a performance hit with the extra TLB pressure and their setup/remapping overhead. The noMMU case in general is probably limited to something like that same type of dedicated RAM/ACR register mechamism. The most commonly used periperal with DMA is the FEC ethernet module, and it has some "special" (used very loosely) cache flushing for parts like the 532x family which probably makes it mostly work right. There is a PCI bus on the 54xx family of parts, and I know general ethernet cards on it (like e1000's) have problems I am sure are related to the fact that coherent memory allocations aren't. If we really just care about FEC we can just switch it do use DMA_ATTR_NON_CONSISTENT and do explicit cache flushing. But as far as I can tell FEC only uses DMA coherent allocations for the TSO headers anyway, is TSO even used on this SOC? The FEC is the most commonly used, but not the only. I test generic PCI NICs on the PCI bus on the ColdFire 5475 - and a lot of those drivers rely on coherent allocations. Regards Greg
Re: [PATCH 3/4] crypto: hisilicon: Add HiSilicon ZIP accelerator support
On Sat, Dec 22, 2018 at 03:51:44PM +0800, Zhou Wang wrote: > > +static struct crypto_alg hisi_zip_zlib = { > + .cra_name = "zlib-deflate", > + .cra_flags = CRYPTO_ALG_TYPE_COMPRESS, > + .cra_ctxsize= sizeof(struct hisi_zip_ctx), > + .cra_priority = 300, > + .cra_module = THIS_MODULE, > + .cra_init = hisi_zip_alloc_comp_ctx, > + .cra_exit = hisi_zip_free_comp_ctx, > + .cra_u = { > + .compress = { > + .coa_compress = hisi_zip_compress, > + .coa_decompress = hisi_zip_decompress > + } > + } > +}; Please do not add any new implementations using the compress interface. You should either use scomp or acomp depending on whether your driver is synchronous or async. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v11 10/15] tracing: Add alternative synthetic event trace action syntax
On Wed, Jan 09, 2019 at 01:49:17PM -0600, Tom Zanussi wrote: > From: Tom Zanussi > > Add a 'trace(synthetic_event_name, params)' alternative to > synthetic_event_name(params). > > Currently, the syntax used for generating synthetic events is to > invoke synthetic_event_name(params) i.e. use the synthetic event name > as a function call. > > Users requested a new form that more explicitly shows that the > synthetic event is in effect being traced. In this version, a new > 'trace()' keyword is used, and the synthetic event name is passed in > as the first argument. > > Signed-off-by: Tom Zanussi > --- > Documentation/trace/histogram.rst | 21 > kernel/trace/trace.c | 1 + > kernel/trace/trace_events_hist.c | 42 > +++ > 3 files changed, 60 insertions(+), 4 deletions(-) > > diff --git a/Documentation/trace/histogram.rst > b/Documentation/trace/histogram.rst > index 79476c906b1a..4939bad1c1cd 100644 > --- a/Documentation/trace/histogram.rst > +++ b/Documentation/trace/histogram.rst > @@ -1874,6 +1874,7 @@ The available handlers are: > The available actions are: > >- (param list) - generate synthetic event > + - trace(,(param list)) - generate synthetic event Shouldn't it be "trace(,param list)" ? Otherwise it looks like we need two parentheses. IMHO, it seems better for consistency using this new syntax only. Of course it should support the old syntax as well for compatibility (and maybe make it undocumented?). But I won't insist strongly.. >- save(field,...)- save current event fields >- snapshot() - snapshot the trace buffer > > @@ -1881,6 +1882,10 @@ The following commonly-used handler.action pairs are > available: > >- onmatch(matching.event).(param list) > > +or > + > + - onmatch(matching.event).trace(,(param list)) > + Ditto. > The 'onmatch(matching.event).(params)' hist > trigger action is invoked whenever an event matches and the > histogram entry would be added or updated. It causes the named > @@ -1889,6 +1894,16 @@ The following commonly-used handler.action pairs are > available: > that consists of the values contained in those variables at the > time the invoking event was hit. > > +There are two equivalent forms available for generating synthetic > +events. In the first form, the synthetic event name is used as if > +it were a function name. For example, if the synthetic event name > +is 'wakeup_latency', the wakeup_latency event would be generated > +by invoking it as if it were a function call, with the event field > +values passed in as arguments: wakeup_latency(arg1,arg2). The > +second form simply uses the 'trace' keyword as the function name > +and passes in the synthetic event name as the first argument, > +followed by the field values: trace(wakeup_latency,arg1,arg2). > + > The 'param list' consists of one or more parameters which may be > either variables or fields defined on either the 'matching.event' > or the target event. The variables or fields specified in the > @@ -1928,6 +1943,12 @@ The following commonly-used handler.action pairs are > available: >wakeup_new_test($testpid) if comm=="cyclictest"' >> \ >/sys/kernel/debug/tracing/events/sched/sched_wakeup_new/trigger > > +Or, equivalently, using the 'trace' keyword syntax: > + > +# echo 'hist:keys=$testpid:testpid=pid:onmatch(sched.sched_wakeup_new).\ > +trace(wakeup_new_test,$testpid) if comm=="cyclictest"' >> \ > +/sys/kernel/debug/tracing/events/sched/sched_wakeup_new/trigger > + > Creating and displaying a histogram based on those events is now > just a matter of using the fields and new synthetic event in the > tracing/events/synthetic directory, as usual:: > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c > index 917677a9bcaa..aae0e4127afc 100644 > --- a/kernel/trace/trace.c > +++ b/kernel/trace/trace.c > @@ -4900,6 +4900,7 @@ static const char readme_msg[] = > "\tonchange(var)- invoke action if var changes\n\n" > "\tThe available actions are:\n\n" > "\t(param list)- generate synthetic > event\n" > + "\ttrace(,(param list))- generate synthetic > event\n" Ditto. Thanks, Namhyung > "\tsave(field,...) - save current event > fields\n" > "\tsnapshot() - snapshot the trace > buffer\n" > #endif
Re: [PATCH v2] RISC-V: defconfig: Enable Generic PCIE by default
Hi Alistair, Looks like you're still sending patches to "palmpalmer" ? On Thu, 10 Jan 2019, Alistair Francis wrote: > Enable generic PCIe by default in the RISC-V defconfig, this allows us > to use QEMU's PCIe support out of the box. > > Signed-off-by: Alistair Francis > --- > arch/riscv/configs/defconfig | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig > index f399659d3b8d..ccfd3f05223c 100644 > --- a/arch/riscv/configs/defconfig > +++ b/arch/riscv/configs/defconfig > @@ -14,6 +14,8 @@ CONFIG_EXPERT=y > CONFIG_BPF_SYSCALL=y > CONFIG_SMP=y > CONFIG_PCI=y > +CONFIG_PCIEPORTBUS=y > +CONFIG_PCI_HOST_GENERIC=y > CONFIG_PCIE_XILINX=y > CONFIG_MODULES=y > CONFIG_MODULE_UNLOAD=y > @@ -77,5 +79,6 @@ CONFIG_NFS_V4_1=y > CONFIG_NFS_V4_2=y > CONFIG_ROOT_NFS=y > CONFIG_CRYPTO_USER_API_HASH=y > +CONFIG_CRYPTO_DEV_VIRTIO=y > CONFIG_PRINTK_TIME=y > # CONFIG_RCU_TRACE is not set Not sure what commit this patch is against - I picked v5.0-rc1. Before applying your patch, I generated a seedconfig with "make defconfig savedefconfig; mv defconfig defconfig.1". Then applied your patch and did a "make defconfig savedefconfig" and then ran "diff -u defconfig.1 defconfig". That should have shown me just the patch above. But it also included a line removing CONFIG_RAS=y. I am sorry to ask you to fix such a nitpicky item, but it is good practice for these defconfig patches. Otherwise the defconfig deltas gradually get out of control. When you repost it, if you verify that the ./defconfig delta from running "make savedefconfig" before and after your patch applied is simply your patch, then feel free to add a Reviewed-by: line from my E-mail address above. - Paul
Re: Kconfig label updates
Tyrel Datwyler writes: > On 01/09/2019 04:37 AM, Michael Ellerman wrote: >> Bjorn Helgaas writes: >>> I want to update the PCI Kconfig labels so they're more consistent and >>> useful to users, something like the patch below. IIUC, the items >>> below are all IBM-related; please correct me if not. >>> >>> I'd also like to expand (or remove) "RPA" because Google doesn't find >>> anything about "IBM RPA", except Robotic Process Automation, which I >>> think must be something else. >> >> Yeah I think just remove it, it's not a well known term and is unlikely >> to help anyone these days. >> >> It stands for "RISC Platform Architecture", which was some kind of >> specification for Power machines back in the day, but from what I can >> tell it was never used in marketing or manuals much (hence so few hits >> on Google). > > It is basically the predecessor to PAPR "Power Architecture Platform > Reference". > Which the LoPAPR document is available through power.org. Not sure if there is > any desire to adopt PAPR in place of RPA. It is the platform reference doc > that > outlines how we do DLPAR and PCI Hotplug. True. But a user is unlikely to know "PAPR" either, and it googles badly. LoPAPR I guess is better, you can google for it, though I'm not entirely sure if everything used by this code is actually in LoPAPR, because some bits of PAPR were ripped out of LoPAPR. >>> Ideally the PCI Kconfig labels would match the terms used in >>> arch/.../Kconfig, e.g., >>> >>> config PPC_POWERNV >>> bool "IBM PowerNV (Non-Virtualized) platform support" >>> >>> config PPC_PSERIES >>> bool "IBM pSeries & new (POWER5-based) iSeries" >> >> TBH these are pretty unhelpful too. PowerNV is not a marketing name and >> so doesn't appear anywhere much in official manuals or brochures and >> it's also used on non-IBM branded machines. And pSeries & iSeries were >> marketing names but are no longer used. > > pseries is still used as a machine type for PAPR compliant qemu/kvm instances. Yeah so I guess it's helpful for someone configuring a kernel with that in mind. But if you've bought an IBM branded system the "pseries" name is not used anywhere AFAIK. cheers
Re: [PATCH v5 2/6] media: sun6i: Add mod_rate quirk
On Mon, Jan 7, 2019 at 6:59 PM Maxime Ripard wrote: > > On Mon, Dec 24, 2018 at 08:57:48PM +0530, Jagan Teki wrote: > > On Fri, Dec 21, 2018 at 6:30 PM Maxime Ripard > > wrote: > > > > > > On Thu, Dec 20, 2018 at 06:24:34PM +0530, Jagan Teki wrote: > > > > Unfortunately default CSI_SCLK rate cannot work properly to > > > > drive the connected sensor interface, particularly on few > > > > Allwinner SoC's like A64. > > > > > > > > So, add mod_rate quirk via driver data so-that the respective > > > > SoC's which require to alter the default mod clock rate can assign > > > > the operating clock rate. > > > > > > > > Signed-off-by: Jagan Teki > > > > --- > > > > .../platform/sunxi/sun6i-csi/sun6i_csi.c | 34 +++ > > > > 1 file changed, 28 insertions(+), 6 deletions(-) > > > > > > > > diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c > > > > b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c > > > > index ee882b66a5ea..fe002beae09c 100644 > > > > --- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c > > > > +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c > > > > @@ -15,6 +15,7 @@ > > > > #include > > > > #include > > > > #include > > > > +#include > > > > #include > > > > #include > > > > #include > > > > @@ -28,8 +29,13 @@ > > > > > > > > #define MODULE_NAME "sun6i-csi" > > > > > > > > +struct sun6i_csi_variant { > > > > + unsigned long mod_rate; > > > > +}; > > > > + > > > > struct sun6i_csi_dev { > > > > struct sun6i_csicsi; > > > > + const struct sun6i_csi_variant *variant; > > > > struct device *dev; > > > > > > > > struct regmap *regmap; > > > > @@ -822,33 +828,43 @@ static int sun6i_csi_resource_request(struct > > > > sun6i_csi_dev *sdev, > > > > return PTR_ERR(sdev->clk_mod); > > > > } > > > > > > > > + if (sdev->variant->mod_rate) > > > > + clk_set_rate_exclusive(sdev->clk_mod, > > > > sdev->variant->mod_rate); > > > > + > > > > > > It still doesn't make any sense to do it in the probe function... > > > > I'm not sure we discussed about the context wrt probe, we discussed > > about exclusive put clock. > > https://lkml.org/lkml/2018/12/18/584 > > "Doing it here is not really optimal either, since you'll put a > constraint on the system (maintaining that clock at 300MHz), while > it's not in use." > > > Since clocks were enabling in set_power and clock rate can be set > > during probe in single time instead of setting it in set_power for > > every power enablement. anything wrong with that. > > See above. > > Plus, a clock running draws power. It doesn't really make sense to > draw power for something that is unused. True, but clock is enabled only on sun6i_csi_set_power so setting clock frequency in probe will draw power?
[PATCH] usb: dwc3: gadget: Fail request submission if it was already queued
If a function driver tries to re-submit an already queued request, it can results in corruption of pending/started request lists. Catch such conditions and fail the request submission to DCD. Signed-off-by: Manu Gautam --- drivers/usb/dwc3/gadget.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 679c12e14522..51716c6b286a 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -1290,6 +1290,12 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request *req) &req->request, req->dep->name)) return -EINVAL; + if (req->request.status == -EINPROGRESS) { + dev_err(dwc->dev, "%s: %pK request already in queue\n", + dep->name, req); + return -EBUSY; + } + pm_runtime_get(dwc->dev); req->request.actual = 0; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH V2] ARM: imx: add i.MX7ULP cpuidle support
This patch adds cpuidle support for i.MX7ULP, 3 cpuidle states supported as below: 1. WFI, just ARM wfi; 2. WAIT mode, mapped to SoC's partial stop mode #3; 3. STOP mode, mapped to SoC's partial stop mode #1. In WAIT mode, system clock and bus clock will be enabled; In STOP mode, system clock and bus clock will be disabled. Signed-off-by: Anson Huang --- ChangeLog Since V1: - add prefix for power mode name; - use tab instead of spaces, sorry for this stupid mistake. --- arch/arm/mach-imx/Makefile | 1 + arch/arm/mach-imx/common.h | 10 +++ arch/arm/mach-imx/cpuidle-imx7ulp.c | 60 + arch/arm/mach-imx/cpuidle.h | 5 arch/arm/mach-imx/mach-imx7ulp.c| 7 + arch/arm/mach-imx/pm-imx7ulp.c | 49 ++ 6 files changed, 127 insertions(+), 5 deletions(-) create mode 100644 arch/arm/mach-imx/cpuidle-imx7ulp.c diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile index 8af2f7e..12aa44a 100644 --- a/arch/arm/mach-imx/Makefile +++ b/arch/arm/mach-imx/Makefile @@ -29,6 +29,7 @@ obj-$(CONFIG_SOC_IMX6SL) += cpuidle-imx6sl.o obj-$(CONFIG_SOC_IMX6SLL) += cpuidle-imx6sx.o obj-$(CONFIG_SOC_IMX6SX) += cpuidle-imx6sx.o obj-$(CONFIG_SOC_IMX6UL) += cpuidle-imx6sx.o +obj-$(CONFIG_SOC_IMX7ULP) += cpuidle-imx7ulp.o endif ifdef CONFIG_SND_IMX_SOC diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h index bc915e5..c51764a 100644 --- a/arch/arm/mach-imx/common.h +++ b/arch/arm/mach-imx/common.h @@ -72,6 +72,15 @@ enum mxc_cpu_pwr_mode { STOP_POWER_OFF, /* STOP + SRPG */ }; +enum ulp_cpu_pwr_mode { + ULP_PM_HSRUN,/* High speed run mode */ + ULP_PM_RUN, /* Run mode */ + ULP_PM_WAIT, /* Wait mode */ + ULP_PM_STOP, /* Stop mode */ + ULP_PM_VLPS, /* Very low power stop mode */ + ULP_PM_VLLS, /* very low leakage stop mode */ +}; + void imx_enable_cpu(int cpu, bool enable); void imx_set_cpu_jump(int cpu, void *jump_addr); u32 imx_get_cpu_arg(int cpu); @@ -98,6 +107,7 @@ int imx6_set_lpm(enum mxc_cpu_pwr_mode mode); void imx6_set_int_mem_clk_lpm(bool enable); void imx6sl_set_wait_clk(bool enter); int imx_mmdc_get_ddr_type(void); +int imx7ulp_set_lpm(enum ulp_cpu_pwr_mode mode); void imx_cpu_die(unsigned int cpu); int imx_cpu_kill(unsigned int cpu); diff --git a/arch/arm/mach-imx/cpuidle-imx7ulp.c b/arch/arm/mach-imx/cpuidle-imx7ulp.c new file mode 100644 index 000..ca86c96 --- /dev/null +++ b/arch/arm/mach-imx/cpuidle-imx7ulp.c @@ -0,0 +1,60 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2016 Freescale Semiconductor, Inc. + * Copyright 2017-2018 NXP + * Anson Huang + */ + +#include +#include +#include + +#include "common.h" +#include "cpuidle.h" + +static int imx7ulp_enter_wait(struct cpuidle_device *dev, + struct cpuidle_driver *drv, int index) +{ + if (index == 1) + imx7ulp_set_lpm(ULP_PM_WAIT); + else + imx7ulp_set_lpm(ULP_PM_STOP); + + cpu_do_idle(); + + imx7ulp_set_lpm(ULP_PM_RUN); + + return index; +} + +static struct cpuidle_driver imx7ulp_cpuidle_driver = { + .name = "imx7ulp_cpuidle", + .owner = THIS_MODULE, + .states = { + /* WFI */ + ARM_CPUIDLE_WFI_STATE, + /* WAIT */ + { + .exit_latency = 50, + .target_residency = 75, + .enter = imx7ulp_enter_wait, + .name = "WAIT", + .desc = "PSTOP2", + }, + /* STOP */ + { + .exit_latency = 100, + .target_residency = 150, + .enter = imx7ulp_enter_wait, + .name = "STOP", + .desc = "PSTOP1", + }, + }, + .state_count = 3, + .safe_state_index = 0, +}; + +int __init imx7ulp_cpuidle_init(void) +{ + return cpuidle_register(&imx7ulp_cpuidle_driver, NULL); +} diff --git a/arch/arm/mach-imx/cpuidle.h b/arch/arm/mach-imx/cpuidle.h index f914012..7694c8f 100644 --- a/arch/arm/mach-imx/cpuidle.h +++ b/arch/arm/mach-imx/cpuidle.h @@ -15,6 +15,7 @@ extern int imx5_cpuidle_init(void); extern int imx6q_cpuidle_init(void); extern int imx6sl_cpuidle_init(void); extern int imx6sx_cpuidle_init(void); +extern int imx7ulp_cpuidle_init(void); #else static inline int imx5_cpuidle_init(void) { @@ -32,4 +33,8 @@ static inline int imx6sx_cpuidle_init(void) { return 0; } +static inline int imx7ulp_cpuidle_init(void) +{ + return 0; +} #endif diff --git a/arch/arm/mach-imx/mach-imx7ulp.c b/arch/arm/mach-imx/mach-imx7ulp.c index 16b295b..11ac71a 100644 --- a/arch/arm/mach-imx/mach-imx7ulp.c +++ b/arch/arm/mach-imx/mach-imx7ulp.c @@ -12,6 +12,7 @@ #include #include "common.h" +#i
[PATCH v2] tracing/kprobes: fix NULL pointer dereference in trace_kprobe_create()
It is possible to trigger a NULL pointer dereference by writing an incorrectly formatted string to krpobe_events (trying to create a kretprobe omitting the symbol). Example: echo "r:event_1 " >> /sys/kernel/debug/tracing/kprobe_events That triggers this: BUG: unable to handle kernel NULL pointer dereference at #PF error: [normal kernel read fault] PGD 0 P4D 0 Oops: [#1] SMP PTI CPU: 6 PID: 1757 Comm: bash Not tainted 5.0.0-rc1+ #125 Hardware name: Dell Inc. XPS 13 9370/0F6P3V, BIOS 1.5.1 08/09/2018 RIP: 0010:kstrtoull+0x2/0x20 Code: 28 00 00 00 75 17 48 83 c4 18 5b 41 5c 5d c3 b8 ea ff ff ff eb e1 b8 de ff ff ff eb da e8 d6 36 bb ff 66 0f 1f 44 00 00 31 c0 <80> 3f 2b 55 48 89 e5 0f 94 c0 48 01 c7 e8 5c ff ff ff 5d c3 66 2e RSP: 0018:b5d482e57cb8 EFLAGS: 00010246 RAX: RBX: 0001 RCX: 82b12720 RDX: b5d482e57cf8 RSI: RDI: RBP: b5d482e57d70 R08: a0c05e5a7080 R09: a0c05e003980 R10: R11: 4000 R12: a0c04fe87b08 R13: 0001 R14: 000b R15: a0c058d749e1 FS: 7f137c7f7740() GS:a0c05e58() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 000497d46004 CR4: 003606e0 Call Trace: ? trace_kprobe_create+0xb6/0x840 ? _cond_resched+0x19/0x40 ? _cond_resched+0x19/0x40 ? __kmalloc+0x62/0x210 ? argv_split+0x8f/0x140 ? trace_kprobe_create+0x840/0x840 ? trace_kprobe_create+0x840/0x840 create_or_delete_trace_kprobe+0x11/0x30 trace_run_command+0x50/0x90 trace_parse_run_command+0xc1/0x160 probes_write+0x10/0x20 __vfs_write+0x3a/0x1b0 ? apparmor_file_permission+0x1a/0x20 ? security_file_permission+0x31/0xf0 ? _cond_resched+0x19/0x40 vfs_write+0xb1/0x1a0 ksys_write+0x55/0xc0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x5a/0x120 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix by doing the proper argument checks in trace_kprobe_create(). Link: https://lore.kernel.org/lkml/20190111095108.b79a2ee026185cbd62365...@kernel.org Fixes: 6212dd29683e ("tracing/kprobes: Use dyn_event framework for kprobe events") Cc: sta...@vger.kernel.org Signed-off-by: Andrea Righi Signed-off-by: Masami Hiramatsu --- v2: argument check refactoring kernel/trace/trace_kprobe.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c index 5c19b8c41c7e..d5fb09ebba8b 100644 --- a/kernel/trace/trace_kprobe.c +++ b/kernel/trace/trace_kprobe.c @@ -607,11 +607,17 @@ static int trace_kprobe_create(int argc, const char *argv[]) char buf[MAX_EVENT_NAME_LEN]; unsigned int flags = TPARG_FL_KERNEL; - /* argc must be >= 1 */ - if (argv[0][0] == 'r') { + switch (argv[0][0]) { + case 'r': is_return = true; flags |= TPARG_FL_RETURN; - } else if (argv[0][0] != 'p' || argc < 2) + break; + case 'p': + break; + default: + return -ECANCELED; + } + if (argc < 2) return -ECANCELED; event = strchr(&argv[0][1], ':'); -- 2.17.1
Re: [PATCH v3 0/2] Add Stratix 10 PCIe Root Port support
On Wed, 2019-01-02 at 14:16 +0800, Ley Foon Tan wrote: > Add PCIe Root Port support for Stratix 10 device and also update > device tree binding documentation. > > v2 -> v3: > - > - Rename Stratix10 to Stratix 10. > - Change bool s10_flag to enum version. > > v1 -> v2: > - > - Add define S10_TLP_FMTTYPE_* macros. > - Remove initialize structure members to NULL/zero. > - Rename *_funcs to *_data. > - Update comment and fix coding style warning from checkpatch.pl. > - Rename StratixXX to stratix10. > > History: > > [v1]: https://lkml.org/lkml/2018/12/26/68 > [v2]: https://lkml.org/lkml/2018/12/31/46 > > Ley Foon Tan (2): > PCI: altera: Add Stratix 10 PCIe support > dt-bindings: PCI: altera: Add altr,pcie-root-port-2.0 > > .../devicetree/bindings/pci/altera-pcie.txt|4 +- > drivers/pci/controller/Kconfig |2 +- > drivers/pci/controller/pcie-altera.c | 246 > ++-- > 3 files changed, 226 insertions(+), 26 deletions(-) > Hi, Any further comment on these patches? Regards Ley Foon
Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()
On Fri, Jan 11, 2019 at 06:04:07AM +0100, Lukas Wunner wrote: > On Thu, Jan 10, 2019 at 07:24:13PM +0100, Greg Kroah-Hartman wrote: > > My tolerance for ZFS is pretty non-existant. Sun explicitly did not > > want their code to work on Linux, so why would we do extra work to get > > their code to work properly? > > ZoL facilitates seamless r/w cross-mounting with macOS, something no > other filesystem allows, and that feature is critical for me to work > on Linux drivers for Mac hardware. Please don't make life harder than > necessary for developers like me. Your "extra work" argument seems > disingenuous to me, Sebastian's patch is causing extra work for > ZFS developers, not the kernel community. The maintenance burden > for the kernel community to retain the export is zero. Sorry, no, we do not keep symbols exported for no in-kernel users. greg k-h
Re: [RFT][PATCH v2] gpiolib: acpi: Introduce ACPI_GPIO_QUIRK_ONLY_GPIOIO
On Wed, Jan 09, 2019 at 12:52:45PM +0200, Andy Shevchenko wrote: > New quirk enforces search for GPIO based on its type, > i.e. iterate over GpioIo resources only. > > Signed-off-by: Andy Shevchenko Acked-by: Mika Westerberg
[PATCH v4 03/16] drm/bochs: atomic: add atomic_flush+atomic_enable callbacks.
Conversion to atomic modesetting, step one. Add atomic crtc helper callbacks. Signed-off-by: Gerd Hoffmann Acked-by: Daniel Vetter --- drivers/gpu/drm/bochs/bochs_kms.c | 25 + 1 file changed, 25 insertions(+) diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c index f7e6d1a9b3..2cbd406b1f 100644 --- a/drivers/gpu/drm/bochs/bochs_kms.c +++ b/drivers/gpu/drm/bochs/bochs_kms.c @@ -115,6 +115,29 @@ static int bochs_crtc_page_flip(struct drm_crtc *crtc, return 0; } +static void bochs_crtc_atomic_enable(struct drm_crtc *crtc, +struct drm_crtc_state *old_crtc_state) +{ +} + +static void bochs_crtc_atomic_flush(struct drm_crtc *crtc, + struct drm_crtc_state *old_crtc_state) +{ + struct drm_device *dev = crtc->dev; + struct drm_pending_vblank_event *event; + + if (crtc->state && crtc->state->event) { + unsigned long irqflags; + + spin_lock_irqsave(&dev->event_lock, irqflags); + event = crtc->state->event; + crtc->state->event = NULL; + drm_crtc_send_vblank_event(crtc, event); + spin_unlock_irqrestore(&dev->event_lock, irqflags); + } +} + + /* These provide the minimum set of functions required to handle a CRTC */ static const struct drm_crtc_funcs bochs_crtc_funcs = { .set_config = drm_crtc_helper_set_config, @@ -128,6 +151,8 @@ static const struct drm_crtc_helper_funcs bochs_helper_funcs = { .mode_set_base = bochs_crtc_mode_set_base, .prepare = bochs_crtc_prepare, .commit = bochs_crtc_commit, + .atomic_enable = bochs_crtc_atomic_enable, + .atomic_flush = bochs_crtc_atomic_flush, }; static const uint32_t bochs_formats[] = { -- 2.9.3
[PATCH v4 06/16] drm/bochs: atomic: use atomic set_config helper
Conversion to atomic modesetting, step four. Use atomic set_config helper for crtc. Signed-off-by: Gerd Hoffmann Reviewed-by: Oleksandr Andrushchenko Acked-by: Daniel Vetter --- drivers/gpu/drm/bochs/bochs_kms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c index c6993c2d59..646f897cb2 100644 --- a/drivers/gpu/drm/bochs/bochs_kms.c +++ b/drivers/gpu/drm/bochs/bochs_kms.c @@ -150,7 +150,7 @@ static void bochs_crtc_atomic_flush(struct drm_crtc *crtc, /* These provide the minimum set of functions required to handle a CRTC */ static const struct drm_crtc_funcs bochs_crtc_funcs = { - .set_config = drm_crtc_helper_set_config, + .set_config = drm_atomic_helper_set_config, .destroy = drm_crtc_cleanup, .page_flip = bochs_crtc_page_flip, .reset = drm_atomic_helper_crtc_reset, -- 2.9.3
[PATCH v4 01/16] drm/bochs: encoder cleanup
Most unused callbacks can be NULL pointers these days. Drop a bunch of empty encoder callbacks. Signed-off-by: Gerd Hoffmann Reviewed-by: Oleksandr Andrushchenko Acked-by: Daniel Vetter --- drivers/gpu/drm/bochs/bochs_kms.c | 26 -- 1 file changed, 26 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c index f87c284dd9..c8ce54498d 100644 --- a/drivers/gpu/drm/bochs/bochs_kms.c +++ b/drivers/gpu/drm/bochs/bochs_kms.c @@ -170,31 +170,6 @@ static void bochs_crtc_init(struct drm_device *dev) drm_crtc_helper_add(crtc, &bochs_helper_funcs); } -static void bochs_encoder_mode_set(struct drm_encoder *encoder, - struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode) -{ -} - -static void bochs_encoder_dpms(struct drm_encoder *encoder, int state) -{ -} - -static void bochs_encoder_prepare(struct drm_encoder *encoder) -{ -} - -static void bochs_encoder_commit(struct drm_encoder *encoder) -{ -} - -static const struct drm_encoder_helper_funcs bochs_encoder_helper_funcs = { - .dpms = bochs_encoder_dpms, - .mode_set = bochs_encoder_mode_set, - .prepare = bochs_encoder_prepare, - .commit = bochs_encoder_commit, -}; - static const struct drm_encoder_funcs bochs_encoder_encoder_funcs = { .destroy = drm_encoder_cleanup, }; @@ -207,7 +182,6 @@ static void bochs_encoder_init(struct drm_device *dev) encoder->possible_crtcs = 0x1; drm_encoder_init(dev, encoder, &bochs_encoder_encoder_funcs, DRM_MODE_ENCODER_DAC, NULL); - drm_encoder_helper_add(encoder, &bochs_encoder_helper_funcs); } -- 2.9.3
[PATCH v4 16/16] drm/bochs: move remaining fb bits to kms
bochs_fbdev.c is almost empty now. Move the remaining framebuffer bits over to bochs_kms.c. Pure code motion. No functional change. Signed-off-by: Gerd Hoffmann Reviewed-by: Oleksandr Andrushchenko Acked-by: Daniel Vetter --- drivers/gpu/drm/bochs/bochs_fbdev.c | 29 - drivers/gpu/drm/bochs/bochs_kms.c | 17 + drivers/gpu/drm/bochs/Makefile | 2 +- 3 files changed, 18 insertions(+), 30 deletions(-) delete mode 100644 drivers/gpu/drm/bochs/bochs_fbdev.c diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c b/drivers/gpu/drm/bochs/bochs_fbdev.c deleted file mode 100644 index 7cac3f5253..00 --- a/drivers/gpu/drm/bochs/bochs_fbdev.c +++ /dev/null @@ -1,29 +0,0 @@ -/* - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - */ - -#include "bochs.h" -#include -#include - -/* -- */ - -static struct drm_framebuffer * -bochs_gem_fb_create(struct drm_device *dev, struct drm_file *file, - const struct drm_mode_fb_cmd2 *mode_cmd) -{ - if (mode_cmd->pixel_format != DRM_FORMAT_XRGB && - mode_cmd->pixel_format != DRM_FORMAT_BGRX) - return ERR_PTR(-EINVAL); - - return drm_gem_fb_create(dev, file, mode_cmd); -} - -const struct drm_mode_config_funcs bochs_mode_funcs = { - .fb_create = bochs_gem_fb_create, - .atomic_check = drm_atomic_helper_check, - .atomic_commit = drm_atomic_helper_commit, -}; diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c index fc856a02a2..e9d5dbc346 100644 --- a/drivers/gpu/drm/bochs/bochs_kms.c +++ b/drivers/gpu/drm/bochs/bochs_kms.c @@ -9,6 +9,7 @@ #include #include #include +#include static int defx = 1024; static int defy = 768; @@ -256,6 +257,22 @@ static void bochs_connector_init(struct drm_device *dev) } } +static struct drm_framebuffer * +bochs_gem_fb_create(struct drm_device *dev, struct drm_file *file, + const struct drm_mode_fb_cmd2 *mode_cmd) +{ + if (mode_cmd->pixel_format != DRM_FORMAT_XRGB && + mode_cmd->pixel_format != DRM_FORMAT_BGRX) + return ERR_PTR(-EINVAL); + + return drm_gem_fb_create(dev, file, mode_cmd); +} + +const struct drm_mode_config_funcs bochs_mode_funcs = { + .fb_create = bochs_gem_fb_create, + .atomic_check = drm_atomic_helper_check, + .atomic_commit = drm_atomic_helper_commit, +}; int bochs_kms_init(struct bochs_device *bochs) { diff --git a/drivers/gpu/drm/bochs/Makefile b/drivers/gpu/drm/bochs/Makefile index 98ef60a19e..e9e0f8f5eb 100644 --- a/drivers/gpu/drm/bochs/Makefile +++ b/drivers/gpu/drm/bochs/Makefile @@ -1,3 +1,3 @@ -bochs-drm-y := bochs_drv.o bochs_mm.o bochs_kms.o bochs_fbdev.o bochs_hw.o +bochs-drm-y := bochs_drv.o bochs_mm.o bochs_kms.o bochs_hw.o obj-$(CONFIG_DRM_BOCHS)+= bochs-drm.o -- 2.9.3
[PATCH v4 12/16] drm/bochs: move ttm_bo_(un)reserve calls into bochs_bo_{pin,unpin}
Signed-off-by: Gerd Hoffmann Acked-by: Daniel Vetter --- drivers/gpu/drm/bochs/bochs_fbdev.c | 8 drivers/gpu/drm/bochs/bochs_kms.c | 14 +- drivers/gpu/drm/bochs/bochs_mm.c| 8 3 files changed, 9 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c b/drivers/gpu/drm/bochs/bochs_fbdev.c index 92feb817ff..ccf783b038 100644 --- a/drivers/gpu/drm/bochs/bochs_fbdev.c +++ b/drivers/gpu/drm/bochs/bochs_fbdev.c @@ -77,14 +77,9 @@ static int bochsfb_create(struct drm_fb_helper *helper, bo = gem_to_bochs_bo(gobj); - ret = ttm_bo_reserve(&bo->bo, true, false, NULL); - if (ret) - return ret; - ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM); if (ret) { DRM_ERROR("failed to pin fbcon\n"); - ttm_bo_unreserve(&bo->bo); return ret; } @@ -92,12 +87,9 @@ static int bochsfb_create(struct drm_fb_helper *helper, &bo->kmap); if (ret) { DRM_ERROR("failed to kmap fbcon\n"); - ttm_bo_unreserve(&bo->bo); return ret; } - ttm_bo_unreserve(&bo->bo); - /* init fb device */ info = drm_fb_helper_alloc_fbi(helper); if (IS_ERR(info)) { diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c index f663c54185..fc856a02a2 100644 --- a/drivers/gpu/drm/bochs/bochs_kms.c +++ b/drivers/gpu/drm/bochs/bochs_kms.c @@ -92,34 +92,22 @@ static int bochs_plane_prepare_fb(struct drm_plane *plane, struct drm_plane_state *new_state) { struct bochs_bo *bo; - int ret; if (!new_state->fb) return 0; bo = gem_to_bochs_bo(new_state->fb->obj[0]); - - ret = ttm_bo_reserve(&bo->bo, true, false, NULL); - if (ret) - return ret; - ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM); - ttm_bo_unreserve(&bo->bo); - return ret; + return bochs_bo_pin(bo, TTM_PL_FLAG_VRAM); } static void bochs_plane_cleanup_fb(struct drm_plane *plane, struct drm_plane_state *old_state) { struct bochs_bo *bo; - int ret; if (!old_state->fb) return; bo = gem_to_bochs_bo(old_state->fb->obj[0]); - ret = ttm_bo_reserve(&bo->bo, true, false, NULL); - if (ret) - return; bochs_bo_unpin(bo); - ttm_bo_unreserve(&bo->bo); } static const struct drm_plane_helper_funcs bochs_plane_helper_funcs = { diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c index 5a0e092847..fcbf35456d 100644 --- a/drivers/gpu/drm/bochs/bochs_mm.c +++ b/drivers/gpu/drm/bochs/bochs_mm.c @@ -223,7 +223,11 @@ int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag) bochs_ttm_placement(bo, pl_flag); for (i = 0; i < bo->placement.num_placement; i++) bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT; + ret = ttm_bo_reserve(&bo->bo, true, false, NULL); + if (ret) + return ret; ret = ttm_bo_validate(&bo->bo, &bo->placement, &ctx); + ttm_bo_unreserve(&bo->bo); if (ret) return ret; @@ -247,7 +251,11 @@ int bochs_bo_unpin(struct bochs_bo *bo) for (i = 0; i < bo->placement.num_placement; i++) bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT; + ret = ttm_bo_reserve(&bo->bo, true, false, NULL); + if (ret) + return ret; ret = ttm_bo_validate(&bo->bo, &bo->placement, &ctx); + ttm_bo_unreserve(&bo->bo); if (ret) return ret; -- 2.9.3
[PATCH v4 14/16] drm/bochs: switch to generic drm fbdev emulation
Signed-off-by: Gerd Hoffmann Acked-by: Daniel Vetter --- drivers/gpu/drm/bochs/bochs_drv.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs_drv.c b/drivers/gpu/drm/bochs/bochs_drv.c index a3f4e21078..cea42ac64d 100644 --- a/drivers/gpu/drm/bochs/bochs_drv.c +++ b/drivers/gpu/drm/bochs/bochs_drv.c @@ -16,10 +16,6 @@ static int bochs_modeset = -1; module_param_named(modeset, bochs_modeset, int, 0444); MODULE_PARM_DESC(modeset, "enable/disable kernel modesetting"); -static bool enable_fbdev = true; -module_param_named(fbdev, enable_fbdev, bool, 0444); -MODULE_PARM_DESC(fbdev, "register fbdev device"); - /* -- */ /* drm interface */ @@ -27,7 +23,6 @@ static void bochs_unload(struct drm_device *dev) { struct bochs_device *bochs = dev->dev_private; - bochs_fbdev_fini(bochs); bochs_kms_fini(bochs); bochs_mm_fini(bochs); bochs_hw_fini(dev); @@ -58,9 +53,6 @@ static int bochs_load(struct drm_device *dev) if (ret) goto err; - if (enable_fbdev) - bochs_fbdev_init(bochs); - return 0; err: @@ -110,9 +102,7 @@ static int bochs_pm_suspend(struct device *dev) { struct pci_dev *pdev = to_pci_dev(dev); struct drm_device *drm_dev = pci_get_drvdata(pdev); - struct bochs_device *bochs = drm_dev->dev_private; - drm_fb_helper_set_suspend_unlocked(&bochs->fb.helper, 1); return drm_mode_config_helper_suspend(drm_dev); } @@ -120,9 +110,7 @@ static int bochs_pm_resume(struct device *dev) { struct pci_dev *pdev = to_pci_dev(dev); struct drm_device *drm_dev = pci_get_drvdata(pdev); - struct bochs_device *bochs = drm_dev->dev_private; - drm_fb_helper_set_suspend_unlocked(&bochs->fb.helper, 0); return drm_mode_config_helper_resume(drm_dev); } #endif @@ -167,6 +155,7 @@ static int bochs_pci_probe(struct pci_dev *pdev, if (ret) goto err_unload; + drm_fbdev_generic_setup(dev, 32); return ret; err_unload: -- 2.9.3
[PATCH v4 04/16] drm/bochs: atomic: add mode_set_nofb callback.
Conversion to atomic modesetting, step two. Add mode_set_nofb crtc helper callback. Signed-off-by: Gerd Hoffmann Reviewed-by: Oleksandr Andrushchenko Acked-by: Daniel Vetter --- drivers/gpu/drm/bochs/bochs_kms.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c index 2cbd406b1f..56fd7be933 100644 --- a/drivers/gpu/drm/bochs/bochs_kms.c +++ b/drivers/gpu/drm/bochs/bochs_kms.c @@ -86,6 +86,14 @@ static int bochs_crtc_mode_set(struct drm_crtc *crtc, return 0; } +static void bochs_crtc_mode_set_nofb(struct drm_crtc *crtc) +{ + struct bochs_device *bochs = + container_of(crtc, struct bochs_device, crtc); + + bochs_hw_setmode(bochs, &crtc->mode); +} + static void bochs_crtc_prepare(struct drm_crtc *crtc) { } @@ -149,6 +157,7 @@ static const struct drm_crtc_helper_funcs bochs_helper_funcs = { .dpms = bochs_crtc_dpms, .mode_set = bochs_crtc_mode_set, .mode_set_base = bochs_crtc_mode_set_base, + .mode_set_nofb = bochs_crtc_mode_set_nofb, .prepare = bochs_crtc_prepare, .commit = bochs_crtc_commit, .atomic_enable = bochs_crtc_atomic_enable, -- 2.9.3
[PATCH v4 08/16] drm/bochs: atomic: use suspend/resume helpers
Switch to atomic helpers: drm_mode_config_helper_suspend/resume(). Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/bochs/bochs_drv.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs_drv.c b/drivers/gpu/drm/bochs/bochs_drv.c index f3dd66ae99..08ba6029d2 100644 --- a/drivers/gpu/drm/bochs/bochs_drv.c +++ b/drivers/gpu/drm/bochs/bochs_drv.c @@ -103,11 +103,8 @@ static int bochs_pm_suspend(struct device *dev) struct drm_device *drm_dev = pci_get_drvdata(pdev); struct bochs_device *bochs = drm_dev->dev_private; - drm_kms_helper_poll_disable(drm_dev); - drm_fb_helper_set_suspend_unlocked(&bochs->fb.helper, 1); - - return 0; + return drm_mode_config_helper_suspend(drm_dev); } static int bochs_pm_resume(struct device *dev) @@ -116,12 +113,8 @@ static int bochs_pm_resume(struct device *dev) struct drm_device *drm_dev = pci_get_drvdata(pdev); struct bochs_device *bochs = drm_dev->dev_private; - drm_helper_resume_force_mode(drm_dev); - drm_fb_helper_set_suspend_unlocked(&bochs->fb.helper, 0); - - drm_kms_helper_poll_enable(drm_dev); - return 0; + return drm_mode_config_helper_resume(drm_dev); } #endif -- 2.9.3
[PATCH v4 09/16] drm/bochs: atomic: set DRIVER_ATOMIC
Conversion to atomic modesetting, final step. Set the DRIVER_ATOMIC flag. Signed-off-by: Gerd Hoffmann Reviewed-by: Oleksandr Andrushchenko Acked-by: Daniel Vetter --- drivers/gpu/drm/bochs/bochs_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bochs/bochs_drv.c b/drivers/gpu/drm/bochs/bochs_drv.c index 08ba6029d2..a8cb22cffe 100644 --- a/drivers/gpu/drm/bochs/bochs_drv.c +++ b/drivers/gpu/drm/bochs/bochs_drv.c @@ -81,7 +81,7 @@ static const struct file_operations bochs_fops = { }; static struct drm_driver bochs_driver = { - .driver_features= DRIVER_GEM | DRIVER_MODESET, + .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC, .fops = &bochs_fops, .name = "bochs-drm", .desc = "bochs dispi vga interface (qemu stdvga)", -- 2.9.3
[PATCH v4 11/16] drm/bochs: drop unused gpu_addr arg from bochs_bo_pin()
It's always NULL, so just remove it. Signed-off-by: Gerd Hoffmann Reviewed-by: Oleksandr Andrushchenko Acked-by: Daniel Vetter --- drivers/gpu/drm/bochs/bochs.h | 2 +- drivers/gpu/drm/bochs/bochs_fbdev.c | 2 +- drivers/gpu/drm/bochs/bochs_kms.c | 2 +- drivers/gpu/drm/bochs/bochs_mm.c| 11 +-- 4 files changed, 4 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h index 4dc1b6384e..d0d474e06f 100644 --- a/drivers/gpu/drm/bochs/bochs.h +++ b/drivers/gpu/drm/bochs/bochs.h @@ -142,7 +142,7 @@ int bochs_dumb_create(struct drm_file *file, struct drm_device *dev, int bochs_dumb_mmap_offset(struct drm_file *file, struct drm_device *dev, uint32_t handle, uint64_t *offset); -int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag, u64 *gpu_addr); +int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag); int bochs_bo_unpin(struct bochs_bo *bo); /* bochs_kms.c */ diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c b/drivers/gpu/drm/bochs/bochs_fbdev.c index d9f3d42999..92feb817ff 100644 --- a/drivers/gpu/drm/bochs/bochs_fbdev.c +++ b/drivers/gpu/drm/bochs/bochs_fbdev.c @@ -81,7 +81,7 @@ static int bochsfb_create(struct drm_fb_helper *helper, if (ret) return ret; - ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM, NULL); + ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM); if (ret) { DRM_ERROR("failed to pin fbcon\n"); ttm_bo_unreserve(&bo->bo); diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c index 5b7e1a7c6b..f663c54185 100644 --- a/drivers/gpu/drm/bochs/bochs_kms.c +++ b/drivers/gpu/drm/bochs/bochs_kms.c @@ -101,7 +101,7 @@ static int bochs_plane_prepare_fb(struct drm_plane *plane, ret = ttm_bo_reserve(&bo->bo, true, false, NULL); if (ret) return ret; - ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM, NULL); + ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM); ttm_bo_unreserve(&bo->bo); return ret; } diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c index 0980411e41..5a0e092847 100644 --- a/drivers/gpu/drm/bochs/bochs_mm.c +++ b/drivers/gpu/drm/bochs/bochs_mm.c @@ -210,20 +210,13 @@ static void bochs_ttm_placement(struct bochs_bo *bo, int domain) bo->placement.num_busy_placement = c; } -static inline u64 bochs_bo_gpu_offset(struct bochs_bo *bo) -{ - return bo->bo.offset; -} - -int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag, u64 *gpu_addr) +int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag) { struct ttm_operation_ctx ctx = { false, false }; int i, ret; if (bo->pin_count) { bo->pin_count++; - if (gpu_addr) - *gpu_addr = bochs_bo_gpu_offset(bo); return 0; } @@ -235,8 +228,6 @@ int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag, u64 *gpu_addr) return ret; bo->pin_count = 1; - if (gpu_addr) - *gpu_addr = bochs_bo_gpu_offset(bo); return 0; } -- 2.9.3
[PATCH v4 05/16] drm/bochs: atomic: switch planes to atomic, wire up helpers.
Conversion to atomic modesetting, step three. Wire up atomic helpers. Switch planes to atomic. We are late to the party, the transitional helpers are gone, so this can't be splitted into smaller steps any more. Signed-off-by: Gerd Hoffmann Reviewed-by: Oleksandr Andrushchenko Acked-by: Daniel Vetter --- drivers/gpu/drm/bochs/bochs_fbdev.c | 3 ++ drivers/gpu/drm/bochs/bochs_kms.c | 82 +++-- 2 files changed, 82 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c b/drivers/gpu/drm/bochs/bochs_fbdev.c index dd3c7df267..d9f3d42999 100644 --- a/drivers/gpu/drm/bochs/bochs_fbdev.c +++ b/drivers/gpu/drm/bochs/bochs_fbdev.c @@ -6,6 +6,7 @@ */ #include "bochs.h" +#include #include /* -- */ @@ -149,6 +150,8 @@ bochs_gem_fb_create(struct drm_device *dev, struct drm_file *file, const struct drm_mode_config_funcs bochs_mode_funcs = { .fb_create = bochs_gem_fb_create, + .atomic_check = drm_atomic_helper_check, + .atomic_commit = drm_atomic_helper_commit, }; int bochs_fbdev_init(struct bochs_device *bochs) diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c index 56fd7be933..c6993c2d59 100644 --- a/drivers/gpu/drm/bochs/bochs_kms.c +++ b/drivers/gpu/drm/bochs/bochs_kms.c @@ -6,7 +6,9 @@ */ #include "bochs.h" +#include #include +#include static int defx = 1024; static int defy = 768; @@ -113,7 +115,7 @@ static int bochs_crtc_page_flip(struct drm_crtc *crtc, struct drm_framebuffer *old_fb = crtc->primary->fb; unsigned long irqflags; - crtc->primary->fb = fb; + drm_atomic_set_fb_for_plane(crtc->primary->state, fb); bochs_crtc_mode_set_base(crtc, 0, 0, old_fb); if (event) { spin_lock_irqsave(&bochs->dev->event_lock, irqflags); @@ -151,6 +153,9 @@ static const struct drm_crtc_funcs bochs_crtc_funcs = { .set_config = drm_crtc_helper_set_config, .destroy = drm_crtc_cleanup, .page_flip = bochs_crtc_page_flip, + .reset = drm_atomic_helper_crtc_reset, + .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state, + .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state, }; static const struct drm_crtc_helper_funcs bochs_helper_funcs = { @@ -169,6 +174,71 @@ static const uint32_t bochs_formats[] = { DRM_FORMAT_BGRX, }; +static void bochs_plane_atomic_update(struct drm_plane *plane, + struct drm_plane_state *old_state) +{ + struct bochs_device *bochs = plane->dev->dev_private; + struct bochs_bo *bo; + + if (!plane->state->fb) + return; + bo = gem_to_bochs_bo(plane->state->fb->obj[0]); + bochs_hw_setbase(bochs, +plane->state->crtc_x, +plane->state->crtc_y, +bo->bo.offset); + bochs_hw_setformat(bochs, plane->state->fb->format); +} + +static int bochs_plane_prepare_fb(struct drm_plane *plane, + struct drm_plane_state *new_state) +{ + struct bochs_bo *bo; + int ret; + + if (!new_state->fb) + return 0; + bo = gem_to_bochs_bo(new_state->fb->obj[0]); + + ret = ttm_bo_reserve(&bo->bo, true, false, NULL); + if (ret) + return ret; + ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM, NULL); + ttm_bo_unreserve(&bo->bo); + return ret; +} + +static void bochs_plane_cleanup_fb(struct drm_plane *plane, + struct drm_plane_state *old_state) +{ + struct bochs_bo *bo; + int ret; + + if (!old_state->fb) + return; + bo = gem_to_bochs_bo(old_state->fb->obj[0]); + ret = ttm_bo_reserve(&bo->bo, true, false, NULL); + if (ret) + return; + bochs_bo_unpin(bo); + ttm_bo_unreserve(&bo->bo); +} + +static const struct drm_plane_helper_funcs bochs_plane_helper_funcs = { + .atomic_update = bochs_plane_atomic_update, + .prepare_fb = bochs_plane_prepare_fb, + .cleanup_fb = bochs_plane_cleanup_fb, +}; + +static const struct drm_plane_funcs bochs_plane_funcs = { + .update_plane = drm_atomic_helper_update_plane, + .disable_plane = drm_atomic_helper_disable_plane, + .destroy= drm_primary_helper_destroy, + .reset = drm_atomic_helper_plane_reset, + .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state, + .atomic_destroy_state = drm_atomic_helper_plane_destroy_state, +}; + static struct drm_plane *bochs_primary_plane(struct drm_device *dev) { struct drm_plane *primary; @@ -181,16 +251,17 @@ static struct drm_plane *bochs_primary_plane(struct drm_device *dev) } ret = drm_universal_plane_init(dev, primary, 0, - &drm
[PATCH v4 13/16] drm/bochs: add basic prime support
Just enough to make the generic framebuffer emulation happy. Signed-off-by: Gerd Hoffmann Reviewed-by: Oleksandr Andrushchenko Acked-by: Daniel Vetter --- drivers/gpu/drm/bochs/bochs.h | 7 ++ drivers/gpu/drm/bochs/bochs_drv.c | 11 - drivers/gpu/drm/bochs/bochs_mm.c | 49 +++ 3 files changed, 66 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h index d0d474e06f..ede22beb85 100644 --- a/drivers/gpu/drm/bochs/bochs.h +++ b/drivers/gpu/drm/bochs/bochs.h @@ -145,6 +145,13 @@ int bochs_dumb_mmap_offset(struct drm_file *file, struct drm_device *dev, int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag); int bochs_bo_unpin(struct bochs_bo *bo); +int bochs_gem_prime_pin(struct drm_gem_object *obj); +void bochs_gem_prime_unpin(struct drm_gem_object *obj); +void *bochs_gem_prime_vmap(struct drm_gem_object *obj); +void bochs_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr); +int bochs_gem_prime_mmap(struct drm_gem_object *obj, +struct vm_area_struct *vma); + /* bochs_kms.c */ int bochs_kms_init(struct bochs_device *bochs); void bochs_kms_fini(struct bochs_device *bochs); diff --git a/drivers/gpu/drm/bochs/bochs_drv.c b/drivers/gpu/drm/bochs/bochs_drv.c index a8cb22cffe..a3f4e21078 100644 --- a/drivers/gpu/drm/bochs/bochs_drv.c +++ b/drivers/gpu/drm/bochs/bochs_drv.c @@ -81,7 +81,8 @@ static const struct file_operations bochs_fops = { }; static struct drm_driver bochs_driver = { - .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC, + .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC | + DRIVER_PRIME, .fops = &bochs_fops, .name = "bochs-drm", .desc = "bochs dispi vga interface (qemu stdvga)", @@ -91,6 +92,14 @@ static struct drm_driver bochs_driver = { .gem_free_object_unlocked = bochs_gem_free_object, .dumb_create= bochs_dumb_create, .dumb_map_offset= bochs_dumb_mmap_offset, + + .gem_prime_export = drm_gem_prime_export, + .gem_prime_import = drm_gem_prime_import, + .gem_prime_pin = bochs_gem_prime_pin, + .gem_prime_unpin = bochs_gem_prime_unpin, + .gem_prime_vmap = bochs_gem_prime_vmap, + .gem_prime_vunmap = bochs_gem_prime_vunmap, + .gem_prime_mmap = bochs_gem_prime_mmap, }; /* -- */ diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c index fcbf35456d..641a33f134 100644 --- a/drivers/gpu/drm/bochs/bochs_mm.c +++ b/drivers/gpu/drm/bochs/bochs_mm.c @@ -395,3 +395,52 @@ int bochs_dumb_mmap_offset(struct drm_file *file, struct drm_device *dev, drm_gem_object_put_unlocked(obj); return 0; } + +/* -- */ + +int bochs_gem_prime_pin(struct drm_gem_object *obj) +{ + struct bochs_bo *bo = gem_to_bochs_bo(obj); + + return bochs_bo_pin(bo, TTM_PL_FLAG_VRAM); +} + +void bochs_gem_prime_unpin(struct drm_gem_object *obj) +{ + struct bochs_bo *bo = gem_to_bochs_bo(obj); + + bochs_bo_unpin(bo); +} + +void *bochs_gem_prime_vmap(struct drm_gem_object *obj) +{ + struct bochs_bo *bo = gem_to_bochs_bo(obj); + bool is_iomem; + int ret; + + ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM); + if (ret) + return NULL; + ret = ttm_bo_kmap(&bo->bo, 0, bo->bo.num_pages, &bo->kmap); + if (ret) { + bochs_bo_unpin(bo); + return NULL; + } + return ttm_kmap_obj_virtual(&bo->kmap, &is_iomem); +} + +void bochs_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr) +{ + struct bochs_bo *bo = gem_to_bochs_bo(obj); + + ttm_bo_kunmap(&bo->kmap); + bochs_bo_unpin(bo); +} + +int bochs_gem_prime_mmap(struct drm_gem_object *obj, +struct vm_area_struct *vma) +{ + struct bochs_bo *bo = gem_to_bochs_bo(obj); + + return ttm_fbdev_mmap(vma, &bo->bo); +} -- 2.9.3
[PATCH v4 07/16] drm/bochs: atomic: use atomic page_flip helper
Conversion to atomic modesetting, step five. Use atomic page_flip helper for crtc. Signed-off-by: Gerd Hoffmann Reviewed-by: Oleksandr Andrushchenko Acked-by: Daniel Vetter --- drivers/gpu/drm/bochs/bochs_kms.c | 23 +-- 1 file changed, 1 insertion(+), 22 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c index 646f897cb2..67c3674609 100644 --- a/drivers/gpu/drm/bochs/bochs_kms.c +++ b/drivers/gpu/drm/bochs/bochs_kms.c @@ -104,27 +104,6 @@ static void bochs_crtc_commit(struct drm_crtc *crtc) { } -static int bochs_crtc_page_flip(struct drm_crtc *crtc, - struct drm_framebuffer *fb, - struct drm_pending_vblank_event *event, - uint32_t page_flip_flags, - struct drm_modeset_acquire_ctx *ctx) -{ - struct bochs_device *bochs = - container_of(crtc, struct bochs_device, crtc); - struct drm_framebuffer *old_fb = crtc->primary->fb; - unsigned long irqflags; - - drm_atomic_set_fb_for_plane(crtc->primary->state, fb); - bochs_crtc_mode_set_base(crtc, 0, 0, old_fb); - if (event) { - spin_lock_irqsave(&bochs->dev->event_lock, irqflags); - drm_crtc_send_vblank_event(crtc, event); - spin_unlock_irqrestore(&bochs->dev->event_lock, irqflags); - } - return 0; -} - static void bochs_crtc_atomic_enable(struct drm_crtc *crtc, struct drm_crtc_state *old_crtc_state) { @@ -152,7 +131,7 @@ static void bochs_crtc_atomic_flush(struct drm_crtc *crtc, static const struct drm_crtc_funcs bochs_crtc_funcs = { .set_config = drm_atomic_helper_set_config, .destroy = drm_crtc_cleanup, - .page_flip = bochs_crtc_page_flip, + .page_flip = drm_atomic_helper_page_flip, .reset = drm_atomic_helper_crtc_reset, .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state, .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state, -- 2.9.3
[PATCH v4 10/16] drm/bochs: remove old bochs_crtc_* functions
Remove the old, now unused crtc callbacks. Signed-off-by: Gerd Hoffmann Reviewed-by: Oleksandr Andrushchenko Acked-by: Daniel Vetter --- drivers/gpu/drm/bochs/bochs_kms.c | 81 --- 1 file changed, 81 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c index 67c3674609..5b7e1a7c6b 100644 --- a/drivers/gpu/drm/bochs/bochs_kms.c +++ b/drivers/gpu/drm/bochs/bochs_kms.c @@ -20,74 +20,6 @@ MODULE_PARM_DESC(defy, "default y resolution"); /* -- */ -static void bochs_crtc_dpms(struct drm_crtc *crtc, int mode) -{ - switch (mode) { - case DRM_MODE_DPMS_ON: - case DRM_MODE_DPMS_STANDBY: - case DRM_MODE_DPMS_SUSPEND: - case DRM_MODE_DPMS_OFF: - default: - return; - } -} - -static int bochs_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y, - struct drm_framebuffer *old_fb) -{ - struct bochs_device *bochs = - container_of(crtc, struct bochs_device, crtc); - struct bochs_bo *bo; - u64 gpu_addr = 0; - int ret; - - if (old_fb) { - bo = gem_to_bochs_bo(old_fb->obj[0]); - ret = ttm_bo_reserve(&bo->bo, true, false, NULL); - if (ret) { - DRM_ERROR("failed to reserve old_fb bo\n"); - } else { - bochs_bo_unpin(bo); - ttm_bo_unreserve(&bo->bo); - } - } - - if (WARN_ON(crtc->primary->fb == NULL)) - return -EINVAL; - - bo = gem_to_bochs_bo(crtc->primary->fb->obj[0]); - ret = ttm_bo_reserve(&bo->bo, true, false, NULL); - if (ret) - return ret; - - ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM, &gpu_addr); - if (ret) { - ttm_bo_unreserve(&bo->bo); - return ret; - } - - ttm_bo_unreserve(&bo->bo); - bochs_hw_setbase(bochs, x, y, gpu_addr); - return 0; -} - -static int bochs_crtc_mode_set(struct drm_crtc *crtc, - struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode, - int x, int y, struct drm_framebuffer *old_fb) -{ - struct bochs_device *bochs = - container_of(crtc, struct bochs_device, crtc); - - if (WARN_ON(crtc->primary->fb == NULL)) - return -EINVAL; - - bochs_hw_setmode(bochs, mode); - bochs_hw_setformat(bochs, crtc->primary->fb->format); - bochs_crtc_mode_set_base(crtc, x, y, old_fb); - return 0; -} - static void bochs_crtc_mode_set_nofb(struct drm_crtc *crtc) { struct bochs_device *bochs = @@ -96,14 +28,6 @@ static void bochs_crtc_mode_set_nofb(struct drm_crtc *crtc) bochs_hw_setmode(bochs, &crtc->mode); } -static void bochs_crtc_prepare(struct drm_crtc *crtc) -{ -} - -static void bochs_crtc_commit(struct drm_crtc *crtc) -{ -} - static void bochs_crtc_atomic_enable(struct drm_crtc *crtc, struct drm_crtc_state *old_crtc_state) { @@ -138,12 +62,7 @@ static const struct drm_crtc_funcs bochs_crtc_funcs = { }; static const struct drm_crtc_helper_funcs bochs_helper_funcs = { - .dpms = bochs_crtc_dpms, - .mode_set = bochs_crtc_mode_set, - .mode_set_base = bochs_crtc_mode_set_base, .mode_set_nofb = bochs_crtc_mode_set_nofb, - .prepare = bochs_crtc_prepare, - .commit = bochs_crtc_commit, .atomic_enable = bochs_crtc_atomic_enable, .atomic_flush = bochs_crtc_atomic_flush, }; -- 2.9.3
[PATCH v4 02/16] drm/bochs: split bochs_hw_setmode
Create a separate bochs_hw_setformat function to configure the framebuffer format (actually just the byteorder). Signed-off-by: Gerd Hoffmann Reviewed-by: Oleksandr Andrushchenko Acked-by: Daniel Vetter --- drivers/gpu/drm/bochs/bochs.h | 5 +++-- drivers/gpu/drm/bochs/bochs_hw.c | 19 --- drivers/gpu/drm/bochs/bochs_kms.c | 3 ++- 3 files changed, 17 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h index fb38c8b857..4dc1b6384e 100644 --- a/drivers/gpu/drm/bochs/bochs.h +++ b/drivers/gpu/drm/bochs/bochs.h @@ -121,8 +121,9 @@ int bochs_hw_init(struct drm_device *dev); void bochs_hw_fini(struct drm_device *dev); void bochs_hw_setmode(struct bochs_device *bochs, - struct drm_display_mode *mode, - const struct drm_format_info *format); + struct drm_display_mode *mode); +void bochs_hw_setformat(struct bochs_device *bochs, + const struct drm_format_info *format); void bochs_hw_setbase(struct bochs_device *bochs, int x, int y, u64 addr); int bochs_hw_load_edid(struct bochs_device *bochs); diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c index d0b4e1cee8..3e04b2f0ec 100644 --- a/drivers/gpu/drm/bochs/bochs_hw.c +++ b/drivers/gpu/drm/bochs/bochs_hw.c @@ -204,8 +204,7 @@ void bochs_hw_fini(struct drm_device *dev) } void bochs_hw_setmode(struct bochs_device *bochs, - struct drm_display_mode *mode, - const struct drm_format_info *format) + struct drm_display_mode *mode) { bochs->xres = mode->hdisplay; bochs->yres = mode->vdisplay; @@ -213,12 +212,8 @@ void bochs_hw_setmode(struct bochs_device *bochs, bochs->stride = mode->hdisplay * (bochs->bpp / 8); bochs->yres_virtual = bochs->fb_size / bochs->stride; - DRM_DEBUG_DRIVER("%dx%d @ %d bpp, format %c%c%c%c, vy %d\n", + DRM_DEBUG_DRIVER("%dx%d @ %d bpp, vy %d\n", bochs->xres, bochs->yres, bochs->bpp, -(format->format >> 0) & 0xff, -(format->format >> 8) & 0xff, -(format->format >> 16) & 0xff, -(format->format >> 24) & 0xff, bochs->yres_virtual); bochs_vga_writeb(bochs, 0x3c0, 0x20); /* unblank */ @@ -236,6 +231,16 @@ void bochs_hw_setmode(struct bochs_device *bochs, bochs_dispi_write(bochs, VBE_DISPI_INDEX_ENABLE, VBE_DISPI_ENABLED | VBE_DISPI_LFB_ENABLED); +} + +void bochs_hw_setformat(struct bochs_device *bochs, + const struct drm_format_info *format) +{ + DRM_DEBUG_DRIVER("format %c%c%c%c\n", +(format->format >> 0) & 0xff, +(format->format >> 8) & 0xff, +(format->format >> 16) & 0xff, +(format->format >> 24) & 0xff); switch (format->format) { case DRM_FORMAT_XRGB: diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c index c8ce54498d..f7e6d1a9b3 100644 --- a/drivers/gpu/drm/bochs/bochs_kms.c +++ b/drivers/gpu/drm/bochs/bochs_kms.c @@ -80,7 +80,8 @@ static int bochs_crtc_mode_set(struct drm_crtc *crtc, if (WARN_ON(crtc->primary->fb == NULL)) return -EINVAL; - bochs_hw_setmode(bochs, mode, crtc->primary->fb->format); + bochs_hw_setmode(bochs, mode); + bochs_hw_setformat(bochs, crtc->primary->fb->format); bochs_crtc_mode_set_base(crtc, x, y, old_fb); return 0; } -- 2.9.3
[PATCH v4 15/16] drm/bochs: drop old fbdev emulation code
Not needed any more, bochs uses the generic emulation now. Signed-off-by: Gerd Hoffmann Reviewed-by: Oleksandr Andrushchenko Acked-by: Daniel Vetter --- drivers/gpu/drm/bochs/bochs.h | 9 --- drivers/gpu/drm/bochs/bochs_fbdev.c | 129 2 files changed, 138 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h index ede22beb85..03711394f1 100644 --- a/drivers/gpu/drm/bochs/bochs.h +++ b/drivers/gpu/drm/bochs/bochs.h @@ -80,12 +80,6 @@ struct bochs_device { struct ttm_bo_device bdev; bool initialized; } ttm; - - /* fbdev */ - struct { - struct drm_framebuffer *fb; - struct drm_fb_helper helper; - } fb; }; struct bochs_bo { @@ -157,7 +151,4 @@ int bochs_kms_init(struct bochs_device *bochs); void bochs_kms_fini(struct bochs_device *bochs); /* bochs_fbdev.c */ -int bochs_fbdev_init(struct bochs_device *bochs); -void bochs_fbdev_fini(struct bochs_device *bochs); - extern const struct drm_mode_config_funcs bochs_mode_funcs; diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c b/drivers/gpu/drm/bochs/bochs_fbdev.c index ccf783b038..7cac3f5253 100644 --- a/drivers/gpu/drm/bochs/bochs_fbdev.c +++ b/drivers/gpu/drm/bochs/bochs_fbdev.c @@ -11,124 +11,6 @@ /* -- */ -static int bochsfb_mmap(struct fb_info *info, - struct vm_area_struct *vma) -{ - struct drm_fb_helper *fb_helper = info->par; - struct bochs_bo *bo = gem_to_bochs_bo(fb_helper->fb->obj[0]); - - return ttm_fbdev_mmap(vma, &bo->bo); -} - -static struct fb_ops bochsfb_ops = { - .owner = THIS_MODULE, - DRM_FB_HELPER_DEFAULT_OPS, - .fb_fillrect = drm_fb_helper_cfb_fillrect, - .fb_copyarea = drm_fb_helper_cfb_copyarea, - .fb_imageblit = drm_fb_helper_cfb_imageblit, - .fb_mmap = bochsfb_mmap, -}; - -static int bochsfb_create_object(struct bochs_device *bochs, -const struct drm_mode_fb_cmd2 *mode_cmd, -struct drm_gem_object **gobj_p) -{ - struct drm_device *dev = bochs->dev; - struct drm_gem_object *gobj; - u32 size; - int ret = 0; - - size = mode_cmd->pitches[0] * mode_cmd->height; - ret = bochs_gem_create(dev, size, true, &gobj); - if (ret) - return ret; - - *gobj_p = gobj; - return ret; -} - -static int bochsfb_create(struct drm_fb_helper *helper, - struct drm_fb_helper_surface_size *sizes) -{ - struct bochs_device *bochs = - container_of(helper, struct bochs_device, fb.helper); - struct fb_info *info; - struct drm_framebuffer *fb; - struct drm_mode_fb_cmd2 mode_cmd; - struct drm_gem_object *gobj = NULL; - struct bochs_bo *bo = NULL; - int size, ret; - - if (sizes->surface_bpp != 32) - return -EINVAL; - - mode_cmd.width = sizes->surface_width; - mode_cmd.height = sizes->surface_height; - mode_cmd.pitches[0] = sizes->surface_width * 4; - mode_cmd.pixel_format = DRM_FORMAT_HOST_XRGB; - size = mode_cmd.pitches[0] * mode_cmd.height; - - /* alloc, pin & map bo */ - ret = bochsfb_create_object(bochs, &mode_cmd, &gobj); - if (ret) { - DRM_ERROR("failed to create fbcon backing object %d\n", ret); - return ret; - } - - bo = gem_to_bochs_bo(gobj); - - ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM); - if (ret) { - DRM_ERROR("failed to pin fbcon\n"); - return ret; - } - - ret = ttm_bo_kmap(&bo->bo, 0, bo->bo.num_pages, - &bo->kmap); - if (ret) { - DRM_ERROR("failed to kmap fbcon\n"); - return ret; - } - - /* init fb device */ - info = drm_fb_helper_alloc_fbi(helper); - if (IS_ERR(info)) { - DRM_ERROR("Failed to allocate fbi: %ld\n", PTR_ERR(info)); - return PTR_ERR(info); - } - - info->par = &bochs->fb.helper; - - fb = drm_gem_fbdev_fb_create(bochs->dev, sizes, 0, gobj, NULL); - if (IS_ERR(fb)) { - DRM_ERROR("Failed to create framebuffer: %ld\n", PTR_ERR(fb)); - return PTR_ERR(fb); - } - - /* setup helper */ - bochs->fb.helper.fb = fb; - - strcpy(info->fix.id, "bochsdrmfb"); - - info->fbops = &bochsfb_ops; - - drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth); - drm_fb_helper_fill_var(info, &bochs->fb.helper, sizes->fb_width, - sizes->fb_height); - - info->screen_base = bo->kmap.virtual; - info->screen_size = size; - - drm_vma_offset_remove(&bo->bo.bdev->vma_manager, &bo->bo.vma_node); - info->fix.smem_start = 0; - info-
Re: Patch series for 4.19 to compile powerpc with Clang
On Thu, Jan 10, 2019 at 10:17:38AM -0700, Nathan Chancellor wrote: > Hi Greg and Sasha, > > Attached is an mbox with a series of patches to allow building the > powerpc kernel with Clang. We have been running continuous integration > that builds and boots the kernel in QEMU for almost two months now with > no regressions. This is on top of 4.19.14, there should be no conflicts > but let me know if I messed something up. > > I will send a series for 4.14 in a little bit as well. All now queued up for 4.19 as well. thanks, greg k-h
Re: [PATCH v2] usb: gadget: musb: fix short isoc packets with inventra dma
Hi Bin, On Wed, Jan 09, 2019 at 09:02:15AM -0600, Bin Liu wrote: > Hi Paul, > > On Wed, Jan 09, 2019 at 02:10:09AM -0500, Paul Elder wrote: > > Handling short packets (length < max packet size) in the Inventra DMA > > engine in the MUSB driver causes the MUSB DMA controller to hang. An > > example of a problem that is caused by this problem is when streaming > > video out of a UVC gadget, only the first video frame is transferred. > > > > For short packets (mode-0 or mode-1 DMA), MUSB_TXCSR_TXPKTRDY must be > > set manually by the driver. This was previously done in musb_g_tx > > (musb_gadget.c), but incorrectly (all csr flags were cleared, and only > > MUSB_TXCSR_MODE and MUSB_TXCSR_TXPKTRDY were set). Fixing that problem > > allows some requests to be transferred correctly, but multiple requests > > were often put together in one USB packet, and caused problems if the > > packet size was not a multiple of 4. Instead, set MUSB_TXCSR_TXPKTRDY > > in dma_controller_irq (musbhsdma.c), just like host mode transfers. > > > > This topic was originally tackled by Nicolas Boichat [0] [1] and is > > discussed further at [2] as part of his GSoC project [3]. > > > > [0] > > https://groups.google.com/forum/?hl=en#!topic/beagleboard-gsoc/k8Azwfp75CU > > [1] > > https://gitorious.org/beagleboard-usbsniffer/beagleboard-usbsniffer-kernel/commit/b0be3b6cc195ba732189b04f1d43ec843c3e54c9?p=beagleboard-usbsniffer:beagleboard-usbsniffer-kernel.git;a=patch;h=b0be3b6cc195ba732189b04f1d43ec843c3e54c9 > > [2] > > http://beagleboard-usbsniffer.blogspot.com/2010/07/musb-isochronous-transfers-fixed.html > > [3] http://elinux.org/BeagleBoard/GSoC/USBSniffer > > > > Signed-off-by: Paul Elder > > --- > > Changes in v2: > > > > - no more flushing FIFO > > - greatly simplified short packet if guard in musb_g_tx, and removed > > unnecessary variables > > - minor indentation and wording changes > > > > drivers/usb/musb/musb_gadget.c | 19 +-- > > drivers/usb/musb/musbhsdma.c | 21 +++-- > > 2 files changed, 16 insertions(+), 24 deletions(-) > > > > diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c > > index eae8b1b1b45b..496643f54faa 100644 > > --- a/drivers/usb/musb/musb_gadget.c > > +++ b/drivers/usb/musb/musb_gadget.c > > @@ -452,13 +452,10 @@ void musb_g_tx(struct musb *musb, u8 epnum) > > } > > > > if (request) { > > - u8 is_dma = 0; > > - boolshort_packet = false; > > > > trace_musb_req_tx(req); > > > > if (dma && (csr & MUSB_TXCSR_DMAENAB)) { > > - is_dma = 1; > > csr |= MUSB_TXCSR_P_WZC_BITS; > > csr &= ~(MUSB_TXCSR_DMAENAB | MUSB_TXCSR_P_UNDERRUN | > > MUSB_TXCSR_TXPKTRDY | MUSB_TXCSR_AUTOSET); > > @@ -476,16 +473,8 @@ void musb_g_tx(struct musb *musb, u8 epnum) > > */ > > if ((request->zero && request->length) > > && (request->length % musb_ep->packet_sz == 0) > > - && (request->actual == request->length)) > > - short_packet = true; > > + && (request->actual == request->length)) { > > > > - if ((musb_dma_inventra(musb) || musb_dma_ux500(musb)) && > > - (is_dma && (!dma->desired_mode || > > - (request->actual & > > - (musb_ep->packet_sz - 1) > > - short_packet = true; > > - > > - if (short_packet) { > > /* > > * On DMA completion, FIFO may not be > > * available yet... > > @@ -493,8 +482,10 @@ void musb_g_tx(struct musb *musb, u8 epnum) > > if (csr & MUSB_TXCSR_TXPKTRDY) > > return; > > > > - musb_writew(epio, MUSB_TXCSR, MUSB_TXCSR_MODE > > - | MUSB_TXCSR_TXPKTRDY); > > + musb_dbg(musb, "sending short pkt (zero=%d, length=%d, > > actual=%d, dma->desired_mode=%d)\n", > > +request->zero, request->length, > > request->actual, > > +dma->desired_mode); > > + musb_writew(epio, MUSB_TXCSR, csr | > > MUSB_TXCSR_TXPKTRDY); > > Sorry I didn't catch this in the last review, but this change seems not > required, isn't it? In the first version of the patch, the code is > 'returned' in the 'if (musb_dma_inventra())' branch above, doesn't reach > here. Do you mean change compared to the last version of the patch, or this last chunk of the diff? I guess I did also remove the return when I removed the 'if (musb_dma_inventra())' block that had the FLUSHFIFIO, but when I tested it it still worked. In fact, I reverted this last diff chunk and it still worked. Paul
Re: [PATCHv2 2/7] acpi: change the topo of acpi_table_upgrade()
On Fri, Jan 11, 2019 at 01:12:52PM +0800, Pingfan Liu wrote: >The current acpi_table_upgrade() relies on initrd_start, but this var is >only valid after relocate_initrd(). There is requirement to extract the >acpi info from initrd before memblock-allocator can work(see [2/4]), hence >acpi_table_upgrade() need to accept the input param directly. > >Signed-off-by: Pingfan Liu >Acked-by: "Rafael J. Wysocki" >Cc: Thomas Gleixner >Cc: Ingo Molnar >Cc: Borislav Petkov >Cc: "H. Peter Anvin" >Cc: Dave Hansen >Cc: Andy Lutomirski >Cc: Peter Zijlstra >Cc: "Rafael J. Wysocki" >Cc: Len Brown >Cc: Yinghai Lu >Cc: Tejun Heo >Cc: Chao Fan >Cc: Baoquan He >Cc: Juergen Gross >Cc: Andrew Morton >Cc: Mike Rapoport >Cc: Vlastimil Babka >Cc: Michal Hocko >Cc: x...@kernel.org >Cc: linux-a...@vger.kernel.org >Cc: linux...@kvack.org >--- > arch/arm64/kernel/setup.c | 2 +- > arch/x86/kernel/setup.c | 2 +- > drivers/acpi/tables.c | 4 +--- > include/linux/acpi.h | 4 ++-- > 4 files changed, 5 insertions(+), 7 deletions(-) > >diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c >index f4fc1e0..bc4b47d 100644 >--- a/arch/arm64/kernel/setup.c >+++ b/arch/arm64/kernel/setup.c >@@ -315,7 +315,7 @@ void __init setup_arch(char **cmdline_p) > paging_init(); > efi_apply_persistent_mem_reservations(); > >- acpi_table_upgrade(); >+ acpi_table_upgrade((void *)initrd_start, initrd_end - initrd_start); > > /* Parse the ACPI tables for possible boot-time configuration */ > acpi_boot_table_init(); >diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c >index ac432ae..dc8fc5d 100644 >--- a/arch/x86/kernel/setup.c >+++ b/arch/x86/kernel/setup.c >@@ -1172,8 +1172,8 @@ void __init setup_arch(char **cmdline_p) > > reserve_initrd(); > >- acpi_table_upgrade(); > I wonder whether this will cause two blank lines together. Thanks, Chao Fan >+ acpi_table_upgrade((void *)initrd_start, initrd_end - initrd_start); > vsmp_init(); > > io_delay_init(); >diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c >index 61203ee..84e0a79 100644 >--- a/drivers/acpi/tables.c >+++ b/drivers/acpi/tables.c >@@ -471,10 +471,8 @@ static DECLARE_BITMAP(acpi_initrd_installed, >NR_ACPI_INITRD_TABLES); > > #define MAP_CHUNK_SIZE (NR_FIX_BTMAPS << PAGE_SHIFT) > >-void __init acpi_table_upgrade(void) >+void __init acpi_table_upgrade(void *data, size_t size) > { >- void *data = (void *)initrd_start; >- size_t size = initrd_end - initrd_start; > int sig, no, table_nr = 0, total_offset = 0; > long offset = 0; > struct acpi_table_header *table; >diff --git a/include/linux/acpi.h b/include/linux/acpi.h >index ed80f14..0b6e0b6 100644 >--- a/include/linux/acpi.h >+++ b/include/linux/acpi.h >@@ -1254,9 +1254,9 @@ acpi_graph_get_remote_endpoint(const struct >fwnode_handle *fwnode, > #endif > > #ifdef CONFIG_ACPI_TABLE_UPGRADE >-void acpi_table_upgrade(void); >+void acpi_table_upgrade(void *data, size_t size); > #else >-static inline void acpi_table_upgrade(void) { } >+static inline void acpi_table_upgrade(void *data, size_t size) { } > #endif > > #if defined(CONFIG_ACPI) && defined(CONFIG_ACPI_WATCHDOG) >-- >2.7.4 > > >
Discuss
Hello, My Name is Johann Reimann and i have something important to discuss with you but only with your permission i will proceed. Regards J. Reimann
Re: [RFC PATCH kernel] powerpc/stack_protector: Fix external modules building
Masahiro Yamada writes: > On Thu, Jan 10, 2019 at 2:44 PM Alexey Kardashevskiy wrote: ... >> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile >> index 488c9ed..0492f62 100644 >> --- a/arch/powerpc/Makefile >> +++ b/arch/powerpc/Makefile >> @@ -419,7 +419,11 @@ archheaders: >> ifdef CONFIG_STACKPROTECTOR >> prepare: stack_protector_prepare >> >> +ifeq ($(KBUILD_EXTMOD),) >> stack_protector_prepare: prepare0 >> +else >> +stack_protector_prepare: >> +endif > > > Honestly, I think this is ugly. Yes I would call it a hack :) > Do you want me to send an alternative solution? I don't grok how external modules are built well enough to work out what the right solution is. So if you can come up with something better that would be awesome. cheers
Re: [PATCH 4/4] usb: musb: Add support for MediaTek musb controller
Hi Bin, I have some questions about musbhs_dma_controller_destroy/create_noirq(). 1,Because of controller->irq=0 in noirq case, destroy_noirq can reuse musbhs_dma_controller_destroy. Is it necessary to write a destroy_noirq function? 2, How about creating a common function for create musb dma controller as following: static struct musb_dma_controller *dma_controller_alloc(struct musb *musb, void __iomem *base) then musbhs_dma_controller_create() and musbhs_dma_controller_create_noirq() call it to alloc common resource. On Tue, 2019-01-08 at 09:44 -0600, Bin Liu wrote: > Hi, > > On Thu, Dec 27, 2018 at 03:34:26PM +0800, min@mediatek.com wrote: > > From: Min Guo > > > > This adds support for MediaTek musb controller in > > host, peripheral and otg mode > > > > diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c > > index 824adcb..c545475 100644 > > --- a/drivers/usb/musb/musbhsdma.c > > +++ b/drivers/usb/musb/musbhsdma.c > > > > void musbhs_dma_controller_destroy(struct dma_controller *c) > > { > > struct musb_dma_controller *controller = container_of(c, > > struct musb_dma_controller, controller); > > + struct musb *musb = controller->private_data; > > > > dma_controller_stop(controller); > > > > - if (controller->irq) > > + if (!(musb->ops->quirks & MUSB_MTK_QUIRKS) && controller->irq) > > free_irq(controller->irq, c); > > > > kfree(controller); > > @@ -398,11 +402,15 @@ struct dma_controller > > *musbhs_dma_controller_create(struct musb *musb, > > struct musb_dma_controller *controller; > > struct device *dev = musb->controller; > > struct platform_device *pdev = to_platform_device(dev); > > - int irq = platform_get_irq_byname(pdev, "dma"); > > + int irq = -1; > > > > - if (irq <= 0) { > > - dev_err(dev, "No DMA interrupt line!\n"); > > - return NULL; > > + if (!(musb->ops->quirks & MUSB_MTK_QUIRKS)) { > > + irq = platform_get_irq_byname(pdev, "dma"); > > + > > + if (irq < 0) { > > + dev_err(dev, "No DMA interrupt line!\n"); > > + return NULL; > > + } > > } > > Please create musbhs_dma_controller_destroy_noirq() for your platform to > not use the quirk. > > > > > controller = kzalloc(sizeof(*controller), GFP_KERNEL); > > @@ -418,15 +426,17 @@ struct dma_controller > > *musbhs_dma_controller_create(struct musb *musb, > > controller->controller.channel_program = dma_channel_program; > > controller->controller.channel_abort = dma_channel_abort; > > > > - if (request_irq(irq, dma_controller_irq, 0, > > + if (!(musb->ops->quirks & MUSB_MTK_QUIRKS)) { > > + if (request_irq(irq, dma_controller_irq, 0, > > dev_name(musb->controller), &controller->controller)) { > > - dev_err(dev, "request_irq %d failed!\n", irq); > > - musb_dma_controller_destroy(&controller->controller); > > + dev_err(dev, "request_irq %d failed!\n", irq); > > + musb_dma_controller_destroy(&controller->controller); > > > > - return NULL; > > - } > > + return NULL; > > + } > > > > - controller->irq = irq; > > + controller->irq = irq; > > + } > > > > return &controller->controller; > > } > > Same here, create musbhs_dma_controller_create_noirq(). Then use both > new API for the mtk glue driver. > Regards, > -Bin.
[PATCH 3/3] ARM: dts: cygnus: Change pwm compatible to new version
From: Praveen Kumar B Change pwm compatible to new version of pwm-kona Add new compatible to check pwm configure status Signed-off-by: Praveen Kumar B Reviewed-by: Ray Jui Reviewed-by: Scott Branden Signed-off-by: Sheetal Tigadoli --- arch/arm/boot/dts/bcm-cygnus.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi index 253df71..2a433e7 100644 --- a/arch/arm/boot/dts/bcm-cygnus.dtsi +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi @@ -595,7 +595,7 @@ }; pwm: pwm@180aa500 { - compatible = "brcm,kona-pwm"; + compatible = "brcm,kona-pwm-v2"; reg = <0x180aa500 0xc4>; #pwm-cells = <3>; clocks = <&asiu_clks BCM_CYGNUS_ASIU_PWM_CLK>; -- 1.9.1
[PATCH 2/3] drivers: pwm: pwm-bcm-kona: Add pwm-kona-v2 support
From: Praveen Kumar B Add support for new version of pwm-kona. Add support to make PWM changes configured and stable. Signed-off-by: Praveen Kumar B Reviewed-by: Ray Jui Reviewed-by: Scott Branden Signed-off-by: Sheetal Tigadoli --- drivers/pwm/pwm-bcm-kona.c | 128 ++--- 1 file changed, 98 insertions(+), 30 deletions(-) diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c index 09a95ae..2b44ad8 100644 --- a/drivers/pwm/pwm-bcm-kona.c +++ b/drivers/pwm/pwm-bcm-kona.c @@ -45,30 +45,39 @@ *high or low depending on its state at that exact instant. */ -#define PWM_CONTROL_OFFSET (0x) +#define PWM_CONTROL_OFFSET 0x #define PWM_CONTROL_SMOOTH_SHIFT(chan) (24 + (chan)) #define PWM_CONTROL_TYPE_SHIFT(chan) (16 + (chan)) #define PWM_CONTROL_POLARITY_SHIFT(chan) (8 + (chan)) #define PWM_CONTROL_TRIGGER_SHIFT(chan)(chan) -#define PRESCALE_OFFSET(0x0004) +#define PRESCALE_OFFSET0x0004 #define PRESCALE_SHIFT(chan) ((chan) << 2) #define PRESCALE_MASK(chan)(0x7 << PRESCALE_SHIFT(chan)) -#define PRESCALE_MIN (0x) -#define PRESCALE_MAX (0x0007) +#define PRESCALE_MIN 0x +#define PRESCALE_MAX 0x0007 #define PERIOD_COUNT_OFFSET(chan) (0x0008 + ((chan) << 3)) -#define PERIOD_COUNT_MIN (0x0002) -#define PERIOD_COUNT_MAX (0x00ff) +#define PERIOD_COUNT_MIN 0x0002 +#define PERIOD_COUNT_MAX 0x00ff #define DUTY_CYCLE_HIGH_OFFSET(chan) (0x000c + ((chan) << 3)) -#define DUTY_CYCLE_HIGH_MIN(0x) -#define DUTY_CYCLE_HIGH_MAX(0x00ff) +#define DUTY_CYCLE_HIGH_MIN0x +#define DUTY_CYCLE_HIGH_MAX0x00ff + +#define PWM_MONITOR_OFFSET 0xb0 +#define PWM_MONITOR_TIMEOUT_US 5 + +enum kona_pwmc_ver { + KONA_PWM_V1 = 1, + KONA_PWM_V2 +}; struct kona_pwmc { struct pwm_chip chip; void __iomem *base; struct clk *clk; + enum kona_pwmc_ver version; }; static inline struct kona_pwmc *to_kona_pwmc(struct pwm_chip *_chip) @@ -76,11 +85,40 @@ static inline struct kona_pwmc *to_kona_pwmc(struct pwm_chip *_chip) return container_of(_chip, struct kona_pwmc, chip); } +static int kona_pwmc_wait_stable(struct pwm_chip *chip, unsigned int chan, +unsigned int kona_ver) +{ + struct kona_pwmc *kp = to_kona_pwmc(chip); + unsigned int value; + unsigned int count = PWM_MONITOR_TIMEOUT_US * 1000; + + switch (kona_ver) { + case KONA_PWM_V1: + /* +* There must be a min 400ns delay between clearing trigger and +* settingit. Failing to do this may result in no PWM signal. +*/ + ndelay(400); + return 0; + case KONA_PWM_V2: + do { + value = readl(kp->base + PWM_MONITOR_OFFSET); + if (!(value & (BIT(chan + return 0; + ndelay(1); + } while (count--); + + return -ETIMEDOUT; + default: + return -ENODEV; + } +} + /* * Clear trigger bit but set smooth bit to maintain old output. */ -static void kona_pwmc_prepare_for_settings(struct kona_pwmc *kp, - unsigned int chan) +static int kona_pwmc_prepare_for_settings(struct kona_pwmc *kp, + unsigned int chan) { unsigned int value = readl(kp->base + PWM_CONTROL_OFFSET); @@ -88,14 +126,10 @@ static void kona_pwmc_prepare_for_settings(struct kona_pwmc *kp, value &= ~(1 << PWM_CONTROL_TRIGGER_SHIFT(chan)); writel(value, kp->base + PWM_CONTROL_OFFSET); - /* -* There must be a min 400ns delay between clearing trigger and setting -* it. Failing to do this may result in no PWM signal. -*/ - ndelay(400); + return kona_pwmc_wait_stable(&kp->chip, chan, kp->version); } -static void kona_pwmc_apply_settings(struct kona_pwmc *kp, unsigned int chan) +static int kona_pwmc_apply_settings(struct kona_pwmc *kp, unsigned int chan) { unsigned int value = readl(kp->base + PWM_CONTROL_OFFSET); @@ -104,8 +138,7 @@ static void kona_pwmc_apply_settings(struct kona_pwmc *kp, unsigned int chan) value |= 1 << PWM_CONTROL_TRIGGER_SHIFT(chan); writel(value, kp->base + PWM_CONTROL_OFFSET); - /* Trigger bit must be held high for at least 400 ns. */ -
[PATCH 1/3] dt-bindings: pwm: kona: Add new compatible for new version pwm-kona
From: Praveen Kumar B Add new compatible string for new version of pwm-kona Signed-off-by: Praveen Kumar B Reviewed-by: Ray Jui Reviewed-by: Scott Branden Signed-off-by: Sheetal Tigadoli --- Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt b/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt index 8eae9fe..d37f697 100644 --- a/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt @@ -3,7 +3,7 @@ Broadcom Kona PWM controller device tree bindings This controller has 6 channels. Required Properties : -- compatible: should contain "brcm,kona-pwm" +- compatible: should contain "brcm,kona-pwm" or "brcm,kona-pwm-v2" - reg: physical base address and length of the controller's registers - clocks: phandle + clock specifier pair for the external clock - #pwm-cells: Should be 3. See pwm.txt in this directory for a -- 1.9.1
[PATCH 0/3] Add support for PWM Configure and stablize for PWM kona
Hi, This patchset contain support to make PWM changes configure and stablize Following are brief changes done a. Add support for version2 compatible string b. Change PWM config and stablize delay in PWM Kona Praveen Kumar B (3): dt-bindings: pwm: kona: Add new compatible for new version pwm-kona drivers: pwm: pwm-bcm-kona: Add pwm-kona-v2 support ARM: dts: cygnus: Change pwm compatible to new version .../devicetree/bindings/pwm/brcm,kona-pwm.txt | 2 +- arch/arm/boot/dts/bcm-cygnus.dtsi | 2 +- drivers/pwm/pwm-bcm-kona.c | 128 - 3 files changed, 100 insertions(+), 32 deletions(-) -- 1.9.1
[PATCHv2 4/7] x86/setup: parse acpi to get hotplug info before init_mem_mapping()
At present, memblock bottom-up allocation can help us against staining over movable node in very high probability. But if the hotplug info has already been parsed, the memblock allocator can step around the movable node by itself. This patch pushes the parsing step forward, just ahead of where, the memblock allocator can work. About how memblock allocator steps around the movable node, referring to the cond check on memblock_is_hotpluggable() in __next_mem_range(). Later in this series, the bottom-up allocation style can be removed on x86_64. Signed-off-by: Pingfan Liu Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Dave Hansen Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: Yinghai Lu Cc: Tejun Heo Cc: Chao Fan Cc: Baoquan He Cc: Juergen Gross Cc: Andrew Morton Cc: Mike Rapoport Cc: Vlastimil Babka Cc: Michal Hocko Cc: x...@kernel.org Cc: linux-a...@vger.kernel.org Cc: linux...@kvack.org --- arch/x86/kernel/setup.c | 39 ++- include/linux/acpi.h| 1 + 2 files changed, 31 insertions(+), 9 deletions(-) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index a0122cd..9b57e01 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -804,6 +804,35 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p) return 0; } +static void early_acpi_parse(void) +{ + phys_addr_t start, end, orig_start, orig_end; + bool enforcing; + + enforcing = memblock_get_current_limit(&orig_start, &orig_end); + /* find a 16MB slot for temporary usage by the following routines. */ + start = memblock_find_in_range(ISA_END_ADDRESS, + max_pfn, 1 << 24, 1); + end = start + 1 + (1 << 24); + memblock_set_current_limit(start, end, true); +#ifdef CONFIG_BLK_DEV_INITRD + if (get_ramdisk_size()) + acpi_table_upgrade(__va(get_ramdisk_image()), + get_ramdisk_size()); +#endif + /* +* Parse the ACPI tables for possible boot-time SMP configuration. +*/ + acpi_boot_table_init(); + early_acpi_boot_init(); + initmem_init(); + /* check whether memory is returned or not */ + start = memblock_find_in_range(start, end, 1<<24, 1); + if (!start) + pr_warn("the above acpi routines change and consume memory\n"); + memblock_set_current_limit(orig_start, orig_end, enforcing); +} + /* * Determine if we were loaded by an EFI loader. If so, then we have also been * passed the efi memmap, systab, etc., so we should use these data structures @@ -1129,6 +1158,7 @@ void __init setup_arch(char **cmdline_p) if (movable_node_is_enabled()) memblock_set_bottom_up(true); #endif + early_acpi_parse(); init_mem_mapping(); memblock_set_current_limit(0, get_max_mapped(), false); @@ -1173,21 +1203,12 @@ void __init setup_arch(char **cmdline_p) reserve_initrd(); - acpi_table_upgrade((void *)initrd_start, initrd_end - initrd_start); vsmp_init(); io_delay_init(); early_platform_quirks(); - /* -* Parse the ACPI tables for possible boot-time SMP configuration. -*/ - acpi_boot_table_init(); - - early_acpi_boot_init(); - - initmem_init(); dma_contiguous_reserve(max_pfn_mapped << PAGE_SHIFT); /* diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 0b6e0b6..4f6b391 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -235,6 +235,7 @@ int acpi_mps_check (void); int acpi_numa_init (void); int acpi_table_init (void); +void acpi_tb_terminate(void); int acpi_table_parse(char *id, acpi_tbl_table_handler handler); int __init acpi_table_parse_entries(char *id, unsigned long table_size, int entry_id, -- 2.7.4
[PATCHv2 2/7] acpi: change the topo of acpi_table_upgrade()
The current acpi_table_upgrade() relies on initrd_start, but this var is only valid after relocate_initrd(). There is requirement to extract the acpi info from initrd before memblock-allocator can work(see [2/4]), hence acpi_table_upgrade() need to accept the input param directly. Signed-off-by: Pingfan Liu Acked-by: "Rafael J. Wysocki" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Dave Hansen Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: Yinghai Lu Cc: Tejun Heo Cc: Chao Fan Cc: Baoquan He Cc: Juergen Gross Cc: Andrew Morton Cc: Mike Rapoport Cc: Vlastimil Babka Cc: Michal Hocko Cc: x...@kernel.org Cc: linux-a...@vger.kernel.org Cc: linux...@kvack.org --- arch/arm64/kernel/setup.c | 2 +- arch/x86/kernel/setup.c | 2 +- drivers/acpi/tables.c | 4 +--- include/linux/acpi.h | 4 ++-- 4 files changed, 5 insertions(+), 7 deletions(-) diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c index f4fc1e0..bc4b47d 100644 --- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -315,7 +315,7 @@ void __init setup_arch(char **cmdline_p) paging_init(); efi_apply_persistent_mem_reservations(); - acpi_table_upgrade(); + acpi_table_upgrade((void *)initrd_start, initrd_end - initrd_start); /* Parse the ACPI tables for possible boot-time configuration */ acpi_boot_table_init(); diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index ac432ae..dc8fc5d 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -1172,8 +1172,8 @@ void __init setup_arch(char **cmdline_p) reserve_initrd(); - acpi_table_upgrade(); + acpi_table_upgrade((void *)initrd_start, initrd_end - initrd_start); vsmp_init(); io_delay_init(); diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c index 61203ee..84e0a79 100644 --- a/drivers/acpi/tables.c +++ b/drivers/acpi/tables.c @@ -471,10 +471,8 @@ static DECLARE_BITMAP(acpi_initrd_installed, NR_ACPI_INITRD_TABLES); #define MAP_CHUNK_SIZE (NR_FIX_BTMAPS << PAGE_SHIFT) -void __init acpi_table_upgrade(void) +void __init acpi_table_upgrade(void *data, size_t size) { - void *data = (void *)initrd_start; - size_t size = initrd_end - initrd_start; int sig, no, table_nr = 0, total_offset = 0; long offset = 0; struct acpi_table_header *table; diff --git a/include/linux/acpi.h b/include/linux/acpi.h index ed80f14..0b6e0b6 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -1254,9 +1254,9 @@ acpi_graph_get_remote_endpoint(const struct fwnode_handle *fwnode, #endif #ifdef CONFIG_ACPI_TABLE_UPGRADE -void acpi_table_upgrade(void); +void acpi_table_upgrade(void *data, size_t size); #else -static inline void acpi_table_upgrade(void) { } +static inline void acpi_table_upgrade(void *data, size_t size) { } #endif #if defined(CONFIG_ACPI) && defined(CONFIG_ACPI_WATCHDOG) -- 2.7.4
[PATCHv2 5/7] x86/mm: set allowed range for memblock allocator
Due to the incoming divergence of x86_32 and x86_64, there is requirement to set the allowed allocating range at the early boot stage. This patch also includes minor change to remove redundat cond check, refer to memblock_find_in_range_node(), memblock_find_in_range() has already protect itself from the case: start > end. Signed-off-by: Pingfan Liu Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Dave Hansen Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: Yinghai Lu Cc: Tejun Heo Cc: Chao Fan Cc: Baoquan He Cc: Juergen Gross Cc: Andrew Morton Cc: Mike Rapoport Cc: Vlastimil Babka Cc: Michal Hocko Cc: x...@kernel.org Cc: linux-a...@vger.kernel.org Cc: linux...@kvack.org --- arch/x86/mm/init.c | 24 +--- 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c index ef99f38..385b9cd 100644 --- a/arch/x86/mm/init.c +++ b/arch/x86/mm/init.c @@ -76,6 +76,14 @@ static unsigned long min_pfn_mapped; static bool __initdata can_use_brk_pgt = true; +static unsigned long min_pfn_allowed; +static unsigned long max_pfn_allowed; +void set_alloc_range(unsigned long low, unsigned long high) +{ + min_pfn_allowed = low; + max_pfn_allowed = high; +} + /* * Pages returned are already directly mapped. * @@ -100,12 +108,10 @@ __ref void *alloc_low_pages(unsigned int num) if ((pgt_buf_end + num) > pgt_buf_top || !can_use_brk_pgt) { unsigned long ret = 0; - if (min_pfn_mapped < max_pfn_mapped) { - ret = memblock_find_in_range( - min_pfn_mapped << PAGE_SHIFT, - max_pfn_mapped << PAGE_SHIFT, - PAGE_SIZE * num , PAGE_SIZE); - } + ret = memblock_find_in_range( + min_pfn_allowed << PAGE_SHIFT, + max_pfn_allowed << PAGE_SHIFT, + PAGE_SIZE * num, PAGE_SIZE); if (ret) memblock_reserve(ret, PAGE_SIZE * num); else if (can_use_brk_pgt) @@ -588,14 +594,17 @@ static void __init memory_map_top_down(unsigned long map_start, start = map_start; mapped_ram_size += init_range_memory_mapping(start, last_start); + set_alloc_range(min_pfn_mapped, max_pfn_mapped); last_start = start; min_pfn_mapped = last_start >> PAGE_SHIFT; if (mapped_ram_size >= step_size) step_size = get_new_step_size(step_size); } - if (real_end < map_end) + if (real_end < map_end) { init_range_memory_mapping(real_end, map_end); + set_alloc_range(min_pfn_mapped, max_pfn_mapped); + } } /** @@ -636,6 +645,7 @@ static void __init memory_map_bottom_up(unsigned long map_start, } mapped_ram_size += init_range_memory_mapping(start, next); + set_alloc_range(min_pfn_mapped, max_pfn_mapped); start = next; if (mapped_ram_size >= step_size) -- 2.7.4