On 10/27/22 09:50, Damien Le Moal wrote:
Move the detection of a device FUA support from ata_scsiop_mode_sense()/ata_dev_supports_fua() to device scan time in ata_dev_configure(). The function ata_dev_config_fua() is introduced to detect a device FUA support and this support is indicated using the new device flag
'detect a device FUA support'? maybe 'to detect if a device supports FUA'?
ATA_DFLAG_FUA. In order to blacklist known buggy devices, the horkage flag ATA_HORKAGE_NO_FUA is introduced. Similarly to other horkage flags, the libata.force= arguments "fua" and "nofua" are also introduced to allow a user to control this horkage flag through the "force" libata module parameter. The ATA_DFLAG_FUA device flag is set only and only if all the following conditions are met: * libata.fua module parameter is set to 1 * The device advertizes support for the WRITE DMA FUA EXT command, * The device is not marked with the ATA_HORKAGE_NO_FUA flag, either from the blacklist or set by the user with libata.force=nofua * The device supports NCQ (while this is not mandated by the standards, this restriction is introduced to avoid problems with older non-NCQ devices). Note: Enabling or diabling libata fua support for all devices by default can now by done using either the "fua" module parameter or the "force=[port[.device]][no]fua" module parameter when libata.fua==1. Signed-off-by: Damien Le Moal <damien.lemoal@xxxxxxxxxxxxxxxxxx> --- .../admin-guide/kernel-parameters.txt | 3 ++ drivers/ata/libata-core.c | 30 ++++++++++++++++++- drivers/ata/libata-scsi.c | 30 ++----------------- include/linux/libata.h | 8 +++-- 4 files changed, 39 insertions(+), 32 deletions(-) Other than that:
Reviewed-by: Hannes Reinecke <hare@xxxxxxx> Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@xxxxxxx +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
