On 06/20/2016 05:44 PM, Tejun Heo wrote: > On Mon, Jun 20, 2016 at 01:39:14PM +0200, Hannes Reinecke wrote: >> The taskfile protocol is a numeric value, and can not be ORed. >> >> Signed-off-by: Hannes Reinecke <hare@xxxxxxx> >> --- >> drivers/ata/libata-core.c | 4 ++-- >> drivers/ata/libata-eh.c | 2 +- >> 2 files changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c >> index e798915..d200102 100644 >> --- a/drivers/ata/libata-core.c >> +++ b/drivers/ata/libata-core.c >> @@ -1238,7 +1238,7 @@ static int ata_read_native_max_address(struct ata_device *dev, u64 *max_sectors) >> } else >> tf.command = ATA_CMD_READ_NATIVE_MAX; >> >> - tf.protocol |= ATA_PROT_NODATA; >> + tf.protocol = ATA_PROT_NODATA; >> tf.device |= ATA_LBA; > > Did the above lead to any actual brekage or was tf.protocol guaranteed > to be zero always? I wish the patch description described what the > stake of the patch is. > This is actually a cleanup; if tf.protocl is '0' we won't see any issues here. But if (for some obsure reason) tf.protocol is _not_ zero we'll run into very obscure problems. Plus the OR here might give others the wrong impression, and might lead to a confusion between ATA_PROT_XXX (which is a scalar value and cannot be ORed) and ATA_PROT_FLAG_XXX (which is a bit value and can be ORed). Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
