summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-06-02gpio: dwapb: Drop redundant check in dwapb_irq_set_type()Andy Shevchenko
For more than 15 years we may not get into ->irq_set_type() without any meaningful type provided. Drop redundant check in dwapb_irq_set_type(). See the commit e76de9f8eb67 ("[PATCH] genirq: add SA_TRIGGER support") out of curiosity. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-06-02gpio: 104-idio-16: Fix coding style issuesNavin Sankar Velliangiri
Fixed multiple bare uses of 'unsigned' without int. Reported by checkpatch. Signed-off-by: Navin Sankar Velliangiri <navin@linumiz.com> Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-28gpiolib: Switch to bitmap_alloc()Andy Shevchenko
Switch to bitmap_alloc() to show clearly what we are allocating. Besides that it returns pointer of bitmap type instead of opaque void *. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-28gpiolib: Split fastpath array to twoAndy Shevchenko
Split fastpath array to two, i.e. for mask and for bits. At the same time declare them as bitmaps. This makes code better to read and gives a clue about use of bitmap API. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-26dt-bindings: gpio: omap: Convert to json-schemaGrygorii Strashko
Convert the OMAP GPIO Device Tree binding documentation to json-schema. The GPIO hogs node names defined to end with a 'hog' suffix. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-25gpio: wm8350: remove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-25gpio: wm8994: remove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-25gpio: wm831x: remove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-25gpio: tps65910: remove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-25gpio: sta2x11: remove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-25gpio: sprd: remove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-25gpio: spear-spics: remove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe. This change isn't removing the 'DT probe failed' message, as some may find it useful as a reason for the failed probe. But that can be part of another change if needed. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-25gpio: ath79: remove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-24gpio: tps65912: remove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-24gpio: tps65218: remove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-24gpio: tc3589x: emove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-24gpio: tps6586x: remove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-23gpio: gpio-tegra186: remove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-23gpio: gpio-tegra186: remove empty remove hookAlexandru Ardelean
The tegra186_gpio_remove hook simply does a return 0. Not defining it yields pretty much the same result. So, this can be removed. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-23gpio: da9052: remove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-23gpio: xgene: simplify probe, return devm_gpiochip_add_data() directlyAlexandru Ardelean
The handling of the return value from devm_gpiochip_add_data() is a bit redundant. It prints messages on error and success cases. While the success message may be useful, it is more in the area of log spam, and these can be printed with other forms of kernel logging. This change does a direct return with devm_gpiochip_add_data() in the probe function. The platform_set_drvdata() is needed, as this driver uses the stored private date in the PM suspend/resume routines. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-21gpio: tps68470: remove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-21gpio: bd9571mwv: remove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-21gpio: altera-a10sr: remove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-21gpio: adp5520: cleanup probe error path + remove platform_set_drvdata()Alexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. This also means that the 'err' label can be removed and all goto statements replaced with direct returns (with error codes). Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-21gpio: visconti: remove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-21gpiolib: Use sysfs_emit() in "show" functionsAndy Shevchenko
The sysfs_emit() function was introduced to make it less ambiguous which function is preferred when writing to the output buffer in a "show" callback [1]. Convert the GPIO library sysfs interface from sprintf() to sysfs_emit() accordingly, as the latter is aware of the PAGE_SIZE buffer and correctly returns the number of bytes written into the buffer. No functional change intended. [1] Documentation/filesystems/sysfs.rst Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-21gpiolib: Make use of assign_bit() API (part 2)Andy Shevchenko
We have for some time the assign_bit() API to replace open coded if (foo) set_bit(n, bar); else clear_bit(n, bar); Use this API in GPIO library code. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-21gpio: da9055: remove platform_set_drvdata() + cleanup probeAlexandru Ardelean
The platform_set_drvdata() call is only useful if we need to retrieve back the private information. Since the driver doesn't do that, it's not useful to have it. If this is removed, we can also just do a direct return on devm_gpiochip_add_data(). We don't need to print that this call failed as there are other ways to log/see this during probe. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-21gpio: stmpe: fully use convert probe to device-managedAlexandru Ardelean
The IRQ is registered via devm_request_threaded_irq(), making the driver only partially device-managed. This changeset converts the entire driver to using only devres APIs. This change also removes platform_set_drvdata() since the information is never retrieved to be used in the driver. Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> [Bart: tweaked the commit message] Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-12gpio: xilinx: No need to disable IRQs in the handlerAndy Shevchenko
In IRQ handler interrupts are already disabled, hence no need to repeat it. Even in the threaded case, it is not a problem because IRQ framework keeps interrupt disabled there as well. Remove disabling IRQ part in the handler. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Neeli Srinivas <sneeli@xilinx.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-12gpio: xilinx: Switch to use bitmap APIsAndy Shevchenko
It seems that Xilinx GPIO driver operates with bit arrays longer than 32 and thus can leverage bitmap APIs for that. It makes code better to understand. The ->probe() function is modified to try read properties for both channels since is_dual check makes only sense for the amount of pins used for the second channel. On top of that kzalloc() guarantees zero initial values for the fields in the private data structure, hence drop unneeded conditionals and assignments. The change is inspired by Syed Nayyar Waris' ideas about bitmap API extension. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Neeli Srinivas <sneeli@xilinx.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-12gpio: xilinx: Introduce xgpio_read_chan() / xgpio_write_chan()Andy Shevchenko
With the new helpers, i.e. xgpio_read_chan() / xgpio_write_chan(), the code is easier to read and maintain. No functional changes intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Neeli Srinivas <sneeli@xilinx.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-12bitmap: Make bitmap_remap() and bitmap_bitremap() available to usersAndy Shevchenko
Currently the bitmap_remap() and bitmap_bitremap() are available only for CONFIG_NUMA=y case, while some users may benefit out of it and being independent to NUMA code. Make them available to users by moving out of ifdeffery and exporting for modules. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Neeli Srinivas <sneeli@xilinx.com> Acked-by: Yury Norov <yury.norov@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-12gpiolib: Drop duplicate offset check in gpiochip_is_requested()Andy Shevchenko
gpiochip_get_desc() already does the check, drop a duplicate in gpiochip_is_requested(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-12gpio: mockup: Switch to use gpiochip_get_desc()Andy Shevchenko
Switch to use gpiochip_get_desc() helper. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-12gpio: logicvc: Remove redundant error printing in logicvc_gpio_probe()Zhen Lei
When devm_ioremap_resource() fails, a clear enough error message will be printed by its subfunction __devm_ioremap_resource(). The error information contains the device name, failure cause, and possibly resource information. Therefore, remove the error printing here to simplify code and reduce the binary size. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-12dt-bindings: gpio: convert rk3328-grf-gpio.txt to YAMLJohan Jonker
Current dts files with RK3328 GRF 'gpio' nodes are manually verified. In order to automate this process rk3328-grf-gpio.txt has to be converted to YAML. Rename 'grf-gpio' nodename to 'gpio'. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-09Linux 5.13-rc1Linus Torvalds
2021-05-09fbmem: fix horribly incorrect placement of __maybe_unusedLinus Torvalds
Commit b9d79e4ca4ff ("fbmem: Mark proc_fb_seq_ops as __maybe_unused") places the '__maybe_unused' in an entirely incorrect location between the "struct" keyword and the structure name. It's a wonder that gcc accepts that silently, but clang quite reasonably warns about it: drivers/video/fbdev/core/fbmem.c:736:21: warning: attribute declaration must precede definition [-Wignored-attributes] static const struct __maybe_unused seq_operations proc_fb_seq_ops = { ^ Fix it. Cc: Guenter Roeck <linux@roeck-us.net> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-05-09Merge tag 'drm-next-2021-05-10' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
Pull drm fixes from Dave Airlie: "Bit later than usual, I queued them all up on Friday then promptly forgot to write the pull request email. This is mainly amdgpu fixes, with some radeon/msm/fbdev and one i915 gvt fix thrown in. amdgpu: - MPO hang workaround - Fix for concurrent VM flushes on vega/navi - dcefclk is not adjustable on navi1x and newer - MST HPD debugfs fix - Suspend/resumes fixes - Register VGA clients late in case driver fails to load - Fix GEM leak in user framebuffer create - Add support for polaris12 with 32 bit memory interface - Fix duplicate cursor issue when using overlay - Fix corruption with tiled surfaces on VCN3 - Add BO size and stride check to fix BO size verification radeon: - Fix off-by-one in power state parsing - Fix possible memory leak in power state parsing msm: - NULL ptr dereference fix fbdev: - procfs disabled warning fix i915: - gvt: Fix a possible division by zero in vgpu display rate calculation" * tag 'drm-next-2021-05-10' of git://anongit.freedesktop.org/drm/drm: drm/amdgpu: Use device specific BO size & stride check. drm/amdgpu: Init GFX10_ADDR_CONFIG for VCN v3 in DPG mode. drm/amd/pm: initialize variable drm/radeon: Avoid power table parsing memory leaks drm/radeon: Fix off-by-one power_state index heap overwrite drm/amd/display: Fix two cursor duplication when using overlay drm/amdgpu: add new MC firmware for Polaris12 32bit ASIC fbmem: Mark proc_fb_seq_ops as __maybe_unused drm/msm/dpu: Delete bonkers code drm/i915/gvt: Prevent divided by zero when calculating refresh rate amdgpu: fix GEM obj leak in amdgpu_display_user_framebuffer_create drm/amdgpu: Register VGA clients after init can no longer fail drm/amdgpu: Handling of amdgpu_device_resume return value for graceful teardown drm/amdgpu: fix r initial values drm/amd/display: fix wrong statement in mst hpd debugfs amdgpu/pm: set pp_dpm_dcefclk to readonly on NAVI10 and newer gpus amdgpu/pm: Prevent force of DCEFCLK on NAVI10 and SIENNA_CICHLID drm/amdgpu: fix concurrent VM flushes on Vega/Navi v2 drm/amd/display: Reject non-zero src_y and src_x for video planes
2021-05-09Merge tag 'block-5.13-2021-05-09' of git://git.kernel.dk/linux-blockLinus Torvalds
Pull block fix from Jens Axboe: "Turns out the bio max size change still has issues, so let's get it reverted for 5.13-rc1. We'll shake out the issues there and defer it to 5.14 instead" * tag 'block-5.13-2021-05-09' of git://git.kernel.dk/linux-block: Revert "bio: limit bio max size"
2021-05-09Merge tag '5.13-rc-smb3-part3' of git://git.samba.org/sfrench/cifs-2.6Linus Torvalds
Pull cifs fixes from Steve French: "Three small SMB3 chmultichannel related changesets (also for stable) from the SMB3 test event this week. The other fixes are still in review/testing" * tag '5.13-rc-smb3-part3' of git://git.samba.org/sfrench/cifs-2.6: smb3: if max_channels set to more than one channel request multichannel smb3: do not attempt multichannel to server which does not support it smb3: when mounting with multichannel include it in requested capabilities
2021-05-09Merge tag 'sched-urgent-2021-05-09' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fixes from Thomas Gleixner: "A set of scheduler updates: - Prevent PSI state corruption when schedule() races with cgroup move. A recent commit combined two PSI callbacks to reduce the number of cgroup tree updates, but missed that schedule() can drop rq::lock for load balancing, which opens the race window for cgroup_move_task() which then observes half updated state. The fix is to solely use task::ps_flags instead of looking at the potentially mismatching scheduler state - Prevent an out-of-bounds access in uclamp caused bu a rounding division which can lead to an off-by-one error exceeding the buckets array size. - Prevent unfairness caused by missing load decay when a task is attached to a cfs runqueue. The old load of the task was attached to the runqueue and never removed. Fix it by enforcing the load update through the hierarchy for unthrottled run queue instances. - A documentation fix fot the 'sched_verbose' command line option" * tag 'sched-urgent-2021-05-09' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/fair: Fix unfairness caused by missing load decay sched: Fix out-of-bound access in uclamp psi: Fix psi state corruption when schedule() races with cgroup move sched,doc: sched_debug_verbose cmdline should be sched_verbose
2021-05-09Merge tag 'locking-urgent-2021-05-09' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking fixes from Thomas Gleixner: "A set of locking related fixes and updates: - Two fixes for the futex syscall related to the timeout handling. FUTEX_LOCK_PI does not support the FUTEX_CLOCK_REALTIME bit and because it's not set the time namespace adjustment for clock MONOTONIC is applied wrongly. FUTEX_WAIT cannot support the FUTEX_CLOCK_REALTIME bit because its always a relative timeout. - Cleanups in the futex syscall entry points which became obvious when the two timeout handling bugs were fixed. - Cleanup of queued_write_lock_slowpath() as suggested by Linus - Fixup of the smp_call_function_single_async() prototype" * tag 'locking-urgent-2021-05-09' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: futex: Make syscall entry points less convoluted futex: Get rid of the val2 conditional dance futex: Do not apply time namespace adjustment on FUTEX_LOCK_PI Revert 337f13046ff0 ("futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op") locking/qrwlock: Cleanup queued_write_lock_slowpath() smp: Fix smp_call_function_single_async prototype
2021-05-09Merge tag 'perf_urgent_for_v5.13_rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 perf fix from Borislav Petkov: "Handle power-gating of AMD IOMMU perf counters properly when they are used" * tag 'perf_urgent_for_v5.13_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/events/amd/iommu: Fix invalid Perf result due to IOMMU PMC power-gating
2021-05-09Merge tag 'x86_urgent_for_v5.13_rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: "A bunch of things accumulated for x86 in the last two weeks: - Fix guest vtime accounting so that ticks happening while the guest is running can also be accounted to it. Along with a consolidation to the guest-specific context tracking helpers. - Provide for the host NMI handler running after a VMX VMEXIT to be able to run on the kernel stack correctly. - Initialize MSR_TSC_AUX when RDPID is supported and not RDTSCP (virt relevant - real hw supports both) - A code generation improvement to TASK_SIZE_MAX through the use of alternatives - The usual misc and related cleanups and improvements" * tag 'x86_urgent_for_v5.13_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: KVM: x86: Consolidate guest enter/exit logic to common helpers context_tracking: KVM: Move guest enter/exit wrappers to KVM's domain context_tracking: Consolidate guest enter/exit wrappers sched/vtime: Move guest enter/exit vtime accounting to vtime.h sched/vtime: Move vtime accounting external declarations above inlines KVM: x86: Defer vtime accounting 'til after IRQ handling context_tracking: Move guest exit vtime accounting to separate helpers context_tracking: Move guest exit context tracking to separate helpers KVM/VMX: Invoke NMI non-IST entry instead of IST entry x86/cpu: Remove write_tsc() and write_rdtscp_aux() wrappers x86/cpu: Initialize MSR_TSC_AUX if RDTSCP *or* RDPID is supported x86/resctrl: Fix init const confusion x86: Delete UD0, UD1 traces x86/smpboot: Remove duplicate includes x86/cpu: Use alternative to generate the TASK_SIZE_MAX constant
2021-05-08Revert "bio: limit bio max size"Jens Axboe
This reverts commit cd2c7545ae1beac3b6aae033c7f31193b3255946. Alex reports that the commit causes corruption with LUKS on ext4. Revert it for now so that this can be investigated properly. Link: https://lore.kernel.org/linux-block/1620493841.bxdq8r5haw.none@localhost/ Reported-by: Alex Xu (Hello71) <alex_y_xu@yahoo.ca> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-05-08Merge tag 'riscv-for-linus-5.13-mw1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - A fix to avoid over-allocating the kernel's mapping on !MMU systems, which could lead to up to 2MiB of lost memory - The SiFive address extension errata only manifest on rv64, they are now disabled on rv32 where they are unnecessary - A pair of late-landing cleanups * tag 'riscv-for-linus-5.13-mw1' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: remove unused handle_exception symbol riscv: Consistify protect_kernel_linear_mapping_text_rodata() use riscv: enable SiFive errata CIP-453 and CIP-1200 Kconfig only if CONFIG_64BIT=y riscv: Only extend kernel reservation if mapped read-only
2021-05-08drm/i915/display: fix compiler warning about array overrunLinus Torvalds
intel_dp_check_mst_status() uses a 14-byte array to read the DPRX Event Status Indicator data, but then passes that buffer at offset 10 off as an argument to drm_dp_channel_eq_ok(). End result: there are only 4 bytes remaining of the buffer, yet drm_dp_channel_eq_ok() wants a 6-byte buffer. gcc-11 correctly warns about this case: drivers/gpu/drm/i915/display/intel_dp.c: In function ‘intel_dp_check_mst_status’: drivers/gpu/drm/i915/display/intel_dp.c:3491:22: warning: ‘drm_dp_channel_eq_ok’ reading 6 bytes from a region of size 4 [-Wstringop-overread] 3491 | !drm_dp_channel_eq_ok(&esi[10], intel_dp->lane_count)) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/display/intel_dp.c:3491:22: note: referencing argument 1 of type ‘const u8 *’ {aka ‘const unsigned char *’} In file included from drivers/gpu/drm/i915/display/intel_dp.c:38: include/drm/drm_dp_helper.h:1466:6: note: in a call to function ‘drm_dp_channel_eq_ok’ 1466 | bool drm_dp_channel_eq_ok(const u8 link_status[DP_LINK_STATUS_SIZE], | ^~~~~~~~~~~~~~~~~~~~ 6:14 elapsed This commit just extends the original array by 2 zero-initialized bytes, avoiding the warning. There may be some underlying bug in here that caused this confusion, but this is at least no worse than the existing situation that could use random data off the stack. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>