summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-04-06platform/x86: intel-hid: Fix spurious wakeups caused by tablet-mode events ↵Hans de Goede1-7/+9
during suspend Some devices send (duplicate) tablet-mode events when moved around even though the mode has not changed; and they do this even when suspended. Change the tablet-mode event handling when priv->wakeup_mode is set to update the switch state in case it changed and then return immediately (without calling pm_wakeup_hard_event()) to avoid spurious wakeups. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212537 Fixes: 537b0dd4729e ("platform/x86: intel-hid: Add support for SW_TABLET_MODE") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Elia Devito <eliadevito@gmail.com> Link: https://lore.kernel.org/r/20210404143831.25173-1-hdegoede@redhat.com
2021-03-23platform/x86: intel_pmc_core: Ignore GBE LTR on Tiger Lake platformsDavid E. Box1-15/+35
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. Box1-3/+8
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. Box1-7/+6
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. Box1-1/+1
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-21platform/x86: intel-vbtn: Stop reporting SW_DOCK eventsHans de Goede1-2/+10
Stop reporting SW_DOCK events because this breaks suspend-on-lid-close. SW_DOCK should only be reported for docking stations, but all the DSDTs in my DSDT collection which use the intel-vbtn code, always seem to use this for 2-in-1s / convertibles and set SW_DOCK=1 when in laptop-mode (in tandem with setting SW_TABLET_MODE=0). This causes userspace to think the laptop is docked to a port-replicator and to disable suspend-on-lid-close, which is undesirable. Map the dock events to KEY_IGNORE to avoid this broken SW_DOCK reporting. Note this may theoretically cause us to stop reporting SW_DOCK on some device where the 0xCA and 0xCB intel-vbtn events are actually used for reporting docking to a classic docking-station / port-replicator but I'm not aware of any such devices. Also the most important thing is that we only report SW_DOCK when it reliably reports being docked to a classic docking-station without any false positives, which clearly is not the case here. If there is a chance of reporting false positives then it is better to not report SW_DOCK at all. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210321163513.72328-1-hdegoede@redhat.com
2021-03-21platform/x86: dell-wmi-sysman: Cleanup create_attributes_level_sysfs_files()Hans de Goede1-9/+7
Cleanup create_attributes_level_sysfs_files(): 1. There is no need to call sysfs_remove_file() on error, sysman_init() will already call release_attributes_data() on failure which already does this. 2. There is no need for the pr_debug() calls sysfs_create_file() should never fail and if it does it will already complain about the problem itself. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: Divya Bharathi <Divya_Bharathi@dell.com> Cc: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210321115901.35072-8-hdegoede@redhat.com
2021-03-21platform/x86: dell-wmi-sysman: Make sysman_init() return -ENODEV of the ↵Hans de Goede1-5/+7
interfaces are not found When either the attributes or the password interface is not found, then unregister the 2 wmi drivers again and return -ENODEV from sysman_init(). Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: Divya Bharathi <Divya_Bharathi@dell.com> Cc: Mario Limonciello <mario.limonciello@dell.com> Reported-by: Alexander Naumann <alexandernaumann@gmx.de> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210321115901.35072-7-hdegoede@redhat.com
2021-03-21platform/x86: dell-wmi-sysman: Cleanup sysman_init() error-exit handlingHans de Goede1-29/+16
Cleanup sysman_init() error-exit handling: 1. There is no need for the fail_reset_bios and fail_authentication_kset eror-exit cases, these can be handled by release_attributes_data() 2. Rename all the labels from fail_what_failed, to err_what_to_cleanup this is the usual way to name these and avoids the need to rename them when extra steps are added. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: Divya Bharathi <Divya_Bharathi@dell.com> Cc: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210321115901.35072-6-hdegoede@redhat.com
2021-03-21platform/x86: dell-wmi-sysman: Fix release_attributes_data() getting called ↵Hans de Goede1-1/+0
twice on init_bios_attributes() failure All calls of init_bios_attributes() will result in a goto fail_create_group if they fail, which calls release_attributes_data(). So there is no need to call release_attributes_data() from init_bios_attributes() on failure itself. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: Divya Bharathi <Divya_Bharathi@dell.com> Cc: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210321115901.35072-5-hdegoede@redhat.com
2021-03-21platform/x86: dell-wmi-sysman: Make it safe to call exit_foo_attributes() ↵Hans de Goede4-0/+12
multiple times During some of the error-exit paths it is possible that release_attributes_data() will get called multiple times, which results in exit_foo_attributes() getting called multiple times. Make it safe to call exit_foo_attributes() multiple times, avoiding double-free()s in this case. Note that release_attributes_data() really should only be called once during error-exit paths. This will be fixed in a separate patch and it is good to have the exit_foo_attributes() functions modified this way regardless. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: Divya Bharathi <Divya_Bharathi@dell.com> Cc: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210321115901.35072-4-hdegoede@redhat.com
2021-03-21platform/x86: dell-wmi-sysman: Fix possible NULL pointer deref on exitHans de Goede1-9/+2
It is possible for release_attributes_data() to get called when the main_dir_kset has not been created yet, move the removal of the bios-reset sysfs attr to under a if (main_dir_kset) check to avoid a NULL pointer deref. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: Divya Bharathi <Divya_Bharathi@dell.com> Cc: Mario Limonciello <mario.limonciello@dell.com> Reported-by: Alexander Naumann <alexandernaumann@gmx.de> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210321115901.35072-3-hdegoede@redhat.com
2021-03-21platform/x86: dell-wmi-sysman: Fix crash caused by calling kset_unregister twiceHans de Goede1-0/+1
On some system the WMI GUIDs used by dell-wmi-sysman are present but there are no enum type attributes, this causes init_bios_attributes() to return -ENODEV, after which sysman_init() does a "goto fail_create_group" and then calls release_attributes_data(). release_attributes_data() calls kset_unregister(wmi_priv.main_dir_kset); but before this commit it was missing a "wmi_priv.main_dir_kset = NULL;" statement; and after calling release_attributes_data() the sysman_init() error handling does this: if (wmi_priv.main_dir_kset) { kset_unregister(wmi_priv.main_dir_kset); wmi_priv.main_dir_kset = NULL; } Which causes a second kset_unregister(wmi_priv.main_dir_kset), leading to a double-free, which causes a crash. Add the missing "wmi_priv.main_dir_kset = NULL;" statement to release_attributes_data() to fix this double-free crash. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: Divya Bharathi <Divya_Bharathi@dell.com> Cc: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210321115901.35072-2-hdegoede@redhat.com
2021-03-21platform/x86: thinkpad_acpi: Disable DYTC CQL mode around switching to ↵Hans de Goede1-2/+7
balanced mode Testing has shown that setting /sys/firmware/acpi/platform_profile to "balanced" when /sys/bus/platform/devices/thinkpad_acpi/dytc_lapmode reports 1, causes dytc_lapmode to get reset to 0 and then it becomes stuck at 0 for aprox. 30 minutes even if the laptop is used on a lap. Disabling CQL (when enabled) before issuing the DYTC_CMD_RESET to get back to balanced mode and re-enabling it afterwards again, like the code already does when switching to low-power / performance mode fixes this. Fixes: c3bfcd4c6762 ("platform/x86: thinkpad_acpi: Add platform profile support") Tested-by: Mark Pearson <markpearson@lenovo.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210321113108.7069-1-hdegoede@redhat.com
2021-03-21platform/x86: thinkpad_acpi: Allow the FnLock LED to change stateEsteve Varela Colominas1-1/+7
On many recent ThinkPad laptops, there's a new LED next to the ESC key, that indicates the FnLock status. When the Fn+ESC combo is pressed, FnLock is toggled, which causes the Media Key functionality to change, making it so that the media keys either perform their media key function, or function as an F-key by default. The Fn key can be used the access the alternate function at any time. With the current linux kernel, the LED doens't change state if you press the Fn+ESC key combo. However, the media key functionality *does* change. This is annoying, since the LED will stay on if it was on during bootup, and it makes it hard to keep track what the current state of the FnLock is. This patch calls an ACPI function, that gets the current media key state, when the Fn+ESC key combo is pressed. Through testing it was discovered that this function causes the LED to update correctly to reflect the current state when this function is called. The relevant ACPI calls are the following: \_SB_.PCI0.LPC0.EC0_.HKEY.GMKS: Get media key state, returns 0x603 if the FnLock mode is enabled, and 0x602 if it's disabled. \_SB_.PCI0.LPC0.EC0_.HKEY.SMKS: Set media key state, sending a 1 will enable FnLock mode, and a 0 will disable it. Relevant discussion: https://bugzilla.kernel.org/show_bug.cgi?id=207841 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1881015 Signed-off-by: Esteve Varela Colominas <esteve.varela@gmail.com> Link: https://lore.kernel.org/r/20210315195823.23212-1-esteve.varela@gmail.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-03-18platform/x86: thinkpad_acpi: check dytc version for lapmode sysfsMark Pearson1-26/+65
Lenovo platforms with DYTC versions earlier than version 5 don't set the lapmode interface correctly, causing issues with thermald on older platforms. Add checking to only create the dytc_lapmode interface for version 5 and later. Fixes: 1ac09656bded ("platform/x86: thinkpad_acpi: Add palm sensor support") Signed-off-by: Mark Pearson <markpearson@lenovo.com> Link: https://lore.kernel.org/r/20210311174843.3161-1-markpearson@lenovo.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-03-06platform/x86: intel-hid: Support Lenovo ThinkPad X1 Tablet Gen 2Alban Bedel1-0/+7
Like a few other system the Lenovo ThinkPad X1 Tablet Gen 2 miss the HEBC method, which prevent the power button from working. Add a quirk to enable the button array on this system family and fix the power button. Signed-off-by: Alban Bedel <albeu@free.fr> Tested-by: Alexander Kobel <a-kobel@a-kobel.de> Link: https://lore.kernel.org/r/20210222141559.3775-1-albeu@free.fr Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-03-06Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdmaLinus Torvalds8-62/+76
Pull rdma fixes from Jason Gunthorpe: "Nothing special here, though Bob's regression fixes for rxe would have made it before the rc cycle had there not been such strong winter weather! - Fix corner cases in the rxe reference counting cleanup that are causing regressions in blktests for SRP - Two kdoc fixes so W=1 is clean - Missing error return in error unwind for mlx5 - Wrong lock type nesting in IB CM" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: RDMA/rxe: Fix errant WARN_ONCE in rxe_completer() RDMA/rxe: Fix extra deref in rxe_rcv_mcast_pkt() RDMA/rxe: Fix missed IB reference counting in loopback RDMA/uverbs: Fix kernel-doc warning of _uverbs_alloc RDMA/mlx5: Set correct kernel-doc identifier IB/mlx5: Add missing error code RDMA/rxe: Fix missing kconfig dependency on CRYPTO RDMA/cm: Fix IRQ restore in ib_send_cm_sidr_rep
2021-03-06Merge tag 'for-5.12/dm-fixes' of ↵Linus Torvalds2-11/+16
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm Pull device mapper fixes from Mike Snitzer: "Fix DM verity target's optional Forward Error Correction (FEC) for Reed-Solomon roots that are unaligned to block size" * tag 'for-5.12/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm verity: fix FEC for RS roots unaligned to block size dm bufio: subtract the number of initial sectors in dm_bufio_get_device_size
2021-03-05Merge tag 'block-5.12-2021-03-05' of git://git.kernel.dk/linux-blockLinus Torvalds9-51/+67
Pull block fixes from Jens Axboe: - NVMe fixes: - more device quirks (Julian Einwag, Zoltán Böszörményi, Pascal Terjan) - fix a hwmon error return (Daniel Wagner) - fix the keep alive timeout initialization (Martin George) - ensure the model_number can't be changed on a used subsystem (Max Gurtovoy) - rsxx missing -EFAULT on copy_to_user() failure (Dan) - rsxx remove unused linux.h include (Tian) - kill unused RQF_SORTED (Jean) - updated outdated BFQ comments (Joseph) - revert work-around commit for bd_size_lock, since we removed the offending user in this merge window (Damien) * tag 'block-5.12-2021-03-05' of git://git.kernel.dk/linux-block: nvmet: model_number must be immutable once set nvme-fabrics: fix kato initialization nvme-hwmon: Return error code when registration fails nvme-pci: add quirks for Lexar 256GB SSD nvme-pci: mark Kingston SKC2000 as not supporting the deepest power state nvme-pci: mark Seagate Nytro XM1440 as QUIRK_NO_NS_DESC_LIST. rsxx: Return -EFAULT if copy_to_user() fails block/bfq: update comments and default value in docs for fifo_expire rsxx: remove unused including <linux/version.h> block: Drop leftover references to RQF_SORTED block: revert "block: fix bd_size_lock use"
2021-03-05Merge tag 'pm-5.12-rc2' of ↵Linus Torvalds3-26/+41
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "These fix the usage of device links in the runtime PM core code and update the DTPM (Dynamic Thermal Power Management) feature added recently. Specifics: - Make the runtime PM core code avoid attempting to suspend supplier devices before updating the PM-runtime status of a consumer to 'suspended' (Rafael Wysocki). - Fix DTPM (Dynamic Thermal Power Management) root node initialization and label that feature as EXPERIMENTAL in Kconfig (Daniel Lezcano)" * tag 'pm-5.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: powercap/drivers/dtpm: Add the experimental label to the option description powercap/drivers/dtpm: Fix root node initialization PM: runtime: Update device status before letting suppliers suspend
2021-03-05Merge tag 'iommu-fixes-v5.12-rc1' of ↵Linus Torvalds4-14/+87
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu Pull iommu fixes from Joerg Roedel: - Fix a sleeping-while-atomic issue in the AMD IOMMU code - Disable lazy IOTLB flush for untrusted devices in the Intel VT-d driver - Fix status code definitions for Intel VT-d - Fix IO Page Fault issue in Tegra IOMMU driver * tag 'iommu-fixes-v5.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/vt-d: Fix status code for Allocate/Free PASID command iommu: Don't use lazy flush for untrusted device iommu/tegra-smmu: Fix mc errors on tegra124-nyan iommu/amd: Fix sleeping in atomic in increase_address_space()
2021-03-05RDMA/rxe: Fix errant WARN_ONCE in rxe_completer()Bob Pearson1-32/+23
In rxe_comp.c in rxe_completer() the function free_pkt() did not clear skb which triggered a warning at 'done:' and could possibly at 'exit:'. The WARN_ONCE() calls are not actually needed. The call to free_pkt() is moved to the end to clearly show that all skbs are freed. Fixes: 899aba891cab ("RDMA/rxe: Fix FIXME in rxe_udp_encap_recv()") Link: https://lore.kernel.org/r/20210304192048.2958-1-rpearson@hpe.com Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-03-05RDMA/rxe: Fix extra deref in rxe_rcv_mcast_pkt()Bob Pearson1-24/+35
rxe_rcv_mcast_pkt() dropped a reference to ib_device when no error occurred causing an underflow on the reference counter. This code is cleaned up to be clearer and easier to read. Fixes: 899aba891cab ("RDMA/rxe: Fix FIXME in rxe_udp_encap_recv()") Link: https://lore.kernel.org/r/20210304192048.2958-1-rpearson@hpe.com Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-03-05RDMA/rxe: Fix missed IB reference counting in loopbackBob Pearson1-1/+9
When the noted patch below extending the reference taken by rxe_get_dev_from_net() in rxe_udp_encap_recv() until each skb is freed it was not matched by a reference in the loopback path resulting in underflows. Fixes: 899aba891cab ("RDMA/rxe: Fix FIXME in rxe_udp_encap_recv()") Link: https://lore.kernel.org/r/20210304192048.2958-1-rpearson@hpe.com Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-03-05Merge branch 'powercap'Rafael J. Wysocki2-1/+4
* powercap: powercap/drivers/dtpm: Add the experimental label to the option description powercap/drivers/dtpm: Fix root node initialization
2021-03-05nvmet: model_number must be immutable once setMax Gurtovoy4-45/+50
In case we have already established connection to nvmf target, it shouldn't be allowed to change the model_number. E.g. if someone will identify ctrl and get model_number of "my_model" later on will change the model_numbel via configfs to "my_new_model" this will break the NVMe specification for "Get Log Page – Persistent Event Log" that refers to Model Number as: "This field contains the same value as reported in the Model Number field of the Identify Controller data structure, bytes 63:24." Although it doesn't mentioned explicitly that this field can't be changed, we can assume it. So allow setting this field only once: using configfs or in the first identify ctrl operation. Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2021-03-05nvme-fabrics: fix kato initializationMartin George1-1/+4
Currently kato is initialized to NVME_DEFAULT_KATO for both discovery & i/o controllers. This is a problem specifically for non-persistent discovery controllers since it always ends up with a non-zero kato value. Fix this by initializing kato to zero instead, and ensuring various controllers are assigned appropriate kato values as follows: non-persistent controllers - kato set to zero persistent controllers - kato set to NVMF_DEV_DISC_TMO (or any positive int via nvme-cli) i/o controllers - kato set to NVME_DEFAULT_KATO (or any positive int via nvme-cli) Signed-off-by: Martin George <marting@netapp.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2021-03-05nvme-hwmon: Return error code when registration failsDaniel Wagner1-0/+1
The hwmon pointer wont be NULL if the registration fails. Though the exit code path will assign it to ctrl->hwmon_device. Later nvme_hwmon_exit() will try to free the invalid pointer. Avoid this by returning the error code from hwmon_device_register_with_info(). Fixes: ed7770f66286 ("nvme/hwmon: rework to avoid devm allocation") Signed-off-by: Daniel Wagner <dwagner@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de>
2021-03-05nvme-pci: add quirks for Lexar 256GB SSDPascal Terjan1-0/+3
Add the NVME_QUIRK_NO_NS_DESC_LIST and NVME_QUIRK_IGNORE_DEV_SUBNQN quirks for this buggy device. Reported and tested in https://bugs.mageia.org/show_bug.cgi?id=28417 Signed-off-by: Pascal Terjan <pterjan@google.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2021-03-05nvme-pci: mark Kingston SKC2000 as not supporting the deepest power stateZoltán Böszörményi1-0/+2
My 2TB SKC2000 showed the exact same symptoms that were provided in 538e4a8c57 ("nvme-pci: avoid the deepest sleep state on Kingston A2000 SSDs"), i.e. a complete NVME lockup that needed cold boot to get it back. According to some sources, the A2000 is simply a rebadged SKC2000 with a slightly optimized firmware. Adding the SKC2000 PCI ID to the quirk list with the same workaround as the A2000 made my laptop survive a 5 hours long Yocto bootstrap buildfest which reliably triggered the SSD lockup previously. Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2021-03-05nvme-pci: mark Seagate Nytro XM1440 as QUIRK_NO_NS_DESC_LIST.Julian Einwag1-1/+2
The kernel fails to fully detect these SSDs, only the character devices are present: [ 10.785605] nvme nvme0: pci function 0000:04:00.0 [ 10.876787] nvme nvme1: pci function 0000:81:00.0 [ 13.198614] nvme nvme0: missing or invalid SUBNQN field. [ 13.198658] nvme nvme1: missing or invalid SUBNQN field. [ 13.206896] nvme nvme0: Shutdown timeout set to 20 seconds [ 13.215035] nvme nvme1: Shutdown timeout set to 20 seconds [ 13.225407] nvme nvme0: 16/0/0 default/read/poll queues [ 13.233602] nvme nvme1: 16/0/0 default/read/poll queues [ 13.239627] nvme nvme0: Identify Descriptors failed (8194) [ 13.246315] nvme nvme1: Identify Descriptors failed (8194) Adding the NVME_QUIRK_NO_NS_DESC_LIST fixes this problem. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205679 Signed-off-by: Julian Einwag <jeinwag-nvme@marcapo.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Keith Busch <kbusch@kernel.org>
2021-03-05Merge tag 'drm-fixes-2021-03-05' of git://anongit.freedesktop.org/drm/drmLinus Torvalds10-16/+29
Pull drm fixes from Dave Airlie: "More may show up but this is what I have at this stage: just a single nouveau regression fix, and a bunch of amdgpu fixes. amdgpu: - S0ix fix - Handle new NV12 SKU - Misc power fixes - Display uninitialized value fix - PCIE debugfs register access fix nouveau: - regression fix for gk104" * tag 'drm-fixes-2021-03-05' of git://anongit.freedesktop.org/drm/drm: drm/amdgpu: fix parameter error of RREG32_PCIE() in amdgpu_regs_pcie drm/amd/display: fix the return of the uninitialized value in ret drm/amdgpu: enable BACO runpm by default on sienna cichlid and navy flounder drm/amd/pm: correct Arcturus mmTHM_BACO_CNTL register address drm/amdgpu/swsmu/vangogh: Only use RLCPowerNotify msg for disable drm/amdgpu/pm: make unsupported power profile messages debug drm/amdgpu:disable VCN for Navi12 SKU drm/amdgpu: Only check for S0ix if AMD_PMC is configured drm/nouveau/fifo/gk104-gp1xx: fix creation of sw class
2021-03-05Merge tag 'mkp-scsi-fixes' of ↵Linus Torvalds2-83/+105
git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi Pull iSCSI fixes from Martin Petersen: "Three fixes for missed iSCSI verification checks (and make the sysfs files use "sysfs_emit()" - that's what it is there for)" * tag 'mkp-scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi: scsi: iscsi: Verify lengths on passthrough PDUs scsi: iscsi: Ensure sysfs attributes are limited to PAGE_SIZE scsi: iscsi: Restrict sessions and handles to admin capabilities
2021-03-05Merge tag 'amd-drm-fixes-5.12-2021-03-03' of ↵Dave Airlie9-16/+26
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-5.12-2021-03-03: amdgpu: - S0ix fix - Handle new NV12 SKU - Misc power fixes - Display uninitialized value fix - PCIE debugfs register access fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210304043255.3792-1-alexander.deucher@amd.com
2021-03-05Merge branch '00.00-inst' of git://github.com/skeggsb/linux into drm-fixesDave Airlie1-0/+3
A single regression fix here that I noticed while testing a bunch of boards for something else, not sure where this got lost! Prevents 3D driver from initialising on some GPUs. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <skeggsb@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv5gmq14BrDmkMncfd=tHVSSaU89BdBEWfs6Jy-aRz03GQ@mail.gmail.com
2021-03-05scsi: iscsi: Verify lengths on passthrough PDUsChris Leech1-0/+9
Open-iSCSI sends passthrough PDUs over netlink, but the kernel should be verifying that the provided PDU header and data lengths fall within the netlink message to prevent accessing beyond that in memory. Cc: stable@vger.kernel.org Reported-by: Adam Nichols <adam@grimm-co.com> Reviewed-by: Lee Duncan <lduncan@suse.com> Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Chris Leech <cleech@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-05scsi: iscsi: Ensure sysfs attributes are limited to PAGE_SIZEChris Leech2-83/+90
As the iSCSI parameters are exported back through sysfs, it should be enforcing that they never are more than PAGE_SIZE (which should be more than enough) before accepting updates through netlink. Change all iSCSI sysfs attributes to use sysfs_emit(). Cc: stable@vger.kernel.org Reported-by: Adam Nichols <adam@grimm-co.com> Reviewed-by: Lee Duncan <lduncan@suse.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Chris Leech <cleech@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-05scsi: iscsi: Restrict sessions and handles to admin capabilitiesLee Duncan1-0/+6
Protect the iSCSI transport handle, available in sysfs, by requiring CAP_SYS_ADMIN to read it. Also protect the netlink socket by restricting reception of messages to ones sent with CAP_SYS_ADMIN. This disables normal users from being able to end arbitrary iSCSI sessions. Cc: stable@vger.kernel.org Reported-by: Adam Nichols <adam@grimm-co.com> Reviewed-by: Chris Leech <cleech@redhat.com> Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Lee Duncan <lduncan@suse.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-03-04Merge tag 'tpmdd-next-v5.12-rc2' of ↵Linus Torvalds2-7/+25
git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd Pull tpm fixes Jarkko Sakkinen: "Three fixes for rc2" * tag 'tpmdd-next-v5.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd: tpm: Remove unintentional dump_stack() call tpm, tpm_tis: Decorate tpm_tis_gen_interrupt() with request_locality() tpm, tpm_tis: Decorate tpm_get_timeouts() with request_locality()
2021-03-04dm verity: fix FEC for RS roots unaligned to block sizeMilan Broz1-11/+12
Optional Forward Error Correction (FEC) code in dm-verity uses Reed-Solomon code and should support roots from 2 to 24. The error correction parity bytes (of roots lengths per RS block) are stored on a separate device in sequence without any padding. Currently, to access FEC device, the dm-verity-fec code uses dm-bufio client with block size set to verity data block (usually 4096 or 512 bytes). Because this block size is not divisible by some (most!) of the roots supported lengths, data repair cannot work for partially stored parity bytes. This fix changes FEC device dm-bufio block size to "roots << SECTOR_SHIFT" where we can be sure that the full parity data is always available. (There cannot be partial FEC blocks because parity must cover whole sectors.) Because the optional FEC starting offset could be unaligned to this new block size, we have to use dm_bufio_set_sector_offset() to configure it. The problem is easily reproduced using veritysetup, e.g. for roots=13: # create verity device with RS FEC dd if=/dev/urandom of=data.img bs=4096 count=8 status=none veritysetup format data.img hash.img --fec-device=fec.img --fec-roots=13 | awk '/^Root hash/{ print $3 }' >roothash # create an erasure that should be always repairable with this roots setting dd if=/dev/zero of=data.img conv=notrunc bs=1 count=8 seek=4088 status=none # try to read it through dm-verity veritysetup open data.img test hash.img --fec-device=fec.img --fec-roots=13 $(cat roothash) dd if=/dev/mapper/test of=/dev/null bs=4096 status=noxfer # wait for possible recursive recovery in kernel udevadm settle veritysetup close test With this fix, errors are properly repaired. device-mapper: verity-fec: 7:1: FEC 0: corrected 8 errors ... Without it, FEC code usually ends on unrecoverable failure in RS decoder: device-mapper: verity-fec: 7:1: FEC 0: failed to correct: -74 ... This problem is present in all kernels since the FEC code's introduction (kernel 4.5). It is thought that this problem is not visible in Android ecosystem because it always uses a default RS roots=2. Depends-on: a14e5ec66a7a ("dm bufio: subtract the number of initial sectors in dm_bufio_get_device_size") Signed-off-by: Milan Broz <gmazyland@gmail.com> Tested-by: Jérôme Carretero <cJ-ko@zougloub.eu> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Cc: stable@vger.kernel.org # 4.5+ Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2021-03-04dm bufio: subtract the number of initial sectors in dm_bufio_get_device_sizeMikulas Patocka1-0/+4
dm_bufio_get_device_size returns the device size in blocks. Before returning the value, we must subtract the nubmer of starting sectors. The number of starting sectors may not be divisible by block size. Note that currently, no target is using dm_bufio_set_sector_offset and dm_bufio_get_device_size simultaneously, so this change has no effect. However, an upcoming dm-verity-fec fix needs this change. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Reviewed-by: Milan Broz <gmazyland@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2021-03-04Merge tag 'for-linus-5.12b-rc2-tag' of ↵Linus Torvalds1-1/+11
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen fixes from Juergen Gross: "Two security issues (XSA-367 and XSA-369)" * tag 'for-linus-5.12b-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen: fix p2m size in dom0 for disabled memory hotplug case xen-netback: respect gnttab_map_refs()'s return value Xen/gnttab: handle p2m update errors on a per-slot basis
2021-03-04iommu/vt-d: Fix status code for Allocate/Free PASID commandZenghui Yu1-2/+2
As per Intel vt-d spec, Rev 3.0 (section 10.4.45 "Virtual Command Response Register"), the status code of "No PASID available" error in response to the Allocate PASID command is 2, not 1. The same for "Invalid PASID" error in response to the Free PASID command. We will otherwise see confusing kernel log under the command failure from guest side. Fix it. Fixes: 24f27d32ab6b ("iommu/vt-d: Enlightened PASID allocation") Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Acked-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20210227073909.432-1-yuzenghui@huawei.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2021-03-04iommu: Don't use lazy flush for untrusted deviceLu Baolu1-7/+8
The lazy IOTLB flushing setup leaves a time window, in which the device can still access some system memory, which has already been unmapped by the device driver. It's not suitable for untrusted devices. A malicious device might use this to attack the system by obtaining data that it shouldn't obtain. Fixes: c588072bba6b5 ("iommu/vt-d: Convert intel iommu driver to the iommu ops") Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20210225061454.2864009-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2021-03-04iommu/tegra-smmu: Fix mc errors on tegra124-nyanNicolin Chen1-1/+71
Commit 25938c73cd79 ("iommu/tegra-smmu: Rework tegra_smmu_probe_device()") removed certain hack in the tegra_smmu_probe() by relying on IOMMU core to of_xlate SMMU's SID per device, so as to get rid of tegra_smmu_find() and tegra_smmu_configure() that are typically done in the IOMMU core also. This approach works for both existing devices that have DT nodes and other devices (like PCI device) that don't exist in DT, on Tegra210 and Tegra3 upon testing. However, Page Fault errors are reported on tegra124-Nyan: tegra-mc 70019000.memory-controller: display0a: read @0xfe056b40: EMEM address decode error (SMMU translation error [--S]) tegra-mc 70019000.memory-controller: display0a: read @0xfe056b40: Page fault (SMMU translation error [--S]) After debugging, I found that the mentioned commit changed some function callback sequence of tegra-smmu's, resulting in enabling SMMU for display client before display driver gets initialized. I couldn't reproduce exact same issue on Tegra210 as Tegra124 (arm-32) differs at arch-level code. Actually this Page Fault is a known issue, as on most of Tegra platforms, display gets enabled by the bootloader for the splash screen feature, so it keeps filling the framebuffer memory. A proper fix to this issue is to 1:1 linear map the framebuffer memory to IOVA space so the SMMU will have the same address as the physical address in its page table. Yet, Thierry has been working on the solution above for a year, and it hasn't merged. Therefore, let's partially revert the mentioned commit to fix the errors. The reason why we do a partial revert here is that we can still set priv in ->of_xlate() callback for PCI devices. Meanwhile, devices existing in DT, like display, will go through tegra_smmu_configure() at the stage of bus_set_iommu() when SMMU gets probed(), as what it did before we merged the mentioned commit. Once we have the linear map solution for framebuffer memory, this change can be cleaned away. [Big thank to Guillaume who reported and helped debugging/verification] Fixes: 25938c73cd79 ("iommu/tegra-smmu: Rework tegra_smmu_probe_device()") Reported-by: Guillaume Tucker <guillaume.tucker@collabora.com> Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> Tested-by: Guillaume Tucker <guillaume.tucker@collabora.com> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20210218220702.1962-1-nicoleotsuka@gmail.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2021-03-04iommu/amd: Fix sleeping in atomic in increase_address_space()Andrey Ryabinin1-4/+6
increase_address_space() calls get_zeroed_page(gfp) under spin_lock with disabled interrupts. gfp flags passed to increase_address_space() may allow sleeping, so it comes to this: BUG: sleeping function called from invalid context at mm/page_alloc.c:4342 in_atomic(): 1, irqs_disabled(): 1, pid: 21555, name: epdcbbf1qnhbsd8 Call Trace: dump_stack+0x66/0x8b ___might_sleep+0xec/0x110 __alloc_pages_nodemask+0x104/0x300 get_zeroed_page+0x15/0x40 iommu_map_page+0xdd/0x3e0 amd_iommu_map+0x50/0x70 iommu_map+0x106/0x220 vfio_iommu_type1_ioctl+0x76e/0x950 [vfio_iommu_type1] do_vfs_ioctl+0xa3/0x6f0 ksys_ioctl+0x66/0x70 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x4e/0x100 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix this by moving get_zeroed_page() out of spin_lock/unlock section. Fixes: 754265bcab ("iommu/amd: Fix race in increase_address_space()") Signed-off-by: Andrey Ryabinin <arbn@yandex-team.com> Acked-by: Will Deacon <will@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210217143004.19165-1-arbn@yandex-team.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2021-03-04drm/amdgpu: fix parameter error of RREG32_PCIE() in amdgpu_regs_pcieKevin Wang1-2/+2
the register offset isn't needed division by 4 to pass RREG32_PCIE() Signed-off-by: Kevin Wang <kevin1.wang@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2021-03-04drm/amd/display: fix the return of the uninitialized value in retColin Ian King1-1/+1
Currently if stream->signal is neither SIGNAL_TYPE_DISPLAY_PORT_MST or SIGNAL_TYPE_DISPLAY_PORT then variable ret is uninitialized and this is checked for > 0 at the end of the function. Ret should be initialized, I believe setting it to zero is a correct default. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: bd0c064c161c ("drm/amd/display: Add return code instead of boolean for future use") Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2021-03-04drm/amdgpu: enable BACO runpm by default on sienna cichlid and navy flounderAlex Deucher1-2/+0
It works fine and was only disabled because primary GPUs don't enter runpm if there is a console bound to the fbdev due to the kmap. This will at least allow runpm on secondary cards. Reviewed-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>