- 12 Jul, 2017 27 commits
-
-
Bjørn Mork authored
commit 996fab55 upstream. A new Sierra Wireless EM7305 device ID used in a Toshiba laptop. Reported-by:
Petr Kloc <petr_kloc@yahoo.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johan Hovold authored
commit 8fb060da upstream. Add two Longcheer device-id entries which specifically enables a Telewell TW-3G HSPA+ branded modem (0x9801). Reported-by:
Teemu Likonen <tlikonen@iki.fi> Reported-by:
Lars Melin <larsm17@gmail.com> Tested-by:
-
Geert Uytterhoeven authored
commit 3091ae77 upstream. Update the sh_pfc_soc_info pointer after calling the SoC-specific initialization function, as it may have been updated to e.g. handle different SoC revisions. This makes sure the correct subdriver name is printed later. Fixes: 0c151062 ("sh-pfc: Add support for SoC-specific initialization") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Sergei Shtylyov authored
commit da7a692f upstream. The R8A7791 PFC driver was apparently based on the preliminary revisions of the user's manual, which omitted the HSCIF1 group E signals in the IPSR4 register description. This would cause HSCIF1's probe to fail with the messages like below: sh-pfc e6060000.pfc: cannot locate data/mark enum_id for mark 1989 sh-sci e62c8000.serial: Error applying setting, reverse things back sh-sci: probe of e62c8000.serial failed with error -22 Add the neceassary PINMUX_IPSR_MSEL() invocations for the HSCK1_E, HCTS1#_E, and HRTS1#_E signals... Fixes: 50884519 ("pinctrl: sh-pfc: r8a7791 PFC support") Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
Uwe Kleine-König authored
commit da6c2add upstream. To set the mux mode of a pin two bits must be set. Up to now this is implemented using the following idiom: writel(mask, reg + CLR); writel(value, reg + SET); . This however results in the mux mode being 0 between the two writes. On my machine there is an IC's reset pin connected to LCD_D20. The bootloader configures this pin as GPIO output-high (i.e. not holding the IC in reset). When Linux reconfigures the pin to GPIO the short time LCD_D20 is muxed as LCD_D20 instead of GPIO_1_20 is enough to confuse the connected IC. The same problem is present for the pin's drive strength setting which is reset to low drive strength before using the right value. So instead of relying on the hardware to modify the register setting using two writes implement the bit toggling using read-modify-write. Fixes: 17723111 ("pinctrl: add pinctrl-mxs support") Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Tony Lindgren authored
commit 664b7c47 upstream. Andre Przywara <andre.przywara@arm.com> noticed that we can get the following warning with -EPROBE_DEFER: "WARNING: CPU: 1 PID: 89 at drivers/base/dd.c:349 driver_probe_device+0x2ac/0x2e8" Let's fix the issue by removing the indices as suggested by Tejun Heo <tj@kernel.org>. All we have to do here is kill the radix tree. I probably ended up with the indices after grepping for removal of all entries using radix_tree_for_each_slot() and the first match found was gmap_radix_tree_free(). Anyways, no need for indices here, and we can just do remove all the entries using radix_tree_for_each_slot() along how the item_kill_tree() test case does. Fixes: c7059c5a ("pinctrl: core: Add generic pinctrl functions for managing groups") Fixes: a76edc89 ("pinctrl: core: Add generic pinctrl functions for managing groups") Reported-by:
Andre Przywara <andre.przywara@arm.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Reviewed-by:
-
Chen-Yu Tsai authored
commit 7903d4f5 upstream. We use well known standard names for functions that have name, such as I2C, SPI, SPDIF, etc.. Fix the function name of SPDIF, which was named OWA (One Wire Audio) based on Allwinner datasheets. Fixes: 4730f33f ("pinctrl: sunxi: add allwinner A83T PIO controller support") Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Alexandre TORGUE authored
commit b7c747d4 upstream. In stm32_pconf_parse_conf function, stm32_pmx_gpio_set_direction is called with wrong parameter value. Indeed, using NULL value for range will raise an oops. Fixes: aceb16dc ("pinctrl: Add STM32 MCUs support") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Alexandre TORGUE <alexandre.torgue@st.com> Signed-off-by:
-
Martin Blumenstingl authored
commit 97ba26b8 upstream. The nand_groups table uses different names for the NAND DQS pins than the GROUP() definition in meson8b_cbus_groups (nand_dqs_0 vs nand_dqs0). This prevents using the NAND DQS pins in the devicetree. Fix this by ensuring that the GROUP() definition and the meson8b_cbus_groups use the same name for these pins. Fixes: 0fefcb68 ("pinctrl: Add support for Meson8b") Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
Geert Uytterhoeven authored
commit 4324b608 upstream. Fix typos in hscif2_clk_b_mux[] and hscif4_ctrl_mux[]. Fixes: a56069c4 ("pinctrl: sh-pfc: r8a7795: Add HSCIF pins, groups, and functions") Signed-off-by:
-
Sergei Shtylyov authored
commit 3908632f upstream. The R8A7791 PFC driver was apparently based on the preliminary revisions of the user's manual, which omitted the DVC_MUTE signal altogether in the PFC section. The modern manual has the signal described, so just add the necassary data to the driver... Fixes: 50884519 ("pinctrl: sh-pfc: r8a7791 PFC support") Signed-off-by:
-
Sergei Shtylyov authored
commit 58439280 upstream. PINMUX_IPSR_MSEL() macro invocation for the TX2 signal has apparently wrong 1st argument -- most probably a result of cut&paste programming... Fixes: 50884519 ("pinctrl: sh-pfc: r8a7791 PFC support") Signed-off-by:
-
Sergei Shtylyov authored
commit 5f4c8caf upstream. All R8A7794 manuals I have here (0.50 and 1.10) agree that the PFC driver has ATAG0# and ATAWR0# signals in IPSR12 swapped -- fix this. Fixes: 43c4436e ("pinctrl: sh-pfc: add R8A7794 PFC support") Signed-off-by:
-
Juri Lelli authored
commit f70b281b upstream. The sysfs cpu_capacity entry for each CPU has nothing to do with PROC_FS, nor it's in /proc/sys path. Remove such ifdef. Cc: Russell King <linux@arm.linux.org.uk> Reported-and-suggested-by:
Sudeep Holla <sudeep.holla@arm.com> Fixes: 7e5930aa ('ARM: 8622/3: add sysfs cpu_capacity attribute') Signed-off-by:
Juri Lelli <juri.lelli@arm.com> Acked-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Johan Hovold authored
commit e271b2c9 upstream. Make sure to release any OF device-node reference taken when creating the USB device. Note that we currently do not hold a reference to the root hub device-tree node (i.e. the parent controller node). Fixes: 69bec725 ("USB: core: let USB device know device node") Acked-by:
Peter Chen <peter.chen@nxp.com> Signed-off-by:
-
Benjamin Herrenschmidt authored
commit 7cf916bd upstream. The current definition is wrong. This breaks my upcoming Aspeed virtual hub driver. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Michael Grzeschik authored
commit b3b51417 upstream. The usbip stack dynamically allocates the transfer_buffer and setup_packet of each urb that got generated by the tcp to usb stub code. As these pointers are always used only once we will set them to NULL after use. This is done likewise to the free_urb code in vudc_dev.c. This patch fixes double kfree situations where the usbip remote side added the URB_FREE_BUFFER. Signed-off-by:
Michael Grzeschik <m.grzeschik@pengutronix.de> Acked-by:
Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
-
Devin Heitmueller authored
commit 6836796d upstream. The USB core and sysfs will attempt to enumerate certain parameters which are unsupported by the au0828 - causing inconsistent behavior and sometimes causing the chip to reset. Avoid making these calls. This problem manifested as intermittent cases where the au8522 would be reset on analog video startup, in particular when starting up ALSA audio streaming in parallel - the sysfs entries created by snd-usb-audio on streaming startup would result in unsupported control messages being sent during tuning which would put the chip into an unknown state. Signed-off-by:
Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by:
-
Jeremie Rapin authored
commit fd90f73a upstream. Added the USB serial device ID for the CEL ZigBee EM3588 radio stick. Signed-off-by:
Jeremie Rapin <rapinj@gmail.com> Acked-by:
-
Felipe Balbi authored
commit 04fb365c upstream. %p will leak kernel pointers, so let's not expose the information on dmesg and instead use %pK. %pK will only show the actual addresses if explicitly enabled under /proc/sys/kernel/kptr_restrict. Acked-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Gerd Hoffmann authored
commit 385aee96 upstream. Reported-by:
李强 <liqiang6-s@360.cn> Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170406155941.458-1-kraxel@redhat.comSigned-off-by:
-
Sabrina Dubroca authored
commit 9e52b325 upstream. Always try to parse an address, since kstrtoul() will safely fail when given a symbol as input. If that fails (which will be the case for a symbol), try to parse a symbol instead. This allows creating a probe such as: p:probe/vlan_gro_receive 8021q:vlan_gro_receive+0 Which is necessary for this command to work: perf probe -m 8021q -a vlan_gro_receive Link: http://lkml.kernel.org/r/fd72d666f45b114e2c5b9cf7e27b91de1ec966f1.1498122881.git.sd@queasysnail.net Fixes: 413d37d1 ("tracing: Add kprobe-based event tracer") Acked-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Yan, Zheng authored
commit b50c2de5 upstream. The dirfragtree is lazily updated, it's not always accurate. Infinite loops happens in following circumstance. - client send request to read frag A - frag A has been fragmented into frag B and C. So mds fills the reply with contents of frag B - client wants to read next frag C. ceph_choose_frag(frag value of C) return frag A. The fix is using previous readdir reply to calculate next readdir frag when possible. Signed-off-by:
"Yan, Zheng" <zyan@redhat.com> Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Boris Pismenny authored
commit 5ecce4c9 upstream. The ib_uverbs_create_ah() ind ib_uverbs_modify_qp() calls receive the port number from user input as part of its attributes and assumes it is valid. Down on the stack, that parameter is used to access kernel data structures. If the value is invalid, the kernel accesses memory it should not. To prevent this, verify the port number before using it. BUG: KASAN: use-after-free in ib_uverbs_create_ah+0x6d5/0x7b0 Read of size 4 at addr ffff880018d67ab8 by task syz-executor/313 BUG: KASAN: slab-out-of-bounds in modify_qp.isra.4+0x19d0/0x1ef0 Read of size 4 at addr ffff88006c40ec58 by task syz-executor/819 Fixes: 67cdb40c ("[IB] uverbs: Implement more commands") Fixes: 189aba99 ("IB/uverbs: Extend modify_qp and support packet pacing") Cc: Yevgeny Kliteynik <kliteyn@mellanox.com> Cc: Tziporet Koren <tziporet@mellanox.com> Cc: Alex Polak <alexpo@mellanox.com> Signed-off-by:
Boris Pismenny <borisp@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Adrian Salido authored
commit 62655397 upstream. The driver_override implementation is susceptible to race condition when different threads are reading vs storing a different driver override. Add locking to avoid race condition. Fixes: 3d713e0e ("driver core: platform: add device binding path 'driver_override'") Cc: stable@vger.kernel.org Signed-off-by:
Adrian Salido <salidoa@google.com> Signed-off-by:
-
Christoph Hellwig authored
commit 629e014b upstream. Currently we just stash anything we got into file->f_flags, and the report it in fcntl(F_GETFD). This patch just clears out all unknown flags so that we don't pass them to the fs or report them. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Christoph Hellwig authored
commit 80f18379 upstream. Add a central define for all valid open flags, and use it in the uniqueness check. Signed-off-by:
-
- 05 Jul, 2017 13 commits
-
-
Greg Kroah-Hartman authored
-
David S. Miller authored
commit ed66e50d upstream. > ../drivers/hsi/clients/ssi_protocol.c:1069:5: error: 'struct net_device' has no member named 'destructor' Reported-by:
Mark Brown <broonie@kernel.org> Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Steffen Klassert authored
[ Upstream commit 0e78a873 ] Locally generated TCP packets are usually cloned, so we do skb_cow_data() on this packets. After that we need to reload the pointer to the esp header. On udpencap this header has an offset to skb_transport_header, so take this offset into account. This is a backport of: commit 0e78a873 ("esp4: Fix udpencap for local TCP packets.") Fixes: 67d349ed ("net/esp4: Fix invalid esph pointer crash") Fixes: fca11ebd ("esp4: Reorganize esp_output") Reported-by:
Don Bowman <db@donbowman.ca> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Wanpeng Li authored
commit d4912215 upstream. WARNING: CPU: 3 PID: 2840 at arch/x86/kvm/vmx.c:10966 nested_vmx_vmexit+0xdcd/0xde0 [kvm_intel] CPU: 3 PID: 2840 Comm: qemu-system-x86 Tainted: G OE 4.12.0-rc3+ #23 RIP: 0010:nested_vmx_vmexit+0xdcd/0xde0 [kvm_intel] Call Trace: ? kvm_check_async_pf_completion+0xef/0x120 [kvm] ? rcu_read_lock_sched_held+0x79/0x80 vmx_queue_exception+0x104/0x160 [kvm_intel] ? vmx_queue_exception+0x104/0x160 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x1171/0x1ce0 [kvm] ? kvm_arch_vcpu_load+0x47/0x240 [kvm] ? kvm_arch_vcpu_load+0x62/0x240 [kvm] kvm_vcpu_ioctl+0x384/0x7b0 [kvm] ? kvm_vcpu_ioctl+0x384/0x7b0 [kvm] ? __fget+0xf3/0x210 do_vfs_ioctl+0xa4/0x700 ? __fget+0x114/0x210 SyS_ioctl+0x79/0x90 do_syscall_64+0x81/0x220 entry_SYSCALL64_slow_path+0x25/0x25 This is triggered occasionally by running both win7 and win2016 in L2, in addition, EPT is disabled on both L1 and L2. It can't be reproduced easily. Commit 0b6ac343 (KVM: nVMX: Correct handling of exception injection) mentioned that "KVM wants to inject page-faults which it got to the guest. This function assumes it is called with the exit reason in vmcs02 being a #PF exception". Commit e011c663 (KVM: nVMX: Check all exceptions for intercept during delivery to L2) allows to check all exceptions for intercept during delivery to L2. However, there is no guarantee the exit reason is exception currently, when there is an external interrupt occurred on host, maybe a time interrupt for host which should not be injected to guest, and somewhere queues an exception, then the function nested_vmx_check_exception() will be called and the vmexit emulation codes will try to emulate the "Acknowledge interrupt on exit" behavior, the warning is triggered. Reusing the exit reason from the L2->L0 vmexit is wrong in this case, the reason must always be EXCEPTION_NMI when injecting an exception into L1 as a nested vmexit. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
Wanpeng Li <wanpeng.li@hotmail.com> Fixes: e011c663 ("KVM: nVMX: Check all exceptions for intercept during delivery to L2") Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
-
Radim Krčmář authored
commit f0367ee1 upstream. Static checker noticed that base3 could be used uninitialized if the segment was not present (useable). Random stack values probably would not pass VMCS entry checks. Reported-by:
Paolo Bonzini <pbonzini@redhat.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Signed-off-by:
-
Radim Krčmář authored
commit 34b0dadb upstream. Static analysis noticed that pmu->nr_arch_gp_counters can be 32 (INTEL_PMC_MAX_GENERIC) and therefore cannot be used to shift 'int'. I didn't add BUILD_BUG_ON for it as we have a better checker. Reported-by:
-
Ladi Prosek authored
commit 6ed071f0 upstream. On AMD, the effect of set_nmi_mask called by emulate_iret_real and em_rsm on hflags is reverted later on in x86_emulate_instruction where hflags are overwritten with ctxt->emul_flags (the kvm_set_hflags call). This manifests as a hang when rebooting Windows VMs with QEMU, OVMF, and >1 vcpu. Instead of trying to merge ctxt->emul_flags into vcpu->arch.hflags after an instruction is emulated, this commit deletes emul_flags altogether and makes the emulator access vcpu->arch.hflags using two new accessors. This way all changes, on the emulator side as well as in functions called from the emulator and accessing vcpu state with emul_to_vcpu, are preserved. More details on the bug and its manifestation with Windows and OVMF: It's a KVM bug in the interaction between SMI/SMM and NMI, specific to AMD. I believe that the SMM part explains why we started seeing this only with OVMF. KVM masks and unmasks NMI when entering and leaving SMM. When KVM emulates the RSM instruction in em_rsm, the set_nmi_mask call doesn't stick because later on in x86_emulate_instruction we overwrite arch.hflags with ctxt->emul_flags, effectively reverting the effect of the set_nmi_mask call. The AMD-specific hflag of interest here is HF_NMI_MASK. When rebooting the system, Windows sends an NMI IPI to all but the current cpu to shut them down. Only after all of them are parked in HLT will the initiating cpu finish the restart. If NMI is masked, other cpus never get the memo and the initiating cpu spins forever, waiting for hal!HalpInterruptProcessorsStarted to drop. That's the symptom we observe. Fixes: a584539b ("KVM: x86: pass the whole hflags field to emulator and back") Signed-off-by:
Ladi Prosek <lprosek@redhat.com> Signed-off-by:
-
Thomas Petazzoni authored
commit ee56874f upstream. In commit eea62819 ("mtd: Add device-tree support to fsmc_nand"), Device Tree support was added to the fmsc_nand driver. However, this code has a bug in how it handles the bank-width DT property to set the bus width. Indeed, in the function fsmc_nand_probe_config_dt() that parses the Device Tree, it sets pdata->width to either 8 or 16 depending on the value of the bank-width DT property. Then, the ->probe() function will test if pdata->width is equal to FSMC_NAND_BW16 (which is 2) to set NAND_BUSWIDTH_16 in nand->options. Therefore, with the DT probing, this condition will never match. This commit fixes that by removing the "width" field from fsmc_nand_platform_data and instead have the fsmc_nand_probe_config_dt() function directly set the appropriate nand->options value. It is worth mentioning that if this commit gets backported to older kernels, prior to the drop of non-DT probing, then non-DT probing will be broken because nand->options will no longer be set to NAND_BUSWIDTH_16. Fixes: eea62819 ("mtd: Add device-tree support to fsmc_nand") Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
-
Kamal Dasu authored
commit 9d2ee0a6 upstream. On brcmnand controller v6.x and v7.x, the #WP pin is controlled through the NAND_WP bit in CS_SELECT register. The driver currently assumes that toggling the #WP pin is instantaneously enabling/disabling write-protection, but it actually takes some time to propagate the new state to the internal NAND chip logic. This behavior is sometime causing data corruptions when an erase/program operation is executed before write-protection has really been disabled. Fixes: 27c5b17c ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller") Signed-off-by:
Kamal Dasu <kdasu.kdev@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
commit 5b0ff9a0 upstream. hns_roce_v1_cq_set_ci() calls roce_set_bit() on an uninitialized field, which will then change only a few of its bits, causing a warning with the latest gcc: infiniband/hw/hns/hns_roce_hw_v1.c: In function 'hns_roce_v1_cq_set_ci': infiniband/hw/hns/hns_roce_hw_v1.c:1854:23: error: 'doorbell[1]' is used uninitialized in this function [-Werror=uninitialized] roce_set_bit(doorbell[1], ROCEE_DB_OTHERS_H_ROCEE_DB_OTH_HW_SYNS_S, 1); The code is actually correct since we always set all bits of the port_vlan field, but gcc correctly points out that the first access does contain uninitialized data. This initializes the field to zero first before setting the individual bits. Fixes: 9a443537 ("IB/hns: Add driver files for hns RoCE driver") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Suravee Suthikulpanit authored
commit 84a21dbd upstream. Pass-through devices to VM guest can get updated IRQ affinity information via irq_set_affinity() when not running in guest mode. Currently, AMD IOMMU driver in GA mode ignores the updated information if the pass-through device is setup to use vAPIC regardless of guest_mode. This could cause invalid interrupt remapping. Also, the guest_mode bit should be set and cleared only when SVM updates posted-interrupt interrupt remapping information. Signed-off-by:
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Cc: Joerg Roedel <jroedel@suse.de> Fixes: d98de49a ('iommu/amd: Enable vAPIC interrupt remapping mode by default') Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Pan Bian authored
commit 73dbd4a4 upstream. In function amd_iommu_bind_pasid(), the control flow jumps to label out_free when pasid_state->mm and mm is NULL. And mmput(mm) is called. In function mmput(mm), mm is referenced without validation. This will result in a NULL dereference bug. This patch fixes the bug. Signed-off-by:
Pan Bian <bianpan2016@163.com> Fixes: f0aac63b ('iommu/amd: Don't hold a reference to mm_struct') Signed-off-by:
-
Robin Murphy authored
commit 938f1bbe upstream. Even if a host controller's CPU-side MMIO windows into PCI I/O space do happen to leak into PCI memory space such that it might treat them as peer addresses, trying to reserve the corresponding I/O space addresses doesn't do anything to help solve that problem. Stop doing a silly thing. Fixes: fade1ec0 ("iommu/dma: Avoid PCI host bridge windows") Reviewed-by:
Eric Auger <eric.auger@redhat.com> Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
