{"push_id":839573082,"size":1000,"distinct_size":0,"ref":"refs/heads/arm/renesas","head":"bad78b13e3057b4bbfe769e21c213dca7c4d51de","before":"bb590c9011a7c4e195af486438ead666023f96bd","commits":[{"sha":"35bfe456be3ae1e11dd63e83096c95d0c6429c51","author":{"email":"6a953cb1c532e2765a42e582ecefff5a01106214@samsung.com","name":"Jacek Anaszewski"},"message":"leds: leds-ipaq-micro: Add LEDS_CLASS dependency\n\nFix missing Kconfig LEDS_CLASS dependency.\n\nSigned-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>\nReviewed-by: Linus Walleij <linus.walleij@linaro.org>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/35bfe456be3ae1e11dd63e83096c95d0c6429c51"},{"sha":"2338f73d407d5abe2036d92716ba25ef5279c3d2","author":{"email":"4596b3305151c7ee743192a95d394341e3d3b644@suse.de","name":"Takashi Iwai"},"message":"leds:lp55xx: Correct Kconfig dependency for f/w user helper\n\nThe commit [b67893206fc0: leds:lp55xx: fix firmware loading error]\ntries to address the firmware file handling with user helper, but it\nsets a wrong Kconfig CONFIG_FW_LOADER_USER_HELPER_FALLBACK.  Since the\nwrong option was enabled, the system got a regression -- it suffers\nfrom the unexpected long delays for non-present firmware files.\n\nThis patch corrects the Kconfig dependency to the right one,\nCONFIG_FW_LOADER_USER_HELPER.  This doesn't change the fallback\nbehavior but only enables UMH when needed.\n\nBugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=944661\nFixes: b67893206fc0 ('leds:lp55xx: fix firmware loading error')\nCc: <stable@vger.kernel.org> # v4.2+\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/2338f73d407d5abe2036d92716ba25ef5279c3d2"},{"sha":"b07bb761cf6a333b2108cdbe4ffee66407189bb1","author":{"email":"a26490dfbee4be3d38287ad6448444504f58193c@vmware.com","name":"Thomas Hellstrom"},"message":"drm/vmwgfx: Only build on X86\n\nioremap_cache() is currently not available on some architectures.\n\nReported-by: kbuild test robot <fengguang.wu@intel.com>\nSigned-off-by: Thomas Hellstrom <thellstrom@vmware.com>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/b07bb761cf6a333b2108cdbe4ffee66407189bb1"},{"sha":"d8949aad3eab5d396f4fefcd581773bf07b9a79e","author":{"email":"628991c7b0a19c384f9b99c21ec330ce952bb838@intel.com","name":"Johan Hedberg"},"message":"Bluetooth: Delay check for conn->smp in smp_conn_security()\n\nThere are several actions that smp_conn_security() might make that do\nnot require a valid SMP context (conn->smp pointer). One of these\nactions is to encrypt the link with an existing LTK. If the SMP\ncontext wasn't initialized properly we should still allow the\nindependent actions to be done, i.e. the check for the context should\nonly be done at the last possible moment.\n\nReported-by: Chuck Ebbert <cebbert.lkml@gmail.com>\nSigned-off-by: Johan Hedberg <johan.hedberg@intel.com>\nSigned-off-by: Marcel Holtmann <marcel@holtmann.org>\nCc: stable@vger.kernel.org # 4.0+","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/d8949aad3eab5d396f4fefcd581773bf07b9a79e"},{"sha":"e56d82a116176f7af9d642b560abbbd3a2b68013","author":{"email":"b913f13ef92ac157955c954ccaaff7be065faba4@arm.com","name":"Will Deacon"},"message":"arm64: cpu hotplug: ensure we mask out CPU_TASKS_FROZEN in notifiers\n\nWe have a couple of CPU hotplug notifiers for resetting the CPU debug\nstate to a sane value when a CPU comes online.\n\nThis patch ensures that we mask out CPU_TASKS_FROZEN so that we don't\nmiss any online events occuring due to suspend/resume.\n\nAcked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>\nSigned-off-by: Will Deacon <will.deacon@arm.com>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/e56d82a116176f7af9d642b560abbbd3a2b68013"},{"sha":"bdec97a855ef1e239f130f7a11584721c9a1bf04","author":{"email":"b913f13ef92ac157955c954ccaaff7be065faba4@arm.com","name":"Will Deacon"},"message":"arm64: compat: fix vfp save/restore across signal handlers in big-endian\n\nWhen saving/restoring the VFP registers from a compat (AArch32)\nsignal frame, we rely on the compat registers forming a prefix of the\nnative register file and therefore make use of copy_{to,from}_user to\ntransfer between the native fpsimd_state and the compat_vfp_sigframe.\n\nUnfortunately, this doesn't work so well in a big-endian environment.\nOur fpsimd save/restore code operates directly on 128-bit quantities\n(Q registers) whereas the compat_vfp_sigframe represents the registers\nas an array of 64-bit (D) registers. The architecture packs the compat D\nregisters into the Q registers, with the least significant bytes holding\nthe lower register. Consequently, we need to swap the 64-bit halves when\nconverting between these two representations on a big-endian machine.\n\nThis patch replaces the __copy_{to,from}_user invocations in our\ncompat VFP signal handling code with explicit __put_user loops that\noperate on 64-bit values and swap them accordingly.\n\nCc: <stable@vger.kernel.org>\nReviewed-by: Catalin Marinas <catalin.marinas@arm.com>\nSigned-off-by: Will Deacon <will.deacon@arm.com>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/bdec97a855ef1e239f130f7a11584721c9a1bf04"},{"sha":"df057cc7b4fa59e9b55f07ffdb6c62bf02e99a00","author":{"email":"b913f13ef92ac157955c954ccaaff7be065faba4@arm.com","name":"Will Deacon"},"message":"arm64: errata: add module build workaround for erratum #843419\n\nCortex-A53 processors <= r0p4 are affected by erratum #843419 which can\nlead to a memory access using an incorrect address in certain sequences\nheaded by an ADRP instruction.\n\nThere is a linker fix to generate veneers for ADRP instructions, but\nthis doesn't work for kernel modules which are built as unlinked ELF\nobjects.\n\nThis patch adds a new config option for the erratum which, when enabled,\nbuilds kernel modules with the mcmodel=large flag. This uses absolute\naddressing for all kernel symbols, thereby removing the use of ADRP as\na PC-relative form of addressing. The ADRP relocs are removed from the\nmodule loader so that we fail to load any potentially affected modules.\n\nCc: <stable@vger.kernel.org>\nAcked-by: Catalin Marinas <catalin.marinas@arm.com>\nSigned-off-by: Will Deacon <will.deacon@arm.com>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/df057cc7b4fa59e9b55f07ffdb6c62bf02e99a00"},{"sha":"ad5001cc7cdf9aaee5eb213fdee657e4a3c94776","author":{"email":"707d14912bb250caf67dfe0ea4035681fbfc4f56@netfilter.org","name":"Pablo Neira Ayuso"},"message":"netfilter: nf_log: wait for rcu grace after logger unregistration\n\nThe nf_log_unregister() function needs to call synchronize_rcu() to make sure\nthat the objects are not dereferenced anymore on module removal.\n\nFixes: 5962815a6a56 (\"netfilter: nf_log: use an array of loggers instead of list\")\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/ad5001cc7cdf9aaee5eb213fdee657e4a3c94776"},{"sha":"88d64253785936d75323c74e7126d180e26de560","author":{"email":"52616596d8f5df0d597e85ab515377f92f939c68@de.ibm.com","name":"Martin Schwidefsky"},"message":"s390/hibernate: fix save and restore of vector registers\n\nThe swsusp_arch_suspend()/swsusp_arch_resume() functions currently only\nsave and restore the floating point registers. If the task that started\nthe hibernation process is using vector registers they can get lost.\nTo fix this just call save_fpu_regs in swsusp_arch_suspend(), the restore\nwill happen automatically on return to user space.\n\nReported-by: Heiko Carstens <heiko.carstens@de.ibm.com>\nSigned-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/88d64253785936d75323c74e7126d180e26de560"},{"sha":"9380cf5a884e237fc0e2571d5adf0b43bb4412c8","author":{"email":"8dcf0f69152f32f23184f83357a3731522e56b9c@de.ibm.com","name":"Heiko Carstens"},"message":"s390: fix floating point register corruption\n\nThe critical section cleanup code misses to add the offset of the\nthread_struct to the task address.\nTherefore, if the critical section code gets executed, it may corrupt\nthe task struct or restore the contents of the floating point registers\nfrom the wrong memory location.\nFixes d0164ee20d \"s390/kernel: remove save_fpu_regs() parameter and use\n__LC_CURRENT instead\".\n\nSigned-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>\nReviewed-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>\nSigned-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/9380cf5a884e237fc0e2571d5adf0b43bb4412c8"},{"sha":"8d4bd0ed0439dfc780aab801a085961925ed6838","author":{"email":"52616596d8f5df0d597e85ab515377f92f939c68@de.ibm.com","name":"Martin Schwidefsky"},"message":"s390/compat: correct uc_sigmask of the compat signal frame\n\nThe uc_sigmask in the ucontext structure is an array of words to keep\nthe 64 signal bits (or 1024 if you ask glibc but the kernel sigset_t\nonly has 64 bits).\n\nFor 64 bit the sigset_t contains a single 8 byte word, but for 31 bit\nthere are two 4 byte words. The compat signal handler code uses a\nsimple copy of the 64 bit sigset_t to the 31 bit compat_sigset_t.\nAs s390 is a big-endian architecture this is incorrect, the two words\nin the 31 bit sigset_t array need to be swapped.\n\nCc: <stable@vger.kernel.org>\nReported-by: Stefan Liebler <stli@linux.vnet.ibm.com>\nSigned-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/8d4bd0ed0439dfc780aab801a085961925ed6838"},{"sha":"58f8e9da33eb0104f5bee3e8b3ca44e1583c78b9","author":{"email":"ea0a2d16c17dd61debc108adbc0ac849646dd099@linux.vnet.ibm.com","name":"Hendrik Brueckner"},"message":"s390/cpum_cf: Corrected return code for unauthorized counter sets\n\nPreviously, the cpum_cf PMU returned -EPERM if a counter is requested and\nthe counter set to which the counter belongs is not authorized.  According\nto the perf_event_open() system call manual, an error code of EPERM indicates\nan unsupported exclude setting or CAP_SYS_ADMIN is missing.\n\nUse ENOENT to indicate that particular counters are not available when the\ncounter set which contains the counter is not authorized.  For generic events,\nthis might trigger a fall back, for example, to a software event.\n\nSigned-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>\nSigned-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/58f8e9da33eb0104f5bee3e8b3ca44e1583c78b9"},{"sha":"61cc37906b45534fcc2bea03c17e135ec010b624","author":{"email":"52616596d8f5df0d597e85ab515377f92f939c68@de.ibm.com","name":"Martin Schwidefsky"},"message":"s390/vtime: correct scaled cputime for SMT\n\nThe scaled cputime is supposed to be derived from the normal per-thread\ncputime by dividing it with the average thread density in the last interval.\n\nThe calculation of the scaling values for the average thread density is\nincorrect. The current, incorrect calculation:\n\n    Ci = cycle count with i active threads\n    T = unscaled cputime, sT = scaled cputime\n    sT = T * (C1 + C2 + ... + Cn) / (1*C1 + 2*C2 + ... + n*Cn)\n\nThe calculation happens to yield the correct numbers for the simple cases\nwith only one Ci value not zero. But for cases with multiple Ci values not\nzero it fails. E.g. on a SMT-2 system with one thread active half the time\nand two threads active for the other half of the time it fails, the scaling\nfactor should be 3/4 but the formula gives 2/3.\n\nThe correct formula is\n\n    sT = T * (C1/1 + C2/2 + ... + Cn/n) / (C1 + C2 + ... + Cn)\n\nSigned-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/61cc37906b45534fcc2bea03c17e135ec010b624"},{"sha":"022435713c0391020b55706c5b80fa1be44ba321","author":{"email":"8dcf0f69152f32f23184f83357a3731522e56b9c@de.ibm.com","name":"Heiko Carstens"},"message":"s390: wire up userfaultfd system call\n\nSigned-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>\nSigned-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/022435713c0391020b55706c5b80fa1be44ba321"},{"sha":"3dc636b2dafbf05b86decc2a55989c3261ffd116","author":{"email":"db4757c56f54651f568cc7cda79cd93c781b1605@linux.vnet.ibm.com","name":"Michael Holzheu"},"message":"s390/configs//zfcpdump_defconfig: Remove CONFIG_MEMSTICK\n\nThis config option is completely irrelevant for zfcpdump and\nunfortunately causes a kernel panic on recent kernels in\n\"mspro_block_init()/driver_register()\".\n\nSigned-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>\nSigned-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/3dc636b2dafbf05b86decc2a55989c3261ffd116"},{"sha":"96d4ee8aaa3cfbfadf137904f3696a9a84fab2d3","author":{"email":"007bef6a47fb57dff675bfa1b0b798b4bdfbfc25@efficios.com","name":"Mathieu Desnoyers"},"message":"s390/s390x: allocate sys_membarrier system call number\n\nSigned-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>\nCC: Andrew Morton <akpm@linux-foundation.org>\nCC: linux-api@vger.kernel.org\nCC: Heiko Carstens <heiko.carstens@de.ibm.com>\nCC: linux-s390@vger.kernel.org\nSigned-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/96d4ee8aaa3cfbfadf137904f3696a9a84fab2d3"},{"sha":"c4cbba9fa078f55d9f6d081dbb4aec7cf969e7c7","author":{"email":"a16cc0c82647c52d401177f8e50567df5499e36c@arm.com","name":"Marc Zyngier"},"message":"arm64: KVM: Disable virtual timer even if the guest is not using it\n\nWhen running a guest with the architected timer disabled (with QEMU and\nthe kernel_irqchip=off option, for example), it is important to make\nsure the timer gets turned off. Otherwise, the guest may try to\nenable it anyway, leading to a screaming HW interrupt.\n\nThe fix is to unconditionally turn off the virtual timer on guest\nexit.\n\nCc: stable@vger.kernel.org\nReviewed-by: Christoffer Dall <christoffer.dall@linaro.org>\nSigned-off-by: Marc Zyngier <marc.zyngier@arm.com>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/c4cbba9fa078f55d9f6d081dbb4aec7cf969e7c7"},{"sha":"688bc577ac42ae3d07c889a1f0a72f0b23763d58","author":{"email":"a16cc0c82647c52d401177f8e50567df5499e36c@arm.com","name":"Marc Zyngier"},"message":"arm: KVM: Disable virtual timer even if the guest is not using it\n\nWhen running a guest with the architected timer disabled (with QEMU and\nthe kernel_irqchip=off option, for example), it is important to make\nsure the timer gets turned off. Otherwise, the guest may try to\nenable it anyway, leading to a screaming HW interrupt.\n\nThe fix is to unconditionally turn off the virtual timer on guest\nexit.\n\nCc: stable@vger.kernel.org\nSigned-off-by: Marc Zyngier <marc.zyngier@arm.com>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/688bc577ac42ae3d07c889a1f0a72f0b23763d58"},{"sha":"34c3faa353db8f5d3ce9966cf854d5643c64c4db","author":{"email":"b913f13ef92ac157955c954ccaaff7be065faba4@arm.com","name":"Will Deacon"},"message":"arm64: KVM: Remove all traces of the ThumbEE registers\n\nAlthough the ThumbEE registers and traps were present in earlier\nversions of the v8 architecture, it was retrospectively removed and so\nwe can do the same.\n\nWhilst this breaks migrating a guest started on a previous version of\nthe kernel, it is much better to kill these (non existent) registers\nas soon as possible.\n\nReviewed-by: Marc Zyngier <marc.zyngier@arm.com>\nSigned-off-by: Will Deacon <will.deacon@arm.com>\n[maz: added commend about migration]\nSigned-off-by: Marc Zyngier <marc.zyngier@arm.com>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/34c3faa353db8f5d3ce9966cf854d5643c64c4db"},{"sha":"ef748917b529847277f07c98c55e1c0ce416449f","author":{"email":"8d0fc11caeb4659419f0ba3104eb4a9d30848d42@canonical.com","name":"Ming Lei"},"message":"arm/arm64: KVM: Remove 'config KVM_ARM_MAX_VCPUS'\n\nThis patch removes config option of KVM_ARM_MAX_VCPUS,\nand like other ARCHs, just choose the maximum allowed\nvalue from hardware, and follows the reasons:\n\n1) from distribution view, the option has to be\ndefined as the max allowed value because it need to\nmeet all kinds of virtulization applications and\nneed to support most of SoCs;\n\n2) using a bigger value doesn't introduce extra memory\nconsumption, and the help text in Kconfig isn't accurate\nbecause kvm_vpu structure isn't allocated until request\nof creating VCPU is sent from QEMU;\n\n3) the main effect is that the field of vcpus[] in 'struct kvm'\nbecomes a bit bigger(sizeof(void *) per vcpu) and need more cache\nlines to hold the structure, but 'struct kvm' is one generic struct,\nand it has worked well on other ARCHs already in this way. Also,\nthe world switch frequecy is often low, for example, it is ~2000\nwhen running kernel building load in VM from APM xgene KVM host,\nso the effect is very small, and the difference can't be observed\nin my test at all.\n\nCc: Dann Frazier <dann.frazier@canonical.com>\nSigned-off-by: Ming Lei <ming.lei@canonical.com>\nReviewed-by: Christoffer Dall <christoffer.dall@linaro.org>\nSigned-off-by: Marc Zyngier <marc.zyngier@arm.com>","distinct":false,"url":"https://api.github.com/repos/joergroedel/linux-iommu/commits/ef748917b529847277f07c98c55e1c0ce416449f"}]}