summaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
* s390/zcrypt: simplify prep of CCA key tokenHarald Freudenberger2023-04-041-23/+12
| | | | | | | | | | | | | | | The preparation of the key data struct for a CCA RSA ME operation had some improvement to skip leading zeros in the key's exponent. However, all supported CCA cards nowadays support leading zeros in key tokens. So for simplifying the CCA key preparing code, this patch simply removes this optimization code. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Juergen Christ <jchrist@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
* s390/zcrypt: remove unused ancient padding codeHarald Freudenberger2023-04-041-64/+8
| | | | | | | | | | | | | | There was some ancient code which padded the results of a clear key ME or CRT operation with some PKCS 1.2 header. According to the comment this was only needed by crypto cards older than the CEX2. These cards are not supported any more and so this patch removes this obscure result padding code. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Juergen Christ <jchrist@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
* Merge branch 'uaccess-inline-asm-cleanup' into featuresVasily Gorbik2023-04-041-0/+21
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Heiko Carstens says: =================== There are a couple of oddities within the s390 uaccess library functions. Therefore cleanup the whole uaccess.c file. There is no functional change, only improved readability. The output of "objdump -Dr" was always compared before/after each patch to make sure that the generated object file is identical, if that could be expected. Therefore the series also includes more patches than really required to cleanup the code. Furthermore the kunit usercopy tests also still pass. =================== Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
| * PCI: s390: Fix use-after-free of PCI resources with per-function hotplugNiklas Schnelle2023-03-131-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On s390 PCI functions may be hotplugged individually even when they belong to a multi-function device. In particular on an SR-IOV device VFs may be removed and later re-added. In commit a50297cf8235 ("s390/pci: separate zbus creation from scanning") it was missed however that struct pci_bus and struct zpci_bus's resource list retained a reference to the PCI functions MMIO resources even though those resources are released and freed on hot-unplug. These stale resources may subsequently be claimed when the PCI function re-appears resulting in use-after-free. One idea of fixing this use-after-free in s390 specific code that was investigated was to simply keep resources around from the moment a PCI function first appeared until the whole virtual PCI bus created for a multi-function device disappears. The problem with this however is that due to the requirement of artificial MMIO addreesses (address cookies) extra logic is then needed to keep the address cookies compatible on re-plug. At the same time the MMIO resources semantically belong to the PCI function so tying their lifecycle to the function seems more logical. Instead a simpler approach is to remove the resources of an individually hot-unplugged PCI function from the PCI bus's resource list while keeping the resources of other PCI functions on the PCI bus untouched. This is done by introducing pci_bus_remove_resource() to remove an individual resource. Similarly the resource also needs to be removed from the struct zpci_bus's resource list. It turns out however, that there is really no need to add the MMIO resources to the struct zpci_bus's resource list at all and instead we can simply use the zpci_bar_struct's resource pointer directly. Fixes: a50297cf8235 ("s390/pci: separate zbus creation from scanning") Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20230306151014.60913-2-schnelle@linux.ibm.com Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
* | s390/vfio-ap: remove redundant driver match functionLizhe2023-03-271-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If there is no driver match function, the driver core assumes that each candidate pair (driver, device) matches, see driver_match_device(). Drop the matrix bus's match function that always returned 1 and so implements the same behaviour as when there is no match function Signed-off-by: Lizhe <sensor1010@163.com> Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com> Link: https://lore.kernel.org/r/20230319041941.259830-1-sensor1010@163.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
* | s390/ap: add ap status asynch error supportHarald Freudenberger2023-03-202-25/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Review and extend the low level AP code to be able to deal with asynchronous reported errors on APQNs. The hypervisor and the SE guest may be confronted with an asynchronously reported error at return of an AP instruction. So all places where AP instructions are called need review and may eventually need extensions. However, not all places need rework. As together with the AP status and the enabled asynch bit there is always a response code set. The asynch error reporting comes with new response codes which may be simple handled in the default case of a switch statement. The idea behind this patch is to report asynch errors as -EPERM (read this as "Operation not permitted") which reflects the fact that only a rapq (with F bit enabled) is a valid AP instruction when an asynch error is flagged. The AP queue state machine functions return AP_SM_WAIT_NONE when a asynch error is detected to reflect the fact, that the state machine can't do anything with such an error as long as the queue is reset. Unfortunately the ap bus scan function needed some update as the ap_queue_info() now needs to return 3 states: 1 if an APQN exists and info is available, -1 if it is assumed an APQN does not exist and the new return value 0 without any info values filled. This 0 returncode is handled as "there is an APQN but we currently don't know any more hw info about this, so please use your previous info and try again later". Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
* | s390/ap: implement SE AP bind, unbind and associateHarald Freudenberger2023-03-202-17/+291
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implementation of the new functions for SE AP support: bind, unbind and associate. There are two new sysfs attributes for this: /sys/devices/ap/cardxx/xx.yyyy/se_bind /sys/devices/ap/cardxx/xx.yyyy/se_associate Writing a 1 into the se_bind attribute triggers the SE AP bind for this AP queue, writing a 0 into does an unbind - that's a reset (RAPQ) with the F bit enabled. The se_associate attribute needs an integer value in range 0...2^16-1 written in. This is the index into a secrets table feed into the ultravisor. For more details please see the Architecture documents. These both new ap queue attributes are only visible inside a SE guest with SB (Secure Binding) available. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
* | s390/ap: introduce low frequency polling possibilityHarald Freudenberger2023-03-203-24/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For some events the ap bus needs to poll. For example when an AP queue is reset until the reset is through. Also when no interrupt support is available (e.g. zVM) there is a need to poll until all requests have been processed and all replies have been delivered. Polling is done with a high resolution timer by default run with a rate of 4kHz (LPAR) or 666Hz (zVM guest). For some events (wait for reset complete, wait for irq enabled complete) this is a much too high poll rate which triggers a lot of TAPQ invocations. This patch introduces the possibility for the state machine functions to return a new wait enum AP_SM_WAIT_LOW_TIMEOUT which gives a hint to the ap_wait() function to eventually set up the timer with a more relaxed timeout value of 25Hz. This patch also includes a slight rework of the sysfs functions parsing the timer related stuff: Use of kstrtobool and kstrtoul instead of sscanf. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
* | s390/ap: provide F bit parameter for ap_rapq() and ap_zapq()Harald Freudenberger2023-03-203-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Extent the ap inline functions ap_rapq() (calls PQAP(RAPQ)) and ap_zapq() (calls PQAP(ZAPQ)) with a new parameter to enable the new architectured F bit which forces an unassociate and/or unbind on a secure execution associated and/or bound queue. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
* | s390/ap: filter ap card functions, new queue functions attributeHarald Freudenberger2023-03-203-4/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With SE SB (Secure Binding) some currently unused and thus always zero bits in the TAPQ GR2 result are now used to show the binding state of a queue. So to check if a card has changed the comparing base is exactly this GR2 value shown as 'ap_function' in sysfs (/sys/devices/ap/cardxx/ap_functions). Now there is some queue specific info in this info and so a new mask TAPQ_CARD_FUNC_CMP_MASK is used to filter out only the relevant bits for card compare. For the same reason now the function bits (including exactly this bind/associate information) need to be exposed to user space now. So tools like lszcrypt can evaluate binding/association state on a queue base. So here comes a new sysfs attribute /sys/devices/ap/cardxx/xx.yyyy/ap_functions This sysfs attribute is similar to the already existing ap_functions attribute at ap card level. It shows the upper 32 bits of GR2 from an invocation of TAPQ for this AP queue. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
* | s390/ap: make tapq gr2 response a structHarald Freudenberger2023-03-202-22/+9
| | | | | | | | | | | | | | | | | | | | | | | | This patch introduces a new struct ap_tapq_gr2 which covers the response in GR2 on TAPQ invocation. This makes it much easier and less error-prone for the calling functions to access the right field without shifting and masking. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
* | s390/ap: introduce new AP bus sysfs attribute featuresHarald Freudenberger2023-03-201-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a new AP bus sysfs attribute /sys/bus/ap/features which shows the features from the QCI information. Currently these feature bits are evaluated: - QCI S bit is shown as 'APSC' - QCI N bit is shown as 'APXA' - QCI C bit is shown as 'QACT' - QCI R bit is shown as 'RC8A' - QCI B bit is shown as 'APSB' Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
* | s390/ap: exploit new B bit from QCI config infoHarald Freudenberger2023-03-203-7/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces an update to the ap_config_info struct which is filled with the QCI subfunction. There is a new bit apsb (short 'B') showing if the AP secure bind facility is available. The patch also includes a simple function ap_sb_available() wrapping this bit test. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
* | s390/zcrypt: replace scnprintf with sysfs_emitHarald Freudenberger2023-03-208-248/+199
| | | | | | | | | | | | | | | | | | | | Replace scnprintf() with sysfs_emit() and friends where possible. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
* | s390/zcrypt: rework length information for dqapHarald Freudenberger2023-03-205-31/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The inline ap_dqap function does not return the number of bytes actually written into the message buffer. The calling code inspects the AP message header to figure out what kind of AP message has been received and pulls the length information from this header. This processing may not work correctly in cases where only a fragment of the reply is received. With this patch the ap_dqap inline function now returns the number of actually written bytes in the *length parameter. So the calling function has a chance to compare the number of received bytes against what the AP message header length field states. This is especially useful in cases where a message could only get partially received. The low level reply processing functions needed some rework to be able to catch this new length information and compare it the right way. The rework also deals with some situations where until now the reply length was not correctly calculated and/or set. All this has been heavily tested as the modifications on the reply length information may affect crypto load. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
* | s390/zcrypt: make psmid unsigned long instead of long longHarald Freudenberger2023-03-205-17/+17
| | | | | | | | | | | | | | | | | | | | | | | | Since s390 kernel build does not support 32 bit build any more there is no difference between long and long long. So this patch reworks all occurrences of psmid (a 64 bit value) to use unsigned long now. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
* | Merge branch 'decompressor-memory-tracking' into featuresHeiko Carstens2023-03-201-4/+4
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Vasily Gorbik says: =================== Combine and generalize all methods for finding unused memory in decompressor, while decreasing complexity, add memory holes support, while improving error handling (especially in low-memory conditions) and debug-ability. =================== Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
| * | s390/boot: rename mem_detect to physmem_infoVasily Gorbik2023-03-201-4/+4
| |/ | | | | | | | | | | | | | | | | | | | | | | In preparation to extending mem_detect with additional information like reserved ranges rename it to more generic physmem_info. This new naming also help to avoid confusion by using more exact terms like "physmem online ranges", etc. Acked-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
* / s390/zcrypt: remove unnecessary (void *) conversionsYu Zhe2023-03-131-7/+5
|/ | | | | | | | | | Pointer variables of void * type do not require type cast. Signed-off-by: Yu Zhe <yuzhe@nfschina.com> Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Link: https://lore.kernel.org/r/20230303052155.21072-1-yuzhe@nfschina.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
* tpm: disable hwrng for fTPM on some AMD designsMario Limonciello2023-03-122-1/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AMD has issued an advisory indicating that having fTPM enabled in BIOS can cause "stuttering" in the OS. This issue has been fixed in newer versions of the fTPM firmware, but it's up to system designers to decide whether to distribute it. This issue has existed for a while, but is more prevalent starting with kernel 6.1 because commit b006c439d58db ("hwrng: core - start hwrng kthread also for untrusted sources") started to use the fTPM for hwrng by default. However, all uses of /dev/hwrng result in unacceptable stuttering. So, simply disable registration of the defective hwrng when detecting these faulty fTPM versions. As this is caused by faulty firmware, it is plausible that such a problem could also be reproduced by other TPM interactions, but this hasn't been shown by any user's testing or reports. It is hypothesized to be triggered more frequently by the use of the RNG because userspace software will fetch random numbers regularly. Intentionally continue to register other TPM functionality so that users that rely upon PCR measurements or any storage of data will still have access to it. If it's found later that another TPM functionality is exacerbating this problem a module parameter it can be turned off entirely and a module parameter can be introduced to allow users who rely upon fTPM functionality to turn it on even though this problem is present. Link: https://www.amd.com/en/support/kb/faq/pa-410 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216989 Link: https://lore.kernel.org/all/20230209153120.261904-1-Jason@zx2c4.com/ Fixes: b006c439d58d ("hwrng: core - start hwrng kthread also for untrusted sources") Cc: stable@vger.kernel.org Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Thorsten Leemhuis <regressions@leemhuis.info> Cc: James Bottomley <James.Bottomley@hansenpartnership.com> Tested-by: reach622@mailcuk.com Tested-by: Bell <1138267643@qq.com> Co-developed-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
* tpm/eventlog: Don't abort tpm_read_log on faulty ACPI addressMorten Linderud2023-03-121-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tpm_read_log_acpi() should return -ENODEV when no eventlog from the ACPI table is found. If the firmware vendor includes an invalid log address we are unable to map from the ACPI memory and tpm_read_log() returns -EIO which would abort discovery of the eventlog. Change the return value from -EIO to -ENODEV when acpi_os_map_iomem() fails to map the event log. The following hardware was used to test this issue: Framework Laptop (Pre-production) BIOS: INSYDE Corp, Revision: 3.2 TPM Device: NTC, Firmware Revision: 7.2 Dump of the faulty ACPI TPM2 table: [000h 0000 4] Signature : "TPM2" [Trusted Platform Module hardware interface Table] [004h 0004 4] Table Length : 0000004C [008h 0008 1] Revision : 04 [009h 0009 1] Checksum : 2B [00Ah 0010 6] Oem ID : "INSYDE" [010h 0016 8] Oem Table ID : "TGL-ULT" [018h 0024 4] Oem Revision : 00000002 [01Ch 0028 4] Asl Compiler ID : "ACPI" [020h 0032 4] Asl Compiler Revision : 00040000 [024h 0036 2] Platform Class : 0000 [026h 0038 2] Reserved : 0000 [028h 0040 8] Control Address : 0000000000000000 [030h 0048 4] Start Method : 06 [Memory Mapped I/O] [034h 0052 12] Method Parameters : 00 00 00 00 00 00 00 00 00 00 00 00 [040h 0064 4] Minimum Log Length : 00010000 [044h 0068 8] Log Address : 000000004053D000 Fixes: 0cf577a03f21 ("tpm: Fix handling of missing event log") Tested-by: Erkki Eilonen <erkki@bearmetal.eu> Signed-off-by: Morten Linderud <morten@linderud.pw> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
* Merge tag 'staging-6.3-rc2' of ↵Linus Torvalds2023-03-12105-51301/+39
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging driver fixes and removal from Greg KH: "Here are four small staging driver fixes, and one big staging driver deletion for 6.3-rc2. The fixes are: - rtl8192e driver fixes for where the driver was attempting to execute various programs directly from the disk for unknown reasons - rtl8723bs driver fixes for issues found by Hans in testing The deleted driver is the removal of the r8188eu wireless driver as now in 6.3-rc1 we have a "real" wifi driver for one that includes support for many many more devices than this old driver did. So it's time to remove it as it is no longer needed. The maintainers of this driver all have acked its removal. Many thanks to them over the years for working to clean it up and keep it working while the real driver was being developed. All of these have been in linux-next this week with no reported problems" * tag 'staging-6.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging: r8188eu: delete driver staging: rtl8723bs: Pass correct parameters to cfg80211_get_bss() staging: rtl8723bs: Fix key-store index handling staging: rtl8192e: Remove call_usermodehelper starting RadioPower.sh staging: rtl8192e: Remove function ..dm_check_ac_dc_power calling a script
| * staging: r8188eu: delete driverGreg Kroah-Hartman2023-03-09101-51232/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that the same hardware that the r8188eu driver supported is supported by the real wireless driver rtl8xxxu, the r8188eu driver can be deleted. Also the rtl8xxxu driver supports way more devices, and is a fraction of the overall size, making this a much better overall solution. Thanks to the r8188eu developers and maintainers and reviewers over the years, your work allowed Linux users to use their hardware before the real driver was implemented properly. Reported-by: Hans de Goede <hdegoede@redhat.com> Cc: Phillip Potter <phil@philpotter.co.uk> Cc: Pavel Skripkin <paskripkin@gmail.com> Acked-by: Larry Finger <LarryFinger@lwfinger.net> Acked-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Martin Kaiser <martin@kaiser.cx> Tested-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> # Edimax N150 Acked-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20230308131934.380395-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * staging: rtl8723bs: Pass correct parameters to cfg80211_get_bss()Hans de Goede2023-03-081-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To last 2 parameters to cfg80211_get_bss() should be of the enum ieee80211_bss_type resp. enum ieee80211_privacy types, which WLAN_CAPABILITY_ESS very much is not. Fix both cfg80211_get_bss() calls in ioctl_cfg80211.c to pass the right parameters. Note that the second call was already somewhat fixed by commenting out WLAN_CAPABILITY_ESS and passing in 0 instead. This was still not entirely correct though since that would limit returned BSS-es to ESS type BSS-es with privacy on. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230306153512.162104-2-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * staging: rtl8723bs: Fix key-store index handlingHans de Goede2023-03-083-31/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are 2 issues with the key-store index handling 1. The non WEP key stores can store keys with indexes 0 - BIP_MAX_KEYID, this means that they should be an array with BIP_MAX_KEYID + 1 entries. But some of the arrays where just BIP_MAX_KEYID entries big. While one other array was hardcoded to a size of 6 entries, instead of using the BIP_MAX_KEYID define. 2. The rtw_cfg80211_set_encryption() and wpa_set_encryption() functions index check where checking that the passed in key-index would fit inside both the WEP key store (which only has 4 entries) as well as in the non WEP key stores. This breaks any attempts to set non WEP keys with index 4 or 5. Issue 2. specifically breaks wifi connection with some access points which advertise PMF support. Without this fix connecting to these access points fails with the following wpa_supplicant messages: nl80211: kernel reports: key addition failed wlan0: WPA: Failed to configure IGTK to the driver wlan0: RSN: Failed to configure IGTK wlan0: CTRL-EVENT-DISCONNECTED bssid=... reason=1 locally_generated=1 Fix 1. by using the right size for the key-stores. After this 2. can safely be fixed by checking the right max-index value depending on the used algorithm, fixing wifi not working with some PMF capable APs. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230306153512.162104-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * staging: rtl8192e: Remove call_usermodehelper starting RadioPower.shPhilipp Hortmann2023-03-081-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | Remove call_usermodehelper starting /etc/acpi/events/RadioPower.sh that is not available. This script is not part of the kernel and it is not officially available on the www. The result is that this lines are just dead code. Signed-off-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20230301215441.GA14049@matrix-ESPRIMO-P710 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * staging: rtl8192e: Remove function ..dm_check_ac_dc_power calling a scriptPhilipp Hortmann2023-03-081-23/+0
| | | | | | | | | | | | | | | | | | | | | | | | Remove function _rtl92e_dm_check_ac_dc_power calling a script /etc/acpi/wireless-rtl-ac-dc-power.sh that is not available. This script is not part of the kernel and it is not available on the www. The result is that this function is just dead code. Signed-off-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20230228202857.GA16442@matrix-ESPRIMO-P710 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | Merge tag 'i2c-for-6.3-rc2' of ↵Linus Torvalds2023-03-1114-40/+41
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c updates from Wolfram Sang: "This marks the end of a transition to let I2C have the same probe semantics as other subsystems. Uwe took care that no drivers in the current tree nor in -next use the deprecated .probe call. So, it is a good time to switch to the new, standard semantics now. There is also a regression fix: - regression fix for the notifier handling of the I2C core - final coversions of drivers away from deprecated .probe - make .probe_new the standard probe and convert I2C core to use it * tag 'i2c-for-6.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: dev: Fix bus callback return values i2c: Convert drivers to new .probe() callback i2c: mux: Convert all drivers to new .probe() callback i2c: Switch .probe() to not take an id parameter media: i2c: ov2685: convert to i2c's .probe_new() media: i2c: ov5695: convert to i2c's .probe_new() w1: ds2482: Convert to i2c's .probe_new() serial: sc16is7xx: Convert to i2c's .probe_new() mtd: maps: pismo: Convert to i2c's .probe_new() misc: ad525x_dpot-i2c: Convert to i2c's .probe_new()
| * | i2c: dev: Fix bus callback return valuesGeert Uytterhoeven2023-03-091-6/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The i2cdev_{at,de}tach_adapter() callbacks are used for two purposes: 1. As notifier callbacks, when (un)registering I2C adapters created or destroyed after i2c_dev_init(), 2. As bus iterator callbacks, for registering already existing adapters from i2c_dev_init(), and for cleanup. Unfortunately both use cases expect different return values: the former expects NOTIFY_* return codes, while the latter expects zero or error codes, and aborts in case of error. Hence in case 2, as soon as i2cdev_{at,de}tach_adapter() returns (non-zero) NOTIFY_OK, the bus iterator aborts. This causes (a) only the first already existing adapter to be registered, leading to missing /dev/i2c-* entries, and (b) a failure to unregister all but the first I2C adapter during cleanup. Fix this by introducing separate callbacks for the bus iterator, wrapping the notifier functions, and always returning succes. Any errors inside these callback functions are unlikely to happen, and are fatal anyway. Fixes: cddf70d0bce71c2a ("i2c: dev: fix notifier return values") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
| * | i2c: Convert drivers to new .probe() callbackUwe Kleine-König2023-03-094-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that .probe() was changed not to get the id parameter, drivers can be converted back to that with the eventual goal to drop .probe_new(). Implement that for the i2c drivers that are part of the i2c core. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
| * | i2c: mux: Convert all drivers to new .probe() callbackUwe Kleine-König2023-03-093-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that .probe() was changed not to get the id parameter, drivers can be converted back to that with the eventual goal to drop .probe_new(). Implement that for the i2c mux drivers. Acked-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Peter Rosin <peda@axentia.se> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
| * | i2c: Switch .probe() to not take an id parameterUwe Kleine-König2023-03-091-9/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type") introduced a new probe callback to convert i2c init routines to not take an i2c_device_id parameter. Now that all in-tree drivers are converted to the temporary .probe_new() callback, .probe() can be modified to match the desired prototype. Now that .probe() and .probe_new() have the same semantic, they can be defined as members of an anonymous union to save some memory and simplify the core code a bit. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
| * | media: i2c: ov2685: convert to i2c's .probe_new()Uwe Kleine-König2023-03-091-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Link: https://lore.kernel.org/lkml/20221121102838.16448-1-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
| * | media: i2c: ov5695: convert to i2c's .probe_new()Uwe Kleine-König2023-03-091-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Link: https://lore.kernel.org/lkml/20221121102705.16092-1-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
| * | w1: ds2482: Convert to i2c's .probe_new()Uwe Kleine-König2023-03-091-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Link: https://lore.kernel.org/lkml/20221118224540.619276-596-uwe@kleine-koenig.org Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
| * | serial: sc16is7xx: Convert to i2c's .probe_new()Uwe Kleine-König2023-03-091-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | .probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/lkml/20221118224540.619276-572-uwe@kleine-koenig.org Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
| * | mtd: maps: pismo: Convert to i2c's .probe_new()Uwe Kleine-König2023-03-091-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Acked-by: Richard Weinberger <richard@nod.at> Link: https://lore.kernel.org/lkml/20221118224540.619276-497-uwe@kleine-koenig.org Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
| * | misc: ad525x_dpot-i2c: Convert to i2c's .probe_new()Uwe Kleine-König2023-03-091-3/+3
| |/ | | | | | | | | | | | | | | | | | | .probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/lkml/20221118224540.619276-483-uwe@kleine-koenig.org Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
* | ubi: block: Fix missing blk_mq_end_requestRichard Weinberger2023-03-111-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Switching to BLK_MQ_F_BLOCKING wrongly removed the call to blk_mq_end_request(). Add it back to have our IOs finished Fixes: 91cc8fbcc8c7 ("ubi: block: set BLK_MQ_F_BLOCKING") Analyzed-by: Linus Torvalds <torvalds@linux-foundation.org> Reported-by: Daniel Palmer <daniel@0x0f.com> Link: https://lore.kernel.org/linux-mtd/CAHk-=wi29bbBNh3RqJKu3PxzpjDN5D5K17gEVtXrb7-6bfrnMQ@mail.gmail.com/ Signed-off-by: Richard Weinberger <richard@nod.at> Reviewed-by: Christoph Hellwig <hch@lst.de> Tested-by: Daniel Palmer <daniel@0x0f.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | Merge tag 'scsi-fixes' of ↵Linus Torvalds2023-03-1020-50/+117
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Twenty fixes all in drivers except the one zone storage revalidation fix to sd. The megaraid_sas fixes are more on the level of a driver update (enabling crash dump and increasing lun number) but I thought you could let this slide on -rc1 and the next most extensive update is a load of fixes to mpi3mr" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: sd: Fix wrong zone_write_granularity value during revalidate scsi: storvsc: Handle BlockSize change in Hyper-V VHD/VHDX file scsi: megaraid_sas: Driver version update to 07.725.01.00-rc1 scsi: megaraid_sas: Add crash dump mode capability bit in MFI capabilities scsi: megaraid_sas: Update max supported LD IDs to 240 scsi: mpi3mr: Bad drive in topology results kernel crash scsi: mpi3mr: NVMe command size greater than 8K fails scsi: mpi3mr: Return proper values for failures in firmware init path scsi: mpi3mr: Wait for diagnostic save during controller init scsi: mpi3mr: Driver unload crashes host when enhanced logging is enabled scsi: mpi3mr: ioctl timeout when disabling/enabling interrupt scsi: lpfc: Avoid usage of list iterator variable after loop scsi: lpfc: Check kzalloc() in lpfc_sli4_cgn_params_read() scsi: ufs: mcq: qcom: Clean the return path of ufs_qcom_mcq_config_resource() scsi: ufs: mcq: qcom: Fix passing zero to PTR_ERR scsi: ufs: ufs-qcom: Remove impossible check scsi: ufs: core: Add soft dependency on governor_simpleondemand scsi: hisi_sas: Check devm_add_action() return value scsi: qla2xxx: Add option to disable FC2 Target support scsi: target: iscsi: Fix an error message in iscsi_check_key()
| * | scsi: sd: Fix wrong zone_write_granularity value during revalidateShin'ichiro Kawasaki2023-03-062-9/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the sd driver revalidates host-managed SMR disks, it calls disk_set_zoned() which changes the zone_write_granularity attribute value to the logical block size regardless of the device type. After that, the sd driver overwrites the value in sd_zbc_read_zone() with the physical block size, since ZBC/ZAC requires this for host-managed disks. Between the calls to disk_set_zoned() and sd_zbc_read_zone(), there exists a window where the attribute shows the logical block size as the zone_write_granularity value, which is wrong for host-managed disks. The duration of the window is from 20ms to 200ms, depending on report zone command execution time. To avoid the wrong zone_write_granularity value between disk_set_zoned() and sd_zbc_read_zone(), modify the value not in sd_zbc_read_zone() but just after disk_set_zoned() call. Fixes: a805a4fa4fa3 ("block: introduce zone_write_granularity limit") Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com> Link: https://lore.kernel.org/r/20230306063024.3376959-1-shinichiro.kawasaki@wdc.com Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
| * | scsi: storvsc: Handle BlockSize change in Hyper-V VHD/VHDX fileMichael Kelley2023-03-061-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hyper-V uses a VHD or VHDX file on the host as the underlying storage for a virtual disk. The VHD/VHDX file format is a sparse format where real disk space on the host is assigned in chunks that the VHD/VHDX file format calls the BlockSize. This BlockSize is not to be confused with the 512-byte (or 4096-byte) sector size of the underlying storage device. The default block size for a new VHD/VHDX file is 32 Mbytes. When a guest VM touches any disk space within a 32 Mbyte chunk of the VHD/VHDX file, Hyper-V allocates 32 Mbytes of real disk space for that section of the VHD/VHDX. Similarly, if a discard operation is done that covers an entire 32 Mbyte chunk, Hyper-V will free the real disk space for that portion of the VHD/VHDX. This BlockSize is surfaced in Linux as the "discard_granularity" in /sys/block/sd<x>/queue, which makes sense. Hyper-V also has differencing disks that can overlay a VHD/VHDX file to capture changes to the VHD/VHDX while preserving the original VHD/VHDX. One example of this differencing functionality is for VM snapshots. When a snapshot is created, a differencing disk is created. If the snapshot is rolled back, Hyper-V can just delete the differencing disk, and the VM will see the original disk contents at the time the snapshot was taken. Differencing disks are used in other scenarios as well. The BlockSize for a differencing disk defaults to 2 Mbytes, not 32 Mbytes. The smaller default is used because changes to differencing disks are typically scattered all over, and Hyper-V doesn't want to allocate 32 Mbytes of real disk space for a stray write here or there. The smaller BlockSize provides more efficient use of real disk space. When a differencing disk is added to a VHD/VHDX, Hyper-V reports UNIT_ATTENTION with a sense code indicating "Operating parameters have changed", because the value of discard_granularity should be changed to 2 Mbytes. When the differencing disk is removed, discard_granularity should be changed back to 32 Mbytes. However, current code simply reports a message from scsi_report_sense() and the value of /sys/block/sd<x>/queue/discard_granularity is not updated. The message isn't very actionable by a sysadmin. Fix this by having the storvsc driver check for the sense code indicating that the underly VHD/VHDX block size has changed, and do a rescan of the device to pick up the new discard_granularity. With this change the entire transition to/from differencing disks is handled automatically and transparently, with no confusing messages being output. Link: https://lore.kernel.org/r/1677516514-86060-1-git-send-email-mikelley@microsoft.com Signed-off-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
| * | scsi: megaraid_sas: Driver version update to 07.725.01.00-rc1Chandrakanth Patil2023-03-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Update driver version. Signed-off-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com> Link: https://lore.kernel.org/r/20230302105342.34933-4-chandrakanth.patil@broadcom.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
| * | scsi: megaraid_sas: Add crash dump mode capability bit in MFI capabilitiesChandrakanth Patil2023-03-062-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In kdump kernel mode, the driver works in reduced functionality mode with some features disabled such as reduced MSI-X count and RDPQ disabled, etc. However, the firmware is not aware of this mode in some cases, which results in undefined behavior. To address this, the driver informs the firmware about the kdump mode through MPI capabilities bit during driver initialization. This allows firmware to adjust its behavior accordingly. Signed-off-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com> Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com> Link: https://lore.kernel.org/r/20230302105342.34933-3-chandrakanth.patil@broadcom.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
| * | scsi: megaraid_sas: Update max supported LD IDs to 240Chandrakanth Patil2023-03-062-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The firmware only supports Logical Disk IDs up to 240 and LD ID 255 (0xFF) is reserved for deleted LDs. However, in some cases, firmware was assigning LD ID 254 (0xFE) to deleted LDs and this was causing the driver to mark the wrong disk as deleted. This in turn caused the wrong disk device to be taken offline by the SCSI midlayer. To address this issue, limit the LD ID range from 255 to 240. This ensures the deleted LD ID is properly identified and removed by the driver without accidently deleting any valid LDs. Fixes: ae6874ba4b43 ("scsi: megaraid_sas: Early detection of VD deletion through RaidMap update") Reported-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com> Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com> Link: https://lore.kernel.org/r/20230302105342.34933-2-chandrakanth.patil@broadcom.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
| * | scsi: mpi3mr: Bad drive in topology results kernel crashRanjan Kumar2023-03-061-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the SAS Transport Layer support is enabled and a device exposed to the OS by the driver fails INQUIRY commands, the driver frees up the memory allocated for an internal HBA port data structure. However, in some places, the reference to the freed memory is not cleared. When the firmware sends the Device Info change event for the same device again, the freed memory is accessed and that leads to memory corruption and OS crash. Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com> Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Link: https://lore.kernel.org/r/20230228140835.4075-7-ranjan.kumar@broadcom.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
| * | scsi: mpi3mr: NVMe command size greater than 8K failsRanjan Kumar2023-03-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A wrong variable is checked while populating PRP entries in the PRP page and this results in failure. No PRP entries in the PRP page were successfully created and any NVMe Encapsulated commands with PRP of size greater than 8K failed. Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com> Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Link: https://lore.kernel.org/r/20230228140835.4075-6-ranjan.kumar@broadcom.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
| * | scsi: mpi3mr: Return proper values for failures in firmware init pathRanjan Kumar2023-03-061-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Return proper non-zero return values for all the cases when the controller initialization and re-initialization fails. Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com> Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Link: https://lore.kernel.org/r/20230228140835.4075-5-ranjan.kumar@broadcom.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
| * | scsi: mpi3mr: Wait for diagnostic save during controller initRanjan Kumar2023-03-061-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a controller reset operation is triggered to recover the controller from a fault state, then wait for the snapdump to be saved in the firmware region before proceeding to reset the controller. Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com> Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Link: https://lore.kernel.org/r/20230228140835.4075-4-ranjan.kumar@broadcom.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
| * | scsi: mpi3mr: Driver unload crashes host when enhanced logging is enabledRanjan Kumar2023-03-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prevent driver from trying to dereference a NULL pointer in a debug print while removing a device during driver unload. Signed-off-by: Ranjan Kumar <ranjan.kumar@broadcom.com> Signed-off-by: Sreekanth Reddy <sreekanth.reddy@broadcom.com> Link: https://lore.kernel.org/r/20230228140835.4075-3-ranjan.kumar@broadcom.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>