aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-08-18drm/nouveau: rip out nvkm_client.superBen Skeggs24-120/+27
No longer required now that userspace can't touch anything that might need it, and should fix DRM MM operations racing with each other, and the random hangs/crashes that come with that. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-08-18drm/nouveau: block a bunch of classes from userspaceBen Skeggs4-15/+48
Long ago, there had been plans for making use of a bunch of these APIs from userspace and there's various checks in place to stop misbehaving. Countless other projects have occurred in the meantime, and the pieces didn't finish falling into place for that to happen. They will (hopefully) in the not-too-distant future, but it won't look quite as insane. The super checks are causing problems right now, and are going to be removed. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-08-18drm/nouveau/fifo/nv50-: rip out dma channelsBen Skeggs7-194/+0
I honestly don't even know why... These have never been used. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-08-18drm/nouveau/kms/nv50: workaround EFI GOP window channel format differencesBen Skeggs3-4/+37
Should fix some initial modeset failures on (at least) Ampere boards. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-08-18drm/nouveau/disp: power down unused DP links during initBen Skeggs3-1/+11
When booted with multiple displays attached, the EFI GOP driver on (at least) Ampere, can leave DP links powered up that aren't being used to display anything. This confuses our tracking of SOR routing, with the likely result being a failed modeset and display engine hang. Fix this by (ab?)using the DisableLT IED script to power-down the link, restoring HW to a state the driver expects. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-08-18drm/nouveau: recognise GA107Ben Skeggs1-0/+21
Still no GA106 as I don't have HW to verif. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2021-08-18staging: rts5208: Fix get_ms_information() heap buffer sizeKees Cook1-7/+3
Fix buf allocation size (it needs to be 2 bytes larger). Found when __alloc_size() annotations were added to kmalloc() interfaces. In file included from ./include/linux/string.h:253, from ./include/linux/bitmap.h:10, from ./include/linux/cpumask.h:12, from ./arch/x86/include/asm/paravirt.h:17, from ./arch/x86/include/asm/irqflags.h:63, from ./include/linux/irqflags.h:16, from ./include/linux/rcupdate.h:26, from ./include/linux/rculist.h:11, from ./include/linux/pid.h:5, from ./include/linux/sched.h:14, from ./include/linux/blkdev.h:5, from drivers/staging/rts5208/rtsx_scsi.c:12: In function 'get_ms_information', inlined from 'ms_sp_cmnd' at drivers/staging/rts5208/rtsx_scsi.c:2877:12, inlined from 'rtsx_scsi_handler' at drivers/staging/rts5208/rtsx_scsi.c:3247:12: ./include/linux/fortify-string.h:54:29: warning: '__builtin_memcpy' forming offset [106, 107] is out of the bounds [0, 106] [-Warray-bounds] 54 | #define __underlying_memcpy __builtin_memcpy | ^ ./include/linux/fortify-string.h:417:2: note: in expansion of macro '__underlying_memcpy' 417 | __underlying_##op(p, q, __fortify_size); \ | ^~~~~~~~~~~~~ ./include/linux/fortify-string.h:463:26: note: in expansion of macro '__fortify_memcpy_chk' 463 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ | ^~~~~~~~~~~~~~~~~~~~ drivers/staging/rts5208/rtsx_scsi.c:2851:3: note: in expansion of macro 'memcpy' 2851 | memcpy(buf + i, ms_card->raw_sys_info, 96); | ^~~~~~ Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-staging@lists.linux.dev Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210818044252.1533634-1-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18staging: r8188eu: Remove code depending on NAT25_LOOKUPFabio M. De Francesco2-164/+1
Remove all the code related to the management of the NAT25_LOOKUP method in nat25_db_handle(). The only function that used that method was the now deleted nat25_handle_frame(). Remove the NAT25_LOOKUP entry from the NAT25_METHOD enum because it is not anymore used everywhere else in the code of the driver. Remove the 'sender' pointer to integer. Remove __nat25_db_network_lookup_and_replace(). Following the deletion of the code related to the NAT25_LOOKUP method, they are no more needed. Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Link: https://lore.kernel.org/r/20210817185723.15192-1-fmdefrancesco@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-18s390/sclp: reserve memory occupied by sclp early bufferAlexander Egorenkov1-2/+0
The memory block occupied by the SCLP early buffer that is allocated by the decompressor and then handed over to the decompressed kernel, must be reserved to prevent it from being reused for other purposes. This is necessary because the SCLP early buffer is still in use during kernel initialization. Fixes: f1d3c5323772 ("s390/boot: move sclp early buffer from fixed address in asm to C") Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com> Reported-by: Alexander Gordeev <agordeev@linux.ibm.com> Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-08-18s390/zcrypt: fix wrong offset index for APKA master key valid stateHarald Freudenberger1-4/+4
Tests showed a mismatch between what the CCA tool reports about the APKA master key state and what's displayed by the zcrypt dd in sysfs. After some investigation, we found out that the documentation which was the source for the zcrypt dd implementation lacks the listing of 3 fields. So this patch now moves the evaluation of the APKA master key state to the correct offset. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-08-18s390/qdio: remove unused support for SLIB parametersJulian Wiedmann2-38/+0
Neither of the two drivers provides any SLIB parameter data, so get rid of the dead code. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-08-18s390/qdio: consolidate QIB codeJulian Wiedmann1-27/+15
Move all QIB-related code into qdio_setup_qib(), and slightly re-order it according to the order of the struct's fields. This makes it easier to understand what the QIB actually looks like before we send it to HW. Also get rid of the qebsm_possible() helper - as 31-bit support is long gone, the comment doesn't make any sense. And while removing some stale QIB-related comment, also move the clearing of the QDR into its proper place. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-08-18s390/qdio: use dev_info() in qdio_print_subchannel_info()Julian Wiedmann1-5/+2
Prefer dev_info() over a raw printk. This also adds the device and driver names into the output, so that we have: Before: qdio: 0.0.17c0 ZFCP on SC 17 using [...] After: zfcp 0.0.17c0: qdio: ZFCP on SC 17 using [...] Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-08-18s390/qdio: fine-tune the queue syncJulian Wiedmann1-11/+20
Push the sync check from qdio_inspect_queue() down into the two get_*_buffer_frontier() code paths, where we actually need the sync to look at the current queue state. This lets us avoid the check when we know that there is no work on the queue (ie. when q->nr_buf_used is 0). While at it introduce the qdio_sync_*_queue() helpers, so that we can avoid the branch on q->is_input_q when we already know the queue type. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-08-18s390/qdio: clean up SIGA capability trackingJulian Wiedmann3-33/+15
Don't bother with translating the SIGA-related capability bits into our own internal format, just cache the full qdioac1 field instead. Also adjust the helper macros so that they take a qdio_irq argument and can be used everywhere, instead of taking a qdio_q and then internally dereferencing the parent pointer. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-08-18s390/qdio: remove unused sync-after-IRQ infrastructureJulian Wiedmann2-16/+3
The queue processing is fully decoupled from any preceding interrupt, so we're no longer making any use of the sync-after-IRQ HW capabilities. And as SIGA-sync is a legacy feature, there's also not much point in re-designing the driver & qdio-layer code just so that we can potentially avoid a few syncs. So just remove all the leftover code. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-08-18s390/qdio: use absolute data address in ESTABLISH ccwJulian Wiedmann1-1/+1
Clean up yet another path where HW wants an absolute address, and we've been implicitly relying on V=R. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-08-18s390/cio: add dev_busid sysfs entry for each subchannelVineeth Vijayan1-0/+17
Introduce dev_busid, which exports the device-id associated with the io-subchannel (and message-subchannel). The dev_busid indicates that of the device which may be physically installed on the corrosponding subchannel. The dev_busid value "none" indicates that the subchannel is not valid, there is no I/O device currently associated with the subchannel. The dev_busid information would be helpful to write device-specific udev-rules associated with the subchannel. The dev_busid interface would be available even when the sch is not bound to any driver or if there is no operational device connected on it. Hence this attribute can be used to write udev-rules which are specific to the device associated with the subchannel. Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com> Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-08-18s390/cio: add rescan functionality on channel subsystemVineeth Vijayan1-0/+13
This patch introduces a new rescan sys-interface for channel-subsystem. The rescan interface allows the user to invoke an evaluation of all subchannels defined in the I/O configuration. The new rescan interface can be found at /sys/devices/css0/rescan and can be triggered by, echo > /sys/devices/css0/rescan Writing to this interface triggers subchannel evaluation. The write request completes only after scan-related work has completed This user-invoked subchannel evaluation allows manual recovery in error situations such as: - restart of device discovery after resolution of temporary device error - inconsistent OS view of subchannel state due to missing state-change interrupts (CRWs) Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com> Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2021-08-18platform/x86: gigabyte-wmi: add support for X570 GAMING XThomas Weißschuh1-0/+1
Reported as working here: https://github.com/t-8ch/linux-gigabyte-wmi-driver/issues/1#issuecomment-900263115 Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20210817154628.84992-1-linux@weissschuh.net Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-08-18platform/x86: gigabyte-wmi: add support for X570 GAMING XThomas Weißschuh1-0/+1
Reported as working here: https://github.com/t-8ch/linux-gigabyte-wmi-driver/issues/1#issuecomment-900263115 Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20210817154628.84992-1-linux@weissschuh.net Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-08-18platform/x86: think-lmi: add debug_cmdMark Pearson2-0/+81
Many Lenovo BIOS's support the ability to send a debug command which is useful for debugging and testing unreleased or early features. Adding support for this feature as a module parameter. Signed-off-by: Mark Pearson <markpearson@lenovo.com> Link: https://lore.kernel.org/r/20210817001501.293501-1-markpearson@lenovo.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-08-18drm/vc4: hdmi: make vc4_hdmi_codec_pdata staticJiapeng Chong1-1/+1
This symbol is not used outside of vc4_hdmi.c, so marks it static. Fix the following sparse warning: drivers/gpu/drm/vc4/vc4_hdmi.c:1479:25: warning: symbol 'vc4_hdmi_codec_pdata' was not declared. Should it be static? Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/1627640794-15718-1-git-send-email-jiapeng.chong@linux.alibaba.com
2021-08-18thermal/drivers/qcom: Add support for LMh driverThara Gopinath3-0/+243
Driver enabling various pieces of Limits Management Hardware(LMh) for cpu cluster0 and cpu cluster1 namely kick starting monitoring of temperature, current, battery current violations, enabling reliability algorithm and setting up various temperature limits. The following has been explained in the cover letter. I am including this here so that this remains in the commit message as well. LMh is a hardware infrastructure on some Qualcomm SoCs that can enforce temperature and current limits as programmed by software for certain IPs like CPU. On many newer LMh is configured by firmware/TZ and no programming is needed from the kernel side. But on certain SoCs like sdm845 the firmware does not do a complete programming of the h/w. On such soc's kernel software has to explicitly set up the temperature limits and turn on various monitoring and enforcing algorithms on the hardware. Tested-by: Steev Klimaszewski <steev@kali.org> # Lenovo Yoga C630 Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210809191605.3742979-3-thara.gopinath@linaro.org
2021-08-18firmware: qcom_scm: Introduce SCM calls to access LMhThara Gopinath2-0/+62
Introduce SCM calls to access/configure limits management hardware(LMH). Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210809191605.3742979-2-thara.gopinath@linaro.org
2021-08-18leds: trigger: remove reference to obsolete CONFIG_IDE_GD_ATALukas Bulwahn1-1/+1
Commit b7fb14d3ac63 ("ide: remove the legacy ide driver") removes the definition of the config IDE_GD_ATA. So, remove the obsolete reference in ./drivers/leds/trigger/Kconfig. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-08-18leds: lp50xx: Fix chip name in KConfigJan Kundrát1-1/+1
The 9-channel one is called LP5009, not LP509. Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-08-18leds: pwm: add support for default-state device propertyDenis Osterland-Heim1-6/+43
This patch adds support for "default-state" devicetree property, which allows to defer pwm init to first use of led. This allows to configure the PWM early in bootloader to let the LED blink until an application in Linux userspace sets something different. Signed-off-by: Denis Osterland-Heim <Denis.Osterland@diehl.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-08-18leds: move default_state read from fwnode to coreDenis Osterland-Heim3-10/+18
This patch introduces a new function to read initial default_state from fwnode. Suggested-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Denis Osterland-Heim <Denis.Osterland@diehl.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-08-18dm crypt: Avoid percpu_counter spinlock contention in crypt_page_alloc()Arne Welzel1-1/+6
On systems with many cores using dm-crypt, heavy spinlock contention in percpu_counter_compare() can be observed when the page allocation limit for a given device is reached or close to be reached. This is due to percpu_counter_compare() taking a spinlock to compute an exact result on potentially many CPUs at the same time. Switch to non-exact comparison of allocated and allowed pages by using the value returned by percpu_counter_read_positive() to avoid taking the percpu_counter spinlock. This may over/under estimate the actual number of allocated pages by at most (batch-1) * num_online_cpus(). Currently, batch is bounded by 32. The system on which this issue was first observed has 256 CPUs and 512GB of RAM. With a 4k page size, this change may over/under estimate by 31MB. With ~10G (2%) allowed dm-crypt allocations, this seems an acceptable error. Certainly preferred over running into the spinlock contention. This behavior was reproduced on an EC2 c5.24xlarge instance with 96 CPUs and 192GB RAM as follows, but can be provoked on systems with less CPUs as well. * Disable swap * Tune vm settings to promote regular writeback $ echo 50 > /proc/sys/vm/dirty_expire_centisecs $ echo 25 > /proc/sys/vm/dirty_writeback_centisecs $ echo $((128 * 1024 * 1024)) > /proc/sys/vm/dirty_background_bytes * Create 8 dmcrypt devices based on files on a tmpfs * Create and mount an ext4 filesystem on each crypt devices * Run stress-ng --hdd 8 within one of above filesystems Total %system usage collected from sysstat goes to ~35%. Write throughput on the underlying loop device is ~2GB/s. perf profiling an individual kworker kcryptd thread shows the following profile, indicating spinlock contention in percpu_counter_compare(): 99.98% 0.00% kworker/u193:46 [kernel.kallsyms] [k] ret_from_fork | --ret_from_fork kthread worker_thread | --99.92%--process_one_work | |--80.52%--kcryptd_crypt | | | |--62.58%--mempool_alloc | | | | | --62.24%--crypt_page_alloc | | | | | --61.51%--__percpu_counter_compare | | | | | --61.34%--__percpu_counter_sum | | | | | |--58.68%--_raw_spin_lock_irqsave | | | | | | | --58.30%--native_queued_spin_lock_slowpath | | | | | --0.69%--cpumask_next | | | | | --0.51%--_find_next_bit | | | |--10.61%--crypt_convert | | | | | |--6.05%--xts_crypt ... After applying this patch and running the same test, %system usage is lowered to ~7% and write throughput on the loop device increases to ~2.7GB/s. perf report shows mempool_alloc() as ~8% rather than ~62% in the profile and not hitting the percpu_counter() spinlock anymore. |--8.15%--mempool_alloc | | | |--3.93%--crypt_page_alloc | | | | | --3.75%--__alloc_pages | | | | | --3.62%--get_page_from_freelist | | | | | --3.22%--rmqueue_bulk | | | | | --2.59%--_raw_spin_lock | | | | | --2.57%--native_queued_spin_lock_slowpath | | | --3.05%--_raw_spin_lock_irqsave | | | --2.49%--native_queued_spin_lock_slowpath Suggested-by: DJ Gregor <dj@corelight.com> Reviewed-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Arne Welzel <arne.welzel@corelight.com> Fixes: 5059353df86e ("dm crypt: limit the number of allocated pages") Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2021-08-17scsi: sd: Do not exit sd_spinup_disk() quietlyChristian Loehle1-1/+3
The sd_spinup_disk() function logs what is happening. Unfortunately this output stops if the media was marked as removed in the meantime. Add a print for this case too. Link: https://lore.kernel.org/r/CWXP265MB26803209FD08A64222EEEA02C4FD9@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Christian Loehle <cloehle@hyperstone.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-08-17scsi: ibmvfc: Do not wait for initial device scanHannes Reinecke2-3/+9
The initial device scan might take some time, and there really is no need to wait for it during probe(). So return immediately from scsi_scan_host() during probe() and avoid any udev stalls during booting. Link: https://lore.kernel.org/r/20210817075306.11315-1-mwilck@suse.com Acked-by: Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by: Hannes Reinecke <hare@suse.com> Signed-off-by: Martin Wilck <mwilck@suse.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-08-17scsi: target: Fix sense key for invalid EXTENDED COPY requestSergey Samoylenko1-11/+15
TCM fails to pass the following tests in libiscsi: SCSI.ExtendedCopy.DescrType SCSI.ExtendedCopy.DescrLimits SCSI.ExtendedCopy.ParamHdr SCSI.ExtendedCopy.ValidSegDescr SCSI.ExtendedCopy.ValidTgtDescr The xcopy code always returns the same NOT READY sense key for all detected errors. Change the sense key for invalid requests to ILLEGAL REQUEST, and for aborted transfers to COPY ABORTED. Link: https://lore.kernel.org/r/20210803145410.80147-3-s.samoylenko@yadro.com Fixes: d877d7275be3 ("target: Fix a deadlock between the XCOPY code and iSCSI session shutdown") Reviewed-by: David Disseldorp <ddiss@suse.de> Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by: Konstantin Shelekhin <k.shelekhin@yadro.com> Signed-off-by: Sergey Samoylenko <s.samoylenko@yadro.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-08-17scsi: target: Allows backend drivers to fail with specific sense codesSergey Samoylenko1-3/+12
Currently, backend drivers can fail I/O with SAM_STAT_CHECK_CONDITION which gets us TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE. Add a new helper that allows backend drivers to fail with specific sense codes. This is based on a patch from Mike Christie <michael.christie@oracle.com>. Cc: Mike Christie <michael.christie@oracle.com> Link: https://lore.kernel.org/r/20210803145410.80147-2-s.samoylenko@yadro.com Reviewed-by: David Disseldorp <ddiss@suse.de> Signed-off-by: Sergey Samoylenko <s.samoylenko@yadro.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-08-17scsi: smartpqi: Replace one-element array with flexible-array memberGustavo A. R. Silva2-3/+2
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use "flexible array members"[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code a bit according to the use of a flexible-array member in struct pqi_event_config instead of a one-element array, and use the struct_size() helper. This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). This issue was found with the help of Coccinelle and audited and fixed, manually. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/109 Link: https://lore.kernel.org/r/20210810210741.GA58765@embeddedor Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-08-17scsi: target: pscsi: Fix possible null-pointer dereference in pscsi_complete_cmd()Tuo Li1-9/+9
The return value of transport_kmap_data_sg() is assigned to the variable buf: buf = transport_kmap_data_sg(cmd); And then it is checked: if (!buf) { This indicates that buf can be NULL. However, it is dereferenced in the following statements: if (!(buf[3] & 0x80)) buf[3] |= 0x80; if (!(buf[2] & 0x80)) buf[2] |= 0x80; To fix these possible null-pointer dereferences, dereference buf and call transport_kunmap_data_sg() only when buf is not NULL. Link: https://lore.kernel.org/r/20210810040414.248167-1-islituo@gmail.com Reported-by: TOTE Robot <oslab@tsinghua.edu.cn> Reviewed-by: Bodo Stroesser <bostroesser@gmail.com> Signed-off-by: Tuo Li <islituo@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-08-17scsi: core: Remove scsi_cmnd.tagJohn Garry1-1/+0
It is never read, so get rid of it. Link: https://lore.kernel.org/r/1628862553-179450-4-git-send-email-john.garry@huawei.com Reviewed-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-08-17scsi: ibmvfc: Stop using scsi_cmnd.tagJohn Garry1-1/+1
Use scsi_cmd_to_rq(scsi_cmnd)->tag in preference to scsi_cmnd.tag. Link: https://lore.kernel.org/r/1629207817-211936-1-git-send-email-john.garry@huawei.com Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2021-08-17ixgbe, xsk: clean up the resources in ixgbe_xsk_pool_enable error pathWang Hai1-1/+4
In ixgbe_xsk_pool_enable(), if ixgbe_xsk_wakeup() fails, We should restore the previous state and clean up the resources. Add the missing clear af_xdp_zc_qps and unmap dma to fix this bug. Fixes: d49e286d354e ("ixgbe: add tracking of AF_XDP zero-copy state for each queue pair") Fixes: 4a9b32f30f80 ("ixgbe: fix potential RX buffer starvation for AF_XDP") Signed-off-by: Wang Hai <wanghai38@huawei.com> Acked-by: Magnus Karlsson <magnus.karlsson@intel.com> Tested-by: Sandeep Penigalapati <sandeep.penigalapati@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://lore.kernel.org/r/20210817203736.3529939-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-17PCI: Remove reset_fn field from pci_devAmey Narkhede6-8/+6
"reset_fn" indicates whether the device supports any reset mechanism. Remove the use of reset_fn in favor of the reset_methods array that tracks supported reset mechanisms of a device and their ordering. The octeon driver incorrectly used reset_fn to detect whether the device supports FLR or not. Use pcie_reset_flr() to probe whether it supports FLR. Co-developed-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-5-ameynarkhede03@gmail.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
2021-08-17PCI: Add array to track reset method orderingAmey Narkhede3-44/+63
Add reset_methods[] in struct pci_dev to keep track of reset mechanisms supported by the device and their ordering. Refactor probing and reset functions to take advantage of calling convention of reset functions. Co-developed-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-4-ameynarkhede03@gmail.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
2021-08-17of: property: fw_devlink: Add support for "leds" and "backlight"Saravana Kannan1-0/+4
Allows tracking dependencies between leds/backlights devices and their consumers. Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210814023132.2729731-2-saravanak@google.com Signed-off-by: Rob Herring <robh@kernel.org>
2021-08-17Merge tag 'wireless-drivers-2021-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-driversJakub Kicinski6-14/+91
Kalle Valo says: ==================== wireless-drivers fixes for v5.14 First set of fixes for v5.14 and nothing major this time. New devices for iwlwifi and one fix for a compiler warning. iwlwifi * support for new devices mt76 * fix compiler warning about MT_CIPHER_NONE * tag 'wireless-drivers-2021-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers: mt76: fix enum type mismatch iwlwifi: add new so-jf devices iwlwifi: add new SoF with JF devices iwlwifi: pnvm: accept multiple HW-type TLVs ==================== Link: https://lore.kernel.org/r/20210817171027.EC1E6C43460@smtp.codeaurora.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-08-17hwmon: remove amd_energy driver in MakefileLukas Bulwahn1-1/+0
Commit 9049572fb145 ("hwmon: Remove amd_energy driver") removes the driver, but misses to adjust the Makefile. Hence, ./scripts/checkkconfigsymbols.py warns: SENSORS_AMD_ENERGY Referencing files: drivers/hwmon/Makefile Remove the missing piece of this driver removal. Fixes: 9049572fb145 ("hwmon: Remove amd_energy driver") Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20210817084811.10673-1-lukas.bulwahn@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-08-17hwmon: (dell-smm) Rework SMM function debuggingArmin Wolf1-15/+6
Drop #ifdef DEBUG and use ktime_us_delta() for improved precision. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20210814190516.26718-1-W_Armin@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-08-17hwmon: (dell-smm) Mark i8k_get_fan_nominal_speed as __initArmin Wolf1-1/+1
Mark function i8k_get_fan_nominal_speed() as __init since it is only used in code also marked as __init. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20210814143637.11922-5-W_Armin@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-08-17hwmon: (dell-smm) Mark tables as __initconstArmin Wolf1-4/+4
Both the config and the DMI tables never change and are only used during module init for setting up the device data struct. Mark all of them as const and __initconst for a smaller runtime memory footprint. Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20210814143637.11922-2-W_Armin@gmx.de Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-08-17hwmon: (pmbus/bpa-rs600) Add workaround for incorrect Pin maxChris Packham1-0/+23
BPD-RS600 modules running firmware v5.70 misreport the MFR_PIN_MAX. The indicate a maximum of 1640W instead of 700W. Detect the invalid reading and return a sensible value instead. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20210812014000.26293-3-chris.packham@alliedtelesis.co.nz Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-08-17hwmon: (pmbus/bpa-rs600) Don't use rated limits as warn limitsChris Packham1-25/+0
In the initial implementation a number of PMBUS_x_WARN_LIMITs were mapped to MFR fields. This was incorrect as these MFR limits reflect the rated limit as opposed to a limit which will generate warning. Instead return -ENXIO like we were already doing for other WARN_LIMITs. Subsequently these rated limits have been exposed generically as new fields in the sysfs ABI so the values are still available. Fixes: 15b2703e5e02 ("hwmon: (pmbus) Add driver for BluTek BPA-RS600") Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20210812014000.26293-2-chris.packham@alliedtelesis.co.nz Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2021-08-17hwmon: (axi-fan-control) Support temperature vs pwm pointsNuno Sá1-1/+73
The HW has some predefined points where it will associate a PWM value. However some users might want to better set these points to their usecases. This patch exposes these points as pwm auto_points: * pwm1_auto_point1_temp_hyst: temperature threshold below which PWM should be 0%; * pwm1_auto_point1_temp: temperature threshold above which PWM should be 25%; * pwm1_auto_point2_temp_hyst: temperature threshold below which PWM should be 25%; * pwm1_auto_point2_temp: temperature threshold above which PWM should be 50%; * pwm1_auto_point3_temp_hyst: temperature threshold below which PWM should be 50%; * pwm1_auto_point3_temp: temperature threshold above which PWM should be 75%; * pwm1_auto_point4_temp_hyst: temperature threshold below which PWM should be 75%; * pwm1_auto_point4_temp: temperature threshold above which PWM should be 100%; Signed-off-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210811114853.159298-4-nuno.sa@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.