summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-04-07virtio-balloon: pull page poisoning config out of free page hintingAlexander Duyck
Currently the page poisoning setting wasn't being enabled unless free page hinting was enabled. However we will need the page poisoning tracking logic as well for free page reporting. As such pull it out and make it a separate bit of config in the probe function. In addition we need to add support for the more recent init_on_free feature which expects a behavior similar to page poisoning in that we expect the page to be pre-zeroed. Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: David Hildenbrand <david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Luiz Capitulino <lcapitulino@redhat.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Michal Hocko <mhocko@kernel.org> Cc: Nitesh Narayan Lal <nitesh@redhat.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Pankaj Gupta <pagupta@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Wei Wang <wei.w.wang@intel.com> Cc: Yang Zhang <yang.zhang.wz@gmail.com> Cc: wei qi <weiqi4@huawei.com> Link: http://lkml.kernel.org/r/20200211224646.29318.695.stgit@localhost.localdomain Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-04-07nvmet-rdma: fix double free of rdma queueIsrael Rukshin
In case rdma accept fails at nvmet_rdma_queue_connect(), release work is scheduled. Later on, a new RDMA CM event may arrive since we didn't destroy the cm-id and call nvmet_rdma_queue_connect_fail(), which schedule another release work. This will cause calling nvmet_rdma_free_queue twice. To fix this we implicitly destroy the cm_id with non-zero ret code, which guarantees that new rdma_cm events will not arrive afterwards. Also add a qp pointer to nvmet_rdma_queue structure, so we can use it when the cm_id pointer is NULL or was destroyed. Signed-off-by: Israel Rukshin <israelr@mellanox.com> Suggested-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Max Gurtovoy <maxg@mellanox.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de>
2020-04-07drm/i915/gt: Yield the timeslice if caught waiting on a user semaphoreChris Wilson
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the user batch or in our own preamble, the engine raises a GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so respond to a semaphore wait by yielding the timeslice, if we have another context to yield to! The only real complication is that the interrupt is only generated for the start of the semaphore wait, and is asynchronous to our process_csb() -- that is, we may not have registered the timeslice before we see the interrupt. To ensure we don't miss a potential semaphore blocking forward progress (e.g. selftests/live_timeslice_preempt) we mark the interrupt and apply it to the next timeslice regardless of whether it was active at the time. v2: We use semaphores in preempt-to-busy, within the timeslicing implementation itself! Ergo, when we do insert a preemption due to an expired timeslice, the new context may start with the missed semaphore flagged by the retired context and be yielded, ad infinitum. To avoid this, read the context id at the time of the semaphore interrupt and only yield if that context is still active. Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200407130811.17321-1-chris@chris-wilson.co.uk
2020-04-07drm/i915/gem: Promote 'remain' to unsigned longChris Wilson
Tidy the code by casting remain to unsigned long once for the duration of eb_relocate_vma() Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200407085930.19421-1-chris@chris-wilson.co.uk
2020-04-07ipmi: kcs: Fix aspeed_kcs_probe_of_v1()Dan Carpenter
This needs to return the newly allocated struct but instead it returns zero which leads to an immediate Oops in the caller. Fixes: 09f5f680707e ("ipmi: kcs: aspeed: Implement v2 bindings") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Message-Id: <20200407122149.GA100026@mwanda> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-04-07xen/blkfront: fix memory allocation flags in blkfront_setup_indirect()Juergen Gross
Commit 1d5c76e664333 ("xen-blkfront: switch kcalloc to kvcalloc for large array allocation") didn't fix the issue it was meant to, as the flags for allocating the memory are GFP_NOIO, which will lead the memory allocation falling back to kmalloc(). So instead of GFP_NOIO use GFP_KERNEL and do all the memory allocation in blkfront_setup_indirect() in a memalloc_noio_{save,restore} section. Fixes: 1d5c76e664333 ("xen-blkfront: switch kcalloc to kvcalloc for large array allocation") Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Link: https://lore.kernel.org/r/20200403090034.8753-1-jgross@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2020-04-07xen: Use evtchn_type_t as a type for event channelsYan Yankovskyi
Make event channel functions pass event channel port using evtchn_port_t type. It eliminates signed <-> unsigned conversion. Signed-off-by: Yan Yankovskyi <yyankovskyi@gmail.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/20200323152343.GA28422@kbp1-lhp-F74019 Signed-off-by: Juergen Gross <jgross@suse.com>
2020-04-07virtio-balloon: Revert "virtio-balloon: Switch back to OOM handler for ↵Michael S. Tsirkin
VIRTIO_BALLOON_F_DEFLATE_ON_OOM" This reverts commit 5a6b4cc5b7a1892a8d7f63d6cbac6e0ae2a9d031. It has been queued properly in the akpm tree, this version is just creating conflicts. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2020-04-07drm/nouveau/kms/nv50-: wait for FIFO space on PIO channelsBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-04-07drm/nouveau/nvif: protect waits against GPU falling off the busBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-04-07drm/nouveau/nvif: access PTIMER through usermode class, if availableBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-04-07drm/nouveau/gr/gp107,gp108: implement workaround for HW hanging during initBen Skeggs
Certain boards with GP107/GP108 chipsets hang (often, but randomly) for unknown reasons during GR initialisation. The first tell-tale symptom of this issue is: nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 409800 [ TIMEOUT ] appearing in dmesg, likely followed by many other failures being logged. Karol found this WAR for the issue a while back, but efforts to isolate the root cause and proper fix have not yielded success so far. I've modified the original patch to include a few more details, limit it to GP107/GP108 by default, and added a config option to override this choice. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com>
2020-04-07drm/nouveau: workaround runpm fail by disabling PCI power management on ↵Karol Herbst
certain intel bridges Fixes the infamous 'runtime PM' bug many users are facing on Laptops with Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU. Depending on the used kernel there might be messages like those in demsg: "nouveau 0000:01:00.0: Refused to change power state, currently in D3" "nouveau 0000:01:00.0: can't change power state from D3cold to D0 (config space inaccessible)" followed by backtraces of kernel crashes or timeouts within nouveau. It's still unkown why this issue exists, but this is a reliable workaround and solves a very annoying issue for user having to choose between a crashing kernel or higher power consumption of their Laptops. Signed-off-by: Karol Herbst <kherbst@redhat.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Mika Westerberg <mika.westerberg@intel.com> Cc: linux-pci@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623 Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-04-07drm/nouveau/svm: remove useless SVM range checkRalph Campbell
When nouveau processes GPU faults, it checks to see if the fault address falls within the "unmanaged" range which is reserved for fixed allocations instead of addresses chosen by the core mm code. If start is greater than or equal to svmm->unmanaged.limit, then limit will also be greater than svmm->unmanaged.limit which is greater than svmm->unmanaged.start and the start = max_t(u64, start, svmm->unmanaged.limit) will change nothing. Just remove the useless lines of code. Signed-off-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-04-07drm/nouveau/svm: check for SVM initialized before migratingRalph Campbell
When migrating system memory to GPU memory, check that SVM has been enabled. Even though most errors can be ignored since migration is a performance optimization, return an error because this is a violation of the API. Signed-off-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-04-07drm/nouveau/svm: fix vma range check for migrationRalph Campbell
find_vma_intersection(mm, start, end) only guarantees that end is greater than or equal to vma->vm_start but doesn't guarantee that start is greater than or equal to vma->vm_start. The calculation for the intersecting range in nouveau_svmm_bind() isn't accounting for this and can call migrate_vma_setup() with a starting address less than vma->vm_start. This results in migrate_vma_setup() returning -EINVAL for the range instead of nouveau skipping that part of the range and migrating the rest. Signed-off-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-04-07drm/nouveau: remove checks for return value of debugfs functionsWambui Karuga
As there is no need to check for the return value of debugfs_create_file and drm_debugfs_create_files, remove unnecessary checks and error handling in nouveau_drm_debugfs_init. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-04-07drm/nouveau/ttm: evict other IO mappings when running out of BAR1 spaceBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-04-06Merge branch 'next' into for-linusDmitry Torokhov
Prepare input updates for 5.7 merge window.
2020-04-06leds: core: Fix warning message when init_dataRicardo Ribalda Delgado
The warning message when a led is renamed due to name collition can fail to show proper original name if init_data is used. Eg: [ 9.073996] leds-gpio a0040000.leds_0: Led (null) renamed to red_led_1 due to name collision Fixes: bb4e9af0348d ("leds: core: Add support for composing LED class device names") Signed-off-by: Ricardo Ribalda Delgado <ribalda@kernel.org> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-04-06leds: sort Makefile entriesPavel Machek
Sort Makefile entries to reduce risk of rejects. Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-04-06leds: ip30: label power LED as suchPavel Machek
Make label "white:power" to be consistent with dt-bindings/leds/common.h . Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-04-06leds: lm3532: make bitfield 'enabled' unsignedColin Ian King
The bitfield 'enabled' should bit unsigned, so make it unsigned. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-04-06drm/i915/gem: Wait until the context is finally retired before releasing enginesChris Wilson
If we want to percolate information back from the HW, up through the GEM context, we need to wait until the intel_context is scheduled out for the last time. This is handled by the retirement of the intel_context's barrier, i.e. by listening to the pulse after the notional unpin. So wait until the intel_context is finally retired before releasing the engine, so that we can inspect the final context state and pass it on. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200406155840.1728-3-chris@chris-wilson.co.uk
2020-04-06drm/i915: Allow asynchronous waits on the i915_active barriersChris Wilson
Allow the caller to also wait upon the barriers stored in i915_active. v2: Hook up i915_request_await_active(I915_ACTIVE_AWAIT_BARRIER) as well for completeness, and avoid the lazy GEM_BUG_ON()! v3: Pull flush_lazy_signals() under the active-ref protection as it too walks the rbtree and so we must be careful that we do not free it as we iterate. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200406155840.1728-2-chris@chris-wilson.co.uk
2020-04-06drm/i915: Make exclusive awaits on i915_active optionalChris Wilson
Later use will require asynchronous waits on the active timelines, but will not utilize an async wait on the exclusive channel. Make the await on the exclusive fence explicit in the selection flags. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200406155840.1728-1-chris@chris-wilson.co.uk
2020-04-06Merge tag 'acpi-5.7-rc1-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull more ACPI updates from Rafael Wysocki: "Additional ACPI updates. These update the ACPICA code in the kernel to the 20200326 upstream revision, fix an ACPI-related CPU hotplug deadlock on x86, update Intel Tiger Lake device IDs in some places, add a new ACPI backlight blacklist entry, update the "acpi_backlight" kernel command line switch documentation and clean up a CPPC library routine. Specifics: - Update the ACPICA code in the kernel to upstream revision 20200326 including: * Fix for a typo in a comment field (Bob Moore) * acpiExec namespace init file fixes (Bob Moore) * Addition of NHLT to the known tables list (Cezary Rojewski) * Conversion of PlatformCommChannel ASL keyword to PCC (Erik Kaneda) * acpiexec cleanup (Erik Kaneda) * WSMT-related typo fix (Erik Kaneda) * sprintf() utility function fix (John Levon) * IVRS IVHD type 11h parsing implementation (Michał Żygowski) * IVRS IVHD type 10h reserved field name fix (Michał Żygowski) - Fix ACPI-related CPU hotplug deadlock on x86 (Qian Cai) - Fix Intel Tiger Lake ACPI device IDs in several places (Gayatri Kammela) - Add ACPI backlight blacklist entry for Acer Aspire 5783z (Hans de Goede) - Fix documentation of the "acpi_backlight" kernel command line switch (Randy Dunlap) - Clean up the acpi_get_psd_map() CPPC library routine (Liguang Zhang)" * tag 'acpi-5.7-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: x86: ACPI: fix CPU hotplug deadlock thermal: int340x_thermal: fix: Update Tiger Lake ACPI device IDs platform/x86: intel-hid: fix: Update Tiger Lake ACPI device ID ACPI: Update Tiger Lake ACPI device IDs ACPI: video: Use native backlight on Acer Aspire 5783z ACPI: video: Docs update for "acpi_backlight" kernel parameter options ACPICA: Update version 20200326 ACPICA: Fixes for acpiExec namespace init file ACPICA: Add NHLT table signature ACPICA: WSMT: Fix typo, no functional change ACPICA: utilities: fix sprintf() ACPICA: acpiexec: remove redeclaration of acpi_gbl_db_opt_no_region_support ACPICA: Change PlatformCommChannel ASL keyword to PCC ACPICA: Fix IVRS IVHD type 10h reserved field name ACPICA: Implement IVRS IVHD type 11h parsing ACPICA: Fix a typo in a comment field ACPI: CPPC: clean up acpi_get_psd_map()
2020-04-06drm/i915/gem: Flush all the reloc_gpu batchChris Wilson
__i915_gem_object_flush_map() takes a byte range, so feed it the written bytes and do not mistake the u32 index as bytes! Fixes: a679f58d0510 ("drm/i915: Flush pages on acquisition") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: <stable@vger.kernel.org> # v5.2+ Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200406114821.10949-1-chris@chris-wilson.co.uk (cherry picked from commit 30c88a47f1abd5744908d3681f54dcf823fe2a12) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-04-06drm/i915/gem: Ignore readonly failures when updating relocsChris Wilson
If the user passes in a readonly reloc[], by the time we notice we have already committed to modifying the execobjects, or have indeed done so already. Reporting the failure just compounds the issue as we have no second pass to fall back to anymore. "Be damned if you do, and damned if you don't." Testcase: igt/gem_exec_reloc/readonly Fixes: 7dc8f1143778 ("drm/i915/gem: Drop relocation slowpath") References: fddcd00a49e9 ("drm/i915: Force the slow path after a user-write error") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200331162150.3635-1-chris@chris-wilson.co.uk (cherry picked from commit 97a37c919f6262fe75afc4a4eb838093bf18b032) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-04-06drm/i915/gt: Fill all the unused space in the GGTTChris Wilson
When we allocate space in the GGTT we may have to allocate a larger region than will be populated by the object to accommodate fencing. Make sure that this space beyond the end of the buffer points safely into scratch space, in case the HW tries to access it anyway (e.g. fenced access to the last tile row). v2: Preemptively / conservatively guard gen6 ggtt as well. Reported-by: Imre Deak <imre.deak@intel.com> References: https://gitlab.freedesktop.org/drm/intel/-/issues/1554 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200331152348.26946-1-chris@chris-wilson.co.uk (cherry picked from commit 4d6c18590870fbac1e65dde5e01e621c8e0ca096) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-04-06drm/i915/dp: Return the right vswing tablesJosé Roberto de Souza
DDI ports have its encoders initialized with INTEL_OUTPUT_DDI type and later eDP ports that have the type changed to INTEL_OUTPUT_EDP. But for all other DDI ports it can drive HDMI or DP depending on what user connects to the ports. ehl_get_combo_buf_trans() and tgl_get_combo_buf_trans() was checking for INTEL_OUTPUT_DP that was never true, causing wrong vswing tables being used. So here replacing the INTEL_OUTPUT_DP checks by the valid output types that this functions receives as parameters. HDMI cases will be correctly handled as it do not use encoder->type, instead it calls the functions with INTEL_OUTPUT_HDMI as type parameter and HDMI don't have retraining. v2: changed INTEL_OUTPUT_DDI to INTEL_OUTPUT_EDP and INTEL_OUTPUT_HDMI Fixes: bd3cf6f7ce20 ("drm/i915/dp/tgl+: Update combo phy vswing tables") Cc: Clinton A Taylor <clinton.a.taylor@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.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/20200330210044.130510-1-jose.souza@intel.com (cherry picked from commit 70988115ac69ecc249aa0f8e8265e8daf87bc28c) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-04-06drm/i915/icl+: Don't enable DDI IO power on a TypeC port in TBT modeImre Deak
The DDI IO power well must not be enabled for a TypeC port in TBT mode, ensure this during driver loading/system resume. This gets rid of error messages like [drm] *ERROR* power well DDI E TC2 IO state mismatch (refcount 1/enabled 0) and avoids leaking the power ref when disabling the output. Cc: <stable@vger.kernel.org> # v5.4+ Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200330152244.11316-1-imre.deak@intel.com (cherry picked from commit f77a2db27f26c3ccba0681f7e89fef083718f07f) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2020-04-06macsec: fix NULL dereference in macsec_upd_offload()Davide Caratti
macsec_upd_offload() gets the value of MACSEC_OFFLOAD_ATTR_TYPE without checking its presence in the request message, and this causes a NULL dereference. Fix it rejecting any configuration that does not include this attribute. Reported-and-tested-by: syzbot+7022ab7c383875c17eff@syzkaller.appspotmail.com Fixes: dcb780fb2795 ("net: macsec: add nla support for changing the offloading selection") Signed-off-by: Davide Caratti <dcaratti@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-06net: dsa: bcm_sf2: Ensure correct sub-node is parsedFlorian Fainelli
When the bcm_sf2 was converted into a proper platform device driver and used the new dsa_register_switch() interface, we would still be parsing the legacy DSA node that contained all the port information since the platform firmware has intentionally maintained backward and forward compatibility to client programs. Ensure that we do parse the correct node, which is "ports" per the revised DSA binding. Fixes: d9338023fb8e ("net: dsa: bcm_sf2: Make it a real platform device driver") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-06qed: remove redundant assignment to variable 'rc'Colin Ian King
The variable 'rc' is being assigned a value that is never read and it is being updated later with a new value. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-06wimax: remove some redundant assignments to variable resultColin Ian King
In function i2400m_bm_buf_alloc there is no need to use a variable 'result' to return -ENOMEM, just return the literal value. In the function i2400m_setup the variable 'result' is initialized with a value that is never read, it is a redundant assignment that can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-06Merge tag 'pm-5.7-rc1-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull more power management updates from Rafael Wysocki: "Additional power management updates. These fix a corner-case suspend-to-idle wakeup issue on systems where the ACPI SCI is shared with another wakeup source, add a kernel command line option to set pm_debug_messages via the kernel command line, add a document desctibing system-wide suspend and resume code flows, modify cpufreq Kconfig to choose schedutil as the preferred governor by default in a couple of cases and do some assorted cleanups. Specifics: - Fix corner-case suspend-to-idle wakeup issue on systems where the ACPI SCI is shared with another wakeup source (Hans de Goede). - Add document describing system-wide suspend and resume code flows to the admin guide (Rafael Wysocki). - Add kernel command line option to set pm_debug_messages (Chen Yu). - Choose schedutil as the preferred scaling governor by default on ARM big.LITTLE systems and on x86 systems using the intel_pstate driver in the passive mode (Linus Walleij, Rafael Wysocki). - Drop racy and redundant checks from the PM core's device_prepare() routine (Rafael Wysocki). - Make resume from hibernation take the hibernation_restore() return value into account (Dexuan Cui)" * tag 'pm-5.7-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: platform/x86: intel_int0002_vgpio: Use acpi_register_wakeup_handler() ACPI: PM: Add acpi_[un]register_wakeup_handler() Documentation: PM: sleep: Document system-wide suspend code flows cpufreq: Select schedutil when using big.LITTLE PM: sleep: Add pm_debug_messages kernel command line option PM: sleep: core: Drop racy and redundant checks from device_prepare() PM: hibernate: Propagate the return value of hibernation_restore() cpufreq: intel_pstate: Select schedutil as the default governor
2020-04-06mlxsw: spectrum_flower: Do not stop at FLOW_ACTION_VLAN_MANGLEPetr Machata
The handler for FLOW_ACTION_VLAN_MANGLE ends by returning whatever the lower-level function that it calls returns. If there are more actions lined up after this action, those are never offloaded. Fix by only bailing out when the called function returns an error. Fixes: a150201a70da ("mlxsw: spectrum: Add support for vlan modify TC action") Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-06mlxsw: spectrum_flower: Do not stop at FLOW_ACTION_PRIORITYPetr Machata
The handler for FLOW_ACTION_PRIORITY ends by returning whatever the lower-level function that it calls returns. If there are more actions lined up after this action, those are never offloaded. Fix by only bailing out when the called function returns an error. Fixes: 463957e3fbab ("mlxsw: spectrum_flower: Offload FLOW_ACTION_PRIORITY") Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-06r8169: change back SG and TSO to be disabled by defaultHeiner Kallweit
There has been a number of reports that using SG/TSO on different chip versions results in tx timeouts. However for a lot of people SG/TSO works fine. Therefore disable both features by default, but allow users to enable them. Use at own risk! Fixes: 93681cd7d94f ("r8169: enable HW csum and TSO") Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-06net: dsa: bcm_sf2: Do not register slave MDIO bus with OFFlorian Fainelli
We were registering our slave MDIO bus with OF and doing so with assigning the newly created slave_mii_bus of_node to the master MDIO bus controller node. This is a bad thing to do for a number of reasons: - we are completely lying about the slave MII bus is arranged and yet we still want to control which MDIO devices it probes. It was attempted before to play tricks with the bus_mask to perform that: https://www.spinics.net/lists/netdev/msg429420.html but the approach was rightfully rejected - the device_node reference counting is messed up and we are effectively doing a double probe on the devices we already probed using the master, this messes up all resources reference counts (such as clocks) The proper fix for this as indicated by David in his reply to the thread above is to use a platform data style registration so as to control exactly which devices we probe: https://www.spinics.net/lists/netdev/msg430083.html By using mdiobus_register(), our slave_mii_bus->phy_mask value is used as intended, and all the PHY addresses that must be redirected towards our slave MDIO bus is happening while other addresses get redirected towards the master MDIO bus. Fixes: 461cd1b03e32 ("net: dsa: bcm_sf2: Register our slave MDIO bus") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-06tun: Don't put_page() for all negative return values from XDP programWill Deacon
When an XDP program is installed, tun_build_skb() grabs a reference to the current page fragment page if the program returns XDP_REDIRECT or XDP_TX. However, since tun_xdp_act() passes through negative return values from the XDP program, it is possible to trigger the error path by mistake and accidentally drop a reference to the fragments page without taking one, leading to a spurious free. This is believed to be the cause of some KASAN use-after-free reports from syzbot [1], although without a reproducer it is not possible to confirm whether this patch fixes the problem. Ensure that we only drop a reference to the fragments page if the XDP transmit or redirect operations actually fail. [1] https://syzkaller.appspot.com/bug?id=e76a6af1be4acd727ff6bbca669833f98cbf5d95 Cc: "David S. Miller" <davem@davemloft.net> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> CC: Eric Dumazet <edumazet@google.com> Acked-by: Jason Wang <jasowang@redhat.com> Fixes: 8ae1aff0b331 ("tuntap: split out XDP logic") Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-04-06ACPI: EC: Fix up fast path check in acpi_ec_add()Rafael J. Wysocki
The fast path check in acpi_ec_add() is not incorrect, because in fact acpi_device_hid(device) can be equal to ACPI_ECDT_HID only if boot_ec is not NULL, but it may confuse static checkers, so change it to explicitly check boot_ec upfront and use the slow path if that pointer is NULL. Link: https://lore.kernel.org/linux-acpi/20200406144217.GA68494@mwanda/ Fixes: 3d9b8dd8320d ("ACPI: EC: Use fast path in acpi_ec_add() for DSDT boot EC") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-04-06drm/i915/gem: Take DBG_FORCE_RELOC into account prior to using reloc_gpuChris Wilson
If we set the debug flag to force ourselves not to relocate via the gpu, do not relocate via the gpu. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200406123616.7334-1-chris@chris-wilson.co.uk
2020-04-06drm/i915/gem: Flush all the reloc_gpu batchChris Wilson
__i915_gem_object_flush_map() takes a byte range, so feed it the written bytes and do not mistake the u32 index as bytes! Fixes: a679f58d0510 ("drm/i915: Flush pages on acquisition") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: <stable@vger.kernel.org> # v5.2+ Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200406114821.10949-1-chris@chris-wilson.co.uk
2020-04-06drm/i915: Extend hotplug detect retry on TypeC connectors to 5 secondsImre Deak
On TypeC ports if a sink deasserts/reasserts its HPD signal, generating a hotplug interrupt without the sink getting unplugged/replugged from the connector, there can be an up to 3 seconds delay until the AUX channel gets functional. To avoid detection failures this delay causes retry the detection for 5 seconds. I noticed this on ICL/TGL RVPs and a DELL XPS 13 7390 ICL laptop. References: https://gitlab.freedesktop.org/drm/intel/issues/1067 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200330095425.29113-2-imre.deak@intel.com
2020-04-06drm/i915: Add a retry counter for hotplug detect retriesImre Deak
On TypeC connectors we need to retry the detection after hotplug events for a longer time, so add a retry counter to support this. The next patch will add detection retries on TypeC ports needing this. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200330095425.29113-1-imre.deak@intel.com
2020-04-06Merge branches 'acpi-cppc', 'acpi-video' and 'acpi-drivers'Rafael J. Wysocki
* acpi-cppc: ACPI: CPPC: clean up acpi_get_psd_map() * acpi-video: ACPI: video: Use native backlight on Acer Aspire 5783z ACPI: video: Docs update for "acpi_backlight" kernel parameter options * acpi-drivers: thermal: int340x_thermal: fix: Update Tiger Lake ACPI device IDs platform/x86: intel-hid: fix: Update Tiger Lake ACPI device ID ACPI: Update Tiger Lake ACPI device IDs
2020-04-06Merge branch 'acpica'Rafael J. Wysocki
* acpica: ACPICA: Update version 20200326 ACPICA: Fixes for acpiExec namespace init file ACPICA: Add NHLT table signature ACPICA: WSMT: Fix typo, no functional change ACPICA: utilities: fix sprintf() ACPICA: acpiexec: remove redeclaration of acpi_gbl_db_opt_no_region_support ACPICA: Change PlatformCommChannel ASL keyword to PCC ACPICA: Fix IVRS IVHD type 10h reserved field name ACPICA: Implement IVRS IVHD type 11h parsing ACPICA: Fix a typo in a comment field
2020-04-06Merge branches 'pm-sleep' and 'pm-cpufreq'Rafael J. Wysocki
* pm-sleep: Documentation: PM: sleep: Document system-wide suspend code flows PM: sleep: Add pm_debug_messages kernel command line option PM: sleep: core: Drop racy and redundant checks from device_prepare() PM: hibernate: Propagate the return value of hibernation_restore() * pm-cpufreq: cpufreq: Select schedutil when using big.LITTLE cpufreq: intel_pstate: Select schedutil as the default governor