summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-03-24drm/amdgpu/display: restore AUX_DPHY_TX_CONTROL for DCN2.xAlex Deucher
Commit 098214999c8f added fetching of the AUX_DPHY register values from the vbios, but it also changed the default values in the case when there are no values in the vbios. This causes problems with displays with high refresh rates. To fix this, switch back to the original default value for AUX_DPHY_TX_CONTROL. Fixes: 098214999c8f ("drm/amd/display: Read VBIOS Golden Settings Tbl") Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1426 Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Igor Kravchenko <Igor.Kravchenko@amd.com> Cc: Aric Cyr <Aric.Cyr@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: stable@vger.kernel.org
2021-03-24drm/amdgpu: Add additional Sienna Cichlid PCI IDAlex Deucher
Add new DID. Reviewed-by: Guchun Chen <guchun.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2021-03-23Merge series "ASoC: SOF: Intel: shutdown and core handling corrections" from ↵Mark Brown
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>: This patchset fixes a logical flow in the core status, improves shutdown support on Intel SOF platforms with an HDaudio controller and cleans-up ElkhartLake support. Guennadi Liakhovetski (1): ASoC: SOF: Intel: HDA: fix core status verification Libin Yang (5): ASoC: SOF: Intel: TGL: fix EHL ops ASoC: SOF: Intel: TGL: set shutdown callback to hda_dsp_shutdown ASoC: SOF: Intel: ICL: set shutdown callback to hda_dsp_shutdown ASoC: SOF: Intel: CNL: set shutdown callback to hda_dsp_shutdown ASoC: SOF: Intel: APL: set shutdown callback to hda_dsp_shutdown Pierre-Louis Bossart (2): ASoC: SOF: core: harden shutdown helper ASoC: SOF: Intel: move ELH chip info sound/soc/sof/core.c | 8 +++++++- sound/soc/sof/intel/apl.c | 3 ++- sound/soc/sof/intel/cnl.c | 19 ++----------------- sound/soc/sof/intel/hda-dsp.c | 21 +++++++++++++++++---- sound/soc/sof/intel/hda.h | 1 + sound/soc/sof/intel/icl.c | 3 ++- sound/soc/sof/intel/pci-tgl.c | 2 +- sound/soc/sof/intel/tgl.c | 18 +++++++++++++++++- 8 files changed, 49 insertions(+), 26 deletions(-) -- 2.25.1
2021-03-23net: bridge: don't notify switchdev for local FDB addressesVladimir Oltean
As explained in this discussion: https://lore.kernel.org/netdev/20210117193009.io3nungdwuzmo5f7@skbuf/ the switchdev notifiers for FDB entries managed to have a zero-day bug. The bridge would not say that this entry is local: ip link add br0 type bridge ip link set swp0 master br0 bridge fdb add dev swp0 00:01:02:03:04:05 master local and the switchdev driver would be more than happy to offload it as a normal static FDB entry. This is despite the fact that 'local' and non-'local' entries have completely opposite directions: a local entry is locally terminated and not forwarded, whereas a static entry is forwarded and not locally terminated. So, for example, DSA would install this entry on swp0 instead of installing it on the CPU port as it should. There is an even sadder part, which is that the 'local' flag is implicit if 'static' is not specified, meaning that this command produces the same result of adding a 'local' entry: bridge fdb add dev swp0 00:01:02:03:04:05 master I've updated the man pages for 'bridge', and after reading it now, it should be pretty clear to any user that the commands above were broken and should have never resulted in the 00:01:02:03:04:05 address being forwarded (this behavior is coherent with non-switchdev interfaces): https://patchwork.kernel.org/project/netdevbpf/cover/20210211104502.2081443-1-olteanv@gmail.com/ If you're a user reading this and this is what you want, just use: bridge fdb add dev swp0 00:01:02:03:04:05 master static Because switchdev should have given drivers the means from day one to classify FDB entries as local/non-local, but didn't, it means that all drivers are currently broken. So we can just as well omit the switchdev notifications for local FDB entries, which is exactly what this patch does to close the bug in stable trees. For further development work where drivers might want to trap the local FDB entries to the host, we can add a 'bool is_local' to br_switchdev_fdb_call_notifiers(), and selectively make drivers act upon that bit, while all the others ignore those entries if the 'is_local' bit is set. Fixes: 6b26b51b1d13 ("net: bridge: Add support for notifying devices about FDB add/del") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-23net/sched: act_ct: clear post_ct if doing ct_clearMarcelo Ricardo Leitner
Invalid detection works with two distinct moments: act_ct tries to find a conntrack entry and set post_ct true, indicating that that was attempted. Then, when flow dissector tries to dissect CT info and no entry is there, it knows that it was tried and no entry was found, and synthesizes/sets key->ct_state = TCA_FLOWER_KEY_CT_FLAGS_TRACKED | TCA_FLOWER_KEY_CT_FLAGS_INVALID; mimicing what OVS does. OVS has this a bit more streamlined, as it recomputes the key after trying to find a conntrack entry for it. Issue here is, when we have 'tc action ct clear', it didn't clear post_ct, causing a subsequent match on 'ct_state -trk' to fail, due to the above. The fix, thus, is to clear it. Reproducer rules: tc filter add dev enp130s0f0np0_0 ingress prio 1 chain 0 \ protocol ip flower ip_proto tcp ct_state -trk \ action ct zone 1 pipe \ action goto chain 2 tc filter add dev enp130s0f0np0_0 ingress prio 1 chain 2 \ protocol ip flower \ action ct clear pipe \ action goto chain 4 tc filter add dev enp130s0f0np0_0 ingress prio 1 chain 4 \ protocol ip flower ct_state -trk \ action mirred egress redirect dev enp130s0f1np1_0 With the fix, the 3rd rule matches, like it does with OVS kernel datapath. Fixes: 7baf2429a1a9 ("net/sched: cls_flower add CT_FLAGS_INVALID flag support") Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Reviewed-by: wenxu <wenxu@ucloud.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-23afs: Use wait_on_page_writeback_killableMatthew Wilcox (Oracle)
Open-coding this function meant it missed out on the recent bugfix for waiters being woken by a delayed wake event from a previous instantiation of the page[1]. [DH: Changed the patch to use vmf->page rather than variable page which doesn't exist yet upstream] Fixes: 1cf7a1518aef ("afs: Implement shared-writeable mmap") Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: kafs-testing@auristor.com cc: linux-afs@lists.infradead.org cc: linux-mm@kvack.org Link: https://lore.kernel.org/r/20210320054104.1300774-4-willy@infradead.org Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c2407cf7d22d0c0d94cf20342b3b8f06f1d904e7 [1]
2021-03-23mm/writeback: Add wait_on_page_writeback_killableMatthew Wilcox (Oracle)
This is the killable version of wait_on_page_writeback. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: kafs-testing@auristor.com cc: linux-afs@lists.infradead.org cc: linux-mm@kvack.org Link: https://lore.kernel.org/r/20210320054104.1300774-3-willy@infradead.org
2021-03-23fs/cachefiles: Remove wait_bit_key layout dependencyMatthew Wilcox (Oracle)
Cachefiles was relying on wait_page_key and wait_bit_key being the same layout, which is fragile. Now that wait_page_key is exposed in the pagemap.h header, we can remove that fragility A comment on the need to maintain structure layout equivalence was added by Linus[1] and that is no longer applicable. Fixes: 62906027091f ("mm: add PageWaiters indicating tasks are waiting for a page bit") Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: kafs-testing@auristor.com cc: linux-cachefs@redhat.com cc: linux-mm@kvack.org Link: https://lore.kernel.org/r/20210320054104.1300774-2-willy@infradead.org/ Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3510ca20ece0150af6b10c77a74ff1b5c198e3e2 [1]
2021-03-23platform/x86: intel_pmc_core: Ignore GBE LTR on Tiger Lake platformsDavid E. Box
Due to a HW limitation, the Latency Tolerance Reporting (LTR) value programmed in the Tiger Lake GBE controller is not large enough to allow the platform to enter Package C10, which in turn prevents the platform from achieving its low power target during suspend-to-idle. Ignore the GBE LTR value on Tiger Lake. LTR ignore functionality is currently performed solely by a debugfs write call. Split out the LTR code into its own function that can be called by both the debugfs writer and by this work around. Signed-off-by: David E. Box <david.e.box@linux.intel.com> Reviewed-by: Sasha Neftin <sasha.neftin@intel.com> Cc: intel-wired-lan@lists.osuosl.org Reviewed-by: Rajneesh Bhardwaj <irenic.rajneesh@gmail.com> Link: https://lore.kernel.org/r/20210319201844.3305399-2-david.e.box@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-03-23platform/x86: intel_pmc_core: Update KconfigDavid E. Box
The intel_pmc_core driver is mostly used as a debugging driver for Intel platforms that support SLPS0 (S0ix). But the driver may also be used to communicate actions to the PMC in order to ensure transition to SLPS0 on some systems and architectures. As such the driver should be built on all platforms it supports. Indicate this in the Kconfig. Also update the list of supported features. Signed-off-by: David E. Box <david.e.box@linux.intel.com> Suggested-by: Mario Limonciello <mario.limonciello@dell.com> Link: https://lore.kernel.org/r/20210319201844.3305399-1-david.e.box@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-03-23platform/x86: intel_pmt_crashlog: Fix incorrect macrosDavid E. Box
Fixes off-by-one bugs in the macro assignments for the crashlog control bits. Was initially tested on emulation but bug revealed after testing on silicon. Fixes: 5ef9998c96b0 ("platform/x86: Intel PMT Crashlog capability driver") Signed-off-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20210317024455.3071477-2-david.e.box@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-03-23platform/x86: intel_pmt_class: Initial resource to 0David E. Box
Initialize the struct resource in intel_pmt_dev_register to zero to avoid a fault should the char *name field be non-zero. Signed-off-by: David E. Box <david.e.box@linux.intel.com> Link: https://lore.kernel.org/r/20210317024455.3071477-1-david.e.box@linux.intel.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-03-23PM: EM: postpone creating the debugfs dir till fs_initcallLukasz Luba
The debugfs directory '/sys/kernel/debug/energy_model' is needed before the Energy Model registration can happen. With the recent change in debugfs subsystem it's not allowed to create this directory at early stage (core_initcall). Thus creating this directory would fail. Postpone the creation of the EM debug dir to later stage: fs_initcall. It should be safe since all clients: CPUFreq drivers, Devfreq drivers will be initialized in later stages. The custom debug log below prints the time of creation the EM debug dir at fs_initcall and successful registration of EMs at later stages. [ 1.505717] energy_model: creating rootdir [ 3.698307] cpu cpu0: EM: created perf domain [ 3.709022] cpu cpu1: EM: created perf domain Fixes: 56348560d495 ("debugfs: do not attempt to create a new file before the filesystem is initalized") Reported-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-03-23arm64: tegra: Fix mmc0 alias for Jetson Xavier NXJon Hunter
There are two variants of the Jetson Xavier NX platform; one has an eMMC and one as a micro SD-card slot. The SDHCI controller used by each variant is different, however, the current device-tree for both Xavier NX boards have the same SDHCI controller defined as 'mmc0' in the device-tree alias node. Fix this by correcting the 'mmc0' alias for the SD-card variant. Fixes: 3f9efbbe57bc ("arm64: tegra: Add support for Jetson Xavier NX") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-23arm64: tegra: Set fw_devlink=on for Jetson TX2Jon Hunter
Commit 5d25c476f252 ("Revert "arm64: tegra: Disable the ACONNECT for Jetson TX2"") re-enabled the Tegra ADMA and ACONNECT drivers to support audio on Jetson TX2. However, this revert was dependent upon commit e590474768f1 ("driver core: Set fw_devlink=on by default") and without this commit, enabling the ACONNECT is causing resume from system suspend to fail on Jetson TX2. Resume fails because the ACONNECT driver is being resumed before the BPMP driver, and the ACONNECT driver is attempting to power on a power-domain that is provided by the BPMP. Commit e590474768f1 ("driver core: Set fw_devlink=on by default") has since been temporarily reverted while some issues are being investigated. This is causing resume from system suspend on Jetson TX2 to fail again. Rather than disable the ACONNECT driver again, fix this by setting fw_devlink is set to 'on' for Jetson TX2 in the bootargs specified in device-tree. Fixes: 5d25c476f252 ("Revert arm64: tegra: Disable the ACONNECT for Jetson TX2") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-23arm64: tegra: Add unit-address for ACONNECT on Tegra186Thierry Reding
The ACONNECT device tree node has a unit-address on all other SoC generations and there's really no reason not to have it on Tegra186. Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-03-23Input: nspire-keypad - enable interrupts only when openedFabian Vogt
The driver registers an interrupt handler in _probe, but didn't configure them until later when the _open function is called. In between, the keypad can fire an IRQ due to touchpad activity, which the handler ignores. This causes the kernel to disable the interrupt, blocking the keypad from working. Fix this by disabling interrupts before registering the handler. Additionally, disable them in _close, so that they're only enabled while open. Fixes: fc4f31461892 ("Input: add TI-Nspire keypad support") Signed-off-by: Fabian Vogt <fabian@ritter-vogt.de> Link: https://lore.kernel.org/r/3383725.iizBOSrK1V@linux-e202.suse.de Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-03-23Input: i8042 - fix Pegatron C15B ID entryArnd Bergmann
The Zenbook Flip entry that was added overwrites a previous one because of a typo: In file included from drivers/input/serio/i8042.h:23, from drivers/input/serio/i8042.c:131: drivers/input/serio/i8042-x86ia64io.h:591:28: error: initialized field overwritten [-Werror=override-init] 591 | .matches = { | ^ drivers/input/serio/i8042-x86ia64io.h:591:28: note: (near initialization for 'i8042_dmi_noselftest_table[0].matches') Add the missing separator between the two. Fixes: b5d6e7ab7fe7 ("Input: i8042 - add ASUS Zenbook Flip to noselftest list") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Marcos Paulo de Souza <mpdesouza@suse.com> Link: https://lore.kernel.org/r/20210323130623.2302402-1-arnd@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2021-03-23Merge tag 'linux-kselftest-kunit-fixes-5.12-rc5.1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest Pull KUnit fixes from Shuah Khan: "Two fixes to the kunit tool from David Gow" * tag 'linux-kselftest-kunit-fixes-5.12-rc5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: kunit: tool: Disable PAGE_POISONING under --alltests kunit: tool: Fix a python tuple typing error
2021-03-23ASoC: wm8960: Fix wrong bclk and lrclk with pll enabled for some chipsShengjiu Wang
The input MCLK is 12.288MHz, the desired output sysclk is 11.2896MHz and sample rate is 44100Hz, with the configuration pllprescale=2, postscale=sysclkdiv=1, some chip may have wrong bclk and lrclk output with pll enabled in master mode, but with the configuration pllprescale=1, postscale=2, the output clock is correct. >From Datasheet, the PLL performs best when f2 is between 90MHz and 100MHz when the desired sysclk output is 11.2896MHz or 12.288MHz, so sysclkdiv = 2 (f2/8) is the best choice. So search available sysclk_divs from 2 to 1 other than from 1 to 2. Fixes: 84fdc00d519f ("ASoC: codec: wm9860: Refactor PLL out freq search") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/1616150926-22892-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-23ASoC: SOF: Intel: move ELH chip infoPierre-Louis Bossart
ELH is a derivative of TGL, so it should be exposed in tgl.c for consistency. No functional change. Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210322163728.16616-9-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-23ASoC: SOF: Intel: APL: set shutdown callback to hda_dsp_shutdownLibin Yang
According to hardware spec and PMC FW requirement, the DSP must be in D3 state before entering S5. Set shutdown call to hda_dsp_shutdown. Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Libin Yang <libin.yang@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210322163728.16616-8-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-23ASoC: SOF: Intel: CNL: set shutdown callback to hda_dsp_shutdownLibin Yang
According to hardware spec and PMC FW requirement, the DSP must be in D3 state before entering S5. Set shutdown call to hda_dsp_shutdown. Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Libin Yang <libin.yang@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210322163728.16616-7-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-23ASoC: SOF: Intel: ICL: set shutdown callback to hda_dsp_shutdownLibin Yang
According to hardware spec and PMC FW requirement, the DSP must be in D3 state before entering S5. Set shutdown call to hda_dsp_shutdown. Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Libin Yang <libin.yang@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210322163728.16616-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-23ASoC: SOF: Intel: TGL: set shutdown callback to hda_dsp_shutdownLibin Yang
According to hardware spec and PMC FW requirement, the DSP must be in D3 state before entering S5. Define the shutdown function to use snd_sof_suspend as shutdown callback to make sure DSP is in D3 state. Fixes: 44a4cfad8d78 ("ASoC: SOF: Intel: tgl: do thorough remove at .shutdown() callback") Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pan Xiuli <xiuli.pan@linux.intel.com> Signed-off-by: Libin Yang <libin.yang@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210322163728.16616-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-23ASoC: SOF: Intel: TGL: fix EHL opsLibin Yang
EHL is derived from TGL, not CNL, so we shall use the TGL ops. Fixes: 8d4ba1be3d22 ("ASoC: SOF: pci: split PCI into different drivers") Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Libin Yang <libin.yang@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210322163728.16616-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-23ASoC: SOF: core: harden shutdown helperPierre-Louis Bossart
When the probe is handled in a workqueue, we must use cancel_work_sync() in the shutdown helper to avoid possible race conditions. We must also take care of possible errors happening in a probe workqueue or during pm_runtime resume (called e.g. before shutdown for PCI devices). We should really only try to access hardware registers and initiate IPCs if the DSP is fully booted. Fixes: daff7f1478e12 ("ASoC: SOF: add snd_sof_device_shutdown() helper for shutdown") Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Libin Yang <libin.yang@intel.com> Link: https://lore.kernel.org/r/20210322163728.16616-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-23ASoC: SOF: Intel: HDA: fix core status verificationGuennadi Liakhovetski
When checking for enabled cores it isn't enough to check that some of the requested cores are running, we have to check that all of them are. Fixes: 747503b1813a ("ASoC: SOF: Intel: Add Intel specific HDA DSP HW operations") Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210322163728.16616-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-23block: recalculate segment count for multi-segment discards correctlyDavid Jeffery
When a stacked block device inserts a request into another block device using blk_insert_cloned_request, the request's nr_phys_segments field gets recalculated by a call to blk_recalc_rq_segments in blk_cloned_rq_check_limits. But blk_recalc_rq_segments does not know how to handle multi-segment discards. For disk types which can handle multi-segment discards like nvme, this results in discard requests which claim a single segment when it should report several, triggering a warning in nvme and causing nvme to fail the discard from the invalid state. WARNING: CPU: 5 PID: 191 at drivers/nvme/host/core.c:700 nvme_setup_discard+0x170/0x1e0 [nvme_core] ... nvme_setup_cmd+0x217/0x270 [nvme_core] nvme_loop_queue_rq+0x51/0x1b0 [nvme_loop] __blk_mq_try_issue_directly+0xe7/0x1b0 blk_mq_request_issue_directly+0x41/0x70 ? blk_account_io_start+0x40/0x50 dm_mq_queue_rq+0x200/0x3e0 blk_mq_dispatch_rq_list+0x10a/0x7d0 ? __sbitmap_queue_get+0x25/0x90 ? elv_rb_del+0x1f/0x30 ? deadline_remove_request+0x55/0xb0 ? dd_dispatch_request+0x181/0x210 __blk_mq_do_dispatch_sched+0x144/0x290 ? bio_attempt_discard_merge+0x134/0x1f0 __blk_mq_sched_dispatch_requests+0x129/0x180 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x47/0xe0 __blk_mq_delay_run_hw_queue+0x15b/0x170 blk_mq_sched_insert_requests+0x68/0xe0 blk_mq_flush_plug_list+0xf0/0x170 blk_finish_plug+0x36/0x50 xlog_cil_committed+0x19f/0x290 [xfs] xlog_cil_process_committed+0x57/0x80 [xfs] xlog_state_do_callback+0x1e0/0x2a0 [xfs] xlog_ioend_work+0x2f/0x80 [xfs] process_one_work+0x1b6/0x350 worker_thread+0x53/0x3e0 ? process_one_work+0x350/0x350 kthread+0x11b/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x22/0x30 This patch fixes blk_recalc_rq_segments to be aware of devices which can have multi-segment discards. It calculates the correct discard segment count by counting the number of bio as each discard bio is considered its own segment. Fixes: 1e739730c5b9 ("block: optionally merge discontiguous discard bios into a single request") Signed-off-by: David Jeffery <djeffery@redhat.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Laurence Oberman <loberman@redhat.com> Link: https://lore.kernel.org/r/20210211143807.GA115624@redhat Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-23block: clear GD_NEED_PART_SCAN later in bdev_disk_changedChris Chiu
The GD_NEED_PART_SCAN is set by bdev_check_media_change to initiate a partition scan while removing a block device. It should be cleared after blk_drop_paritions because blk_drop_paritions could return -EBUSY and then the consequence __blkdev_get has no chance to do delete_partition if GD_NEED_PART_SCAN already cleared. It causes some problems on some card readers. Ex. Realtek card reader 0bda:0328 and 0bda:0158. The device node of the partition will not disappear after the memory card removed. Thus the user applications can not update the device mapping correctly. BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1920874 Signed-off-by: Chris Chiu <chris.chiu@canonical.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20210323085219.24428-1-chris.chiu@canonical.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-23x86/build: Turn off -fcf-protection for realmode targetsArnd Bergmann
The new Ubuntu GCC packages turn on -fcf-protection globally, which causes a build failure in the x86 realmode code: cc1: error: ‘-fcf-protection’ is not compatible with this target Turn it off explicitly on compilers that understand this option. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20210323124846.1584944-1-arnd@kernel.org
2021-03-23drivers: video: fbcon: fix NULL dereference in fbcon_cursor()Du Cheng
add null-check on function pointer before dereference on ops->cursor Reported-by: syzbot+b67aaae8d3a927f68d20@syzkaller.appspotmail.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Du Cheng <ducheng2@gmail.com> Link: https://lore.kernel.org/r/20210312081421.452405-1-ducheng2@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-23mei: allow map and unmap of client dma buffer only for disconnected clientTomas Winkler
Allow map and unmap of the client dma buffer only when the client is not connected. The functions return -EPROTO if the client is already connected. This is to fix the race when traffic may start or stop when buffer is not available. Cc: <stable@vger.kernel.org> #v5.11+ Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Link: https://lore.kernel.org/r/20210318055959.305627-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-23MAINTAINERS: Add linux-phy list and patchworkVinod Koul
Linux-phy subsystem gained mailing list and a patchwork instance. Add the details to MAINTAINERS file Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20210226111233.2601369-1-vkoul@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-23driver core: clear deferred probe reason on probe retryAhmad Fatoum
When retrying a deferred probe, any old defer reason string should be discarded. Otherwise, if the probe is deferred again at a different spot, but without setting a message, the now incorrect probe reason will remain. This was observed with the i.MX I2C driver, which ultimately failed to probe due to lack of the GPIO driver. The probe defer for GPIO doesn't record a message, but a previous probe defer to clock_get did. This had the effect that /sys/kernel/debug/devices_deferred listed a misleading probe deferral reason. Cc: stable <stable@vger.kernel.org> Fixes: d090b70ede02 ("driver core: add deferring probe reason to devices_deferred property") Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Link: https://lore.kernel.org/r/20210319110459.19966-1-a.fatoum@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-23drm/amd/pm: workaround for audio noise issueKenneth Feng
On some Intel platforms, audio noise can be detected due to high pcie speed switch latency. This patch leaverages ppfeaturemask to fix to the highest pcie speed then disable pcie switching. v2: coding style fix Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2021-03-23staging: rtl8192e: Change state information from u16 to u8Atul Gopinathan
The "u16 CcxRmState[2];" array field in struct "rtllib_network" has 4 bytes in total while the operations performed on this array through-out the code base are only 2 bytes. The "CcxRmState" field is fed only 2 bytes of data using memcpy(): (In rtllib_rx.c:1972) memcpy(network->CcxRmState, &info_element->data[4], 2) With "info_element->data[]" being a u8 array, if 2 bytes are written into "CcxRmState" (whose one element is u16 size), then the 2 u8 elements from "data[]" gets squashed and written into the first element ("CcxRmState[0]") while the second element ("CcxRmState[1]") is never fed with any data. Same in file rtllib_rx.c:2522: memcpy(dst->CcxRmState, src->CcxRmState, 2); The above line duplicates "src" data to "dst" but only writes 2 bytes (and not 4, which is the actual size). Again, only 1st element gets the value while the 2nd element remains uninitialized. This later makes operations done with CcxRmState unpredictable in the following lines as the 1st element is having a squashed number while the 2nd element is having an uninitialized random number. rtllib_rx.c:1973: if (network->CcxRmState[0] != 0) rtllib_rx.c:1977: network->MBssidMask = network->CcxRmState[1] & 0x07; network->MBssidMask is also of type u8 and not u16. Fix this by changing the type of "CcxRmState" from u16 to u8 so that the data written into this array and read from it make sense and are not random values. NOTE: The wrong initialization of "CcxRmState" can be seen in the following commit: commit ecdfa44610fa ("Staging: add Realtek 8192 PCI wireless driver") The above commit created a file `rtl8192e/ieee80211.h` which used to have the faulty line. The file has been deleted (or possibly renamed) with the contents copied in to a new file `rtl8192e/rtllib.h` along with additional code in the commit 94a799425eee (tagged in Fixes). Fixes: 94a799425eee ("From: wlanfae <wlanfae@realtek.com> [PATCH 1/8] rtl8192e: Import new version of driver from realtek") Cc: stable@vger.kernel.org Signed-off-by: Atul Gopinathan <atulgopinathan@gmail.com> Link: https://lore.kernel.org/r/20210323113413.29179-2-atulgopinathan@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-23staging: rtl8192e: Fix incorrect source in memcpy()Atul Gopinathan
The variable "info_element" is of the following type: struct rtllib_info_element *info_element defined in drivers/staging/rtl8192e/rtllib.h: struct rtllib_info_element { u8 id; u8 len; u8 data[]; } __packed; The "len" field defines the size of the "data[]" array. The code is supposed to check if "info_element->len" is greater than 4 and later equal to 6. If this is satisfied then, the last two bytes (the 4th and 5th element of u8 "data[]" array) are copied into "network->CcxRmState". Right now the code uses "memcpy()" with the source as "&info_element[4]" which would copy in wrong and unintended information. The struct "rtllib_info_element" has a size of 2 bytes for "id" and "len", therefore indexing will be done in interval of 2 bytes. So, "info_element[4]" would point to data which is beyond the memory allocated for this pointer (that is, at x+8, while "info_element" has been allocated only from x to x+7 (2 + 6 => 8 bytes)). This patch rectifies this error by using "&info_element->data[4]" which correctly copies the last two bytes of "data[]". NOTE: The faulty line of code came from the following commit: commit ecdfa44610fa ("Staging: add Realtek 8192 PCI wireless driver") The above commit created the file `rtl8192e/ieee80211/ieee80211_rx.c` which had the faulty line of code. This file has been deleted (or possibly renamed) with the contents copied in to a new file `rtl8192e/rtllib_rx.c` along with additional code in the commit 94a799425eee (tagged in Fixes). Fixes: 94a799425eee ("From: wlanfae <wlanfae@realtek.com> [PATCH 1/8] rtl8192e: Import new version of driver from realtek") Cc: stable@vger.kernel.org Signed-off-by: Atul Gopinathan <atulgopinathan@gmail.com> Link: https://lore.kernel.org/r/20210323113413.29179-1-atulgopinathan@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-23USB: quirks: ignore remote wake-up on Fibocom L850-GL LTE modemVincent Palatin
This LTE modem (M.2 card) has a bug in its power management: there is some kind of race condition for U3 wake-up between the host and the device. The modem firmware sometimes crashes/locks when both events happen at the same time and the modem fully drops off the USB bus (and sometimes re-enumerates, sometimes just gets stuck until the next reboot). Tested with the modem wired to the XHCI controller on an AMD 3015Ce platform. Without the patch, the modem dropped of the USB bus 5 times in 3 days. With the quirk, it stayed connected for a week while the 'runtime_suspended_time' counter incremented as excepted. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Link: https://lore.kernel.org/r/20210319124802.2315195-1-vpalatin@chromium.org Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-23USB: cdc-acm: do not log successful probe on later errorsJohan Hovold
Do not log the successful-probe message until the tty device has been registered. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210322155318.9837-9-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-23USB: cdc-acm: always claim data interfaceJohan Hovold
Make sure to always claim the data interface and bail out if binding fails. Note that the driver had a check to verify that the data interface was not already bound to a driver but would not detect other failures (e.g. if the interface was not authorised). Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210322155318.9837-8-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-23USB: cdc-acm: use negation for NULL checksJohan Hovold
Use negation consistently throughout the driver for NULL checks. Acked-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210322155318.9837-7-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-23USB: cdc-acm: clean up probe error labelsJohan Hovold
Name the probe error labels after what they do rather than using sequence numbers which is harder to review and maintain (e.g. may require renaming unrelated labels when a label is added or removed). Acked-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210322155318.9837-6-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-23USB: cdc-acm: drop redundant driver-data resetJohan Hovold
There's no need to clear the interface driver data on failed probe (and driver core will clear it anyway). Acked-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210322155318.9837-5-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-23USB: cdc-acm: drop redundant driver-data assignmentJohan Hovold
The interface driver data has already been set by usb_driver_claim_interface() so drop the redundant subsequent assignment. Acked-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210322155318.9837-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-23USB: cdc-acm: fix use-after-free after probe failureJohan Hovold
If tty-device registration fails the driver would fail to release the data interface. When the device is later disconnected, the disconnect callback would still be called for the data interface and would go about releasing already freed resources. Fixes: c93d81955005 ("usb: cdc-acm: fix error handling in acm_probe()") Cc: stable@vger.kernel.org # 3.9 Cc: Alexey Khoroshilov <khoroshilov@ispras.ru> Acked-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210322155318.9837-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-23USB: cdc-acm: fix double free on probe failureJohan Hovold
If tty-device registration fails the driver copy of any Country Selection functional descriptor would end up being freed twice; first explicitly in the error path and then again in the tty-port destructor. Drop the first erroneous free that was left when fixing a tty-port resource leak. Fixes: cae2bc768d17 ("usb: cdc-acm: Decrement tty port's refcount if probe() fail") Cc: stable@vger.kernel.org # 4.19 Cc: Jaejoong Kim <climbbb.kim@gmail.com> Acked-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20210322155318.9837-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-23drm/i915/dsc: fix DSS CTL register usage for ICL DSI transcodersJani Nikula
Use the correct DSS CTL registers for ICL DSI transcoders. As a side effect, this also brings back the sanity check for trying to use pipe DSC registers on pipe A on ICL. Fixes: 8a029c113b17 ("drm/i915/dp: Modify VDSC helpers to configure DSC for Bigjoiner slave") References: http://lore.kernel.org/r/87eegxq2lq.fsf@intel.com Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: <stable@vger.kernel.org> # v5.11+ Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210319115333.8330-1-jani.nikula@intel.com (cherry picked from commit 5706d02871240fdba7ddd6ab1cc31672fc95a90f) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-03-23drm/i915: Fix enabled_planes bitmaskVille Syrjälä
The enabled_planes bitmask was supposed to track logically enabled planes (ie. fb!=NULL and crtc!=NULL), but instead we end up putting even disabled planes into the bitmask since intel_plane_atomic_check_with_state() only takes the early exit if the plane was disabled and stays disabled. I think I misread the early said codepath to exit whenever the plane is logically disabled, which is not true. So let's fix this up properly and set the bit only when the plane actually is logically enabled. Cc: Manasi Navare <manasi.d.navare@intel.com> Fixes: ee42ec19ca2e ("drm/i915: Track logically enabled planes for hw state") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210305153610.12177-2-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> (cherry picked from commit 97bc7ffa1b1e9a8672e0a8e9a96680b0c3717427) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-03-23drm/i915: Disable LTTPR support when the LTTPR rev < 1.4Imre Deak
By the specification the 0xF0000 - 0xF02FF range is only valid if the LTTPR revision at 0xF0000 is at least 1.4. Disable the LTTPR support otherwise. Fixes: 7b2a4ab8b0ef ("drm/i915: Switch to LTTPR transparent mode link training") Cc: <stable@vger.kernel.org> # v5.11 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210317184901.4029798-4-imre.deak@intel.com (cherry picked from commit 1663ad4936e0679443a315fe342f99636a2420dd) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>