aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-06-09hwmon: (corsair-psu) fix suspend behaviorWilken Gottwalt1-0/+14
During standby some PSUs turn off the microcontroller. A re-init is required during resume or the microcontroller stays unresponsive. Fixes: d115b51e0e56 ("hwmon: add Corsair PSU HID controller driver") Signed-off-by: Wilken Gottwalt <wilken.gottwalt@posteo.net> Link: https://lore.kernel.org/r/YLjCJiVtu5zgTabI@monster.powergraphx.local Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-06-09mtd: spi-nor: otp: implement erase for Winbond and similar flashesMichael Walle4-1/+92
Winbond flashes with OTP support provide a command to erase the OTP data. This might come in handy during development. This was tested with a Winbond W25Q32JW on a LS1028A SoC with the NXP FSPI controller. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
2021-06-09mtd: spi-nor: otp: return -EROFS if region is read-onlyMichael Walle1-3/+38
SPI NOR flashes will just ignore program commands if the OTP region is locked. Thus, a user might not notice that the intended write didn't end up in the flash. Return -EROFS to the user in this case. From what I can tell, chips/cfi_cmdset_0001.c also return this error code. One could optimize spi_nor_mtd_otp_range_is_locked() to read the status register only once and not for every OTP region, but for that we would need some more invasive changes. Given that this is one-time-programmable memory and the normal access mode is reading, we just live with the small overhead. By moving the code around a bit, we can just check the length before calling spi_nor_mtd_otp_range_is_locked() and avoid an underflow there if a len is 0. This way we don't need to take the lock either. We also skip the "*retlen = 0" assignment, mtdcore already takes care of that for us. Fixes: 069089acf88b ("mtd: spi-nor: add OTP support") Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
2021-06-09mtd: spi-nor: otp: use more consistent wordingMichael Walle1-8/+19
Use the wording as used in the datasheet to describe the access methods of the security registers (aka OTP storage). This will also match the function names. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
2021-06-09mtd: spi-nor: otp: fix access to security registers in 4 byte modeMichael Walle1-2/+0
The security registers either take a 3 byte or a 4 byte address offset, depending on the address mode of the flash. Thus just leave the nor->addr_width as is. Fixes: cad3193fe9d1 ("mtd: spi-nor: implement OTP support for Winbond and similar flashes") Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Acked-by: Pratyush Yadav <p.yadav@ti.com>
2021-06-09drm/i915/uc: Use platform specific defaults for GuC/HuC enablingJohn Harrison2-2/+2
The meaning of 'default' for the enable_guc module parameter has been updated to accurately reflect what is supported on current platforms. So start using the defaults instead of forcing everything off. Although, note that right now, the default is for everything to be off anyway. So this is not a change for current platforms. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210603164812.19045-2-matthew.brost@intel.com
2021-06-09drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveauLyude Paul4-18/+186
This adds support for controlling panel backlights over eDP using VESA's standard backlight control interface. Luckily, Nvidia was cool enough to never come up with their own proprietary backlight control interface (at least, not any that I or the laptop manufacturers I've talked to are aware of), so this should work for any laptop panels which support the VESA backlight control interface. Note that we don't yet provide the panel backlight frequency to the DRM DP backlight helpers. This should be fine for the time being, since it's not required to get basic backlight controls working. For reference: there's some mentions of PWM backlight values in nouveau_reg.h, but I'm not sure these are the values we would want to use. If we figure out how to get this information in the future, we'll have the benefit of more granular backlight control. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-10-lyude@redhat.com
2021-06-09drm/dp: Extract i915's eDP backlight code into DRM helpersLyude Paul3-258/+379
Since we're about to implement eDP backlight support in nouveau using the standard protocol from VESA, we might as well just take the code that's already written for this and move it into a set of shared DRM helpers. Note that these helpers are intended to handle DPCD related backlight control bits such as setting the brightness level over AUX, probing the backlight's TCON, enabling/disabling the backlight over AUX if supported, etc. Any PWM-related portions of backlight control are explicitly left up to the driver, as these will vary from platform to platform. The only exception to this is the calculation of the PWM frequency pre-divider value. This is because the only platform-specific information required for this is the PWM frequency of the panel, which the driver is expected to provide if available. The actual algorithm for calculating this value is standard and is defined in the eDP specification from VESA. Note that these helpers do not yet implement the full range of features the VESA backlight interface provides, and only provide the following functionality (all of which was already present in i915's DPCD backlight support): * Basic control of brightness levels * Basic probing of backlight capabilities * Helpers for enabling and disabling the backlight v3: * Split out changes to i915's backlight code to separate patches to make it easier to review v4: * Style/spelling changes from Thomas Zimmermann v5: * Start using new drm_dbg_*() functions Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-9-lyude@redhat.com
2021-06-09drm/i915/dpcd_bl: Print return codes for VESA backlight failuresLyude Paul1-49/+52
Also, stop printing the DPCD register that failed, and just describe it instead. Saves us from having to look up each register offset when reading through kernel logs (plus, DPCD dumping with drm.debug |= 0x100 will give us that anyway). Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-8-lyude@redhat.com
2021-06-09drm/i915/dpcd_bl: Return early in vesa_calc_max_backlight if we can't read PWMGEN_BIT_COUNTLyude Paul1-3/+6
If we can't read DP_EDP_PWMGEN_BIT_COUNT in intel_dp_aux_vesa_calc_max_backlight() but do have a valid PWM frequency defined in the VBT, we'll keep going in the function until we inevitably fail on reading DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN. There's not much point in doing this, so just return early. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-7-lyude@redhat.com
2021-06-09drm/i915/dpcd_bl: Move VESA backlight enabling code closer togetherLyude Paul1-27/+27
No functional changes, just move set_vesa_backlight_enable() closer to it's only caller: intel_dp_aux_vesa_enable_backlight(). Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-6-lyude@redhat.com
2021-06-09drm/i915/dpcd_bl: Cache some backlight capabilities in intel_panel.backlightLyude Paul2-10/+21
Since we're about to be moving this code into shared DRM helpers, we might as well start to cache certain backlight capabilities that can be determined from the EDP DPCD, and are likely to be relevant to the majority of drivers using said helpers. The main purpose of this is just to prevent every driver from having to check everything against the eDP DPCD using DP macros, which makes the code slightly easier to read (especially since the names of some of the eDP capabilities don't exactly match up with what we actually need to use them for, like DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT for instance). Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-5-lyude@redhat.com
2021-06-09drm/i915/dpcd_bl: Cleanup intel_dp_aux_vesa_enable_backlight() a bitLyude Paul1-13/+2
Get rid of the extraneous switch case in here, and just open code edp_backlight_mode as we only ever use it once. v4: * Check that backlight mode is DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD, not DP_EDP_BACKLIGHT_CONTROL_MODE_MASK - imirkin Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-4-lyude@redhat.com
2021-06-09drm/i915/dpcd_bl: Handle drm_dpcd_read/write() return values correctlyLyude Paul1-22/+19
This is kind of an annoying aspect of DRM's DP helpers: drm_dp_dpcd_readb/writeb() return the size of bytes read/written on success, thus we want to check against that instead of checking if the return value is less than 0. I'll probably be fixing this in the near future once I start doing DP work again, also because I'd rather not mix a tree-wide refactor like that in with a patch series intended to be around introducing DP backlight helpers. So, for now let's just handle the return values from each function correctly. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-3-lyude@redhat.com
2021-06-09drm/i915/dpcd_bl: Remove redundant AUX backlight frequency calculationsLyude Paul2-46/+20
Noticed this while moving all of the VESA backlight code in i915 over to DRM helpers: it would appear that we calculate the frequency value we want to write to DP_EDP_BACKLIGHT_FREQ_SET twice even though this value never actually changes during runtime. So, let's simplify things by just caching this value in intel_panel.backlight, and re-writing it as-needed. Changes since v1: * Wrap panel->backlight.edp.vesa.pwm_freq_pre_divider in DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP check - Jani Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-2-lyude@redhat.com
2021-06-09iio: light: si1145: Drop use of %hhx format specifier.Jonathan Cameron1-5/+5
Since: commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of unnecessary %h[xudi] and %hh[xudi]") use of these format strings has been discouraged. As there are only a few such instances in IIO, this is part of a series clearing them out so they don't get copied into new drivers. Use the 0x02x form as the length specifier when used with # includes the 0x prefix and is very unlikely to be what was intended by the author. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20210603180612.3635250-5-jic23@kernel.org
2021-06-09iio: imu: inv_mpu6050: Drop use of %hhx format string.Jonathan Cameron1-3/+2
Since: commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of unnecessary %h[xudi] and %hh[xudi]") use of these format strings has been discouraged. Use the 0x02x form as the length specifier when used with # includes the 0x prefix and is very unlikely to be what was intended by the author. Part of a series removing all uses from IIO in the interestings of avoiding providing bad examples for people to copy. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20210603180612.3635250-4-jic23@kernel.org
2021-06-09iio: light: si1133: Drop remaining uses of %hhx format string.Jonathan Cameron1-7/+7
Since: commit cbacb5ab0aa0 ("docs: printk-formats: Stop encouraging use of unnecessary %h[xudi] and %hh[xudi]") use of these format strings has been discouraged. Use the 0x02x form as the length specifier when used with # includes the 0x prefix and is very unlikely to be what was intended by the author. As there are not that many in IIO, this is part of an effort to clear them out so we don't have any instances that might get copied into new drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Maxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com> Cc: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20210603180612.3635250-3-jic23@kernel.org
2021-06-09iio: si1133: fix format string warningsArnd Bergmann1-2/+2
clang complains about multiple instances of printing an integer using the %hhx format string: drivers/iio/light/si1133.c:982:4: error: format specifies type 'unsigned char' but the argument has type 'unsigned int' [-Werror,-Wformat] part_id, rev_id, mfr_id); ^~~~~~~ Print them as a normal integer instead, leaving the "#02" length modifier. Use the 0x02x form as the length specifier when used with # includes the 0x prefix and is very unlikely to be what was intended by the author. Fixes: e01e7eaf37d8 ("iio: light: introduce si1133") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20210603180612.3635250-2-jic23@kernel.org
2021-06-09misc: rtsx: separate aspm mode into MODE_REG and MODE_CFGRicky Wu9-13/+42
aspm (Active State Power Management) rtsx_comm_set_aspm: this function is for driver to make sure not enter power saving when processing of init and card_detcct ASPM_MODE_CFG: 8411 5209 5227 5229 5249 5250 Change back to use original way to control aspm ASPM_MODE_REG: 5227A 524A 5250A 5260 5261 5228 Keep the new way to control aspm Fixes: 121e9c6b5c4c ("misc: rtsx: modify and fix init_hw function") Reported-by: Chris Chiu <chris.chiu@canonical.com> Tested-by: Gordon Lack <gordon.lack@dsl.pipex.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Ricky Wu <ricky_wu@realtek.com> Link: https://lore.kernel.org/r/20210607101634.4948-1-ricky_wu@realtek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-09bus: mhi: pci-generic: Fix hibernationLoic Poulain1-1/+35
This patch fixes crash after resuming from hibernation. The issue occurs when mhi stack is builtin and so part of the 'restore-kernel', causing the device to be resumed from 'restored kernel' with a no more valid context (memory mappings etc...) and leading to spurious crashes. This patch fixes the issue by implementing proper freeze/restore callbacks. Link: https://lore.kernel.org/r/1622571445-4505-1-git-send-email-loic.poulain@linaro.org Reported-by: Shujun Wang <wsj20369@163.com> Cc: stable <stable@vger.kernel.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20210606153741.20725-4-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-09bus: mhi: pci_generic: Fix possible use-after-free in mhi_pci_remove()Wei Yongjun1-1/+1
This driver's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself. Link: https://lore.kernel.org/r/20210413160318.2003699-1-weiyongjun1@huawei.com Fixes: 8562d4fe34a3 ("mhi: pci_generic: Add health-check") Cc: stable <stable@vger.kernel.org> Reported-by: Hulk Robot <hulkci@huawei.com> Reviewed-by: Hemant kumar <hemantk@codeaurora.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20210606153741.20725-3-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-09bus: mhi: pci_generic: T99W175: update channel name from AT to DUNJarvis Jiang1-2/+2
According to MHI v1.1 specification, change the channel name of T99W175 from "AT" to "DUN" (Dial-up networking) for both channel 32 and 33, so that the channels can be bound to the Qcom WWAN control driver, and device node such as /dev/wwan0p3DUN will be generated, which is very useful for debugging modem Link: https://lore.kernel.org/r/20210429014226.21017-1-jarvis.w.jiang@gmail.com [mani: changed the dev node to /dev/wwan0p3DUN] Fixes: aac426562f56 ("bus: mhi: pci_generic: Introduce Foxconn T99W175 support") Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Jarvis Jiang <jarvis.w.jiang@gmail.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20210606153741.20725-2-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-09uacce: add print information if not enable svaKai Ye1-2/+9
Add print information necessary if user not enable sva. Signed-off-by: Kai Ye <yekai13@huawei.com> Link: https://lore.kernel.org/r/1623233345-8765-1-git-send-email-yekai13@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-09eeprom: idt_89hpesx: use SPDX-License-IdentifierAndy Shevchenko1-32/+1
Use SPDX-License-Identifier: GPL-2.0-only, instead of hand writing it. Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210607221757.81465-3-andy.shevchenko@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-09eeprom: idt_89hpesx: Restore printing the unsupported fwnode nameAndy Shevchenko1-4/+3
When iterating over child firmware nodes restore printing the name of ones that are not supported. While at it, refactor loop body to clearly show that we stop at the first match. Fixes: db15d73e5f0e ("eeprom: idt_89hpesx: Support both ACPI and OF probing") Cc: Huy Duong <qhuyduong@hotmail.com> Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210607221757.81465-2-andy.shevchenko@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-09eeprom: idt_89hpesx: Put fwnode in matching case during ->probe()Andy Shevchenko1-0/+1
device_get_next_child_node() bumps a reference counting of a returned variable. We have to balance it whenever we return to the caller. Fixes: db15d73e5f0e ("eeprom: idt_89hpesx: Support both ACPI and OF probing") Cc: Huy Duong <qhuyduong@hotmail.com> Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210607221757.81465-1-andy.shevchenko@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-09intel_idle: Adjust the SKX C6 parameters if PC6 is disabledChen Yu1-0/+33
Because cpuidle assumes worst-case C-state parameters, PC6 parameters are used for describing C6, which is worst-case for requesting CC6. When PC6 is enabled, this is appropriate. But if PC6 is disabled in the BIOS, the exit latency and target residency should be adjusted accordingly. Exit latency: Previously the C6 exit latency was measured as the PC6 exit latency. With PC6 disabled, the C6 exit latency should be the one of CC6. Target residency: With PC6 disabled, the idle duration within [CC6, PC6) would make the idle governor choose C1E over C6. This would cause low energy-efficiency. We should lower the bar to request C6 when PC6 is disabled. To fill this gap, check if PC6 is disabled in the BIOS in the MSR_PKG_CST_CONFIG_CONTROL(0xe2) register. If so, use the CC6 exit latency for C6 and set target_residency to 3 times of the new exit latency. [This is consistent with how intel_idle driver uses _CST to calculate the target_residency.] As a result, the OS would be more likely to choose C6 over C1E when PC6 is disabled, which is reasonable, because if C6 is enabled, it implies that the user cares about energy, so choosing C6 more frequently makes sense. The new CC6 exit latency of 92us was measured with wult[1] on SKX via NIC wakeup as the 99.99th percentile. Also CLX and CPX both have the same CPU model number as SkX, but their CC6 exit latencies are similar to the SKX one, 96us and 89us respectively, so reuse the SKX value for them. There is a concern that it might be better to use a more generic approach instead of optimizing every platform. However, if the required code complexity and different PC6 bit interpretation on different platforms are taken into account, tuning the code per platform seems to be an acceptable tradeoff. Link: https://intel.github.io/wult/ # [1] Suggested-by: Len Brown <len.brown@intel.com> Signed-off-by: Chen Yu <yu.c.chen@intel.com> Reviewed-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-09z2ram: remove unnecessary oom messageZhen Lei1-8/+2
Fixes scripts/checkpatch.pl warning: WARNING: Possible unnecessary 'out of memory' message Remove it can help us save a bit of memory. Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-06-09sx8: remove unnecessary oom messageZhen Lei1-2/+0
Fixes scripts/checkpatch.pl warning: WARNING: Possible unnecessary 'out of memory' message Remove it can help us save a bit of memory. Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-06-09sunvdc: remove unnecessary oom messageZhen Lei1-2/+1
Fixes scripts/checkpatch.pl warning: WARNING: Possible unnecessary 'out of memory' message Remove it can help us save a bit of memory. Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-06-09mtip32xx: remove unnecessary oom messageZhen Lei1-21/+5
Fixes scripts/checkpatch.pl warning: WARNING: Possible unnecessary 'out of memory' message Remove it can help us save a bit of memory. Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-06-09drbd: remove unnecessary oom messageZhen Lei1-16/+6
Fixes scripts/checkpatch.pl warning: WARNING: Possible unnecessary 'out of memory' message Remove it can help us save a bit of memory. Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-06-09aoe: remove unnecessary oom messageZhen Lei1-3/+1
Fixes scripts/checkpatch.pl warning: WARNING: Possible unnecessary 'out of memory' message Remove it can help us save a bit of memory. Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-06-09counter: stm32-timer-cnt: Add const qualifier for actions_list arrayWilliam Breathitt Gray1-1/+1
The struct counter_synapse actions_list member expects a const enum counter_synapse_action array. This patch adds the const qualifier to the stm32_synapse_actions to match actions_list. Cc: Benjamin Gaignard <benjamin.gaignard@st.com> Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/9675edda958ee2ca371d271f46445d3e1934ba82.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: stm32-lptimer-cnt: Add const qualifier for actions_list arrayWilliam Breathitt Gray1-1/+1
The struct counter_synapse actions_list member expects a const enum counter_synapse_action array. This patch adds the const qualifier to the stm32_lptim_cnt_synapse_actions to match actions_list. Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/785e0daa3633923ede42394f423fcf94c4469154.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: microchip-tcb-capture: Add const qualifier for actions_list arrayWilliam Breathitt Gray1-1/+1
The struct counter_synapse actions_list member expects a const enum counter_synapse_action array. This patch adds the const qualifier to the mchp_tc_synapse_actions to match actions_list. Cc: Kamel Bouhara <kamel.bouhara@bootlin.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/165f9682ce308a60a477aaa56fdae7bc949dc218.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: ftm-quaddec: Add const qualifier for actions_list arrayWilliam Breathitt Gray1-1/+1
The struct counter_synapse actions_list member expects a const enum counter_synapse_action array. This patch adds the const qualifier to the ftm_quaddec_synapse_actions to match actions_list. Cc: Patrick Havelange <patrick.havelange@essensium.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/db1df2021efb1b98e6d1a50787be5a52a1896574.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: 104-quad-8: Add const qualifier for actions_list arrayWilliam Breathitt Gray1-2/+2
The struct counter_synapse actions_list member expects a const enum counter_synapse_action array. This patch adds the const qualifier to the quad8_index_actions_list and quad8_synapse_actions_list to match actions_list. Acked-by: Syed Nayyar Waris <syednwaris@gmail.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/776ba3ad0a3c609d3600cffe0ed6446baf29fee9.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: stm32-timer-cnt: Add const qualifier for functions_list arrayWilliam Breathitt Gray1-1/+1
The struct counter_count functions_list member expects a const enum counter_count_function array. This patch adds the const qualifier to the stm32_count_functions to match functions_list. Cc: Benjamin Gaignard <benjamin.gaignard@st.com> Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/46a1e7096dd9280d8f241894186b3c903956a55f.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: stm32-lptimer-cnt: Add const qualifier for functions_list arrayWilliam Breathitt Gray1-1/+1
The struct counter_count functions_list member expects a const enum counter_count_function array. This patch adds the const qualifier to the stm32_lptim_cnt_functions to match functions_list. Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/08830119594acdb3bc9d36ae2e65b2eb26589ade.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: microchip-tcb-capture: Add const qualifier for functions_list arrayWilliam Breathitt Gray1-1/+1
The struct counter_count functions_list member expects a const enum counter_count_function array. This patch adds the const qualifier to the mchp_tc_count_functions to match functions_list. Cc: Kamel Bouhara <kamel.bouhara@bootlin.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/74cb91ab7b459563762ec28633cd8808093aa2ad.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: interrupt-cnt: Add const qualifier for functions_list arrayWilliam Breathitt Gray1-1/+1
The struct counter_count functions_list member expects a const enum counter_count_function array. This patch adds the const qualifier to the interrupt__cnt_functions to match functions_list. Cc: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/86f7fb77f703cf2508a6b4ee9cf80aa523392976.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: 104-quad-8: Add const qualifier for functions_list arrayWilliam Breathitt Gray1-1/+1
The struct counter_count functions_list member expects a const enum counter_count_function array. This patch adds the const qualifier to the quad8_count_functions_list to match functions_list. Acked-by: Syed Nayyar Waris <syednwaris@gmail.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/6847da7553208e7f2554e6c7688e2021f7e19716.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: 104-quad-8: Add const qualifiers for quad8_preset_register_setWilliam Breathitt Gray1-2/+2
Add some safety by qualifying the quad8_preset_register_set() function parameters as const. Acked-by: Syed Nayyar Waris <syednwaris@gmail.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/050f1b518eeae8e3683f7d6d11f3219a137adf48.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09counter: 104-quad-8: Annotate hardware config module parameterWilliam Breathitt Gray1-1/+1
When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates the 104-QUAD-8 driver. Acked-by: Syed Nayyar Waris <syednwaris@gmail.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/97ce79878a26809f0b15b2eac9a86ca39e0ecd74.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09libnvdimm/pmem: Fix blk_cleanup_disk() usageDan Williams1-3/+3
The queue_to_disk() helper can not be used after del_gendisk() communicate @disk via the pgmap->owner. Otherwise, queue_to_disk() returns NULL resulting in the splat below. Kernel attempted to read user page (330) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000330 Faulting instruction address: 0xc000000000906344 Oops: Kernel access of bad area, sig: 11 [#1] [..] NIP [c000000000906344] pmem_pagemap_cleanup+0x24/0x40 LR [c0000000004701d4] memunmap_pages+0x1b4/0x4b0 Call Trace: [c000000022cbb9c0] [c0000000009063c8] pmem_pagemap_kill+0x28/0x40 (unreliable) [c000000022cbb9e0] [c0000000004701d4] memunmap_pages+0x1b4/0x4b0 [c000000022cbba90] [c0000000008b28a0] devm_action_release+0x30/0x50 [c000000022cbbab0] [c0000000008b39c8] release_nodes+0x2f8/0x3e0 [c000000022cbbb60] [c0000000008ac440] device_release_driver_internal+0x190/0x2b0 [c000000022cbbba0] [c0000000008a8450] unbind_store+0x130/0x170 Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com> Fixes: 87eb73b2ca7c ("nvdimm-pmem: convert to blk_alloc_disk/blk_cleanup_disk") Link: http://lore.kernel.org/r/DFB75BA8-603F-4A35-880B-C5B23EF8FA7D@linux.vnet.ibm.com Cc: Christoph Hellwig <hch@lst.de> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com> Link: https://lore.kernel.org/r/162310994435.1571616.334551212901820961.stgit@dwillia2-desk3.amr.corp.intel.com [axboe: fold in compile warning fix] Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-06-09counter: 104-quad-8: Remove pointless commentWilliam Breathitt Gray1-1/+0
It is obvious that devm_counter_register() is used to register a Counter device, so a comment stating such is pointless here. Acked-by: Syed Nayyar Waris <syednwaris@gmail.com> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Link: https://lore.kernel.org/r/77e9f3daa091d0ad0ee56b8973705dd03db85dd4.1623201081.git.vilhelm.gray@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-06-09drm/i915/adl_p: Same slices mask is not same Dbuf stateStanislav Lisovskiy1-2/+4
We currently treat same slice mask as a same DBuf state and skip updating the Dbuf slices, if we detect that. This is wrong as if we have a multi to single pipe change or vice versa, that would be treated as a same Dbuf state and thus no changes required, so we don't get Mbus updated, causing issues. Solution: check also mbus_join, in addition to slices mask. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210527110106.21434-1-stanislav.lisovskiy@intel.com
2021-06-09drm/i915/adl_p: CDCLK crawl support for ADLStanislav Lisovskiy4-9/+68
CDCLK crawl feature allows to change CDCLK frequency without disabling the actual PLL and doesn't require a full modeset. v2: - Added has_cdclk_crawl as a feature flag to intel_device_info(Matt Roper) - s/gen13_cdclk_pll_crawl/adlp_cdclk_pll_crawl/ (Matt Roper) Cc: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210603065038.7298-1-stanislav.lisovskiy@intel.com