- 10 Oct, 2023 6 commits
-
-
Andy Shevchenko authored
The acpi_evaluate_dsm_typed() provides a way to check the type of the object evaluated by _DSM call. Use it instead of open coded variant. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20231002135125.2602895-1-andriy.shevchenko@linux.intel.comReviewed-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Peter Wang authored
If a dev command times out, clk_scaling.active_reqs is not decreased which causes abnormal clock scaling. It is complicated to handle different dev command timeout cases in both legacy mode and MCQ mode. Besides, dev cmds are rarely used and the busy time is short. Remove clock scaling busy window for dev cmds like we do for UIC or TM cmds which don't update busy window either. Signed-off-by:
Peter Wang <peter.wang@mediatek.com> Link: https://lore.kernel.org/r/20231004062454.29165-1-peter.wang@mediatek.comReviewed-by:
Stanley Chu <stanley.chu@mediatek.com> Signed-off-by:
-
Justin Stitt authored
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. The only caller of mptsas_exp_repmanufacture_info() is mptsas_probe_one_phy() which can allocate rphy in either sas_end_device_alloc() or sas_expander_alloc(). Both of which zero-allocate: | rdev = kzalloc(sizeof(*rdev), GFP_KERNEL); ... this is supplied to mptsas_exp_repmanufacture_info() as edev meaning that no future NUL-padding of edev members is needed. Considering the above, a suitable replacement is strscpy() [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. Also use the more idiomatic strscpy() pattern of (dest, src, sizeof(dest)). Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Cc: Kees Cook <keescook@chromium.org> Signed-off-by:
Justin Stitt <justinstitt@google.com> Link: https://lore.kernel.org/r/20231003-strncpy-drivers-message-fusion-mptsas-c-v2-1-5ce07e60bd21@google.comReviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Justin Stitt authored
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. Since all these structs are copied out to userspace let's keep them NUL-padded by using strscpy_pad() which guarantees NUL-termination of the destination buffer while also providing the NUL-padding behavior that strncpy() has. Let's also opt to use the more idiomatic strscpy() usage of: 'dest, src, sizeof(dest)' in cases where the compiler can determine the size of the destination buffer. Do this for all cases of strscpy...() in this file. To be abundantly sure we don't leak stack data out to user space let's also change a strscpy() to strscpy_pad(). This strscpy() was introduced in commit dbe37c71 ("scsi: message: fusion: Replace all non-returning strlcpy() with strscpy()") Note that since we are creating these structs with a copy_from_user() and modifying fields and then copying back out to the user it is probably OK not to explicitly NUL-pad everything as any data leak is probably just data from the user themselves. If this is too eager, let's opt for strscpy() which is still in the spirit of removing deprecated strncpy() usage treewide. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Cc: Kees Cook <keescook@chromium.org> Signed-off-by:
-
Peter Wang authored
When runtime PM send SSU times out, the SCSI core invokes eh_host_reset_handler, in this case ufshcd_eh_host_reset_handler(), which is then stuck waiting for flush_work(&hba->eh_work). However, ufshcd_err_handler hangs in wait RPM resume. Do link recovery only in this case. The following IO hang stack dump was observed: kworker/4:0 D <ffffffd7d31f6fb4> __switch_to+0x180/0x344 <ffffffd7d31f779c> __schedule+0x5ec/0xa14 <ffffffd7d31f7c3c> schedule+0x78/0xe0 <ffffffd7d31fefbc> schedule_timeout+0xb0/0x15c <ffffffd7d31f8120> io_schedule_timeout+0x48/0x70 <ffffffd7d31f8e40> do_wait_for_common+0x108/0x19c <ffffffd7d31f837c> wait_for_completion_io_timeout+0x50/0x78 <ffffffd7d2876bc0> blk_execute_rq+0x1b8/0x218 <ffffffd7d2b4297c> scsi_execute_cmd+0x148/0x238 <ffffffd7d2da7358> ufshcd_set_dev_pwr_mode+0xe8/0x244 <ffffffd7d2da7e40> __ufshcd_wl_resume+0x1e0/0x45c <ffffffd7d2da7b28> ufshcd_wl_runtime_resume+0x3c/0x174 <ffffffd7d2b4f290> scsi_runtime_resume+0x7c/0xc8 <ffffffd7d2ae1d48> __rpm_callback+0xa0/0x410 <ffffffd7d2ae0128> rpm_resume+0x43c/0x67c <ffffffd7d2ae1e98> __rpm_callback+0x1f0/0x410 <ffffffd7d2ae014c> rpm_resume+0x460/0x67c <ffffffd7d2ae1450> pm_runtime_work+0xa4/0xac <ffffffd7d22e39ac> process_one_work+0x208/0x598 <ffffffd7d22e3fc0> worker_thread+0x228/0x438 <ffffffd7d22eb038> kthread+0x104/0x1d4 <ffffffd7d22171a0> ret_from_fork+0x10/0x20 scsi_eh_0 D <ffffffd7d31f6fb4> __switch_to+0x180/0x344 <ffffffd7d31f779c> __schedule+0x5ec/0xa14 <ffffffd7d31f7c3c> schedule+0x78/0xe0 <ffffffd7d31fef50> schedule_timeout+0x44/0x15c <ffffffd7d31f8e40> do_wait_for_common+0x108/0x19c <ffffffd7d31f8234> wait_for_completion+0x48/0x64 <ffffffd7d22deb88> __flush_work+0x260/0x2d0 <ffffffd7d22de918> flush_work+0x10/0x20 <ffffffd7d2da4728> ufshcd_eh_host_reset_handler+0x88/0xcc <ffffffd7d2b41da4> scsi_try_host_reset+0x48/0xe0 <ffffffd7d2b410fc> scsi_eh_ready_devs+0x934/0xa40 <ffffffd7d2b41618> scsi_error_handler+0x168/0x374 <ffffffd7d22eb038> kthread+0x104/0x1d4 <ffffffd7d22171a0> ret_from_fork+0x10/0x20 kworker/u16:5 D <ffffffd7d31f6fb4> __switch_to+0x180/0x344 <ffffffd7d31f779c> __schedule+0x5ec/0xa14 <ffffffd7d31f7c3c> schedule+0x78/0xe0 <ffffffd7d2adfe00> rpm_resume+0x114/0x67c <ffffffd7d2adfca8> __pm_runtime_resume+0x70/0xb4 <ffffffd7d2d9cf48> ufshcd_err_handler+0x1a0/0xe68 <ffffffd7d22e39ac> process_one_work+0x208/0x598 <ffffffd7d22e3fc0> worker_thread+0x228/0x438 <ffffffd7d22eb038> kthread+0x104/0x1d4 <ffffffd7d22171a0> ret_from_fork+0x10/0x20 Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
-
Martin K. Petersen authored
Tyrel Datwyler <tyreld@linux.ibm.com> says: This series includes a couple minor fixes, generalization of some code that is not protocol specific, and a reworking of the way event pool buffers are accounted for by the driver. This is a precursor to a series to follow that introduces support for NVMeoF protocol with ibmvfc. Link: https://lore.kernel.org/r/20230921225435.3537728-1-tyreld@linux.ibm.comSigned-off-by:
-
- 27 Sep, 2023 8 commits
-
-
Jiapeng Chong authored
No functional modification involved. drivers/scsi/fnic/fnic_fcs.c:152 fnic_handle_link() warn: inconsistent indenting. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=6678Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Link: https://lore.kernel.org/r/20230922100657.14566-1-jiapeng.chong@linux.alibaba.comSigned-off-by:
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct tcmu_tmr. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Bodo Stroesser <bostroesser@gmail.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Cc: target-devel@vger.kernel.org Signed-off-by:
"Gustavo A. R. Silva" <gustavoars@kernel.org> Reviewed-by:
Bodo Stroesser <bostroesser@gmail.com> Signed-off-by:
-
Martin K. Petersen authored
Bart Van Assche <bvanassche@acm.org> says: Hi Martin, Please consider these UFS core patches for the next merge window. Thanks, Bart. Link: https://lore.kernel.org/r/20230921192335.676924-1-bvanassche@acm.orgSigned-off-by:
-
Bart Van Assche authored
Make the UFS device execute realtime (RT) requests before other requests. This will be used in Android to reduce the I/O latency of the foreground app. Note: UFS devices do not support CDL so using CDL is not a viable alternative. Signed-off-by:
-
Bart Van Assche authored
ufshcd_comp_scsi_upiu() has one caller and that caller ensures that lrbp->cmd != NULL. Hence leave out the lrbp->cmd check from ufshcd_comp_scsi_upiu(). Signed-off-by:
-
Bart Van Assche authored
The DMA alignment for the Exynos controller follows directly from the PRDT segment size configured in ufs-exynos.c. Hence, move the DMA alignment code into the Exynos driver source code. Cc: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by:
Alim Akhtar <alim.akhtar@samsung.com> Tested-by:
-
Bart Van Assche authored
The block layer core guarantees that tag numbers are in the expected range. Hence remove the statements that check this. This patch suppresses Coverity warnings about left shifts with a negative right hand operand. The following commit originally introduced request tag range checks: 14497328 ("scsi: ufs: verify command tag validity"). Cc: daejun7.park@samsung.com Cc: John Garry <john.g.garry@oracle.com> Signed-off-by:
John Garry <john.g.garry@oracle.com> Signed-off-by:
-
http://www.linux-iscsi.org/Bart Van Assche authored
The website http://www.linux-iscsi.org/ disappeared more than a year ago. DNS records have been removed for linux-iscsi.org. The company that sponsored this website (Datera; formerly called Rising Tide) has been liquidated in early 2021 according to https://blocksandfiles.com/2021/03/19/datera-is-being-liquidated/. Since it is unlikely that the website http://www.linux-iscsi.org/ will be restored, remove the references to that website. Reviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
-
- 22 Sep, 2023 25 commits
-
-
Tyrel Datwyler authored
Add a per target protocol field so target code can determine correct protocol specific actions as well as identify the correct channel group target list. Signed-off-by:
Tyrel Datwyler <tyreld@linux.ibm.com> Link: https://lore.kernel.org/r/20230921225435.3537728-12-tyreld@linux.ibm.comReviewed-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
-
Tyrel Datwyler authored
The target discovery buffer that the VIOS populates with targets is currently a host adapter field. To facilitate the discovery of NVMe targets as well as SCSI another discovery buffer is required. Move the discovery buffer out of the host struct and into the ibmvfc_channels struct so that each channels instance for a given protocol has its own discovery buffer. Signed-off-by:
-
Tyrel Datwyler authored
There are cases in the generic code where protocol specific configuration or actions may need to be taken. Add a protocol field to struct ibmvfc_channels and initial IBMVFC_PROTO_[SCSI/NVME] definitions. Signed-off-by:
-
Tyrel Datwyler authored
With the coming of NVMeoF support the driver will need to also allocate channels for NVMe. Implement generic channel allocation wrappers that can be used for both SCSI and NVMeoF protocol setup. Signed-off-by:
-
Tyrel Datwyler authored
Add fields for desired and max number of queues to ibmvfc_channels. With support for NVMeoF protocol coming these sorts of values should be tracked in the protocol specific channel struct instead of the overarching host adapter. Signed-off-by:
-
Tyrel Datwyler authored
There is nothing scsi specific about the ibmvfc_scsi_channels struct. It is meant to encapsulate a set of channels regardless of protocol. Remove _scsi from the struct name to reflect this genric nature. Signed-off-by:
-
Tyrel Datwyler authored
There are currently 9 binary flag fields in the ibmvfc host structure. Converting each of these to a single bitfield reduces the foot print of the structure by 32 bytes. Signed-off-by:
-
Tyrel Datwyler authored
Commit 0217a272 ("scsi: ibmvfc: Store return code of H_FREE_SUB_CRQ during cleanup") wrongly changed the busy loop check to use rtas_busy_delay() instead of H_BUSY and H_IS_LONG_BUSY(). The busy return codes for RTAS and hypercalls are not the same. Fix this issue by restoring the use of H_BUSY and H_IS_LONG_BUSY(). Fixes: 0217a272 ("scsi: ibmvfc: Store return code of H_FREE_SUB_CRQ during cleanup") Signed-off-by:
-
Tyrel Datwyler authored
An LPAR could potentially be configured with a small logical cpu count that is less then the default hardware queue max. Ensure that we don't allocate more hw queues than available cpus. Signed-off-by:
-
Tyrel Datwyler authored
Extend ibmvfc_queue, ibmvfc_event, and ibmvfc_event_pool to provide queue depths for general I/O commands and reserved commands as well as proper accounting of the free events of each type from the general event pool. Further, calculate the negotiated max command limit with the VIOS at NPIV login time as a function of the number of queues times their total queue depth (general and reserved depths combined). This does away with the legacy max_request value, and allows the driver to better manage and track it resources. Signed-off-by:
-
Tyrel Datwyler authored
In practice the driver should never send more commands than are allocated to a queue's event pool. In the unlikely event that this happens, the code asserts a BUG_ON, and in the case that the kernel is not configured to crash on panic returns a junk event pointer from the empty event list causing things to spiral from there. This BUG_ON is a historical artifact of the ibmvfc driver first being upstreamed, and it is well known now that the use of BUG_ON is bad practice except in the most unrecoverable scenario. There is nothing about this scenario that prevents the driver from recovering and carrying on. Remove the BUG_ON in question from ibmvfc_get_event() and return a NULL pointer in the case of an empty event pool. Update all call sites to ibmvfc_get_event() to check for a NULL pointer and perfrom the appropriate failure or recovery action. Signed-off-by:
-
Yihang Li authored
Currently, if CONFIG_SCSI_HISI_SAS_DEBUGFS_DEFAULT_ENABLE is enabled, the memory space used by DFX is allocated during device initialization, which occupies a large number of memory resources. The memory usage before and after the driver is loaded is as follows: Memory usage before the driver is loaded: $ free -m total used free shared buff/cache available Mem: 867352 2578 864037 11 735 861681 Swap: 4095 0 4095 Memory usage after the driver which include 4 HBAs is loaded: $ insmod hisi_sas_v3_hw.ko $ free -m total used free shared buff/cache available Mem: 867352 4760 861848 11 743 859495 Swap: 4095 0 4095 The driver with 4 HBAs connected will allocate about 110 MB of memory without enabling debugfs. Therefore, to avoid wasting memory resources, DFX memory is allocated during dump triggering. The dump may fail due to memory allocation failure. After this change, each dump costs about 10 MB of memory, and each dump lasts about 100 ms. Signed-off-by:Yihang Li <liyihang9@huawei.com> Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Link: https://lore.kernel.org/r/1694571327-78697-4-git-send-email-chenxiang66@hisilicon.comSigned-off-by:
-
Yihang Li authored
Currently, register information dump is performed via workqueue, regardless of the trigger mode (automatic or manual). There is a delay in dumping register through workqueue, the exact register information at trigger time cannot be obtained. Call register snapshot directly instead of through a workqueue. Signed-off-by:
-
Yihang Li authored
If init debugfs failed during device registration due to memory allocation failure, debugfs_remove_recursive() is called, after which debugfs_dir is not set to NULL. debugfs_remove_recursive() will be called again during device removal. As a result, illegal pointer is accessed. [ 1665.467244] hisi_sas_v3_hw 0000:b4:02.0: failed to init debugfs! ... [ 1669.836708] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 1669.872669] pc : down_write+0x24/0x70 [ 1669.876315] lr : down_write+0x1c/0x70 [ 1669.879961] sp : ffff000036f53a30 [ 1669.883260] x29: ffff000036f53a30 x28: ffffa027c31549f8 [ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000 [ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270 [ 1669.899122] x23: ffff0000095406b8 x22: ffff0000095406a8 [ 1669.904408] x21: 0000000000000000 x20: ffffa027bf37c310 [ 1669.909695] x19: 00000000000000a0 x18: ffff8027dcd86f10 [ 1669.914982] x17: 0000000000000000 x16: 0000000000000000 [ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870 [ 1669.925555] x13: 0000000000000040 x12: 0000000000000228 [ 1669.930842] x11: 0000000000000020 x10: 0000000000000bb0 [ 1669.936129] x9 : ffff000036f537f0 x8 : ffff80273088ca10 [ 1669.941416] x7 : 000000000000001d x6 : 00000000ffffffff [ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00 [ 1669.951989] x3 : ffff000009513e90 x2 : 0000000000000000 [ 1669.957276] x1 : 00000000000000a0 x0 : ffffffff00000001 [ 1669.962563] Call trace: [ 1669.965000] down_write+0x24/0x70 [ 1669.968301] debugfs_remove_recursive+0x5c/0x1b0 [ 1669.972905] hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main] [ 1669.978541] hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw] [ 1669.984175] pci_device_remove+0x48/0xd8 [ 1669.988082] device_release_driver_internal+0x1b4/0x250 [ 1669.993282] device_release_driver+0x28/0x38 [ 1669.997534] pci_stop_bus_device+0x84/0xb8 [ 1670.001611] pci_stop_and_remove_bus_device_locked+0x24/0x40 [ 1670.007244] remove_store+0xfc/0x140 [ 1670.010802] dev_attr_store+0x44/0x60 [ 1670.014448] sysfs_kf_write+0x58/0x80 [ 1670.018095] kernfs_fop_write+0xe8/0x1f0 [ 1670.022000] __vfs_write+0x60/0x190 [ 1670.025472] vfs_write+0xac/0x1c0 [ 1670.028771] ksys_write+0x6c/0xd8 [ 1670.032071] __arm64_sys_write+0x24/0x30 [ 1670.035977] el0_svc_common+0x78/0x130 [ 1670.039710] el0_svc_handler+0x38/0x78 [ 1670.043442] el0_svc+0x8/0xc To fix this, set debugfs_dir to NULL after debugfs_remove_recursive(). Signed-off-by:
Xingui Yang <yangxingui@huawei.com> Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). All platform drivers below drivers/ufs/ unconditionally return zero in their remove callback and so can be converted trivially to the variant returning void. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230917145722.1131557-1-u.kleine-koenig@pengutronix.deReviewed-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
-
Martin K. Petersen authored
Damien Le Moal <dlemoal@kernel.org> says: The first patch of this series fixes an issue with IRQ setup which prevents the controller from resuming after a system suspend. The following patches are code cleanup without any functional changes. [mkp: The first patch went into v6.6-rc2 and thus this merge constitutes the remaining patches of the series] Link: https://lore.kernel.org/r/20230911232745.325149-1-dlemoal@kernel.orgSigned-off-by:
-
Damien Le Moal authored
Remove the macro PM8001_READ_VPD used to define if a controller WWN should be retrieved from the device. Instead, define the better named boolean module parameter "read_wwn" to control this. The code to set a fixed address for a phy device address when read_wwn is set to false is simplified and fixed to avoid sparse warnings. Signed-off-by:
Damien Le Moal <dlemoal@kernel.org> Link: https://lore.kernel.org/r/20230911232745.325149-11-dlemoal@kernel.orgSigned-off-by:
-
Damien Le Moal authored
Remove the macro PM8001_USE_TASKLET used to conditionally use tasklets for MSI-X interrupts handling and replace it with the boolean module parameter pm8001_use_tasklet. This parameter defaults to true and can be true only if pm8001_use_msix is also true. Code conditionnaly defined with PM8001_USE_TASKLET is modified to instead use the parameter pm8001_use_tasklet. Signed-off-by:
Jack Wang <jinpu.wang@ionos.com> Signed-off-by:
-
Damien Le Moal authored
The pm8001 driver does not compile if PM8001_USE_MSIX is not defined in pm8001_sas.h because various fields and functions conditionally defined are used unconditionally without a "#ifdef PM8001_USE_MSIX" protection. This macro is rather useless anyway and not convenient as diabling MSI-X use requires recompiling the driver. Remove this macro and replace it with the bool module parameter "use_msix" which defaults to true. The use of MSI-X interrupts for an adapter is gated by this module parameter for adapters that actually support MSI-X. The "use_msix" boolean field is added to struct pm8001_hba_info and all code defined depending on PM8001_USE_MSIX is modified to rely on pm8001_hba_info->use_msix instead. Signed-off-by:
-
Damien Le Moal authored
Remove the functions pm80xx_chip_intx_interrupt_enable() and pm80xx_chip_intx_interrupt_disable() and open code them respectively in pm80xx_chip_interrupt_enable() and pm80xx_chip_interrupt_disable(). Signed-off-by:
-
Damien Le Moal authored
pm8001_chip_msix_interrupt_enable() and pm8001_chip_msix_interrupt_disable() are always cold with the vector argument equal to 0. This allows simplifying the code for these functions. With this change, the functions are simple enough and can be removed by open coding them directly in pm8001_chip_interrupt_enable() and pm8001_chip_interrupt_disable(). Also do the same for the functions pm8001_chip_intx_interrupt_enable() and pm8001_chip_intx_interrupt_disable() and remove these functions. Signed-off-by:
-
Damien Le Moal authored
Factor out the common code of pm8001_interrupt_handler_msix and of pm8001_interrupt_handler_intx() into the new function pm8001_handle_irq() and use this new helper in these two functions to simplify the code. Signed-off-by:
-
Damien Le Moal authored
Factor out the identical code for killing tasklets in pm8001_pci_remove() and pm8001_pci_suspend() and instead use the new function pm8001_kill_tasklet(). Signed-off-by:
-
Damien Le Moal authored
Factor out the identical code for initializing tasklets in pm8001_pci_alloc() and pm8001_pci_resume() and instead use the new function pm8001_init_tasklet(). Signed-off-by:
-
Damien Le Moal authored
Instead of repeating the same code twice in pm8001_pci_remove() and pm8001_pci_suspend() to free IRQs, introduuce the function pm8001_free_irq() to do that. Signed-off-by:
-
- 14 Sep, 2023 1 commit
-
-
Martin K. Petersen authored
Nitin Rawat <quic_nitirawa@quicinc.com> says: This patch series adds programming support for Qualcomm UFS V4 and above to align avoid with Hardware Specification. This patch series will address stability and performance issues. In this patch series below changes are taken care. 1) Register layout for DME_VS_CORE_CLK_CTRL has changed for v4 and above. 2) Adds Support to configure PA_VS_CORE_CLK_40NS_CYCLES attibute for UFS V4 and above. 3) Adds Support to configure multiple unipro frequencies like 403MHz, 300MHz, 202MHz, 150 MHz, 75Mhz, 37.5 MHz for Qualcomm UFS Controller V4 and above. 4) Allow configuration of SYS1CLK_1US_REG for UFS V4 and above. Link: https://lore.kernel.org/r/20230905052400.13935-1-quic_nitirawa@quicinc.comSigned-off-by:
-
