summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2018-11-09drm/i915/psr: Move intel_psr_disable_source() code to intel_psr_disable_locked()José Roberto de Souza
In the past we had hooks to configure HW for VLV/CHV too, in the drop of VLV/CHV support the intel_psr_disable_source() code was not moved to the caller, so doing it here. Suggested-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-4-jose.souza@intel.com
2018-11-09drm/i915/icl: Reset PSR interruptionsJosé Roberto de Souza
All other interruptions gen11 interruptions are reset in gen11_irq_reset() also it is done for other gens that supports PSR. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-3-jose.souza@intel.com
2018-11-09drm/i915/psr: Always wait for idle state when disabling PSRJosé Roberto de Souza
It should always wait for idle state when disabling PSR because PSR could be inactive due a call to intel_psr_exit() and while PSR is still being disabled asynchronously userspace could change the modeset causing a call to psr_disable() that will not wait for PSR idle and then PSR will be enabled again while PSR is still not idle. v2: rebased on top of the patch reusing psr_exit() Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-2-jose.souza@intel.com
2018-11-09drm/i915/psr: Use intel_psr_exit() in intel_psr_disable_source()José Roberto de Souza
Both functions have the same code to disable PSR, so let's reuse that code instead of duplicate. Suggested-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-1-jose.souza@intel.com
2018-11-09usb: typec: ucsi: add support for Cypress CCGxAjay Gupta
Latest NVIDIA GPU cards have a Cypress CCGx Type-C controller over I2C interface. This UCSI I2C driver uses I2C bus driver interface for communicating with Type-C controller. Signed-off-by: Ajay Gupta <ajayg@nvidia.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2018-11-09serial: sh-sci: Fix could not remove dev_attr_rx_fifo_timeoutYoshihiro Shimoda
This patch fixes an issue that the sci_remove() could not remove dev_attr_rx_fifo_timeout because uart_remove_one_port() set the port->port.type to PORT_UNKNOWN. Reported-by: Hiromitsu Yamasaki <hiromitsu.yamasaki.ym@renesas.com> Fixes: 5d23188a473d ("serial: sh-sci: make RX FIFO parameters tunable via sysfs") Cc: <stable@vger.kernel.org> # v4.11+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-09drm/dp_mst: Check if primary mstb is nullStanislav Lisovskiy
Unfortunately drm_dp_get_mst_branch_device which is called from both drm_dp_mst_handle_down_rep and drm_dp_mst_handle_up_rep seem to rely on that mgr->mst_primary is not NULL, which seem to be wrong as it can be cleared with simultaneous mode set, if probing fails or in other case. mgr->lock mutex doesn't protect against that as it might just get assigned to NULL right before, not simultaneously. There are currently bugs 107738, 108616 bugs which crash in drm_dp_get_mst_branch_device, caused by this issue. v2: Refactored the code, as it was nicely noticed. Fixed Bugzilla bug numbers(second was 108616, but not 108816) and added links. [changed title and added stable cc] Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108616 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107738 Link: https://patchwork.freedesktop.org/patch/msgid/20181109090012.24438-1-stanislav.lisovskiy@intel.com
2018-11-09drm/i915: Generalize skl_ddb_allocation_overlaps()Ville Syrjälä
Make skl_ddb_allocation_overlaps() useful for other callers besides skl_update_crtcs(). We'll need it to do plane updates as well. And while we're here we can reduce the stack utilization a bit by noting that each struct skl_ddb_entry is 4 bytes whereas a pointer to one is 8 bytes (on 64bit). So we'll switch to an array of structs from the array of pointers we used before. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181101150605.18235-9-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-11-09drm/i915: Clean up skl+ PLANE_POS vs. scaler handlingVille Syrjälä
On skl+ the scaler (when enabled) will take care of the plane output position. Make the code less ugly by just setting crtc_x/y to 0 when the scaler is enabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181101150605.18235-6-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-11-09drm/i915: Polish the skl+ plane keyval/msk/max register setupVille Syrjälä
Due to the constant alpha we're going to have to program two of the the tree keying registers anyway, so might as well always program all three. And parametrize the plane constant alpha define while at it. v2: Rebase due to input CSC Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181107184138.31359-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-11-09drm/i915: Remove the PS_PWR_GATE write from skl_program_scaler()Ville Syrjälä
If we don't need the PS_PWR_GATE write when programming the pipe scaler I don't see why we'd need it for plane scalers either. Just remove it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181101150605.18235-4-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-11-09i2c: nvidia-gpu: make pm_ops staticWolfram Sang
sparse rightfully says: warning: symbol 'gpu_i2c_driver_pm' was not declared. Should it be static? Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2018-11-09i2c: add i2c bus driver for NVIDIA GPUAjay Gupta
Latest NVIDIA GPU card has USB Type-C interface. There is a Type-C controller which can be accessed over I2C. This driver adds I2C bus driver to communicate with Type-C controller. I2C client driver will be part of USB Type-C UCSI driver. Signed-off-by: Ajay Gupta <ajayg@nvidia.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> [wsa: kept Makefile sorting] Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2018-11-09can: flexcan: use can_rx_offload_queue_sorted() for flexcan_irq_bus_*()Oleksij Rempel
Currently, in case of bus error, driver will generate error message and put in the tail of the message queue. To avoid confusions, this change should place the bus related messages in proper order. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-11-09can: rx-offload: rename can_rx_offload_irq_queue_err_skb() to ↵Oleksij Rempel
can_rx_offload_queue_tail() This function has nothing todo with error. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-11-09can: flexcan: handle tx-complete CAN frames via rx-offload infrastructureOleksij Rempel
Current flexcan driver will put TX-ECHO in regular unsorted way, in this case TX-ECHO can come after the response to the same TXed message. In some cases, for example for J1939 stack, things will break. This patch is using new rx-offload API to put the messages just in the right place. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-11-09xhci: Add quirk to workaround the errata seen on Cavium Thunder-X2 SocCherian, George
Implement workaround for ThunderX2 Errata-129 (documented in CN99XX Known Issues" available at Cavium support site). As per ThunderX2errata-129, USB 2 device may come up as USB 1 if a connection to a USB 1 device is followed by another connection to a USB 2 device, the link will come up as USB 1 for the USB 2 device. Resolution: Reset the PHY after the USB 1 device is disconnected. The PHY reset sequence is done using private registers in XHCI register space. After the PHY is reset we check for the PLL lock status and retry the operation if it fails. From our tests, retrying 4 times is sufficient. Add a new quirk flag XHCI_RESET_PLL_ON_DISCONNECT to invoke the workaround in handle_xhci_port_status(). Cc: stable@vger.kernel.org Signed-off-by: George Cherian <george.cherian@cavium.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-09usb: xhci: fix timeout for transition from RExit to U0Aaron Ma
This definition is used by msecs_to_jiffies in milliseconds. According to the comments, max rexit timeout should be 20ms. Align with the comments to properly calculate the delay. Verified on Sunrise Point-LP and Cannon Lake. Cc: stable@vger.kernel.org Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-09usb: xhci: fix uninitialized completion when USB3 port got wrong statusAaron Ma
Realtek USB3.0 Card Reader [0bda:0328] reports wrong port status on Cannon lake PCH USB3.1 xHCI [8086:a36d] after resume from S3, after clear port reset it works fine. Since this device is registered on USB3 roothub at boot, when port status reports not superspeed, xhci_get_port_status will call an uninitialized completion in bus_state[0]. Kernel will hang because of NULL pointer. Restrict the USB2 resume status check in USB2 roothub to fix hang issue. Cc: stable@vger.kernel.org Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-09xhci: Add check for invalid byte size error when UAS devices are connected.Sandeep Singh
Observed "TRB completion code (27)" error which corresponds to Stopped - Length Invalid error(xhci spec section 4.17.4) while connecting USB to SATA bridge. Looks like this case was not considered when the following patch[1] was committed. Hence adding this new check which can prevent the invalid byte size error. [1] ade2e3a xhci: handle transfer events without TRB pointer Cc: <stable@vger.kernel.org> Signed-off-by: Sandeep Singh <sandeep.singh@amd.com> cc: Nehal Shah <Nehal-bakulchandra.Shah@amd.com> cc: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-09xhci: handle port status events for removed USB3 hcdMathias Nyman
At xhci removal the USB3 hcd (shared_hcd) is removed before the primary USB2 hcd. Interrupts for port status changes may still occur for USB3 ports after the shared_hcd is freed, causing NULL pointer dereference. Check if xhci->shared_hcd is still valid before handing USB3 port events Cc: <stable@vger.kernel.org> Reported-by: Peter Chen <peter.chen@nxp.com> Tested-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-09xhci: Fix leaking USB3 shared_hcd at xhci removalMathias Nyman
Ensure that the shared_hcd pointer is valid when calling usb_put_hcd() The shared_hcd is removed and freed in xhci by first calling usb_remove_hcd(xhci->shared_hcd), and later usb_put_hcd(xhci->shared_hcd) Afer commit fe190ed0d602 ("xhci: Do not halt the host until both HCD have disconnected their devices.") the shared_hcd was never properly put as xhci->shared_hcd was set to NULL before usb_put_hcd(xhci->shared_hcd) was called. shared_hcd (USB3) is removed before primary hcd (USB2). While removing the primary hcd we might need to handle xhci interrupts to cleanly remove last USB2 devices, therefore we need to set xhci->shared_hcd to NULL before removing the primary hcd to let xhci interrupt handler know shared_hcd is no longer available. xhci-plat.c, xhci-histb.c and xhci-mtk first create both their hcd's before adding them. so to keep the correct reverse removal order use a temporary shared_hcd variable for them. For more details see commit 4ac53087d6d4 ("usb: xhci: plat: Create both HCDs before adding them") Fixes: fe190ed0d602 ("xhci: Do not halt the host until both HCD have disconnected their devices.") Cc: Joel Stanley <joel@jms.id.au> Cc: Chunfeng Yun <chunfeng.yun@mediatek.com> Cc: Thierry Reding <treding@nvidia.com> Cc: Jianguo Sun <sunjianguo1@huawei.com> Cc: <stable@vger.kernel.org> Reported-by: Jack Pham <jackp@codeaurora.org> Tested-by: Jack Pham <jackp@codeaurora.org> Tested-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-09i2c: qcom-geni: Fix runtime PM mismatch with child devicesStephen Boyd
We need to enable runtime PM on this i2c controller before populating child devices with i2c_add_adapter(). Otherwise, if a child device uses runtime PM and stays runtime PM enabled we'll get the following warning at boot. Enabling runtime PM for inactive device (a98000.i2c) with active children [...] Call trace: pm_runtime_enable+0xd8/0xf8 geni_i2c_probe+0x440/0x460 platform_drv_probe+0x74/0xc8 [...] Let's move the runtime PM enabling and setup to before we add the adapter, so that this device can respond to runtime PM requests from children. Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2018-11-09i2c: omap: Enable for ARCH_K3Vignesh R
Allow I2C_OMAP to be built for K3 platforms. Signed-off-by: Vignesh R <vigneshr@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2018-11-09drm/i915/mst: Drop pre_pll_enable null checkJosé Roberto de Souza
MST is only supported in DDI ports that have this hook, so the null check can be dropped. Suggested-by: Imre Deak <imre.deak@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181107235449.32264-3-jose.souza@intel.com
2018-11-09drm/i915: Release DDI power well references in MST portsJosé Roberto de Souza
MST ports did not had the post_pll_disable() hook causing the references get in pre_pll_enable() never being released causing DDI and AUX CH being enabled all the times. v2: renamed intel_mst_post_pll_disable_dp() parameters Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181107235449.32264-2-jose.souza@intel.com
2018-11-09drm/i915: Reuse the aux_domain cachedJosé Roberto de Souza
intel_dp_detect() caches the aux_domain in the beginning of the function as it is used twice, so lets also use it as the aux_domain don't change in runtime. v3: returning intel_dp_retrain_link() error insted of connector_status_disconnected Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181107235449.32264-1-jose.souza@intel.com
2018-11-09can: rx-offload: introduce can_rx_offload_get_echo_skb() and ↵Oleksij Rempel
can_rx_offload_queue_sorted() functions Current CAN framework can't guarantee proper/chronological order of RX and TX-ECHO messages. To make this possible, drivers should use this functions instead of can_get_echo_skb(). Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-11-09can: dev: __can_get_echo_skb(): print error message, if trying to echo non ↵Marc Kleine-Budde
existing skb Prior to echoing a successfully transmitted CAN frame (by calling can_get_echo_skb()), CAN drivers have to put the CAN frame (by calling can_put_echo_skb() in the transmit function). These put and get function take an index as parameter, which is used to identify the CAN frame. A driver calling can_get_echo_skb() with a index not pointing to a skb is a BUG, so add an appropriate error message. Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-11-09can: dev: __can_get_echo_skb(): Don't crash the kernel if can_priv::echo_skb ↵Marc Kleine-Budde
is accessed out of bounds If the "struct can_priv::echo_skb" is accessed out of bounds would lead to a kernel crash. Better print a sensible warning message instead and try to recover. Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-11-09can: dev: __can_get_echo_skb(): replace struct can_frame by canfd_frame to ↵Marc Kleine-Budde
access frame length This patch replaces the use of "struct can_frame::can_dlc" by "struct canfd_frame::len" to access the frame's length. As it is ensured that both structures have a compatible memory layout for this member this is no functional change. Futher, this compatibility is documented in a comment. Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-11-09can: dev: can_get_echo_skb(): factor out non sending code to ↵Marc Kleine-Budde
__can_get_echo_skb() This patch factors out all non sending parts of can_get_echo_skb() into a seperate function __can_get_echo_skb(), so that it can be re-used in an upcoming patch. Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-11-09can: flexcan: remove not needed struct flexcan_priv::tx_mb and struct ↵Marc Kleine-Budde
flexcan_priv::tx_mb_idx The previous patch changes the TX path to always use the last mailbox regardless of the used offload scheme (rx-fifo or timestamp based). This means members "tx_mb" and "tx_mb_idx" of the struct flexcan_priv don't depend on the offload scheme, so replace them by compile time constants. Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-11-09can: flexcan: Always use last mailbox for TXAlexander Stein
Essentially this patch moves the TX mailbox to position 63, regardless of timestamp based offloading or RX FIFO. So mainly the iflag register usage regarding TX has changed. The rest is consolidating RX FIFO and timestamp offloading as they now use both the same TX mailbox. The reason is a very annoying behavior regarding sending RTR frames when _not_ using RX FIFO: If a TX mailbox sent a RTR frame it becomes a RX mailbox. For that reason flexcan_irq disables the TX mailbox again. But if during the time the RTR was sent and the TX mailbox is disabled a new CAN frames is received, it is lost without notice. The reason is that so-called "Move-in" process starts from the lowest mailbox which happen to be a TX mailbox set to EMPTY. Steps to reproduce (I used an imx7d): 1. generate regular bursts of messages 2. send a RTR from flexcan with higher priority than burst messages every 1ms, e.g. cangen -I 0x100 -L 0 -g 1 -R can0 3. notice a lost message without notification after some seconds When running an iperf in parallel this problem is occurring even more frequently. Using filters is not possible as at least one single CAN-ID is allowed. Handling the TX MB during RX is also not possible as there is no race-free disable of RX MB. There is still a slight window when the described problem can occur. But for that all RX MB must be in use which is essentially next to an overrun. Still there will be no indication if it ever occurs. Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-11-09can: flexcan: Unlock the MB unconditionallyPankaj Bansal
Unlock the MB irrespective of reception method being FIFO or timestamp based. It is optional but recommended to unlock Mailbox as soon as possible and make it available for reception. Reported-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-11-09can: hi311x: Use level-triggered interruptLukas Wunner
If the hi3110 shares the SPI bus with another traffic-intensive device and packets are received in high volume (by a separate machine sending with "cangen -g 0 -i -x"), reception stops after a few minutes and the counter in /proc/interrupts stops incrementing. Bus state is "active". Bringing the interface down and back up reconvenes the reception. The issue is not observed when the hi3110 is the sole device on the SPI bus. Using a level-triggered interrupt makes the issue go away and lets the hi3110 successfully receive 2 GByte over the course of 5 days while a ks8851 Ethernet chip on the same SPI bus handles 6 GByte of traffic. Unfortunately the hi3110 datasheet is mum on the trigger type. The pin description on page 3 only specifies the polarity (active high): http://www.holtic.com/documents/371-hi-3110_v-rev-kpdf.do Cc: Mathias Duckeck <m.duckeck@kunbus.de> Cc: Akshay Bhat <akshay.bhat@timesys.com> Cc: Casey Fitzpatrick <casey.fitzpatrick@timesys.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-11-09can: rcar_can: Fix erroneous registrationFabrizio Castro
Assigning 2 to "renesas,can-clock-select" tricks the driver into registering the CAN interface, even though we don't want that. This patch improves one of the checks to prevent that from happening. Fixes: 862e2b6af9413b43 ("can: rcar_can: support all input clocks") Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com> Signed-off-by: Chris Paterson <Chris.Paterson2@renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-11-09can: ucan: remove duplicated include from ucan.cYueHaibing
Remove duplicated include. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Martin Elshuber <martin.elshuber@theobroma-systems.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-11-09can: ucan: remove set but not used variable 'udev'YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/can/usb/ucan.c: In function 'ucan_disconnect': drivers/net/can/usb/ucan.c:1578:21: warning: variable 'udev' set but not used [-Wunused-but-set-variable] struct usb_device *udev; Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Martin Elshuber <martin.elshuber@theobroma-systems.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-11-09can: kvaser_usb: Fix accessing freed memory in kvaser_usb_start_xmit()Jimmy Assarsson
The call to can_put_echo_skb() may result in the skb being freed. The skb is later used in the call to dev->ops->dev_frame_to_cmd(). This is avoided by moving the call to can_put_echo_skb() after dev->ops->dev_frame_to_cmd(). Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jimmy Assarsson <jimmyassarsson@gmail.com> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-11-09can: kvaser_usb: Fix potential uninitialized variable useJimmy Assarsson
If alloc_can_err_skb() fails, cf is never initialized. Move assignment of cf inside check. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jimmy Assarsson <jimmyassarsson@gmail.com> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2018-11-09drm/i915: Sanitize PCH port transcoder select on IBXVille Syrjälä
IBX has a documented workaround which states that when we disable the port we must change its transcoder select to A, otherwise it will prevent the other port (DP vs. HDMI/SDVO) from using transcoder A. We implement the workaround during encoder disable, but looks like some BIOSen leave transcoder B selected even when the port wasn't actually enabled by the BIOS. That will trip up our asserts that attempt to make sure we never forget this w/a. Sanitize the transcoder select to A for all disabled PCH DP/HDMI/SDVO ports. We assume that the port was never enabled by the BIOS on transcoder B, because if it had we'd actually have to toggle the port on and back off to properly switch it back to transcoder A. That would cause some display flicker if transcoder A is already enabled on some other port, so it's better not to do it unless absolutely necessary. Since we have no indication that the transcoder select is misbehaving on the affected machines we can assume the port was never actually enabled by the BIOS. This cures warning like this during driver load: IBX PCH DP C still using transcoder B WARNING: CPU: 2 PID: 172 at drivers/gpu/drm/i915/intel_display.c:1279 assert_pch_dp_disabled+0x9e/0xb0 [i915] v2: Add comments to remind the reader that SDVOB==HDMIB (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181108143635.9556-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2018-11-09drm/i915: Fix hpd handling for pins with two encodersVille Syrjälä
In my haste to remove irq_port[] I accidentally changed the way we deal with hpd pins that are shared by multiple encoders (DP and HDMI for pre-DDI platforms). Previously we would only handle such pins via ->hpd_pulse(), but now we queue up the hotplug work for the HDMI encoder directly. Worse yet, we now count each hpd twice and this increment the hpd storm count twice as fast. This can lead to spurious storms being detected. Go back to the old way of doing things, ie. delegate to ->hpd_pulse() for any pin which has an encoder with that hook implemented. I don't really like the idea of adding irq_port[] back so let's loop through the encoders first to check if we have an encoder with ->hpd_pulse() for the pin, and then go through all the pins and decided on the correct course of action based on the earlier findings. I have occasionally toyed with the idea of unifying the pre-DDI HDMI and DP encoders into a single encoder as well. Besides the hotplug processing it would have the other benefit of preventing userspace from trying to enable both encoders at the same time. That is simply illegal as they share the same clock/data pins. We have some testcases that will attempt that and thus fail on many older machines. But for now let's stick to fixing just the hotplug code. Cc: stable@vger.kernel.org # 4.19+ Cc: Lyude Paul <lyude@redhat.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Fixes: b6ca3eee18ba ("drm/i915: Nuke dev_priv->irq_port[]") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181108200424.28371-1-ville.syrjala@linux.intel.com Reviewed-by: Lyude Paul <lyude@redhat.com>
2018-11-09xen: remove size limit of privcmd-buf mapping interfaceJuergen Gross
Currently the size of hypercall buffers allocated via /dev/xen/hypercall is limited to a default of 64 memory pages. For live migration of guests this might be too small as the page dirty bitmask needs to be sized according to the size of the guest. This means migrating a 8GB sized guest is already exhausting the default buffer size for the dirty bitmap. There is no sensible way to set a sane limit, so just remove it completely. The device node's usage is limited to root anyway, so there is no additional DOS scenario added by allowing unlimited buffers. While at it make the error path for the -ENOMEM case a little bit cleaner by setting n_pages to the number of successfully allocated pages instead of the target size. Fixes: c51b3c639e01f2 ("xen: add new hypercall buffer mapping device") Cc: <stable@vger.kernel.org> #4.18 Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2018-11-09drm/vc4: Prefer PPF over TPZ when dst >= 2/3 srcBoris Brezillon
The HVS spec recommends using PPF when the downscaling ratio is between 2/3 and 1. Let's modify vc4_get_scaling_mode() to follow this recommendation. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20181109102633.32603-2-boris.brezillon@bootlin.com
2018-11-09drm/vc4: ->x_scaling[1] should never be set to VC4_SCALING_NONEBoris Brezillon
For the YUV conversion to work properly, ->x_scaling[1] should never be set to VC4_SCALING_NONE, but vc4_get_scaling_mode() might return VC4_SCALING_NONE if the horizontal scaling ratio exactly matches the horizontal subsampling factor. Add a test to turn VC4_SCALING_NONE into VC4_SCALING_PPF when that happens. The old ->x_scaling[0] adjustment is dropped as I couldn't find any mention to this constraint in the spec and it's proven to be unnecessary (I tested various multi-planar YUV formats with scaling disabled, and all of them worked fine without this adjustment). Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.") Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20181109102633.32603-1-boris.brezillon@bootlin.com
2018-11-09drm/i915/icl: Fix PLL mapping sanitization for DP portsImre Deak
We shouldn't consider an encoder inactive if it doesn't have a CRTC linked, but has virtual MST encoders with a crtc linked. Fix this. Also we should not sanitize the mapping for MST encoders, as it's always their primary encoder (which could be even in SST mode) whose active state determines if we need the clock being enabled for the corresponding physical port. Fix this too. This fixes at least an existing breakage where we incorrectly disabled the clock for an active DP encoder when sanitizing its MST virtual encoders. Not sure if there are BIOSes that enable an output in MST mode, but our HW readout is mostly missing for it anyway, so just warn for that case. Fixes: 70332ac539c5 ("drm/i915/icl+: Sanitize port to PLL mapping") Cc: Antonio Argenziano <antonio.argenziano@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reported-by: Antonio Argenziano <antonio.argenziano@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: Clint Taylor <Clinton.A.Taylor@intel.com> Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181107200836.10191-2-imre.deak@intel.com
2018-11-09drm/i915/ddi: Add more sanity check to the encoder HW readoutImre Deak
Check for reserved register field values and conflicting transcoder->port mappings (both MST and non-MST mappings or multiple SST mappings). This is also needed for the next patch to determine if a port is in MST mode during sanitization after HW readout. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Antonio Argenziano <antonio.argenziano@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181107200836.10191-1-imre.deak@intel.com
2018-11-09Revert "nvmet-rdma: use a private workqueue for delete"Christoph Hellwig
This reverts commit 2acf70ade79d26b97611a8df52eb22aa33814cd4. The commit never really fixed the intended issue and caused all kinds of other issues, including a use before initialization. Suggested-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2018-11-09nvme: make sure ns head inherits underlying device limitsSagi Grimberg
Whenever we update ns_head info, we need to make sure it is still compatible with all underlying backing devices because although nvme multipath doesn't have any explicit use of these limits, other devices can still be stacked on top of it which may rely on the underlying limits. Start with unlimited stacking limits, and every info update iterate over siblings and adjust queue limits. Signed-off-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
generated by cgit (git 2.34.1) at 2025-09-13 00:46:20 +0000