summaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
* iio: fix center temperature of bmc150-accel-corePascal Bouwmann2019-11-061-1/+1
| | | | | | | | | | | | | | | [ Upstream commit 6c59a962e081df6d8fe43325bbfabec57e0d4751 ] The center temperature of the supported devices stored in the constant BMC150_ACCEL_TEMP_CENTER_VAL is not 24 degrees but 23 degrees. It seems that some datasheets were inconsistent on this value leading to the error. For most usecases will only make minor difference so not queued for stable. Signed-off-by: Pascal Bouwmann <bouwmann@tau-tec.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* iio: adc: meson_saradc: Fix memory allocation orderRemi Pommarel2019-11-061-5/+5
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit de10ac47597e7a3596b27631d0d5ce5f48d2c099 ] meson_saradc's irq handler uses priv->regmap so make sure that it is allocated before the irq get enabled. This also fixes crash when CONFIG_DEBUG_SHIRQ is enabled, as device managed resources are freed in the inverted order they had been allocated, priv->regmap was freed before the spurious fake irq that CONFIG_DEBUG_SHIRQ adds called the handler. Fixes: 3af109131b7eb8 ("iio: adc: meson-saradc: switch from polling to interrupt mode") Reported-by: Elie Roudninski <xademax@gmail.com> Signed-off-by: Remi Pommarel <repk@triplefau.lt> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Tested-by: Elie ROUDNINSKI <xademax@gmail.com> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* power: supply: max14656: fix potential use-after-freeSven Van Asbroeck2019-11-061-2/+15
| | | | | | | | | | | | | | | | | | [ Upstream commit 252fbeb86ceffa549af9842cefca2412d53a7653 ] Explicitly cancel/sync the irq_work delayed work, otherwise there's a chance that it will run after the device is removed, which would result in a use-after-free. Note that cancel/sync should happen: - after irq's have been disabled, as the isr re-schedules the work - before the power supply is unregistered, because the work func uses the power supply handle. Cc: Alexander Kurz <akurz@blala.de> Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/amd/display: fix odm combine pipe resetDmytro Laktyushkin2019-11-061-4/+2
| | | | | | | | | | | | | [ Upstream commit f25f06b67ba237b76092a6fc522b1a94e84bfa85 ] We fail to reset the second odm combine pipe. This change fixes odm pointer management. Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* PCI/PME: Fix possible use-after-free on removeSven Van Asbroeck2019-11-061-0/+1
| | | | | | | | | | | | | | | | | | [ Upstream commit 7cf58b79b3072029af127ae865ffc6f00f34b1f8 ] In remove(), ensure that the PME work cannot run after kfree() is called. Otherwise, this could result in a use-after-free. This issue was detected with the help of Coccinelle. Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Sinan Kaya <okaya@kernel.org> Cc: Frederick Lawler <fred@fredlawl.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Keith Busch <keith.busch@intel.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* net: dsa: mv88e6xxx: Release lock while requesting IRQAndrew Lunn2019-11-061-0/+2
| | | | | | | | | | | | | [ Upstream commit 342a0ee70acbee97fdeb91349420f8744eb291fb ] There is no need to hold the register lock while requesting the GPIO interrupt. By not holding it we can also avoid a false positive lockdep splat. Reported-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
* media: vimc: Remove unused but set variablesLucas A. M. Magalhães2019-11-061-7/+0
| | | | | | | | | | | | [ Upstream commit 5515e414f42bf2769caae15b634004d456658284 ] Remove unused but set variables to clean up the code and avoid warning. Signed-off-by: Lucas A. M. Magalhães <lucmaga@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* scsi: lpfc: Correct localport timeout duration errorJames Smart2019-11-062-1/+7
| | | | | | | | | | | | | | | | [ Upstream commit 2a0fb340fcc816975b8b0f2fef913d11999c39cf ] Current code incorrectly specifies a completion wait timeout duration in 5 jiffies, when it should have been 5 seconds. Fix the adjust for units for the completion timeout call. [mkp: manual merge] Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* mlxsw: spectrum: Set LAG port collector only when activeNir Dotan2019-11-061-17/+45
| | | | | | | | | | | | | | | | [ Upstream commit 48ebab31d424fbdb8ede8914923bec671a933246 ] The LAG port collecting (receive) function was mistakenly set when the port was registered as a LAG member, while it should be set only when the port collection state is set to true. Set LAG port to collecting when it is set to distributing, as described in the IEEE link aggregation standard coupled control mux machine state diagram. Signed-off-by: Nir Dotan <nird@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
* rtc: pcf8523: set xtal load capacitance from DTSam Ravnborg2019-11-061-8/+20
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit 189927e719e36ceefbb8037f23d3849e47833aef ] Add support for specifying the xtal load capacitance in the DT node. The pcf8523 supports xtal load capacitance of 7pF or 12.5pF. If the rtc has the wrong configuration the time will drift several hours/week. The driver use the default value 12.5pF. The DT may specify either 7000fF or 12500fF. (The DT uses femto Farad to avoid decimal numbers). Other values are warned and the driver uses the default value. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* usb: handle warm-reset port requests on hub resumeJan-Marek Glogowski2019-11-061-0/+7
| | | | | | | | | | | | | | | | | | | [ Upstream commit 4fdc1790e6a9ef22399c6bc6e63b80f4609f3b7e ] On plug-in of my USB-C device, its USB_SS_PORT_LS_SS_INACTIVE link state bit is set. Greping all the kernel for this bit shows that the port status requests a warm-reset this way. This just happens, if its the only device on the root hub, the hub therefore resumes and the HCDs status_urb isn't yet available. If a warm-reset request is detected, this sets the hubs event_bits, which will prevent any auto-suspend and allows the hubs workqueue to warm-reset the port later in port_event. Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* usb: dwc3: gadget: clear DWC3_EP_TRANSFER_STARTED on cmd completeFelipe Balbi2019-11-061-14/+5
| | | | | | | | | | | | | | [ Upstream commit acbfa6c26f21a18830ee064b588c92334305b6af ] We must wait until End Transfer completes in order to clear DWC3_EP_TRANSFER_STARTED, otherwise we may confuse the driver. This patch is in preparation to fix a rare race condition that happens upon Disconnect Interrupt. Tested-by: Thinh Nguyen <thinhn@synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* usb: dwc3: gadget: early giveback if End Transfer already completedFelipe Balbi2019-11-061-1/+5
| | | | | | | | | | | | | | | | | [ Upstream commit 9f45581f5eec6786c6eded2b3c85345d82a910c9 ] There is a rare race condition that may happen during a Disconnect Interrupt if we have a started request that happens to be dequeued *after* completion of End Transfer command. If that happens, that request will be left waiting for completion of an End Transfer command that will never happen. If End Transfer command has already completed before, we are safe to giveback the request straight away. Tested-by: Thinh Nguyen <thinhn@synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* HID: steam: fix deadlock with input devices.Rodrigo Rivas Costa2019-11-061-7/+19
| | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 6b538cc21334b83f09b25dec4aa2d2726bf07ed0 ] When using this driver with the wireless dongle and some usermode program that monitors every input device (acpid, for example), while another usermode client opens and closes the low-level device repeadedly, the system eventually deadlocks. The reason is that steam_input_register_device() must not be called with the mutex held, because the input subsystem has its own synchronization that clashes with this one: it is possible that steam_input_open() is called before input_register_device() returns, and since steam_input_open() needs to lock the mutex, it deadlocks. However we must hold the mutex when calling any function that sends commands to the controller. If not, random commands end up falling fail. Reported-by: Simon Gene Gottlieb <simon@gottliebtfreitag.de> Signed-off-by: Rodrigo Rivas Costa <rodrigorivascosta@gmail.com> Tested-by: Simon Gene Gottlieb <simon@gottliebtfreitag.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
* HID: steam: fix boot loop with bluetooth firmwareRodrigo Rivas Costa2019-11-061-23/+11
| | | | | | | | | | | | | | | [ Upstream commit cf28aee292e102740e49f74385b4b89c00050763 ] There is a new firmware for the Steam Controller with support for BLE connections. When using such a device with a wired connection, it reboots itself every 10 seconds unless an application has opened it. Doing hid_hw_open() unconditionally on probe fixes the issue, and the code becomes simpler. Signed-off-by: Rodrigo Rivas Costa <rodrigorivascosta@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
* HID: Add ASUS T100CHI keyboard dock battery quirksNOGUCHI Hiroshi2019-11-061-0/+3
| | | | | | | | | | | [ Upstream commit a767ffea05d2737f6542cd78458a84a157fa216d ] Add ASUS Transbook T100CHI/T90CHI keyboard dock into battery quirk list, in order to add specific implementation in hid-asus. Signed-off-by: NOGUCHI Hiroshi <drvlabo@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
* staging: mt7621-pinctrl: use pinconf-generic for 'dt_node_to_map' and ↵Sergio Paracuellos2019-11-062-38/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'dt_free_map' [ Upstream commit 0ca1f90861b6d64386261096b42bfc81ce11948a ] Instead of reimplement afunction to do 'dt_node_to_map' task like 'rt2880_pinctrl_dt_node_to_map' make use of 'pinconf_generic_dt_node_to_map_all' generic function for this task. Also use its equivalent function for free which is 'pinconf_generic_dt_free_map'. Remove 'rt2880_pinctrl_dt_node_to_map' function which is not needed anymore. This decrease a bit driver LOC and make it more generic. To properly compile this changes 'GENERIC_PINCONF' option is selected with the driver in its Kconfig file. This also fix a problem with function 'rt2880_pinctrl_dt_node_to_map' which was calling internally 'pinctrl_utils_reserve_map' which expects 'num_maps' to be initialized. It does a memory allocation based on the value, and triggers the following warning if is not properly set: if (unlikely(order >= MAX_ORDER)) { WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN)); return NULL; } Generic function 'pinconf_generic_dt_node_to_map_all' initializes properly 'num_maps' to zero fixing the problem. Fixes: e12a1a6e087b ("staging: mt7621-pinctrl: refactor rt2880_pinctrl_dt_node_to_map function") Reported-by: NeilBrown <neil@brown.name> Tested-by: NeilBrown <neil@brown.name> Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* clk: boston: unregister clks on failure in clk_boston_setup()Yi Wang2019-11-061-5/+13
| | | | | | | | | | | [ Upstream commit 8b627f616ed63dcaf922369fc14a5daf8ad03038 ] The registered clks should unregister when something wrong happens before going out in function clk_boston_setup(). Signed-off-by: Yi Wang <wang.yi59@zte.com.cn> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* ath10k: assign 'n_cipher_suites = 11' for WCN3990 to enable WPA3Abhishek Ambure2019-11-061-1/+1
| | | | | | | | | | | | | | | | | | [ Upstream commit 7ba31e6e0cdc0cc2e60e1fcbf467f3c95aea948e ] Hostapd uses CCMP, GCMP & GCMP-256 as 'wpa_pairwise' option to run WPA3. In WCN3990 firmware cipher suite numbers 9 to 11 are for CCMP, GCMP & GCMP-256. To enable CCMP, GCMP & GCMP-256 cipher suites in WCN3990 firmware, host sets 'n_cipher_suites = 11' while initializing hardware parameters. Tested HW: WCN3990 Tested FW: WLAN.HL.2.0-01188-QCAHLSWMTPLZ-1 Signed-off-by: Abhishek Ambure <aambure@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* platform/x86: Fix config space access for intel_atomisp2_pmVille Syrjälä2019-11-061-20/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 6a31061833a52a79c99221b6251db08cf377470e ] We lose even config space access when we power gate the ISP via the PUNIT. That makes lspci & co. produce gibberish. To fix that let's try to implement actual runtime pm hooks and inform the pci core that the device always goes to D3cold. That will cause the pci core to resume the device before attempting config space access. This introduces another annoyance though. We get the following error every time we try to resume the device: intel_atomisp2_pm 0000:00:03.0: Refused to change power state, currently in D3 The reason being that the pci core tries to put the device back into D0 via the standard PCI PM mechanism before calling the driver resume hook. To fix this properly we'd need to infiltrate the platform pm hooks (could turn ugly real fast), or use pm domains (which don't seem to exist on x86), or some extra early resume hook for the driver (which doesn't exist either). So maybe we just choose to live with the error? Cc: Hans de Goede <hdegoede@redhat.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Darren Hart <dvhart@infradead.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* platform/x86: Add the VLV ISP PCI ID to atomisp2_pmVille Syrjälä2019-11-061-0/+1
| | | | | | | | | | | | | | | | | [ Upstream commit 8a7d7141528ad67e465bc6afacc6a3144d1fe320 ] If the ISP is exposed as a PCI device VLV machines need the same treatment as CHV machines to power gate the ISP. Otherwise s0ix will not work. Cc: Hans de Goede <hdegoede@redhat.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Darren Hart <dvhart@infradead.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* HID: i2c-hid: Add Odys Winbook 13 to descriptor overrideHans de Goede2019-11-061-0/+8
| | | | | | | | | | | | | | [ Upstream commit f8f807441eefddc3c6d8a378421f0ede6361d565 ] The Odys Winbook 13 uses a SIPODEV SP1064 touchpad, which does not supply descriptors, add this to the DMI descriptor override list, fixing the touchpad not working. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1526312 Reported-by: Rene Wagner <redhatbugzilla@callerid.de> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
* HID: i2c-hid: Ignore input report if there's no data present on Elan touchpanelsKai-Heng Feng2019-11-061-0/+9
| | | | | | | | | | | | | | | | | | [ Upstream commit 1475af255e18f35dc46f8a7acc18354c73d45149 ] While using Elan touchpads, the message floods: [ 136.138487] i2c_hid i2c-DELL08D6:00: i2c_hid_get_input: incomplete report (14/65535) Though the message flood is annoying, the device it self works without any issue. I suspect that the device in question takes too much time to pull the IRQ back to high after I2C host has done reading its data. Since the host receives all useful data, let's ignore the input report when there's no data. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* HID: i2c-hid: Disable runtime PM for LG touchscreenKai-Heng Feng2019-11-062-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 86c31524b27c7e686841dd4a79eda95cfd989f16 ] LG touchscreen (1fd2:8001) stops working after reboot: [ 4.859153] i2c_hid i2c-SAPS2101:00: i2c_hid_get_input: incomplete report (64/66) [ 4.936070] i2c_hid i2c-SAPS2101:00: i2c_hid_get_input: incomplete report (64/66) [ 9.948224] i2c_hid i2c-SAPS2101:00: failed to reset device. The device in question stops working after receives SLEEP, ON, SLEEP commands in a short period. The scenario is like this: - Once the desktop session closes, it also closed the hid device, so the device gets runtime suspended and receives a SLEEP command. - Before calling shutdown callback, it gets runtime resumed and received an ON command. - In the shutdown callback, it receives another SLEEP command. I failed to find a reliable interval between ON/SLEEP commands that can make it work, so let's simply disable runtime PM for the device. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
* PCI: Fix Switchtec DMA aliasing quirk dmesg noiseLogan Gunthorpe2019-11-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 742bbe1ee35b5699c092541f97c7cec326556bb1 ] Currently the Switchtec quirk runs on all endpoints in the switch, including all the upstream and downstream ports. These other functions do not contain BARs, so the quirk fails when trying to map the BAR and prints the error "Cannot iomap Switchtec device". The user will see a few of these useless and scary errors, one for each port in the switch. At most, the quirk should only run on either a management endpoint (PCI_CLASS_MEMORY_OTHER) or an NTB endpoint (PCI_CLASS_BRIDGE_OTHER). However, the quirk is useless except in NTB applications, so we will only run it when the class is PCI_CLASS_BRIDGE_OTHER. Switch to using DECLARE_PCI_FIXUP_CLASS_FINAL and only match PCI_CLASS_BRIDGE_OTHER. Reported-by: Stephen Bates <sbates@raithlin.com> Fixes: ad281ecf1c7d ("PCI: Add DMA alias quirk for Microsemi Switchtec NTB") Signed-off-by: Logan Gunthorpe <logang@deltatee.com> [bhelgaas: split SWITCHTEC_QUIRK() introduction to separate patch] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Doug Meyer <dmeyer@gigaio.com> Cc: Kurt Schwemmer <kurt.schwemmer@microsemi.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* bcache: fix input overflow to writeback_rate_minimumColy Li2019-11-061-1/+3
| | | | | | | | | | | | | | | | | [ Upstream commit dab71b2db98dcdd4657d151b01a7be88ce10f9d1 ] dc->writeback_rate_minimum is type unsigned integer variable, it is set via sysfs interface, and converte from input string to unsigned integer by d_strtoul_nonzero(). When the converted input value is larger than UINT_MAX, overflow to unsigned integer happens. This patch fixes the overflow by using sysfs_strotoul_clamp() to convert input string and limit the value in range [1, UINT_MAX], then the overflow can be avoided. Signed-off-by: Coly Li <colyli@suse.de> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drm/msm/dpu: handle failures while initializing displaysJeykumar Sankaran2019-11-061-13/+18
| | | | | | | | | | | | | | | | | [ Upstream commit a802ee99c448ca0496fa307f3e46b834ae2a46a3 ] Bail out KMS hw init on display initialization failures with proper error logging. changes in v3: - introduced in the series changes in v4: - avoid duplicate return on errors (Sean Paul) - avoid spamming errors on failures (Jordon Crouse) Signed-off-by: Jeykumar Sankaran <jsanka@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* usb: dwc2: fix unbalanced use of external vbus-supplyFabrice Gasnier2019-11-061-7/+26
| | | | | | | | | | | | | | | | | | | [ Upstream commit cd7cd0e6cedfda8da6668a4af6748f96bbb6fed4 ] When using external vbus supply regulator, it should be enabled synchronously with PWR bit in HPRT register. This also fixes unbalanced use of this optional regulator (This can be reproduced easily when unbinding the driver). Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus supply") Tested-by: Artur Petrosyan <arturp@synopsys.com> Acked-by: Minas Harutyunyan <hminas@synopsys.com> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* HID: i2c-hid: add Direkt-Tek DTLAPY133-1 to descriptor overrideJulian Sax2019-11-061-0/+8
| | | | | | | | | | | | [ Upstream commit 399474e4c1100bca264ed14fa3ad0d68fab484d8 ] This device uses the SIPODEV SP1064 touchpad, which does not supply descriptors, so it has to be added to the override list. Reported-by: Tim Aldridge <taldridge@mac.com> Signed-off-by: Julian Sax <jsbc@gmx.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
* sc16is7xx: Fix for "Unexpected interrupt: 8"Phil Elwell2019-11-061-0/+28
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 30ec514d440cf2c472c8e4b0079af2c731f71a3e ] The SC16IS752 has an Enhanced Feature Register which is aliased at the same address as the Interrupt Identification Register; accessing it requires that a magic value is written to the Line Configuration Register. If an interrupt is raised while the EFR is mapped in then the ISR won't be able to access the IIR, leading to the "Unexpected interrupt" error messages. Avoid the problem by claiming a mutex around accesses to the EFR register, also claiming the mutex in the interrupt handler work item (this is equivalent to disabling interrupts to interlock against a non-threaded interrupt handler). See: https://github.com/raspberrypi/linux/issues/2529 Signed-off-by: Phil Elwell <phil@raspberrypi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* scsi: lpfc: Fix a duplicate 0711 log message number.James Smart2019-11-061-1/+1
| | | | | | | | | | | [ Upstream commit 2c4c91415a05677acc5c8131a5eb472d4aa96ae1 ] Renumber one of the 0711 log messages so there isn't a duplication. Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* wil6210: fix freeing of rx buffers in EDMA modeAhmad Masri2019-11-061-30/+14
| | | | | | | | | | | | | | [ Upstream commit 6470f31927b46846d957628b719dcfda05446664 ] After being associated with some EDMA rx traffic, upon "down" driver doesn't free all skbs in the rx ring. Modify wil_move_all_rx_buff_to_free_list to loop on active list of rx buffers, unmap the physical memory and free the skb. Signed-off-by: Ahmad Masri <amasri@codeaurora.org> Signed-off-by: Maya Erez <merez@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* dm snapshot: rework COW throttling to fix deadlockMikulas Patocka2019-11-061-14/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit b21555786f18cd77f2311ad89074533109ae3ffa ] Commit 721b1d98fb517a ("dm snapshot: Fix excessive memory usage and workqueue stalls") introduced a semaphore to limit the maximum number of in-flight kcopyd (COW) jobs. The implementation of this throttling mechanism is prone to a deadlock: 1. One or more threads write to the origin device causing COW, which is performed by kcopyd. 2. At some point some of these threads might reach the s->cow_count semaphore limit and block in down(&s->cow_count), holding a read lock on _origins_lock. 3. Someone tries to acquire a write lock on _origins_lock, e.g., snapshot_ctr(), which blocks because the threads at step (2) already hold a read lock on it. 4. A COW operation completes and kcopyd runs dm-snapshot's completion callback, which ends up calling pending_complete(). pending_complete() tries to resubmit any deferred origin bios. This requires acquiring a read lock on _origins_lock, which blocks. This happens because the read-write semaphore implementation gives priority to writers, meaning that as soon as a writer tries to enter the critical section, no readers will be allowed in, until all writers have completed their work. So, pending_complete() waits for the writer at step (3) to acquire and release the lock. This writer waits for the readers at step (2) to release the read lock and those readers wait for pending_complete() (the kcopyd thread) to signal the s->cow_count semaphore: DEADLOCK. The above was thoroughly analyzed and documented by Nikos Tsironis as part of his initial proposal for fixing this deadlock, see: https://www.redhat.com/archives/dm-devel/2019-October/msg00001.html Fix this deadlock by reworking COW throttling so that it waits without holding any locks. Add a variable 'in_progress' that counts how many kcopyd jobs are running. A function wait_for_in_progress() will sleep if 'in_progress' is over the limit. It drops _origins_lock in order to avoid the deadlock. Reported-by: Guruswamy Basavaiah <guru2018@gmail.com> Reported-by: Nikos Tsironis <ntsironis@arrikto.com> Reviewed-by: Nikos Tsironis <ntsironis@arrikto.com> Tested-by: Nikos Tsironis <ntsironis@arrikto.com> Fixes: 721b1d98fb51 ("dm snapshot: Fix excessive memory usage and workqueue stalls") Cc: stable@vger.kernel.org # v5.0+ Depends-on: 4a3f111a73a8c ("dm snapshot: introduce account_start_copy() and account_end_copy()") Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* dm snapshot: introduce account_start_copy() and account_end_copy()Mikulas Patocka2019-11-061-3/+13
| | | | | | | | | | | | | | [ Upstream commit a2f83e8b0c82c9500421a26c49eb198b25fcdea3 ] This simple refactoring moves code for modifying the semaphore cow_count into separate functions to prepare for changes that will extend these methods to provide for a more sophisticated mechanism for COW throttling. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Reviewed-by: Nikos Tsironis <ntsironis@arrikto.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* zram: fix race between backing_dev_show and backing_dev_storeSasha Levin2019-11-061-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit f7daefe4231e57381d92c2e2ad905a899c28e402 ] CPU0: CPU1: backing_dev_show backing_dev_store ...... ...... file = zram->backing_dev; down_read(&zram->init_lock); down_read(&zram->init_init_lock) file_path(file, ...); zram->backing_dev = backing_dev; up_read(&zram->init_lock); up_read(&zram->init_lock); gets the value of zram->backing_dev too early in backing_dev_show, which resultin the value being NULL at the beginning, and not NULL later. backtrace: d_path+0xcc/0x174 file_path+0x10/0x18 backing_dev_show+0x40/0xb4 dev_attr_show+0x20/0x54 sysfs_kf_seq_show+0x9c/0x10c kernfs_seq_show+0x28/0x30 seq_read+0x184/0x488 kernfs_fop_read+0x5c/0x1a4 __vfs_read+0x44/0x128 vfs_read+0xa0/0x138 SyS_read+0x54/0xb4 Link: http://lkml.kernel.org/r/1571046839-16814-1-git-send-email-chenwandun@huawei.com Signed-off-by: Chenwandun <chenwandun@huawei.com> Acked-by: Minchan Kim <minchan@kernel.org> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: <stable@vger.kernel.org> [4.14+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* RDMA/cxgb4: Do not dma memory off of the stackGreg KH2019-10-291-11/+17
| | | | | | | | | | | | | | | | | | | | commit 3840c5b78803b2b6cc1ff820100a74a092c40cbb upstream. Nicolas pointed out that the cxgb4 driver is doing dma off of the stack, which is generally considered a very bad thing. On some architectures it could be a security problem, but odds are none of them actually run this driver, so it's just a "normal" bug. Resolve this by allocating the memory for a message off of the heap instead of the stack. kmalloc() always will give us a proper memory location that DMA will work correctly from. Link: https://lore.kernel.org/r/20191001165611.GA3542072@kroah.com Reported-by: Nicolas Waisman <nico@semmle.com> Tested-by: Potnuri Bharat Teja <bharat@chelsio.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* PCI: PM: Fix pci_power_up()Rafael J. Wysocki2019-10-291-13/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 45144d42f299455911cc29366656c7324a3a7c97 upstream. There is an arbitrary difference between the system resume and runtime resume code paths for PCI devices regarding the delay to apply when switching the devices from D3cold to D0. Namely, pci_restore_standard_config() used in the runtime resume code path calls pci_set_power_state() which in turn invokes __pci_start_power_transition() to power up the device through the platform firmware and that function applies the transition delay (as per PCI Express Base Specification Revision 2.0, Section 6.6.1). However, pci_pm_default_resume_early() used in the system resume code path calls pci_power_up() which doesn't apply the delay at all and that causes issues to occur during resume from suspend-to-idle on some systems where the delay is required. Since there is no reason for that difference to exist, modify pci_power_up() to follow pci_set_power_state() more closely and invoke __pci_start_power_transition() from there to call the platform firmware to power up the device (in case that's necessary). Fixes: db288c9c5f9d ("PCI / PM: restore the original behavior of pci_set_power_state()") Reported-by: Daniel Drake <drake@endlessm.com> Tested-by: Daniel Drake <drake@endlessm.com> Link: https://lore.kernel.org/linux-pm/CAD8Lp44TYxrMgPLkHCqF9hv6smEurMXvmmvmtyFhZ6Q4SE+dig@mail.gmail.com/T/#m21be74af263c6a34f36e0fc5c77c5449d9406925 Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: 3.10+ <stable@vger.kernel.org> # 3.10+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xen/netback: fix error path of xenvif_connect_data()Juergen Gross2019-10-291-1/+0
| | | | | | | | | | | | | | | | | | commit 3d5c1a037d37392a6859afbde49be5ba6a70a6b3 upstream. xenvif_connect_data() calls module_put() in case of error. This is wrong as there is no related module_get(). Remove the superfluous module_put(). Fixes: 279f438e36c0a7 ("xen-netback: Don't destroy the netdev until the vif is shut down") Cc: <stable@vger.kernel.org> # 3.12 Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Paul Durrant <paul@xen.org> Reviewed-by: Wei Liu <wei.liu@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* cpufreq: Avoid cpufreq_suspend() deadlock on system shutdownRafael J. Wysocki2019-10-292-10/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 65650b35133ff20f0c9ef0abd5c3c66dbce3ae57 upstream. It is incorrect to set the cpufreq syscore shutdown callback pointer to cpufreq_suspend(), because that function cannot be run in the syscore stage of system shutdown for two reasons: (a) it may attempt to carry out actions depending on devices that have already been shut down at that point and (b) the RCU synchronization carried out by it may not be able to make progress then. The latter issue has been present since commit 45975c7d21a1 ("rcu: Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds"), but the former one has been there since commit 90de2a4aa9f3 ("cpufreq: suspend cpufreq governors on shutdown") regardless. Fix that by dropping cpufreq_syscore_ops altogether and making device_shutdown() call cpufreq_suspend() directly before shutting down devices, which is along the lines of what system-wide power management does. Fixes: 45975c7d21a1 ("rcu: Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds") Fixes: 90de2a4aa9f3 ("cpufreq: suspend cpufreq governors on shutdown") Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 4.0+ <stable@vger.kernel.org> # 4.0+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* memstick: jmb38x_ms: Fix an error handling path in 'jmb38x_ms_probe()'Christophe JAILLET2019-10-291-1/+1
| | | | | | | | | | | | | | | | commit 28c9fac09ab0147158db0baeec630407a5e9b892 upstream. If 'jmb38x_ms_count_slots()' returns 0, we must undo the previous 'pci_request_regions()' call. Goto 'err_out_int' to fix it. Fixes: 60fdd931d577 ("memstick: add support for JMicron jmb38x MemoryStick host controller") Cc: stable@vger.kernel.org Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* pinctrl: armada-37xx: swap polarity on LED groupPatrick Williams2019-10-291-4/+4
| | | | | | | | | | | | | | | | commit b835d6953009dc350d61402a854b5a7178d8c615 upstream. The configuration registers for the LED group have inverted polarity, which puts the GPIO into open-drain state when used in GPIO mode. Switch to '0' for GPIO and '1' for LED modes. Fixes: 87466ccd9401 ("pinctrl: armada-37xx: Add pin controller support for Armada 37xx") Signed-off-by: Patrick Williams <alpawi@amazon.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191001155154.99710-1-alpawi@amazon.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* pinctrl: armada-37xx: fix control of pins 32 and upPatrick Williams2019-10-291-9/+9
| | | | | | | | | | | | | | | | | | | | | commit 20504fa1d2ffd5d03cdd9dc9c9dd4ed4579b97ef upstream. The 37xx configuration registers are only 32 bits long, so pins 32-35 spill over into the next register. The calculation for the register address was done, but the bitmask was not, so any configuration to pin 32 or above resulted in a bitmask that overflowed and performed no action. Fix the register / offset calculation to also adjust the offset. Fixes: 5715092a458c ("pinctrl: armada-37xx: Add gpio support") Signed-off-by: Patrick Williams <alpawi@amazon.com> Acked-by: Gregory CLEMENT <gregory.clement@bootlin.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191001154634.96165-1-alpawi@amazon.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* pinctrl: cherryview: restore Strago DMI workaround for all versionsDmitry Torokhov2019-10-291-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | commit 260996c30f4f3a732f45045e3e0efe27017615e4 upstream. This is essentially a revert of: e3f72b749da2 pinctrl: cherryview: fix Strago DMI workaround 86c5dd6860a6 pinctrl: cherryview: limit Strago DMI workarounds to version 1.0 because even with 1.1 versions of BIOS there are some pins that are configured as interrupts but not claimed by any driver, and they sometimes fire up and result in interrupt storms that cause touchpad stop functioning and other issues. Given that we are unlikely to qualify another firmware version for a while it is better to keep the workaround active on all Strago boards. Reported-by: Alex Levin <levinale@chromium.org> Fixes: 86c5dd6860a6 ("pinctrl: cherryview: limit Strago DMI workarounds to version 1.0") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Alex Levin <levinale@chromium.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* dm cache: fix bugs when a GFP_NOWAIT allocation failsMikulas Patocka2019-10-291-26/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 13bd677a472d534bf100bab2713efc3f9e3f5978 upstream. GFP_NOWAIT allocation can fail anytime - it doesn't wait for memory being available and it fails if the mempool is exhausted and there is not enough memory. If we go down this path: map_bio -> mg_start -> alloc_migration -> mempool_alloc(GFP_NOWAIT) we can see that map_bio() doesn't check the return value of mg_start(), and the bio is leaked. If we go down this path: map_bio -> mg_start -> mg_lock_writes -> alloc_prison_cell -> dm_bio_prison_alloc_cell_v2 -> mempool_alloc(GFP_NOWAIT) -> mg_lock_writes -> mg_complete the bio is ended with an error - it is unacceptable because it could cause filesystem corruption if the machine ran out of memory temporarily. Change GFP_NOWAIT to GFP_NOIO, so that the mempool code will properly wait until memory becomes available. mempool_alloc with GFP_NOIO can't fail, so remove the code paths that deal with allocation failure. Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* EDAC/ghes: Fix Use after free in ghes_edac remove pathJames Morse2019-10-291-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 1e72e673b9d102ff2e8333e74b3308d012ddf75b upstream. ghes_edac models a single logical memory controller, and uses a global ghes_init variable to ensure only the first ghes_edac_register() will do anything. ghes_edac is registered the first time a GHES entry in the HEST is probed. There may be multiple entries, so subsequent attempts to register ghes_edac are silently ignored as the work has already been done. When a GHES entry is unregistered, it calls ghes_edac_unregister(), which free()s the memory behind the global variables in ghes_edac. But there may be multiple GHES entries, the next call to ghes_edac_unregister() will dereference the free()d memory, and attempt to free it a second time. This may also be triggered on a platform with one GHES entry, if the driver is unbound/re-bound and unbound. The re-bind step will do nothing because of ghes_init, the second unbind will then do the same work as the first. Doing the unregister work on the first call is unsafe, as another CPU may be processing a notification in ghes_edac_report_mem_error(), using the memory we are about to free. ghes_init is already half of the reference counting. We only need to do the register work for the first call, and the unregister work for the last. Add the unregister check. This means we no longer free ghes_edac's memory while there are GHES entries that may receive a notification. This was detected by KASAN and DEBUG_TEST_DRIVER_REMOVE. [ bp: merge into a single patch. ] Fixes: 0fe5f281f749 ("EDAC, ghes: Model a single, logical memory controller") Reported-by: John Garry <john.garry@huawei.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: linux-edac <linux-edac@vger.kernel.org> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: Robert Richter <rrichter@marvell.com> Cc: Tony Luck <tony.luck@intel.com> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20191014171919.85044-2-james.morse@arm.com Link: https://lkml.kernel.org/r/304df85b-8b56-b77e-1a11-aa23769f2e7c@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* mmc: cqhci: Commit descriptors before setting the doorbellFaiz Abbas2019-10-291-1/+2
| | | | | | | | | | | | | | commit c07d0073b9ec80a139d07ebf78e9c30d2a28279e upstream. Add a write memory barrier to make sure that descriptors are actually written to memory, before ringing the doorbell. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drivers/base/memory.c: don't access uninitialized memmaps in ↵David Hildenbrand2019-10-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | soft_offline_page_store() commit 641fe2e9387a36f9ee01d7c69382d1fe147a5e98 upstream. Uninitialized memmaps contain garbage and in the worst case trigger kernel BUGs, especially with CONFIG_PAGE_POISONING. They should not get touched. Right now, when trying to soft-offline a PFN that resides on a memory block that was never onlined, one gets a misleading error with CONFIG_PAGE_POISONING: :/# echo 5637144576 > /sys/devices/system/memory/soft_offline_page [ 23.097167] soft offline: 0x150000 page already poisoned But the actual result depends on the garbage in the memmap. soft_offline_page() can only work with online pages, it returns -EIO in case of ZONE_DEVICE. Make sure to only forward pages that are online (iow, managed by the buddy) and, therefore, have an initialized memmap. Add a check against pfn_to_online_page() and similarly return -EIO. Link: http://lkml.kernel.org/r/20191010141200.8985-1-david@redhat.com Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online") [visible after d0dc12e86b319] Signed-off-by: David Hildenbrand <david@redhat.com> Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Acked-by: Michal Hocko <mhocko@suse.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: <stable@vger.kernel.org> [4.13+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/amdgpu: Bail earlier when amdgpu.cik_/si_support is not set to 1Hans de Goede2019-10-292-35/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 984d7a929ad68b7be9990fc9c5cfa5d5c9fc7942 upstream. Bail from the pci_driver probe function instead of from the drm_driver load function. This avoid /dev/dri/card0 temporarily getting registered and then unregistered again, sending unwanted add / remove udev events to userspace. Specifically this avoids triggering the (userspace) bug fixed by this plymouth merge-request: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59 Note that despite that being a userspace bug, not sending unnecessary udev events is a good idea in general. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490 Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/ttm: Restore ttm prefaultingThomas Hellstrom2019-10-291-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | commit 941f2f72dbbe0cf8c2d6e0b180a8021a0ec477fa upstream. Commit 4daa4fba3a38 ("gpu: drm: ttm: Adding new return type vm_fault_t") broke TTM prefaulting. Since vmf_insert_mixed() typically always returns VM_FAULT_NOPAGE, prefaulting stops after the second PTE. Restore (almost) the original behaviour. Unfortunately we can no longer with the new vm_fault_t return type determine whether a prefaulting PTE insertion hit an already populated PTE, and terminate the insertion loop. Instead we continue with the pre-determined number of prefaults. Fixes: 4daa4fba3a38 ("gpu: drm: ttm: Adding new return type vm_fault_t") Cc: Souptick Joarder <jrdr.linux@gmail.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/330387/ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/edid: Add 6 bpc quirk for SDC panel in Lenovo G50Kai-Heng Feng2019-10-291-0/+3
| | | | | | | | | | | | | | | commit 11bcf5f78905b90baae8fb01e16650664ed0cb00 upstream. Another panel that needs 6BPC quirk. BugLink: https://bugs.launchpad.net/bugs/1819968 Cc: <stable@vger.kernel.org> # v4.8+ Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190402033037.21877-1-kai.heng.feng@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-03 05:46:28 +0000