summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2019-06-11drm/i915: Maintain consistent documentation subsection orderingJonathan Corbet2-4/+4
commit 551bd3368a7b3cfef01edaade8970948d178d40a upstream. With Sphinx 2.0 (or prior versions with the deprecation warnings fixed) the docs build fails with: Documentation/gpu/i915.rst:403: WARNING: Title level inconsistent: Global GTT Fence Handling ~~~~~~~~~~~~~~~~~~~~~~~~~ reST markup error: Documentation/gpu/i915.rst:403: (SEVERE/4) Title level inconsistent: I "fixed" it by changing the subsections in i915.rst, but that didn't seem like the correct change. It turns out that a couple of i915 files create their own subsections in kerneldoc comments using apostrophes as the heading marker: Layout '''''' That breaks the normal subsection marker ordering, and newer Sphinx is rather more strict about enforcing that ordering. So fix the offending comments to make Sphinx happy. (This is unfortunate, in that kerneldoc comments shouldn't need to be aware of where they might be included in the heading hierarchy, but I don't see a better way around it). Cc: stable@vger.kernel.org # v4.14+ Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11drm/i915/gvt: emit init breadcrumb for gvt requestWeinan1-0/+19
commit a8c2d5ab9e71be3f9431c47bd45329a36e1fc650 upstream. "To track whether a request has started on HW, we can emit a breadcrumb at the beginning of the request and check its timeline's HWSP to see if the breadcrumb has advanced past the start of this request." It means all the request which timeline's has_init_breadcrumb is true, then the emit_init_breadcrumb process must have before emitting the real commands, otherwise, the scheduler might get a wrong state of this request during reset. If the request is exactly the guilty one, the scheduler won't terminate it with the wrong state. To avoid this, do emit_init_breadcrumb for all the requests from gvt. v2: cc to stable kernel Fixes: 8547444137ec ("drm/i915: Identify active requests") Cc: stable@vger.kernel.org Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Weinan <weinan.z.li@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11drm/i915/fbc: disable framebuffer compression on GeminiLakeDaniel Drake1-0/+4
commit 396dd8143bdd94bd1c358a228a631c8c895a1126 upstream. On many (all?) the Gemini Lake systems we work with, there is frequent momentary graphical corruption at the top of the screen, and it seems that disabling framebuffer compression can avoid this. The ticket was reported 6 months ago and has already affected a multitude of users, without any real progress being made. So, lets disable framebuffer compression on GeminiLake until a solution is found. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108085 Fixes: fd7d6c5c8f3e ("drm/i915: enable FBC on gen9+ too") Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.11+ Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190423092810.28359-1-jian-hong@endlessm.com (cherry picked from commit 1d25724b41fad7eeb2c3058a5c8190d6ece73e08) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11drm/amdgpu: fix ring test failure issue during s3 in vce 3.0 (V2)Louis Li1-1/+3
commit ce0e22f5d886d1b56c7ab4347c45b9ac5fcc058d upstream. [What] vce ring test fails consistently during resume in s3 cycle, due to mismatch read & write pointers. On debug/analysis its found that rptr to be compared is not being correctly updated/read, which leads to this failure. Below is the failure signature: [drm:amdgpu_vce_ring_test_ring] *ERROR* amdgpu: ring 12 test failed [drm:amdgpu_device_ip_resume_phase2] *ERROR* resume of IP block <vce_v3_0> failed -110 [drm:amdgpu_device_resume] *ERROR* amdgpu_device_ip_resume failed (-110). [How] fetch rptr appropriately, meaning move its read location further down in the code flow. With this patch applied the s3 failure is no more seen for >5k s3 cycles, which otherwise is pretty consistent. V2: remove reduntant fetch of rptr Signed-off-by: Louis Li <Ching-shih.Li@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11drm/amd/display: Add ASICREV_IS_PICASSOHarry Wentland1-3/+4
commit ada637e70f96862ff5ba20a169506b58cf567db9 upstream. [WHY] We only want to load DMCU FW on Picasso and Raven 2, not on Raven 1. Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11drm/amdgpu/soc15: skip reset on initAlex Deucher1-0/+5
commit 5887a59961e2295c5b02f39dbc0ecf9212709b7b upstream. Not necessary on soc15 and breaks driver reload on server cards. Acked-by: Amber Lin <Amber.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11drm/amdgpu: remove ATPX_DGPU_REQ_POWER_FOR_DISPLAYS check when hotplug-inAaron Liu1-2/+1
commit bdb1ccb080dafc1b4224873a5b759ff85a7d1c10 upstream. In amdgpu_atif_handler, when hotplug event received, remove ATPX_DGPU_REQ_POWER_FOR_DISPLAYS check. This bit's check will cause missing system resume. Signed-off-by: Aaron Liu <aaron.liu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11drm/radeon: prefer lower reference dividersChristian König1-2/+2
commit 2e26ccb119bde03584be53406bbd22e711b0d6e6 upstream. Instead of the closest reference divider prefer the lowest, this fixes flickering issues on HP Compaq nx9420. Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=108514 Suggested-by: Paul Dufresne <dufresnep@gmail.com> Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11drm/amdgpu/psp: move psp version specific function pointers to early_initAlex Deucher1-9/+10
commit 9d6fea5744d6798353f37ac42a8a653a2607ca69 upstream. In case we need to use them for GPU reset prior initializing the asic. Fixes a crash if the driver attempts to reset the GPU at driver load time. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11drm: Fix timestamp docs for variable refresh properties.Mario Kleiner1-6/+0
commit 0cbd0adc4429930567083d18cc8c0fbc5f635d96 upstream. As discussed with Nicholas and Daniel Vetter (patchwork link to discussion below), the VRR timestamping behaviour produced utterly useless and bogus vblank/pageflip timestamps. We have found a way to fix this and provide sane behaviour. As of Linux 5.2, the amdgpu driver will be able to provide exactly the same vblank / pageflip timestamp semantic in variable refresh rate mode as in standard fixed refresh rate mode. This is achieved by deferring core vblank handling (drm_crtc_handle_vblank()) until the end of front porch, and also defer the sending of pageflip completion events until end of front porch, when we can safely compute correct pageflip/vblank timestamps. The same approach will be possible for other VRR capable kms drivers, so we can actually have sane and useful timestamps in VRR mode. This patch removes the section of the docs that describes the broken timestamp behaviour present in Linux 5.0/5.1. Fixes: ab7a664f7a2d ("drm: Document variable refresh properties") Link: https://patchwork.freedesktop.org/patch/285333/ Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190418060157.18968-1-mario.kleiner.de@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11drm: add non-desktop quirks to Sensics and OSVR headsets.Ryan Pavlik1-0/+6
commit 29054230f3e11ea818eccfa7bb4e4b3e89544164 upstream. Add two EDID vendor/product pairs used across a variety of Sensics products, as well as the OSVR HDK and HDK 2. Signed-off-by: Ryan Pavlik <ryan.pavlik@collabora.com> Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20181203164644.13974-1-ryan.pavlik@collabora.com Cc: <stable@vger.kernel.org> # v4.15+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)Dave Airlie2-3/+17
commit b30a43ac7132cdda833ac4b13dd1ebd35ace14b7 upstream. There was a nouveau DDX that relied on legacy context ioctls to work, but we fixed it years ago, give distros that have a modern DDX the option to break the uAPI and close the mess of holes that legacy context support is. Full context of the story: commit 0e975980d435d58df2d430d688b8c18778b42218 Author: Peter Antoine <peter.antoine@intel.com> Date: Tue Jun 23 08:18:49 2015 +0100 drm: Turn off Legacy Context Functions The context functions are not used by the i915 driver and should not be used by modeset drivers. These driver functions contain several bugs and security holes. This change makes these functions optional can be turned on by a setting, they are turned off by default for modeset driver with the exception of the nouvea driver that may require them with an old version of libdrm. The previous attempt was commit 7c510133d93dd6f15ca040733ba7b2891ed61fd1 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Aug 8 15:41:21 2013 +0200 drm: mark context support as a legacy subsystem but this had to be reverted commit c21eb21cb50d58e7cbdcb8b9e7ff68b85cfa5095 Author: Dave Airlie <airlied@redhat.com> Date: Fri Sep 20 08:32:59 2013 +1000 Revert "drm: mark context support as a legacy subsystem" v2: remove returns from void function, and formatting (Daniel Vetter) v3: - s/Nova/nouveau/ in the commit message, and add references to the previous attempts - drop the part touching the drm hw lock, that should be a separate patch. Signed-off-by: Peter Antoine <peter.antoine@intel.com> (v2) Cc: Peter Antoine <peter.antoine@intel.com> (v2) Reviewed-by: Peter Antoine <peter.antoine@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> v2: move DRM_VM dependency into legacy config. v3: fix missing dep (kbuild robot) Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11drm: add non-desktop quirk for Valve HMDsAndres Rodriguez1-0/+19
commit 30d62d4453e49f85dd17b2ba60bbb68b6593dba0 upstream. Add vendor/product pairs for the Valve Index HMDs. Signed-off-by: Andres Rodriguez <andresx7@gmail.com> Cc: Dave Airlie <airlied@redhat.com> Cc: <stable@vger.kernel.org> # v4.15 Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190502193157.15692-1-andresx7@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11drm/msm: fix fb references in async updateHelen Koike1-0/+4
commit 474d952b4870cfbdc55d3498f4d498775fe77e81 upstream. Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Cc: <stable@vger.kernel.org> # v4.14+ Fixes: 224a4c970987 ("drm/msm: update cursors asynchronously through atomic") Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Helen Koike <helen.koike@collabora.com> Acked-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-4-helen.koike@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11drm/gma500/cdv: Check vbt config bits when detecting lvds panelsPatrik Jakobsson3-0/+7
commit 7c420636860a719049fae9403e2c87804f53bdde upstream. Some machines have an lvds child device in vbt even though a panel is not attached. To make detection more reliable we now also check the lvds config bits available in the vbt. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1665766 Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190416114607.1072-1-patrik.r.jakobsson@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11drm/vc4: fix fb references in async updateHelen Koike1-1/+1
commit c16b85559dcfb5a348cc085a7b4c75ed49b05e2c upstream. Async update callbacks are expected to set the old_fb in the new_state so prepare/cleanup framebuffers are balanced. Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new fb and put the old fb) is not required, as it's taken care by drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane(). Cc: <stable@vger.kernel.org> # v4.19+ Fixes: 539c320bfa97 ("drm/vc4: update cursors asynchronously through atomic") Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Helen Koike <helen.koike@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-5-helen.koike@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11drm/rockchip: fix fb references in async updateHelen Koike1-25/+26
commit d985a3533274ef7dd1ccb25cb05a72259b25268f upstream. In the case of async update, modifications are done in place, i.e. in the current plane state, so the new_state is prepared and the new_state is cleaned up (instead of the old_state, unlike what happens in a normal sync update). To cleanup the old_fb properly, it needs to be placed in the new_state in the end of async_update, so cleanup call will unreference the old_fb correctly. Also, the previous code had a: plane_state = plane->funcs->atomic_duplicate_state(plane); ... swap(plane_state, plane->state); if (plane->state->fb && plane->state->fb != new_state->fb) { ... } Which was wrong, as the fb were just assigned to be equal, so this if statement nevers evaluates to true. Another details is that the function drm_crtc_vblank_get() can only be called when vop->is_enabled is true, otherwise it has no effect and trows a WARN_ON(). Calling drm_atomic_set_fb_for_plane() (which get a referent of the new fb and pus the old fb) is not required, as it is taken care by drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane(). Fixes: 15609559a834 ("drm/rockchip: update cursors asynchronously through atomic.") Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by: Helen Koike <helen.koike@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-2-helen.koike@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11genwqe: Prevent an integer overflow in the ioctlDan Carpenter2-0/+6
commit 110080cea0d0e4dfdb0b536e7f8a5633ead6a781 upstream. There are a couple potential integer overflows here. round_up(m->size + (m->addr & ~PAGE_MASK), PAGE_SIZE); The first thing is that the "m->size + (...)" addition could overflow, and the second is that round_up() overflows to zero if the result is within PAGE_SIZE of the type max. In this code, the "m->size" variable is an u64 but we're saving the result in "map_size" which is an unsigned long and genwqe_user_vmap() takes an unsigned long as well. So I have used ULONG_MAX as the upper bound. From a practical perspective unsigned long is fine/better than trying to change all the types to u64. Fixes: eaf4722d4645 ("GenWQE Character device and DDCB queue") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11xen-blkfront: switch kcalloc to kvcalloc for large array allocationRoger Pau Monne1-19/+19
commit 1d5c76e66433382a1e170d1d5845bb0fed7467aa upstream. There's no reason to request physically contiguous memory for those allocations. [boris: added CC to stable] Cc: stable@vger.kernel.org Reported-by: Ian Jackson <ian.jackson@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Juergen Gross <jgross@suse.com> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11nvme-rdma: fix queue mapping when queue count is limitedSagi Grimberg1-38/+61
commit 5651cd3c43368873d0787b52acb2e0e08f3c5da4 upstream. When the controller supports less queues than requested, we should make sure that queue mapping does the right thing and not assume that all queues are available. This fixes a crash when the controller supports less queues than requested. The rules are: 1. if no write/poll queues are requested, we assign the available queues to the default queue map. The default and read queue maps share the existing queues. 2. if write queues are requested: - first make sure that read queue map gets the requested nr_io_queues count - then grant the default queue map the minimum between the requested nr_write_queues and the remaining queues. If there are no available queues to dedicate to the default queue map, fallback to (1) and share all the queues in the existing queue map. 3. if poll queues are requested: - map the remaining queues to the poll queue map. Also, provide a log indication on how we constructed the different queue maps. Reported-by: Harris, James R <james.r.harris@intel.com> Reviewed-by: Max Gurtovoy <maxg@mellanox.com> Tested-by: Jim Harris <james.r.harris@intel.com> Cc: <stable@vger.kernel.org> # v5.0+ Signed-off-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11i2c: xiic: Add max_read_len quirkRobert Hancock1-0/+5
commit 49b809586730a77b57ce620b2f9689de765d790b upstream. This driver does not support reading more than 255 bytes at once because the register for storing the number of bytes to read is only 8 bits. Add a max_read_len quirk to enforce this. This was found when using this driver with the SFP driver, which was previously reading all 256 bytes in the SFP EEPROM in one transaction. This caused a bunch of hard-to-debug errors in the xiic driver since the driver/logic was treating the number of bytes to read as zero. Rejecting transactions that aren't supported at least allows the problem to be diagnosed more easily. Signed-off-by: Robert Hancock <hancock@sedsystems.ca> Reviewed-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11mmc: sdhci_am654: Fix SLOTTYPE writeFaiz Abbas1-1/+1
commit 7397993145872c74871ab2aa7fa26a427144088a upstream. In the call to regmap_update_bits() for SLOTTYPE, the mask and value fields are exchanged. Fix this. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Fixes: 41fd4caeb00b ("mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11mmc: tmio: fix SCC error handling to avoid false positive CRC errorTakeshi Saito1-1/+2
commit 51b72656bb39fdcb8f3174f4007bcc83ad1d275f upstream. If an SCC error occurs during a read/write command execution, a false positive CRC error message is output. mmcblk0: response CRC error sending r/w cmd command, card status 0x900 check_scc_error() checks SCC_RVSREQ.RVSERR bit. RVSERR detects a correction error in the next (up or down) delay tap position. However, since the command is successful, only retuning needs to be executed. This has been confirmed by HW engineers. Thus, on SCC error, set retuning flag instead of setting an error code. Fixes: b85fb0a1c8ae ("mmc: tmio: Fix SCC error detection") Signed-off-by: Takeshi Saito <takeshi.saito.xv@renesas.com> [wsa: updated comment and commit message, removed some braces] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11memstick: mspro_block: Fix an error code in mspro_block_issue_req()Dan Carpenter1-7/+6
commit 61009f82a93f7c0b33cd9b3b263a6ab48f8b49d4 upstream. We accidentally changed the error code from -EAGAIN to 1 when we did the blk-mq conversion. Maybe a contributing factor to this mistake is that it wasn't obvious that the "while (chunk) {" condition is always true. I have cleaned that up as well. Fixes: d0be12274dad ("mspro_block: convert to blk-mq") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11parisc: Use implicit space register selection for loading the coherence ↵John David Anglin2-5/+2
index of I/O pdirs commit 63923d2c3800919774f5c651d503d1dd2adaddd5 upstream. We only support I/O to kernel space. Using %sr1 to load the coherence index may be racy unless interrupts are disabled. This patch changes the code used to load the coherence index to use implicit space register selection. This saves one instruction and eliminates the race. Tested on rp3440, c8000 and c3750. Signed-off-by: John David Anglin <dave.anglin@bell.net> Cc: stable@vger.kernel.org Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11habanalabs: fix debugfs codeJann Horn1-42/+18
commit 8438846cce61e284a22316c13aa4b63772963070 upstream. This fixes multiple things in the habanalabs debugfs code, in particular: - mmu_write() was unnecessarily verbose, copying around between multiple buffers - mmu_write() could write a user-specified, unbounded amount of userspace memory into a kernel buffer (out-of-bounds write) - multiple debugfs read handlers ignored the user-supplied count, potentially corrupting out-of-bounds userspace data - hl_device_read() was unnecessarily verbose - hl_device_write() could read uninitialized stack memory - multiple debugfs read handlers copied terminating null characters to userspace Signed-off-by: Jann Horn <jannh@google.com> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11net/mlx4_en: ethtool, Remove unsupported SFP EEPROM high pages queryErez Alfasi2-6/+3
[ Upstream commit 135dd9594f127c8a82d141c3c8430e9e2143216a ] Querying EEPROM high pages data for SFP module is currently not supported by our driver but is still tried, resulting in invalid FW queries. Set the EEPROM ethtool data length to 256 for SFP module to limit the reading for page 0 only and prevent invalid FW queries. Fixes: 7202da8b7f71 ("ethtool, net/mlx4_en: Cable info, get_module_info/eeprom ethtool support") Signed-off-by: Erez Alfasi <ereza@mellanox.com> Signed-off-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11net: aquantia: fix wol configuration not applied sometimesNikita Danilov2-8/+10
[ Upstream commit 930b9a0543385d4eb8ef887e88cf84d95a844577 ] WoL magic packet configuration sometimes does not work due to couple of leakages found. Mainly there was a regression introduced during readx_poll refactoring. Next, fw request waiting time was too small. Sometimes that caused sleep proxy config function to return with an error and to skip WoL configuration. At last, WoL data were passed to FW from not clean buffer. That could cause FW to accept garbage as a random configuration data. Fixes: 6a7f2277313b ("net: aquantia: replace AQ_HW_WAIT_FOR with readx_poll_timeout_atomic") Signed-off-by: Nikita Danilov <nikita.danilov@aquantia.com> Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11net: sfp: read eeprom in maximum 16 byte incrementsRussell King1-4/+20
[ Upstream commit 28e74a7cfd6403f0d1c0f8b10b45d6fae37b227e ] Some SFP modules do not like reads longer than 16 bytes, so read the EEPROM in chunks of 16 bytes at a time. This behaviour is not specified in the SFP MSAs, which specifies: "The serial interface uses the 2-wire serial CMOS E2PROM protocol defined for the ATMEL AT24C01A/02/04 family of components." and "As long as the SFP+ receives an acknowledge, it shall serially clock out sequential data words. The sequence is terminated when the host responds with a NACK and a STOP instead of an acknowledge." We must avoid breaking a read across a 16-bit quantity in the diagnostic page, thankfully all 16-bit quantities in that page are naturally aligned. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11net: mvpp2: Use strscpy to handle stat stringsMaxime Chevallier1-2/+2
[ Upstream commit d37acd5aa99c57505b64913e0e2624ec3daed8c5 ] Use a safe strscpy call to copy the ethtool stat strings into the relevant buffers, instead of a memcpy that will be accessing out-of-bound data. Fixes: 118d6298f6f0 ("net: mvpp2: add ethtool GOP statistics") Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-11net: ethernet: ti: cpsw_ethtool: fix ethtool ring param setIvan Khoronzhuk1-0/+1
[ Upstream commit 09faf5a7d7c0bcb07faba072f611937af9dd5788 ] Fix ability to set RX descriptor number, the reason - initially "tx_max_pending" was set incorrectly, but the issue appears after adding sanity check, so fix is for "sanity" patch. Fixes: 37e2d99b59c476 ("ethtool: Ensure new ring parameters are within bounds during SRINGPARAM") Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09drm/cma-helper: Fix drm_gem_cma_free_object()Noralf Trønnes1-4/+4
commit 23e35c0eb81a23d40c079a7eb187fc321fa1deb7 upstream. The logic for freeing an imported buffer with a virtual address is broken. It will free the buffer instead of unmapping the dma buf. Fix by reversing the if ladder and first check if the buffer is imported. Fixes: b9068cde51ee ("drm/cma-helper: Add DRM_GEM_CMA_VMAP_DRIVER_OPS") Cc: stable@vger.kernel.org Reported-by: "Li, Tingqian" <tingqian.li@intel.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190426124753.53722-1-noralf@tronnes.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09drm/lease: Make sure implicit planes are leasedDaniel Vetter2-0/+12
commit 204f640da6914844b3270b41b29c84f6e3b74083 upstream. If userspace doesn't enable universal planes, then we automatically add the primary and cursor planes. But for universal userspace there's no such check (and maybe we only want to give the lessee one plane, maybe not even the primary one), hence we need to check for the implied plane. v2: don't forget setcrtc ioctl. v3: Still allow disabling of the crtc in SETCRTC. Cc: stable@vger.kernel.org Cc: Keith Packard <keithp@keithp.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190228144910.26488-6-daniel.vetter@ffwll.ch Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09drm/rockchip: shutdown drm subsystem on shutdownVicente Bergas1-0/+9
commit b8f9d7f37b6af829c34c49d1a4f73ce6ed58e403 upstream. As explained by Robin Murphy: > the IOMMU shutdown disables paging, so if the VOP is still > scanning out then that will result in whatever IOVAs it was using now going > straight out onto the bus as physical addresses. We had a more radical approach before in commit 7f3ef5dedb14 ("drm/rockchip: Allow driver to be shutdown on reboot/kexec") but that resulted in new warnings and oopses on shutdown on rk3399 chromeos devices. So second try is resurrecting Vicentes shutdown change which should achieve the same result but in a less drastic way. Fixes: 63238173b2fa ("Revert "drm/rockchip: Allow driver to be shutdown on reboot/kexec"") Cc: Jeffy Chen <jeffy.chen@rock-chips.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Brian Norris <briannorris@chromium.org> Cc: Doug Anderson <dianders@chromium.org> Cc: stable@vger.kernel.org Suggested-by: JeffyChen <jeffy.chen@rock-chips.com> Suggested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Vicente Bergas <vicencb@gmail.com> [adapted commit message to explain the history] Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Brian Norris <briannorris@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Acked-by: Marc Zyngier <marc.zyngier@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190402113753.10118-1-heiko@sntech.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09drm: Expose "FB_DAMAGE_CLIPS" property to atomic aware user-space onlyDeepak Rawat1-2/+3
commit c8f005684c98f4d9942baec13ad98054dbf312a0 upstream. Plane property "FB_DAMAGE_CLIPS" can only be used by atomic aware user-space, so no point exposing it otherwise. Cc: <stable@vger.kernel.org> Signed-off-by: Deepak Rawat <drawat@vmware.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: d3b21767821e ("drm: Add a new plane property to send damage during plane update") Link: https://patchwork.freedesktop.org/patch/msgid/20190415172814.9840-1-drawat@vmware.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09drm/atomic: Wire file_priv through for property changesDaniel Vetter3-15/+23
commit 36e4523aaf4a35de963e190064b53839fa131653 upstream. We need this to make sure lessees can only connect their plane/connectors to crtc objects they own. And note that this is irrespective of whether the lessor is atomic or not, lessor cannot prevent lessees from enabling atomic. Cc: stable@vger.kernel.org Cc: Keith Packard <keithp@keithp.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190228144910.26488-7-daniel.vetter@ffwll.ch Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09drm/fb-helper: generic: Call drm_client_add() after setup is doneNoralf Trønnes1-2/+2
commit 6e3f17ee73f7e3c2ef0e2c8fd8624b2ece8ef2c9 upstream. Hotplug can happen while drm_fbdev_generic_setup() is running so move drm_client_add() call after setup is done to avoid drm_fbdev_client_hotplug() running in two threads at the same time. Fixes: 9060d7f49376 ("drm/fb-helper: Finish the generic fbdev emulation") Cc: stable@vger.kernel.org Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190401141358.25309-1-noralf@tronnes.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09drm/imx: ipuv3-plane: fix atomic update status query for non-plus i.MX6QPhilipp Zabel2-6/+8
commit 137caa702f2308f7ef03876e164b0d0f3300712a upstream. The current buffer check halves the frame rate on non-plus i.MX6Q, as the IDMAC current buffer pointer is not yet updated when ipu_plane_atomic_update_pending is called from the EOF irq handler. Fixes: 70e8a0c71e9 ("drm/imx: ipuv3-plane: add function to query atomic update status") Tested-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09drm/sun4i: Fix sun8i HDMI PHY configuration for > 148.5 MHzJernej Skrabec1-1/+2
commit 831adffb3b7b8df4c8e20b7b00843129fb87a166 upstream. Vendor provided documentation says that EMP bits should be set to 3 for pixel clocks greater than 148.5 MHz. Fix that. Cc: stable@vger.kernel.org # 4.17+ Fixes: 4f86e81748fe ("drm/sun4i: Add support for H3 HDMI PHY variant") Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190514204337.11068-3-jernej.skrabec@siol.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09drm/sun4i: Fix sun8i HDMI PHY clock initializationJernej Skrabec1-12/+14
commit 8a943c6021ba8b95a36c842327e468df1fddd4a7 upstream. Current code initializes HDMI PHY clock driver before reset line is deasserted and clocks enabled. Because of that, initial readout of clock divider is incorrect (0 instead of 2). This causes any clock rate with divider 1 (register value 0) to be set incorrectly. Fix this by moving initialization of HDMI PHY clock driver after reset line is deasserted and clocks enabled. Cc: stable@vger.kernel.org # 4.17+ Fixes: 4f86e81748fe ("drm/sun4i: Add support for H3 HDMI PHY variant") Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190514204337.11068-2-jernej.skrabec@siol.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09drm/vmwgfx: Don't send drm sysfs hotplug events on initial master setThomas Hellstrom1-1/+7
commit 63cb44441826e842b7285575b96db631cc9f2505 upstream. This may confuse user-space clients like plymouth that opens a drm file descriptor as a result of a hotplug event and then generates a new event... Cc: <stable@vger.kernel.org> Fixes: 5ea1734827bb ("drm/vmwgfx: Send a hotplug event at master_set") Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09drm/vmwgfx: Fix compat mode shader operationThomas Hellstrom1-0/+13
commit e41c20cf50a8a7d0dfa337a7530590aacef4193b upstream. In compat mode, we allowed host-backed user-space with guest-backed kernel / device. In this mode, set shader commands was broken since no relocations were emitted. Fix this. Cc: <stable@vger.kernel.org> Fixes: e8c66efbfe3a ("drm/vmwgfx: Make user resource lookups reference-free during validation") Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09drm/vmwgfx: Fix user space handle equal to zeroThomas Hellstrom1-1/+1
commit 8407f8a1d940fe28c4243ad4f0cb6a44dcee88f6 upstream. User-space handles equal to zero are interpreted as uninitialized or illegal by some drm systems (most notably kms). This means that a dumb buffer or surface with a zero user-space handle can never be used as a kms frame-buffer. Cc: <stable@vger.kernel.org> Fixes: c7eae62666ad ("drm/vmwgfx: Make the object handles idr-generated") Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09drm/tegra: gem: Fix CPU-cache maintenance for BO's allocated using get_pages()Dmitry Osipenko1-2/+2
commit 61b51fb51c01a519a249d28ec55c6513a13be5a3 upstream. The allocated pages need to be invalidated in CPU caches. On ARM32 the DMA_BIDIRECTIONAL flag only ensures that data is written-back to DRAM and the data stays in CPU cache lines. While the DMA_FROM_DEVICE flag ensures that the corresponding CPU cache lines are getting invalidated and nothing more, that's exactly what is needed for a newly allocated pages. This fixes randomly failing rendercheck tests on Tegra30 using the Opentegra driver for tests that use small-sized pixmaps (10x10 and less, i.e. 1-2 memory pages) because apparently CPU reads out stale data from caches and/or that data is getting evicted to DRAM at the time of HW job execution. Fixes: bd43c9f0fa1f ("drm/tegra: gem: Map pages via the DMA API") Cc: stable <stable@vger.kernel.org> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09staging: wlan-ng: fix adapter initialization failureTim Collier1-1/+2
commit a67fedd788182764dc8ed59037c604b7e60349f1 upstream. Commit e895f00a8496 ("Staging: wlan-ng: hfa384x_usb.c Fixed too long code line warnings.") moved the retrieval of the transfer buffer from the URB from the top of function hfa384x_usbin_callback to a point after reposting of the URB via a call to submit_rx_urb. The reposting of the URB allocates a new transfer buffer so the new buffer is retrieved instead of the buffer containing the response passed into the callback. This results in failure to initialize the adapter with an error reported in the system log (something like "CTLX[1] error: state(Request failed)"). This change moves the retrieval to just before the point where the URB is reposted so that the correct transfer buffer is retrieved and initialization of the device succeeds. Signed-off-by: Tim Collier <osdevtc@gmail.com> Fixes: e895f00a8496 ("Staging: wlan-ng: hfa384x_usb.c Fixed too long code line warnings.") Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09staging: vc04_services: prevent integer overflow in create_pagelist()Dan Carpenter1-0/+9
commit ca641bae6da977d638458e78cd1487b6160a2718 upstream. The create_pagelist() "count" parameter comes from the user in vchiq_ioctl() and it could overflow. If you look at how create_page() is called in vchiq_prepare_bulk_data(), then the "size" variable is an int so it doesn't make sense to allow negatives or larger than INT_MAX. I don't know this code terribly well, but I believe that typical values of "count" are typically quite low and I don't think this check will affect normal valid uses at all. The "pagelist_size" calculation can also overflow on 32 bit systems, but not on 64 bit systems. I have added an integer overflow check for that as well. The Raspberry PI doesn't offer the same level of memory protection that x86 does so these sorts of bugs are probably not super critical to fix. Fixes: 71bad7f08641 ("staging: add bcm2708 vchiq driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09serial: sh-sci: disable DMA for uart_consoleGeorge G. Davis1-0/+7
commit 099506cbbc79c0bd52b19cb6b930f256dabc3950 upstream. As noted in commit 84b40e3b57ee ("serial: 8250: omap: Disable DMA for console UART"), UART console lines use low-level PIO only access functions which will conflict with use of the line when DMA is enabled, e.g. when the console line is also used for systemd messages. So disable DMA support for UART console lines. Reported-by: Michael Rodin <mrodin@de.adit-jv.com> Link: https://patchwork.kernel.org/patch/10929511/ Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: stable@vger.kernel.org Signed-off-by: George G. Davis <george_davis@mentor.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09vt/fbcon: deinitialize resources in visual_init() after failed memory allocationGrzegorz Halat2-3/+10
commit a1ad1cc9704f64c169261a76e1aee1cf1ae51832 upstream. After memory allocation failure vc_allocate() doesn't clean up data which has been initialized in visual_init(). In case of fbcon this leads to divide-by-0 in fbcon_init() on next open of the same tty. memory allocation in vc_allocate() may fail here: 1097: vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size, GFP_KERNEL); on next open() fbcon_init() skips vc_font.data initialization: 1088: if (!p->fontdata) { division by zero in fbcon_init() happens here: 1149: new_cols /= vc->vc_font.width; Additional check is needed in fbcon_deinit() to prevent usage of uninitialized vc_screenbuf: 1251: if (vc->vc_hi_font_mask && vc->vc_screenbuf) 1252: set_vc_hi_font(vc, false); Crash: #6 [ffffc90001eafa60] divide_error at ffffffff81a00be4 [exception RIP: fbcon_init+463] RIP: ffffffff814b860f RSP: ffffc90001eafb18 RFLAGS: 00010246 ... #7 [ffffc90001eafb60] visual_init at ffffffff8154c36e #8 [ffffc90001eafb80] vc_allocate at ffffffff8154f53c #9 [ffffc90001eafbc8] con_install at ffffffff8154f624 ... Signed-off-by: Grzegorz Halat <ghalat@redhat.com> Reviewed-by: Oleksandr Natalenko <oleksandr@redhat.com> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09clk: imx: imx8mm: fix int pll clk gatePeng Fan1-6/+6
commit b3fddd5b100e4aee4f7ec58360435024971dea47 upstream. To Frac pll, the gate shift is 13, however to Int PLL the gate shift is 11. Cc: <stable@vger.kernel.org> Fixes: ba5625c3e27 ("clk: imx: Add clock driver support for imx8mm") Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Jacky Bai <ping.bai@nxp.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-09tty: max310x: Fix external crystal register setupJoe Burmeister1-1/+1
commit 5d24f455c182d5116dd5db8e1dc501115ecc9c2c upstream. The datasheet states: Bit 4: ClockEnSet the ClockEn bit high to enable an external clocking (crystal or clock generator at XIN). Set the ClockEn bit to 0 to disable clocking Bit 1: CrystalEnSet the CrystalEn bit high to enable the crystal oscillator. When using an external clock source at XIN, CrystalEn must be set low. The bit 4, MAX310X_CLKSRC_EXTCLK_BIT, should be set and was not. This was required to make the MAX3107 with an external crystal on our board able to send or receive data. Signed-off-by: Joe Burmeister <joe.burmeister@devtank.co.uk> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-26 20:12:42 +0300