- 20 May, 2020 5 commits
-
-
Luo Jiaxing authored
Make it clear that BIOS may modify some register settings. Link: https://lore.kernel.org/r/1589552025-165012-3-git-send-email-john.garry@huawei.comSigned-off-by:
Luo Jiaxing <luojiaxing@huawei.com> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Luo Jiaxing authored
We found out that after phy up, the hardware reports another oob interrupt but did not follow a phy up interrupt: oob ready -> phy up -> DEV found -> oob read -> wait phy up -> timeout We run link reset when wait phy up timeout, and it send a normal disk into reset processing. So we made some circumvention action in the code, so that this abnormal oob interrupt will not start the timer to wait for phy up. Link: https://lore.kernel.org/r/1589552025-165012-2-git-send-email-john.garry@huawei.comSigned-off-by:
-
Damien Le Moal authored
Export through sysfs as a scsi_disk attribute the zoned capabilities of a disk ("zoned_cap" attribute file). This new attribute indicates in human readable form (i.e. a string) the zoned block capabilities implemented by the disk as found in the ZONED field of the disk block device characteristics VPD page. The possible values are: - "none": ZONED=00b (not reported), regular disk - "host-aware": ZONED=01b, host-aware ZBC disk - "drive-managed": ZONED=10b, drive-managed ZBC disk (regular disk interface) For completeness, also add the following value which is detected using the device type rather than the ZONED field: - "host-managed": device type = 0x14 (TYPE_ZBC), host-managed ZBC disk This new sysfs attribute is purely informational and complementary to the "zoned" device request queue sysfs attribute as it allows applications and user daemons (e.g. udev) to easily differentiate regular disks from drive-managed SMR disks without the need for direct access tools such as provided by sg3utils. Link: https://lore.kernel.org/r/20200515054856.1408575-1-damien.lemoal@wdc.comReviewed-by:Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by:
Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by:
-
Bart Van Assche authored
The ufshcd_wait_for_register() function either sleeps or spins until the specified register has reached the desired value. Busy-waiting is not only considered a bad practice but also has a bad impact on energy consumption. Always sleep instead of spinning by making sure that all ufshcd_wait_for_register() calls happen from a context where it is allowed to sleep. The only function call that has to be moved is the ufshcd_hba_stop() call in ufshcd_host_reset_and_restore(). Link: https://lore.kernel.org/r/20200507222750.19113-1-bvanassche@acm.org Cc: Can Guo <cang@codeaurora.org> Cc: Avri Altman <avri.altman@wdc.com> Cc: Bean Huo <beanhuo@micron.com> Cc: Alim Akhtar <alim.akhtar@samsung.com> Cc: Asutosh Das <asutoshd@codeaurora.org> Tested-by:
Bean Huo <beanhuo@micron.com> Reviewed-by:
Stanley Chu <stanley.chu@mediatek.com> Reviewed-by:
Asutosh Das <asutoshd@codeaurora.org> Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Wei Yongjun authored
Fix to return negative error code -ENOMEM from create_afu error handling case instead of 0, as done elsewhere in this function. Link: https://lore.kernel.org/r/20200428141855.88704-1-weiyongjun1@huawei.comAcked-by:
Matthew R. Ochs <mrochs@linux.ibm.com> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
- 15 May, 2020 6 commits
-
-
Stanley Chu authored
Change the WriteBooster policy to keep VCC on during runtime suspend if available WriteBooster buffer is less than 80%. Link: https://lore.kernel.org/r/20200509093716.21010-5-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Allow flush threshold for WriteBooster to be customizable by vendors. To achieve this, make the value a variable in struct ufs_hba_variant_params. Also introduce UFS_WB_BUF_REMAIN_PERCENT() macro to provide a more flexible way to specify WriteBooster available buffer values. Link: https://lore.kernel.org/r/20200509093716.21010-4-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
The UFS driver is growing more and more customizable parameters. Collect them in one place. Link: https://lore.kernel.org/r/20200509093716.21010-2-stanley.chu@mediatek.comReviewed-by:
-
Damien Le Moal authored
Print a message indicating that a disk is a drive-managed SMR model when such drive is found using the ZONED field of the Block Device Characteristics VPD page (IDENTIFY data on ATA side). [mkp: typo] Link: https://lore.kernel.org/r/20200514081953.1252087-1-damien.lemoal@wdc.comReviewed-by:
-
ChenTao authored
Fix the following warning: drivers/scsi/ufs/ufs-mediatek.c:585:6: warning: symbol 'ufs_mtk_fixup_dev_quirks' was not declared. Should it be static? Link: https://lore.kernel.org/r/20200514012655.127202-1-chentao107@huawei.comReported-by:
Hulk Robot <hulkci@huawei.com> Reviewed-by:
ChenTao <chentao107@huawei.com> Signed-off-by:
-
Dan Carpenter authored
If the memdup_user() function fails then it results in an Oops in the error handling code when we try to kfree() and error pointer. Link: https://lore.kernel.org/r/20200513093703.GB347693@mwanda Fixes: 8d925b1f ("scsi: aacraid: Use memdup_user() as a cleanup") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 13 May, 2020 1 commit
-
-
Jason Yan authored
The 'proc_name' entry in sysfs for hisi_sas is 'null' now because it is not initialized in scsi_host_template. It looks like: [root@localhost ~]# cat /sys/class/scsi_host/host2/proc_name (null) While the other driver's entry looks like: linux-vnMQMU:~ # cat /sys/class/scsi_host/host0/proc_name megaraid_sas Link: https://lore.kernel.org/r/20200512113258.30781-1-yanaijie@huawei.com Cc: John Garry <john.garry@huawei.com> Cc: Xiang Chen <chenxiang66@hisilicon.com> Acked-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
-
- 12 May, 2020 28 commits
-
-
Dan Carpenter authored
This test is checking the wrong variable. It should be testing "res". The "sdeb_zbc_model" variable is an enum (unsigned in this situation) and we never assign negative values to it. [mkp: fixed commit desc issue reported by Doug] Link: https://lore.kernel.org/r/20200509100408.GA5555@mwanda Fixes: 9267e0eb ("scsi: scsi_debug: Add ZBC module parameter") Acked-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
-
Benjamin Block authored
At the moment we allocate and register the Scsi_Host object corresponding to a zfcp adapter (FCP device) very early in the life cycle of the adapter - even before we fully discover and initialize the underlying firmware/hardware. This had the advantage that we could already use the Scsi_Host object, and fill in all its information during said discover and initialize. Due to commit 737eb78e ("block: Delay default elevator initialization") (first released in v5.4), we noticed a regression that would prevent us from using any storage volume if zfcp is configured with support for DIF or DIX (zfcp.dif=1 || zfcp.dix=1). Doing so would result in an illegal memory access as soon as the first request is sent with such an configuration. As example for a crash resulting from this: scsi host0: scsi_eh_0: sleeping scsi host0: zfcp qdio: 0.0.1900 ZFCP on SC 4bd using AI:1 QEBSM:0 PRI:1 TDD:1 SIGA: W AP scsi 0:0:0:0: scsi scan: INQUIRY pass 1 length 36 Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0000000000000000 TEID: 0000000000000483 Fault in home space mode while using kernel ASCE. AS:0000000035c7c007 R3:00000001effcc007 S:00000001effd1000 P:000000000000003d Oops: 0004 ilc:3 [#1] PREEMPT SMP DEBUG_PAGEALLOC Modules linked in: ... CPU: 1 PID: 783 Comm: kworker/u760:5 Kdump: loaded Not tainted 5.6.0-rc2-bb-next+ #1 Hardware name: ... Workqueue: scsi_wq_0 fc_scsi_scan_rport [scsi_transport_fc] Krnl PSW : 0704e00180000000 000003ff801fcdae (scsi_queue_rq+0x436/0x740 [scsi_mod]) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0fffffffffffffff 0000000000000000 0000000187150120 0000000000000000 000003ff80223d20 000000000000018e 000000018adc6400 0000000187711000 000003e0062337e8 00000001ae719000 0000000187711000 0000000187150000 00000001ab808100 0000000187150120 000003ff801fcd74 000003e0062336a0 Krnl Code: 000003ff801fcd9e: e310a35c0012 lt %r1,860(%r10) 000003ff801fcda4: a7840010 brc 8,000003ff801fcdc4 #000003ff801fcda8: e310b2900004 lg %r1,656(%r11) >000003ff801fcdae: d71710001000 xc 0(24,%r1),0(%r1) 000003ff801fcdb4: e310b2900004 lg %r1,656(%r11) 000003ff801fcdba: 41201018 la %r2,24(%r1) 000003ff801fcdbe: e32010000024 stg %r2,0(%r1) 000003ff801fcdc4: b904002b lgr %r2,%r11 Call Trace: [<000003ff801fcdae>] scsi_queue_rq+0x436/0x740 [scsi_mod] ([<000003ff801fcd74>] scsi_queue_rq+0x3fc/0x740 [scsi_mod]) [<00000000349c9970>] blk_mq_dispatch_rq_list+0x390/0x680 [<00000000349d1596>] blk_mq_sched_dispatch_requests+0x196/0x1a8 [<00000000349c7a04>] __blk_mq_run_hw_queue+0x144/0x160 [<00000000349c7ab6>] __blk_mq_delay_run_hw_queue+0x96/0x228 [<00000000349c7d5a>] blk_mq_run_hw_queue+0xd2/0xe0 [<00000000349d194a>] blk_mq_sched_insert_request+0x192/0x1d8 [<00000000349c17b8>] blk_execute_rq_nowait+0x80/0x90 [<00000000349c1856>] blk_execute_rq+0x6e/0xb0 [<000003ff801f8ac2>] __scsi_execute+0xe2/0x1f0 [scsi_mod] [<000003ff801fef98>] scsi_probe_and_add_lun+0x358/0x840 [scsi_mod] [<000003ff8020001c>] __scsi_scan_target+0xc4/0x228 [scsi_mod] [<000003ff80200254>] scsi_scan_target+0xd4/0x100 [scsi_mod] [<000003ff802d8b96>] fc_scsi_scan_rport+0x96/0xc0 [scsi_transport_fc] [<0000000034245ce8>] process_one_work+0x458/0x7d0 [<00000000342462a2>] worker_thread+0x242/0x448 [<0000000034250994>] kthread+0x15c/0x170 [<0000000034e1979c>] ret_from_fork+0x30/0x38 INFO: lockdep is turned off. Last Breaking-Event-Address: [<000003ff801fbc36>] scsi_add_cmd_to_list+0x9e/0xa8 [scsi_mod] Kernel panic - not syncing: Fatal exception: panic_on_oops While this issue is exposed by the commit named above, this is only by accident. The real issue exists for longer already - basically since it's possible to use blk-mq via scsi-mq, and blk-mq pre-allocates all requests for a tag-set during initialization of the same. For a given Scsi_Host object this is done when adding the object to the midlayer (`scsi_add_host()` and such). In `scsi_mq_setup_tags()` the midlayer calculates how much memory is required for a single scsi_cmnd, and its additional data, which also might include space for additional protection data - depending on whether the Scsi_Host has any form of protection capabilities (`scsi_host_get_prot()`). The problem is now thus, because zfcp does this step before we actually know whether the firmware/hardware has these capabilities, we don't set any protection capabilities in the Scsi_Host object. And so, no space is allocated for additional protection data for requests in the Scsi_Host tag-set. Once we go through discover and initialize the FCP device firmware/hardware fully (this is done via the firmware commands "Exchange Config Data" and "Exchange Port Data") we find out whether it actually supports DIF and DIX, and we set the corresponding capabilities in the Scsi_Host object (in `zfcp_scsi_set_prot()`). Now the Scsi_Host potentially has protection capabilities, but the already allocated requests in the tag-set don't have any space allocated for that. When we then trigger target scanning or add scsi_devices manually, the midlayer will use requests from that tag-set, and before sending most requests, it will also call `scsi_mq_prep_fn()`. To prepare the scsi_cmnd this function will check again whether the used Scsi_Host has any protection capabilities - and now it potentially has - and if so, it will try to initialize the assumed to be preallocated structures and thus it causes the crash, like shown above. Before delaying the default elevator initialization with the commit named above, we always would also allocate an elevator for any scsi_device before ever sending any requests - in contrast to now, where we do it after device-probing. That elevator in turn would have its own tag-set, and that is initialized after we went through discovery and initialization of the underlying firmware/hardware. So requests from that tag-set can be allocated properly, and if used - unless the user changes/disabled the default elevator - this would hide the underlying issue. To fix this for any configuration - with or without an elevator - we move the allocation and registration of the Scsi_Host object for a given FCP device to after the first complete discovery and initialization of the underlying firmware/hardware. By doing that we can make all basic properties of the Scsi_Host known to the midlayer by the time we call `scsi_add_host()`, including whether we have any protection capabilities. To do that we have to delay all the accesses that we would have done in the past during discovery and initialization, and do them instead once we are finished with it. The previous patches ramp up to this by fencing and factoring out all these accesses, and make it possible to re-do them later on. In addition we make also use of the diagnostic buffers we recently added with commit 92953c6e ("scsi: zfcp: signal incomplete or error for sync exchange config/port data") commit 7e418833 ("scsi: zfcp: diagnostics buffer caching and use for exchange port data") commit 08821023 ("scsi: zfcp: add diagnostics buffer for exchange config data") (first released in v5.5), because these already cache all the information we need for that "re-do operation" - the information cached are always updated during xconf or xport data, so it won't be stale. In addition to the move and re-do, this patch also updates the function-documentation of `zfcp_scsi_adapter_register()` and changes how it reports if a Scsi_Host object already exists. In that case future recovery-operations can skip this step completely and behave much like they would do in the past - zfcp does not release a once allocated Scsi_Host object unless the corresponding FCP device is deconstructed completely. Link: https://lore.kernel.org/r/030dd6da318bbb529f0b5268ec65cebcd20fc0a3.1588956679.git.bblock@linux.ibm.comReviewed-by:
Steffen Maier <maier@linux.ibm.com> Signed-off-by:
Benjamin Block <bblock@linux.ibm.com> Signed-off-by:
-
Benjamin Block authored
When setting an adapter online for the first time, we also create a couple of entries for it in the sysfs device tree. This is also true even if the adapter has not yet ever gone successfully through exchange config and exchange port data. When moving the scsi host object allocation and registration to after the first exchange config and exchange port data, this make the `port_rescan` attribute susceptible to invalid pointer-dereferences of the shost field before the adapter is fully initialized. When written to, it schedules a `scan_work` item that will in turn make use of the associated fibre channel host object to check the topology used for this FCP device. Because scanning for remote ports can't be done successfully without completing exchange config and exchange port data first, we can simply fence `port_rescan`, and so prevent the illegal access. As with cases where we can't get a reference to the adapter, we also return -ENODEV here. Applications need to handle that errno today already. After a successful allocation of the scsi host object nothing changes in the work flow. Link: https://lore.kernel.org/r/ef65366d309993ca91b6917727590ca7ca166c8f.1588956679.git.bblock@linux.ibm.comReviewed-by:
-
Benjamin Block authored
Common status flags that all main objects - adapter, port, and unit - support are propagated to sub-objects when set or cleared. For instance, when setting the status ZFCP_STATUS_COMMON_ERP_INUSE for an adapter object, we will propagate this to all its child ports and units - same for when clearing a common status flag. Units of an adapter object are enumerated via __shost_for_each_device() over the scsi host object of the corresponding adapter. Once we move the scsi host object allocation and registration to after the first exchange config and exchange port data, this won't be possible for cases where we set or clear common statuses during the very first adapter recovery. But since we won't have any port or unit objects yet at that point of time, we can just fence the status propagation for cases where the scsi host object is not yet set in the adapter object. It won't change any effective status propagations, but will prevent us from dereferencing invalid pointers. For any later point in the work flow the scsi host object will be set and thus nothing is changed then. Link: https://lore.kernel.org/r/f51fe5f236a1e3d1ce53379c308777561bfe35e1.1588956679.git.bblock@linux.ibm.comReviewed-by:
-
Benjamin Block authored
When doing the very first adapter recovery - initialization - for a FCP device in a point-to-point topology we also allocate the port object corresponding to the attached remote port, and trigger a port recovery for it that will run after the adapter recovery finished. Right now this happens right after we finished with the exchange config data command, and uses the fibre channel host object corresponding to the FCP device to determine whether a point-to-point topology is used. When moving the scsi host object allocation and registration - and thus also the fibre channel host object allocation - to after the first exchange config and exchange port data, this use of the fc_host object is not possible anymore at that point in the work flow. But the allocation and recovery trigger doesn't have notable side-effects on the following exchange port data processing, so we can move those to after xport data, and thus also to after the scsi host object allocation, once we move it. Then the fc_host object can be used again, like it is now. For any further adapter recoveries this doesn't change anything, because at that point the port object already exists and recovery is triggered elsewhere for existing port objects. Link: https://lore.kernel.org/r/73e5d4ac21e2b37bf0c3ca8e530bc5a5c6e74f8f.1588956679.git.bblock@linux.ibm.comReviewed-by:
-
Benjamin Block authored
When receiving a notification that a FCP device lost its local link we usually update the fibre channel host object which represents that FCP device to reflect that. This notification/information can also surface when the FCP device is running through adapter recovery (exchange config and exchange port data return incomplete). When moving the scsi host object allocation and registration - and thus also the fibre channel host object allocation - to after the first exchange config and exchange port data, and this happens during the very first adapter recovery, these updates can not be done until after the scsi host object is allocated. Reorder the fc_host updates in zfcp_fsf_fc_host_link_down() so that they only happen after a check of whether the scsi host object is already allocated or not. During the first adapter recovery this will cause the skip of these updates if a link-down condition is detected, but we can repeat them after we allocated the scsi host object, if necessary. For any further link-down handling the only changes in the work flow are the slightly reordered assignments in zfcp_fsf_fc_host_link_down(). Link: https://lore.kernel.org/r/f841f2cda61dcd7b8549910c44e1831927459edf.1588956679.git.bblock@linux.ibm.comReviewed-by:
-
Benjamin Block authored
When executing exchange port data for a FCP device for the first time, or after an adapter recovery, we update several properties of the fibre channel host object which represents that FCP device. When moving the scsi host object allocation and registration - and thus also the fibre channel host object allocation - to after the first exchange config and exchange port data, this is not possible for the former case. Move all these update into separate, and fenced function that first checks whether the scsi host object already exists or not, before making the updates. During the first ever exchange port data in the adapter life cycle this will make the exchange port data handler skip over this update step, but we can repeat it later, after we allocated the scsi host object. For any further recovery of that adapter the work flow is only changed slightly because then the scsi host object already exists and we don't free it until we release the adapter completely at the end of its life cycle. Link: https://lore.kernel.org/r/ae454c2dc6da0b02907c489af91d0b211d331825.1588956679.git.bblock@linux.ibm.comReviewed-by:
-
Benjamin Block authored
When executing exchange config data for a FCP device for the first time, or after an adapter recovery, we update several properties of the scsi host or fibre channel host object that represent that FCP device. When moving the scsi host object allocation and registration - and thus also the fibre channel host object allocation - to after the first exchange config and exchange port data, this is not possible for the former case. Move all these update into separate, and fenced function that first checks whether the scsi host object already exists or not, before making the updates. During the first ever exchange config data in the adapter life cycle this will make the exchange config data handler skip over this update step, but we can repeat it later, after we allocated the scsi host object. For any further recovery of that adapter the work flow is only changed slightly because then the scsi host object already exists and we don't free it until we release the adapter completely at the end of its life cycle. Link: https://lore.kernel.org/r/5fc3f4d38d4334f7aa595497c6f7865fb1102e0f.1588956679.git.bblock@linux.ibm.comReviewed-by:
-
Benjamin Block authored
When establishing and activating the QDIO queue pair for a FCP device for the first time, or after an adapter recovery, we publish some of its characteristics to the scsi host object representing that FCP device. When moving the scsi host object allocation and registration to after the first exchange config and exchange port data, this is not possible for the former case - QDIO open for the first time - because that happens before exchange config and exchange port data. Move the scsi host object update into a fenced function that checks whether the object already exists or not. This way we can repeat that step later, once we are past the allocation. Once the first recovery succeeds we don't release the scsi host object anymore, so further recoveries do work as before. Link: https://lore.kernel.org/r/a214ebf508f71e3690113e3e90edab1cea0e24e3.1588956679.git.bblock@linux.ibm.comReviewed-by:
-
Samuel Zou authored
Fix the following versioncheck warning: drivers/scsi/mpt3sas/mpt3sas_debugfs.c:16:1: unused including <linux/version.h> Link: https://lore.kernel.org/r/1588938573-57847-1-git-send-email-zou_wei@huawei.comReported-by:
Samuel Zou <zou_wei@huawei.com> Signed-off-by:
-
Suganath Prabu S authored
Fix following warning from Smatch static analyser: drivers/scsi/mpt3sas/mpt3sas_base.c:5256 _base_allocate_memory_pools() warn: 'ioc->hpr_lookup' double freed drivers/scsi/mpt3sas/mpt3sas_base.c:5256 _base_allocate_memory_pools() warn: 'ioc->internal_lookup' double freed Link: https://lore.kernel.org/r/20200508110738.30732-1-suganath-prabu.subramani@broadcom.comReported-by:
Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by:
-
Chandrakanth Patil authored
Link: https://lore.kernel.org/r/20200508085314.23461-1-chandrakanth.patil@broadcom.comSigned-off-by:
Chandrakanth Patil <chandrakanth.patil@broadcom.com> Signed-off-by:
-
Sumit Saxena authored
When TM command times out, driver invokes the controller reset. Post reset, driver re-fires pended TM commands which leads to firmware crash. Post controller reset, return pended TM commands back to OS. Link: https://lore.kernel.org/r/20200508085242.23406-1-chandrakanth.patil@broadcom.com Cc: stable@vger.kernel.org Signed-off-by:
Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
-
Shivasharan S authored
MFI_BIG_ENDIAN macro used in drivers structure bitfield to check the CPU big endianness is undefined which would break the code on big endian machine. __BIG_ENDIAN_BITFIELD kernel macro should be used in places of MFI_BIG_ENDIAN macro. Link: https://lore.kernel.org/r/20200508085130.23339-1-chandrakanth.patil@broadcom.com Fixes: a7faf81d ("scsi: megaraid_sas: Set no_write_same only for Virtual Disk") Cc: <stable@vger.kernel.org> # v5.6+ Signed-off-by:
Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by:
-
Sumit Saxena authored
As blk_queue_virt_boundary() API in slave_configure ensures that no IOs will come with holes/gaps. Hence, code logic to detect the holes/gaps in IO buffer is not required. Link: https://lore.kernel.org/r/20200508083838.22778-3-chandrakanth.patil@broadcom.comSigned-off-by:
-
Kashyap Desai authored
The driver currently assigns a pre-defined queue depth when the firmware-provided device queue depth is greater than the controller queue depth. Use the controller queue depth if the reported target queue depth is too large. Link: https://lore.kernel.org/r/20200508083838.22778-2-chandrakanth.patil@broadcom.comSigned-off-by:
Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by:
-
Stanley Chu authored
Small cleanup as below items, 1. Use ufshcd_is_wb_allowed() directly instead of ufshcd_wb_sup() since ufshcd_wb_sup() just returns the result of ufshcd_is_wb_allowed(). 2. In ufshcd_suspend(), "else if (!ufshcd_is_runtime_pm(pm_op)) can be simplified to "else" since both have the same meaning. This patch does not change any functionality. Link: https://lore.kernel.org/r/20200508080115.24233-9-stanley.chu@mediatek.comReviewed-by:Avri Altman <avri.altman@wdc.com> Reviewed-by:
-
Stanley Chu authored
Enable WriteBooster capability on MediaTek UFS platforms. Link: https://lore.kernel.org/r/20200508080115.24233-8-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
According to UFS specification, there are two WriteBooster mode of operations: "LU dedicated buffer" mode and "shared buffer" mode. In the "LU dedicated buffer" mode, the WriteBooster Buffer is dedicated to a logical unit. If the device supports the "LU dedicated buffer" mode, this mode is configured by setting bWriteBoosterBufferType to 00h. The logical unit WriteBooster Buffer size is configured by setting the dLUNumWriteBoosterBufferAllocUnits field of the related Unit Descriptor. Only a value greater than zero enables the WriteBooster feature in the logical unit. Modify ufshcd_wb_probe() as above description to support LU Dedicated buffer mode. Note that according to UFS 3.1 specification, the valid value of bDeviceMaxWriteBoosterLUs parameter in Geometry Descriptor is 1, which means at most one LUN can have WriteBooster buffer in "LU dedicated buffer mode". Therefore this patch supports only one LUN with WriteBooster enabled. All WriteBooster related sysfs nodes are specifically mapped to the LUN with WriteBooster enabled in LU Dedicated buffer mode. Link: https://lore.kernel.org/r/20200508080115.24233-7-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
For preparation of LU Dedicated buffer mode support on WriteBooster feature, "index" parameter shall be added and allowed to be specified by callers. Link: https://lore.kernel.org/r/20200508080115.24233-6-stanley.chu@mediatek.comReviewed-by:
Can Guo <cang@codeaurora.org> Reviewed-by:
-
Stanley Chu authored
Add fixup_dev_quirk vops in MediaTek UFS platforms and provide an initial vendor-specific device quirk table. Link: https://lore.kernel.org/r/20200508080115.24233-5-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Export ufs_fixup_device_setup() to allow vendors to re-use it for fixing device quriks on specified UFS hosts. Link: https://lore.kernel.org/r/20200508080115.24233-4-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Some UFS deivces may have required device quirks or have non-standard features which are enabled only on specified UFS hosts or for special customers. To not "pollute" common device quirk list, i.e. ufs_fixups table, for those devices mentioned above, introduce "fixup_dev_quirks" vops to allow vendors to fix or modify device quirks accordingly. Link: https://lore.kernel.org/r/20200508080115.24233-3-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
The WriteBooster feature can be supported by some pre-3.1 UFS devices by upgrading firmware. To enable WriteBooster feature in such devices, introduce a device quirk to relax the entrance condition of ufshcd_wb_probe() to allow host driver to check those devices' WriteBooster capability. WriteBooster feature can be available if below all conditions are satisfied, 1. Host enables WriteBooster capability 2. UFS 3.1 device or UFS pre-3.1 device with quirk UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES enabled 3. The device descriptor shall have DEVICE_DESC_PARAM_EXT_UFS_FEATURE_SUP field 4. WriteBooster support is specified in above field Link: https://lore.kernel.org/r/20200508080115.24233-2-stanley.chu@mediatek.comReviewed-by: -
Colin Ian King authored
The variable rc is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Link: https://lore.kernel.org/r/20200507203111.64709-1-colin.king@canonical.comSigned-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Link: https://lore.kernel.org/r/20200507192550.GA16683@embeddedorSigned-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Link: https://lore.kernel.org/r/20200507192147.GA16206@embeddedorReviewed-by: -
Xie XiuQi authored
uctrl and udev are unused after commit 9632a6b4 ("scsi: qedi: Move LL2 producer index processing in BH.") Remove them. Link: https://lore.kernel.org/r/20200505121904.25702-1-xiexiuqi@huawei.comReviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by:
-
