summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-05-24usb: roles: intel_xhci: Enable runtime PMHeikki Krogerus
This fixes an issue where the mux does not get configured when the parent device is suspended. The registers for this mux are mapped to the parent device MMIO (usually xHCI PCI device), so in order for the driver to be able to program the registers, the parent device must be resumed. Reported-by: Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@intel.com> Fixes: f6fb9ec02be1 ("usb: roles: Add Intel xHCI USB role switch driver") Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24usb: typec: fusb302: Fix debugfs issueHeikki Krogerus
Removing the "fusb302" debugfs directory when unloading the driver. That allows the driver to be loaded more then one time. The directory will not get actually removed until it is empty, so only after the last instance has been removed. This fixes an issue where the driver can't be re-loaded if it has been unloaded as the "fusb302" debugfs directory already exists. Fixes: 76f0c53d08b9 ("usb: typec: fusb302: Move out of staging") Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24platform: x86: intel_cht_int33fe: Fix dependenciesHeikki Krogerus
The driver will not probe unless bq24190 is loaded, so making it a dependency. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Darren Hart <dvhart@infradead.org> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24usb: roles: intel_xhci: Always allow user controlHeikki Krogerus
Trying to determine the USB port type with this mux is very difficult. To simplify the situation, always allow user control, even if the port is USB Type-C port. Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24drm/omap: fix NULL deref crash with SDI displaysTomi Valkeinen
Fix a NULL deref bug introduced in commit 24aac6011f70 ("drm: omapdrm: sdi: Allocate the sdi private data structure dynamically"). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/2f803bfc-3ffe-332a-7b9a-d59a39db4630@ti.com Fixes: 24aac6011f70 ("drm: omapdrm: sdi: Allocate the sdi private data structure dynamically") Reported-by: Tony Lindgren <tony@atomide.com> Tested-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Benoit Parrot <bparrot@ti.com>
2018-05-24usb: typec: Fix htmldocs warningHeikki Krogerus
Fix htmldocs warning: drivers/usb/typec/mux.c:186: warning: Function parameter or member 'mux' not described in 'typec_mux_unregister' Reported-by: kbuild test robot <lkp@intel.com> Fixes: bdecb33af34f ("usb: typec: API for controlling USB Type-C Multiplexers") Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24usbip: vhci_sysfs: fix potential Spectre v1Gustavo A. R. Silva
pdev_nr and rhport can be controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/usb/usbip/vhci_sysfs.c:238 detach_store() warn: potential spectre issue 'vhcis' drivers/usb/usbip/vhci_sysfs.c:328 attach_store() warn: potential spectre issue 'vhcis' drivers/usb/usbip/vhci_sysfs.c:338 attach_store() warn: potential spectre issue 'vhci->vhci_hcd_ss->vdev' drivers/usb/usbip/vhci_sysfs.c:340 attach_store() warn: potential spectre issue 'vhci->vhci_hcd_hs->vdev' Fix this by sanitizing pdev_nr and rhport before using them to index vhcis and vhci->vhci_hcd_ss->vdev respectively. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Shuah Khan (Samsung OSG) <shuah@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24usb: gadget: function: printer: avoid wrong list handling in printer_write()Yoshihiro Shimoda
When printer_write() calls usb_ep_queue(), a udc driver (e.g. renesas_usbhs driver) may call usb_gadget_giveback_request() in the udc .queue ops immediately. Then, printer_write() calls list_add(&req->list, &dev->tx_reqs_active) wrongly. After that, if we do unbind the printer driver, WARN_ON() happens in printer_func_unbind() because the list entry is not removed. So, this patch moves list_add(&req->list, &dev->tx_reqs_active) calling before usb_ep_queue(). Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24typec: tcpm: Provide fwnode pointer as part of psy_cfgAdam Thomson
For supply registration, provide fwnode pointer of the port device, via the power_supply_config structure, to allow other psy drivers to add us as a supplier. At present this only applies to DT based platforms using the 'power-supplies' DT property, but in the future should also work for ACPI platforms when the relevant support is added to the power_supply core. Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24power: supply: Add fwnode pointer to power_supply_config structAdam Thomson
To allow users of the power supply framework to be hw description agnostic, this commit adds the ability to pass a fwnode pointer, via the power_supply_config structure, to the initialisation code of the core, instead of explicitly specifying of_ndoe. If that fwnode pointer is provided then it will automatically resolve down to of_node on platforms which support it, otherwise it will be NULL. In the future, when ACPI support is added, this can be modified to accommodate ACPI without the need to change calling code which already provides the fwnode handle in this manner. Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24usb: mtu3: fix warning of sleep in atomic context in notifier callbackChunfeng Yun
The notifier callbacks of extcon are called in atomic context, but the callbacks will call regulator_enable()/regulator_disable() which may sleep caused by mutex, so use work queue to call the sleep functions. Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24usb: mtu3: reset gadget when VBUS_FALL interrupt arisesChunfeng Yun
When VBUS_FALL interrupt arises, it means U3 device is disconnected with host, so need reset status of gadget Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24usb: mtu3: avoid sleep in atomic context when enter test modeChunfeng Yun
Use readl_poll_timeout_atomic() instead of readl_poll_timeout() in atomic context Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24usb: mtu3: clear test_mode flag when resetChunfeng Yun
Clear test_mode flag when the gadget is reset by host, otherwise will affect the next test item. Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24usb: mtu3: fix uncontinuous SeqN issue after disable EPChunfeng Yun
Reset EP when disable it to reset data toggle for U2 EP, and SeqN, flow control status etc for U3 EP, this can avoid issue of uncontinuous SeqN Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24usb: mtu3: re-enable controller to accept LPM request after LPM resumeChunfeng Yun
After the controller receives a LPM request, it will reject the LPM request, and need software to re-enable it after LPM resume if the controller doesn't remote wakeup from L1 automatically Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24xhci: debugfs: add debugfs interface to enable compliance mode for a portMathias Nyman
Enable compliance transition for a port by writing "compliance" to the ports portsc file in debugfs. port must be "Not-connected" and Link must be in RxDetect state to enable compliance mode. Only needed for host that have CTC flag set. Allows state transitioning to compliance at 1st LFPS timeout. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24xhci: debugfs: add usb ports to xhci debugfsMathias Nyman
Add ports/portxx/portsc for each xHC hardware usb port to debugfs. Showing the content of the port status and control register for each port (PORTSC) Portxx is numbered starting from 1 for historical reasons to better match port numbering shown by lsusb and other places. Ports in debugfs are in the order XHC controller has them, In most cases USB2 ports come first, followed by USB3 ports. i.e. USB2 ports are port01-portxx, and USB3 portxx-portmax. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24xhci: xhci-mem: remove port_arrays and the code initializing themMathias Nyman
As we are now using the new port strtuctes the port_arrays are no longer needed, remove them completely Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24xhci-mtk: use xhci hub structures to get number of ports in roothubsMathias Nyman
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24xhci: xhci-hub: use port structure members instead of xhci_get_ports()Mathias Nyman
xhci_get_ports() is one of the last functions using port_arrays in xhci-hub.c. We get the same data directly from hub and port structures instead, so convert and remove both xhci_get_ports() and port_arrays from all function that no longer need it. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24xhci: use port structures instead of port arrays in xhci.c functionsMathias Nyman
get rid of port iomem arrays and use port structures in the following functions: xhci_find_raw_port_number() xhci_disable_port_wake_on_bits() xhci_set_usb2_hardware_lpm() xhci_all_ports_seen_u0() compliance_mode_recovery() Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24xhci: change xhci_test_and_clear_bit() to use new port structureMathias Nyman
Don't use pointers to port array and port index as function parameters in xhci_test_and_clear_bit(), just use a pointer to the right port structure. xhci_test_and_clear_bit() was the last port_array user in xhci_get_port_status() and handle_port_status(), so remove the port_array from them as well. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24xhci: change xhci_set_link_state() to work with port structuresMathias Nyman
Remove old iomem port array and index as parameters, just send a ponter to a port strucure instread Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24xhci: rename faked_port_index to hcd_portnumMathias Nyman
hcd_portnum is a better desctiption than faked_port_index, and is in line with the name the port structure uses. No functional changes Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24xhci: xhci-ring: use port structures for port event handlerMathias Nyman
use port structures in the port event handler. Getting the right hcd and hcd portnumber from the hardware port number is a lot easier with port structures, and allows us to remove a lot of the previous code, including the find_faked_portnum_from_hw_index() function Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24xhci: xhci-hub: use new port structures for cas and wake mask functions.Mathias Nyman
Use port structures instead of mmio port arrays for xhci_port_missing_cas_quirk() and xhci_set_remote_wake_mask() in xhci-hub.c Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24xhci: xhci-hub: use new port structures to get port address instead of port ↵Mathias Nyman
array Use the new port structures for functions in xhci-hub.c to get port mmio address of portsc register instead of the port array xhci_get_port_io_addr() is no longer needeed and is removed. Plan is to get rid of the mmio port array completely. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24xhci: Add helper to get xhci roothub from hcdMathias Nyman
quick way to get the xhci roothub and thus all the ports belonging to a certain hcd Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24xhci: set hcd pointers for xhci usb2 and usb3 roothub structuresMathias Nyman
Allows us to know the correct hcd a xhci roothub and its ports belong to. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24xhci: Create new structures to store xhci port informationMathias Nyman
Current way of having one array telling only the port speed, and then two separate arrays with mmio addresses for usb2 and usb3 ports requeres helper functions to transate hw to hcd, and hcd to hw port numbers, and is hard to expand. Instead create a structure describing a port, including the mmio address, the port hardware index, hcd port index, and a pointer to the roothub it belongs to. Create one array containing all port structures in the same order the hardware controller sees them. Then add an array of port pointers to each xhci hub structure pointing to the ports that belonging to the roothub. This way we can easily convert hw indexed port events to usb core hcd port numbers, and vice versa usb core hub hcd port numbers to hw index and mmio address. Other benefit is that we can easily find the parent hcd and xhci structure of a port structure. This is useful in debugfs where we can give one port structure pointer as parameter and get both the correct mmio address and xhci lock needed to set some port parameter. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24xhci: hisilicon: support HiSilicon STB xHCI host controllerJianguo Sun
This commit adds support for HiSilicon STB xHCI host controller. There are two xHCI host controllers on HiSilicon STB SoCs. Each one requires additional configuration before exposing interface compliant with xHCI. Reviewed-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by: Jianguo Sun <sunjianguo1@huawei.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24dt-bindings: usb: add bindings doc for HiSilicon STB xHCI host controllerJianguo Sun
This commit adds bindings doc for HiSilicon STB xHCI host controller. Signed-off-by: Jianguo Sun <sunjianguo1@huawei.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24usb: xhci: dbc: Add SPDX identifiers to dbc filesLu Baolu
Update the xhci dbc files with the correct SPDX license identifiers. Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Cc: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Philippe Ombredanne <pombredanne@nexB.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-05-24KVM: x86: Update cpuid properly when CR4.OSXAVE or CR4.PKE is changedWei Huang
The CPUID bits of OSXSAVE (function=0x1) and OSPKE (func=0x7, leaf=0x0) allows user apps to detect if OS has set CR4.OSXSAVE or CR4.PKE. KVM is supposed to update these CPUID bits when CR4 is updated. Current KVM code doesn't handle some special cases when updates come from emulator. Here is one example: Step 1: guest boots Step 2: guest OS enables XSAVE ==> CR4.OSXSAVE=1 and CPUID.OSXSAVE=1 Step 3: guest hot reboot ==> QEMU reset CR4 to 0, but CPUID.OSXAVE==1 Step 4: guest os checks CPUID.OSXAVE, detects 1, then executes xgetbv Step 4 above will cause an #UD and guest crash because guest OS hasn't turned on OSXAVE yet. This patch solves the problem by comparing the the old_cr4 with cr4. If the related bits have been changed, kvm_update_cpuid() needs to be called. Signed-off-by: Wei Huang <wei@redhat.com> Reviewed-by: Bandan Das <bsd@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2018-05-24Merge tag 'for-linus-20180524' of git://git.kernel.dk/linux-blockLinus Torvalds
Pull block fixes from Jens Axboe: "Two fixes that should go into this release: - a loop writeback error clearing fix from Jeff - the sr sense fix from myself" * tag 'for-linus-20180524' of git://git.kernel.dk/linux-block: loop: clear wb_err in bd_inode when detaching backing file sr: pass down correctly sized SCSI sense buffer
2018-05-24Merge tag 'pm-4.17-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fix from Rafael Wysocki: "Fix a regression from the 4.15 cycle that caused the system suspend and resume overhead to increase on many systems and triggered more serious problems on some of them (Rafael Wysocki)" * tag 'pm-4.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PM / core: Fix direct_complete handling for devices with no callbacks
2018-05-24Merge tag 'usb-for-v4.18' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next usb: changes for v4.18 merge window A total of 98 non-merge commits, the biggest part being in dwc3 this time around with a large refactoring of dwc3's transfer handling code. We also have a new driver for Aspeed virtual hub controller. Apart from that, just a list of miscellaneous fixes all over the place.
2018-05-24bpf: properly enforce index mask to prevent out-of-bounds speculationDaniel Borkmann
While reviewing the verifier code, I recently noticed that the following two program variants in relation to tail calls can be loaded. Variant 1: # bpftool p d x i 15 0: (15) if r1 == 0x0 goto pc+3 1: (18) r2 = map[id:5] 3: (05) goto pc+2 4: (18) r2 = map[id:6] 6: (b7) r3 = 7 7: (35) if r3 >= 0xa0 goto pc+2 8: (54) (u32) r3 &= (u32) 255 9: (85) call bpf_tail_call#12 10: (b7) r0 = 1 11: (95) exit # bpftool m s i 5 5: prog_array flags 0x0 key 4B value 4B max_entries 4 memlock 4096B # bpftool m s i 6 6: prog_array flags 0x0 key 4B value 4B max_entries 160 memlock 4096B Variant 2: # bpftool p d x i 20 0: (15) if r1 == 0x0 goto pc+3 1: (18) r2 = map[id:8] 3: (05) goto pc+2 4: (18) r2 = map[id:7] 6: (b7) r3 = 7 7: (35) if r3 >= 0x4 goto pc+2 8: (54) (u32) r3 &= (u32) 3 9: (85) call bpf_tail_call#12 10: (b7) r0 = 1 11: (95) exit # bpftool m s i 8 8: prog_array flags 0x0 key 4B value 4B max_entries 160 memlock 4096B # bpftool m s i 7 7: prog_array flags 0x0 key 4B value 4B max_entries 4 memlock 4096B In both cases the index masking inserted by the verifier in order to control out of bounds speculation from a CPU via b2157399cc98 ("bpf: prevent out-of-bounds speculation") seems to be incorrect in what it is enforcing. In the 1st variant, the mask is applied from the map with the significantly larger number of entries where we would allow to a certain degree out of bounds speculation for the smaller map, and in the 2nd variant where the mask is applied from the map with the smaller number of entries, we get buggy behavior since we truncate the index of the larger map. The original intent from commit b2157399cc98 is to reject such occasions where two or more different tail call maps are used in the same tail call helper invocation. However, the check on the BPF_MAP_PTR_POISON is never hit since we never poisoned the saved pointer in the first place! We do this explicitly for map lookups but in case of tail calls we basically used the tail call map in insn_aux_data that was processed in the most recent path which the verifier walked. Thus any prior path that stored a pointer in insn_aux_data at the helper location was always overridden. Fix it by moving the map pointer poison logic into a small helper that covers both BPF helpers with the same logic. After that in fixup_bpf_calls() the poison check is then hit for tail calls and the program rejected. Latter only happens in unprivileged case since this is the *only* occasion where a rewrite needs to happen, and where such rewrite is specific to the map (max_entries, index_mask). In the privileged case the rewrite is generic for the insn->imm / insn->code update so multiple maps from different paths can be handled just fine since all the remaining logic happens in the instruction processing itself. This is similar to the case of map lookups: in case there is a collision of maps in fixup_bpf_calls() we must skip the inlined rewrite since this will turn the generic instruction sequence into a non- generic one. Thus the patch_call_imm will simply update the insn->imm location where the bpf_map_lookup_elem() will later take care of the dispatch. Given we need this 'poison' state as a check, the information of whether a map is an unpriv_array gets lost, so enforcing it prior to that needs an additional state. In general this check is needed since there are some complex and tail call intensive BPF programs out there where LLVM tends to generate such code occasionally. We therefore convert the map_ptr rather into map_state to store all this w/o extra memory overhead, and the bit whether one of the maps involved in the collision was from an unpriv_array thus needs to be retained as well there. Fixes: b2157399cc98 ("bpf: prevent out-of-bounds speculation") Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-05-24x86/kvm: fix LAPIC timer drift when guest uses periodic modeDavid Vrabel
Since 4.10, commit 8003c9ae204e (KVM: LAPIC: add APIC Timer periodic/oneshot mode VMX preemption timer support), guests using periodic LAPIC timers (such as FreeBSD 8.4) would see their timers drift significantly over time. Differences in the underlying clocks and numerical errors means the periods of the two timers (hv and sw) are not the same. This difference will accumulate with every expiry resulting in a large error between the hv and sw timer. This means the sw timer may be running slow when compared to the hv timer. When the timer is switched from hv to sw, the now active sw timer will expire late. The guest VCPU is reentered and it switches to using the hv timer. This timer catches up, injecting multiple IRQs into the guest (of which the guest only sees one as it does not get to run until the hv timer has caught up) and thus the guest's timer rate is low (and becomes increasing slower over time as the sw timer lags further and further behind). I believe a similar problem would occur if the hv timer is the slower one, but I have not observed this. Fix this by synchronizing the deadlines for both timers to the same time source on every tick. This prevents the errors from accumulating. Fixes: 8003c9ae204e21204e49816c5ea629357e283b06 Cc: Wanpeng Li <wanpeng.li@hotmail.com> Signed-off-by: David Vrabel <david.vrabel@nutanix.com> Cc: stable@vger.kernel.org Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Wanpeng Li <wanpengli@tencent.com> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
2018-05-24Merge tag 'kvm-ppc-fixes-4.17-1' of ↵Radim Krčmář
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc Fixes for PPC KVM: - Close a hole which could possibly lead to the host timebase getting out of sync. - Three fixes relating to PTEs and TLB entries for radix guests. - Fix a bug which could lead to an interrupt never getting delivered to the guest, if it is pending for a guest vCPU when the vCPU gets offlined.
2018-05-24spi: sh-msiof: Fix setting SIRMDR1.SYNCAC to match SITMDR1.SYNCACGeert Uytterhoeven
According to section 59.2.4 MSIOF Receive Mode Register 1 (SIRMDR1) in the R-Car Gen3 datasheet Rev.1.00, the value of the SIRMDR1.SYNCAC bit must match the value of the SITMDR1.SYNCAC bit. However, sh_msiof_spi_setup() changes only the latter. Fix this by updating the SIRMDR1 register like the SITMDR1 register, taking into account register bits that exist in SITMDR1 only. Reported-by: Renesas BSP team via Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Fixes: 7ff0b53c4051145d ("spi: sh-msiof: Avoid writing to registers from spi_master.setup()") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-24ahci: Add PCI ID for Cannon Lake PCH-LP AHCIMika Westerberg
This one should be using the default LPM policy for mobile chipsets so add the PCI ID to the driver list of supported revices. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Tejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org
2018-05-24drm/psr: Fix missed entry in PSR setup time table.Dhinakaran Pandiyan
Entry corresponding to 220 us setup time was missing. I am not aware of any specific bug this fixes, but this could potentially result in enabling PSR on a panel with a higher setup time requirement than supported by the hardware. I verified the value is present in eDP spec versions 1.3, 1.4 and 1.4a. Fixes: 6608804b3d7f ("drm/dp: Add drm_dp_psr_setup_time()") Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jose Roberto de Souza <jose.souza@intel.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Tarun Vyas <tarun.vyas@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-3-dhinakaran.pandiyan@intel.com
2018-05-24MIPS: ptrace: Fix PTRACE_PEEKUSR requests for 64-bit FGRsMaciej W. Rozycki
Use 64-bit accesses for 64-bit floating-point general registers with PTRACE_PEEKUSR, removing the truncation of their upper halves in the FR=1 mode, caused by commit bbd426f542cb ("MIPS: Simplify FP context access"), which inadvertently switched them to using 32-bit accesses. The PTRACE_POKEUSR side is fine as it's never been broken and continues using 64-bit accesses. Fixes: bbd426f542cb ("MIPS: Simplify FP context access") Signed-off-by: Maciej W. Rozycki <macro@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # 3.15+ Patchwork: https://patchwork.linux-mips.org/patch/19334/ Signed-off-by: James Hogan <jhogan@kernel.org>
2018-05-24MIPS: prctl: Disallow FRE without FR with PR_SET_FP_MODE requestsMaciej W. Rozycki
Having PR_FP_MODE_FRE (i.e. Config5.FRE) set without PR_FP_MODE_FR (i.e. Status.FR) is not supported as the lone purpose of Config5.FRE is to emulate Status.FR=0 handling on FPU hardware that has Status.FR=1 hardwired[1][2]. Also we do not handle this case elsewhere, and assume throughout our code that TIF_HYBRID_FPREGS and TIF_32BIT_FPREGS cannot be set both at once for a task, leading to inconsistent behaviour if this does happen. Return unsuccessfully then from prctl(2) PR_SET_FP_MODE calls requesting PR_FP_MODE_FRE to be set with PR_FP_MODE_FR clear. This corresponds to modes allowed by `mips_set_personality_fp'. References: [1] "MIPS Architecture For Programmers, Vol. III: MIPS32 / microMIPS32 Privileged Resource Architecture", Imagination Technologies, Document Number: MD00090, Revision 6.02, July 10, 2015, Table 9.69 "Config5 Register Field Descriptions", p. 262 [2] "MIPS Architecture For Programmers, Volume III: MIPS64 / microMIPS64 Privileged Resource Architecture", Imagination Technologies, Document Number: MD00091, Revision 6.03, December 22, 2015, Table 9.72 "Config5 Register Field Descriptions", p. 288 Fixes: 9791554b45a2 ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS") Signed-off-by: Maciej W. Rozycki <macro@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # 4.0+ Patchwork: https://patchwork.linux-mips.org/patch/19327/ Signed-off-by: James Hogan <jhogan@kernel.org>
2018-05-24MIPS: lantiq: gphy: Drop reboot/remove reset assertsMathias Kresin
While doing a global software reset, these bits are not cleared and let some bootloader fail to initialise the GPHYs. The bootloader don't expect the GPHYs in reset, as they aren't during power on. The asserts were a workaround for a wrong syscon-reboot mask. With a mask set which includes the GPHY resets, these resets aren't required any more. Fixes: 126534141b45 ("MIPS: lantiq: Add a GPHY driver which uses the RCU syscon-mfd") Signed-off-by: Mathias Kresin <dev@kresin.me> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: Hauke Mehrtens <hauke@hauke-m.de> Cc: John Crispin <john@phrozen.org> Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # 4.14+ Patchwork: https://patchwork.linux-mips.org/patch/19003/ [jhogan@kernel.org: Fix build warnings] Signed-off-by: James Hogan <jhogan@kernel.org>
2018-05-24ARM: dts: stm32: Add exti support to stm32mp157 pinctrlLudovic Barre
This patch adds support of external interrupt for gpio[a..k], gpioz Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-05-24ARM: dts: stm32: Add exti support for stm32mp157cLudovic Barre
This patch adds external interrupt (exti) support on stm32mp157c SoC. Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-05-24pinctrl/stm32: Add irq_eoi for stm32gpio irqchipLudovic Barre
-Parent domain of stm32gpio evolves to hierarchy domain and could have a handle_fasteoi_irq. So an irq_eoi parent callback is needed for children. -Replace space by tabulation. Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
generated by cgit (git 2.34.1) at 2025-09-15 11:24:01 +0000