- Dec 17, 2021
-
-
George Kennedy authored
Avoid data corruption by rejecting pass-through commands where T_LENGTH is zero (No data is transferred) and the dma direction is not DMA_NONE. Cc: <stable@vger.kernel.org> Reported-by:
<syzkaller<syzkaller@googlegroups.com> Signed-off-by:
George <Kennedy<george.kennedy@oracle.com> Signed-off-by:
Damien Le Moal <damien.lemoal@opensource.wdc.com>
-
- Dec 09, 2021
-
-
Hannes Reinecke authored
The ASMedia 1092 has a configuration mode which will present a dummy device; sadly the implementation falsely claims to provide a device with 100M which doesn't actually exist. So disable this device to avoid errors during boot. Cc: stable@vger.kernel.org Signed-off-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
-
- Dec 06, 2021
-
-
Damien Le Moal authored
ATA IDENTIFY command returns an array of le16 words. Accessing it as a u16 array triggers the following sparse warning: drivers/ata/ahci_ceva.c:107:33: warning: invalid assignment: &= drivers/ata/ahci_ceva.c:107:33: left side has type unsigned short drivers/ata/ahci_ceva.c:107:33: right side has type restricted __le16 Use a local variable to explicitly cast the id array to __le16 to avoid this warning. Signed-off-by:
-
- Dec 02, 2021
-
-
Yang Guang authored
coccinelle report： ./drivers/ata/libata-sata.c:830:8-16: WARNING: use scnprintf or sprintf Use sysfs_emit instead of scnprintf or sprintf makes more sense. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Yang Guang <yang.guang5@zte.com.cn> Signed-off-by:
-
- Nov 29, 2021
-
-
Baokun Li authored
Trying to remove the fsl-sata module in the PPC64 GNU/Linux leads to the following warning: ------------[ cut here ]------------ remove_proc_entry: removing non-empty directory 'irq/69', leaking at least 'fsl-sata[ff0221000.sata]' WARNING: CPU: 3 PID: 1048 at fs/proc/generic.c:722 .remove_proc_entry+0x20c/0x220 IRQMASK: 0 NIP [c00000000033826c] .remove_proc_entry+0x20c/0x220 LR [c000000000338268] .remove_proc_entry+0x208/0x220 Call Trace: .remove_proc_entry+0x208/0x220 (unreliable) .unregister_irq_proc+0x104/0x140 .free_desc+0x44/0xb0 .irq_free_descs+0x9c/0xf0 .irq_dispose_mapping+0x64/0xa0 .sata_fsl_remove+0x58/0xa0 [sata_fsl] .platform_drv_remove+0x40/0x90 .device_release_driver_internal+0x160/0x2c0 .driver_detach+0x64/0xd0 .bus_remove_driver+0x70/0xf0 .driver_unregister+0x38/0x80 .platform_driver_unregister+0x14/0x30 .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] ---[ end trace 0ea876d4076908f5 ]--- The driver creates the mapping by calling irq_of_parse_and_map(), so it also has to dispose the mapping. But the easy way out is to simply use platform_get_irq() instead of irq_of_parse_map(). Also we should adapt return value checking and propagate error values. In this case the mapping is not managed by the device but by the of core, so the device has not to dispose the mapping. Fixes: faf0b2e5 ("drivers/ata: add support to Freescale 3.0Gbps SATA Controller") Cc: stable@vger.kernel.org Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Baokun Li <libaokun1@huawei.com> Reviewed-by:
Sergei Shtylyov <sergei.shtylyov@gmail.com> Signed-off-by:
-
Baokun Li authored
When the `rmmod sata_fsl.ko` command is executed in the PPC64 GNU/Linux, a bug is reported: ================================================================== BUG: Unable to handle kernel data access on read at 0x80000800805b502c Oops: Kernel access of bad area, sig: 11 [#1] NIP [c0000000000388a4] .ioread32+0x4/0x20 LR [80000000000c6034] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl] Call Trace: .free_irq+0x1c/0x4e0 (unreliable) .ata_host_stop+0x74/0xd0 [libata] .release_nodes+0x330/0x3f0 .device_release_driver_internal+0x178/0x2c0 .driver_detach+0x64/0xd0 .bus_remove_driver+0x70/0xf0 .driver_unregister+0x38/0x80 .platform_driver_unregister+0x14/0x30 .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl] .__se_sys_delete_module+0x1ec/0x2d0 .system_call_exception+0xfc/0x1f0 system_call_common+0xf8/0x200 ================================================================== The triggering of the BUG is shown in the following stack: driver_detach device_release_driver_internal __device_release_driver drv->remove(dev) --> platform_drv_remove/platform_remove drv->remove(dev) --> sata_fsl_remove iounmap(host_priv->hcr_base); <---- unmap kfree(host_priv); <---- free devres_release_all release_nodes dr->node.release(dev, dr->data) --> ata_host_stop ap->ops->port_stop(ap) --> sata_fsl_port_stop ioread32(hcr_base + HCONTROL) <---- UAF host->ops->host_stop(host) The iounmap(host_priv->hcr_base) and kfree(host_priv) functions should not be executed in drv->remove. These functions should be executed in host_stop after port_stop. Therefore, we move these functions to the new function sata_fsl_host_stop and bind the new function to host_stop. Fixes: faf0b2e5 ("drivers/ata: add support to Freescale 3.0Gbps SATA Controller") Cc: stable@vger.kernel.org Reported-by:
-
Finn Thain authored
The zero day bot reported some sparse complaints in pata_falcon.c. E.g. drivers/ata/pata_falcon.c:58:41: warning: cast removes address space '__iomem' of expression drivers/ata/pata_falcon.c:58:41: warning: incorrect type in argument 1 (different address spaces) drivers/ata/pata_falcon.c:58:41: expected unsigned short volatile [noderef] [usertype] __iomem *port drivers/ata/pata_falcon.c:58:41: got unsigned short [usertype] * The same thing shows up in 8 places, all told. Avoid this by removing unnecessary type casts. Cc: Jens Axboe <axboe@kernel.dk> Cc: Michael Schmitz <schmitzmic@gmail.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Reported-by:
kernel test robot <lkp@intel.com> Suggested-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Finn Thain <fthain@linux-m68k.org> Reviewed-by:
-
- Nov 18, 2021
-
-
Damien Le Moal authored
Since ata_ncq_sdev_attrs is a local struct, declare it static. This avoids a sparse warning at compile time. Signed-off-by: -
Mario Limonciello authored
The StorageD3Enable _DSD is used for the vendor to indicate that the disk should be opted into or out of a different behavior based upon the platform design. For AMD's Renoir and Green Sardine platforms it's important that any attached SATA storage has transitioned into DevSlp when s2idle is used. If the disk is left in active/partial/slumber, then the system is not able to resume properly. When the StorageD3Enable _DSD is detected, check the system is using s2idle and DevSlp is enabled and if so explicitly wait long enough for the disk to enter DevSlp. Cc: Nehal-bakulchandra Shah <Nehal-bakulchandra.Shah@amd.com> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214091 Link: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/power-management-for-storage-hardware-devices-intro Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
-
Mario Limonciello authored
AMD requires that the SATA controller be configured for devsleep in order for S0i3 entry to work properly. commit b1a9585c ("ata: ahci: Enable DEVSLP by default on x86 with SLP_S0") sets up a kernel policy to enable devsleep on Intel mobile platforms that are using s0ix. Add the PCI ID for the SATA controller in Green Sardine platforms to extend this policy by default for AMD based systems using s0i3 as well. Cc: Nehal-bakulchandra Shah <Nehal-bakulchandra.Shah@amd.com> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214091 Signed-off-by:
-
Damien Le Moal authored
ata_dev_config_ncq_prio() and ata_dev_config_devslp() both access pages of the IDENTIFY DEVICE data log. Before calling ata_read_log_page(), make sure to check for the existence of the IDENTIFY DEVICE data log and of the log page accessed using ata_identify_page_supported(). This avoids useless error messages from ata_read_log_page() and failures with some LLDD scsi drivers using libsas. Reported-by:
Nikolay <knv418@gmail.com> Cc: stable@kernel.org # 5.15 Signed-off-by:
Matthew Perkowski <mgperkow@gmail.com>
-
- Nov 16, 2021
-
-
Damien Le Moal authored
If ata_read_log_page() fails to read a log page, the ata_dev_err() error message only print the page number, omitting the log number. In case of error, facilitate debugging by also printing the log number. Cc: stable@kernel.org # 5.15 Signed-off-by:
-
- Nov 11, 2021
-
-
Damien Le Moal authored
ahci_shost_attr_group is referenced only in drivers/ata/libahci.c. Declare it as static. Fixes: c3f69c7f ("scsi: ata: Switch to attribute groups") Cc: Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Christoph Hellwig <hch@lst.de>
-
Damien Le Moal authored
ACS-3 introduced the ATA Identify Device Data log as mandatory. A warning message currently signals to the user if a device does not report supporting this log page in the log directory page, regardless of the ATA version of the device. Furthermore, this warning will appear for all attempts at accessing this missing log page during device revalidation. Since it is useless to constantly access the log directory and warn about this lack of support once we have discovered that the device does not support this log page, introduce the horkage flag ATA_HORKAGE_NO_ID_DEV_LOG to mark a device as lacking support for the Identify Device Data log page. Set this flag when ata_log_supported() returns false in ata_identify_page_supported(). The warning is printed only if the device ATA level is 10 or above (ACS-3 or above), and only once on device scan. With this flag set, the log directory page is not accessed again to test for Identify Device Data log page support. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Xu Wang authored
The print function dev_err() is redundant because platform_get_irq() already prints an error. Signed-off-by:
Xu Wang <vulab@iscas.ac.cn> Signed-off-by:
-
Damien Le Moal authored
Some ATA drives are very slow to respond to READ_LOG_EXT and READ_LOG_DMA_EXT commands issued from ata_dev_configure() when the device is revalidated right after resuming a system or inserting the ATA adapter driver (e.g. ahci). The default 5s timeout (ATA_EH_CMD_DFL_TIMEOUT) used for these commands is too short, causing errors during the device configuration. Ex: ... ata9: SATA max UDMA/133 abar m524288@0x9d200000 port 0x9d200400 irq 209 ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300) ata9.00: ATA-9: XXX XXXXXXXXXXXXXXX, XXXXXXXX, max UDMA/133 ata9.00: qc timeout (cmd 0x2f) ata9.00: Read log page 0x00 failed, Emask 0x4 ata9.00: Read log page 0x00 failed, Emask 0x40 ata9.00: NCQ Send/Recv Log not supported ata9.00: Read log page 0x08 failed, Emask 0x40 ata9.00: 27344764928 sectors, multi 16: LBA48 NCQ (depth 32), AA ata9.00: Read log page 0x00 failed, Emask 0x40 ata9.00: ATA Identify Device Log not supported ata9.00: failed to set xfermode (err_mask=0x40) ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300) ata9.00: configured for UDMA/133 ... The timeout error causes a soft reset of the drive link, followed in most cases by a successful revalidation as that give enough time to the drive to become fully ready to quickly process the read log commands. However, in some cases, this also fails resulting in the device being dropped. Fix this by using adding the ata_eh_revalidate_timeouts entries for the READ_LOG_EXT and READ_LOG_DMA_EXT commands. This defines a timeout increased to 15s, retriable one time. Reported-by:
Geert Uytterhoeven <geert+renesas@glider.be> Cc: stable@vger.kernel.org Signed-off-by:
-
- Oct 27, 2021
-
-
Damien Le Moal authored
Add support to discover if an ATA device supports the Concurrent Positioning Ranges data log (address 0x47), indicating that the device is capable of seeking to multiple different locations in parallel using multiple actuators serving different LBA ranges. Also add support to translate the concurrent positioning ranges log into its equivalent Concurrent Positioning Ranges VPD page B9h in libata-scsi.c. The format of the Concurrent Positioning Ranges Log is defined in ACS-5 r9. Signed-off-by:
Damien Le Moal <damien.lemoal@wdc.com> Reviewed-by:
Keith Busch <kbusch@kernel.org> Link: https://lore.kernel.org/r/20211027022223.183838-4-damien.lemoal@wdc.com Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
- Oct 24, 2021
-
-
Zheyu Ma authored
mv_init_host() propagates the value returned by mv_chip_id() which in turn gets propagated by mv_pci_init_one() and hits local_pci_probe(). During the process of driver probing, the probe function should return < 0 for failure, otherwise, the kernel will treat value > 0 as success. Since this is a bug rather than a recoverable runtime error we should use dev_alert() instead of dev_err(). Signed-off-by:
Zheyu Ma <zheyuma97@gmail.com> Signed-off-by:
-
- Oct 17, 2021
-
-
Bart Van Assche authored
struct device supports attribute groups directly but does not support struct device_attribute directly. Hence switch to attribute groups. Link: https://lore.kernel.org/r/20211012233558.4066756-3-bvanassche@acm.org Acked-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
Bart Van Assche authored
Conditional statements are faster than indirect calls. Hence call scsi_done() directly. Link: https://lore.kernel.org/r/20211007202923.2174984-4-bvanassche@acm.org Acked-by:
-
- Oct 14, 2021
-
-
Wang Hai authored
I got a null-ptr-deref report: KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] ... RIP: 0010:regulator_enable+0x84/0x260 ... Call Trace: ahci_platform_enable_regulators+0xae/0x320 ahci_platform_enable_resources+0x1a/0x120 ahci_probe+0x4f/0x1b9 platform_probe+0x10b/0x280 ... entry_SYSCALL_64_after_hwframe+0x44/0xae If devm_regulator_get() in ahci_platform_get_resources() fails, hpriv->phy_regulator will point to NULL, when enabling or disabling it, null-ptr-deref will occur. ahci_probe() ahci_platform_get_resources() devm_regulator_get(, "phy") // failed, let phy_regulator = NULL ahci_platform_enable_resources() ahci_platform_enable_regulators() regulator_enable(hpriv->phy_regulator) // null-ptr-deref commit 962399bb ("ata: libahci_platform: Fix regulator_get_optional() misuse") replaces devm_regulator_get_optional() with devm_regulator_get(), but PHY regulator omits to delete "hpriv->phy_regulator = NULL;" like AHCI. Delete it like AHCI regulator to fix this bug. Fixes: commit 962399bb ("ata: libahci_platform: Fix regulator_get_optional() misuse") Reported-by:
Wang Hai <wanghai38@huawei.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
- Oct 12, 2021
-
-
Reimar Döffinger authored
Checking if DMA is enabled should be done via the ata_dma_enabled helper function, since the init state 0xff indicates disabled. Change based on code review, not tested due to lack of hardware. Signed-off-by:
Reimar Döffinger <Reimar.Doeffinger@gmx.de> Signed-off-by:
-
Reimar Döffinger authored
Checking if DMA is enabled should be done via the ata_dma_enabled helper function, since the init state 0xff indicates disabled. Change based on code review, not tested due to lack of hardware. Signed-off-by:
-
Reimar Döffinger authored
Checking if DMA is enabled should be done via the ata_dma_enabled helper function, since the init state 0xff indicates disabled. Change based on code review, not tested due to lack of hardware. Signed-off-by:
-
Reimar Döffinger authored
Checking if DMA is enabled should be done via the ata_dma_enabled helper function, since the init state 0xff indicates disabled. Change based on code review, not tested due to lack of hardware. Signed-off-by:
-
Reimar Döffinger authored
Checking if DMA is enabled should be done via the ata_dma_enabled helper function, since the init state 0xff indicates disabled. Change based on code review, not tested due to lack of hardware. Signed-off-by:
-
Reimar Döffinger authored
Checking if DMA is enabled should be done via the ata_dma_enabled helper function, since the init state 0xff indicates disabled. This meant that ATA_CMD_READ_LOG_DMA_EXT was used and probed for before DMA was enabled, which caused hangs for some combinations of controllers and devices. It might also have caused it to be incorrectly disabled as broken, but there have been no reports of that. Cc: stable@vger.kernel.org BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195895 Signed-off-by:
Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by:
-
István Pongrácz authored
Add support for PCIe SATA expander cards based on ASMedia 1062 + JBM575 controllers. These cards can provide up to 10 or more SATA ports on one PCIe card. Signed-off-by:
István Pongrácz <pongracz.istvan@gmail.com> Signed-off-by:
-
Dan Carpenter authored
The last byte of "pad" is used without being initialized. Fixes: 55dba312 ("libata: update ->data_xfer hook for ATAPI") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- Sep 21, 2021
-
-
Krzysztof Kozlowski authored
Intel devices 0x2822, 0x2823, 0x2826 and 0x2827 are already on the list as Lewisburg AHCI/RAID. They use same configuration except 0x2822 which has board_ahci_nosntf (for ICH8). Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by:
-
- Sep 03, 2021
-
-
Kate Hsuan authoredMany users are reporting that the Samsung 860 and 870 SSD are having various issues when combined with AMD/ATI (vendor ID 0x1002) SATA controllers and only completely disabling NCQ helps to avoid these issues. Always disabling NCQ for Samsung 860/870 SSDs regardless of the host SATA adapter vendor will cause I/O performance degradation with well behaved adapters. To limit the performance impact to ATI adapters, introduce the ATA_HORKAGE_NO_NCQ_ON_ATI flag to force disable NCQ only for these adapters. Also, two libata.force parameters (noncqati and ncqati) are introduced to disable and enable the NCQ for the system which equipped with ATI SATA adapter and Samsung 860 and 870 SSDs. The user can determine NCQ function to be enabled or disabled according to the demand. After verifying the chipset from the user reports, the issue appears on AMD/ATI SB7x0/SB8x0/SB9x0 SATA Controllers and does not appear on recent AMD SATA adapters. The vendor ID of ATI should be 0x1002. Therefore, ATA_HORKAGE_NO_NCQ_ON_AMD was modified to ATA_HORKAGE_NO_NCQ_ON_ATI. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201693 Signed-off-by:
Kate Hsuan <hpa@redhat.com> Reviewed-by:
-
Hans de Goede authored
Commit ca6bfcb2 ("libata: Enable queued TRIM for Samsung SSD 860") limited the existing ATA_HORKAGE_NO_NCQ_TRIM quirk from "Samsung SSD 8*", covering all Samsung 800 series SSDs, to only apply to "Samsung SSD 840*" and "Samsung SSD 850*" series based on information from Samsung. But there is a large number of users which is still reporting issues with the Samsung 860 and 870 SSDs combined with Intel, ASmedia or Marvell SATA controllers and all reporters also report these problems going away when disabling queued trims. Note that with AMD SATA controllers users are reporting even worse issues and only completely disabling NCQ helps there, this will be addressed in a separate patch. Fixes: ca6bfcb2 ("libata: Enable queued TRIM for Samsung SSD 860") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=203475 Cc: stable@vger.kernel.org Cc: Kate Hsuan <hpa@redhat.com> Signed-off-by:
-
- Aug 18, 2021
-
-
Damien Le Moal authored
Currently, the only way a user can determine if a SATA device supports NCQ priority is to try to enable the use of this feature using the ncq_prio_enable sysfs device attribute. If enabling the feature fails, it is because the device does not support NCQ priority. Otherwise, the feature is enabled and success indicates that the device supports NCQ priority. Improve this odd interface by introducing the read-only ncq_prio_supported sysfs device attribute to indicate if a SATA device supports NCQ priority. The value of this attribute reflects the status of device flag ATA_DFLAG_NCQ_PRIO, which is set only for devices supporting NCQ priority. Add this new sysfs attribute to the device attributes group of libahci and libata-sata. Signed-off-by:
-
Damien Le Moal authored
Print a list of features supported by a drive when it is configured in ata_dev_configure() using the new function ata_dev_print_features(). The features printed are not already advertized and are: trusted send-recev support, device attention support, device sleep support, NCQ send-recv support and NCQ priority support. Signed-off-by:
-
Damien Le Moal authored
Support for the READ LOG PAGE DMA EXT command is indicated by words 119 and 120 of a device identify data. This is tested in ata_read_log_page() with ata_id_has_read_log_dma_ext() and the READ LOG PAGE DMA command used if the device reports supports for it. However, some devices lie about this support and using the DMA version of the command fails, generating the warning message "READ LOG DMA EXT failed, trying PIO". Since READ LOG PAGE DMA EXT is an optional command, this warning is not at all important but may be scary for the user. Change ata_read_log_page() to suppres this warning and to print an error message if both DMA and PIO attempts failed. With this change, there is no need to print again an error message when ata_read_log_page() returns an error. So simplify the users of this function. Signed-off-by:
-
Damien Le Moal authored
The ata device flag ATA_DFLAG_NCQ_PRIO indicates if a device supports the NCQ Priority feature while the ATA_DFLAG_NCQ_PRIO_ENABLE device flag indicates if the feature is enabled. Enabling NCQ priority use is controlled by the user through the device sysfs attribute ncq_prio_enable. As a result, the ATA_DFLAG_NCQ_PRIO flag should not be cleared when ATA_DFLAG_NCQ_PRIO_ENABLE is not set as the device still supports the feature even after the user disables it. This leads to the following cleanups: - In ata_build_rw_tf(), set a command high priority bit based on the ATA_DFLAG_NCQ_PRIO_ENABLE flag, not on the ATA_DFLAG_NCQ flag. That is, set a command high priority only if the user enabled NCQ priority use. - In ata_dev_config_ncq_prio(), ATA_DFLAG_NCQ_PRIO should not be cleared if ATA_DFLAG_NCQ_PRIO_ENABLE is not set. If the device does not support NCQ priority, both ATA_DFLAG_NCQ_PRIO and ATA_DFLAG_NCQ_PRIO_ENABLE must be cleared. With the above ata_dev_config_ncq_prio() change, ATA_DFLAG_NCQ_PRIO flag is set on device scan and revalidation. There is no need to trigger a device revalidation in ata_ncq_prio_enable_store() when the user enables the use of NCQ priority. Remove the revalidation code from that funciton to simplify it. Also change the return value from -EIO to -EINVAL when a user tries to enable NCQ priority for a device that does not support this feature. While at it, also simplify ata_ncq_prio_enable_show(). Overall, there is no functional change introduced by this patch. Signed-off-by:
-
Damien Le Moal authored
Introduce the helper functions ata_dev_config_lba() and ata_dev_config_chs() to configure the addressing capabilities of a device. To control message printing in these new helpers, as well as in ata_dev_configure() and in ata_hpa_resize(), add the helper function ata_dev_print_info() to avoid open coding for the eh context ATA_EHI_PRINTINFO flag in multiple functions. Signed-off-by:
-
Damien Le Moal authored
Move the code to retrieve the device sleep capability and timings out of ata_dev_configure() into the helper function ata_dev_config_devslp(). While at it, mark the device as supporting the device sleep capability only if the sata settings page was retrieved successfully to ensure that the timing information is correctly initialized. Signed-off-by:
-
Damien Le Moal authored
Sparse complains about context imbalance in ata_scsi_rbuf_get() and ata_scsi_rbuf_put() due to these functions respectively only taking and releasing the ata_scsi_rbuf_lock spinlock. Since these functions are only called from ata_scsi_rbuf_fill() with ata_scsi_rbuf_get() being called with a copy_in argument always false, the code can be simplified and ata_scsi_rbuf_{get|put} removed. This change both simplifies the code and fixes the sparse warning. Signed-off-by: -
Damien Le Moal authored
The loop on entry of ata_host_start() may not initialize host->ops to a non NULL value. The test on the host_stop field of host->ops must then be preceded by a check that host->ops is not NULL. Reported-by:
-
