summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2019-10-18net: bcmgenet: reset 40nm EPHY on energy detectDoug Berger
The EPHY integrated into the 40nm Set-Top Box devices can falsely detect energy when connected to a disabled peer interface. When the peer interface is enabled the EPHY will detect and report the link as active, but on occasion may get into a state where it is not able to exchange data with the connected GENET MAC. This issue has not been observed when the link parameters are auto-negotiated; however, it has been observed with a manually configured link. It has been empirically determined that issuing a soft reset to the EPHY when energy is detected prevents it from getting into this bad state. Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") Signed-off-by: Doug Berger <opendmb@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-18net: bcmgenet: soft reset 40nm EPHYs before MAC initDoug Berger
It turns out that the "Workaround for putting the PHY in IDDQ mode" used by the internal EPHYs on 40nm Set-Top Box chips when powering down puts the interface to the GENET MAC in a state that can cause subsequent MAC resets to be incomplete. Rather than restore the forced soft reset when powering up internal PHYs, this commit moves the invocation of phy_init_hw earlier in the MAC initialization sequence to just before the MAC reset in the open and resume functions. This allows the interface to be stable and allows the MAC resets to be successful. The bcmgenet_mii_probe() function is split in two to accommodate this. The new function bcmgenet_mii_connect() handles the first half of the functionality before the MAC initialization, and the bcmgenet_mii_config() function is extended to provide the remaining PHY configuration following the MAC initialization. Fixes: 484bfa1507bf ("Revert "net: bcmgenet: Software reset EPHY after power on"") Signed-off-by: Doug Berger <opendmb@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-18net: phy: bcm7xxx: define soft_reset for 40nm EPHYDoug Berger
The internal 40nm EPHYs use a "Workaround for putting the PHY in IDDQ mode." These PHYs require a soft reset to restore functionality after they are powered back up. This commit defines the soft_reset function to use genphy_soft_reset during phy_init_hw to accommodate this. Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") Signed-off-by: Doug Berger <opendmb@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-18net: bcmgenet: don't set phydev->link from MACDoug Berger
When commit 28b2e0d2cd13 ("net: phy: remove parameter new_link from phy_mac_interrupt()") removed the new_link parameter it set the phydev->link state from the MAC before invoking phy_mac_interrupt(). However, once commit 88d6272acaaa ("net: phy: avoid unneeded MDIO reads in genphy_read_status") was added this initialization prevents the proper determination of the connection parameters by the function genphy_read_status(). This commit removes that initialization to restore the proper functionality. Fixes: 88d6272acaaa ("net: phy: avoid unneeded MDIO reads in genphy_read_status") Signed-off-by: Doug Berger <opendmb@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-18drm/i915: Correct the PCH type in irq postinstallVivek Kasireddy
JasperLake PCH (JSP) has DDI HPD pin mappings similar to TGP and not MCC. Also add the correct HPD pin mappings for the MCC PCH. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191016183514.11128-1-vivek.kasireddy@intel.com
2019-10-18Merge tag 'acpi-5.4-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "Fix possible use-after-free in the ACPI CPPC support code (John Garry) and prevent the ACPI HMAT parsing code from using possibly incorrect data coming from the platform firmware (Daniel Black)" * tag 'acpi-5.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: CPPC: Set pcc_data[pcc_ss_id] to NULL in acpi_cppc_processor_exit() ACPI: HMAT: ACPI_HMAT_MEMORY_PD_VALID is deprecated since ACPI-6.3
2019-10-18Merge tag 'pm-5.4-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "These include a fix for a recent regression in the ACPI CPU performance scaling code, a PCI device power management fix, a system shutdown fix related to cpufreq, a removal of an ACPI suspend-to-idle blacklist entry and a build warning fix. Specifics: - Fix possible NULL pointer dereference in the ACPI processor scaling initialization code introduced by a recent cpufreq update (Rafael Wysocki). - Fix possible deadlock due to suspending cpufreq too late during system shutdown (Rafael Wysocki). - Make the PCI device system resume code path be more consistent with its PM-runtime counterpart to fix an issue with missing delay on transitions from D3cold to D0 during system resume from suspend-to-idle on some systems (Rafael Wysocki). - Drop Dell XPS13 9360 from the LPS0 Idle _DSM blacklist to make it use suspend-to-idle by default (Mario Limonciello). - Fix build warning in the core system suspend support code (Ben Dooks)" * tag 'pm-5.4-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: processor: Avoid NULL pointer dereferences at init time PCI: PM: Fix pci_power_up() PM: sleep: include <linux/pm_runtime.h> for pm_wq cpufreq: Avoid cpufreq_suspend() deadlock on system shutdown ACPI: PM: Drop Dell XPS13 9360 from LPS0 Idle _DSM blacklist
2019-10-18Merge tag 'mkp-scsi-postmerge' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi Pull scsi fixes from Martin Petersen: "These two commits were in a separate postmerge branch due to a dependency on changes merged for 5.4 in the block tree. They fix two issues in the intersection of the request cleanup changes from block (b7e9e1fb7a92) and the request batching changes (8930a6c20791) that were made to SCSI during the 5.4 cycle" * tag 'mkp-scsi-postmerge' of git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi: scsi: core: fix dh and multipathing for SCSI hosts without request batching scsi: core: fix missing .cleanup_rq for SCSI hosts without request batching
2019-10-18iommu/amd: Check PM_LEVEL_SIZE() condition in locked sectionJoerg Roedel
The increase_address_space() function has to check the PM_LEVEL_SIZE() condition again under the domain->lock to avoid a false trigger of the WARN_ON_ONCE() and to avoid that the address space is increase more often than necessary. Reported-by: Qian Cai <cai@lca.pw> Fixes: 754265bcab78 ("iommu/amd: Fix race in increase_address_space()") Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-10-18Merge branch 'nvme-5.4' of git://git.infradead.org/nvme into for-linusJens Axboe
Pull NVMe updates from Keith: "This is a collection of bug fixes committed since the previous pull request that address deadlocks, double resets, memory leaks, and other regression." * 'nvme-5.4' of git://git.infradead.org/nvme: nvme-pci: Set the prp2 correctly when using more than 4k page nvme-tcp: fix possible leakage during error flow nvmet-loop: fix possible leakage during error flow nvme-tcp: Initialize sk->sk_ll_usec only with NET_RX_BUSY_POLL nvme: Wait for reset state when required nvme: Prevent resets during paused controller state nvme: Restart request timers in resetting state nvme: Remove ADMIN_ONLY state nvme-pci: Free tagset if no IO queues nvme: retain split access workaround for capability reads nvme: fix possible deadlock when nvme_update_formats fails
2019-10-18drm/i915: Make hdcp2_msg_timeout.timeout u16Ville Syrjälä
All the timeout values fit in u16, so let's shrink the structure a bit. This ends up actually increasing the .text size a bit due to some changes in instructions (constant imul+small jmps replaced with mov+bigger jmpqs). Seems pretty arbitrary to me so I'll just pretend I didn't see it. text data bss dec hex filename - 34521 360 0 34881 8841 intel_hdmi.o + 34537 360 0 34897 8851 intel_hdmi.o Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010145127.7487-5-ville.syrjala@linux.intel.com Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
2019-10-18drm/i915: Remove hdcp2_hdmi_msg_timeout.timeout2Ville Syrjälä
The only reason for the timeout2 value in the array is the HDCP_2_2_AKE_SEND_HPRIME message. But that one still needs special casing inside the loop, and so just ends up making the code harder to read. Let's just remove this leaky timeout2 abstraction and special case that one command in a way that is easy to understand. We can then remove the timeout2 member from struct entirely. text data bss dec hex filename - 34633 360 0 34993 88b1 intel_hdmi.o + 34521 360 0 34881 8841 intel_hdmi.o Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010145127.7487-4-ville.syrjala@linux.intel.com Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
2019-10-18drm/i915: Remove dead weight from hdcp2_msg_timeout[]Ville Syrjälä
The .read_2_2() hooks is never called for any of the message types with a zero timeout. So it's all just dead weight which we can chuck. text data bss dec hex filename - 34701 360 0 35061 88f5 intel_hdmi.o + 34633 360 0 34993 88b1 intel_hdmi.o Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010145127.7487-3-ville.syrjala@linux.intel.com Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
2019-10-18nvme-pci: Set the prp2 correctly when using more than 4k pageKevin Hao
In the current code, the nvme is using a fixed 4k PRP entry size, but if the kernel use a page size which is more than 4k, we should consider the situation that the bv_offset may be larger than the dev->ctrl.page_size. Otherwise we may miss setting the prp2 and then cause the command can't be executed correctly. Fixes: dff824b2aadb ("nvme-pci: optimize mapping of small single segment requests") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
2019-10-18drm/i915: s/hdcp2_hdmi_msg_data/hdcp2_hdmi_msg_timeout/Ville Syrjälä
The array is there only for timeout, "data" doesn't mean anything so let's rename the thing to be more descriptive. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010145127.7487-2-ville.syrjala@linux.intel.com Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
2019-10-18drm/i915: Shrink eDRAM ways/sets arraysVille Syrjälä
Make the ways/sets arrays static cosnt u8 to shrink things a bit. text data bss dec hex filename - 23935 629 128 24692 6074 i915_drv.o + 23818 629 128 24575 5fff i915_drv.o Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010145127.7487-1-ville.syrjala@linux.intel.com Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
2019-10-18drm/i915: Make dirty_pipes refer to pipesVille Syrjälä
Despite the its name dirty_pipes refers to crtc indexes. Let's change its behaviout to match the name. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191011200949.7839-4-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2019-10-18drm/i915: Nuke 'realloc_pipes'Ville Syrjälä
The 'realloc_pipes' bitmask is pointless. It is either: a) the set of pipes which are already part of the state, in which case adding them again is entirely redundant b) the set of all pipes which we then add to the state Also the fact that 'realloc_pipes' uses the crtc indexes is going to bite is at some point so best get rid of it quick. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191011200949.7839-3-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2019-10-18drm/i915: Nuke the useless changed param from skl_ddb_add_affected_pipes()Ville Syrjälä
changed==true just means we have some crtcs in the state. All the stuff following this only operates on crtcs in the state anyway so there is no point in having this bool. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191011200949.7839-2-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2019-10-18drm/i915: Refuse modes with hdisplay==4096 on pre-HSW DPVille Syrjälä
The DP port/pipe goes wonky if we try to use timings with hdisplay==4096 on pre-HSW platforms. The link fails to train and the pipe may not signal vblank interrupts. On HDMI such at mode works just fine (tested on ELK/SNB/CHV). So let's refuse such modes on DP on older platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190718144340.1114-1-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
2019-10-18drm/i915: Polish possible_clones setupVille Syrjälä
Replace the hand rolled stuff with drm_encoder_mask() when populating possible_clones, and rename the function to intel_encoder_possible_clones() to make it clear what it's used for. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191002162505.30716-1-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2019-10-18drm/i915: Move the cursor rotation handling into intel_cursor_check_surface()Ville Syrjälä
Unlike other planes the cursor currently handles 180 degree rotation adjustment during the hardware programming phase. Let's move that stuff into intel_cursor_check_surface() to match how we do things with other plane types. And while at we'll plop in the final src x/y coordinates (which will actually always be zero) into the src rect and color_plane[0].x/y, just for some extra consistency. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191015152757.12231-1-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2019-10-18drm/i915/gt: Convert the leftover for_each_engine(gt)Chris Wilson
Use the local gt for iterating over the available set of engines. 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/20191018115331.8980-1-chris@chris-wilson.co.uk
2019-10-18drm/i915/selftests: Add the mock engine to the gt->engine[]Chris Wilson
Remember to include the newly created mock engine in the list of available engines inside the gt. Fixes: a50134b1983b ("drm/i915: Make for_each_engine_masked work on intel_gt") 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/20191018130703.31125-1-chris@chris-wilson.co.uk
2019-10-18drm/i915: treat stolen as a regionMatthew Auld
Convert stolen memory over to a region object. Still leaves open the question with what to do with pre-allocated objects... Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191018090751.28295-3-matthew.auld@intel.com
2019-10-18drm/i915: treat shmem as a regionMatthew Auld
Convert shmem to an intel_memory_region. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191018090751.28295-2-matthew.auld@intel.com
2019-10-18drm/i915: enumerate and init each supported regionAbdiel Janulgue
Nothing to enumerate yet... Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191018090751.28295-1-matthew.auld@intel.com
2019-10-18drm/syncobj: extend syncobj query ability v3Chunming Zhou
user space needs a flexiable query ability. So that umd can get last signaled or submitted point. v2: add sanitizer checking. v3: rebase Change-Id: I6512b430524ebabe715e602a2bf5abb0a7e780ea Signed-off-by: Chunming Zhou <david1.zhou@amd.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Christian König <Christian.Koenig@amd.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/series/64044/
2019-10-18drm/i915/execlists: Don't merely skip submission if maybe timeslicingChris Wilson
Normally, we try and skip submission if ELSP[1] is filled. However, we may desire to enable timeslicing due to the queue priority, even if ELSP[1] itself does not require timeslicing. That is the queue is equal priority to ELSP[0] and higher priority then ELSP[1]. Previously, we would wait until the context switch to preempt the current ELSP[1], but with timeslicing, we want to preempt ELSP[0] and replace it with the queue. In writing the test case, it become quickly apparent that we were also suppressing the tasklet during promotion and so failing to notice when the queue started requiring timeslicing. Fixes: 2229adc81380 ("drm/i915/execlist: Trim immediate timeslice expiry") 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/20191018072027.31948-1-chris@chris-wilson.co.uk
2019-10-18drm/i915/pmu: Fix uninitialized variable on error pathTvrtko Ursulin
If name allocation failed the log message will contain an uninitialized error code which can be confusing. Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple GPUs") Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191018090514.1818-1-tvrtko.ursulin@linux.intel.com [tursulin: Commit message spelling fix.]
2019-10-18drm/arm: make undeclared items staticBen Dooks (Codethink)
Make the following items static to avoid clashes with other parts of the kernel (dev_attr_core_id) or just silence the following sparse warning: drivers/gpu/drm/arm/malidp_drv.c:371:24: warning: symbol 'malidp_fb_create' was not declared. Should it be static? drivers/gpu/drm/arm/malidp_drv.c:494:6: warning: symbol 'malidp_error_stats_dump' was not declared. Should it be static? drivers/gpu/drm/arm/malidp_drv.c:668:1: warning: symbol 'dev_attr_core_id' was not declared. Should it be static? Signed-off-by: Ben Dooks (Codethink) <ben.dooks@codethink.co.uk> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191017111756.12861-1-ben.dooks@codethink.co.uk
2019-10-18Merge branch 'acpi-tables'Rafael J. Wysocki
* acpi-tables: ACPI: HMAT: ACPI_HMAT_MEMORY_PD_VALID is deprecated since ACPI-6.3
2019-10-18ACPI: CPPC: Set pcc_data[pcc_ss_id] to NULL in acpi_cppc_processor_exit()John Garry
When enabling KASAN and DEBUG_TEST_DRIVER_REMOVE, I find this KASAN warning: [ 20.872057] BUG: KASAN: use-after-free in pcc_data_alloc+0x40/0xb8 [ 20.878226] Read of size 4 at addr ffff00236cdeb684 by task swapper/0/1 [ 20.884826] [ 20.886309] CPU: 19 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc1-00009-ge7f7df3db5bf-dirty #289 [ 20.894994] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.16.01 03/15/2019 [ 20.903505] Call trace: [ 20.905942] dump_backtrace+0x0/0x200 [ 20.909593] show_stack+0x14/0x20 [ 20.912899] dump_stack+0xd4/0x130 [ 20.916291] print_address_description.isra.9+0x6c/0x3b8 [ 20.921592] __kasan_report+0x12c/0x23c [ 20.925417] kasan_report+0xc/0x18 [ 20.928808] __asan_load4+0x94/0xb8 [ 20.932286] pcc_data_alloc+0x40/0xb8 [ 20.935938] acpi_cppc_processor_probe+0x4e8/0xb08 [ 20.940717] __acpi_processor_start+0x48/0xb0 [ 20.945062] acpi_processor_start+0x40/0x60 [ 20.949235] really_probe+0x118/0x548 [ 20.952887] driver_probe_device+0x7c/0x148 [ 20.957059] device_driver_attach+0x94/0xa0 [ 20.961231] __driver_attach+0xa4/0x110 [ 20.965055] bus_for_each_dev+0xe8/0x158 [ 20.968966] driver_attach+0x30/0x40 [ 20.972531] bus_add_driver+0x234/0x2f0 [ 20.976356] driver_register+0xbc/0x1d0 [ 20.980182] acpi_processor_driver_init+0x40/0xe4 [ 20.984875] do_one_initcall+0xb4/0x254 [ 20.988700] kernel_init_freeable+0x24c/0x2f8 [ 20.993047] kernel_init+0x10/0x118 [ 20.996524] ret_from_fork+0x10/0x18 [ 21.000087] [ 21.001567] Allocated by task 1: [ 21.004785] save_stack+0x28/0xc8 [ 21.008089] __kasan_kmalloc.isra.9+0xbc/0xd8 [ 21.012435] kasan_kmalloc+0xc/0x18 [ 21.015913] pcc_data_alloc+0x94/0xb8 [ 21.019564] acpi_cppc_processor_probe+0x4e8/0xb08 [ 21.024343] __acpi_processor_start+0x48/0xb0 [ 21.028689] acpi_processor_start+0x40/0x60 [ 21.032860] really_probe+0x118/0x548 [ 21.036512] driver_probe_device+0x7c/0x148 [ 21.040684] device_driver_attach+0x94/0xa0 [ 21.044855] __driver_attach+0xa4/0x110 [ 21.048680] bus_for_each_dev+0xe8/0x158 [ 21.052591] driver_attach+0x30/0x40 [ 21.056155] bus_add_driver+0x234/0x2f0 [ 21.059980] driver_register+0xbc/0x1d0 [ 21.063805] acpi_processor_driver_init+0x40/0xe4 [ 21.068497] do_one_initcall+0xb4/0x254 [ 21.072322] kernel_init_freeable+0x24c/0x2f8 [ 21.076667] kernel_init+0x10/0x118 [ 21.080144] ret_from_fork+0x10/0x18 [ 21.083707] [ 21.085186] Freed by task 1: [ 21.088056] save_stack+0x28/0xc8 [ 21.091360] __kasan_slab_free+0x118/0x180 [ 21.095445] kasan_slab_free+0x10/0x18 [ 21.099183] kfree+0x80/0x268 [ 21.102139] acpi_cppc_processor_exit+0x1a8/0x1b8 [ 21.106832] acpi_processor_stop+0x70/0x80 [ 21.110917] really_probe+0x174/0x548 [ 21.114568] driver_probe_device+0x7c/0x148 [ 21.118740] device_driver_attach+0x94/0xa0 [ 21.122912] __driver_attach+0xa4/0x110 [ 21.126736] bus_for_each_dev+0xe8/0x158 [ 21.130648] driver_attach+0x30/0x40 [ 21.134212] bus_add_driver+0x234/0x2f0 [ 21.0x10/0x18 [ 21.161764] [ 21.163244] The buggy address belongs to the object at ffff00236cdeb600 [ 21.163244] which belongs to the cache kmalloc-256 of size 256 [ 21.175750] The buggy address is located 132 bytes inside of [ 21.175750] 256-byte region [ffff00236cdeb600, ffff00236cdeb700) [ 21.187473] The buggy address belongs to the page: [ 21.192254] page:fffffe008d937a00 refcount:1 mapcount:0 mapping:ffff002370c0fa00 index:0x0 compound_mapcount: 0 [ 21.202331] flags: 0x1ffff00000010200(slab|head) [ 21.206940] raw: 1ffff00000010200 dead000000000100 dead000000000122 ffff002370c0fa00 [ 21.214671] raw: 0000000000000000 00000000802a002a 00000001ffffffff 0000000000000000 [ 21.222400] page dumped because: kasan: bad access detected [ 21.227959] [ 21.229438] Memory state around the buggy address: [ 21.234218] ffff00236cdeb580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 21.241427] ffff00236cdeb600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 21.248637] >ffff00236cdeb680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 21.255845] ^ [ 21.259062] ffff00236cdeb700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 21.266272] ffff00236cdeb780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 21.273480] ================================================================== It seems that global pcc_data[pcc_ss_id] can be freed in acpi_cppc_processor_exit(), but we may later reference this value, so NULLify it when freed. Also remove the useless setting of data "pcc_channel_acquired", which we're about to free. Fixes: 85b1407bf6d2 ("ACPI / CPPC: Make CPPC ACPI driver aware of PCC subspace IDs") Signed-off-by: John Garry <john.garry@huawei.com> Cc: 4.15+ <stable@vger.kernel.org> # 4.15+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-10-18Merge branches 'pm-cpufreq' and 'pm-sleep'Rafael J. Wysocki
* pm-cpufreq: ACPI: processor: Avoid NULL pointer dereferences at init time cpufreq: Avoid cpufreq_suspend() deadlock on system shutdown * pm-sleep: PM: sleep: include <linux/pm_runtime.h> for pm_wq ACPI: PM: Drop Dell XPS13 9360 from LPS0 Idle _DSM blacklist
2019-10-17net: phy: micrel: Update KSZ87xx PHY nameMarek Vasut
The KSZ8795 PHY ID is in fact used by KSZ8794/KSZ8795/KSZ8765 switches. Update the PHY ID and name to reflect that, as this family of switches is commonly refered to as KSZ87xx Signed-off-by: Marek Vasut <marex@denx.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: David S. Miller <davem@davemloft.net> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: George McCollister <george.mccollister@gmail.com> Cc: Heiner Kallweit <hkallweit1@gmail.com> Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk> Cc: Tristram Ha <Tristram.Ha@microchip.com> Cc: Woojung Huh <woojung.huh@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-17net: phy: micrel: Discern KSZ8051 and KSZ8795 PHYsMarek Vasut
The KSZ8051 PHY and the KSZ8794/KSZ8795/KSZ8765 switch share exactly the same PHY ID. Since KSZ8051 is higher in the ksphy_driver[] list of PHYs in the micrel PHY driver, it is used even with the KSZ87xx switch. This is wrong, since the KSZ8051 configures registers of the PHY which are not present on the simplified KSZ87xx switch PHYs and misconfigures other registers of the KSZ87xx switch PHYs. Fortunatelly, it is possible to tell apart the KSZ8051 PHY from the KSZ87xx switch by checking the Basic Status register Bit 0, which is read-only and indicates presence of the Extended Capability Registers. The KSZ8051 PHY has those registers while the KSZ87xx switch does not. This patch implements simple check for the presence of this bit for both the KSZ8051 PHY and KSZ87xx switch, to let both use the correct PHY driver instance. Fixes: 9d162ed69f51 ("net: phy: micrel: add support for KSZ8795") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: David S. Miller <davem@davemloft.net> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: George McCollister <george.mccollister@gmail.com> Cc: Heiner Kallweit <hkallweit1@gmail.com> Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk> Cc: Tristram Ha <Tristram.Ha@microchip.com> Cc: Woojung Huh <woojung.huh@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-18drm/i915: Pass in intel_gt at some for_each_engine sitesTvrtko Ursulin
Where the function, or code segment, operates on intel_gt, we need to start passing it instead of i915 to for_each_engine(_masked). This is another partial step in migration of i915->engines[] to gt->engines[]. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191017094500.21831-2-tvrtko.ursulin@linux.intel.com
2019-10-18drm/i915: Make for_each_engine_masked work on intel_gtTvrtko Ursulin
Medium term goal is to eliminate the i915->engine[] array and to get there we have recently introduced equivalent array in intel_gt. Now we need to migrate the code further towards this state. This next step is to eliminate usage of i915->engines[] from the for_each_engine_masked iterator. For this to work we also need to use engine->id as index when populating the gt->engine[] array and adjust the default engine set indexing to use engine->legacy_idx instead of assuming gt->engines[] indexing. v2: * Populate gt->engine[] earlier. * Check that we don't duplicate engine->legacy_idx v3: * Work around the initialization order issue between default_engines() and intel_engines_driver_register() which sets engine->legacy_idx for now. It will be fixed properly later. v4: * Merge with forgotten v2.5. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191017161852.8836-1-tvrtko.ursulin@linux.intel.com
2019-10-17Merge tag 'drm-fixes-2019-10-18' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
Pull drm fixes from Dave Airlie: "This is this weeks fixes for drm. The dma-resv one is probably the more important one a fair few people have reported it, besides that it's a couple of panfrost, a few i915 and a few amdgpu fixes. One radeon patch to fix some ppc64 related issues caused an x86 regression so is getting reverted for now. Summary: dma-resv: - shared fences for lima/panfrost ttm: - prefault regression fix - lifetime fix panfrost: - stopped job timeout fix - missing register values amdgpu: - smu7 powerplay fix - bail earlier for cik/si detection - navi SDMA fix radeon: - revert a ppc64 shutdown fix that broke x86 i915: - VBT information handling fix - Circular locking fix - preemption vs resubmission virtual requests fix" * tag 'drm-fixes-2019-10-18' of git://anongit.freedesktop.org/drm/drm: drm/i915: Fixup preempt-to-busy vs resubmission of a virtual request drm/i915/userptr: Never allow userptr into the mappable GGTT drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pin drm/i915/execlists: Refactor -EIO markup of hung requests drm/panfrost: Handle resetting on timeout better drm/panfrost: Add missing GPU feature registers drm/ttm: fix handling in ttm_bo_add_mem_to_lru drm/ttm: Restore ttm prefaulting drm/ttm: fix busy reference in ttm_mem_evict_first drm/amdgpu/sdma5: fix mask value of POLL_REGMEM packet for pipe sync drm/amdgpu: Bail earlier when amdgpu.cik_/si_support is not set to 1 Revert "drm/radeon: Fix EEH during kexec" drm/msm/dsi: Implement reset correctly dma-buf/resv: fix exclusive fence get drm/edid: Add 6 bpc quirk for SDC panel in Lenovo G50 drm/tiny: Kconfig: Remove always-y THERMAL dep. from TINYDRM_REPAPER drm/amdgpu/powerplay: fix typo in mvdd table setup
2019-10-17drm/i915: Don't disable interrupts independently of the lockSebastian Andrzej Siewior
The locks (active.lock and rq->lock) need to be taken with disabled interrupts. This is done in i915_request_retire() by disabling the interrupts independently of the locks itself. While local_irq_disable()+spin_lock() equals spin_lock_irq() on vanilla it does not on PREEMPT_RT. Chris Wilson confirmed that local_irq_disable() was just introduced as an optimisation to avoid enabling/disabling interrupts during lock/unlock combo. Enable/disable interrupts as part of the locking instruction. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191017161352.e5z3ugse7gxl5ari@linutronix.de
2019-10-18Merge tag 'drm-misc-fixes-2019-10-17' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes -dma-resv: Change shared_count to post-increment to fix lima crash (Qiang) -ttm: A couple fixes related to lifetime and restore prefault behavior (Christian & Thomas) -panfrost: Fill in missing feature reg values and fix stoppedjob timeouts (Steven) Cc: Qiang Yu <yuq825@gmail.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Christian König <christian.koenig@amd.com> Cc: Steven Price <steven.price@arm.com> Signed-off-by: Dave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20191017203419.GA142909@art_vandelay
2019-10-17drm/i915/selftests: Teach requests to use all available enginesChris Wilson
The request selftests straddle the boundary between checking the driver and the hardware. They are subject to the quirks of the underlying HW, but operate on top of the backend abstractions. The tests focus on the scheduler elements and so should check for interactions of the scheduler across all exposed engines. 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/20191016125236.17960-1-chris@chris-wilson.co.uk
2019-10-18Merge tag 'drm-fixes-5.4-2019-10-16' of ↵Dave Airlie
git://people.freedesktop.org/~agd5f/linux into drm-fixes drm-fixes-5.4-2019-10-16: amdgpu: - Powerplay fix for SMU7 parts - Bail earlier when cik/si support is not set to 1 - Fix an SDMA issue on navi radeon: - revert a PPC fix which broken x86 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191017022443.3853-1-alexander.deucher@amd.com
2019-10-17net: dsa: microchip: Add shared regmap mutexMarek Vasut
The KSZ driver uses one regmap per register width (8/16/32), each with it's own lock, but accessing the same set of registers. In theory, it is possible to create a race condition between these regmaps, although the underlying bus (SPI or I2C) locking should assure nothing bad will really happen and the accesses would be correct. To make the driver do the right thing, add one single shared mutex for all the regmaps used by the driver instead. This assures that even if some future hardware is on a bus which does not serialize the accesses the same way SPI or I2C does, nothing bad will happen. Note that the status_mutex was unused and only initied, hence it was renamed and repurposed as the regmap mutex. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: David S. Miller <davem@davemloft.net> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: George McCollister <george.mccollister@gmail.com> Cc: Tristram Ha <Tristram.Ha@microchip.com> Cc: Woojung Huh <woojung.huh@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-17net: dsa: microchip: Do not reinit mutexes on KSZ87xxMarek Vasut
The KSZ87xx driver calls mutex_init() on mutexes already inited in ksz_common.c ksz_switch_register(). Do not do it twice, drop the reinitialization. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: David S. Miller <davem@davemloft.net> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: George McCollister <george.mccollister@gmail.com> Cc: Tristram Ha <Tristram.Ha@microchip.com> Cc: Woojung Huh <woojung.huh@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-17net: stmmac: fix argument to stmmac_pcs_ctrl_ane()Ben Dooks (Codethink)
The stmmac_pcs_ctrl_ane() expects a register address as argument 1, but for some reason the mac_device_info is being passed. Fix the warning (and possible bug) from sparse: drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: warning: incorrect type in argument 1 (different address spaces) drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: expected void [noderef] <asn:2> *ioaddr drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: got struct mac_device_info *hw Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-17dpaa2-eth: Fix TX FQID valuesIoana Radulescu
Depending on when MC connects the DPNI to a MAC, Tx FQIDs may not be available during probe time. Read the FQIDs each time the link goes up to avoid using invalid values. In case an error occurs or an invalid value is retrieved, fall back to QDID-based enqueueing. Fixes: 1fa0f68c9255 ("dpaa2-eth: Use FQ-based DPIO enqueue API") Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-17dpaa2-eth: add irq for the dpmac connect/disconnect eventFlorin Chiculita
Add IRQ for the DPNI endpoint change event, resolving the issue when a dynamically created DPNI gets a randomly generated hw address when the endpoint is a DPMAC object. Signed-off-by: Florin Chiculita <florinlaurentiu.chiculita@nxp.com> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-17usb: hso: obey DMA rules in tiocmgetOliver Neukum
The serial state information must not be embedded into another data structure, as this interferes with cache handling for DMA on architectures without cache coherence.. That would result in data corruption on some architectures Allocating it separately. v2: fix syntax error Signed-off-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-17Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input fixes from Dmitry Torokhov: "The main change is that we are reverting blanket enablement of SMBus mode for devices with Elan touchpads that report BIOS release date as 2018+ because there are older boxes with updated BIOSes that still do not work well in SMbus mode. We will have to establish whitelist for SMBus mode it looks like" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Revert "Input: elantech - enable SMBus on new (2018+) systems" Input: synaptics-rmi4 - avoid processing unknown IRQs Input: soc_button_array - partial revert of support for newer surface devices Input: goodix - add support for 9-bytes reports Input: da9063 - fix capability and drop KEY_SLEEP