[PATCH] ata: libata-core: Add BRIDGE_OK quirk for QEMU drives

[Pedro Falcato]

Currently, whenever you boot with a QEMU drive over an AHCI interface,
you get:
[    1.632121] ata1.00: applying bridge limits

This happens due to the kernel not believing the given drive is SATA,
since word 93 of IDENTIFY (ATA_ID_HW_CONFIG) is non-zero. The result is
a pretty severe limit in max_hw_sectors_kb, which limits our IO sizes.

QEMU shares IDENTIFY data between PATA/SATA drives (and the corresponding
emulation of IDE/AHCI) but does not, in any way, emulate any of these
real hardware details. There is no PATA drive and no SATA cable.

As such, add a BRIDGE_OK quirk for QEMU HARDDISK. This results in the
max_hw_sectors being limited solely by the controller interface's limits.
Which, for AHCI controllers, takes it from 128KB to 32767KB.

Signed-off-by: Pedro Falcato <pfalcato@xxxxxxx>
---
Note: This may be ok for stable, but I'll leave it up to you. There is
obviously no Fixes: here that doesn't go back 20 years.
 drivers/ata/libata-core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index d61846f03edc..70703432063a 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4231,6 +4231,7 @@ static const struct ata_dev_quirks_entry __ata_dev_quirks[] = {
 	/* Devices that do not need bridging limits applied */
 	{ "MTRON MSP-SATA*",		NULL,	ATA_QUIRK_BRIDGE_OK },
 	{ "BUFFALO HD-QSU2/R5",		NULL,	ATA_QUIRK_BRIDGE_OK },
+	{ "QEMU HARDDISK",		NULL,	ATA_QUIRK_BRIDGE_OK },
 
 	/* Devices which aren't very happy with higher link speeds */
 	{ "WD My Book",			NULL,	ATA_QUIRK_1_5_GBPS },
-- 
2.53.0