- 04 1月, 2022 4 次提交
-
-
由 Damien Le Moal 提交于
Use sysfs_emit() instead of snprintf() in ata_scsi_park_show(). Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
由 Damien Le Moal 提交于
Use sysfs_emit() instead of snprintf() in sysfs attibute show() functions. Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
由 Kees Cook 提交于
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. Use struct_group() in struct command_desc around members acmd and fill, so they can be referenced together. This will allow memset(), memcpy(), and sizeof() to more easily reason about sizes, improve readability, and avoid future warnings about writing beyond the end of acmd: In function 'fortify_memset_chk', inlined from 'sata_fsl_qc_prep' at drivers/ata/sata_fsl.c:534:3: ./include/linux/fortify-string.h:199:4: warning: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning] 199 | __write_overflow_field(); | ^~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: NKees Cook <keescook@chromium.org> Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
由 Jason Wang 提交于
Static variables do not need to be initialized to 0. Signed-off-by: NJason Wang <wangborong@cdjrlc.com> Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
- 17 12月, 2021 1 次提交
-
-
由 George Kennedy 提交于
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: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
- 09 12月, 2021 1 次提交
-
-
由 Hannes Reinecke 提交于
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: NHannes Reinecke <hare@suse.de> Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
- 06 12月, 2021 1 次提交
-
-
由 Damien Le Moal 提交于
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: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
- 02 12月, 2021 1 次提交
-
-
由 Yang Guang 提交于
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: NZeal Robot <zealci@zte.com.cn> Signed-off-by: NYang Guang <yang.guang5@zte.com.cn> Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
- 29 11月, 2021 3 次提交
-
-
由 Baokun Li 提交于
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: NHulk Robot <hulkci@huawei.com> Signed-off-by: NBaokun Li <libaokun1@huawei.com> Reviewed-by: NSergei Shtylyov <sergei.shtylyov@gmail.com> Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
由 Baokun Li 提交于
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: NHulk Robot <hulkci@huawei.com> Signed-off-by: NBaokun Li <libaokun1@huawei.com> Reviewed-by: NSergei Shtylyov <sergei.shtylyov@gmail.com> Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
由 Finn Thain 提交于
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: Nkernel test robot <lkp@intel.com> Suggested-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NFinn Thain <fthain@linux-m68k.org> Reviewed-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
- 18 11月, 2021 4 次提交
-
-
由 Damien Le Moal 提交于
Since ata_ncq_sdev_attrs is a local struct, declare it static. This avoids a sparse warning at compile time. Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
由 Mario Limonciello 提交于
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-introSigned-off-by: NMario Limonciello <mario.limonciello@amd.com> Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
由 Mario Limonciello 提交于
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=214091Signed-off-by: NMario Limonciello <mario.limonciello@amd.com> Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
由 Damien Le Moal 提交于
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: NNikolay <knv418@gmail.com> Cc: stable@kernel.org # 5.15 Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com> Tested-by: NMatthew Perkowski <mgperkow@gmail.com>
-
- 17 11月, 2021 1 次提交
-
-
由 Damien Le Moal 提交于
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: NDamien Le Moal <damien.lemoal@opensource.wdc.com> Tested-by: NMatthew Perkowski <mgperkow@gmail.com>
-
- 12 11月, 2021 2 次提交
-
-
由 Damien Le Moal 提交于
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: NDamien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: NChristoph Hellwig <hch@lst.de>
-
由 Damien Le Moal 提交于
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: NDamien Le Moal <damien.lemoal@opensource.wdc.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
- 11 11月, 2021 2 次提交
-
-
由 Xu Wang 提交于
The print function dev_err() is redundant because platform_get_irq() already prints an error. Signed-off-by: NXu Wang <vulab@iscas.ac.cn> Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
由 Damien Le Moal 提交于
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: NGeert Uytterhoeven <geert@linux-m68k.org> Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be> Cc: stable@vger.kernel.org Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
- 27 10月, 2021 1 次提交
-
-
由 Damien Le Moal 提交于
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: NDamien Le Moal <damien.lemoal@wdc.com> Reviewed-by: NHannes Reinecke <hare@suse.de> Reviewed-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Reviewed-by: NKeith Busch <kbusch@kernel.org> Link: https://lore.kernel.org/r/20211027022223.183838-4-damien.lemoal@wdc.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
-
- 25 10月, 2021 1 次提交
-
-
由 Zheyu Ma 提交于
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: NZheyu Ma <zheyuma97@gmail.com> Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
- 17 10月, 2021 2 次提交
-
-
由 Bart Van Assche 提交于
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.orgAcked-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com> Signed-off-by: NBart Van Assche <bvanassche@acm.org> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Bart Van Assche 提交于
Conditional statements are faster than indirect calls. Hence call scsi_done() directly. Link: https://lore.kernel.org/r/20211007202923.2174984-4-bvanassche@acm.orgAcked-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com> Signed-off-by: NBart Van Assche <bvanassche@acm.org> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
- 14 10月, 2021 1 次提交
-
-
由 Wang Hai 提交于
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: NHulk Robot <hulkci@huawei.com> Signed-off-by: NWang Hai <wanghai38@huawei.com> Reviewed-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
-
- 12 10月, 2021 8 次提交
-
-
由 Reimar Döffinger 提交于
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: NReimar Döffinger <Reimar.Doeffinger@gmx.de> Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
-
由 Reimar Döffinger 提交于
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: NReimar Döffinger <Reimar.Doeffinger@gmx.de> Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
-
由 Reimar Döffinger 提交于
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: NReimar Döffinger <Reimar.Doeffinger@gmx.de> Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
-
由 Reimar Döffinger 提交于
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: NReimar Döffinger <Reimar.Doeffinger@gmx.de> Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
-
由 Reimar Döffinger 提交于
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: NReimar Döffinger <Reimar.Doeffinger@gmx.de> Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
-
由 Reimar Döffinger 提交于
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=195895Signed-off-by: NReimar Döffinger <Reimar.Doeffinger@gmx.de> Tested-by: NPaul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
-
由 István Pongrácz 提交于
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: NIstván Pongrácz <pongracz.istvan@gmail.com> Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
-
由 Dan Carpenter 提交于
The last byte of "pad" is used without being initialized. Fixes: 55dba312 ("libata: update ->data_xfer hook for ATAPI") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
-
- 21 9月, 2021 1 次提交
-
-
由 Krzysztof Kozlowski 提交于
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: NKrzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
-
- 03 9月, 2021 2 次提交
-
-
由 Kate Hsuan 提交于
Many 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=201693Signed-off-by: NKate Hsuan <hpa@redhat.com> Reviewed-by: NHans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210903094411.58749-1-hpa@redhat.comReviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Hans de Goede 提交于
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: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NDamien Le Moal <damien.lemoal@wdc.com> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Link: https://lore.kernel.org/r/20210823095220.30157-1-hdegoede@redhat.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
-
- 18 8月, 2021 4 次提交
-
-
由 Damien Le Moal 提交于
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: NDamien Le Moal <damien.lemoal@wdc.com> Link: https://lore.kernel.org/r/20210816014456.2191776-10-damien.lemoal@wdc.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Damien Le Moal 提交于
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: NDamien Le Moal <damien.lemoal@wdc.com> Reviewed-by: NHannes Reinecke <hare@suse.de> Link: https://lore.kernel.org/r/20210816014456.2191776-9-damien.lemoal@wdc.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Damien Le Moal 提交于
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: NDamien Le Moal <damien.lemoal@wdc.com> Reviewed-by: NHannes Reinecke <hare@suse.de> Link: https://lore.kernel.org/r/20210816014456.2191776-8-damien.lemoal@wdc.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Damien Le Moal 提交于
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: NDamien Le Moal <damien.lemoal@wdc.com> Reviewed-by: NHannes Reinecke <hare@suse.de> Link: https://lore.kernel.org/r/20210816014456.2191776-7-damien.lemoal@wdc.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
-